RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v9]

Lin Zang lzang at openjdk.java.net
Mon Nov 2 16:03:03 UTC 2020

On Mon, 2 Nov 2020 13:10:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>>> Hi @tschatzl, Thanks for your reviewing. I think the biggest problem you mentioned is that the type of _claimed_index and old_gen()->iterable_blocks() is not match (conversion from unsigned to signed). As I cannot change _claim_index to be unsigned because it use -1 and -2 for identifing youngGen, do you think that changing "iterable_blocks()" to be a signed value is reasonable? and I will also change all these types to be 64bit signed value to avoid auto widening.
>> Yes, the signed/unsigned changes are the largest issue.
>> You could use the mentioned `ssize_t` as an automatically widening signed integer type. However you could also use `(size_t)-1/-2` (i.e. `MAX_SIZE_T/MAX_SIZE_T-1` or whatever they are called) as identifiers for young and survivor. There seems to be no difference in using either since the code only does direct comparisons.
>> This works because you can't have these values for regular old gen blocks (as block size is 1M, so the maximum value for a regular block is 2^(64-20) - you can STATIC_ASSERT that block size is big enough to not cover these special values btw).
>> Or alternatively, `(u)intptr_t` as its range is defined to cover all possible pointer values (which is what we care about) and might be the best fit.
>> I'm good with all of these options.
>> You could use the mentioned `ssize_t` as an automatically widening signed integer type. 
> I would prefer this alternative.

Dear @kstefanj and @tschatzl,
Thanks in advance for your review, I have updated a new commit that use ssize_t for _claimed_index in HeapBlockClaimer, and made conversion from "size_t" to "ssize_t" when block index of PSOldGen is used to calculate claimed index. Not sure whether this conversion is better. would you like to help review again?



PR: https://git.openjdk.java.net/jdk/pull/25

More information about the hotspot-gc-dev mailing list