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

David Holmes david.holmes at oracle.com
Thu Jun 16 10:55:30 UTC 2016

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.


> 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

More information about the jtreg-use mailing list