I find it a bit bizarre that this JEP doesn't enable Compact Object Headers by default. Most users will not know to specifically enable it, so if they're that confident in its stability and performance, why not enable it for everyone?
The JVM used to have a reputation for requiring byzantine flags to properly optimise its performance (mostly GC configuration). We've mostly left that behind these days, but it feels like JEP 519 takes a step backwards here.
jeroenhd · 2h ago
The JVM world is slow and extremely careful. If there's a chance something that once works breaks, it'll take many years before the change is applied by default.
Many JVM users can make huge performance gains by switching the GC to a better once and by toggling all kinds of options.
inopinatus · 25m ago
Major enterprise and critical systems worlds can be incredibly conservative even about adopting apparently unequivocal optimisations and improvements, having been burned by changes to runtime duration of batch jobs that activated hidden race conditions with some other service, or compiler optimisations that do away with busy-wait loops that turn out to be completely essential for some signalling protocol or guidance system.
Some might say, “that’s on them”, but once you’ve seen the MS-DOS box running the heart of a major financial institution’s core banking system you kinda understand, even if you don’t sympathise.
zaphirplane · 1h ago
That would be the LTS track. A change has no effect on the LTS version which is supported for a long time
pron · 2h ago
These things tend to be done gradually out of an abundance of caution. Assuming the experience remains positive, it will be made the default in some future release.
SerCe · 3h ago
The previous JEP 450 [1] has a lot more implementation details for those who are interested.
> They have been tested at Oracle by running the full JDK test suite. They have also been tested at Amazon by hundreds of services in production, most of them using backports of the feature to JDK 21 and JDK 17.
One of the underappreciated perks of working on platform teams in large (and very large in the case of Amazon) companies is that you've got a playground to see and quantify the impact of your performance work that few others have.
The JVM used to have a reputation for requiring byzantine flags to properly optimise its performance (mostly GC configuration). We've mostly left that behind these days, but it feels like JEP 519 takes a step backwards here.
Many JVM users can make huge performance gains by switching the GC to a better once and by toggling all kinds of options.
Some might say, “that’s on them”, but once you’ve seen the MS-DOS box running the heart of a major financial institution’s core banking system you kinda understand, even if you don’t sympathise.
> They have been tested at Oracle by running the full JDK test suite. They have also been tested at Amazon by hundreds of services in production, most of them using backports of the feature to JDK 21 and JDK 17.
One of the underappreciated perks of working on platform teams in large (and very large in the case of Amazon) companies is that you've got a playground to see and quantify the impact of your performance work that few others have.
[1]: https://openjdk.org/jeps/450
Very good performance results though. Particularly like the json parsing benchmark showing a 10% performance improvement.
So, you still need to run some perf. testing on your own to decide.