On Wed, 1 May 2024 19:15:17 GMT, Chris Plummer wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address additional problem listed tests in hotspot/jtreg/serviceability
>
>
On Wed, 1 May 2024 19:02:29 GMT, Chris Plummer wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address additional problem listed tests in hotspot/jtreg/serviceability
>
>
> 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`?
>
> When jtreg was enhanced to allow running the tests from
On Wed, 1 May 2024 23:17:58 GMT, Chris Plummer wrote:
>> Good suggestion, thanks. Then I'd suggest this:
>>
>> // Virtual threads are not supported by the GetObjectMonitorUsage.
>> // Correct the expected values if the test is executed with the
>> //
On Thu, 2 May 2024 00:51:20 GMT, Serguei Spitsyn wrote:
>> Copy and paste issue on my part. I would use "if only virtual threads".
>
> Okay, thanks.
Second suggestion is better. "waited by" is not grammatically correct in this
context.
-
PR Review Comment:
just to demonstrate:
$ docker run -it --name=js1 openjdk:17.0.1-jdk /bin/jshell
...
$ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 /bin/jshell
$ docker exec -it js1 bash
bash-4.4# ls /tmp/hsperfdata_root
1 26
bash-4.4# readlink /proc/26/ns/pid
pid:[4026532751]
bash-4.4#
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 22:40:02 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmti.xml line 8266:
>>
>>> 8264:
>>> 8265: The number of platform threads waiting to own this
>>> monitor,
>>> 8266: or 0 if the monitor is owned by a virtual
>>> thread or
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
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 in the both
On 5/1/24 2:03 PM, Doyle, James, K wrote:
Hi Sebastian,
I think I can confirm that there is a regression.
Thanks for reproducing the regression, your test makes sense to me, and I think
it is similar to the scenario we have with Kubernetes debug containers
(separate filesystems, but same
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
moment. By imposing a rank on each monitor, we can check to
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
Hi Sebastian,
> I think I can confirm that there is a regression.
Thanks for reproducing the regression, your test makes sense to me, and I think
it is similar to the scenario we have with Kubernetes debug containers
(separate filesystems, but same PID namespace).
I noticed some of the other
On Wed, 1 May 2024 20:07:00 GMT, Larry Cable wrote:
>> c.f: /proc//ns/pid
>>
>> every (Linux) namespace has a unique id, if 2 (or more) processes occupy the
>> same pid namespace (or any other for that matter) then their ../ns/pid
>> namespace ids will be the same.
>
>
On Wed, 1 May 2024 18:35:29 GMT, Larry Cable wrote:
>> Do you mean that it should compare the input PID against the outermost
>> (leftmost) PID in the `NSpid` list from `/proc//status` and not
>> innermost (rightmost) as is done right now? What would be the benefit of
>> that? Or did you mean
On Tue, 30 Apr 2024 12:08:21 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, 1 May 2024 17:47:47 GMT, Sebastian Lövdahl wrote:
>> should it not be comparing pid namespace ids and not pids?
>
> Do you mean that it should compare the input PID against the outermost
> (leftmost) PID in the `NSpid` list from `/proc//status` and not
> innermost (rightmost) as is
On Fri, 12 Apr 2024 02:17:34 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`,
> `-XX:+HeapDumpAfterFullGC`
On Wed, 1 May 2024 17:30:05 GMT, Larry Cable wrote:
>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line
>> 217:
>>
>>> 215: // Instead, attach relative to the target root filesystem as
>>> exposed by
>>> 216: // procfs regardless of namespaces.
>>>
On Tue, 30 Jan 2024 12:13:05 GMT, Per Lundberg wrote:
>> 8226919: attach in linux hangs due to permission denied accessing
>> /proc/pid/root
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line
> 217:
>
>> 215: // Instead, attach relative to the target root
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. This testcase should be problemlist.
Only change the ProblemList, no risk.
-
Commit
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 executed under
>
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 is executed under
29 matches
Mail list logo
