On Fri, 6 May 2022 06:48:46 GMT, Alan Bateman <al...@openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 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 
>> can add additional labels, if required, as the PR progresses.
>> 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 Extent 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 with a new target base due to a 
> merge or a rebase. The pull request now contains 21 commits:
>  - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
>  - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - ... and 11 more: 
> https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

> It is understandable to ship the preview feature not implemented on all 
> platforms. It is even understandable to ship the final product feature that 
> breaks some platforms in an clearly understandable way, prompting platform 
> maintainers to implement the agreed-upon, final Java feature. What I am 
> seeing, though, is that just running `java -version` (!) after integrating a 
> _preview feature_ is broken!

Preview features need to be implemented by a port before it can be released. 
For JDK 19 this means that the maintainers of ports will have work to do for 
both JEP 424 and JEP 425 (ifdef is not an option).

I think the issue that are concerned about is the interim period between the 
JEP 425 integration and the port/implementation of this feature to other 
architectures. I think the answer is that it will vary. It may be that some 
port maintainers decide to do something very short term so they can run without 
--enable-preview and buy time before they do the port/implementation for JDK 
19. Good progress has been reported on at least ppc64le port and maybe that 
port be ready before others. So yes, some ports may crash until they receive 
attention, others (like zero) should be able to run tests that don't use 
--enable-preview. I've no doubt there will be a flurry of changes post 

The motivation for Continuations::enabled() was to reduce risk and disable a 
lot of the new code by default. The motivation wasn't porting but it may be 
helpful during the interim period. That is probably a topic for loom-dev rather 


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

Reply via email to