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

[David Holmes]

On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
> 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.

Yes that is what happens, but why do _we_ need it when ...

> 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.

... we have two kinds of operator new implementations (or at least we 
_should_ only have two kinds):

1. Will abort on OOM (either ResourceArea exhaustion or Stack 
exhaustion) and so never returns NULL
2. Can return NULL and uses std::nothrow to indicate that

So we should not need this if the nothrow is acting as I think it 
should. Have we missed places where nothrow is needed? Do we have errant 
operator new definitions unrelated to the allocation base classes?

David
-----

> 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
>>>