Another question regarding Thread dumps

Langer, Christoph christoph.langer at
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.

Best regards

> -----Original Message-----
> From: David Holmes [mailto:david.holmes at]
> Sent: Dienstag, 13. März 2018 05:36
> To: Langer, Christoph <christoph.langer at>; serviceability-
> dev at; Hotspot dev runtime <hotspot-runtime-
> dev at>
> 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.
> Cheers,
> David
> > Thanks
> > Christoph
> >

More information about the hotspot-runtime-dev mailing list