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 Christoph > -----Original Message----- > From: David Holmes [mailto:david.hol...@oracle.com] > Sent: Dienstag, 13. März 2018 05:36 > To: Langer, Christoph <christoph.lan...@sap.com>; serviceability- > d...@openjdk.java.net; Hotspot dev runtime <hotspot-runtime- > d...@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. > > Cheers, > David > > > Thanks > > Christoph > >
