> 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/80eeb443..b007eb01
Webrevs
> 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/4d175e27..80eeb443
Webrevs
> 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 eight commits:
- rename
- Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8330694
- review
- Merge branch 'master' into JDK-8330694
- f
On Fri, 3 May 2024 12:49:03 GMT, Albert Mingkun Yang wrote:
>> 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
>
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
> in
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
> in
On Fri, 3 May 2024 18:31:21 GMT, Chris Plummer wrote:
> What "debugging option" are you referring to.
`-Djdk.tracePinnedThreads=full`. When this system property is set then it means
the onPinned callback is running the printing code. This is happen in a
transition when running with JVMTI enabl
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
> in
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 place - a non-root user cannot rea
I'll ponder ... have a good weekend!
regardless I think the added check for mnt ns comparison "adds value" by
expressing the constraints explicitly vs comparing pid & ns pid
Rgds
- Larry
On 5/3/24 9:45 AM, Sebastian Lövdahl wrote:
On Thu, 2 May 2024 10:13:51 GMT, Sebastian Lövdahl 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)
Thanks for the patch @larry-cable, much appreciated! I really like this idea.
I tried it out a bit locally. These cases seem to work:
On Fri, 3 May 2024 15:58:11 GMT, Severin Gehwolf wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 375:
>>
>>> 373: if (!c.isContainerized()) {
>>> 374: ostream.println(INDENT + "System not containerized.");
>>> 375: return;
>>
>> Why re
On Mon, 22 Apr 2024 13:56:23 GMT, Jan Kratochvil
wrote:
> Anyway in this patch one could unify naming across variables/parameters, the
> same value is called `_is_ro`, `is_read_only`, `ro_opt`, `read_only`, `ro`.
I've tried to unify the naming a bit. Thanks for the review!
-
PR C
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
> memory/cpu limits by means of the cgroup filesystem. If neither of thos
On Tue, 16 Apr 2024 18:21:29 GMT, Thomas Stuefe wrote:
> Why return here?
Because it's not useful to see containerized settings (other than the cg
version in use) after this patch. The JVM won't use them (uses the physical
settings instead). Why would you want to show the settings?
--
On Tue, 16 Apr 2024 18:16:33 GMT, Thomas Stuefe wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains ten additional
>> comm
On Tue, 16 Apr 2024 18:10:08 GMT, Thomas Stuefe wrote:
>> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:
>>
>>> 349: //
>>> 350: // We collect the read only mount option in the cgroup infos so as
>>> to have that
>>> 351: // info ready when determining is_containerized().
> 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
> 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
> `jvmt
On Thu, 2 May 2024 21:47:50 GMT, Chris Plummer wrote:
>> expEnteringCount/expWaitingCount contain the tested patterns. I don't see
>> why they can't just replace
>> NUMBER_OF_ENTERING_THREADS/NUMBER_OF_WAITING_THREADS in the comments also.
>> In fact it is confusing if you don't because code r
On Fri, 3 May 2024 06:40:07 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmti.xml line 8280:
>>
>>> 8278:
>>> 8279: The number of platform threads waiting to own this
>>> monitor, or 0
>>> 8280: if only virtual threads are waiting or no threads are
>>
On Fri, 3 May 2024 06:49:09 GMT, Alan Bateman wrote:
> It seems maybe we should instead be trying to avoid these events by
> preloading the classes as was suggested as an option in the CR.
The problem is that all such cases are unknown, so it is just not realistic. As
Alan commented, this exac
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
>
23 matches
Mail list logo
