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

[Lindenmaier, Goetz]

HI Ralf, 

Thanks for the info.
Looks good, in my eyes ready to be pushed.

Best regards,
  Goetz.

-----Original Message-----
From: Schmelter, Ralf <ralf.schmelter at sap.com> 
Sent: Montag, 8. Juni 2020 11:38
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph <christoph.langer at sap.com>
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net runtime <hotspot-runtime-dev at openjdk.java.net>; David Holmes <david.holmes at oracle.com>; serguei.spitsyn at oracle.com; Ioi Lam <ioi.lam at oracle.com>
Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Goetz,

> What kind of tests did you run?

The jdk submit repo, the JCK tests (apart from API) and the jtreg tests on Windows x86/64, MacOS X, linux on x86/64, ppcle, ppcbe, zarch and aarch64 and on AIX.

If there aren't any other concerns, I would like to commit this this change on Wednesday.  

Best regards,
Ralf

-----Original Message-----
From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com> 
Sent: Friday, 5 June 2020 18:02
To: Schmelter, Ralf <ralf.schmelter at sap.com>; Langer, Christoph <christoph.langer at sap.com>
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net runtime <hotspot-runtime-dev at openjdk.java.net>
Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Ralf, 

Thanks for the quick reply and all the fixes.
The changes to the workgroup are ok.
Reviewed.  (An incremental webrev would have helped ��)

What kind of tests did you run?

> Yes, the buffer is now smaller (1M) versus the original (8M). You need
> to be able to at least allocate one buffer or you get an error (this
> is handled in the CompressionBackend ctor). You then allocate
> additional buffers as needed (we want a new buffer, but there is no
> free one), until we have a buffer for every worker thread or until
> the allocation of the buffer failed. In this case some threads will
> be idle, since we cannot have a buffer for each thread.
Ok, that's what I thought. Thanks for the explanation.

> > Another question.
> > The basic dumping is done sequential, right? The comression 
> > is parallel. Is there a tradeoff in #of threads where
> > the compression is faster than writing?
> Yes. The compression and writing is done parallel. Depeding on
> the compression level and the speed of your harddrive, not all
> threads will be active all the time. But since we reuse the GC threads
> this should not matter. And the relative poor performance of
> deflate() ensures that at least 5 to 10 threads will probably always
> be active ;)
Ok, thanks.

Best regards,
  Goetz.