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

Roman Kennke rkennke at redhat.com
Wed Sep 18 14:00:06 UTC 2019

>> 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")                   \


Incremental diff:

Ok now?


More information about the hotspot-gc-dev mailing list