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

[David Holmes]

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() ?

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
>