New Early Access builds
Alan.Bateman at oracle.com
Sat Mar 13 09:53:40 UTC 2021
We've published new builds on the Project Loom Early Access (EA)
download page . 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 
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
 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 , 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.
More information about the loom-dev