On Tue, 11 Jun 2024 11:34:34 GMT, Serguei Spitsyn wrote:
> Please, review a jdk23 backport of the:
> [8333931](https://bugs.openjdk.org/browse/JDK-8333931): Problemlist
> serviceability/jvmti/vthread/CarrierThreadEventNotification
>
> Thanks
This pull request has now
On Tue, 11 Jun 2024 11:34:34 GMT, Serguei Spitsyn wrote:
> Please, review a jdk23 backport of the:
> [8333931](https://bugs.openjdk.org/browse/JDK-8333931): Problemlist
> serviceability/jvmti/vthread/CarrierThreadEventNotification
>
> Thanks
Thank you for review, Chris.
--
Please, review a jdk23 backport of the:
[8333931](https://bugs.openjdk.org/browse/JDK-8333931): Problemlist
serviceability/jvmti/vthread/CarrierThreadEventNotification
Thanks
-
Commit messages:
- Backport fe9c63cf73db7833646345e362cbda020ac403d1
Changes:
On Sat, 8 Jun 2024 17:00:04 GMT, Leonid Mesnik wrote:
> Tests
> SetFieldAccessWatch/setfldw001
> SetFieldModificationWatch/setfmodw001
> intermittently fail with Xcomp. I was unable to reproduce the problem.
> The fix adds more checks and variants with jvmti logging.
>
> The goal is to
On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote:
> Allow warning messages such as the following to appear in stderr:
>
> Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option
> UseNotificationThread; support is scheduled for removal in 24.0
>
> Tested by running CI
On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn wrote:
> 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`.
On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote:
> The fix updates com/sun/tools/attach/BasicTests.java to listen and connect
> using loopback addresses
>
> Testing: run the test on all Oracle-supported platforms
Looks good.
-
Marked as reviewed by sspitsyn (Reviewer).
PR
On Wed, 5 Jun 2024 23:57:02 GMT, Serguei Spitsyn wrote:
>> 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 gener
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 revision:
revi
On Wed, 5 Jun 2024 22:49:51 GMT, Chris Plummer wrote:
>> I'm still not sure this works. It seems kind of muddled. Rather than trying
>> to retrofit in the clarifying text, why not start from scratch. That should
>> result in better organization and clearer descriptions. For example, I think
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 with a new target base due to a
merge or a rebase. The pull request
On Tue, 28 May 2024 22:24:53 GMT, Serguei Spitsyn wrote:
> Please, review the following `interp-only` issue related to carrier threads.
> There are 3 problems fixed here:
> - The `EnterInterpOnlyModeClosure::do_threads` is taking the
> `JvmtiThreadState` with the `jt->jvm
On Mon, 3 Jun 2024 22:55:24 GMT, Serguei Spitsyn wrote:
>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>> - The `EnterInterpOnlyModeClosure::do_threads` is taking the
>> `JvmtiThreadState` with the
On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote:
> With ubsan enabled binaries we run into the following issue in HS :tier4
> tests :
> e.g.
> vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr
>
>
On Fri, 31 May 2024 15:12:39 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785)
>> replacing all naked uses for ```UseSharedSpaces``` with
>> ```CDSConfig::is_using_archive```.
>>
>> Testing:
>> - [x] Tier 1 with
On Wed, 5 Jun 2024 01:17:37 GMT, Jaikiran Pai wrote:
>> I think `timeout`s are not needed for the refactored tests.
>> Per JDK-6528548 the shell action has timed out using a network mounted JDK
>> (MakeJAR2.sh run `javac` 3 times and `jar` 1 time).
>> But I don't see big problem here - up to
On Tue, 4 Jun 2024 17:25:04 GMT, Leonid Mesnik wrote:
> The kill sends async exception that is thrown somewhere during
> log.display(...) method.
> The log shows that it is thrown while PrintStream locking moving it into an
> inconsistent state.
> So the fix is to use some method that could
On Tue, 4 Jun 2024 19:00:32 GMT, Chris Plummer wrote:
>> I think this is the right place but it is only for return values. There are
>> a few functions where a parameter value can be a null pointer, e.g. in
>> GetThreadState, SuspendThread, GetOwnedMonitorInfo the thread parameter can
>> be a
On Tue, 4 Jun 2024 21:05:40 GMT, Leonid Mesnik wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java line 153:
>>
>>> 151: }
>>> 152: }
>>> 153:
>>
>> Have you tried an empty method? I don't think it's a matter of how much time
>> you spend in the method, but
On Tue, 4 Jun 2024 08:54:40 GMT, Jaikiran Pai wrote:
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java line 34:
>>
>>> 32: * @modules java.management
>>> 33: * java.instrument
>>> 34: * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent
>>> NativeMethodPrefixApp
On Mon, 3 Jun 2024 23:02:28 GMT, Leonid Mesnik wrote:
>> The fix removes finalization cleanup from vmTestbase.
>> The last to classes that use it are: DebugeeBinder and SocketIOPipe.
>> The DebugeeBinder is used in jdi and jdwp tests and is always linked with
>> debuggee process. So the
On Tue, 4 Jun 2024 01:34:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which addresses
>> https://bugs.openjdk.org/browse/JDK-8333130?
>>
>> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp`
>> under `test/jdk/java/lang/instrument/`
On Mon, 3 Jun 2024 22:55:24 GMT, Serguei Spitsyn wrote:
>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>> - The `EnterInterpOnlyModeClosure::do_threads` is taking the
>> `JvmtiThreadState` with the
On Tue, 4 Jun 2024 04:48:04 GMT, David Holmes wrote:
>> src/hotspot/share/prims/jvmti.xml line 1007:
>>
>>> 1005: explicitly deallocate. This is indicated in the individual
>>>
>>> 1006: function descriptions. Empty lists, arrays, sequences, etc are
>>> 1007: returned as a null
On Fri, 17 May 2024 03:49:21 GMT, Quan Anh Mai 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 Fri, 31 May 2024 23:55:20 GMT, Serguei Spitsyn wrote:
>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>> - The `EnterInterpOnlyModeClosure::do_threads` is taking the
>> `JvmtiThreadState` with the
he virtual thread gets unmounted.
>
> The fix also includes new test case `vthread/CarrierThreadEventNotification`
> developed by Patricio.
>
> Testing:
> - Ran new test case locally
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally wi
On Sat, 1 Jun 2024 00:22:45 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: refactored def and use of process_pending_interp_only()
>
> test/hotspot/jtre
On Mon, 3 Jun 2024 08:01:25 GMT, David Holmes wrote:
> The general rules are to either say "a null pointer" (possibly with capital A
> depending on context), or just "null". And in most cases you could choose
> either. I made various suggestions but really it is up to you. It is hard to
> get
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 revision:
On Fri, 31 May 2024 21:04:41 GMT, Daniel D. Daugherty
wrote:
> Ping @sspitsyn - who handles JLI/JPLIS reviews for the Serviceability team?
Sorry for the latency. Will start reviewing it today. Also, I see Alex is
reviewing it.
-
PR Comment:
On Thu, 30 May 2024 18:59:10 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: addressed nits in new test
>
> src/hotspot/share/prims/jvmtiThrea
he virtual thread gets unmounted.
>
> The fix also includes new test case `vthread/CarrierThreadEventNotification`
> developed by Patricio.
>
> Testing:
> - Ran new test case locally
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally with
On Thu, 30 May 2024 06:36:09 GMT, SendaoYan wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> change from java_lang_VirtualThread::is_instance(thread_oop) to
>> hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in
On Fri, 31 May 2024 01:41:17 GMT, Serguei Spitsyn wrote:
>> 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 gener
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 revision:
r
On Fri, 17 May 2024 04:47:31 GMT, Alan Bateman wrote:
>> Thank you, Kim. I like this suggestion. Updated now.
>
> That part looks okay but I think all the parameters and error descriptions
> changed by JDK-8324680 will now need to change to use "null" instead of
> "nullptr".
Okay. I've made a
On Fri, 17 May 2024 04:34:22 GMT, Kim Barrett wrote:
> But this clarification doesn't actually clarify that the rest of the spec
> uses nullptr. Based on the proposed wording I would expect things like:
>
> The function may return nullptr
>
> to say
>
> The function may return a null pointer
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 revision:
revie
On Tue, 28 May 2024 20:24:31 GMT, Leonid Mesnik wrote:
> The
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java
> uses cleanup() to kill debuggee process.
>
> However, most tests kill the debuggee process explicitly. I verified that
> debuggee process is killed before test
On Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote:
>> Hi all,
>> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
>> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>> There are two changes in this PR:
>> 1. In
On Wed, 29 May 2024 19:06:57 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: addressed nits in new test
>
> test/hotspot/jtreg/serviceabilit
he virtual thread gets unmounted.
>
> The fix also includes new test case `vthread/CarrierThreadEventNotification`
> developed by Patricio.
>
> Testing:
> - Ran new test case locally
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally with
On Thu, 30 May 2024 01:03:01 GMT, Alex Menkov wrote:
>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>> - The `EnterInterpOnlyModeClosure::do_threads` is taking the
>> `JvmtiThreadState` with the `jt->jvmti_thread_state()`
On Thu, 30 May 2024 00:41:28 GMT, Alex Menkov wrote:
>> Please, review the following `interp-only` issue related to carrier threads.
>> There are 3 problems fixed here:
>> - The `EnterInterpOnlyModeClosure::do_threads` is taking the
>> `JvmtiThreadState` with the `jt->jvmti_thread_state()`
On Tue, 28 May 2024 06:52:13 GMT, SendaoYan wrote:
>> Hi all,
>> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
>> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>> There are two changes in this PR:
>> 1. In
On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robustness
>
On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe wrote:
> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area
> that is supposed to work even if the current thread is not attached yet and
> there is no associated Thread or the Thread has no valid ResourceArea.
>
> It
On Wed, 29 May 2024 01:47:27 GMT, Chris Plummer wrote:
>> Fixed "double-checked-locking" bug in `ReferenceImplType.classObject()`.
>> Details in the first comment. Tested with the following:
>> - com/sun/jdi
>> - nsk/jdi
>> - nsk/jdwp
>> - nsk/jdb
>
> Chris Plummer has updated the pull request
On Tue, 28 May 2024 22:29:28 GMT, Leonid Mesnik wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while
>> current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>>
Please, review the following `interp-only` issue related to carrier threads.
There are 3 problems fixed here:
- The `EnterInterpOnlyModeClosure::do_threads` is taking the
`JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when
we have a deal with a carrier thread. The
On Tue, 21 May 2024 19:55:01 GMT, Leonid Mesnik wrote:
> The BindServer starts several threads and opens streams.
>
> It registered them for cleanup using "Finalizer" from nsk.share.framework.
> Currently, it cleanup resources during shutdown hook.
>
> This fix changes BindServer to
On Wed, 1 May 2024 10:20:52 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 are not
> listed
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 Sat, 18 May 2024 00:47:59 GMT, Alex Menkov wrote:
> JVMTI GetCarrierThread extension function was introduced by loom for testing.
> It's used by several tests in hotspot/jtreg/serviceability.
>
> Testings: tier1..tier6
Looks good.
-
Marked as reviewed by sspitsyn (Reviewer).
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
1 - 100 of 1579 matches
Mail list logo
