On Tue, 19 Dec 2023 16:59:05 GMT, Emanuel Peter wrote:
> [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the
> `GrowableArrayCHeap`. This duplicates the current C-Heap allocation
> capability in `GrowableArray`. I now remove that from `GrowableArray` and
> move all
On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote:
> Please review this PR with a simple solution for resolving duplicate `Thread`
> symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there
> was an alternative suggestion to redefine the symbol at build time, such as
>
On Wed, 8 May 2024 16:39:33 GMT, Chris Plummer wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all
>
> Marked as reviewed by cjplummer
On Wed, 8 May 2024 23:48:08 GMT, Serguei Spitsyn wrote:
>> Yes, the 2nd loop is a different check. That's why I said it also checks all
>> the leaf monitors "but for a different reason". Your two loops do not flag
>> a rank violation if both monitors are leafs, even if grabbed in the wrong
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:40:26 GMT, Serguei Spitsyn wrote:
>> If the following are all true
>> - you are entering is a leaf monitor
>> - the current thread has already entered a leaf monitor
>> - the rank of the monitor you are entering is lower than the rank of the
>> monitor already held
>>
>>
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:10:15 GMT, Serguei Spitsyn wrote:
>> I think you are suggesting that all monitors be created up front during
>> util_intialize(). The debug agent in the past has always created them lazily
>> (and sometimes some of them end up never being created because they are not
>>
On Tue, 7 May 2024 16:38:23 GMT, Matias Saavedra Silva
wrote:
>> The beginning of the RW region contains pointers to c++ vtables which are
>> always located at a fixed offset from the shared base address at runtime.
>> This offset can be calculated at dumptime and stored with the read-only
I did some thinking on this issue over the weekend and came up with an
idea that *may* improve the probability of an attach succeeding in the
case that the target has elevated privileges and the jcmd is not in the
same mnt namespace as the target JVM.
basically, the idea is to recurse
On 5/3/24 10:43 AM, jdoylei wrote:
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)
I think it boils down to the same reason as why the fix for JDK-8226919 was needed in
the first
On Wed, 8 May 2024 21:44:37 GMT, Serguei Spitsyn wrote:
>>> A "leaf" failure is more specific than a "rank order" failure, so it is
>>> better to report it first. Each "leaf" failure is also a "rank order"
>>> failure (AFAICS).
>>
>> It's not just a matter of which is reported first. Even if
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 20:23:21 GMT, Serguei Spitsyn wrote:
> A "leaf" failure is more specific than a "rank order" failure, so it is
> better to report it first. Each "leaf" failure is also a "rank order" failure
> (AFAICS).
It's not just a matter of which is reported first. Even if you swap the
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 Wed, 8 May 2024 15:47:09 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix jcheck extra whitespace.
>> - Fix comment typo.
>
> src/jdk.jdwp.agent/share/native/libjdwp/util.c line
> 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
On Wed, 8 May 2024 16:46:33 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix jcheck extra whitespace.
>> - Fix comment typo.
>
> src/jdk.jdwp.agent/share/native/libjdwp/util.c line
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Wed, 8 May 2024 15:44:37 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix jcheck extra whitespace.
>> - Fix comment typo.
>
> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line
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 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 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 Wed, 8 May 2024 07:37:52 GMT, Serguei Spitsyn wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all
>
> Marked as reviewed by sspitsyn
On Tue, 30 Apr 2024 09:54:40 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 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`?
> 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.
>
>
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
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
33 matches
Mail list logo
