A New Early Access Build

[Dávid Karnok]

Hi. The following setup hangs for me, is this due to the mentioned nested
scope issues right now?

        var result = new AtomicReference<Boolean>();
        try (var exec = Executors.newSingleThreadExecutor()) {
            try (var scope =
Executors.newUnboundedExecutor(Thread.builder().virtual(exec).factory())) {
                try (var scope2  =
Executors.newUnboundedExecutor(Thread.builder().virtual(scope).factory())) {
                    scope2.submit(() ->
result.set(Thread.currentThread().isVirtual()));
                }
            }
        }

        System.out.println(result.get());

Windows 10 x64, Build 14-loom+3-74 (2019/12/18)

Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2019. dec. 19.,
Cs, 11:23):

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

-- 
Best regards,
David Karnok