> 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.
>
>
On Thu, 5 May 2022 13:42:12 GMT, Jaroslav Bachorik
wrote:
>> An option would be to place it after
>> https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901
>> but it would make the code less coherent.
>
> Ok, moved it a bit around
On Thu, 5 May 2022 12:40:02 GMT, Jaroslav Bachorik
wrote:
>> src/hotspot/share/runtime/thread.hpp line 649:
>>
>>> 647: // support AGCT
>>> 648: private:
>>> 649: bool _in_agct;
>>
>> This should actually be in JavaThread as AGCT only operates on JavaThreads.
>
> I will have to do check/ca
> The test counts calls of intercepted JNI functions, but doesn't completely
> filter out calls from other threads.
> Function isThreadExpected is used only for ExceptionOccurred function and the
> function checks only some known JFR/Graal threads.
>
> The change:
> - updates the test to count
On Mon, 2 May 2022 23:20:52 GMT, Alex Menkov wrote:
> The test counts all "system" threads before the execution and expects that
> this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads
> may end.
>
> The fix updates the
On Thu, 5 May 2022 17:43:58 GMT, Aleksey Shipilev wrote:
> I am sorry to be a buzzkill here, but this integration would break lots of
> platforms even when Loom functionality is not enabled/used. For example,
> running `java -version` on RISC-V runs into many issues:
> `TemplateInterpreterGene
On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman 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 an
On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman 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 an
On Thu, 5 May 2022 13:02:58 GMT, Jaroslav Bachorik
wrote:
>> A gist of the fix is to allow relaxed special handling of code blob lookup
>> when done for ASGCT.
>>
>> Currently, a guarantee will fail when we happen to hit a zombie method which
>> is still on stack. While this would indicate a
On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman 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 an
On Thu, 5 May 2022 13:21:39 GMT, Johannes Bechberger
wrote:
>> I had tried identifying any gaps I might use but found none. Not saying they
>> are none but it is rather difficult to spot anything with all the Thread
>> related attributes spread across many lines, interspersed with the method
On Thu, 5 May 2022 12:55:31 GMT, Jaroslav Bachorik
wrote:
>> Just to clarify - you mean finding a gap due to padding and putting the
>> field there?
>> The rest of the fields are usually clustered around the supported
>> functionality so before I insert this flag somewhere in the middle of
>>
On Thu, 5 May 2022 12:20:41 GMT, Jaroslav Bachorik
wrote:
>> src/hotspot/share/runtime/thread.hpp line 649:
>>
>>> 647: // support ASGCT
>>> 648: private:
>>> 649: bool _in_asgct;
>>
>> The position of this field may be significant. See if there are gaps in the
>> Thread structure which t
> A gist of the fix is to allow relaxed special handling of code blob lookup
> when done for ASGCT.
>
> Currently, a guarantee will fail when we happen to hit a zombie method which
> is still on stack. While this would indicate a serious error for the normal
> execution flow, in case of ASGCT
On Thu, 5 May 2022 12:13:49 GMT, David Holmes wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Naming and comments cleanup
>
> src/hotspot/share/runtime/thread.hpp line 649:
>
>> 647: // support AGCT
>> 648:
On Thu, 5 May 2022 12:00:49 GMT, David Holmes wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make sure the code blob result check is correct
>
> src/hotspot/share/runtime/thread.hpp line 649:
>
>> 647: // s
On Thu, 5 May 2022 12:08:54 GMT, Johannes Bechberger
wrote:
>> I would like to disagree: The abbreviation "ASGCT" is used in multiple
>> places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found).
>
> I found "AGCT" only in a method named
> "Java_MyPackage_ASGCTBaseTest_checkA
On Thu, 5 May 2022 12:13:18 GMT, Jaroslav Bachorik
wrote:
>> A gist of the fix is to allow relaxed special handling of code blob lookup
>> when done for ASGCT.
>>
>> Currently, a guarantee will fail when we happen to hit a zombie method which
>> is still on stack. While this would indicate a
On Thu, 5 May 2022 12:07:10 GMT, Johannes Bechberger
wrote:
>> src/hotspot/share/runtime/thread.hpp line 647:
>>
>>> 645: #endif // __APPLE__ && AARCH64
>>> 646:
>>> 647: // support ASGCT
>>
>> Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT
>
> I would like to disagree: The ab
On Thu, 5 May 2022 11:59:16 GMT, David Holmes wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make sure the code blob result check is correct
>
> src/hotspot/share/runtime/thread.hpp line 647:
>
>> 645: #endi
> A gist of the fix is to allow relaxed special handling of code blob lookup
> when done for ASGCT.
>
> Currently, a guarantee will fail when we happen to hit a zombie method which
> is still on stack. While this would indicate a serious error for the normal
> execution flow, in case of ASGCT
On Thu, 5 May 2022 11:51:47 GMT, Jaroslav Bachorik
wrote:
>> A gist of the fix is to allow relaxed special handling of code blob lookup
>> when done for ASGCT.
>>
>> Currently, a guarantee will fail when we happen to hit a zombie method which
>> is still on stack. While this would indicate a
> A gist of the fix is to allow relaxed special handling of code blob lookup
> when done for ASGCT.
>
> Currently, a guarantee will fail when we happen to hit a zombie method which
> is still on stack. While this would indicate a serious error for the normal
> execution flow, in case of ASGCT
On Thu, 5 May 2022 11:28:14 GMT, Jaroslav Bachorik
wrote:
> A gist of the fix is to allow relaxed special handling of code blob lookup
> when done for ASGCT.
>
> Currently, a guarantee will fail when we happen to hit a zombie method which
> is still on stack. While this would indicate a seri
A gist of the fix is to allow relaxed special handling of code blob lookup when
done for ASGCT.
Currently, a guarantee will fail when we happen to hit a zombie method which is
still on stack. While this would indicate a serious error for the normal
execution flow, in case of ASGCT being in pro
On Thu, 5 May 2022 10:29:07 GMT, Johannes Bechberger
wrote:
>> Calling JavaThread::thread_from_jni_environment for a terminated thread in
>> AsyncGetCallTrace might cause the acquisition of a lock, making
>> AsyncGetCallTrace non-signal-safe.
>>
>> AsyncGetCallTrace can only be called for th
> Calling JavaThread::thread_from_jni_environment for a terminated thread in
> AsyncGetCallTrace might cause the acquisition of a lock, making
> AsyncGetCallTrace non-signal-safe.
>
> AsyncGetCallTrace can only be called for the current threads (there are
> asserts for that), therefore using J
On Wed, 4 May 2022 16:02:36 GMT, Aleksey Shipilev wrote:
> So, does this PR pass current GHA checks? I see they are not enabled for this
> PR. It would be unfortunate for this large integration to break builds/tests
> for smaller PRs that would follow it.
I've enabled it on my fork and we'll s
On Tue, 3 May 2022 08:02:57 GMT, Johannes Bechberger
wrote:
>> Calling JavaThread::thread_from_jni_environment for a terminated thread in
>> AsyncGetCallTrace might cause the acquisition of a lock, making
>> AsyncGetCallTrace non-signal-safe.
>>
>> AsyncGetCallTrace can only be called for th
> 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.
>
>
30 matches
Mail list logo
