RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35
lois.foltan at oracle.com
Tue Aug 27 19:39:09 UTC 2013
On 8/27/2013 1:29 PM, Christian Thalinger wrote:
> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
>> Please review the following fix:
>> open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>> bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>> Summary of fix:
>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ compiler, exhibited a compiler optimization issue when prims/unsafe.cpp was compiled at the default -Os level. As a work around fix, knock the optimization level down down to -O0.
> Why are we lowering to -O0 when you state in the bug report that -O1 also works? What is the code that breaks?
> -- Chris
The convention within make/bsd/makefiles/gcc.make indicated that
historically files that exhibited C++ compiler optimization issues were
knocked down to /NOOPT or -O0. I did also check with Coleen to make
sure that prims/unsafe.cpp was not a performance critical file. -O1
does add some optimizations on top of -O0 but not inlining. I will
recheck testing with -O1 to confirm and change unsafe.cpp's optimization
level to -O1 if testing yields good results.
I suspect the optimization problem is in unsafe.cpp's definition of
Unsafe_GetNativeByte. I had left off tracking it at that level and
certainly will not close the JDK bug until I can narrow in further and
hopefully report to the clang compiler team.
>> MacOS: built fastdebug & product images using clang++ (ran JTREG & vm.quick.testlist)
>> built using llvm-g++ to verify prims/unsafe.cpp remained compiled at -Os
>> Thank you,
More information about the build-dev