Re: [External] : Re: JDK 22 Release Candidates & Virtual Threads pinning heads-up

[David Delabassee]

Thanks for the update !

--David

From: Rick Hillegas 
Date: Wednesday, 21 February 2024 at 01:12
To: derby-dev@db.apache.org , David Delabassee 

Subject: [External] : Re: JDK 22 Release Candidates & Virtual Threads pinning 
heads-up
Thanks for the heads-up, David. Derby found no problems with this
release candidate. See 
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs8iGLOM3$

On 2/20/24 12:00 AM, David Delabassee wrote:
> Welcome to the latest OpenJDK Quality Outreach update!
>
> The first JDK 22 Release Candidates builds are now available [1]. At this 
> stage, only P1 issues will still be evaluated. And with the JDK 22 General 
> Availability set for March 19th, it is now time to fully focus on JDK 23. At 
> the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 
> 455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But 
> new JEP candidates [3][4] have recently been announced, so things should 
> evolve rapidly.
>
> I'd like to thank those of you who have already provided feedback on the JDK 
> 22 EA builds. Feedback is always extremely useful, even more, when it comes 
> early in the development cycle. Another area where we need your help is Loom. 
> So, please make sure to check the heads-up below that discusses the so-called 
> Virtual Threads "pinning" issue.
>
> [1] https://openjdk.org/projects/jdk/22/
> [2] https://openjdk.org/jeps/455
> [3] https://openjdk.org/jeps/465
> [4] https://openjdk.org/jeps/466
>
>
> ## Heads-up: Virtual Threads “Pinning” Issue
>
> Virtual threads became a permanent feature in JDK 21. This feature has been 
> extremely well received by the Java ecosystem but there are still a few pain 
> points. Much has been written about the so-called "pinning" issue that arises 
> with synchronized methods or synchronized statements. The two most common 
> cases are (a) a virtual thread parks (ex. doing socket I/O) while in a 
> synchronized method, and (b) a virtual thread blocks entering a synchronized 
> method because the object's associated monitor is held by another thread. In 
> both cases, the underlying carrier/native thread is not "released" to do 
> other work. Performance and scalability may suffer and in some cases, 
> starvation and deadlock might happen. This recent "Virtual Threads Next 
> Steps" video [5] explains in more details the why's and discusses some 
> potential solutions.
>
> New Loom early-access builds haven been recently published [6]. Those Loom EA 
> builds have changes to the object monitor implementation that do not pin for 
> these two common cases. The Loom team needs your help to test these updated 
> object monitors with code that you know is using virtual threads and with 
> libraries that are heavily synchronized. The goal is to gauge both 
> reliability and performance.
>
> The simplest way to report an issue or feedback is to use the Loom mailing 
> list [7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current 
> default) and `-XX:LockingMode=2` would be extremely helpful as that would 
> exercise the two locking modes currently implemented by the HotSpot VM.
>
> [5] 
> https://urldefense.com/v3/__https://inside.java/2024/02/17/virtual-threads-next-steps/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsxUtvLKd$
> [6] 
> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs2hd_OBY$
> [7] https://mail.openjdk.org/pipermail/loom-dev/
>
>
> ## JDK 22 Release Candidates
>
> The JDK 22 Release Candidate builds (builds 36) are available [8] and are 
> provided under the GNU General Public License v2, with the Classpath 
> Exception. The Release Notes are available here [9], and the javadocs here 
> [10].
>
> [8] 
> https://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsyPEpb4d$
> [9] 
> https://urldefense.com/v3/__https://jdk.java.net/22/release-notes__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJP

Re: JDK 22 Release Candidates & Virtual Threads pinning heads-up

[Rick Hillegas]

Thanks for the heads-up, David. Derby found no problems with this 
release candidate. See https://issues.apache.org/jira/browse/DERBY-7159


On 2/20/24 12:00 AM, David Delabassee wrote:

Welcome to the latest OpenJDK Quality Outreach update!

