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.lindenma...@sap.com> Sent: Friday, 5 June 2020 18:02 To: Schmelter, Ralf <ralf.schmel...@sap.com>; Langer, Christoph <christoph.lan...@sap.com> Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net runtime <hotspot-runtime-...@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.
