[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
From:       Ioi Lam <ioi.lam () oracle ! com>
Date:       2020-02-25 17:03:25
Message-ID: e8943a91-839b-3601-cc33-77f338aab96e () oracle ! com
[Download RAW message or body]

Hi Christoph,

This sounds fair. I will remove my objection :-)

Thanks
- Ioi

On 2/25/20 2:21 AM, Langer, Christoph wrote:
> Hi Ioi,
> 
> > Ralf and Christoph,
> > 
> > I agree that making it easy for the user is important, so dependency on
> > an external program like pgzip will be a hassle.
> Yes 😊
> 
> > How about implementing the compression in a Java program? Will something
> > like this be too much of a hassle?
> > 
> > jcmd $PID GC.dump -stdout | java -jar HeapDumpZipper.jar > heap.gz
> > 
> > This way, we can implement the exact compression algorithm as Ralf
> > described, without making it part of the VM. Writing it in Java probably
> > would be easier to maintain.
> > 
> > If it makes sense, we can include the Java code as part of the JDK, so
> > there's no need to ship a separate JAR file to the user.
> > 
> > jcmd $PID GC.dump -stdout | java jdk.internal.heapdump.Zipper >
> > heap.gz
> Well, we definitely would have to enhance hotspot and jcmd to be able to stream the \
> dump data out. And the Java code, doing the compression should also be internalized \
> to jcmd such that piping is not required. It's hard to say whether maintainability \
> will be easier when implementing these parts in Java. However, performance is \
> definitely a thing which has to be considered - I guess doing the zipping in \
> hotspot is better for that. And also the option to support the "heapdump on OOM" \
> scenarios would not be handled here. 
> Best regards
> Christoph
> 


[prev in list] [next in list] [prev in thread] [next in thread]