On Fri, 17 May 2024 04:34:22 GMT, Kim Barrett wrote:
> So JDK-8324680 was somewhat mistaken about what needed to be done, and what
was done.
The `jvmti.xml` is used to generate several things with the XSL scripts:
- JVMTI spec (`jvm.html`)
- JVMTI api (`jvmti.h`)
- `jvmtiEnter.cpp`,
his update is to make it clear that `nullptr` is C programming language
> `null` pointer.
>
> I think we do not need a CSR for this fix.
>
> Testing: N/A (not needed)
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revisi
On Thu, 16 May 2024 07:59:51 GMT, Kim Barrett wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: corrected the nullptr clarification
>
> src/hotspot/share/prims/j
On Thu, 16 May 2024 19:26:07 GMT, Chris Plummer wrote:
>> src/hotspot/share/prims/jvmti.xml line 1008:
>>
>>> 1006: function descriptions. Empty lists, arrays, sequences, etc are
>>> 1007: returned as nullptr which is C programming language
>>> 1008: null pointer.
>>
>> Shouldn't
The following RFE was fixed recently:
[8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with
nullptr in JVMTI generated code
It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents
can be developed in C or C++.
This update is to make it clear that
On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin wrote:
> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has
> [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
>
On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls wrote:
> Running JConsole from a previous JDK, and attaching to jdk-23 (after
> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
> Management Extension (JMX) Subject Delegation feature), the MBean tab is
> blank.
>
> In
On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads
On Wed, 15 May 2024 20:09:52 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1535:
>>
>>> 1533: bool is_virtual =
>>> java_lang_VirtualThread::is_instance(thread_oop);
>>> 1534: if (is_virtual) {
>>> 1
pport for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note:
> degrade virtual thread support for GetObjectMonitorUsage
>
> Testing:
> - tested impacted and updated tests locally
> - tested with mach5 tiers 1-6
Serguei Spitsyn
pport for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note:
> degrade virtual thread support for GetObjectMonitorUsage
>
> Testing:
> - tested impacted and updated tests locally
> - tested with mach5 tiers 1-6
Serguei Spitsyn has up
On Wed, 15 May 2024 19:52:36 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test
>> c
On Wed, 15 May 2024 19:51:51 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: 1. clarifications in JDWP and JDI spec; 2. clarifications in test
>> c
pport for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note:
> degrade virtual thread support for GetObjectMonitorUsage
>
> Testing:
> - tested impacted and updated tests locally
> - tested with mach5 tiers 1-6
Serguei Spitsyn h
On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which removes the
> `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg
> launches these tests through a virtual thread?
>
> These tests aren't actually incompatible with
On Fri, 10 May 2024 22:09:01 GMT, Daniel D. Daugherty
wrote:
> Perhaps this is not what Chris had in mind, but I'm wondering what happens in
> some
> Thread-A when it is checked and passed by but then Thread-A sets the flag in
> itself
> after the for-loop has passed it by. Does that Thread-A
pport for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note:
> degrade virtual thread support for GetObjectMonitorUsage
>
> Testing:
> - tested impacted and updated tests locally
> - tested with mach5 tiers 1-6
Serguei Spits
On Wed, 1 May 2024 20:45:58 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: tweaks in JVMTI and JDWP changes
>
> src/jdk.jdi/share/classes/com/sun/jdi
On Thu, 2 May 2024 21:50:26 GMT, Chris Plummer wrote:
>> src/java.se/share/data/jdwp/jdwp.spec line 1622:
>>
>>> 1620: (threadObject owner "The platform thread owning this
>>> monitor, or nullptr "
>>> 1621: "if owned` by a virtual thread or not
>>>
On Tue, 14 May 2024 23:13:28 GMT, Serguei Spitsyn wrote:
>> I don't understand the issue with the updated commented. It is precisely
>> telling you what the expected "count" values should be. If you leave the
>> macros in the comment, then the comment is wrong
On Tue, 14 May 2024 17:51:03 GMT, Chris Plummer wrote:
>>> expEnteringCount/expWaitingCount contain the tested patterns.
>>
>> I kind of disagree.
>> Please, take look at the loop below:
>>
>> for (int i = 0; i < NUMBER_OF_WAITING_THREADS; i++) {
>> expEnteringCount
On Wed, 8 May 2024 17:05:30 GMT, Kevin Walls wrote:
> Remove from zgc problemlists.
> Trivial fix.
>
> This was omitted when https://bugs.openjdk.org/browse/JDK-8303136 was
> integrated.
>
> I see the tests passing, including with ZGC. Just ran my own batch of tests
> in addition, and it
On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn wrote:
> Any event posting code except CFLH, ClassPrepare and ClassLoad events has a
> conditional return in case if the event is posted during a VTMS transition.
> The CFLH, ClassPrepare and ClassLoad event posting code has just
On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn wrote:
> Any event posting code except CFLH, ClassPrepare and ClassLoad events has a
> conditional return in case if the event is posted during a VTMS transition.
> The CFLH, ClassPrepare and ClassLoad event posting code has just
On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn wrote:
> Any event posting code except CFLH, ClassPrepare and ClassLoad events has a
> conditional return in case if the event is posted during a VTMS transition.
> The CFLH, ClassPrepare and ClassLoad event posting code has just
On Thu, 9 May 2024 01:00:52 GMT, Chris Plummer wrote:
>> Okay, thanks. Please, let me list the variants with some analysis.
>> We have 3 variants:
>> 1. Both monitors are leaf: Entering any monitor while a leaf monitor has
>> been entered is a violation (`LEAF RULE` violation). The order does
On Wed, 8 May 2024 22:41:45 GMT, Chris Plummer wrote:
>> I just wanted to say that Alex's suggestion is in a similar direction.
>> I do not see a big advantage to save just on creation of a few monitors. It
>> is not a scalability problem as their number is constant. Creation of the
>>
On Wed, 8 May 2024 22:53:06 GMT, Chris Plummer wrote:
>> Okay, thanks.
>>> Then you have both a rank order violation and a violation for entering a
>>> leaf monitor when you have already entered a leaf monitor.
>>
>> I kind of disagree with the second part of this statement.
>> My
On Wed, 8 May 2024 22:10:29 GMT, Chris Plummer wrote:
>> In fact, I do not understand why reporting the "rank order" violation is
>> important what "leaf rank order" is violated. I feel that I'm missing
>> something. Let me think on it a little bit.
>
> If the following are all true
> - you
On Wed, 8 May 2024 20:34:01 GMT, Chris Plummer wrote:
>>> The special popFrame check needs to go in the first loop only, so it
>>> shouldn't be a problem or add any complexity that we don't already have.
>>
>> Sounds good.
>>
>>> One things to resolve is if we enter a regular monitor while
On Wed, 8 May 2024 19:09:18 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1117:
>>
>>> 1115: jrawMonitorID monitor;
>>> 1116: const char* name;
>>> 1117: DebugRawMonitorRank rank;
>>
>> Nit: Please, consider to add same comment for lines
On Wed, 8 May 2024 19:22:31 GMT, Chris Plummer wrote:
> The special popFrame check needs to go in the first loop only, so it
> shouldn't be a problem or add any complexity that we don't already have.
Sounds good.
> One things to resolve is if we enter a regular monitor while holding a leaf
>
On Wed, 8 May 2024 18:27:15 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 66:
>>
>>> 64: debugLoop_initialize(void)
>>> 65: {
>>> 66: vmDeathLock = debugMonitorCreate(vmDeathLockForDebugLoop_Rank,
>>> "JDWP VM_DEATH Lock");
>>
>> Nit: Just a
On Tue, 7 May 2024 18:53:23 GMT, Chris Plummer wrote:
>> This PR adds ranked monitor support to the debug agent. The debug agent has
>> a large number of monitors, and it's really hard to know which order to grab
>> them in, and for that matter which monitors might already be held at any
>>
On Tue, 7 May 2024 18:54:37 GMT, Chris Plummer wrote:
> What do you think about the terminology usage of "rank".
I slightly prefer to have the same rank order as Hotspot uses.
At the same time, I'm not sure if it won't cause any issues/difficulties. But
I'd give it a try.
-
PR
On Thu, 2 May 2024 03:57:25 GMT, Jaikiran Pai wrote:
>> Can I please get a review of these test-only changes which proposes to
>> remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from
>> `ProblemList-Virtual.txt`?
On Wed, 8 May 2024 01:19:05 GMT, SendaoYan wrote:
>> Hi,
>> GHA
>> [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136)
>> shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent
>> fail on macos-aarch64. The testcase has been problemlisted
On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer wrote:
>> This PR adds ranked monitor support to the debug agent. The debug agent has
>> a large number of monitors, and it's really hard to know which order to grab
>> them in, and for that matter which monitors might already be held at any
>>
On Mon, 6 May 2024 21:22:05 GMT, Chris Plummer wrote:
>> This PR adds ranked monitor support to the debug agent. The debug agent has
>> a large number of monitors, and it's really hard to know which order to grab
>> them in, and for that matter which monitors might already be held at any
>>
On Mon, 6 May 2024 21:31:02 GMT, Chris Plummer wrote:
>> I originally started at `rank`, but then when I added the 2nd of the two
>> checks below I switched to 0, but your min suggestion should be optimal.
>
> Fixed.
I was about to post a similar comment but found it has been already fixed in
On Wed, 1 May 2024 14:14:22 GMT, SendaoYan wrote:
> Hi,
> GHA
> [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136)
> shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail
> on macos-aarch64. The testcase has been problemlisted on
>
On Fri, 3 May 2024 01:54:24 GMT, Alex Menkov wrote:
>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>>
>> Testing: tier1-6
>
> Alex Menkov has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - update
> - Revert
On Wed, 17 Apr 2024 20:19:49 GMT, Leonid Mesnik wrote:
> The jdwp tests use debugger and debugee. There is no goal to execute debugger
> part with all VM flags, they are needed to be used with debugee VM only.
> The change is all tests is to don't use System.exit() and use 'driver'
> instead
On Mon, 22 Apr 2024 11:21:15 GMT, Andrey Turbanov wrote:
>> The jdwp tests use debugger and debugee. There is no goal to execute
>> debugger part with all VM flags, they are needed to be used with debugee VM
>> only.
>> The change is all tests is to don't use System.exit() and use 'driver'
>>
On Thu, 2 May 2024 10:07:35 GMT, Serguei Spitsyn wrote:
> Any event posting code except CFLH, ClassPrepare and ClassLoad events has a
> conditional return in case if the event is posted during a VTMS transition.
> The CFLH, ClassPrepare and ClassLoad event posting code has just
pport for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note:
> degrade virtual thread support for GetObjectMonitorUsage
>
> Testing:
> - tested impacted and updated tests locally
> - tested with mach5 tiers 1-6
Serguei Spitsyn ha
On Thu, 2 May 2024 21:47:50 GMT, Chris Plummer wrote:
>> expEnteringCount/expWaitingCount contain the tested patterns. I don't see
>> why they can't just replace
>> NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in the comments also.
>> In fact it is confusing if you don't because code
On Fri, 3 May 2024 06:40:07 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmti.xml line 8280:
>>
>>> 8278:
>>> 8279: The number of platform threads waiting to own this
>>> monitor, or 0
>>> 8280: if only virtual threads are waiting or no threads are
On Fri, 3 May 2024 06:49:09 GMT, Alan Bateman wrote:
> It seems maybe we should instead be trying to avoid these events by
> preloading the classes as was suggested as an option in the CR.
The problem is that all such cases are unknown, so it is just not realistic. As
Alan commented, this
On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads
Any event posting code except CFLH, ClassPrepare and ClassLoad events has a
conditional return in case if the event is posted during a VTMS transition. The
CFLH, ClassPrepare and ClassLoad event posting code has just an assert instead.
The ClassPrepare and ClassLoad events also have a
pport for GetObjectMonitorUsage
> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note:
> degrade virtual thread support for GetObjectMonitorUsage
>
> Testing:
> - tested impacted and updated tests locally
> - tested with mach5 tiers 1-6
Serguei Sp
On Wed, 1 May 2024 21:01:16 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
On Wed, 1 May 2024 21:11:36 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
On Thu, 2 May 2024 02:49:35 GMT, David Holmes wrote:
>> You can drop "the" from "with the JTREG_TEST_THREAD_FACTORY=Virtual"
>
> And drop "the" from "the GetObjectMonitorUsage".
Thank you. Updated.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587137513
On Thu, 2 May 2024 02:47:19 GMT, David Holmes wrote:
>> Okay, thanks.
>
> Second suggestion is better. "waited by" is not grammatically correct in this
> context.
Thank you, David.
So, the latest version is:
The number of platform threads waiting to own this monitor, or
0
On Wed, 1 May 2024 23:16:09 GMT, Chris Plummer wrote:
>> Good suggestion, thanks. But it is more "incorrect". It should say "is
>> waited by" instead of "is owned by":
>>
>>The number of platform threads waiting to own this monitor, or
>> 0
>>if is waited by virtual
On Wed, 1 May 2024 20:40:35 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
On Wed, 1 May 2024 21:03:31 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
On Wed, 1 May 2024 20:30:54 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
On Wed, 1 May 2024 20:21:28 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
On Wed, 1 May 2024 20:21:25 GMT, Chris Plummer wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the both
The fix is to degrade virtual threads support in the JVM TI
`GetObjectMonitorUsage` function so that it is specified to only return an
owner when the owner is a platform thread. Also, virtual threads are not listed
in the both `waiters` and `notify_waiters` lists returned in the
On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn wrote:
> This is a fix of the following JVMTI scalability issue. A closed benchmark
> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
> been loaded. For instance, this is observable when an app is execu
On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app
On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov wrote:
> The fix updates HeapMerger to use writer buffer (no need to copy memory, also
> writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of
> `size_t` is a typo, the argument should
On Wed, 17 Apr 2024 20:42:54 GMT, Alex Menkov wrote:
>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the
>> fix affects `HotSpotDiagnosticMXBean.dumpHeap()`,
>> `-XX:+HeapDumpBeforeFullGC`,
On Fri, 26 Apr 2024 22:59:43 GMT, Alex Menkov wrote:
> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>
> Testing: tier1-6
This looks good in general. Thank you for taking care about it. The Runtime
team suggested to use the name `current` for the current thread.
On Sat, 27 Apr 2024 00:01:16 GMT, Alex Menkov wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1976:
>>
>>> 1974: oop thread_obj = nullptr;
>>> 1975:
>>> 1976: jvmtiError err =
>>> JvmtiEnvBase::get_threadOop_and_JavaThread(tlh.list(), target, current,
>>> _thread, _obj);
>>
>> I
ect` utility.
> For performance analysis, experiments and numbers, please, see the comment
> below this description.
>
> The fix is to replace the global counter `_VTMS_transition_count` with the
> mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>
> Testing:
> - Tested with
On Fri, 26 Apr 2024 19:34:55 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: fixed minor issues: renamed function, corrected comment, removed
>> typo i
On Fri, 26 Apr 2024 19:38:40 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: fixed minor issues: renamed function, corrected comment, removed
>> typo i
ect` utility.
> For performance analysis, experiments and numbers, please, see the comment
> below this description.
>
> The fix is to replace the global counter `_VTMS_transition_count` with the
> mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>
> Testing:
> - Tested with
On Thu, 25 Apr 2024 20:39:03 GMT, Alex Menkov wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app is executed under
>>
On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn wrote:
> This is a fix of the following JVMTI scalability issue. A closed benchmark
> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
> been loaded. For instance, this is observable when an app is execu
This is a fix of the following JVMTI scalability issue. A closed benchmark with
millions of virtual threads shows 4X overhead when a JVMTI agent has been
loaded. For instance, this is observable when an app is executed under control
of the Oracle Studio `collect` utility.
The benchmark takes a
On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn wrote:
> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of
> `_target_jt->vthread()`.
> The `_target_jt->vthread()` can be outdated in some specific contexts as
&
On Wed, 24 Apr 2024 05:44:42 GMT, Chris Plummer wrote:
>> 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/rebase. The pull request contai
gt; `_target_jt->jvmti_vthread()`.
>
> There are three places which need to be fixed the same way:
> - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
> - `SetForceEarlyReturn::do_vthread(Handle target_h)`
> - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
>
> Testi
On Mon, 15 Apr 2024 06:47:24 GMT, Serguei Spitsyn wrote:
> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait`
> event but has not released the `lockCheck` monitor yet. It has been fixed to
> wait for each `WaitingTask` thread to really reach the `WAITI
On Wed, 24 Apr 2024 00:01:45 GMT, Serguei Spitsyn wrote:
>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait`
>> event but has not released the `lockCheck` monitor yet. It has been fixed to
>> wait for each `WaitingTask` thread to really reach t
gt; `_target_jt->jvmti_vthread()`.
>
> There are three places which need to be fixed the same way:
> - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
> - `SetForceEarlyReturn::do_vthread(Handle target_h)`
> - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
>
&
gt; `_target_jt->jvmti_vthread()`.
>
> There are three places which need to be fixed the same way:
> - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
> - `SetForceEarlyReturn::do_vthread(Handle target_h)`
> - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
>
> Testi
On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn wrote:
> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of
> `_target_jt->vthread()`.
> The `_target_jt->vthread()` can be outdated in some specific contexts as
&
It has been fixed to wait
> for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>
> Testing:
> - Reran the test
> `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
> - TBD: submit the mach5 tiers 1-6 as well
Serguei Spitsy
On Tue, 23 Apr 2024 19:05:38 GMT, Patricio Chilano Mateo
wrote:
>> This is a simple fix of three similar asserts.
>> The `_target_jt->jvmti_vthread()` has to be used instead of
>> `_target_jt->vthread()`.
>> The `_target_jt->vthread()` can be outdated in some specific contexts as
>> shown in
On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn wrote:
> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of
> `_target_jt->vthread()`.
> The `_target_jt->vthread()` can be outdated in some specific contexts as
&
On Tue, 23 Apr 2024 20:47:34 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: tweak in wait_for_state func to allow exp_state bit mask
>
> test/hots
On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn wrote:
> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of
> `_target_jt->vthread()`.
> The `_target_jt->vthread()` can be outdated in some specific contexts as
&
On Thu, 18 Apr 2024 21:56:09 GMT, Serguei Spitsyn wrote:
>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait`
>> event but has not released the `lockCheck` monitor yet. It has been fixed to
>> wait for each `WaitingTask` thread to really reach t
It has been fixed to wait
> for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>
> Testing:
> - Reran the test
> `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
> - TBD: submit the mach5 tiers 1-6 as well
Serguei Spitsy
This is a simple fix of three similar asserts.
The `_target_jt->jvmti_vthread()` has to be used instead of
`_target_jt->vthread()`.
The `_target_jt->vthread()` can be outdated in some specific contexts as shown
in the `hs_err` stack trace.
I've seen similar issue and already fixed it in this
On Tue, 16 Apr 2024 21:55:54 GMT, Serguei Spitsyn wrote:
>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait`
>> event but has not released the `lockCheck` monitor yet. It has been fixed to
>> wait for each `WaitingTask` thread to really reach t
It has been fixed to wait
> for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>
> Testing:
> - Reran the test
> `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
> - TBD: submit the mach5 tiers 1-6 as well
Serguei Spitsy
On Tue, 16 Apr 2024 19:21:16 GMT, Leonid Mesnik wrote:
> The fix looks good, just one nit. rml.wait(100); might be changed to plain
> sleep(100)
Right, thanks. Will fix it.
-
PR Comment: https://git.openjdk.org/jdk/pull/18778#issuecomment-2059950982
It has been fixed to wait
> for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>
> Testing:
> - Reran the test
> `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
> - TBD: submit the mach5 tiers 1-6 as well
Serguei Spitsy
On Mon, 15 Apr 2024 21:34:48 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: removed event_lock; moved wait_for_state() to jvmti_common.hpp
>
> test/hots
This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event
but has not released the `lockCheck` monitor yet. It has been fixed to wait for
each `WaitingTask` thread to really reach the `WAITING` state. The same
approach is used for `EnteringTask` threads. It has been fixed
On Thu, 4 Apr 2024 15:28:41 GMT, Serguei Spitsyn wrote:
> 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
&
iEnvThreadState::reset_current_location on the base of JvmtiHandshake and
> JvmtiUnitedHandshakeClosure classes.
>
> Testing:
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
review
1 - 100 of 1524 matches
Mail list logo
