A New Early Access Build

Thu Dec 19 12:38:04 UTC 2019

Hi Ron and the entire Loom dev team.

Thanks for providing a new early access build of project Loom.

I like the "virtual thread is a thread" API and it was very easy
to upgrade and polish my JUnit Loom TestEngine implementation.
Find the interesting lines here: [1] -- pretty straightforward.

Here's [2] also a first result of running up to 1.000.000 tests concurrently
on GitHub Actions using the new API. "Tests" are fake tests, just calling:

  Thread.sleep((long) (Math.random() * 1000))

The result shows some performance degradation compared to the old
API (and implementation). I'm not sure, what causes the difference.
Will update the result table in the README document from time to time.

Cheers,
Christian

[1]:
https://github.com/sormuras/junit5-looming/blob/master/src/de.sormuras.junit.looming/main/java/de/sormuras/junit/looming/LoomTestEngine.java#L43-L60
[2]: https://github.com/sormuras/junit5-looming/runs/356277420

On Thu, Dec 19, 2019 at 11:23 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> Hi.
>
> We have just published a new -- our second -- Early Access build:
>
>     http://jdk.java.net/loom/
>
> This build represents a drastic departure from the API in the first EA
> builds.
> We don't expect further radical changes in the short term, so we may be
> able to
> publish EA builds on a more regular basis.
>
> API
> ---
>
> This prototype has the new API we introduced in October, that represents
> Loom's
> lightweight user-mode threads as instances of java.lang.Thread [1]; the
> rationale for that decision is explained in [2]. We are now calling Loom's
> lightweight user-mode threads "virtual threads" [3].
>
> Virtual threads can be created with the newly-introduced Thread.Builder
> class.
> It can be used to directly build Thread instances, or to create a
> ThreadFactory
> instance. For example:
>
>     Thread thread = Thread.builder().virtual().task(() -> { ... }).start();
>
> Thread.Builder exposes other settings we're experimenting with, like
> optionally
> disallowing the use of ThreadLocal.
>
> The previous EA build introduced structured concurrency [4]. In the updated
> prototype, a more limited form of a structured concurrency can be achieved
> with
> ExecutorService; for example:
>
>     ThreadFactory factory = Thread.builder().virtual().factory();
>     try (ExecutorService executor =
> Executors.newUnboundedExecutor(factory)) {
>         executor.submit(task1);
>         executor.submit(task2);
>     }
>
> The new Executors.newUnboundedExecutor method creates an ExecutorService
> that
> spawns a new thread for each submitted task -- in this case, a virtual
> thread
> constructed by the provided factory.
>
> Please consult the Javadoc [5] for details.
>
>
> Performance
> -----------
>
> We have begun work to improve performance. The performance of virtual
> threads is
> a result of three components: the implementation of continuations in the
> VM, the
> implementation of the scheduler (recall: thread = continuation +
> scheduler), and
> tuning the concurrency constructs in java.util.concurrent to work well with
> virtual threads. So far we've started addressing the first component, and
> this
> build contains a new implementation of continuations. By default, the old
> implementation is used; to use the new one, launch your application with
> the
> flag -XX:+UseContinuationChunks. Depending on your code, you may or may
> not see
> a difference in performance due to the other two components. To reduce the
> effect of the as-yet-untuned scheduler, use a scheduler with a single
> worker
> (carrier) thread. If you are using the default scheduler (by creating the
> thread
> with no-argument Thread.builder().virtual() method), this can be done by
> supplying the flag -Djdk.defaultScheduler.parallelism=1.
>
> Because we are starting to address performance, we are now ready to accept
> benchmarks, preferably those that you think might represent workloads you
> are
> interested in. If you think you have a benchmark that could be of interest
> for
> optimization, please submit it to the mailing list. This can be a
> benchmark with
> what you consider to be unexpectedly bad performance, or just some
> workload you
> find important for your particular use-cases of virtual threads.
>
> I'd like to remind you that virtual threads have the (hopefully temporary)
> limitation that blocking the thread on IO while holding a monitor (i.e.
> inside
> a synchronized method or block) will block the underlying carrier kernel
> thread
> (as do calls to Object.wait()). This should only impact performance if
> done
> frequently. To detect when a virtual thread is "pinned" to the carrier
> thread
> and cannot release it due to a held monitor, add either the
> -Djdk.tracePinnedThreads=full or -Djdk.tracePinnedThreads=short flag.
>
> Debugging
> ---------
>
> You should be able to debug (step-through and inspect) virtual threads in
> jdb or
> an IDE. Some operations are not supported. Please share your experience:
> Does it
> fit your expectations or is the behavior surprising?
>
> Profiling and Monitoring
> ------------------------
>
> We have only begun work to support virtual threads in JFR, and this build
> does
> not yet contain any support for virtual threads.
>
> Continuations
> -------------
>
> Continuations are the low-level VM mechanism used to implement virtual
> threads
> in the core libraries. The Continuation class will likely become
> non-public in
> a future build (whether and how to expose continuations will be debated at
> some
> later time), but it is currently still public. Due to internal changes,
> nested
> continuation scopes currently crash the VM; this will be fixed soon.
>
> Stability
> ---------
>
> This prototype is far from stable, and you can expect VM crashes. If you
> encounter them, please submit a reproduction and the resulting hs_err file
> to
> the mailing list. We will start addressing stability issues in the new
> year.
>
> ---
>
> Most of the Loom team will be out on vacation for the next couple of
> weeks, so
> responses may be sparse; don't let that keep you from posting your reports.
>
> Happy holidays!
>
> - Ron
>
> [1]:
> https://mail.openjdk.java.net/pipermail/loom-dev/2019-October/000825.html
>
> [2]:
> https://mail.openjdk.java.net/pipermail/loom-dev/2019-October/000825.html
>
> [3]:
> https://mail.openjdk.java.net/pipermail/loom-dev/2019-November/000864.html
>
> [4]:
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
>
> [5]: https://download.java.net/java/early_access/loom/docs/api/
>
>
>
>
>