RFR: 8243470: [macos] bring back O2 opt level for unsafe.cpp

[Vladimir Kempik]

Hello
The result of the test varies from run to run, it can give +-5%.
So you need average of multiple runs to have some useful result
Thanks.

> 8 июня 2020 г., в 21:18, gerard ziemski <gerard.ziemski at oracle.com> написал(а):
> 
> hi Vladimir,
> 
> My testing show no problem with the "-O2" flag, however, using just "-Os" (i.e. dropping "-O1" from JvmOverrideFiles.gmk") shows about the same performance as adding "-O2", and in fact it is slightly fastest for the TestRandom use case:
> 
> -Os -O1 (the current default for unsafe.cpp) takes 196s
> 
> -Os (the default for most hotspot files) takes 158s
> 
> -O2 takes 161s
> 
> -O3 takes 161s
> 
> Can you reproduce my findings?
> 
> 
> cheers
> 
> On 6/3/20 2:59 PM, gerard ziemski wrote:
>> hi Vladimir, I will take a look to see if I can help review this...
>> 
>> 
>> On 6/3/20 12:38 PM, Vladimir Kempik wrote:
>>> Hello
>>> 
>>> Can somebody please review this simple change ?
>>> 
>>> Thanks
>>> 
>>>> 6 мая 2020 г., в 12:43, Vladimir Kempik <vkempik at azul.com> написал(а):
>>>> 
>>>> Adding hotspot-runtime-dev
>>>> 
>>>>> 23 апр. 2020 г., в 18:26, Vladimir Kempik <vkempik at azul.com> написал(а):
>>>>> 
>>>>> 
>>>>> Hello
>>>>> Please review a fix for JDK-8243470
>>>>> 
>>>>> Long time ago as part of JEP284: New HotSpot Build System this fix was applied to jdk9 https://bugs.openjdk.java.net/browse/JDK-8152666
>>>>> At that time it was decided to lower optimisation level for unsafe.cpp from O2 to O1 only for clang on Macosx.
>>>>> 
>>>>> I suppose it was done due to issues in Set/Get<Object> helper functions where too optimistic optimisations were eliminating some null pointer checks. it was probably a clang bug.
>>>>> That issue could be checked with test jdk/test/sun/misc/CopyMemory.java.
>>>>> 
>>>>> I believe that workaround (going from O2 to O1) produced this issue - https://bugs.openjdk.java.net/browse/JDK-8234963 (Thread.getStackTrace is slow with clang).
>>>>> JDK-8234963 can only be seen on mac with libjvm compiled by clang.
>>>>> 
>>>>> Here I propose the patch which eliminates that workaround for clang 8+.
>>>>> 
>>>>> I have tested clang versions 8/9/9.1/10, all of them showed good results:
>>>>> 1) CopyMemory test passes fine on 11/14/15.
>>>>> 2) jdk11/jdk14 passed tck. Regression testing were good as well. jdk15: no new failures in tck.
>>>>> 3) The testRandom "benchmark" from 8234963 shows great improvements on my machine, going down from ~200 seconds to ~150 seconds (the newer clang the better result). For comparision, gcc built libjvm for jdk11 shows ~130 seconds on my machine.
>>>>> 
>>>>> The webrev: http://cr.openjdk.java.net/~vkempik/8243470/webrev.00/
>>>>> 
>>>>> getStackTrace benchmark: http://cr.openjdk.java.net/~vkempik/8243470/TestRandom.java
>>>>> 
>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8243470
>>>>> 
>>>>> Thanks, Vladimir
>>