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

[David Holmes]

On 18/03/2020 4:39 pm, Schmelter, Ralf wrote:
> 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.

All of which is happening via VM_HeapDumper::doit().

Got it.

Thanks,
David


> 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
> 
> -----
> 
>