[aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Dec 1 14:46:05 UTC 2017


> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.03/

Looks good.

Best regards,
Vladimir Ivanov

> 01.12.2017 15:37, Vladimir Ivanov пишет:
>>> There's at least one thing missing in the test, there should be 
>>> -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the 
>>> run below was probably fastdebug.
>>
>> Yes, it was fastdebug.
>>
>>> After adding that I see the test passing on my x86 and latest 
>>> sources. Maybe it would make sense not to fail if some deopt doesn't 
>>> occur.
>>
>> The problem is related to -Xcomp.
>>
>> (I don't know why, but jtreg doesn't list -Xcomp in the log. It was 
>> passed passed as a CLI argument to jtreg.)
> 
> Yes, it was confusing
> 
>> Best regards,
>> Vladimir Ivanov
>>
>>> On 12/01/2017 02:03 PM, Vladimir Ivanov wrote:
>>>> Hold on, I observed a failure in the newly added test on linux-x64:
>>>>
>>>> ----------messages:(4/497)----------
>>>> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI 
>>>> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server 
>>>> -XX:-TieredCompilation -XX:TypeProfileLevel=020 
>>>> compiler.profiling.TestTypeProfiling
>>>> reason: User specified action: run main/othervm -Xbootclasspath/a:. 
>>>> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation 
>>>> -XX:-UseOnStackReplacement -server -XX:-TieredCompilation 
>>>> -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling
>>>> Mode: othervm [/othervm specified]
>>>> elapsed time (seconds): 21.462
>>>> ----------configuration:(0/0)----------
>>>> ----------System.out:(0/0)----------
>>>> ----------System.err:(13/992)----------
>>>> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should 
>>>> deoptimize for actual type check)
>>>>     at 
>>>> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130)
>>>>     at 
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>>>> Method)
>>>>     at 
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>>>>
>>>>     at 
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
>>>>
>>>>     at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>>>     at 
>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) 
>>>>
>>>>     at java.base/java.lang.Thread.run(Thread.java:844)
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 12/1/17 9:37 AM, Boris Ulasevich wrote:
>>>>> Thank you!
>>>>>
>>>>> Boris Ulasevich
>>>>>
>>>>> 01.12.2017 09:23, Vladimir Kozlov пишет:
>>>>>> Testing passed clean. You can push it - we don't use JPRT anymore 
>>>>>> for pushes.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote:
>>>>>>> I submitted pre-integration testing to make sure the test pass on 
>>>>>>> all our platforms.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 11/30/17 8:31 AM, Andrew Haley wrote:
>>>>>>>> On 30/11/17 16:28, Boris Ulasevich wrote:
>>>>>>>>> Thanks for good points!
>>>>>>>>>
>>>>>>>>> Updated webrew (with asserts and renamed test moved to better 
>>>>>>>>> location):
>>>>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ 
>>>>>>>>>
>>>>>>>>
>>>>>>>> Great, that's good to go.
>>>>>>>>
>>>>>>>> I think you have to get someone from Oracle to help because it
>>>>>>>> includes a new test case.
>>>>>>>>
>>>


More information about the hotspot-compiler-dev mailing list