openj9-website
openj9-website copied to clipboard
Update latest release section for 0.44.0
What's New update for the website, for 0.44.0 (May 2024)
First draft (0.43.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.44.0 released
May 2024
We're pleased to announce the availability of Eclipse OpenJ9™ v0.44.0.
This release supports OpenJDK 8, 11, 17, and 21. For more information about supported platforms and OpenJDK versions, see Supported environments.
Other updates in this release include the following:
- Like on other operating systems, on AIX systems also the display of warnings each time the same agent is loaded without specifying the
-XX:+EnableDynamicAgentLoading
option is now restricted to displaying the warnings on the first load only.- XL C++ Runtime 16.1.0.7 or later is required for AIX OpenJ9 builds on OpenJDK 8.
- A new option,
-XX:[+|-]ShowUnmountedThreadStacks
is added to control the inclusion of the unmounted virtual threads in a Java™ core file.- For OpenJDK compatibility, OpenJ9 now supports direct use of the Java process name, full or partial, as the ID to send the
jcmd
command. Thejcmd
tool also now supports specifying0
as a VMID to target all VMs.- Flag names that refer to the fields of
J9BuildFlags
are changed in the Direct Dump Reader (DDR) code. To reduce complexity and improve the uniformity of how the DDR code uses the flags, you must use the names that are specified inj9cfg.h
as flag names in the plug-in code.- A new system property,
-Dcom.ibm.tools.attach.fileAccessUpdateTime
, is added to prevent automatic deletion of the Attach API control files in the/tmp
folder.To read more about these and other changes, see the OpenJ9 user documentation.
Performance highlights include:
- Improvements to JVMTI redefinition and restransformation runtime performance.
- JITServer now supports Java 21.
- Performance optimisation due to not storing or finding heap size hints when heap is fully expanded.
@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!
@tajila should we be mentioning the fix (improvement) to the JVMTI code path that was doing a heap walk when a class was redefined ? I'm not sure if the current status on that is if it will make it for 0.44 but I wanted to ask about it since that was seen by a user.
@mpirvu do we need to mention the changes for AOT code being used independently of the shared cache with JIT server, or anything else ?
I wouldn't mention about the AOT cache being used independently of the SCC at the client until I am satisfied with performance.
We could mention that JITServer now supports Java 21.
@tajila should we be mentioning the fix (improvement) to the JVMTI code path that was doing a heap walk when a class was redefined ? I'm not sure if the current status on that is if it will make it for 0.44 but I wanted to ask about it since that was seen by a user.
The changes will make it into 0.44 so we can mention them. I'm not sure how much detail we need to go into, but something like: "Improvements to JVMTI redefinition and restransformation runtime performance."
@pshipton @vijaysun-omr @tajila @mpirvu - I have updated the content (https://github.com/eclipse-openj9/openj9-website/issues/364#issuecomment-1987783990). Anything else to be added?
Is there anything else to be added to "Improvements to JVMTI redefinition and restransformation runtime performance." ? This will be enough for the user to understand the improvement?
Thanks!
Looks good from my side.
Is there anything else to be added to "Improvements to JVMTI redefinition and restransformation runtime performance."
@tajila could we say the performance regression when moving from jdk8 or jdk11 to jdk17+ no longer exists?
Flag names that refer to the fields of J9BuildFlags is changed
-> are changed.
@pshipton @amicic - I have added the following line under the Performance highlights:
Performance optimisation because of not storing or finding heap size hints when heap is fully expanded.
Is this ok? Thanks!
I would word it using "due to" rather than "because of".
Published