RFR: 8252842: Extend jmap to support parallel heap dump [v20]
Lin Zang
lzang at openjdk.java.net
Mon Apr 26 12:31:34 UTC 2021
On Tue, 20 Apr 2021 22:20:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>>
>> - Merge branch 'master' into par-dump
>> - Merge branch 'master' into par-dump
>> - Typo fix
>> - remove parallel option and dumpheapext command
>> - Revert "hide the dumpheapext error message"
>>
>> This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.
>> - resize large object threshold
>> - Merge branch 'master' into par-dump
>> - Merge branch 'master' into par-dump
>> - code clean
>> - fix trailing white space issue
>> - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1
>
> src/hotspot/share/services/heapDumperCompression.cpp line 240:
>
>> 238: }
>> 239:
>> 240: void CompressionBackend::flush_buffer() {
>
> This method looks to be indentical to `CompressionBackend::deactivate()` except `CompressionBackend::deactivate()` does a couple more tasks at the end. Perhaps `CompressionBackend::deactivate()` should be calling this now.
The reason for dup of the code is that both method use the MonitorLocker, but with different scope. Do you think that it is better if I extract those common codes as a method that accept a MonitorLocker as an argument? Such as `flush_buffer_without_lock(MonitorLocker* lock)`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2261
More information about the serviceability-dev
mailing list