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