RFR/RFC: Rework shared bool/enum flags with proper types and synchronization

Roman Kennke rkennke at redhat.com
Fri Dec 1 19:19:11 UTC 2017



>> http://cr.openjdk.java.net/~shade/shenandoah/refactor-shared-flags/webrev.01/
>>
>> Current shared flag handling is messy and ad-hoc: we use char, unsigned int, volatile jbyte, etc,
>> sometimes inconsistently updating the fields, etc. This fix commons operations on shared flags with
>> a handy abstraction. Apart from doing the synchronization right, it also pads out the fields to
>> eliminate false sharing against other heavily-mutated fields, since most of these fields are used on
>> critical path checks.
>>
>> Current hotspot_gc_shenandoah testing fails some tests with:
>>    http://cr.openjdk.java.net/~shade/shenandoah/after-flag-partial-fail-hs_err.log
>>
>> ...which I believe is the pre-existing bug?
> 
> Gaaaah! I understand now, this is C1 bug, fixed by:
> 
>   -    __ move(new LIR_Address(mark_in_prog_addr, T_CHAR), mark_in_prog);
>   +    __ move(new LIR_Address(mark_in_prog_addr, T_BYTE), mark_in_prog);
> 
> Looked at other usages of the affected flags, and this seems to be the only case like this.
> 
> New version:
>   http://cr.openjdk.java.net/~shade/shenandoah/refactor-shared-flags/webrev.03/
> 
> This now passes hotspot_gc_shenandoah (fastdebug)

Good to go then!

Roman


More information about the shenandoah-dev mailing list