RFR (S) 8224522: Shenandoah should apply barriers on deoptimization

[Roman Kennke]

It looks good to me.

It probably warrants a proper GC interface. But let's fix the bug first.

I was thinking what kind of GC interface would be appropriate. It really
is a load from an off-heap address plus a load-barrier, so maybe
NativeAccess<>::load() with appropriate decorators would cover it? Let's
discuss this in a follow-up though.

Thanks,
Roman

> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8224522
> 
> Fix:
>   http://cr.openjdk.java.net/~shade/8224522/webrev.01/
> 
> Shenandoah, like ZGC, needs to make sure that the oops that are in deoptimized frames are passed
> through the barriers. Otherwise deoptimization might sneak bad oops into into Java heap. This is a
> very rare, hard to replicate, but still fatal error. The fix copies what ZGC code already does.
> Since Shenandoah also runs with compressed oops, we need to take care of "narrowoop" path as well. I
> made the oop/narrowoop as close as possible style-wise.
> 
> Testing: hotspot_gc_shenandoah; build with -shenandoahgc; jdk-submit (running)
>