Re: Safepoint Bean?

Hi Tony, A side effect of modularization is that it’s breaking more diagnostic tooling. Oh well…. Kind regards, Kirk > On Oct 14, 2019, at 8:25 AM, Tony Printezis wrote: > > Is jvmstat a public / supported API? The jdk.internal.jvmstat module doesn’t > seem to be exporting anything publicly

Re: Safepoint Bean?

Hi Tony, I think delivering this information, available via logging, could be useful. Be happy to assist where I can. Kind regards, Kirk > On Oct 14, 2019, at 11:23 AM, Tony Printezis wrote: > > Hi Mandy, > > Thanks for the response! I hope you’re well! > > We’d like to be able to get safe

Re: RFR(XS) 8230674 Heap dumps should exclude dormant CDS archived objects of unloaded classes

Hi, Might I add a diagnostic twist to this request. It is sometimes useful to try to determine where unreferenced objects live in heap because this can help you solve questions of nepotism. Kind regards, Kirk > On Sep 6, 2019, at 4:06 PM, Jiangli Zhou wrote: > > On Fri, Sep 6, 2019 at 3:17

Re: JFR thread sampling mechanism

Hi Gil, I would support an improvement in sampling as there is an obvious bias which allows me to write benchmarks where JFR completely misses things it should find. That said, I’m not sure that waking a thread up every 10ms is a great idea as it is very disruptive to Linux thread scheduling. I

Re: OperatingSystemMXBean unaware of container memory limits

ifically for a separate bean. > > That could be indicated via a property in the OS Bean (if it’s not the case > already). > > Nevertheless, I think consistency in the OS Bean should be achieved. > > Cheers, > Mario > > On Fri 21. Jun 2019 at 13:23, Kirk Pepperdine &

Re: OperatingSystemMXBean unaware of container memory limits

