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

[Christian Thalinger]

Thanks.  -- Chris

On Aug 28, 2013, at 10:58 AM, Lois Foltan <lois.foltan at oracle.com> wrote:

> Hi Christian,
> 
> Thanks for the review.  I completed the change to only knock the optimization level  down to -O1 for the file prims/unsafe.cpp.
> 
> Lois
> 
> On 8/27/2013 9:15 PM, Christian Thalinger wrote:
>> On Aug 27, 2013, at 1:05 PM, Coleen Phillimore <coleen.phillimore at oracle.com> 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.
>> I agree.  Most of the (performance critical) Unsafe methods are intrinsified anyway but why waste computing cycles and more importantly bytes (in object size) if we don't have to.
>> 
>> -- Chris
>> 
>>> 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
>>>>>> 
>>>>>> 
>