[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