Hi Chris,
It looks good in general.
One question:
It seems, the methods toHex() and fromHex() are no longer used and can
be removed now.
Thanks,
Serguei
On 2/15/19 5:08 PM, Chris Plummer wrote:
Hi,
Please review the updated webrev:
Hi,
Please review the updated webrev:
http://cr.openjdk.java.net/~cjplummer/8218947/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8218947
I removed "hex" from "object description and hex id" and removed the
java.lang. prefix from java.lang.Long references. There was no need to
update
Testing showed that the re-enabling of the retiring of TLABs was broken.
This has been fixed with this patch:
http://cr.openjdk.java.net/~stefank/8218922/webrev.03.delta
http://cr.openjdk.java.net/~stefank/8218922/webrev.03
During mark start we change what's considered the "good" view of the
I followed up on this just to make sure. It turns out we still do some
localizations, but they are handled automatically near the end of the
release cycle. So I think the changes are good as-is.
thanks,
Chris
On 2/14/19 6:56 AM, Chris Plummer wrote:
Do you mean for the non-english locales?
Is anyone setup to try this with
docker? I know initially jvm's running on the same host OS but in
different docker containers would not show up when requesting a
list of JVMs, but could be attached to when a specific PID was
provided. I believe all these issues
Hi Kevin,
On 2019-02-15 13:14, Kevin Walls wrote:
Hi Stefan,
This is great - if I want to try it out, what order do the changes
apply, does the 8218746 webrev apply to create ZExternalBitMap.java
and then the 8218922 webrev?
This is my patch queue of outgoing patches:
It isn't pretty, but it's functional : "-f to force communication. ...
Revised webrev: http://cr.openjdk.java.net/~gadams/8149461/webrev.02/
On 2/15/19, 11:57 AM, Daniel D. Daugherty wrote:
Yes. That's the direction I was thinking about.
Don't know about the '-F' versus '-F ', but
that a cmd
Yes. That's the direction I was thinking about.
Don't know about the '-F' versus '-F ', but
that a cmd line option parsing detail.
Dan
On 2/15/19 11:37 AM, Gary Adams wrote:
Here's a quick dirty "-F" that gets past
the "-XX:-UsePerfData" setting for jcmd.
Need to follow up on docs and usage
Here's a quick dirty "-F" that gets past
the "-XX:-UsePerfData" setting for jcmd.
Need to follow up on docs and usage
for the other commands.
Is this the direction you were thinking?
diff --git
a/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java
On 2/15/19 8:44 AM, Gary Adams wrote:
Confirmed
-XX:-UsePerfData
prevents visibility to jps, but allows direct access via pid.
The new check would block access before the attach is attempted.
May be best to close this bug as "will not fix".
Requires a valid Java process pid.
Or make it a
Could we not just use another signal? One less... quitty? I think SIGUSR2
may still be unused, but I may be mistaken. Or, one of the real time
signals (SIGRTMIN + x).
Other than that, I still think that knowing the pid there could be platform
dependent ways of verifying the process, e.g. checking
On Fri, Feb 15, 2019 at 3:19 PM Thomas Stüfe
wrote:
> Could we not just use another signal? One less... quitty? I think SIGUSR2
> may still be unused, but I may be mistaken. Or, one of the real time
> signals (SIGRTMIN + x).
>
>
wait, that one would break downward compatibility. Still want to be
Confirmed
-XX:-UsePerfData
prevents visibility to jps, but allows direct access via pid.
The new check would block access before the attach is attempted.
May be best to close this bug as "will not fix".
Requires a valid Java process pid.
On 2/15/19, 8:29 AM, Bernd Eckenfels wrote:
I wonder,
On 15/02/2019 11:28 pm, Gary Adams wrote:
On 2/15/19, 8:18 AM, David Holmes wrote:
On 15/02/2019 8:04 pm, gary.ad...@oracle.com wrote:
Let me clarify a few things about the proposed fix.
The VirtualMachine.list() mechanism is based on
Java processes that are up and running.
During VM startup
I wonder, instead of listing all VMs, would it be better to check only the
target PID?
BTW speaking of hs_perf files: is it supposed to work without -XX:-UserPerfData
also?
Gruss
Bernd
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gary Adams
Gesendet:
On 2/15/19, 8:18 AM, David Holmes wrote:
On 15/02/2019 8:04 pm, gary.ad...@oracle.com wrote:
Let me clarify a few things about the proposed fix.
The VirtualMachine.list() mechanism is based on
Java processes that are up and running.
During VM startup when agent libraries are loaded,
the fact
On a linux system with 1 Java process and 500 non-Java processes,
/tmp is not tmpfs mounted, 20 runs average 255.5 ms stddev 9.32.
JDK-8176828 is the issue that enabled perfmemory visibility once the vm
is in live mode.
For containers that are configured without a shared view of /tmp, it may
On 15/02/2019 8:04 pm, gary.ad...@oracle.com wrote:
Let me clarify a few things about the proposed fix.
The VirtualMachine.list() mechanism is based on
Java processes that are up and running.
During VM startup when agent libraries are loaded,
the fact is recorded in the filesystem that a Java
I'll get some measurements on some local systems so we have a
specific idea about the overhead of the pid check.
I imagine in most production environments the /tmp tmpfs
is memory only set of checks.
One of the "not all vms are recognized" was fixed recently.
When starting a libjdwp session with
Hi Stefan,
This is great - if I want to try it out, what order do the changes
apply, does the 8218746 webrev apply to create ZExternalBitMap.java and
then the 8218922 webrev?
Thanks
Kevin
On 14/02/2019 17:12, Stefan Karlsson wrote:
Hi again,
I've separated the live regions iteration
Hello,
I see possible issues here, not sure if they still exist but I wanted to
mention them:
the list-vm function might be slow on a loaded system (as it is a complex
function). It’s not the best Situation if your diagnostic attempts are slow
down in such a situation.
Also in the past not
Hello Sharath,
Thanks for your help.
Best Regards
From: Sharath Ballal
Sent: 2019年2月15日 18:10
To: Shuai Gao ; serviceability-dev@openjdk.java.net
Subject: RE: jstack mixed mode and jhsdb stack mixed mode can not get expected
result(stack trace is incomplete) on latest ubuntu or
Ok Gao. I will open another bug for your case.
Thanks,
Sharath
From: Shuai Gao
Sent: Friday, February 15, 2019 3:35 PM
To: Sharath Ballal; serviceability-dev@openjdk.java.net
Subject: RE: jstack mixed mode and jhsdb stack mixed mode can not get expected
result(stack trace is
Let me clarify a few things about the proposed fix.
The VirtualMachine.list() mechanism is based on
Java processes that are up and running.
During VM startup when agent libraries are loaded,
the fact is recorded in the filesystem that a Java process
is eligible for an attach request.
This is a
Hello Sharath,
Thanks for your reply.
I am afraid the issue in BUG JDK—8219086 is not the same as mine.
In the bug, the output of jhsdb jstack prints some mixed stack trace but does
not print all the threads.
Within my issue, the output of jhsdb jstack can print all the threads but can
Hi Gao,
I also observed this failure and opened HYPERLINK
"https://bugs.openjdk.java.net/browse/JDK-8219086"JDK-8219086 for it.
Thanks,
Sharath
From: Shuai Gao
Sent: Friday, February 15, 2019 12:15 PM
To: serviceability-dev@openjdk.java.net
Subject: jstack mixed mode and jhsdb
Thanks, Yasumasa!
StefanK
On 2019-02-15 01:54, Yasumasa Suenaga wrote:
Hi Stefan,
Both changes look good to me!
Thanks,
Yasumasa
2019年2月15日(金) 2:12 Stefan Karlsson :
Hi again,
I've separated the live regions iteration refactoring into this patch:
On Fri, Feb 15, 2019 at 3:26 AM David Holmes
wrote:
> Gary,
>
> What is the overhead of doing the validation? How do we list VMs? Do we
> need to examine every running process to get the list of VMs? Wouldn't
> it be better to check the given process is a VM rather than checking all
> potential
28 matches
Mail list logo
