RFR: JDK-8231087: Shenandoah: Self-fixing references

[Roman Kennke]

>> Jira issue:
>> https://bugs.openjdk.java.net/browse/JDK-8231087
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8231087/webrev.00/
> 
> Looks cool.
> 
> We are still doing the full non-fixing LRB from assembler, because it is much harder to do there,
> or? And that version still does resolve-fwdptr path, so it does not call to slowpath all that often?

Correct. The register shuffling in interpreter to get the load-addr to 
the runtime call would be aweful, especially in x86_32. E.g. some loads 
override the base register of the load-addr, it would have to be lea'd 
and saved acrossed the load, plus we need an actual register for that, 
etc. Sorry, I forgot that in the original description.

> *) gc/shenandoah/shenandoahRuntime.(cpp|hpp)
> 
> I think your squashed patch misses this important follow-up:
>    https://hg.openjdk.java.net/shenandoah/jdk/rev/7175c0025de1
> 
> In other words, we should not extend SHR::load_reference_barrier_native without changing all the
> uses too, because it wrecks up calling convention when called from assembler.
> 

Ok, fixed.

> *) Should be diagnostic. Also, description: "Fix references with load reference barrier. Disabling
> this might degrade performance". (It would, because we remove the resolve-fwdptr parts from everywhere):
> 
>   395   experimental(bool, ShenandoahSelfFixing, true,                            \
>   396           "Load-reference-barrier also fixes references")                   \

Fixed.

Incremental diff:
http://cr.openjdk.java.net/~rkennke/JDK-8231087/webrev.01.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8231087/webrev.01/

Ok now?

Roman