RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

[Schmelter, Ralf]

Hi David,

> However I'm not clear how this solves  the problem of destroying
> the monitor while it can still be being accessed - is the dumping
> occurring at a safepoint in the WorkGang threads?

Because when the run_task() method returns, I can be sure none
of the work gang threads still use the mutex. They have to exit the
thread_loop() method to finish the task. And by exiting the method
they have released the mutex.

Best regards,
Ralf






From: David Holmes <david.holmes at oracle.com>

Sent: Wednesday, March 18, 2020 6:11 AM

To: Schmelter, Ralf <ralf.schmelter at sap.com>; Ioi Lam <ioi.lam at oracle.com>; Langer, Christoph <christoph.langer at sap.com>; Yasumasa Suenaga <suenaga at oss.nttdata.com>; serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>; hotspot-runtime-dev at openjdk.java.net
 runtime <hotspot-runtime-dev at openjdk.java.net>

Cc: serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>

Subject: Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

 


Hi Ralf,



On 13/03/2020 9:43 pm, Schmelter, Ralf wrote:

> Hi,

> 

> I have updated the webrev: 
http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.1/

> 

> It has the following significant changes:

> 

> - The jcmd now uses two separate flags. The -gz flag is now a boolean flag which toggles the compression  on/off. And the new -gz-level flag can be used to change the compression level. If tried to change the jlong flag coding to allow the old behavior (only
 one flag, which acts both as a boolean flag and a jlong flag), but decided against it, since it changes the semantic of a jlong flag. And I don't expect the -gz-level flag to be used all that much.

> 

> - I no longer use my own threads. Instead I use the WorkGang returned from CollectedHeap:: get_safepoint_workers(). This works fine, apart from Shenandoah GC, which runs into assertions when calling the CollectedHeap::object_iterate() method from a worker
 thread. I'm not sure if the assertion is too strong, but since the GC is currently experimental, I switch back to single threading in this case (as would be the case for serial GC or epsilon GC). Using the worker threads removes the problems the original code
 had regarding destruction of the monitor used.



I'm glad to see you are no longer using your own threads, and I 

apologise that I have not yet been able to look further into the thread 

lifecycle issues you encountered. However I'm not clear how this solves 

the problem of destroying the monitor while it can still be being 

accessed - is the dumping occurring at a safepoint in the WorkGang threads?



Thanks,

David

-----