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