The first JDK 22 Release Candidates builds are now available [1]. At this 
stage, only P1 issues will still be evaluated. And with the JDK 22 General 
Availability set for March 19th, it is now time to fully focus on JDK 23. At 
the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 
455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But 
new JEP candidates [3][4] have recently been announced, so things should evolve 
rapidly.

I'd like to thank those of you who have already provided feedback on the JDK 22 EA 
builds. Feedback is always extremely useful, even more, when it comes early in the 
development cycle. Another area where we need your help is Loom. So, please make sure to 
check the heads-up below that discusses the so-called Virtual Threads "pinning" 
issue.

[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466


## Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been extremely well received by the 
Java ecosystem but there are still a few pain points. Much has been written about the so-called 
"pinning" issue that arises with synchronized methods or synchronized statements. The two most 
common cases are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized method, and (b) a 
virtual thread blocks entering a synchronized method because the object's associated monitor is held by 
another thread. In both cases, the underlying carrier/native thread is not "released" to do other 
work. Performance and scalability may suffer and in some cases, starvation and deadlock might happen. This 
recent "Virtual Threads Next Steps" video [5] explains in more details the why's and discusses some 
potential solutions.

New Loom early-access builds haven been recently published [6]. Those Loom EA 
builds have changes to the object monitor implementation that do not pin for 
these two common cases. The Loom team needs your help to test these updated 
object monitors with code that you know is using virtual threads and with 
libraries that are heavily synchronized. The goal is to gauge both reliability 
and performance.

The simplest way to report an issue or feedback is to use the Loom mailing list 
[7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current default) 
and `-XX:LockingMode=2` would be extremely helpful as that would exercise the 
two locking modes currently implemented by the HotSpot VM.

[5] https://inside.java/2024/02/17/virtual-threads-next-steps/
[6] https://jdk.java.net/loom/
[7] https://mail.openjdk.org/pipermail/loom-dev/


## JDK 22 Release Candidates

The JDK 22 Release Candidate builds (builds 36) are available [8] and are 
provided under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [9], and the javadocs here [10].

[8] https://jdk.java.net/22/
[9] https://jdk.java.net/22/release-notes
[10] https://download.java.net/java/early_access/jdk22/docs/api/


## JDK 23 Early-Access Builds

The JDK 23 Early-Access builds 10 are available [11], and are provided under 
the GNU General Public License v2, with the Classpath Exception. The Release 
Notes are available here [12].

### Changes in recent JDK 23 builds that may be of interest:

- JDK-8324287: Record total and free swap space in JFR
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8324665: Loose matching of space separators in the lenient date/time 
parsing mode
- JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks 
because it can be very slow
- JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat 
pattern
- JDK-8325221: Obsolete TLABStats
- JDK-8322535: Change default AArch64 SpinPause instruction
- JDK-8323746: Add PathElement hashCode and equals
- JDK-8325570: Update to Graphviz 9.0.0
- JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8324068: Improve references to tags in the Doc Comment Spec
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8321545: Override toString() for Format subclasses
- JDK-8324301: Obsolete MaxGCMinorPauseMillis
- JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1
- JDK-8324771: Obsolete RAMFraction related flags
- JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa…
- JDK-8325150: (tz) Update Timezone Data to 2024a
- JDK-8324571: JDK 23 L10n resource files update

Note: Complete list of changes can be found here [13].

[11] https://jdk.java.net/23/
[12] https://jdk.jav

[jira] [Commented] (DERBY-7159) Make it possible to build and test Derby with Open JDK 22

[Richard N. Hillegas (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819020#comment-17819020
 ] 

Richard N. Hillegas commented on DERBY-7159:


Derby built cleanly (including javadoc) with the first release candidate for 
Open JDK 22 (build 22+36-2370). The tests ran cleanly with both the classpath 
and modulepath.

> Make it possible to build and test Derby with Open JDK 22
> -
>
> Key: DERBY-7159
> URL: https://issues.apache.org/jira/browse/DERBY-7159
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7159-01-aa-addJdk22VM.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

JDK 22 Release Candidates & Virtual Threads pinning heads-up

[David Delabassee]

Welcome to the latest OpenJDK Quality Outreach update!

The first JDK 22 Release Candidates builds are now available [1]. At this 
stage, only P1 issues will still be evaluated. And with the JDK 22 General 
Availability set for March 19th, it is now time to fully focus on JDK 23. At 
the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 
455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But 
new JEP candidates [3][4] have recently been announced, so things should evolve 
rapidly.

I'd like to thank those of you who have already provided feedback on the JDK 22 
EA builds. Feedback is always extremely useful, even more, when it comes early 
in the development cycle. Another area where we need your help is Loom. So, 
please make sure to check the heads-up below that discusses the so-called 
Virtual Threads "pinning" issue.

[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466


## Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been 
extremely well received by the Java ecosystem but there are still a few pain 
points. Much has been written about the so-called "pinning" issue that arises 
with synchronized methods or synchronized statements. The two most common cases 
are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized 
method, and (b) a virtual thread blocks entering a synchronized method because 
the object's associated monitor is held by another thread. In both cases, the 
underlying carrier/native thread is not "released" to do other work. 
Performance and scalability may suffer and in some cases, starvation and 
deadlock might happen. This recent "Virtual Threads Next Steps" video [5] 
explains in more details the why's and discusses some potential solutions.

New Loom early-access builds haven been recently published [6]. Those Loom EA 
builds have changes to the object monitor implementation that do not pin for 
these two common cases. The Loom team needs your help to test these updated 
object monitors with code that you know is using virtual threads and with 
libraries that are heavily synchronized. The goal is to gauge both reliability 
and performance.

The simplest way to report an issue or feedback is to use the Loom mailing list 
[7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current default) 
and `-XX:LockingMode=2` would be extremely helpful as that would exercise the 
two locking modes currently implemented by the HotSpot VM.

[5] https://inside.java/2024/02/17/virtual-threads-next-steps/
[6] https://jdk.java.net/loom/
[7] https://mail.openjdk.org/pipermail/loom-dev/


## JDK 22 Release Candidates

The JDK 22 Release Candidate builds (builds 36) are available [8] and are 
provided under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [9], and the javadocs here [10].

[8] https://jdk.java.net/22/
[9] https://jdk.java.net/22/release-notes
[10] https://download.java.net/java/early_access/jdk22/docs/api/


## JDK 23 Early-Access Builds

The JDK 23 Early-Access builds 10 are available [11], and are provided under 
the GNU General Public License v2, with the Classpath Exception. The Release 
Notes are available here [12].

### Changes in recent JDK 23 builds that may be of interest:

- JDK-8324287: Record total and free swap space in JFR
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8324665: Loose matching of space separators in the lenient date/time 
parsing mode
- JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks 
because it can be very slow
- JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat 
pattern
- JDK-8325221: Obsolete TLABStats
- JDK-8322535: Change default AArch64 SpinPause instruction
- JDK-8323746: Add PathElement hashCode and equals
- JDK-8325570: Update to Graphviz 9.0.0
- JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8324068: Improve references to tags in the Doc Comment Spec
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8321545: Override toString() for Format subclasses
- JDK-8324301: Obsolete MaxGCMinorPauseMillis
- JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1
- JDK-8324771: Obsolete RAMFraction related flags
- JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa…
- JDK-8325150: (tz) Update Timezone Data to 2024a
- JDK-8324571: JDK 23 L10n resource files update

Note: Complete list of changes can be found here [13].

[11] https://jdk.java.net/23/
[12] https://jdk.java.net/23/release-notes
[13] https://github.com/openjdk/jdk/compare/jdk-23+6...jdk-23+10


## JavaFX Early-Access Builds:

These are early access builds of the JavaFX 22 & 23 Runtime bui