[RFR]8215623: Add incremental dump for jmap histo

[Hohensee, Paul]

As for 8215622, update the copyright dates to 2019 please, since this won’t get pushed until then.

You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. “incremental” could become “chunkcount=<n>”, where <n> defaults to infinity (max value of size_t).

I’d not use a default file name when “chunkcount” is specified, I’d just write to whatever the output stream is. “chunkcount” is then independent of “file”.

I’d add another histo argument for the maximum file size, call it “maxfilesize”, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t).

If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original “incremental” argument as syntactic sugar for “chunkcount=8k,maxfilesize=5m”.

INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as “const int” within RecordInstanceClosure.

Thanks,

Paul

From: serviceability-dev <serviceability-dev-bounces at openjdk.java.net> on behalf of 臧琳 <zanglin5 at jd.com>
Date: Thursday, December 20, 2018 at 11:13 PM
To: "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>
Subject: [RFR]8215623: Add incremental dump for jmap histo

Hi All,
       May I ask your help to review this patch for enhance jmap –histo.
It adds the “incremental” arguments that allow jmap –histo to incrementally save the intermediate data into a temp file.
The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small.
This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large.

This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535.

Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8215623

Thanks.

BRs,
Lin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181231/a9cce788/attachment.html>