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

List:       openjdk-serviceability-dev
Subject:    Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
From:       David Holmes <david.holmes () oracle ! com>
Date:       2020-03-18 6:43:22
Message-ID: 05ae5818-f1b7-2e86-e4dd-c09ff240748e () oracle ! com
[Download RAW message or body]

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@oracle.com>
> 
> Sent: Wednesday, March 18, 2020 6:11 AM
> 
> To: Schmelter, Ralf <ralf.schmelter@sap.com>; Ioi Lam <ioi.lam@oracle.com>; Langer, \
> Christoph <christoph.langer@sap.com>; Yasumasa Suenaga <suenaga@oss.nttdata.com>; \
> serguei.spitsyn@oracle.com <serguei.spitsyn@oracle.com>; \
> hotspot-runtime-dev@openjdk.java.net runtime <hotspot-runtime-dev@openjdk.java.net>
> 
> Cc: serviceability-dev@openjdk.java.net <serviceability-dev@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
> 
> -----
> 
> 


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