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

[Ioi Lam]

Hi Ralf,

We are usually pretty picky about adding new features into the JVM. This 
seems to be an edge case (where your environment has more RAM than 
disk). I think it would be better to handle this outside of the JVM 
(using a named pipe and and external program such as the parallel gzip 
"pigz") to limit the maintenance overhead of the JVM.

This would also have the benefit that you can do it with almost no local 
storage -- you can read from the named pipe, optionally compress the 
data, and send that over the network.

Thanks
- Ioi

On 2/18/20 1:11 PM, serguei.spitsyn at oracle.com wrote:
> 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
>>
>