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