Many tests depend on this VM option and are being removed. I'm not sure if
> it is okay to completely remove those e may want another way to handle this
> (e.g. problem-listing the impacted tests for now).
>
> Testing:
> - mach5 tiers 1-6 are good
> - may need to run ma
The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a
temporary backward compatibility flag under JDK-8192936 and was immediately
marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in
JDK 27.
There are two concerns which may require some negoti
On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updat
On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has upda
On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has upda
On Thu, 12 Dec 2024 09:08:28 GMT, SendaoYan wrote:
> Hi all,
> Trivial fix to problemlist
> vmTestbase/vm/mlvm/indy/func/jvmti/mergeCP_indy2manySame_a/TestDescription.java
> in virtual thread mode to make less test noisy, it's supplement for PR
> https://github.com/openjdk/jdk/pull/21417
Good
On Fri, 13 Dec 2024 23:07:53 GMT, Alex Menkov wrote:
>> In some circumstances ClassFileTransformer.transform can get
>> ClassCircularityError or LinkageError concatenating strings (see
>> JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> Th
On Thu, 7 Nov 2024 19:15:50 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
On Thu, 7 Nov 2024 00:38:57 GMT, Patricio Chilano Mateo
wrote:
>>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in
>>> JvmtiUnmountBeginMark
>>>
>> Why is not needed? I guess you meant to say we should use
>> `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()`
On Thu, 7 Nov 2024 00:40:26 GMT, Patricio Chilano Mateo
wrote:
>>> So at some point I think we need to figure out how to make them go away ...
>>
>> Yes, the 2 extension events (`VirtualThreadMount` and
>> `VirtualThreadUnmount`) were added for testing purposes. We wanted to get
>> rid of th
On Thu, 7 Nov 2024 00:38:18 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
On Thu, 7 Nov 2024 00:38:18 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
On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote:
> So at some point I think we need to figure out how to make them go away ...
Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`)
were added for testing purposes. We wanted to get rid of them at some point but
the
On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo
wrote:
>> Yes, I see your idea to get rid of the pending unmount event code. Before
>> commenting on that, note that we still need to check if the freeze failed to
>> undo the transition, which would call for this RAII object that we curr
On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuation.cpp line 88:
>>
>>> 86: if (_target->has_async_exception_condition()) {
>>> 87: _failed = true;
>>> 88: }
>>
>> Q: I wonder why the failed conditions are not checked be
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 Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo
wrote:
>> Yes, I see your idea to get rid of the pending unmount event code. Before
>> commenting on that, note that we still need to check if the freeze failed to
>> undo the transition, which would call for this RAII object that we curr
On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote:
> So at some point I think we need to figure out how to make them go away ...
Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`)
were added for testing purposes. We wanted to get rid of them at some point but
the
On Tue, 5 Nov 2024 01:40:15 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
On Mon, 4 Nov 2024 18:18:23 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
On Fri, 1 Nov 2024 19:37:14 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
On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuation.cpp line 88:
>>
>>> 86: if (_target->has_async_exception_condition()) {
>>> 87: _failed = true;
>>> 88: }
>>
>> Q: I wonder why the failed conditions are not checked be
On Wed, 30 Oct 2024 00:44:14 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 08:34:14 GMT, Alan Bateman wrote:
> This is an update to the Virtual thread implementation that we'd like to
> integrate in advance of JEP 491.
>
> The update removes the use of "temporary transitions", basically cases where
> the thread identity switches to the carrier th
On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn wrote:
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHidden
On Tue, 29 Oct 2024 08:35:27 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
On Tue, 29 Oct 2024 06:45:30 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: tweak description of the annotation class JvmtiHideEvents
>
> src/java.base
On Tue, 29 Oct 2024 00:04:09 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 Wed, 23 Oct 2024 07:24:05 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 11 commits:
>>
>> - Merge
>> - review: explain better what
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
On Mon, 28 Oct 2024 05:56:20 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove newly added trailing space
>
> src/java.base/share/classes/jdk/internal/vm/a
On Sat, 26 Oct 2024 06:40:00 GMT, Serguei Spitsyn wrote:
>> Good catch, thanks.
>> These two functions are impacted by temporary VTMS transitions. It seems we
>> fail to hide frames in these transitions while we skip the JVMTI events in
>> their context. I'll t
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
On Sat, 26 Oct 2024 06:34:08 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 667:
>>
>>> 665:
>>> 666: javaVFrame*
>>> 667: JvmtiEnvBase::check_and_skip_hidden_frames(bool is_in_VTMS_transition,
>>> javaVFrame* j
On Thu, 24 Oct 2024 22:58:01 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: removed asserts from continuationFreezeThaw.cpp again
>
> src/hotspot/share/p
On Sat, 26 Oct 2024 05:13:08 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java
>> line 38:
>>
>>> 36: *
>>> 37: * @implNote
>>> 38: * This annotation is only used for the VirtualThread notifyJvmti*
>>> methods.
>>
>> What about Vi
On Sat, 26 Oct 2024 00:43:00 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: introduce new annotation @JvmtiHideEvents and use it in
>> VirtualThread/Co
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
On Tue, 15 Oct 2024 21:26:26 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.r
On Thu, 17 Oct 2024 09:16:31 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
On Tue, 15 Oct 2024 21:59:41 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:
>>
>>> 690: if (jt->is_in_VTMS_transition()) {
>>> 691: jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(),
>>> jvf);
On Wed, 16 Oct 2024 14:38:13 GMT, Alan Bateman wrote:
>> Thank you for the comment. I can move the try-finally to the method
>> `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it
>> will play the same role functionally.
>
> Changing the run method to
>
> vthread.notify
On Wed, 16 Oct 2024 08:00:12 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuati
On Tue, 15 Oct 2024 21:21:07 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.r
On Wed, 16 Oct 2024 14:50:43 GMT, Alan Bateman wrote:
>> The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting
>> and finishing in a VTMS transition. The issue is with the JVMTI
>> `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests
>> to its fra
On Wed, 16 Oct 2024 08:00:48 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuati
On Wed, 16 Oct 2024 08:05:20 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuati
On Tue, 15 Oct 2024 21:26:55 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.r
On Tue, 15 Oct 2024 20:55:54 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.r
On Tue, 15 Oct 2024 20:40:50 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.r
On Tue, 15 Oct 2024 20:45:46 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.r
On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn
On Tue, 8 Oct 2024 00:11:12 GMT, Leonid Mesnik wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - Mach
On Mon, 7 Oct 2024 23:43:23 GMT, Leonid Mesnik wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - Mach
On Mon, 7 Oct 2024 22:41:06 GMT, Leonid Mesnik wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - Mach
On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn wrote:
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHidden
This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames
hiding mechanism.
Please, see a fix description in the first comment.
Testing:
- Verified with new test `vthread/CheckHiddenFrames`
- Mach5 tiers 1-6 are passed
-
Commit messages:
- fix one more place
On Fri, 19 Jul 2024 16:59:54 GMT, Alan Bateman wrote:
>> Bringover some of the changes accumulated in the loom repo to the main line,
>> most of these changes are test updates and have been baking in the loom repo
>> for several months. The motive is partly to reduce the large set of changes
>
On Thu, 18 Jul 2024 11:18:08 GMT, Alan Bateman wrote:
> I will check but there are a few renames that have to keep the initial year.
> Also there are some new files that have been checked into the loom repo for a
> long time so they have their initial year too.
Okay, thanks.
>> test/jdk/java/
On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote:
> Bringover some of the changes accumulated in the loom repo to the main line,
> most of these changes are test updates and have been baking in the loom repo
> for several months. The motive is partly to reduce the large set of changes
> th
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
> Maybe
On Tue, 16 Jul 2024 05:58:18 GMT, David Holmes wrote:
>> Bringover some of the changes accumulated in the loom repo to the main line,
>> most of these changes are test updates and have been baking in the loom repo
>> for several months. The motive is partly to reduce the large set of changes
>
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same fix
On Thu, 30 May 2024 02:28:56 GMT, Leonid Mesnik wrote:
> The message is generated if cores (or any other tools) section doesn't exist
> or is empty. However, there is no any tool for cores processing now defined.
> So ERROR message is generating, confusing users.
> The fix is to don't print err
On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFilePars
On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFilePars
On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote:
>> Please help review this trivial fix for resolving `ld: error: duplicate
>> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
>> thanks.
>
> Jiangli Zhou has updated the pull request incrementally with two additi
On Wed, 21 Feb 2024 21:42:08 GMT, Alex Menkov wrote:
>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with
>> AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from
>> HotSpotVirtualMachine.processCompletionStatus (called from
>> Ho
The implementation of the JVM TI `GetCurrentContendedMonitor` does not match
the spec. It can sometimes return an incorrect information about the contended
monitor. Such a behavior does not match the function spec.
With this update the `GetCurrentContendedMonitor` is returning the monitor only
On Mon, 8 Jan 2024 07:55:45 GMT, Serguei Spitsyn wrote:
> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
> static.
> The method disables/enables suspend of the current virtual thread, a no-op if
> the current thread is a platform thread. It is confusing
On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn wrote:
>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
>> static.
>> The method disables/enables suspend of the current virtual thread, a no-op
>> if the current thread is a platform thr
On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn wrote:
>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
>> static.
>> The method disables/enables suspend of the current virtual thread, a no-op
>> if the current thread is a platform thr
needs to use the
> argument #0 instead of #1.
>
> Testing:
> - The mach5 tiers 1-6 show no regressions
Serguei Spitsyn has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/reba
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Mon, 8 Jan 2024 09:04:57 GMT, Alan Bateman wrote:
>> In preparation for when virtual threads can unmount while holding a monitor
>> or unmount when blocking on monitorenter, the implementation of
>> VirtualThread's interrupt method is refactored to avoid parking/blocking
>> while holding th
The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
static.
The method disables/enables suspend of the current virtual thread, a no-op if
the current thread is a platform thread. It is confusing for this to be an
instance method, it should be static to make it clearer tha
Hi all,
This pull request contains a backport of commit
[0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and
was
On Wed, 20 Dec 2023 14:15:48 GMT, Alan Bateman wrote:
> Update: ignore this I mis-read that it updates the current thread's suspend
> value, not the thread's suspend value.
Thanks, Alan. I've also got confused with this and even filed a follow up bug.
:)
Yes, the initial design was the `_is_di
On Wed, 20 Dec 2023 08:02:14 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvm.cpp line 4024:
>>
>>> 4022: #else
>>> 4023: fatal("Should only be called with JVMTI enabled");
>>> 4024: #endif
>>
>> You can't do this! The Java code knows nothing about JVM TI being
>> enabled/disabled and
On Thu, 7 Dec 2023 06:28:43 GMT, Serguei Spitsyn wrote:
> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
> time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections
> with the `interruptLock` (in methods: `unpark()`
On Fri, 15 Dec 2023 10:49:56 GMT, Serguei Spitsyn wrote:
>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
>> time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical
>> sections with the `interruptLock` (in methods
viceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vt
On Fri, 15 Dec 2023 08:57:45 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: moved a couple of comments out of try blocks
>
> src/hotspot/share/prims
viceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vt
On Thu, 14 Dec 2023 22:35:18 GMT, Serguei Spitsyn wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 1043:
>>
>>> 1041: notifyJvmtiDisableSuspend(true);
>>> 1042: try {
>>> 1043: // include
viceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vt
1 - 100 of 207 matches
Mail list logo
