New Early Access builds

[Christian Stein]

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].

Cheers,
Christian

[0] https://github.com/sormuras/junit5-looming
[1]
https://github.com/sormuras/junit5-looming/blob/master/src/de.sormuras.junit.looming/main/java/de/sormuras/junit/looming/LoomTestEngine.java

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

>
> 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
>
>