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

Aleksey Shipilev shade at redhat.com
Fri Dec 1 19:05:50 UTC 2017


On 12/01/2017 05:35 PM, Aleksey Shipilev wrote:
> 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)

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list