Another question regarding Thread dumps
christoph.langer at sap.com
Wed Mar 14 16:04:27 UTC 2018
Thanks David for your comments.
I decided that I adapt our coding to the one currently used in OpenJDK. I'm not aware of any issues either way, so I prefer to have common coding.
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 13. März 2018 05:36
> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> dev at openjdk.java.net; Hotspot dev runtime <hotspot-runtime-
> dev at openjdk.java.net>
> Subject: Re: Another question regarding Thread dumps
> On 13/03/2018 1:41 AM, Langer, Christoph wrote:
> > Hi,
> > I have another question regarding thread dumping code.
> > At the places where thread dumps get generated (attachListener.cpp,
> diagnosticCommand.cpp, os.cpp), there's always a series of 3 VM operations:
> VM_PrintThreads, VM_PrintJNI and VM_FindDeadlocks. I'm wondering if it
> would make sense to do this altogether in one VM operation? Then probably
> the picture could be more consistent. However, I can imagine the risk that
> the safepoint takes too long. Are there other pros and cons I'm missing?
> > I'm asking because in our JVM codebase I can find places where some of
> these VM ops had been combined and I'm wondering what might be the
> reasoning behind that and whether it makes sense to revert to the OpenJDK
> way of doing things or whether the changes are smart and even worth
> contributing. What do you think?
> VM_FindDeadlocks is also used stand-alone in jmm_FindDeadlockedThreads.
> I think they are logically three distinct operations. And one really
> long safepoint could be quite problematic. You'd need extensive
> real-life benchmarking of the impact on real apps that use active
> monitoring before being able to make this change. This seems to me like
> a "if it ain't broke ..." situation.
> > Thanks
> > Christoph
More information about the hotspot-runtime-dev