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

Leonid Mesnik leonid.mesnik at oracle.com
Thu Jun 16 15:09:36 UTC 2016


Thanks for reviewing.
The testing finished successfully. Still waiting for more reviews.

Leonid

On 16.06.2016 16:45, Dmitrij Pochepko wrote:
> 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: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160616/f93e0fb2/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list