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

Thu Aug 23 19:55:49 UTC 2018

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
> 