New Early Access builds

Christian Stein sormuras at gmail.com
Sat Jan 16 09:49:51 UTC 2021


Ran the "junit5-looming" [0] with the new build, and
everything's looking good. Especially the 114 seconds
for executing 1.000.000 virtual threads on the GH
"hardware" marks a new best value.

Cheers,
Christian

[0]:
https://github.com/sormuras/junit5-looming/runs/1713243492?check_suite_focus=true#step:3:5

On Sat, Jan 16, 2021 at 9:36 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> We've published new builds on the Project Loom Early Access download
> page [1]. The new builds are based on jdk-17+5 (JDK 17 build 5) so we
> are up to date with the main line. The "Getting started" page [1] is up
> to date.
>
> There are a few more stability fixes in this build, our testing has been
> with G1 and ZGC.
>
> As I mentioned in a previous mail, the debugger support has been work in
> progress. The implementation of JVM TI (the underlying tools interface)
> has been significantly updated since the last build. It's enough to get
> jshell working again. There are still a few issues with some of the low
> level events around scheduling points and we need to resolve those
> issues before the IDE debuggers will step correctly.
>
> We've started to explore serviceability/diagnosability features. JFR has
> support for virtual threads for some time, it can record socket I/O
> events on virtual threads that exceed some threshold for example. There
> is also rudimentary support for thread dumps in this build in the form
> of a new jcmd command and a new JDK-specific ThreadMXBean operation.
> Use `jcmd <pid> JavaThread.dump -format=json` to get a thread dump in
> JSON format.  For now, the thread dump will only include the stack trace
> of virtual threads when the new thread executors are used, and only when
> they are used in a structured way. The JSON object has enough to allow
> tools to reconstitute the structure, de-duplicate stack traces, and
> other interesting things. We're re-evaulate all this at some point but
> for now, it's something simple that does not require a stop-the-world
> operation to find the virtual threads in the heap.
>
> -Alan
>
> [1] http://jdk.java.net/loom/
> [2] https://wiki.openjdk.java.net/display/loom/Getting+started
>


More information about the loom-dev mailing list