RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS; hs_err_pid file produced

[Daniel D. Daugherty]

On 8/29/13 12:33 PM, Lois Foltan wrote:
>
> Please review the following updated webrev:
>
> Internal webrev:

Not an "internal" webrev. :-)


>
> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/

src/share/vm/adlc/arena.cpp
src/share/vm/adlc/arena.hpp
src/share/vm/adlc/main.cpp
src/share/vm/asm/codeBuffer.hpp
src/share/vm/c1/c1_Compilation.hpp
src/share/vm/c1/c1_Instruction.hpp
src/share/vm/code/codeBlob.cpp
src/share/vm/code/codeBlob.hpp
src/share/vm/code/debugInfoRec.cpp
src/share/vm/code/nmethod.cpp
src/share/vm/code/nmethod.hpp
src/share/vm/code/relocInfo.hpp
src/share/vm/code/vtableStubs.cpp
src/share/vm/code/vtableStubs.hpp
src/share/vm/gc_implementation/shared/gcUtil.hpp
src/share/vm/libadt/port.hpp
src/share/vm/memory/allocation.cpp
src/share/vm/memory/allocation.hpp
src/share/vm/memory/allocation.inline.hpp
src/share/vm/memory/memRegion.cpp
src/share/vm/memory/memRegion.hpp
src/share/vm/oops/klass.cpp
src/share/vm/oops/klass.hpp
src/share/vm/oops/symbol.cpp
src/share/vm/oops/symbol.hpp
src/share/vm/opto/callGenerator.hpp
src/share/vm/opto/callnode.hpp
src/share/vm/opto/machnode.hpp
src/share/vm/opto/node.hpp
src/share/vm/opto/type.hpp
src/share/vm/runtime/fprofiler.cpp
src/share/vm/runtime/handles.cpp
src/share/vm/runtime/handles.hpp
src/share/vm/runtime/interfaceSupport.hpp
src/share/vm/runtime/objectMonitor.hpp
src/share/vm/runtime/park.cpp
src/share/vm/runtime/park.hpp
src/share/vm/runtime/thread.hpp
src/share/vm/services/memRecorder.hpp
src/share/vm/services/memTrackWorker.cpp
src/share/vm/services/memTrackWorker.hpp
src/share/vm/utilities/array.hpp
     Yikes, this list is scary...

     But I reviewed it via the patch link instead...

     Changes are restricted to:

     - additions of "throw()" in operator new() definitions
       and operator new() declarations
     - white space changes to make things line up
     - copyright updates

     Thumbs up!

     I didn't try to verify that all the operator new() declarations
     and definitions were covered. I don't know if there is an auto-magic
     to perform such a verification.

     Please ping Vladimir Kozlov about this change so that PPC work
     that is being done can also update their operator new() stuff.

Dan



>
> 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.
>
> Tests:
>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, MacOS 
> (llvm-g++ & clang++)
>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>
> Original Testing:
>      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
>      Windows:  built fastdebug & product images with VS2010
>
> Thank you,
> Lois
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/7c3dc3df/attachment.html