On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <[email protected]> wrote:
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
> JDK version to target.
>
> We will refresh this PR periodically to pick up changes and fixes from the
> loom repo.
>
> Most of the new mechanisms in the HotSpot VM are disabled by default and
> require running with `--enable-preview` to enable.
>
> The patch has support for x64 and aarch64 on the usual operating systems
> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero
> and some of the other ports. Additional ports can be contributed via PRs
> against the fibers branch in the loom repo.
>
> There are changes in many areas. To reduce notifications/mails, the labels
> have been trimmed down for now to hotspot, serviceability and core-libs.
> We'll add the complete set of labels when the PR is further along.
>
> The changes include a refresh of java.util.concurrent and ForkJoinPool from
> Doug Lea's CVS. These changes will probably be proposed and integrated in
> advance of this PR.
>
> The changes include some non-exposed and low-level infrastructure to support
> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
> make life a bit easier and avoid having to separate VM changes and juggle
> branches at this time.
src/java.base/share/classes/java/io/BufferedReader.java line 101:
> 99: */
> 100: public BufferedReader(Reader in, int sz) {
> 101: Objects.requireNonNull(in);
Not sure if that even matters - but there will be a slight change of behaviour
here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of
synchronizing on `in`, the `BufferedReader` will synchronize on `this`.
Now that I think of it - it probably does matter since even if
CAN_USE_INTERNAL_LOCK is true, untrusted subclasses of BufferedReader calling
this constructor might expect the locking to be performed on `in`?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8166
