New Early Access builds

Christian Stein sormuras at
Sat Mar 13 17:17:31 UTC 2021

Hi Alan,

As usual, here's my short feedback on using the latest Loom build
with a `Thread.sleep()` JUnit 5 TestEngine [0]: all is fine and green.
No API changes affected this tiny implementation [1].



On Sat, Mar 13, 2021 at 10:54 AM Alan Bateman <Alan.Bateman at>

> 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]
> [2]
> [3]
> [4]

More information about the loom-dev mailing list