On Wed, 27 Apr 2022 14:24:20 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.
>
> Alan Bateman has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

I've reviewed the new files in Hotspot runtime and the cpu directories, as well 
as the changes to existing files in runtime, oops, utilities, interpreter and 
classfile.
I'm happy to approve this PR. Thank you to everyone for their hard work in 
reviewing this code, and well done to @pron and @AlanBateman and all the loom 
team for bringing us this significant and exciting new feature for Java!

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388:

> 2386: }
> 2387: 
> 2388: void

@sspitsyn We should clean up this aberrant style of putting the return type on 
the line before the rest of the function declaration after this integration.  
It looks so strange.  I noticed that it's pre-existing for other functions in 
this file.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

Reply via email to