RFR: enqueue barrier + some other things

[Roman Kennke]

Am 20.06.2018 um 13:44 schrieb Roland Westrelin:
> 
>> In test_evacuation_in_progress() you are not reusing the gc_state load
>> from the test_heap_stable() test. I tried doing this, but got a crash.
>> Would C2 common up the 2 loads anyway? This seems useful.
> 
> The wb and enqueue barriers are 2 unrelated things by the time expansion
> happens. -XX:+ShenandoahCommonGCStateLoads would do that.

What I mean is this. I believe we currently do:

if (load(gc_state) != 0) { // Heap-stable
  if (load(gc_state) & FLAGS != 0) // evac-in-progress
    wb(..)
  }
}

Is that right? (Are we doing this to possibly common with later
equivalent heap-stable-tests, even if the actual flags are different?)

We don't actually need to load the flag 2x:

flag = load(gc_state);
if (flag != 0) { // Heap-stable
  if (flag & FLAGS != 0) { // evac_in_progress
    wb(..);
  }
}


>> What I *really* would like to have is to avoid the whole
>> evac-in-progress check at all, and only emit heap-stable-test for
>> traversal, for both WBs and EQBs. Would that be possible? As follow-up?
>> I tried to hack it by short-circuiting test_evacuation_in_progress after
>> the null-check, but it did not work (of course. it's C2 ;-) ).
> 
> Sure. What would be the flag that triggers that?
> ShenandoahStoreValEnqueueBarrier?
> 
> Roland.

Also, if we do that, we'd emit, for each store, something like this:

if (heap_stable()) {
  p' = wb(p); // write_barrier on target object
}
if (heap_stable()) {
  v' = wb(v); // storeval_barrier on value
}
if (heap_stable()) {
  enqueue(v'); // EQ barrier on value
}
p'.field = v'

We *are* grouping back-to-back heap-stable checks, do we?

if (heap_stable()) {
  p' = wb(p); // write_barrier on target object
  v' = wb(v); // storeval_barrier on value
  enqueue(v'); // EQ barrier on value
}
p'.field = v'

Roman