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

[serguei.spitsyn at oracle.com]

Hi Ralf,

Thank you for the explanation.
I'm still not sure this justifies the complexity introduced with this fix.
But it would be nice to collect more opinions on this.

On 2/12/20 9:02 AM, Laurence Cable wrote:
>
>
> On 2/12/20 4:17 AM, Schmelter, Ralf wrote:
>> 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).
> or named pipe
>>   But this would add complexity too and needs an external program.
> agreed
>>
>> 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.

This is for the HotSpot Runtime team to decide if it is acceptable or not.
So, I've added the hotspot-runtime-dev to the list.

> but what is the performance impact of this?
>>
>> Best regards,
>> Ralf
>>
>> -----Original Message-----
>> From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
>> Sent: Dienstag, 11. Februar 2020 20:49
>> To: Schmelter, Ralf <ralf.schmelter at sap.com>; Yasumasa Suenaga 
>> <suenaga at oss.nttdata.com>; OpenJDK Serviceability 
>> <serviceability-dev at openjdk.java.net>
>> Cc: yasuenag at 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
>