Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]

2022-05-05 Thread Alan Bateman
> 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. > >

Re: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v4]

2022-05-05 Thread Martin Doerr
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

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]

2022-05-05 Thread Alan Bateman
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

Re: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v5]

2022-05-05 Thread Johannes Bechberger
> 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

Re: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v5]

2022-05-05 Thread Jaroslav Bachorik
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

RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee

2022-05-05 Thread Jaroslav Bachorik
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee

2022-05-05 Thread Johannes Bechberger
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Jaroslav Bachorik
> 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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread David Holmes
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

2022-05-05 Thread Jaroslav Bachorik
> 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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Johannes Bechberger
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Johannes Bechberger
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

2022-05-05 Thread David Holmes
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread David Holmes
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Jaroslav Bachorik
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

2022-05-05 Thread Jaroslav Bachorik
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:

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]

2022-05-05 Thread Jaroslav Bachorik
> 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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Jaroslav Bachorik
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Johannes Bechberger
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 >>

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread Jaroslav Bachorik
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

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]

2022-05-05 Thread Sean Coffey
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]

2022-05-05 Thread Daniel D . Daugherty
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

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]

2022-05-05 Thread Joe Darcy
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

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]

2022-05-05 Thread Aleksey Shipilev
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

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]

2022-05-05 Thread Alan Bateman
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

Integrated: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing

2022-05-05 Thread Alex Menkov
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

Re: RFR: 8279358: vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java fails with usage tracker [v2]

2022-05-05 Thread Alex Menkov
> 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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

2022-05-05 Thread David Holmes
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

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

2022-05-05 Thread David Holmes
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

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]

2022-05-05 Thread Alan Bateman
> 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. > >