[aarch64-port-dev ] RFR: 8081669: aarch64: JTreg TestStable tests failing

Alexeev, Alexander Alexander.Alexeev at caviumnetworks.com
Tue Jun 2 16:55:29 UTC 2015

Vladimir, I am contributing on behalf of Cavium Inc.
It actually exists in the list. Is it enough?


-----Original Message-----
From: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Ivanov
Sent: Tuesday, June 2, 2015 7:51 PM
To: edward.nevill at linaro.org; aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers
Subject: Re: [aarch64-port-dev ] RFR: 8081669: aarch64: JTreg TestStable tests failing

The only concern I have is that I don't see Alexander on OCA list [1].
In order to proceed with the fix, he should sign OCA first.

Best regards,
Vladimir Ivanov

[1] http://www.oracle.com/technetwork/community/oca-486395.html

On 6/2/15 5:17 PM, Vladimir Ivanov wrote:
> Looks good.
> Best regards,
> Vladimir Ivanov
> On 6/2/15 12:26 PM, Edward Nevill wrote:
>> Hi,
>> The following webrev
>> http://cr.openjdk.java.net/~enevill/8081669/webrev.00/
>> fixes a number of TestStable tests.
>> This patch was contributed by alexander.alexeev at caviumnetworks.com
>> The following are the test failures that are fixed by this patch
>> compiler/stable/TestStableByte.java
>> compiler/stable/TestStableBoolean.java
>> compiler/stable/TestStableChar.java
>> compiler/stable/TestStableFloat.java
>> compiler/stable/TestStableObject.java
>> compiler/stable/TestStableDouble.java
>> compiler/stable/TestStableInt.java
>> compiler/stable/TestStableLong.java
>> compiler/stable/TestStableShort.java
>> The problem is that the method 'get' in StableConfiguration is 
>> supposed to return true if the method is server compiled, false 
>> otherwise.
>> On aarch64 it is always returning true, even when the method is 
>> client compiled. The reason for this is that aarch64 differs from 
>> other ports in that it always deopts on patching.
>> This means that the method 'get' deopts immediately when compiled 
>> with -Xcomp because it hits an unresolved method call. This means 
>> that the method is now executing in the interpreter.
>> When the method 'get' is executing in the interpreter, it uses the 
>> value of java.vm.name to determine whether the method would be server 
>> compiled if it were to be compiled. This ends up returning true on 
>> aarch64, because it is a server compiler.
>> However in the case where we force it not to server compile by using 
>> -XX:+TieredCompilation and -XX:TieredStopAtLevel=1 (as in the 
>> TestStable tests) this will be incorrect.
>> The solution is to introduce a simple (null) method 'get1' which will 
>> never be deopted (because there is never anything to patch) and uses 
>> this as the basis for deciding whether we are server compiling or not.
>> This is more fully explained in the inline comment in the patch.
>> Please review and if appropriate I will push.
>> All the best,
>> Ed.

More information about the hotspot-dev mailing list