openj9-website
openj9-website copied to clipboard
eclipse-openj9
Update latest release section for 0.46.0
What's New update for the website, for 0.46.0 (August 2024)
First draft (0.45.0 content is live at https://www.eclipse.org/openj9). Note: this isn't an exhaustive list of all the changes, just the main ones:
Eclipse OpenJ9 version 0.46.0 released
August 2024
We're pleased to announce the availability of Eclipse OpenJ9™ v0.46.0.
This release supports OpenJDK 8, 11, 17, 21, and 22. For more information about supported platforms and OpenJDK versions, see Supported environments.
Other updates in this release include the following:
- OpenSSL native cryptographic support is added for the MD5 message digest algorithm, providing improved cryptographic performance.
- The OpenJ9 VM implementation supports measurement of the total memory allocation for all threads (
com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes()API).- The JITServer AOT caching feature is enabled by default at the JITServer server. The client still needs the
-XX:+JITServerUseAOTCacheoption, but it no longer relies on the presence of a shared class cache to take advantage of this feature.- A new option,
-XX:[+|-]EnableExtendedHCRis added to enable or disable the extended Hot Code Replace (HCR) capability in the VM.- A new option,
-XX:[+|-]ShareOrphansis added to enable class sharing from all class loaders, irrespective of whether the class loader implements the shared classes cache API.- A new option,
-XdynamicHeapAdjustmentoption is added to automatically adjust the maximum and minimum Java heap sizes such that they are within the physical memory limitations on the checkpoint and restore systems.To read more about these and other changes, see the OpenJ9 user documentation.
Performance highlights include:
- Performance improvements to object and array allocation sequences on X86.
- Performance improvements to array copying sequences on X86.
- VarHandle performance improvements because of support for inlining VarHandle operations.
@pshipton @vijaysun-omr - Are there any performance updates that you want to highlight in the website? Any other what's new update to be added here? Thanks!
To start with, a couple of statements.
Performance improvements to object and array allocation sequences on X86. Performance improvements to array copying sequences on X86.
@mpirvu please summarize anything from a general control viewpoint, as well as specific features like AOT caching. @nbhuiyan how would you characterize the method handle performance improvements in 1-4 sentences ?
fyi @0xdaryl and @hzongaro
From a VM perspective, do we need to document the new option for storing more classes in the shared classes cache ? @hangshao0 and @tajila
From a VM perspective, do we need to document the new option for storing more classes in the shared classes cache ?
Yes, we need to document that. The doc issue is https://github.com/eclipse-openj9/openj9-docs/issues/1330.
Suggested phrasing for the AOT cache feature:
The JITServer AOT caching feature is enabled by default at the JITServer server. The client still needs the -XX:+JITServerUseAOTCache option, but it no longer relies on the presence of a shared class cache to take advantage of this feature.
As for other performance improvements:
- there was a small footprint improvement due to disclaiming of memory used for data caches and interpreter profiler
- there was a small reduction in compilation overhead due to some inliner changes
Quantifying the amount of these improvement is hard because it depends on the benchmark being run. I am not sure whether we should call them out.
As for other performance improvements:
- there was a small footprint improvement due to disclaiming of memory used for data caches and interpreter profiler
- there was a small reduction in compilation overhead due to some inliner changes
Quantifying the amount of these improvement is hard because it depends on the benchmark being run. I am not sure whether we should call them out.
I would prefer NOT to call these out at this time. Thanks for checking.
how would you characterize the method handle performance improvements in 1-4 sentences ?
Support for inlining VarHandle operations resulting in major improvements in VarHandle performance.
As for other performance improvements:
- there was a small footprint improvement due to disclaiming of memory used for data caches and interpreter profiler
- there was a small reduction in compilation overhead due to some inliner changes
Quantifying the amount of these improvement is hard because it depends on the benchmark being run. I am not sure whether we should call them out.
I would prefer NOT to call these out at this time. Thanks for checking.
@vijaysun-omr - So that means I don't have to mention these 2 points?
To start with, a couple of statements.
Performance improvements to object and array allocation sequences on X86. Performance improvements to array copying sequences on X86.
@mpirvu please summarize anything from a general control viewpoint, as well as specific features like AOT caching. @nbhuiyan how would you characterize the method handle performance improvements in 1-4 sentences ?
fyi @0xdaryl and @hzongaro
@vijaysun-omr - Is it clear enough to write "X86"?
how would you characterize the method handle performance improvements in 1-4 sentences ?
Support for inlining VarHandle operations resulting in major improvements in VarHandle performance.
@nbhuiyan @vijaysun-omr - Would the users understand this statement? Sounds very technical and vague to me but if everybody's of the opinion that the users will understand this then I will write it as
VarHandle performance improvements because of support for inlining VarHandle operations.
Is that fine?
VarHandle performance improvements because of support for inlining VarHandle operations.
Yes, this works too.
How about just "Improved VarHandle performance" ? I doubt our users care why it specifically improved...
How about just "Improved VarHandle performance" ? I doubt our users care why it specifically improved...
I agree. @Sreekala-Gopakumar Please update the VarHandle note in eclipse-openj9/openj9-website-publish#16 if you also agree with removing this detail.
And..."Improved allocation and arraycopy instruction sequences for X86" ?
Is it clear enough to write "X86"? Is it something that the developers use internally or is there some other term that we can use that is clearer?
Website updated with the 0.46.0 release updates (10 August 2024) https://eclipse.dev/openj9/