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
-----
- The reported number of bytes is now the one written to disk.
Best regards,
Ralf
-----Original Message-----
From: Ioi Lam <ioi....@oracle.com>
Sent: Dienstag, 25. Februar 2020 18:03
To: Langer, Christoph <christoph.lan...@sap.com>; Schmelter, Ralf <ralf.schmel...@sap.com>;
Yasumasa Suenaga <suen...@oss.nttdata.com>; serguei.spit...@oracle.com;
hotspot-runtime-...@openjdk.java.net runtime <hotspot-runtime-...@openjdk.java.net>
Cc: serviceability-dev@openjdk.java.net
Subject: Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
Hi Christoph,
This sounds fair. I will remove my objection :-)
Thanks
- Ioi
