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

[Roman Kennke]

>>>>> Hi Erik,
>>>>> thanks for reviewing!
>>>>>
>>>>>> 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.
>>>>> We do need to avoid read-barriers on those paths. The problem is that
>>>>> during full-GC we temporarily don't have the fwd-ptr available (it's a
>>>>> sliding mark-compact algorithm). However, we can work around this by
>>>>> not
>>>>> using the base+offset variants like in the patch. However, this
>>>>> seems to
>>>>> make the Access API unhappy at compile-time when using
>>>>> ON_UNKNOWN_OOP_REF. Can you check this? I've no clue where to look.
>>>> The reason is that wherever ON_UNKNOWN_OOP_REF is used, the backend
>>>> needs to be able to determine the exact strength. And to do that, the
>>>> backend needs to be able to determine of this is a referent field. And
>>>> to do that, it needs a base pointer.
>>>>
>>>> I'm not 100% sure what I think is a good solution to this. I wonder if
>>>> along the lines of introducing these resolve for read/write decorators
>>>> (which it looks like we will be needing anyway), there could be a do not
>>>> resolve decorator that could be passed in to determining how to resolve
>>>> the access. Default for stores could be ACCESS_WRITE, for loads
>>>> ACCESS_READ, for atomics ACCESS_READ | ACCESS_WRITE, and explicitly
>>>> setting ACCESS_NONE meaning don't resolve this one. Maybe the prefix
>>>> ought to be RESOLVE_READ / RESOLVE_WRITE / RESOLVE_NONE instead though
>>>> to be more specific.
>>> We are in instanceRefKlass, and we should be able to determine the
>>> reference strength statically, and pass in the correct ON_XXX_OOP_REF
>>> decorator, right? E.g. via InstanceKlass::reference_type() ? Or would
>>> that not work?
>>
>> That should probably do the trick, yes.
> 
> not 100% sure this is the correct ReferenceType -> decorators mapping?
> 
> Incremental:
> http://cr.openjdk.java.net/~rkennke/JDK-8206457/webrev.02.diff/
> Full patch:
> http://cr.openjdk.java.net/~rkennke/JDK-8206457/webrev.02/
> 

Ping?

Thanks, Roman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180801/53dda3fc/signature.asc>