[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: Another question regarding Thread dumps
From:       "Langer, Christoph" <christoph.langer () sap ! com>
Date:       2018-03-14 16:04:27
Message-ID: 6e2ff19f042d4b1083847a33faad23f7 () sap ! com
[Download RAW message or body]

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.holmes@oracle.com]
> Sent: Dienstag, 13. März 2018 05:36
> To: Langer, Christoph <christoph.langer@sap.com>; serviceability-
> dev@openjdk.java.net; Hotspot dev runtime <hotspot-runtime-
> dev@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
> > 


[prev in list] [next in list] [prev in thread] [next in thread]