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

[Roman Kennke]

Nevermind, my bad. I pushed the wrong patch.

Roman


> I pushed this to jdk/submit but it came back with failure. Can somebody
> with access let me know what's up?
> 
> Thanks, Roman
> 
> 
> Build Details: 2018-08-23-1902021.roman.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
> 
>     EXECUTED_WITH_FAILURE: 14
>     FAILED: 0
>     NA: 0
>     PASSED: 0
>     KILLED: 0
>     UNABLE_TO_RUN: 61
>     Build
> 
>         18 Not run
>             linux-x64-linux-x64-build-0 error while building, return
> value: 2
>             linux-x64-debug-linux-x64-build-1 error while building,
> return value: 2
>             linux-x64-install-linux-x64-build-14 Dependency task failed:
> mach5...180823-1905-35871-linux-x64-linux-x64-build-0
>             linux-x64-open-linux-x64-build-2 error while building,
> return value: 2
>             linux-x64-open-debug-linux-x64-build-3 error while building,
> return value: 2
>             macosx-x64-macosx-x64-build-4 error while building, return
> value: 2
>             macosx-x64-debug-macosx-x64-build-5 error while building,
> return value: 2
>             macosx-x64-install-macosx-x64-build-15 Dependency task
> failed: mach5...0823-1905-35871-macosx-x64-macosx-x64-build-4
>             macosx-x64-open-macosx-x64-build-6 error while building,
> return value: 2
>             macosx-x64-open-debug-macosx-x64-build-7 error while
> building, return value: 2
>             See all 18...
> 
>     Test
> 
>         57 Not run
> 
> tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-linux-x64-18
> Dependency task failed:
> mach5...180823-1905-35871-linux-x64-linux-x64-build-0
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-linux-x64-debug-24
> Dependency task failed:
> mach5...-1905-35871-linux-x64-debug-linux-x64-build-1
> 
> tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-macosx-x64-19
> Dependency task failed:
> mach5...0823-1905-35871-macosx-x64-macosx-x64-build-4
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-macosx-x64-debug-25
> Dependency task failed:
> mach5...905-35871-macosx-x64-debug-macosx-x64-build-5
> 
> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-57
> Dependency task failed:
> mach5...35871-solaris-sparcv9-solaris-sparcv9-build-8
> 
> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-58
> Dependency task failed:
> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
> 
> tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-20
> Dependency task failed: JReWJbBoCd
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-26
> Dependency task failed: JReWJbBpCd
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-linux-x64-debug-27
> Dependency task failed:
> mach5...-1905-35871-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-macosx-x64-debug-28
> Dependency task failed:
> mach5...905-35871-macosx-x64-debug-macosx-x64-build-5
>             See all 57...
> 
> 
> 
> 
>> Hi Roman,
>>
>> Yes, looks good.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-08-09 10:10, Roman Kennke wrote:
>>>
>>>>>>>>> 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?
>>>
>>> Erik, is this good now?
>>>
>>> Thanks, Roman
>>
>