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
src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168:
> 166: assert(!tl->is_excluded(), "invariant");
> 167: if (virtual_thread) {
> 168: // TODO: blob cache for virtual threads
Fix this now or after integration?
src/hotspot/share/jfr/metadata/metadata.xml line 121:
> 119: thread="true" stackTrace="true">
> 120: <Field type="Thread" name="carrierThread" label="Carrier Thread"
> description="Thread enlisted as a carrier" />
> 121: <Field type="Class" name="contClass" label="Continuation class"
> description="Class of the continuation" />
"Continuation class" = >" Continuation Class"
numFrames = frames
numRefs = references
"Number of interpreted frames" => "Interpreted Frames"
"Number of references" => "References"
"Stack size in bytes" => "Stack Size" contentType"bytes"
src/hotspot/share/jfr/metadata/metadata.xml line 130:
> 128: thread="true" stackTrace="true">
> 129: <Field type="Thread" name="carrierThread" label="Carrier Thread"
> description="Thread enlisted as a carrier" />
> 130: <Field type="Class" name="contClass" label="Continuation class"
> description="Class of the continuation" />
contClass => continuationClass
"Continuation class" => "Continuation Class"
"Class of the continuation" Remove (not needed)
"Number of interpreted frames" => "Interpreted Frames"
numFrames => frames
"Number of references" => "References"
numRefs => references
"Stack size in bytes" => "Stack Size" contentType="bytes"
src/hotspot/share/jfr/metadata/metadata.xml line 138:
> 136: <Event name="ContinuationFreezeYoung" experimental="true"
> category="Java Virtual Machine" label="Continuation Freeze Young"
> thread="true" stackTrace="false" startTime="false">
> 137: <Field type="ulong" name="id" label="Continuation ID" />
> 138: <Field type="uint" name="size" label="Size" />
"Allocated new" => "Allocated New"
src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94:
> 92: static const size_t global_buffer_size = 512 * K;
> 93:
> 94: static const size_t thread_local_buffer_prealloc_count = 32;
Why is more memory needed? Moore's law or something specific to virtual threads?
src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81:
> 79: be_writer.write(size);
> 80: be_writer.write(time);
> 81: be_writer.write(JfrTicks::now().value() - time);
Why is this changed?
src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35:
> 33:
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread end")
"Virtual thread end" => "Virtual Thread End"
Remove description.
src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35:
> 33:
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread pinned")
"Virtual thread pinned" => "Virtual Thread Pinned"
Remove description
src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35:
> 33:
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread start")
"virtual thread start" => "Virtual Thread Start"
Remove description
src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java
line 35:
> 33:
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread submit task failed")
The label is a bit a long, would "Virtual Thread Submit Failed" work?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8166
