> 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 "renamed current_thread to current"
This reverts commit
On Tue, 30 Apr 2024 23:48:02 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 one additional
> commit since the last revision:
>
> renamed
On Tue, 30 Apr 2024 23:48:02 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 one additional
> commit since the last revision:
>
> renamed
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 an assert
>
diff --git
a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
b/src/jdk.attach/linux/classes/sun/tools/attach/V
irtualMachineImpl.java
index 81d4fd259ed..74bd60c791d 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++
On Thu, 2 May 2024 03:57:42 GMT, Jaikiran Pai wrote:
>> test/hotspot/jtreg/serviceability/tmtools/jstack/DaemonThreadTest.java line
>> 77:
>>
>>> 75: t.setDaemon(false);
>>> 76: }
>>> 77: testThread(t, "");
>>
>> I think the following is a bit clearer:
>>
>>
>>
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 Thu, 2 May 2024 21:36:27 GMT, Chris Plummer wrote:
>> Thank you for the comment. In fact, I don't know how to fix it.
>> Replacing of NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in
>> comments with `expEnteringCount/expWaitingCount` does not make sense to me.
>> The comments are
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 are not
>> listed in the
On Wed, 1 May 2024 20:42:16 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3)
>> test comments
>
>
On Thu, 2 May 2024 06:45:39 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java
>> line 257:
>>
>>> 255: // Correct the expected values for the virtual thread case.
>>> 256: int expEnteringCount = isVirtual ?
On Sat, 20 Apr 2024 03:04:23 GMT, Chris Plummer wrote:
>> Lei Zaakjyu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java
> line 131:
>
>> 129:
On Thu, 2 May 2024 02:40:36 GMT, Alex Menkov 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, 30 Apr 2024 18:54:09 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 Wed, 1 May 2024 21:32:46 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
> given
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 are not
>> listed in the
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` could then be
On Thu, 2 May 2024 17:23:21 GMT, Aleksey Shipilev wrote:
>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1270:
>>
>>> 1268:
>>> 1269: ParallelScavengeHeap* heap = ParallelScavengeHeap::heap();
>>> 1270: assert(!heap->is_stw_gc_active(), "not reentrant");
>>
>> While reading
On Thu, 2 May 2024 17:04:44 GMT, Stefan Karlsson wrote:
>> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_
>> GC phase is running, while it actually only covers the STW GCs. It would be
>> good to rename it for clarity. The freed-up name, `is_gc_active` could then
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` could then be
On Thu, 2 May 2024 16:56:11 GMT, Stefan Karlsson wrote:
>> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_
>> GC phase is running, while it actually only covers the STW GCs. It would be
>> good to rename it for clarity. The freed-up name, `is_gc_active` could then
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` could then be
`CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
phase is running, while it actually only covers the STW GCs. It would be good
to rename it for clarity. The freed-up name, `is_gc_active` could then be
repurposed to track any (concurrent or STW) GC phase running.
> follow up 8267941
Lei Zaakjyu has updated the pull request incrementally with one additional
commit since the last revision:
review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18871/files
- new: https://git.openjdk.org/jdk/pull/18871/files/f4e066c4..92d0df4d
> follow up 8267941
Lei Zaakjyu has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains five commits:
- Merge branch 'master' into JDK-8330694
- fix indentation
- also tidy up
- tidy up
- rename
-
Changes:
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 are not
>> listed in the
Thank you, Larry - that /proc//ns/mnt test makes a lot of sense to me, and
I learned something new today!
Jim
-Original Message-
From: serviceability-dev On Behalf Of
Laurence Cable
Sent: Wednesday, May 1, 2024 8:44 PM
To: serviceability-dev@openjdk.org
Subject: Re: 8327114: Attach in
It's probably easier to read the new code directly. The two classes in
`serialVMOperations` serve as entrance points to invoke young/full GCs. Some
previously hidden decisions are made more obvious, e.g. if a young-gc fails (or
will probablly fail), fallback to full-gc.
Additionally,
On Thu, 2 May 2024 10:13:51 GMT, Sebastian Lövdahl wrote:
> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
> (Kubernetes debug container)
Ran the following tests locally:
$ make test TEST="jtreg:test/hotspot/jtreg/containers"
...
==
Test
using pid to namespace comparison is IMO inappropriate/misleading what
is being tested is the sharing of a common mount namespace, therefore
the test should be comparing the "mnt" namespace ids.
Rgds
- Larry
On 5/2/24 3:22 AM, Sebastian Lövdahl wrote:
On Thu, 2 May 2024 10:13:51 GMT,
On Thu, 2 May 2024 10:13:51 GMT, Sebastian Lövdahl wrote:
> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
> (Kubernetes debug container)
This is a first stab at fixing the regression introduced in #17628. There has
been a bit of discussion in
On 5/2/24 3:09 AM, Sebastian Lövdahl wrote:
Interesting, TIL about /proc//ns. I tried to look for something
like that but couldn't find anything relevant in /proc//status.
ok
So, a pixel perfect solution could compare these IDs to know whether
/tmp or /proc//root/tmp should be used.
>
8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
(Kubernetes debug container)
-
Commit messages:
- 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
(Kubernetes debug container)
Changes: https://git.openjdk.org/jdk/pull/19055/files
Webrev:
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
Interesting, TIL about /proc//ns. I tried to look for something
like that but couldn't find anything relevant in /proc//status.
So, a pixel perfect solution could compare these IDs to know whether
/tmp or /proc//root/tmp should be used.
> 2. jcmd treats it as a heuristic and attempts each
On Tue, 30 Apr 2024 18:54:09 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`,
> 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, 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
41 matches
Mail list logo
