Hi Serguei, the use case is being able to get a heap dump from big Java servers. These usually run on machines with a lot of memory and CPUs, but not much disk space (which they don't need apart from some trace files and the server code itself). And if we can get the customer to mount some NFS file system on the machine, it is usually slow. So writing only a third or forth of the data is a big win.
Doing the compression outside the VM would either depend on the hprof file written first (so we would still need the disk space) or have another channel to dump the data (e.g. via socket). But this would add complexity too and needs an external program. I've compiled 2 release versions on Windows with and without my change. The change adds 14.5k to the server.dll (which is 10.4 MB). Not sure if this is considered acceptable. Best regards, Ralf -----Original Message----- From: serguei.spit...@oracle.com <serguei.spit...@oracle.com> Sent: Dienstag, 11. Februar 2020 20:49 To: Schmelter, Ralf <ralf.schmel...@sap.com>; Yasumasa Suenaga <suen...@oss.nttdata.com>; OpenJDK Serviceability <serviceability-dev@openjdk.java.net> Cc: yasue...@gmail.com Subject: Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump Ralf, I see this feature adds a lot of code. In fact, I'm not sure, it is worth to add this kind of complexity (including new compressing threads) into the VM implementation. What is a real use case behind it? Could this compressing be done separately from VM implementation? Thanks, Serguei
