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.spit...@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.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
