RFR: 8210330: Make CLD claiming allow multiple claim bits

[Erik Österlund]

Hi Coleen,

Thank you for the review.

Per wanted the following naming change: claim_value -> claim, claim() -> 
try_claim(). And the strong_claim to be 3 instead of 1, so that one does 
not accidentally set the wrong value when using it from ZGC (strong 
claimed always implies final claimed too). Hope you are also okay with that.

Incremental:
http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00_01/

Full:
http://cr.openjdk.java.net/~eosterlund/8210330/webrev.01/

Thanks,
/Erik

On 2018-09-04 14:29, coleen.phillimore at oracle.com wrote:
>
> This change looks good to me.
> Coleen
>
> On 9/4/18 4:42 AM, Erik Österlund wrote:
>> Hi,
>>
>> Today, the claim value of a CLD is logically a boolean, stored as an 
>> int. Either a CLD is claimed, or not claimed. This is used by the GC 
>> to see if oops_do can be skipped on the CLD, because its handles have 
>> already been marked.
>> With ZGC supporting concurrent class unloading, the CLD holder can be 
>> marked finalizably reachable first, and afterwards strongly 
>> reachable. This requires 2 claim bits in the CLD: one for claiming it 
>> for strong marking of the oop handles, and one for finalizable marking.
>>
>> Rather than making a separate mechanism for ZGC only, I would like to 
>> use these shared claim bits. I think this is a fascility that anyone 
>> who has concurrent reference processing and concurrent class 
>> unloading will need, it just happens to be that ZGC is the first GC 
>> to do that in hotspot. I also have the hypothesis that this can be 
>> beneficial for other uses such as the JFR leak profiler, which can 
>> have its own claim bits, instead of clearing the claim bit, doing its 
>> thing, and then restoring the claim bit to what it was before.
>>
>> As part of this change, I changed the "must_claim" boolean that is 
>> passed around to instead take an int for the desired claim value, and 
>> made it explicit and not implicit.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8210330
>>
>> Thanks,
>> /Erik
>