On 7/17/24 10:03 PM, Thomas Stuefe wrote:
On Thu, 18 Jul 2024 00:45:24 GMT, Leonid Mesnik wrote:
Sonia Zaldana Calles has updated the pull request incrementally with one
additional commit since the last revision:
Updates based on feedback
src/hotspot/share/code/codeCache.cpp line
On 7/12/24 12:06 PM, Ron Pressler wrote:
On 10 Jul 2024, at 16:37, Jaroslav Bachorik wrote:
This may not always be possible. Some systems have rather complex and inlexible
launchers - for example Apache Spark with its clusters, drivers and executors
and automatic distribution of
On 7/1/24 5:59 AM, Kevin Walls wrote:
On Mon, 1 Jul 2024 07:19:48 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
On 6/28/24 8:45 AM, Severin Gehwolf wrote:
On Thu, 27 Jun 2024 18:40:09 GMT, Larry Cable wrote:
Severin Gehwolf has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 17 commits:
- Refactor mount info matching to helper function
will do!
On 6/26/24 3:04 AM, Severin Gehwolf wrote:
On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf wrote:
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
Forwarded Message
Subject: Re: RFR: 8332124: Jcmd processing should accept the "help" sub
option as command argument [v2]
Date: Tue, 25 Jun 2024 13:30:04 -0700
From: Laurence Cable
To: serviceability-dev@openjdk.org
what about '*jcmd help *' not a
and jcmd already supports "help" w/o a target argument, so this pattern
is a natural extension, and one which other toolsets have adopted!
On 6/25/24 1:28 PM, Laurence Cable wrote:
what about '*jcmd help *'
not a great deal of additional code for the 'help' jcmd to delegate to
what about '*jcmd help *'
not a great deal of additional code for the 'help' jcmd to delegate to
the target jcmd?
- Larry
On 6/25/24 10:15 AM, Kevin Walls wrote:
On Tue, 25 Jun 2024 13:55:32 GMT, Sonia Zaldana Calles
wrote:
Hi all,
This PR addresses
On 6/4/24 5:57 AM, Sebastian Lövdahl wrote:
On Tue, 21 May 2024 17:10:15 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 two
additional
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
just a thought ... what if the code were to recurse "up" the process
tree if the target JVM had elevated privs (and its /proc/... was not
accessible), in order to find an
ancestor whose /proc was accessible, since the JVM itself does not
modify its pid or mnt namespaces (or capabilities) only
is.
/Sebastian
On 2024-05-05 00:06, Laurence Cable wrote:
so I think to summarize the logic we require:
1) if we can determine that the attacher and attachee occupy the same
mnt ns (/proc//ns/mnt == /proc//ns/mnt), return
"/tmp"
2) if they are not in the same mnt ns:
- test
so I think to summarize the logic we require:
1) if we can determine that the attacher and attachee occupy the same
mnt ns (/proc//ns/mnt == /proc//ns/mnt), return "/tmp"
2) if they are not in the same mnt ns:
- test the /proc//root/tmp path for readability, if it
is, return that
- if
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:
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
+++
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,
the attacher does not
have sufficient privilege to access that due
to attachee capabilities etc then the attach will fail
Rgds
- Larry
/Sebastian
On 2024-05-02 03:43, Laurence Cable wrote:
just to demonstrate:
$ docker run -it --name=js1 openjdk:17.0.1-jdk /bin/jshell
...
$ docker run -
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 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
On 4/18/24 2:54 AM, Severin Gehwolf wrote:
On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
IMHO `is_containerized()` is OK to return `false` even when running in a
container but with no limitations set.
The idea here is to use this property to tune OpenJDK for in-container,
On 4/18/24 9:38 AM, Severin Gehwolf wrote:
On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
Could not we rename `is_containerized()` to `use_container_limit()` ? As that
is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()`
Hi Maxim, a great idea, the JDK serviceability team here at Oracle would
like to assist you in any way we can.
I think also we should (in the future) consider the format of the error
file and associated jcmd and perhaps render the content
in a format that is better suited to programmatic
Forwarded Message
Subject:RFO: a tool to analyze HotSpot fatal error logs
Date: Thu, 11 Apr 2024 18:05:44 +0400
From: Maxim Kartashev
To: disc...@openjdk.org, hotspot-...@openjdk.org
Hello,
I am writing to inquire about the potential interest of the
looking at the "attacher" code in jdk.attach it certainly does not
appear to attempt to "attach" via cwd, so I would say that the
"attachee" code to check this is redundant, unless there is a backwards
compatibility/interoperability issue that requires this where
an early JDK "attacher" might
On 2/5/24 1:56 AM, Kevin Walls wrote:
On Mon, 5 Feb 2024 09:25:24 GMT, Yi Yang wrote:
jcmd VM.debug MyDebugCode.java
Are you thinking to run some Java code in the target JVM?
VM.debug as presented here is all about inspecting JVM state, mostly using
existing mechanisms but which were
Thanks Marcus!!!
looking forward to it!
- Larry
On 10/15/23 1:28 PM, Marcus Hirt wrote:
Hi all,
Roughly 19 months ago I held an OpenJDK Serviceability Meetup, where a
few people (35 in total) from various companies (Oracle, SAP, Red Hat,
Datadog, Azul, VMware and more) interested in
On 9/28/23 10:38 PM, Alan Bateman wrote:
On 28/09/2023 21:42, daniel.daughe...@oracle.com wrote:
java.lang.instrument is owned by the Serviceability Team so I'm
redirecting this
message to that alias...
This doesn't look like a JDK issue, instead it looks like
this is effectively what dynamic agent loading enables, which
https://openjdk.org/jeps/451 proposes to disable.
Rgds
- Larry Cable
On 7/16/23 10:09 PM, David Holmes wrote:
On 17/07/2023 12:21 pm, Yi Yang wrote:
Actually, this is not a very new and strange idea. I often encounter
similar
I think while this discussion is an interesting one, and clearly one the
elicits strong opinions; I believe that the focus on the proposed change
on dynamic loading of agents has truly been lost therein, further
exchanges have little relevance to the topic of Java serviceability and
the issue
agree Alan
On 7/14/22 1:27 AM, Alan Bateman wrote:
On Thu, 14 Jul 2022 07:54:56 GMT, xpbob wrote:
Thanks for review. The runtime information is already fetched through the
OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the
configuration data.Such an interface
31 matches
Mail list logo
