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 Thu, 2 May 2024 21:14:06 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1289:
>>
>>> 1287:
>>> 1288: static void
>>> 1289: verifyMonitorRank(JNIEnv *env, DebugRawMonitorRank rank, jthread
>>> thread)
>>
>> please add a comment that the function should be
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
>>
> 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 Mon, 6 May 2024 17:05:47 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
>
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 Sat, 4 May 2024 03:45:31 GMT, Lei Zaakjyu wrote:
>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> review
In SA I see references to heapRegionIterate() that possibly should be renamed.
I noticed that
On Thu, 2 May 2024 21:02:17 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1231:
>>
>>> 1229: }
>>> 1230:
>>> 1231: dbg_monitor->monitor = NULL;
>>
>> I think it would be better to protect this with dbgRawMonitor
>
> I don't see how that helps. Access
On Thu, 2 May 2024 21:09:42 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1243:
>>
>>> 1241: error = JVMTI_FUNC_PTR(gdata->jvmti,GetThreadInfo)
>>> 1242: (gdata->jvmti, thread, );
>>> 1243: return info.name;
>>
>> Need to delete JNI
On Thu, 2 May 2024 21:00:52 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1204:
>>
>>> 1202: // Need to lock during initialization so verifyMonitorRank() can
>>> be guaranteed that
>>> 1203: // if the monitor field is set, then the monitor if fully
> 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
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 tables at
the top of the RO region. As a further improvement, all the
On Mon, 6 May 2024 17:29:05 GMT, Sebastian Lövdahl wrote:
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
>> (Kubernetes debug container)
>
> Sebastian Lövdahl has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
On Mon, 6 May 2024 17:29:05 GMT, Sebastian Lövdahl wrote:
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
>> (Kubernetes debug container)
>
> Sebastian Lövdahl has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
> (Kubernetes debug container)
Sebastian Lövdahl has updated the pull request incrementally with one
additional commit since the last revision:
Reworked attach logic
-
Changes:
- all:
I'll send you another diff, I have something that I think may work...
On 5/6/24 9:16 AM, Sebastian Lövdahl wrote:
Yep, that sounds reasonable. I'll try to work something out along
these lines, thanks for the input!
Unfortunately, /proc//cwd is also restricted in the same way
as /proc//root
On Fri, 3 May 2024 17:40:54 GMT, jdoylei wrote:
> > I think it boils down to the same reason as why the fix for JDK-8226919 was
> > needed in the first place - a non-root user cannot read the symlinks in
> > `/proc//ns` for a process running with more privileges even though
> > it's run by
Yep, that sounds reasonable. I'll try to work something out along these
lines, thanks for the input!
Unfortunately, /proc//cwd is also restricted in the same way
as /proc//root is.
/Sebastian
On 2024-05-05 00:06, Laurence Cable wrote:
so I think to summarize the logic we require:
1) if we
On Mon, 6 May 2024 09:12:47 GMT, Albert Mingkun Yang wrote:
>> src/hotspot/share/gc/serial/serialHeap.cpp line 461:
>>
>>> 459: if (should_verify && VerifyBeforeGC) {
>>> 460: prepare_for_verify();
>>> 461: Universe::verify("Before GC");
>>
>> May the prefix of the verification log
> 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 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:26:58 GMT, Stefan Karlsson wrote:
>> Ah, hm. Indeed! Separate PR? There is some light cleanup in G1 that can be
>> associated with it. This PR would keep with just a mechanical rename.
>
> Sounds like a good idea.
Filed: https://bugs.openjdk.org/browse/JDK-8331719 -- I'll
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
> 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 Sat, 4 May 2024 02:39:38 GMT, Guoxiong Li wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains one commit:
>>
>> s1-do-collect
>
> src/hotspot/share/gc/serial/serialHeap.cpp line 461:
>
>> 459: if
26 matches
Mail list logo
