Integrated: 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling
On Wed, 27 Mar 2024 01:02:41 GMT, Andrei Pangin wrote: > This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe. > Reentrancy is required in the cases when two or more profiling engines are > running at the same time, e.g., when CPU and Wall clock profilers work > together and therefore one profiler may interrupt another in the middle of > getting a stack trace. > > Tested with async-profiler: > > java > -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr This pull request has now been integrated. Changeset: 6b1b0e9d Author:Andrei Pangin Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/6b1b0e9d45eb56f88398e2a6bca0d90c03112eaa Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling Reviewed-by: dholmes, sspitsyn - PR: https://git.openjdk.org/jdk/pull/18504
Re: RFR: JDK-8322042: HeapDumper should perform merge on the current thread instead of VMThread
On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov wrote: > The fix updated HeapDumper to always perform merge on the current thread. > > Testing: tier1-5, all HeapDump-related tests > Covered heap dumping scenarios: > - `jcmd GC.heap_dump` command; > - `HotSpotDiagnosticMXBean.dumpHeap()`; > - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options; > - `HeapDumpOnOutOfMemoryError` VM option. - jcmd GC.heap_dump command; `AttachListenerThread` - HotSpotDiagnosticMXBean.dumpHeap(); `JavaThread` - HeapDumpBeforeFullGC, HeapDumpAfterFullGC VM options; `VMThread` - HeapDumpOnOutOfMemoryError VM option. `VMThread` Mabye we can always use AttachListenerThread(via Handshake) or new virtual thread? - PR Review: https://git.openjdk.org/jdk/pull/18571#pullrequestreview-1972484174
Re: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling [v2]
On Fri, 29 Mar 2024 11:35:57 GMT, Andrei Pangin wrote: >> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe. >> Reentrancy is required in the cases when two or more profiling engines are >> running at the same time, e.g., when CPU and Wall clock profilers work >> together and therefore one profiler may interrupt another in the middle of >> getting a stack trace. >> >> Tested with async-profiler: >> >> java >> -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr > > Andrei Pangin has updated the pull request incrementally with one additional > commit since the last revision: > > Rephrased comment about AsyncGetCallTrace reentrancy Marked as reviewed by dholmes (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18504#pullrequestreview-1972482922
Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v11]
On Wed, 27 Mar 2024 18:31:50 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is not a
>> general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Test more pointer types: compiled method and metadata.
src/hotspot/share/services/diagnosticCommand.cpp line 1254:
> 1252: DebuggingContext dc{}; // avoid asserts
> 1253:
> 1254: if (!UnlockDiagnosticVMOptions) {
Drive-by comment: As per the comment from @plummercj this flag should not be
hijacked for this purpose. If you need a VM flag to control this feature then
please add one. Thanks.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1547032078
Integrated: 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the test > failure reported in https://bugs.openjdk.org/browse/JDK-8328273? > > As noted in that issue, the > `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently > fails with a port already in use error. The test attempts to find a free port > and then uses it during the test. The interesting part is that the test > already has a loop of 10 attempts to retry the test if the port wasn't > actually free. So for the test to fail, it would then mean that each of the > 10 attempts of using a free port failed (which should be extremely rare and > should almost never happen). > > I didn't have an answer for that until today and had it on my TODO to look > further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns > out this is the exact same issue that Kevin fixed in > https://github.com/openjdk/jdk/pull/18470 for a different test. After > noticing that fix, I spotted the same typo in the exception message check in > this test. That explains why it wasn't retrying at most 10 times. The test > was thus immediately failing on first attempt whenever the chosen free port > was in use. > > I have run this test with a test repeat of 50 with this change and the test > now passes always. Without this change and a test repeat of 50, the test > failed 2 times. I've additionally searched for any other similar typos in > other tests and haven't found any (I searched for the string "Exception > thrown by the agent :"). This pull request has now been integrated. Changeset: a85c8493 Author:Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a85c8493aec73e81c000ea3e3d983b05706bbfec Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use Reviewed-by: dcubed - PR: https://git.openjdk.org/jdk/pull/18561
Re: RFR: 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the test > failure reported in https://bugs.openjdk.org/browse/JDK-8328273? > > As noted in that issue, the > `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently > fails with a port already in use error. The test attempts to find a free port > and then uses it during the test. The interesting part is that the test > already has a loop of 10 attempts to retry the test if the port wasn't > actually free. So for the test to fail, it would then mean that each of the > 10 attempts of using a free port failed (which should be extremely rare and > should almost never happen). > > I didn't have an answer for that until today and had it on my TODO to look > further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns > out this is the exact same issue that Kevin fixed in > https://github.com/openjdk/jdk/pull/18470 for a different test. After > noticing that fix, I spotted the same typo in the exception message check in > this test. That explains why it wasn't retrying at most 10 times. The test > was thus immediately failing on first attempt whenever the chosen free port > was in use. > > I have run this test with a test repeat of 50 with this change and the test > now passes always. Without this change and a test repeat of 50, the test > failed 2 times. I've additionally searched for any other similar typos in > other tests and haven't found any (I searched for the string "Exception > thrown by the agent :"). Thank you Dan for the review. Since this is a test-only trivial fix, I'll go ahead with the integration. - PR Comment: https://git.openjdk.org/jdk/pull/18561#issuecomment-2030898184
Re: RFR: JDK-8322042: HeapDumper should perform merge on the current thread instead of VMThread
On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov wrote: > The fix updated HeapDumper to always perform merge on the current thread. > > Testing: tier1-5, all HeapDump-related tests > Covered heap dumping scenarios: > - `jcmd GC.heap_dump` command; > - `HotSpotDiagnosticMXBean.dumpHeap()`; > - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options; > - `HeapDumpOnOutOfMemoryError` VM option. added serviceability label - PR Comment: https://git.openjdk.org/jdk/pull/18571#issuecomment-2030892178
RFR: 8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake
The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes. Testing: Ran mach5 tiers 1-6 - Commit messages: - 8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake Changes: https://git.openjdk.org/jdk/pull/18570/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18570=00 Issue: https://bugs.openjdk.org/browse/JDK-8329432 Stats: 41 lines in 3 files changed: 13 ins; 20 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/18570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18570/head:pull/18570 PR: https://git.openjdk.org/jdk/pull/18570
Integrated: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout
On Thu, 21 Mar 2024 07:11:33 GMT, Serguei Spitsyn wrote: > This PR fixes a synchronization issue in the test: > `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` > > The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it > has not reached an expected breakpoint yet. > The fix is to add a call to the method `ensureAtBreakpoint()` one more time > in the `B2` sub-test. It is needed after the top-most frame was popped with > the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint > again after its execution was resumed. > > The time is very intermittent. At least, I was not able to reproduce the > timeout failure in thousands of mach5 runs with the `-Xcomp` option. > > Testing: > - Run the test > `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands > times in mach5 This pull request has now been integrated. Changeset: 70c8ff1c Author:Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/70c8ff1c9a9adf21a16d8a6b4da1eeec65afe61d Stats: 17 lines in 1 file changed: 9 ins; 2 del; 6 mod 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout Reviewed-by: lmesnik, cjplummer - PR: https://git.openjdk.org/jdk/pull/18419
Re: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
On Fri, 29 Mar 2024 15:25:48 GMT, Coleen Phillimore wrote: > This change simplifies the code that grows the jmethodID cache in > InstanceKlass. Instead of lazily, when there's a rare request for a > jmethodID for an obsolete method, the jmethodID cache is grown during the > RedefineClasses safepoint. The InstanceKlass's jmethodID cache is lazily > allocated when there's a jmethodID allocated, so not every InstanceKlass has > a cache, but the growth now only happens in a safepoint. This code will > become racy with the potential change for deallocating jmethodIDs. > > Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case > they're not in tier1-4). Looks like good simplification - Marked as reviewed by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1972336247
Integrated: 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64
On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList noisy tests: > > [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList > containers/docker/TestJFREvents.java on linux-x64 > [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList > vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java > with Xcomp on windows-x64 > [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList > javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 > [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList > vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp This pull request has now been integrated. Changeset: c2979c15 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/c2979c150bdbcc2a9e6026347dc590e6a7e86595 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64 8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64 8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp Reviewed-by: dholmes - PR: https://git.openjdk.org/jdk/pull/18568
Re: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64
On Mon, 1 Apr 2024 22:15:06 GMT, David Holmes wrote: >> Trivial fixes to ProblemList noisy tests: >> >> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList >> containers/docker/TestJFREvents.java on linux-x64 >> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList >> vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java >> with Xcomp on windows-x64 >> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList >> javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 >> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList >> vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp > > Seems okay. Thanks @dholmes-ora - Thanks for the lightning fast review! - PR Comment: https://git.openjdk.org/jdk/pull/18568#issuecomment-2030672631
Re: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64
On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList noisy tests: > > [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList > containers/docker/TestJFREvents.java on linux-x64 > [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList > vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java > with Xcomp on windows-x64 > [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList > javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 > [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList > vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp Seems okay. Thanks - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18568#pullrequestreview-1972236395
RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64
Trivial fixes to ProblemList noisy tests: [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64 [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64 [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp - Commit messages: - 8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp - 8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 - 8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64 - 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64 Changes: https://git.openjdk.org/jdk/pull/18568/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18568=00 Issue: https://bugs.openjdk.org/browse/JDK-8329425 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18568/head:pull/18568 PR: https://git.openjdk.org/jdk/pull/18568
Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes [v2]
On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov wrote: >> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE >> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) >> which was used for AOT [JEP 295](https://openjdk.org/jeps/295) >> implementation in JDK 9. The code was left in HotSpot assuming it will help >> in a future. But during work on Leyden we decided to not use it. In Leyden >> cached compiled code will be restored in CodeCache as normal nmethods: no >> need to change VM's runtime and GC code to process them. >> >> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce >> header size in separate changes. In these changes I did simple fields >> reordering to keep small (1 byte) fields together. >> >> I do not see (and not expected) performance difference with these changes. >> >> Tested tier1-5, xcomp, stress. Running performance testing. >> >> I need help with testing on platforms which Oracle does not support. > > Vladimir Kozlov has updated the pull request incrementally with one > additional commit since the last revision: > > Removed not_used state of nmethod I did not change `src/hotspot/share/code//codeHeapState.cpp` code which counts nmethods with `not_used` state by checking `(!nm->is_not_entrant()` after `(nm->is_in_use())`. Removing `not_used` does not affect it. The code is complicated and needs separate RFE if we decide to clean it. - PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030560338
Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes [v2]
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE > [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) > which was used for AOT [JEP 295](https://openjdk.org/jeps/295) > implementation in JDK 9. The code was left in HotSpot assuming it will help > in a future. But during work on Leyden we decided to not use it. In Leyden > cached compiled code will be restored in CodeCache as normal nmethods: no > need to change VM's runtime and GC code to process them. > > I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce > header size in separate changes. In these changes I did simple fields > reordering to keep small (1 byte) fields together. > > I do not see (and not expected) performance difference with these changes. > > Tested tier1-5, xcomp, stress. Running performance testing. > > I need help with testing on platforms which Oracle does not support. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Removed not_used state of nmethod - Changes: - all: https://git.openjdk.org/jdk/pull/18554/files - new: https://git.openjdk.org/jdk/pull/18554/files/7635b333..246ff68a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18554=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18554=00-01 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18554.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18554/head:pull/18554 PR: https://git.openjdk.org/jdk/pull/18554
Re: RFR: 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the test > failure reported in https://bugs.openjdk.org/browse/JDK-8328273? > > As noted in that issue, the > `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently > fails with a port already in use error. The test attempts to find a free port > and then uses it during the test. The interesting part is that the test > already has a loop of 10 attempts to retry the test if the port wasn't > actually free. So for the test to fail, it would then mean that each of the > 10 attempts of using a free port failed (which should be extremely rare and > should almost never happen). > > I didn't have an answer for that until today and had it on my TODO to look > further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns > out this is the exact same issue that Kevin fixed in > https://github.com/openjdk/jdk/pull/18470 for a different test. After > noticing that fix, I spotted the same typo in the exception message check in > this test. That explains why it wasn't retrying at most 10 times. The test > was thus immediately failing on first attempt whenever the chosen free port > was in use. > > I have run this test with a test repeat of 50 with this change and the test > now passes always. Without this change and a test repeat of 50, the test > failed 2 times. I've additionally searched for any other similar typos in > other tests and haven't found any (I searched for the string "Exception > thrown by the agent :"). Thumbs up. This is a trivial fix. @jaikiran - Thanks for fixing this bug!! - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18561#pullrequestreview-1972108656
Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
On Mon, 1 Apr 2024 18:15:43 GMT, Dean Long wrote: > The `not_used` state was introduced for AOT. It can go away now. Good catch, Dean. I want to keep `nmethod::make_not_used()` method because we use it in Leyden to keep AOT code (outside of CodeCache): [nmethod.hpp#L476](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/nmethod.hpp#L476) It does not use this flag value. - PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030448462
Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v7]
On Mon, 1 Apr 2024 11:29:58 GMT, Serguei Spitsyn wrote: >> This PR fixes a synchronization issue in the test: >> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` >> >> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it >> has not reached an expected breakpoint yet. >> The fix is to add a call to the method `ensureAtBreakpoint()` one more time >> in the `B2` sub-test. It is needed after the top-most frame was popped with >> the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint >> again after its execution was resumed. >> >> The time is very intermittent. At least, I was not able to reproduce the >> timeout failure in thousands of mach5 runs with the `-Xcomp` option. >> >> Testing: >> - Run the test >> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands >> times in mach5 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: adjusted trap timeout and fixed a typo in comment Thank you for review, Chris. - PR Comment: https://git.openjdk.org/jdk/pull/18419#issuecomment-2030434649
Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
On Mon, 1 Apr 2024 00:19:32 GMT, Fei Yang wrote: >> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE >> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) >> which was used for AOT [JEP 295](https://openjdk.org/jeps/295) >> implementation in JDK 9. The code was left in HotSpot assuming it will help >> in a future. But during work on Leyden we decided to not use it. In Leyden >> cached compiled code will be restored in CodeCache as normal nmethods: no >> need to change VM's runtime and GC code to process them. >> >> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce >> header size in separate changes. In these changes I did simple fields >> reordering to keep small (1 byte) fields together. >> >> I do not see (and not expected) performance difference with these changes. >> >> Tested tier1-5, xcomp, stress. Running performance testing. >> >> I need help with testing on platforms which Oracle does not support. > > Hi, I also performed some tests (tier1-3 and hotspot:tier4) on linux-riscv64 > platform. Result looks good. @RealFYang and @offamitkumar thank you for testing. - PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030425253
Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov wrote: > Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE > [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) > which was used for AOT [JEP 295](https://openjdk.org/jeps/295) > implementation in JDK 9. The code was left in HotSpot assuming it will help > in a future. But during work on Leyden we decided to not use it. In Leyden > cached compiled code will be restored in CodeCache as normal nmethods: no > need to change VM's runtime and GC code to process them. > > I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce > header size in separate changes. In these changes I did simple fields > reordering to keep small (1 byte) fields together. > > I do not see (and not expected) performance difference with these changes. > > Tested tier1-5, xcomp, stress. Running performance testing. > > I need help with testing on platforms which Oracle does not support. The `not_used` state was introduced for AOT. It can go away now. - PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030282409
Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v7]
On Mon, 1 Apr 2024 11:29:58 GMT, Serguei Spitsyn wrote: >> This PR fixes a synchronization issue in the test: >> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` >> >> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it >> has not reached an expected breakpoint yet. >> The fix is to add a call to the method `ensureAtBreakpoint()` one more time >> in the `B2` sub-test. It is needed after the top-most frame was popped with >> the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint >> again after its execution was resumed. >> >> The time is very intermittent. At least, I was not able to reproduce the >> timeout failure in thousands of mach5 runs with the `-Xcomp` option. >> >> Testing: >> - Run the test >> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands >> times in mach5 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: adjusted trap timeout and fixed a typo in comment Marked as reviewed by cjplummer (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18419#pullrequestreview-1971806536
RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
This change simplifies the code that grows the jmethodID cache in InstanceKlass. Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint. The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint. This code will become racy with the potential change for deallocating jmethodIDs. Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4). - Commit messages: - Add Safepoint assert, don't use order accessors because they're not needed. - 8313332: Simplify lazy jmethodID cache in InstanceKlass Changes: https://git.openjdk.org/jdk/pull/18549/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18549=00 Issue: https://bugs.openjdk.org/browse/JDK-8313332 Stats: 222 lines in 7 files changed: 41 ins; 144 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/18549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18549/head:pull/18549 PR: https://git.openjdk.org/jdk/pull/18549
Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov wrote:
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
> implementation in JDK 9. The code was left in HotSpot assuming it will help
> in a future. But during work on Leyden we decided to not use it. In Leyden
> cached compiled code will be restored in CodeCache as normal nmethods: no
> need to change VM's runtime and GC code to process them.
>
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce
> header size in separate changes. In these changes I did simple fields
> reordering to keep small (1 byte) fields together.
>
> I do not see (and not expected) performance difference with these changes.
>
> Tested tier1-5, xcomp, stress. Running performance testing.
>
> I need help with testing on platforms which Oracle does not support.
I performed the build + testing `{fastdebug, release, slowdebug} X {tier1}` on
`s390x` and result looks fine.
-
PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2029655163
Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]
On Sat, 30 Mar 2024 01:32:27 GMT, Daniel D. Daugherty wrote: >> It wait for some increment of time upto a maximum of 100 seconds. > > I'm good with that. Thanks for clarifying. Thanks, Dan. I've decided to increase this timeout to 20 secs. Pushed now. - PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1546232711
Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v7]
> This PR fixes a synchronization issue in the test: > `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` > > The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it > has not reached an expected breakpoint yet. > The fix is to add a call to the method `ensureAtBreakpoint()` one more time > in the `B2` sub-test. It is needed after the top-most frame was popped with > the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint > again after its execution was resumed. > > The time is very intermittent. At least, I was not able to reproduce the > timeout failure in thousands of mach5 runs with the `-Xcomp` option. > > Testing: > - Run the test > `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands > times in mach5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: adjusted trap timeout and fixed a typo in comment - Changes: - all: https://git.openjdk.org/jdk/pull/18419/files - new: https://git.openjdk.org/jdk/pull/18419/files/f8344149..21c57eae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18419=06 - incr: https://webrevs.openjdk.org/?repo=jdk=18419=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18419/head:pull/18419 PR: https://git.openjdk.org/jdk/pull/18419
Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v6]
On Fri, 29 Mar 2024 20:45:14 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp
>> line 164:
>>
>>> 162: fatal(jni, "Main: ensureAtBreakpoint: waited 10 sec");
>>> 163: }
>>> 164: LOG("Main: ensureAtBreakpoint: waitig 100 millis\n");
>>
>> Suggestion:
>>
>> LOG("Main: ensureAtBreakpoint: waiting 100 millis\n");
>
> Thanks, Chris. Will fix it.
Fixed and pushed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1546232896
