Forwarding to include the openjdk distribution lists.
Lois
-------- Original Message --------
Subject: Re: RFR JDK-8022407 sun/misc/CopyMemory.java fails with
SIGSEGV in Unsafe_SetByte+0x35
Date: Wed, 28 Aug 2013 14:10:08 -0400
From: Lois Foltan <lois.fol...@oracle.com>
Organization: Oracle Corporation
To: David Holmes <david.hol...@oracle.com>
CC: Coleen Phillimore <coleen.phillim...@oracle.com>
Hi David,
Thanks for the review. In this situation for the file, -O1 is a valid
work around and I have sent out a second round of review request. I
also have one additional comment see interspersed below.
Lois
On 8/27/2013 8:50 PM, David Holmes wrote:
<offlist>
From past observation the normal way we handle this is to drop the
optimization level one notch at a time until it works. That way we
maintain maximum optimization and by seeing what optimizations are
performed at each level we can generally narrow it down to a specific
optimization that can be disabled.
Clang does not support the same -f<specific_optimization> command line
options that gcc does. From the documentation I could find the
difference between -O1 (passes) and -O2 (fails) for clang are
*
-O2 is based on -01
o /adds/: -inline -memdep -globaldce -constmerge
o /removes/: -always-inline
However, you can not pass these options directly to clang. From my take
on this one must compile with -emit-llvm to generate llvm IR/bitcode and
then pipe the resulting file into the opt phase. So not feasible for our
build makefiles but should help me further narrow down which
optimization is causing the issue. Thanks again for the tip on how this
is usually handled.
Lois
David
On 28/08/2013 6:05 AM, Coleen Phillimore wrote:
On 08/27/2013 03:39 PM, Lois Foltan wrote:
On 8/27/2013 1:29 PM, Christian Thalinger wrote:
On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.fol...@oracle.com>
wrote:
Please review the following fix:
open webrev at
http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
Bug:
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
Hi 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.
So my advice was that it wasn't performance critical - because it's
mostly calls from Java. Except for maybe the anonymous class
functions. If you disagree, let us know.
Coleen
-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.
Thanks,
Lois
Tests:
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,
Lois
