Update latest release section for 0.39.0

[Sreekala-Gopakumar]

What's New update for the website, for 0.39.0 (June 2023)

[Sreekala-Gopakumar]

First draft (0.38.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.39.0 released

June 2023

We're pleased to announce the availability of Eclipse OpenJ9™ v0.39.0.

This release supports OpenJDK 20. For more information about supported platforms and OpenJDK versions, see Supported environments.

Other update in this release include the following:

• RHEL 8.4 is out of support. RHEL 8.6 is the new minimum operating system level.

To read more about these and other changes, see the OpenJ9 user documentation.

Performance highlights include:

• For virtual threads, throughput is optimized by reducing the synchronization overhead in the mount and unmount code paths, and the memory usage is reduced through a Java stack caching feature that enables reuse of Java stacks.
• MethodHandle throughput performance is improved by using compiled code instead of interpreter in more cases.
• Footprint in garbage collection (GC) policies other than the balanced GC is improved with enabling of dual indexable header.

[Sreekala-Gopakumar]

@pshipton @vijaysun-omr @tajila @babsingh Are there any performance updates that you want to highlight in the website? Any other what's new update to be added here? Thanks!

[babsingh]

Are there any performance updates that you want to highlight in the website?

Virtual threads have been significantly optimized for better throughput and lower memory usage. Throughput was optimized by reducing the synchronization overhead in the virtual thread's mount and unmount code paths. Memory usage was reduced via a Java stack caching feature, which allows us to reuse Java stacks; this leads to better scalability i.e. an app can launch a lot more virtual threads without hitting the memory limit.

@Sreekala-Gopakumar Is the above statement sufficient or are more details required?

[vijaysun-omr]

@amicic was footprint improvement due to dual indexable header shape shipped in this release ? If so, we should mention a sentence about the fact that footprint improved.

[vijaysun-omr]

We should mention that "MethodHandle throughput performance was improved by some changes in this release"

[Sreekala-Gopakumar]

We should mention that "MethodHandle throughput performance was improved by some changes in this release"

Any particular change that the user must know? Saying "some changes" is ambiguous.

[vijaysun-omr]

The change in question was https://github.com/eclipse-openj9/openj9/pull/17322 . Instead of "some changes" you could say "using compiled code instead of interpreter in more cases" and maybe that is the right balance between being too specific and too generic.

[amicic]

@amicic was footprint improvement due to dual indexable header shape shipped in this release ? If so, we should mention a sentence about the fact that footprint improved.

Yes, I can confirm that dual indexable header was enabled in 0.39.

[amicic]

Besides small footprint improvements (or reduction of GC overhead for fully expanded heap) in GC policies other than Balanced GC, note there is also a slight throughput regression in Balanced GC, since we now initialize dataAddr. But we intend to compensate it with off-heap allocations in near future.

[Sreekala-Gopakumar]

@babsingh @vijaysun-omr @amicic - I have updated the content. Please check and confirm. Thanks!

[babsingh]

LGTM. Minor reword recommended:

For virtual threads, throughput is optimized by reducing the synchronization overhead in the mount and unmount code paths, and memory usage is reduced through a Java stack caching feature that enables reuse of Java stacks.

[vijaysun-omr]

Thanks, LGTM

[Sreekala-Gopakumar]

@pshipton @vijaysun-omr @tajila @babsingh @amicic - Can we finalise this content? Thanks!

[Sreekala-Gopakumar]

LGTM. Minor reword recommended:

For virtual threads, throughput is optimized by reducing the synchronization overhead in the mount and unmount code paths, and memory usage is reduced through a Java stack caching feature that enables reuse of Java stacks.

Done.

[babsingh]

Can we finalise this content?

GTG. No more changes from my end.

[pshipton]

lgtm