Fwd: Re: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35

[Lois Foltan]

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.foltan at oracle.com>
Organization: 	Oracle Corporation
To: 	David Holmes <david.holmes at oracle.com>
CC: 	Coleen Phillimore <coleen.phillimore at 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.foltan at 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
>>>>>
>>>>>
>>>
>>