Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v6]

2023-06-08 Thread Serguei Spitsyn
On Thu, 8 Jun 2023 01:42:10 GMT, Serguei Spitsyn wrote: >> This is REDO the fix of >> [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). >> The last update of the fix in the review cycle was incorrect and incorrectly >> tested, so the issue has not been noticed. It is why the fix was b

Integrated: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING

2023-06-08 Thread Serguei Spitsyn
On Wed, 7 Jun 2023 18:42:34 GMT, Serguei Spitsyn wrote: > This is REDO the fix of > [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). > The last update of the fix in the review cycle was incorrect and incorrectly > tested, so the issue has not been noticed. It is why the fix was backe

Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]

2023-06-08 Thread Serguei Spitsyn
On Thu, 8 Jun 2023 06:25:20 GMT, Alan Bateman wrote: >> It was decided with Alan that it is okay to be in a waiting state. The >> `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` state requires a monitor to be >> blocked on, so it can be confusing. Alan's comment in the original PR >> [https://gi

Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

2023-06-08 Thread Serguei Spitsyn
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote: > HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will > not enforce checking line number derived from uncommon trap debug info. > However, Graal does not set this property explicitly. Looks good. Is JVMCI used by the G

Re: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v8]

2023-06-08 Thread Serguei Spitsyn
On Thu, 8 Jun 2023 19:05:54 GMT, Doug Simon wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> update copyright comments > > src/hotspot/share/runtime/sharedRuntime.cpp line 641: > >> 639: JRT_ENTRY(void, SharedRu

RFR: 8309673: Refactor ref_at methods in Serviceability ConstantPool

2023-06-08 Thread Matias Saavedra Silva
The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability code. Verified with tier 1-5 tests. - Commit messages: - 8309

Re: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"

2023-06-08 Thread Kevin Walls
On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer wrote: > The test waits for a ThreadDeathEvent for "main". Once that arrives, it then > waits for the next ThreadStartEvent (for any thread). Once it arrives, the > test tries to create and enable a StepRequest on the "main" thread. Since > "main"

Re: RFR: 8309271: A way to align already compiled methods with compiler directives

2023-06-08 Thread Paul Hohensee
On Wed, 24 May 2023 00:38:27 GMT, Dmitry Chuyko wrote: > Compiler Control (https://openjdk.org/jeps/165) provides method-context > dependent control of the JVM compilers (C1 and C2). The active directive > stack is built from the directive files passed with the > `-XX:CompilerDirectivesFile` d

Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

2023-06-08 Thread Doug Simon
On Thu, 8 Jun 2023 18:29:50 GMT, Yudi Zheng wrote: >> test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java >> line 257: >> >>> 255: >>> 256: checkLines = !(enableJVMCI.getValue().equals("true") >>> 257: && useJVMCICompiler.getValue().equals("true")); >

Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

2023-06-08 Thread Doug Simon
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote: > HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will > not enforce checking line number derived from uncommon trap debug info. > However, Graal does not set this property explicitly. Marked as reviewed by dnsimon (Com

Re: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v8]

2023-06-08 Thread Doug Simon
On Tue, 2 May 2023 02:01:44 GMT, Serguei Spitsyn wrote: >> This refactoring to separate ThreadStart/ThreadEnd events posting code in >> the JVMTI VTMS transitions is needed for future work on JVMTI scalability >> and performance improvements. It is to easier put this code on slow path. >> >> T

Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

2023-06-08 Thread Yudi Zheng
On Thu, 8 Jun 2023 17:19:46 GMT, Doug Simon wrote: >> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will >> not enforce checking line number derived from uncommon trap debug info. >> However, Graal does not set this property explicitly. > > test/hotspot/jtreg/serviceab

Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v6]

2023-06-08 Thread Alex Menkov
On Thu, 8 Jun 2023 01:42:10 GMT, Serguei Spitsyn wrote: >> This is REDO the fix of >> [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). >> The last update of the fix in the review cycle was incorrect and incorrectly >> tested, so the issue has not been noticed. It is why the fix was b

Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

2023-06-08 Thread Doug Simon
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote: > HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will > not enforce checking line number derived from uncommon trap debug info. > However, Graal does not set this property explicitly. test/hotspot/jtreg/serviceability/

RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

2023-06-08 Thread Yudi Zheng
HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly. - Commit messages: - Avoid using jvmci.Compiler property to determine if Graal

Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v17]

2023-06-08 Thread Andrew Haley
On Wed, 7 Jun 2023 21:03:47 GMT, Kelvin Nilsen wrote: > We would like to thank everyone who has taken time to review and provide > feedback on our pull request. Given the risks identified during the review > process and the lack of time available to perform the thorough review that > such a la

Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]

2023-06-08 Thread Julian Waters
On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use >> the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request incrementally with four additional > commits since th