RFR: 8243470: [macos] bring back O2 opt level for unsafe.cpp
vkempik at azul.com
Wed Jun 3 17:38:53 UTC 2020
Can somebody please review this simple change ?
> 6 мая 2020 г., в 12:43, Vladimir Kempik <vkempik at azul.com> написал(а):
> Adding hotspot-runtime-dev
>> 23 апр. 2020 г., в 18:26, Vladimir Kempik <vkempik at azul.com> написал(а):
>> 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
More information about the hotspot-runtime-dev