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

[Laurence Cable]

On 2/18/20 4:15 PM, Ioi Lam wrote:
> 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.
nice solution!
>
> 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
>>>
>>
>