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