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

[Roman Kennke]

Am 01.12.2017 um 17:35 schrieb Aleksey Shipilev:
> 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?
> 
> Thanks,
> -Aleksey
> 
> 

This is very good stuff!

Some comments:
- some _addr() methods are defined in shenandoahHeap.cpp some in 
shenandoahHeap.inline.hpp. I think it's good enough to define them all 
in shenandoahHeap.cpp
- Likewise, all state accessors should probably follow the same pattern 
(either with is_ or without, but consistent) and all go into 
shenandoahHeap.inline.hpp
- ShenandoahSharedEnumFlag::cmpxchg() takes expected and new in 
different order than Atomic::cmpxchg(). I find this surprising.
- In ShenandoahSharedFlag, declare constants or enum for 0 and 1 as 
FALSE and TRUE?

Couldn't find what would cause the new failure though...

Roman