RFR: JDK-8203157: Object equals abstraction for BarrierSetAssembler

Tue Jun 12 20:07:30 UTC 2018

Did you bring in ZGC into your branch?  After the integration, the infrastructure expects it to be there. This is not specific to the ZGC integration, but an infrastructure issue with any change that contains changes to both open code and Oracle internal parts.
/Jesper

> On 12 Jun 2018, at 21:38, Roman Kennke <rkennke at redhat.com> wrote:
> 
> I merged in updates from default branch, but it still fails. See below.
> 
> Are they any other known blockers?
> 
> Thanks, Roman
> 
> 
> 
> Build Details: 2018-06-12-1716282.roman.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
> 
>    PASSED: 55
>    KILLED: 0
>    FAILED: 0
>    UNABLE_TO_RUN: 18
>    EXECUTED_WITH_FAILURE: 2
>    NA: 0
>    Build
> 
>        3 Not run
>            build_jdk_linux-linux-x64-linux-x64-build-0 Error while
> running 'jib configure', return value: 1
>            build_jdk_linux-linux-x64-debug-linux-x64-build-1 Error
> while running 'jib configure', return value: 1
>            linux-x64-install-linux-x64-build-14 Dependency task failed:
> mach5...5-build_jdk_linux-linux-x64-linux-x64-build-0
> 
>    Test
> 
>        17 Not run
> 
> tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-linux-x64-18
> Dependency task failed:
> mach5...5-build_jdk_linux-linux-x64-linux-x64-build-0
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-linux-x64-debug-24
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-linux-x64-debug-27
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-linux-x64-debug-30
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_3-linux-x64-debug-33
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_not_xcomp-linux-x64-debug-36
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_1-linux-x64-debug-39
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_2-linux-x64-debug-42
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
> 
> tier1-product-jdk_open_test_hotspot_jtreg_tier1_gc_gcbasher-linux-x64-21
> Dependency task failed:
> mach5...5-build_jdk_linux-linux-x64-linux-x64-build-0
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_gcbasher-linux-x64-debug-45
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>            See all 17...
> 
> 
>> Hi,
>> 
>>  the issue is (or actually the fix) https://bugs.openjdk.java.net/brow
>> se/JDK-8204861 .
>> 
>> Thanks,
>>  Thomas
>> 
>> On Tue, 2018-06-12 at 14:59 +0200, Roman Kennke wrote:
>>> jdk/submit came back with unstable (see below). Can somebody with
>>> access
>>> look what's going on?
>>> 
>>> Thanks, Roman
>>> 
>>> Build Details: 2018-06-12-1147472.roman.source
>>> 0 Failed Tests
>>> Mach5 Tasks Results Summary
>>> 
>>>    PASSED: 62
>>>    KILLED: 0
>>>    FAILED: 0
>>>    UNABLE_TO_RUN: 11
>>>    EXECUTED_WITH_FAILURE: 2
>>>    NA: 0
>>>    Build
>>> 
>>>        2 Not run
>>>            build_jdk_linux-linux-x64-debug-linux-x64-build-1 error
>>> while building, return value: 2
>>>            build_jdk_linux-linux-x64-open-debug-linux-x64-build-3
>>> error
>>> while building, return value: 2
>>> 
>>>    Test
>>> 
>>>        11 Not run
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-linux-x64-debug-
>>> 24
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-linux-x64-
>>> debug-27
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-linux-x64-
>>> debug-30
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_3-linux-x64-
>>> debug-33
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_not_xcomp-
>>> linux-x64-debug-36
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_1-linux-x64-debug-39
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_2-linux-x64-debug-42
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_gcbasher-linux-x64-
>>> debug-45
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_gcold-linux-x64-
>>> debug-48
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>> 
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_runtime-linux-x64-
>>> debug-51
>>> Dependency task failed:
>>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>>            See all 11...
>>> 
>>> 
>>>> On 06/12/2018 10:23 AM, Roman Kennke wrote:
>>>>> Am 12.06.2018 um 11:11 schrieb Andrew Haley:
>>>>>> On 06/11/2018 08:17 PM, Roman Kennke wrote:
>>>>>>> Am 11.06.2018 um 19:11 schrieb Andrew Haley:
>>>>>>>> On 06/11/2018 04:56 PM, Andrew Haley wrote:
>>>>>>>>> On 06/08/2018 09:17 PM, Roman Kennke wrote:
>>>>>>>>>> Why is it better? And how would I do that? It sounds
>>>>>>>>>> like a fairly
>>>>>>>>>> complex undertaking for a special case. Notice that if
>>>>>>>>>> the oop doesn't
>>>>>>>>>> qualify as immediate operand (quite likely for an oop?)
>>>>>>>>>> it used to be
>>>>>>>>>> moved into rscratch1 anyway a few lines below.
>>>>>>>>> 
>>>>>>>>> Sorry for the slow reply.  I'm looking now.
>>>>>>>> 
>>>>>>>> OK.  The problem is that this is a very bad code smell:
>>>>>>>> 
>>>>>>>>      case T_ARRAY:
>>>>>>>>        jobject2reg(opr2->as_constant_ptr()->as_jobject(),
>>>>>>>> rscratch1);
>>>>>>>>        __ cmpoop(reg1, rscratch1);
>>>>>>>> 
>>>>>>>> I can't tell that this is correct.  rscratch1 is used by
>>>>>>>> assembler
>>>>>>>> macros, and I don't know if some other GC (e.g. ZGC) might
>>>>>>>> need to use
>>>>>>>> rscratch1 inside cmpoop.  The risk here is obvious.  The
>>>>>>>> Right Thing
>>>>>>>> to do IMO is to generate a scratch register for pointer
>>>>>>>> comparisons.
>>>>>>>> 
>>>>>>>> Unless, I guess, we know that cmpoop never ever needs a
>>>>>>>> scratch
>>>>>>>> register for any forseeable garbage collector.
>>>>>>>> 
>>>>>>> 
>>>>>>> I do know that Shenandoah does not require a tmp reg. I also
>>>>>>> do know
>>>>>>> that no other collector currently needs equals-barriers at
>>>>>>> all.
>>>>>> 
>>>>>> So cmpoop() is literally useless.  It does nothing except add a
>>>>>> layer
>>>>>> of obfuscation in the name of some possible future collector.
>>>>> 
>>>>> The layer of abstraction is needed by Shenandoah. We need special
>>>>> handling for comparing oops. It is certainly not useless. Or are
>>>>> we
>>>>> talking about different issues?
>>>> 
>>>> Ah, okay.  I'm looking at
>>>> ShenandoahBarrierSetAssembler::obj_equals()
>>>> and I see that it actually has a side effect on its operands rather
>>>> than using scratch registers.  Ewww.  I get it now.
>>>> 
>>>> OK, I withdraw my objection.  It's very confusing code to read, but
>>>> it is what it is.
>>>> 
>>> 
>>> 
>> 
> 
> 