however, that from the point of view of a containerised VM >> its OS is the container not the bare metal (or virtualized metal perhaps), >> so tooling would need to check specifically for a separate bean. >> >> That could be indicated via a property in the OS Bean (if it’s n

Re: OperatingSystemMXBean unaware of container memory limits

Hi Mario, I don’t believe the MBean returns the wrong information. Is it not that the calls by-pass the container? Would it not be more appropriate to add a container aware mean? From a tooling perspective it’s a mistake to completely seal the JVM away from the hardware as it makes certain diag

Re: Proposal: Always-on Statistical History

. Kind regards, Kirk Pepperdine > On Nov 15, 2018, at 9:07 AM, Simon Roberts > wrote: > > I don't begin to claim to know the politics, legalities, boundaries of JFR > license conditionsm and so forth" but: > > Java Flight Recorder requires a commercia

Re: Proposal: Always-on Statistical History

Hi, I agree, this could be very useful… — Kirk > On Nov 14, 2018, at 10:29 AM, Simon Roberts > wrote: > > I would say this could be pretty useful. It's almost like a > platform-independent, process specific vmstat, with JVM extras. Given the > existence of jps, this seems to fit in that ec

Re: hprof format question

Hi Simon, I’ve also started a small project to try and solve the we need to look at very large heap problem. My solution is to load the data into Neo4J. You can find the project on my GitHub account. So, I believe I’ve taken the same tactic in just abandoning the segment for the moment. It wou

Re: Kerberos authentication for JMX?

Hi Peter, This is an issue for prod environments that is becoming bigger as clusters become bigger and bigger. I believe the answer to your issues and others related to the reliance of RMI has been proven by a project call Jolokia (https://jolokia.org ) which uses REST. At

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

> On Jun 6, 2018, at 6:05 PM, Thomas Stüfe wrote: > > Dear all, > > may I please have feedback and if possible reviews for this small addition: I can see the need to visualize this but the output looks easily parsable so it all looks good from my perspective. Not an official review — Kirk

Re: RFR(S): 8200720: Print additional information in thread dump (times, allocated bytes etc.)

> On Jun 4, 2018, at 8:24 PM, Chris Plummer wrote: > > Hi Gunter, > > Just restating what I said with my initial review: > >> The output you are adding is all useful. I think the question is (and I'd >> like to see a few people chime in on this for this review) is whether or not >> all of i

Re: jcmd - executing multiple commands at the same safepoint?

> On May 10, 2018, at 11:26 AM, Thomas Stüfe wrote: > > On Thu, May 10, 2018 at 9:13 AM, Kirk Pepperdine > wrote: >> The stacking at the safe point would be a huge win. Right now thread dump >> consistency can really confuse people as the tooling will show two threads

Re: jcmd - executing multiple commands at the same safepoint?

is very useful and I wished I had of known about it earlier. — Kirk > On May 10, 2018, at 7:50 AM, Thomas Stüfe wrote: > > Hi Kirk, > > On Thu, May 10, 2018 at 8:07 AM, Kirk Pepperdine > wrote: >> >>> On May 10, 2018, at 7:04 AM, Thomas Stüfe wrote: >>

Re: jcmd - executing multiple commands at the same safepoint?

d just specify: > > jcmd GC.class_stats columns=InstBytes,KlassBytes VM.metaspace show-loaders I’d vote for this form. Simple.. — Kirk > > and that would be for jcmd too. It is more for the benefit of the user. > > On Thu, May 10, 2018 at 7:54 AM, Kirk Pepperdine >

Re: jcmd - executing multiple commands at the same safepoint?

Awesome idea! Would the semicolon would be an issue for shell scripts? > On May 10, 2018, at 6:52 AM, Thomas Stüfe wrote: > > Hi all, > > just asking around for opinions. > > I am playing with the idea of bundling diagnostic commands to have > them executed at the same safepoint, in order to ge

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

Hi Paul, Is this is targeted for 11? It seems like a positive useful change. My opinion is that if you’re going to break the tool chain.. make sure the change is well worth the pain and get in everything that you want or makes sense or what ever. Just make sure it’s worth the pain. It’s been f

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

o there will always be a demand for the ability to > get collector and memory pool specific details, so I don’t see a way to get > around providing named entities. Agreed…tuning strategies are implementation dependent and sensitive to specific versions. One is always going to need

Re: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error

is initialized we can not explicitly say whether java.instrument > module is present or not. This is the only legitimate reason that is imaginable. I’d suggest that rather than overreaching you just state what you tried to do and that it failed. Kind regards, Kirk Pepperdine > >

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

html >> >> <https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html> >> RMIConnector is one implementation of above connector. >> >> On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >>> Hi Harsha, >>>

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

n referring to. > > On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >> Hi Harsha, >> >> From Chapter 5 of the JMX documentation. "Many different implementations of >> connectors are possible. In particular, there are many possibilities for the &g

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

lable for local communications but it offers some advantages over using a socket based protocol, even if that comms is over local loopback. Kind regards, Kirk Pepperdine > On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B > wrote: > > Hi Kirk, > > REST APIs work as an adapter and cannot w

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

I is an issue. I think this where we can learn from jolokia. Kind regards, Kirk Pepperdine > > Best Regards > Martin Skarsaune > > man. 11. sep. 2017 kl. 21:55 skrev Kirk Pepperdine <mailto:kirk.pepperd...@gmail.com>>: >> On Sep 11, 2017, at 9:46 PM, Martin Ska

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

lessons to be learned from Jolokia. It is a great/useful tool but it is not a JMXConnector. IMHO the REST layer should be implemented as a JMXConnector. It is the implementation that has the ability to integrate with widest set of exiting tooling. Kind regards, Kirk Pepperdine > it wo

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

gt;>>> Jolokia? This could make life a lot easier for third party tools that >>>> connect to it. >>>> >>>> Best Regards >>>> >>>> Martin Skarsaune >>>> >>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >&g

Re: JEP review : JDK-8171311 - REST APIs for JMX

gt; Jolokia can serve as a viable alternative but can be bulky. We are looking > for simple and lightweight solution. > > -Harsha > > On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >> Hi, >> >> Have you run into this project? https://jolokia.org &

Re: JEP review : JDK-8171311 - REST APIs for JMX

Hi, Have you run into this project? https://jolokia.org. Unfortunately it’s not exactly a drop in replacement for the standard RMI based JMX connector but it’s not far off. Kind regards, Kirk > On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: > > Hi Harsha, > > Looping in jmx-dev. > > > byte

Re: output of jstack command

ifferent, so the tools need to > change for Java 9. > > Is it fair to count on a consistent format per Java release for jstack? > > Thanks, > Ramki > > On Thu, May 25, 2017 at 8:07 AM, Kirk Pepperdine <mailto:kirk.pepperd...@gmail.com>> wrote: > Hi Ramki, > > T

Re: output of jstack command

Hi Ramki, The source for jstack is in openJDK. Feel free to create your own copy of jstack where you can output the information in any format he likes. If you are suggesting that the existing format be changed do be aware that there are many tools that expect the current format. These have been

Re: PRE-RFR: 8177154: Default configuration should disallow loading agents

Hi Alan, I have to agree with Mario here. I think a natural reaction would be to configure the JVM to opt-in by default. Otherwise you will break just about every APM/Monitoring tool out there. If opt-in is almost an automatic then you have to question the value of this change. Kind regards, K

Re: Low-Overhead Heap Profiling

Hi Jeremy, > > The answer to that is not to use safepoint-biased execution profilers, I > think. Thank you for the advice. I’ve been advocating for a number of years that people understand the sampling bias that exists in all profilers. I also would consider safe point bias being the most e

Re: Low-Overhead Heap Profiling

> > Do you mean “sample every X ms, say”? > > > This is not impossible, but a little weird. Yes, you are right, this is weird and I don’t think is necessary for this type of profiling. Please ignore. Regards, Kirk

Re: Low-Overhead Heap Profiling

rate has to be that high to find hot allocation sites. Kind regards, Kirk Pepperdine > > Tony > > > >> >> Kind regards, >> Kirk Pepperdine >> > > > - > > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > tprinte...@twitter.com

Re: Low-Overhead Heap Profiling

uld allocation frequency be more damaging to performance? Allocation > is cheap, and as long as they become dead before the YG collection, it costs > the same to collect one 1MB object as it does to collection 1000 1K objects. > > Jeremy > > On Wed, Jun 24, 2015 at 11:54 PM, Kirk

Re: Low-Overhead Heap Profiling

d sampling Kind regards, Kirk Pepperdine

Re: Low-Overhead Heap Profiling

; > jlong uid; > }; If you could get age data that could be interesting as well. Kind regards, Kirk Pepperdine

Re: Low-Overhead Heap Profiling

Hi Vladimir, The difference would be in the licensing. Kind regards, Kirk Pepperdine On Jun 23, 2015, at 7:31 AM, Vladimir Voskresensky wrote: > Hello Jeremy, > > If this is sampling, not tracing, then how is it different from the > low-overhead memory profiling provided by JF

Re: System.gc() causes for jcl (BufferPoolMXBean)

> > Back-off + gc is implementation specific and I don't think appropriate to add > to the BufferPoolMXBean. This type of tracking might be better served with > jvmstat counters. JFR isn't in OpenJDK but others here might be able to say > whether it could make use of the counters and updated i

Re: More visibility into code cache churn

Hi Ramki, Anything to improve visibility of the CodeCache would be hugely appreciated! Regards, Kirk On Jun 10, 2015, at 9:15 AM, Srinivas Ramakrishna wrote: > > I filed https://bugs.openjdk.java.net/browse/JDK-8087107 and attached a patch > to the ticket that exposes some useful code cache

Re: Updates to JEP-158: JVM Unified Logging are coming...

On Apr 17, 2015, at 11:29 AM, Fredrik Arvidsson wrote: > Hi > Ill try to reply in-line below. > > On 2015-04-17 10:27, Mattis Castegren wrote: >> Ok. One risk I see would be that you would forget "base tags". For example, >> if you write a lot of code in g1, it would be easy to log something

Re: Updates to JEP-158: JVM Unified Logging are coming...

Hi All, I’m very happy for a digital solution. As for solving problems in JFR.. great but that is a commercial solution and thus doesn’t work for OpenJDK. Remember? Plus, with all due respect for JFR, not all of us agree that this is the best way to sort out performance issues ;-) Regards, Kir

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

" to GCCause. > > So I applied it to new patch. > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > > > Could you review it again? > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/28 5:0

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

Hi Staffan, >> >> Anyway, it’s a record in a GC log so I don’t see the value of GC.run. >> Certainly “DiagCmd" or even "Diagnostic Command” seems sufficient given the >> context. > > Let’s go with “Diagnostic Command”, then. Thank you! Regards, Kirk signature.asc Description: Message sign

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

On Jan 27, 2015, at 8:37 PM, Staffan Larsen wrote: > >> On 27 jan 2015, at 18:00, Kirk Pepperdine wrote: >> >> Hi, >> >> On Jan 27, 2015, at 1:22 PM, Yasumasa Suenaga wrote: >> >>> Hi Staffan, >>> >>> Thank

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

Hi, On Jan 27, 2015, at 1:22 PM, Yasumasa Suenaga wrote: > Hi Staffan, > > Thank you for your comments. > > I've uploaded new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.01/ > > I changed as below: > - GCCause::_jcmd_gc_run -> GCCause::_dcmd_gc_run > - GCCause string

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

p failed - reason unknown"); } else { output()->print_cr("%s", error); } } } For example. For consistency, how would you suggest these be handled. Kind regards, Kirk Pepperdine On Jan 26, 2015, at 9:12 AM, Staffan Larsen wrote: > A bit of terminology here. ‘GC.run’

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

see a downstream impact on tooling. Thus I don’t see a compelling argument for the value of this change thus I will argue towards not destabilizing downstream tooling. That said, I’ve said my piece and have added enough spam to the list on this subject. Kind regards, Kirk Pepperdine On Jan 26

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

ho or why is responsible. My interest lies in keeping the GC logs as simple as possible. If there is meaningful data to add so be it. That said, I’m not sure that this change meets that bar. That said, I’m still concerned that the caller/callee division seems inside out. But it’s Sunday so…

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

lse { output()->print_cr("Explicit GC is disabled, no GC has been performed."); } Kind regards, Kirk Pepperdine On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga wrote: > Hi all, > > GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is >

Re: Logging JEP

Hi Fredrik, More comments inlined. Regards, Kirk >> My primary objection with the current specification is that the JEP is both over-reaching and restrictive. It suggest taxonomy a closed hierarchical taxonomy instead of a more open and flexible arrangement. The JEP overr

Re: Logging JEP

Hi Fredrik, comments below… Regards, Kirk >> >> My primary objection with the current specification is that the JEP is both >> over-reaching and restrictive. It suggest taxonomy a closed hierarchical >> taxonomy instead of a more open and flexible arrangement. The JEP >> overreaches in that

Re: Need comments on JEP-158: Unified JVM Logging

formalized logging interface to it though it’s something being discussed/thought about as we speak. https://github.com/peter-lawrey/Java-Chronicle. I’m not suggesting you take this implementation but there might be things to learn from it as this spec is being strengthened. Kind regards, Kirk

Re: Need comments on JEP-158: Unified JVM Logging

e had been forced to use leak into the JVM. Lets reconsider this JEP in it’s current form before moving to an implementation. Kind regards, Kirk Pepperdine On May 17, 2014, at 9:47 AM, Chris Newland wrote: > Hi Fredrik, > > The discussion I had with David Holmes and John Rose on ho

Re: RFR: 7164841: Improvements to the GC log file rotation

> Append vs clobber: with or without rotation, -Xloggc always clobbers the last > log. That's why people want a time stamp or pid in the gc file name, IMHO. My client just clobbered his log files yet... I'd still *not* want the time stamp because this can potentially accidentally fill producti

Re: RFR: 7164841: Improvements to the GC log file rotation

On 2013-08-27, at 10:01 AM, Bengt Rutisson wrote: > > Yumin, > > On 8/26/13 7:01 PM, Yumin Qi wrote: >> Bengt, >> >> Thanks for your comments. >> Yes, as you said, the purpose of rotating logs is primarily targeted for >> saving disk space. This bug is supplying customers another option t

Re: [PATCH] EnableTracing: output from multiple threads may be mixed together

irk, > > I'm not quite clear what "the other mixed up log files" means, since when > using EnableTracing the output uses stdout by default. > > > Regards, > Yunda > ________ > From: Kirk Pepperdine [k...@kodewerk.com] >

Re: [PATCH] EnableTracing: output from multiple threads may be mixed together

What effect with this have on the other mixed up log files? Regards, Kirk On 2013-05-02, at 2:57 PM, Staffan Larsen wrote: > Looks good. (not a reviewer) > > /Staffan > > On 2 maj 2013, at 05:07, 云达(Yunda) wrote: > >> Could anyone review this for me, please? >> >> Regards, >> Yunda >> >

Re: JEP 158: Unified JVM logging

Hi Staffan, Thanks for the response. You call it levels, I call is at hierarchy. I'm happy to change to the work levels. On 2012-08-17, at 10:20 PM, Staffan Larsen wrote: > > On 15 aug 2012, at 16:19, Dmitry Samersoff > wrote: > >> On 2012-08-15 12:44, Kirk Pepper

Re: JEP 158: Unified JVM logging

On 2012-08-15, at 3:28 PM, Dmitry Samersoff wrote: > Kirk, > > On 2012-08-15 12:56, Kirk Pepperdine wrote: >> I should have added that Neal Ford has an excellent talk on taxonomy systems >> and tags vs. hierarchies. >> It includes a bit on the 5 kingdoms that a

Re: JEP 158: Unified JVM logging

On 2012-08-15, at 11:29 AM, Dmitry Samersoff wrote: > Kirk, > > Thank you. I'm downloading it. > > PS: > Tags vs hierarchy discussion is as old as taxonomy it self. which is why I'm surprised we're here ;-) Kirk

Re: JEP 158: Unified JVM logging

that it >> doesn't fix the problems that exist in current logging frameworks, >> it only mimics them. > >> http://openjdk.java.net/jeps/158 > > Any comments is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility &g

Re: JEP 158: Unified JVM logging

nk that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: >> Hi Yasumasa, >> >> I'm not sure that log file rotation is a part of this JEP. >> However I do have very serious concer

Re: JEP 158: Unified JVM logging

ts is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: >> Hi Yasumasa, >> >> I'm not sure that log file rotation is a part of thi

Re: 7090324: gclog rotation via external tool

Hi Yasumasa, I'm not sure that log file rotation is a part of this JEP. However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. Regards, Kirk On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote:

Re: JEP 158

ee what the >> serviceability team thinks since they are the ones who will actually >> implement this in the end. >> >> Another solution that I don't really like but guess is easier to implement >> is to add the current verbose flag to the actual message so that t

Re: JEP 158

> >>> >>> I understand what you want and I see that the logging level won't help us >>> get there. I don't agree that the logging we have today can't fit nicely >>> into a hierarchical scheme though, it just needs to be more fine grained to >>> achieve what you want. >> >> I think to do this

Re: JEP 158

tenuring. Or >> >> -Xverbose:gc.tenuring >> >> that could be equal to what that flag prints today. Let's see what the >> serviceability team thinks since they are the ones who will actually >> implement this in the end. >> >> Another solut

Re: JEP 158

e a good taxonomy for logging categories and instead of over-reaching and forcing one on everybody, why not come to a specification that would allow groups to define their own. So again, I ask the question, what would the specification look like with levels taken out. Regards, Kirk > /Jespe

Re: JEP 158

Hi Staffan, > Thanks for the feedback! > > It is going to be hard to find the right balance between a system that > provides great power and one that is simple to use and to implement. In > general, I will lean more towards making it simple, but I want to make sure > we cover the major use ca