On Thu, 24 Nov 2022 10:59:41 GMT, Martin Doerr wrote:
> Related issue is fixed with
> [JDK-8228649](https://bugs.openjdk.org/browse/JDK-8228649)
> Test has passed.
Lgtm
-
Marked as reviewed by rrich (Reviewer).
PR: https://git.openjdk.org/jdk/pull/11351
On Tue, 14 Feb 2023 07:38:21 GMT, Johannes Bechberger wrote:
>> The test fails without this relaxation and the relaxation has been used on
>> PPC to solve a similar issue a few years back.
>
> The original assumption does not always hold anymore and should therefore
> relaxed.
I think `unexten
On Wed, 15 Feb 2023 20:38:04 GMT, Johannes Bechberger wrote:
>>> I think `unextended_sp < sp` is possible on x86 when interpreter entries
>>> generated by `MethodHandles::generate_method_handle_interpreter_entry()`
>>> are executed. They modify `sp` ([here for
>>> example](https://github.com/o
On Wed, 15 Feb 2023 21:12:19 GMT, Jorn Vernee wrote:
>>> I think your conclusion is correct wrt `unextended_sp < sp` in that case.
>>> For certain MH linker calls, an additional `MemberName` 'appendix' is
>>> passed as the last argument. The MH adapter/trampoline stub pops the
>>> appendix arg
On Wed, 15 Feb 2023 21:39:52 GMT, Jorn Vernee wrote:
> The entry generated by generate_method_handle_interpreter_entry is
> essentially the from_interpreted_entry, AFAIU.
But it is also stored in `Method::_i2i_entry` which is [used by c2i
adapters](https://github.com/openjdk/jdk/blob/3ba156082
On Thu, 16 Feb 2023 00:36:03 GMT, Jorn Vernee wrote:
> So... my understanding is that a c2i adapter is used when a callee is
> interpreted, so its `from_compiled_entry` points to the c2i adapter. A
> compiled caller calls the `from_compiled_entry`, so it ends up going through
> the `c2i` adapter
On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue by
>> modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Fri, 17 Feb 2023 14:47:56 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert previous change
src/hotspo
On Mon, 20 Feb 2023 09:04:39 GMT, Johannes Bechberger wrote:
>> The sanity test worked :)
>
> ... and no regression in the other serviceability tests.
Probably it's better to adapt the limit though (sorry).
Problem with this version is that it allows `unextended_sp` outside the address
range re
On Mon, 20 Feb 2023 09:18:46 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Improve condition again
Looks goo
On Tue, 7 Mar 2023 13:30:50 GMT, Coleen Phillimore wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>> metho
On Thu, 9 Mar 2023 16:01:21 GMT, Coleen Phillimore wrote:
>> This change should be in a further RFE though (and you can explain it there
>> so we can maybe use it in the other platforms too). Does it affect
>> performance when generating the template interpreter? Do you need to have
>> hsdis
On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Tue, 14 Mar 2023 13:18:40 GMT, Coleen Phillimore wrote:
> Ok, never mind, I saw s390 port but it doesn't seem to be in these changes (?)
It is not in these changes.
@offamitkumar is working on s390x. It is not yet finished though.
(I wasn't aware that putting the URL of this PR into a comment
On Tue, 14 Mar 2023 17:01:20 GMT, Matias Saavedra Silva
wrote:
> > @matias9927 can I ask you to merge master? There seem to be conflicts (at
> > least I see a message "This branch has conflicts that must be resolved").
> > I'd like to give the change a spin in our CI testing. This requires tha
On Wed, 15 Mar 2023 19:04:41 GMT, Martin Doerr wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
>
>> 3396: co
On Thu, 16 Mar 2023 09:21:26 GMT, Martin Doerr wrote:
>> Basically I kept the local variable as a name for the (now) constant value
>> passed in the call at L3409.
>>
>> The parameter cannot be eliminated since `load_invoke_cp_cache_entry()` is
>> declared in a shared header.
>>
>> I could re
On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Tue, 21 Mar 2023 10:49:32 GMT, Andrew Haley wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix riscv interpreter mistake and acquire semantics
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line
On Tue, 28 Mar 2023 16:33:09 GMT, Martin Doerr wrote:
>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
>>
>>> 650: // Scale the index to be the entry index *
>>> sizeof(ResolvedInvokeDynamicInfo)
>>> 651: __ sldi(size, size, log2i_exact(sizeof(ResolvedIndyEntry)));
With `StressReflectiveCode` C2 has inexact type information which can prevent ea
based optimizations (see `ConnectionGraph::add_call_node()`)
This pr changes the test jdk/com/sun/jdi/EATests.java to read the flag
`StressReflectiveCode`. If enabled it shall neither expect ea based
optimizations
of
On Wed, 19 Oct 2022 15:43:17 GMT, Richard Reingruber wrote:
> With `StressReflectiveCode` C2 has inexact type information which can prevent
> ea
> based optimizations (see `ConnectionGraph::add_call_node()`)
>
> This pr changes the test jdk/com/sun/jdi/EATests.java t
On Thu, 20 Oct 2022 19:52:39 GMT, Vladimir Kozlov wrote:
> Should we add check for `StressReflectiveCode` to all `shouldSkip()` methods
> too? Similar to `DeoptimizeObjectsALot` flag.
I'd be ok to skip all testcases (by checking for `StressReflectiveCode` in the
base classes' `shouldSkip()`).
VM_OPTS="-XX:+IgnoreUnrecognizedVMOptions -XX:+StressReflectiveCode"
Richard Reingruber has updated the pull request incrementally with one
additional commit since the last revision:
Skip all test cases if StressReflectiveCode is enabled
-
Changes:
- all: https://git.openjdk.org/jdk/pul
On Thu, 20 Oct 2022 20:55:12 GMT, Richard Reingruber wrote:
>> With `StressReflectiveCode` C2 has inexact type information which can
>> prevent ea
>> based optimizations (see `ConnectionGraph::add_call_node()`)
>>
>> This pr changes the test jdk/com/sun/jdi
On Wed, 19 Oct 2022 15:43:17 GMT, Richard Reingruber wrote:
> With `StressReflectiveCode` C2 has inexact type information which can prevent
> ea
> based optimizations (see `ConnectionGraph::add_call_node()`)
>
> This pr changes the test jdk/com/sun/jdi/EATests.java t
On Mon, 14 Nov 2022 16:07:34 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs h
On Thu, 17 Nov 2022 09:23:48 GMT, Erik Österlund wrote:
>> src/hotspot/share/gc/shared/barrierSetStackChunk.cpp line 68:
>>
>>> 66:
>>> 67: virtual void do_oop(oop* p) override {
>>> 68: if (UseCompressedOops) {
>>
>> Wouldn't it be better to hoist the check for `UseCompressedOops`?
>
>
On Thu, 17 Nov 2022 09:24:04 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs h
On Sun, 20 Nov 2022 08:48:16 GMT, Serguei Spitsyn wrote:
>> The can_support_virtual_thread was initially implemented as an onload
>> capability.
>> It is why this capability does not work for the agents loaded into running
>> VM.
>> The fix is to move it from `onload` to `always`capabilities li
On Mon, 21 Nov 2022 19:08:16 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 201:
>>
>>> 199: JvmtiVirtualThreadEventMark(JavaThread *thread) :
>>> 200: JvmtiEventMark(thread) {
>>> 201: if (thread->vthread() != NULL) {
>>
>> Can this condition ever be fals
On Tue, 22 Nov 2022 05:57:37 GMT, Serguei Spitsyn wrote:
>> The can_support_virtual_thread was initially implemented as an onload
>> capability.
>> It is why this capability does not work for the agents loaded into running
>> VM.
>> The fix is to move it from `onload` to `always`capabilities li
On Wed, 8 Nov 2023 19:00:53 GMT, Roman Kennke wrote:
> See JBS issue for details.
>
> I basically:
> - took the test-modification and turned it into its own test-case
> - added test runners for lightweight- and legacy-locking, so that we keep
> testing both, no matter what is the default
> -
On Thu, 9 Nov 2023 15:54:13 GMT, Roman Kennke wrote:
>> See JBS issue for details.
>>
>> I basically:
>> - took the test-modification and turned it into its own test-case
>> - added test runners for lightweight- and legacy-locking, so that we keep
>> testing both, no matter what is the defaul
This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled`
to switch to `WXWrite` before transitioning to the vm.
Testing:
make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
make test TEST=compiler/intrinsics/klass/CastNullCheck
On Wed, 13 Mar 2024 09:49:19 GMT, David Holmes wrote:
> As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?
(I wanted to publish the PR before answering your comment)
This would be reasonable in my opinion.
I've hoisted setting `WXWrite` mode in `JfrJvmtiAgent::retransform_c
On Wed, 13 Mar 2024 12:19:34 GMT, David Holmes wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=-XX:+A
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled`
> to switch to `WXWrite` before transitioning to the vm.
>
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>
On Thu, 14 Mar 2024 14:49:12 GMT, Matthias Baesken wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=-X
T=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
> TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>
> More tests are pending.
Richard Reingruber has updated the pull request incrementally with one
additional commit since the last revision:
Set WXWrite at more locations
On Fri, 15 Mar 2024 13:58:15 GMT, Tobias Holenstein
wrote:
> > As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?
>
> I agree. This is something I am investigating at the moment. Ideally,
> AssertWXAtThreadSync would also be true by default.
I've added a bunch more locati
T=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
> TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>
> More tests are pending.
Richard Reingruber has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
broug
On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes wrote:
> But all this discussion suggests to me that this PR is not really worth
> pursuing at this time - IIUC no actual failures are observed other than those
> pertaining to AssertWXAtThreadSync and that flag will be gone if we do decide
> to b
On Tue, 19 Mar 2024 17:46:31 GMT, Tobias Holenstein
wrote:
>> I've asked this myself (after making the change).
>> Being in `WXWrite` mode would be wrong if the thread would execute
>> dynamically generated code. There's not too much happening outside the scope
>> of the `ThreadInVMfromNative`
T=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
> TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>
> More tests are pending.
Richard Reingruber has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
broug
On Wed, 20 Mar 2024 14:06:04 GMT, Richard Reingruber wrote:
>> Updated (2024-03-20):
>>
>> This PR adds switching to `WXWrite` mode before entering the vm where it is
>> missing.
>>
>> With the changes the following jtreg tests succeed with AssertWXAtThre
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> Updated (2024-03-20):
>
> This PR adds switching to `WXWrite` mode before entering the vm where it is
> missing.
>
> With the changes the following jtreg tests succeed with AssertWXAtThreadSync
> enabled.
&g
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote:
> An alternative for preemptively switching the W^X thread mode on macOS with
> an AArch64 CPU. This implementation triggers the switch in response to the
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
> approa
On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - r
On Sat, 26 Oct 2024 01:42:17 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interruptible check from conditional in Objec
On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interruptible check from conditional in Objec
On Sat, 26 Oct 2024 01:54:26 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interruptible check from conditional in Objec
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes hav
On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the
On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes have been sp
On Sat, 12 Jul 2025 06:10:31 GMT, Richard Reingruber wrote:
> This pr makes sure to call System.gc() before each test in
> UnmountedVThreadNativeMethodAtTop.java
>
> The intention is to get rid of unreachable objects representing loaded heap
> dumps from previous tests.
>
On Sat, 12 Jul 2025 06:10:31 GMT, Richard Reingruber wrote:
> This pr makes sure to call System.gc() before each test in
> UnmountedVThreadNativeMethodAtTop.java
>
> The intention is to get rid of unreachable objects representing loaded heap
> dumps from previous tests.
>
On Wed, 16 Jul 2025 06:24:16 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25.
>
>
> Test-
This pr makes sure to call System.gc() before each test in
UnmountedVThreadNativeMethodAtTop.java
The intention is to get rid of unreachable objects representing loaded heap
dumps from previous tests.
This prevents OutOfMemoryErrors. Parsing the smaller dumps is faster too.
The PR also include
verifyHeapDump(dumpFile) throws an exception. It also wraps the wait into a
loop to protect against spurious wake up.
The commit being backported was authored by Richard Reingruber on 12 Jul 2025
and was reviewed by Chris Plummer, Christoph Langer and David Holmes.
Testing was done with fastdebug and
On Thu, 3 Jul 2025 08:36:53 GMT, Alan Bateman wrote:
> It might be that it could be updated to work with debug or -Xcomp too,
> execution times would need to be checked out.
I found that the runtime of each test is ~300ms with a release build and ~11s
with a fastdebug build on x86_64 and ppc64
This pull request contains a backport of commit
[fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Richard Reingruber on 7 Jul 2025
and was
On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote:
>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java
>> to force inlining of java/lang/String*.* methods. This will make inlining
>> more stable to allow for the expected lock elimination
On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote:
> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java
> to force inlining of java/lang/String*.* methods. This will make inlining
> more stable to allow for the expected lock elimination based on
On Fri, 4 Jul 2025 08:11:12 GMT, Richard Reingruber wrote:
> I've removed the `!vm.debug` requirement. I'll await our local testing of the
> pr on a wider range of platforms.
Local testing was good.
-
PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043828120
On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote:
>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java
>> to force inlining of java/lang/String*.* methods. This will make inlining
>> more stable to allow for the expected lock elimination
> This pr moves the `notify()` call to the finally block to avoid the deadlock
> in `join()` if `verifyHeapDump(dumpFile)` throws an exception.
>
> Testing was done with fastdebug and release builds on the main platforms and
> also on Linux/PPC64le and AIX.
Richard Reingruber
This pr moves the `notify()` call to the finally block to avoid the deadlock in
`join()` if `verifyHeapDump(dumpFile)` throws an exception.
Testing was done with fastdebug and release builds on the main platforms and
also on Linux/PPC64le and AIX.
-
Commit messages:
- Notify in fi
On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber wrote:
> This pull request contains a backport of commit
> [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> T
On Thu, 10 Jul 2025 08:16:10 GMT, David Holmes wrote:
> That fixes the observed problem, but I find the existing test logic somewhat
> awkward. You only need a finally block to ensure something happens if an
> exception occurred - but here if you get an exception why do we care about
> joining
> This pr moves the `notify()` call to the finally block to avoid the deadlock
> in `join()` if `verifyHeapDump(dumpFile)` throws an exception.
>
> Testing was done with fastdebug and release builds on the main platforms and
> also on Linux/PPC64le and AIX.
Richard Reingruber
> This pr moves the `notify()` call to the finally block to avoid the deadlock
> in `join()` if `verifyHeapDump(dumpFile)` throws an exception.
>
> Testing was done with fastdebug and release builds on the main platforms and
> also on Linux/PPC64le and AIX.
Richard Reingruber
On Thu, 10 Jul 2025 21:01:32 GMT, Chris Plummer wrote:
> With your fix in place, I assume now if verifyHeapDump() throws an exception
> the test will still fail, but in a more timely and meaningful manner.
Yes, that's the intention.
> Why is verifyHeapDump() throwing an exception in the first
On Fri, 11 Jul 2025 08:30:57 GMT, Richard Reingruber wrote:
>> This pr moves the `notify()` call to the finally block to avoid the deadlock
>> in `join()` if `verifyHeapDump(dumpFile)` throws an exception.
>>
>> Testing was done with fastdebug and release builds o
On Wed, 9 Jul 2025 07:39:05 GMT, Richard Reingruber wrote:
> This pr moves the `notify()` call to the finally block to avoid the deadlock
> in `join()` if `verifyHeapDump(dumpFile)` throws an exception.
>
> Testing was done with fastdebug and release builds on the main platforms an
to a big method
> @ 30
> java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3
On Thu, 3 Jul 2025 17:57:27 GMT, Alan Bateman wrote:
> > I found that the runtime of each test is ~300ms with a release build and
> > ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove
> > the requirement within this pr and do some more testing. -Xcomp doesn't
> > seem t
This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to
force inlining of java/lang/String*.* methods. This will make inlining more
stable to allow for the expected lock elimination based on c2 escape analysis.
Forcing inlining of java/lang/StringBuffer.* wasn't sufficient
On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote:
> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java
> to force inlining of java/lang/String*.* methods. This will make inlining
> more stable to allow for the expected lock elimination based on
On Sat, 12 Jul 2025 08:27:19 GMT, Richard Reingruber wrote:
> This pull request contains a backport of commit
> [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> It m
On Sat, 12 Jul 2025 08:27:19 GMT, Richard Reingruber wrote:
> This pull request contains a backport of commit
> [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> It m
On Thu, 17 Jul 2025 08:04:50 GMT, Richard Reingruber wrote:
>> test/hotspot/jtreg/serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java
>> line 59:
>>
>>> 57: @BeforeEach
>>> 58: void doGC() {
>>> 59: System.gc();
>
On Wed, 16 Jul 2025 18:00:50 GMT, Leonid Mesnik wrote:
> The Systen.gc() might not trigger full GC.
Indeed. Might be better to use the Whitebox or start a dedicated VM.
> While not tjust o restrict heap for this test? 256M should be enough.
This would not help. The tests accumulate heap dumps
On Thu, 17 Jul 2025 08:21:56 GMT, Richard Reingruber wrote:
>>> The Systen.gc() might not trigger full GC.
>>
>> Indeed. Might be better to use the Whitebox or start a dedicated VM.
>>
>>> While not tjust o restrict heap for this test? 256M should be eno
Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC.
It is assumed that one full GC is sufficient for these tests.
Testing was done with fastdebug and release builds on the main platforms and
also on Linux/PPC64le and AIX.
-
Commit messages:
- Merge branch 'mast
On Thu, 17 Jul 2025 11:48:15 GMT, SendaoYan wrote:
>> Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC.
>> It is assumed that one full GC is sufficient for these tests.
>>
>> Testing was done with fastdebug and release builds on the main platforms and
>> also on Linux/PPC
On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote:
> Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC.
> It is assumed that one full GC is sufficient for these tests.
>
> Testing was done with fastdebug and release builds on the main platforms an
On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote:
> Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC.
> It is assumed that one full GC is sufficient for these tests.
>
> Testing was done with fastdebug and release builds on the main platforms an
92 matches
Mail list logo
