RFR: Re-do streamlining of read-barriers in Access API, and fix call paths that might lead to read-barriers via oop_iterate()

[Aleksey Shipilev]

On 07/06/2018 02:04 PM, Roman Kennke wrote:
> Thanks. Testing turned out another code path that requires raw access
> (and needs upstreaming). This is obviously bogus to do barrier'd access:
> 
> diff --git a/src/hotspot/share/oops/instanceRefKlass.inline.hpp
> b/src/hotspot/share/oops/instanceRefKlass.inline.hpp
> --- a/src/hotspot/share/oops/instanceRefKlass.inline.hpp
> +++ b/src/hotspot/share/oops/instanceRefKlass.inline.hpp
> @@ -184,9 +184,9 @@
> 
>    log_develop_trace(gc, ref)("InstanceRefKlass %s for obj " PTR_FORMAT,
> s, p2i(obj));
>    log_develop_trace(gc, ref)("     referent_addr/* " PTR_FORMAT " / "
> PTR_FORMAT,
> -      p2i(referent_addr), p2i((oop)HeapAccess<ON_UNKNOWN_OOP_REF |
> AS_NO_KEEPALIVE>::oop_load_at(obj,
> java_lang_ref_Reference::referent_offset)));
> +      p2i(referent_addr), p2i((oop)RawAccess<>::oop_load(referent_addr)));
>    log_develop_trace(gc, ref)("     discovered_addr/* " PTR_FORMAT " / "
> PTR_FORMAT,
> -      p2i(discovered_addr),
> p2i((oop)HeapAccess<AS_NO_KEEPALIVE>::oop_load(discovered_addr)));
> +      p2i(discovered_addr),
> p2i((oop)RawAccess<>::oop_load(discovered_addr)));
>  }
>  #endif
> 
> 
> Ok to include that in the patch?

OK.

>>> Testing: tier3_gc_shenandoah
>>
>> This seems to improve Serial:
>>   before: 19535.551 ± 225.129  ops/s
>>    after: 20120.271 ± 103.193  ops/s
> 
> Very nice. So we finally found a benchmark that is performance sensitive
> on runtime barriers? I always used to argue that runtime barriers would
> likely not show up anywhere...

Apparently. Serial is special, because Java serialization uses String.intern as the matter of
course, and that goes into VM for doing the actual work.


-Aleksey