On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <al...@openjdk.org> 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