RFR JDK-8021954 VM SIGSEGV during classloading on MacOS; hs_err_pid file produced

[Mikael Gerdin]

On 2013-08-27 04:41, David Holmes wrote:
> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>> Please review the following fix:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>           runtime/6878713/Test6878713.sh fails on mac
>>
>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>> command line option to the llvm-g++ compiler.
>>      The -fcheck-new option directs the compiler to "check that the
>> pointer returned by |operator new| is non-null
>>       before attempting to modify the storage allocated."  The clang++
>> compiler does not support the
>>       -fcheck-new option.  To obtain similiar functionality when
>> building Hotspot with clang++, empty exception
>>       throw() specifications must be added to all user-defined operator
>> new()'s.
>
> We just spotted something related in the PPC64 port and were going the
> other way or removing these "spurious" throw() declarations.
>
> But this seems really ugly - is there really a need to specialize this
> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
> honour the nothrow() semantics?
>
> That said I thought we already handled this using the "const
> std::nothrow_t&  nothrow_constant" where needed? Our other operator new
> implementations shouldn't return NULL but will abort.
>
> So why do we need -fcheck-new or this empty throw() ?

I guess that if the C++ compiler knows that operator new() will throw an 
exception if an allocation fails then it doesn't need to emit code to 
explicitly avoid calling the constructor.

If we declare operator new() with an empty throw() we will also inform 
the compiler that new can't throw an exception and therefore the 
compiler needs to explicitly handle failed allocations.

The g++ man page states:

        -fcheck-new
            Check that the pointer returned by "operator new" is 
non-null before attempting to modify the storage allocated.  This check 
is normally unnecessary because the C++ standard specifies that
            "operator new" will only return 0 if it is declared throw(), 
in which case the compiler will always check the return value even 
without this option.  In all other cases, when "operator new"
            has a non-empty exception specification, memory exhaustion 
is signalled by throwing "std::bad_alloc".  See also new (nothrow).

/Mikael

>
> Thanks,
> David
>
>> Tests:
>>
>>       Solaris: built fastdebug & product images
>>       Linux: built fastdebug & product images
>>       MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                      built fastdebug & product images using clang++ -
>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>       Windows:  built fastdebug & product images with VS2010
>>