RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop() must use obj+offset in HeapAccess call

[Roman Kennke]

Mach5 is not clean (see below). Can someone with access please have a look?

Thanks, Roman


Build Details: 2018-04-12-1133048.roman.source
0 Failed Tests
Mach5 Tasks Results Summary

    PASSED: 60
    UNABLE_TO_RUN: 21
    EXECUTED_WITH_FAILURE: 2
    NA: 0
    KILLED: 0
    FAILED: 0
    Build

        2 Not run
            build_jdk_windows-windows-x64-windows-x64-build-10 error
while building, return value: 2
            build_jdk_windows-windows-x64-debug-windows-x64-build-11
error while building, return value: 2

    Test

        21 Not run

tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
Dependency task failed: YLFraZAoY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
Dependency task failed: YLFraZApY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-windows-x64-debug-61
Dependency task failed: YLFraZApY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_gc_closed-windows-x64-debug-64
Dependency task failed: YLFraZApY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_runtime-windows-x64-debug-67
Dependency task failed: YLFraZApY
            jdk_closed_test_jdk_tier1-windows-x64-77 Dependency task
failed: YLFraZAoY

tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-16
Dependency task failed: YLFraZAoY

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-25
Dependency task failed: YLFraZApY

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-28
Dependency task failed: YLFraZApY

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-31
Dependency task failed: YLFraZApY


> Thanks Erik & Aleksey for reviewing!
> 
> I just submitted the change for testing.
> 
> I do need to wait 24h from posting RFR, do I? That means it's gonna miss
> the integration and need to wait till next week. Or do you think it's
> safe to go ahead and push it, given that submit repo comes back green?
> 
> Thanks, Roman
> 
>> Looks good. Would be great to stick that IN_HEAP_ARRAY decorator in the
>> mix as well, so that when we decide runtime code should use precise
>> marking for arrays, we catch this case. I don't need another webrev for
>> that.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-11 21:49, Roman Kennke wrote:
>>> Please review the following little change.
>>>
>>>
>>> objArrayOopDesc::atomic_compare_exchange_oop() currently computes and
>>> uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
>>> should use the object+offset variant because it's accessing the heap and
>>> GC might need to resolve the target object (e.g. Shenandoah).
>>>
>>> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/
>>>
>>> Testing: hotspot-tier1
>>>
>>>
>>> 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/20180412/f71d3502/signature.asc>