Another question regarding Thread dumps (original) (raw)
David Holmes david.holmes at oracle.com
Tue Mar 13 04:36:05 UTC 2018
- Previous message: Another question regarding Thread dumps
- Next message: Another question regarding Thread dumps
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: VMPrintThreads, VMPrintJNI and VMFindDeadlocks. 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
- Previous message: Another question regarding Thread dumps
- Next message: Another question regarding Thread dumps
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]