RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v9]
Lin Zang
lzang at openjdk.java.net
Mon Nov 2 15:36:59 UTC 2020
On Fri, 30 Oct 2020 19:15:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'upstream/master' into jmap-par
>> - Merge remote-tracking branch 'upstream/master' into jmap-par
>> - update the return type of iterable_blocks to size_t
>> - cast iterable_blocks to int in claim_and_get_block()
>> - fix constant coding style and do code refine
>> - Refine HeapBlockClaimer implementation
>> - 8252103: Parallel heap inspection for ParallelScavengeHeap
>>
>> - Parallel heap iteration support for PSS
>> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103
>
> src/hotspot/share/gc/parallel/psOldGen.cpp line 191:
>
>> 189: */
>> 190: void PSOldGen::block_iterate(ObjectClosure* cl, uint block_index) {
>> 191: MutableSpace *space = object_space();
>
> Similar to `object_iterate()` this method should be implemented in the underlying `MutableSpace`, not in `PSOldGen` and just forward to the `MutableSpace` here. While the current design may be debatable, we should adhere to it in new code.
Hi @tschatzl,
IMHO, the block_iterate() uses PSOldGen's start_array() to identify the object in the block, and without this kind of mechanism, it may not easy to devide Mutablespace into blocks and iterate objects in those blocks, so I think it maybe better to leave it here only for PSOldGen. what do you think?
Thanks,
Lin
-------------
PR: https://git.openjdk.java.net/jdk/pull/25
More information about the hotspot-gc-dev
mailing list