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

[David Holmes]

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
>>>>>
>>>
>