RFR: 8157831: JVMCI tests should not be executed on linux-arm32

Dmitrij Pochepko dmitrij.pochepko at oracle.com
Thu Jun 16 13:45:23 UTC 2016


Leonid,

thank you for taking care of this issue.
Looks good to me(not a reviewer).

Thanks,
Dmitrij
> Hi
>
> I've updated fix
>
> The vm.simpleArch variable has been added which corresponds to 
> os.simpleArch of tested platform. All hotspot tests have been updated 
> to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to 
> read 'os.arch' from tested JDK then it would be possible just revert 
> this fix and preserver same behavior (See CODETOOLS-7901695 
> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>) .
>
> Updated webrev:
> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/
> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/
>
> Testing is still in progress.
>
> Leonid
>
> On 16.06.2016 13:55, David Holmes wrote:
>> On 16/06/2016 8:47 PM, Leonid Mesnik wrote:
>>> Hi
>>>
>>> On 09.06.2016 03:43, David Holmes wrote:
>>>> Hi Leonid,
>>>>
>>>> Sorry for the delay.
>>>>
>>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> Added jtreg-use at openjdk.java.net
>>>>>
>>>>> I think that you are right. Here is the documentation:
>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>
>>>>>
>>>>> "@requires <expression>
>>>>>
>>>>>     Express a dependence on characteristics of the system being 
>>>>> tested.
>>>>>     Some harnesses allow tests to be selected according to the
>>>>>     characteristics of the system being tested. The expression may be
>>>>>     composed of the following elements:"
>>>>>
>>>>> "os.arch The operating system architecture, as given by the
>>>>> corresponding system property."
>>>>>
>>>>> So user could expect to have "os.arch" of tested VM.
>>>>>
>>>>> If filed jtreg issues for this:
>>>>>
>>>>>  1. CODETOOLS-7901695
>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>>>>     value 'os.arch' property of JDK which executed JDK and not of
>>>>> tested JDK
>>>>>
>>>>>
>>>>> Following fix could be used as a temporary workaround while jtreg 
>>>>> fix is
>>>>> not ready.  Does it make a sense? I this case it is needed to change
>>>>> linux-arm64 back to linux-aarch64 to minimize changes.
>>>>
>>>> I still think we have a fundamental problem concerning what os.arch
>>>> means. This workaround seems to work but I find it all very confusing.
>>>> We really need a vm.arch property, distinct from os.arch.
>>> I see that CODETOOLS-7901695 is going to be fixed. After it is
>>> implemented the 'os.arch' property will point to 'os.arch' of tested 
>>> JDK
>>> as it described in jtreg documentation.
>>> However there are 64 failures in nightly are caused by failures of 
>>> JVMCI
>>> tests. Does it make a sense to implement this fix as a workaround to
>>> remove noise until jtreg is fixed?
>>
>> There may be some delay between jtreg being fixed and the updated 
>> version being put in to use.
>>
>> Implementing the workaround seems reasonable.
>>
>> Thanks,
>> David
>>
>>> Leonid
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>
>>>>> Leonid
>>>>>
>>>>> On 31.05.2016 04:26, David Holmes wrote:
>>>>>> Hi Leonid,
>>>>>>
>>>>>> This really strikes me as as a jtreg problem that should be fixed in
>>>>>> jtreg. When writing an @requires clause in a test the test writer
>>>>>> should not have to be thinking "oh wait! Is this going to query 
>>>>>> the VM
>>>>>> running jtreg or the VM running the test?". It should obviously 
>>>>>> be the
>>>>>> VM running the test.
>>>>>>
>>>>>> That said we also seem to have a problem with the definition of
>>>>>> os.arch:
>>>>>>
>>>>>> os.arch     Operating system architecture
>>>>>>
>>>>>> if it is returning the build architecture of the VM and not the 
>>>>>> OS it
>>>>>> is running on. That in itself argues for two distinct properties.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Could you please review following fix:
>>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>>>>> hotspot 
>>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>>>>> for bug
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>>>>
>>>>>>> The property "os.name" which was used to filter tests depends on 
>>>>>>> the
>>>>>>> arch of jdk which is used to run jtreg. It might differ from 
>>>>>>> arch of
>>>>>>> tested jdk.
>>>>>>> This fix introduce new property "vm.arch" which depends on the 
>>>>>>> arch of
>>>>>>> tested jdk and could be used to filter tests with @requires.
>>>>>>>
>>>>>>> I verified that tests are filtered where it is expected.
>>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>>>>>> testing.
>>>>>>>
>>>>>>> Leonid
>>>>>>>
>>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160616/a1b2240b/attachment.htm>


More information about the hotspot-gc-dev mailing list