New Early Access builds

[Alan Bateman]

We've published new builds on the Project Loom Early Access (EA) 
download page [1]. The new builds are based on jdk-17+13 (JDK 17 build 
13) so are up to date with the main line. The "Getting started" page [1] 
is also up to date.

There are a lot of changes since the last EA build.

The Thread.Builder API has a number of changes to address consistency 
issues and to catch more misuses at compile-time. The Thread API docs 
[3] have examples and hopefully won't be too disruptive. There are 
naming and other issues that we still need to work through so expect at 
least some shimmer as it iterates.

This build has a prototype API for scope variables [4], this replaces 
the previous prototype of lightweight thread locals. There is a rename 
and other API improvements coming but I think we are generally happy 
that it provides an efficient alternative to using thread locals for 
implicit parameters/context. It also supports inheritance at thread 
create time that doesn't require copying so it's super efficient when 
compared to legacy inheritable thread local. Andrew Haley is leading 
this feature and we expect it will go through more iterations and maybe 
be proposed as a preview feature with this own JEP.

There are also a few changes to the 
Executors.newThreadExecutor/newVirtualThreadExecutor APIs, the 
main/experimental change is that they enforce structured usage. There is 
a new method to create a thread executor for unstructured usage (when 
keeping a reference in a static final field for example). Aside from 
encapsulation and other obvious benefits, an additional reward for using 
these executors in a structured manner is better diagnosability in that 
`jcmd JavaThread.dump -format=json <file>` will include the structure in 
the thread dump.

The most significant changes in this build are under the covers in the 
JVM Tools Interface (JVM TI), a native interface that very few people 
will use directly but it critical for debugging, profilers, and other 
tools. Our initial approach for debugging was to train the Java Debug 
Wire Protocol (JDWP) agent be a master illusionist and not require JVM 
TI to have deep support for virtual threads. Emulating the debugger 
suspend policies and many other issues turned out to be too complex and 
unworkable. The summary is that we've done significant U-turn and are in 
the midst of upgrading JVM TI with deep support for virtual threads. 
Most of the upgrade is in this build so that JVM TI functions can be 
called from a virtual threads and events are invoked on virtual threads.

The next step for debugging needs the help of the IDE/debugger 
maintainers. We expect that first class support for virtual threads will 
need to at least some changes in the main stream debuggers. Virtual 
threads are just objects in the heap, there will be many thousands, 
maybe millions. This is a challenge for debuggers that track all threads 
today, e.g. a UI with a drop down list to select a thread is not going 
to scale. Another example is that virtual threads are not live members 
of a thread group and at least some debuggers have views by thread 
group. The JDWP agent in this build has a number of configuration 
options to emulate legacy behavior that help "virtual thread unaware" 
debuggers but we'd like that to be temporary if possible. We'll document 
those on the wiki.

This may be the last build with the "old" implementation for freezing 
and thawing stacks and the option to disable lazy copy. Ron has changes 
coming soon that upgrade the new implementation to support interpreter 
frames that will allow the old implementation and a lot of code, esp. 
architecture specific code, to go away. Once that in then it unlocks the 
door for ports, aarch64 being the highest priority.

That's probably enough for now.

-Alan



[1] https://jdk.java.net/loom/
[2] https://wiki.openjdk.java.net/display/loom/Getting+started
[3] 
https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html
[4] 
https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Scoped.html