RFR: JDK-8206457: Code paths from oop_iterate() must use barrier-free access

[Erik Österlund]

Hi Roman,

In instanceRefKlass.inline.hpp:

Are these changes to logging required for Shenandoah not to crash? It 
appears to me that for ZGC, it would print the wrong addresses if 
barriers were not used. That's why I wonder if this is a strict 
requirement or not for Shenandoah to work.

In oops/oop.cpp:
Rather than changing the metadata accessors to always assume raw 
accesses are enough for all metadata accesses, I would prefer to have 
explicit metadata_field_raw accessors instead where we expect this (even 
if that turns out to be always).

Thanks,
/Erik

On 2018-07-06 16:46, Roman Kennke wrote:
>   We have several code paths going out from oop_iterate() methods that
> lead to GC barriers. This is not only inefficient but outright wrong.
> oop_iterate() is normally used by GC and GC need to see the raw stuff,
> not some resolved objects. In Shenandoah's full-GC it's fatal to attempt
> to read objects's forwarding pointers, because it's temporarily pointing
> to nowhere land.
>
> I propose to selectively use _raw() variants of the various accessors
> that are used on oop_iterate() paths. This means to introduce an
> oopDesc::int_field_raw(). I also propose to change metadata_field()
> accessors to always use raw access wholesale. This is only used to load
> the Klass* field, which is immutable and thus doesn't require barriers.
>
> The log_* statements in instanceRefKlass.inline.hpp surely don't need
> barriers. I turned them into raw accessors as well.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8206457?filter=-1
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8206457/webrev.00/
>
> Test: passes hotspot-tier1 here.
>
> Can I please get review?
>
> Roman
>