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