RFR: 8165755: [JVMCI] replace use of vm_abort with vm_exit

Fri Sep 9 18:33:40 UTC 2016

Can someone from the runtime team confirm that using vm_exit (instead of vm_abort) is the best way to stop the VM when JVMCI initialization fails (e.g., when invalid JVMCI options are provided on the command line). Thanks!

-Doug

> On 09 Sep 2016, at 19:48, Christian Thalinger <cthalinger at twitter.com> wrote:
> 
> I think this looks fine but maybe we should ask the runtime folks.
> 
>> On Sep 8, 2016, at 11:01 PM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> Calling vm_abort from multiple threads can cause nasty crashes such as double free errors. We've seen this in Graal during JVMCI initialization when an unknown Graal option is encountered. Multiple compiler threads try to initialize JVMCI which fails with an exception indicating the bad option:
>> 
>> Uncaught exception at /scratch/graaluser/buildslave/buildlog/ci_executor/main/graal-jvmci-8/src/share/vm/jvmci/jvmciCompiler.cpp:127 
>> java.lang.ExceptionInInitializerError 
>>       at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:85) 
>>       at jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) 
>>       at jdk.vm.ci.runtime.JVMCI.<clinit>(JVMCI.java:58) 
>> Caused by: java.lang.IllegalArgumentException: Could not find option OptSomethingThatDoesNotExcist 
>>       at com.oracle.graal.options.OptionsParser.parseOption(OptionsParser.java:134) 
>>       at com.oracle.graal.options.OptionsParser.parseOptions(OptionsParser.java:62) 
>>       at com.oracle.graal.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:156) 
>>       at com.oracle.graal.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:86) 
>>       at jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:96) 
>>       at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.<init>(HotSpotJVMCIRuntime.java:277) 
>>       at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.<init>(HotSpotJVMCIRuntime.java:67) 
>>       at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.<clinit>(HotSpotJVMCIRuntime.java:75) 
>>       at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:85) 
>>       at jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) 
>>       at jdk.vm.ci.runtime.JVMCI.<clinit>(JVMCI.java:58) 
>> 
>> The native JVMCI code then tries to exit the VM by calling vm_abort. If multiple compiler threads do this concurrently, certain destructors can be called twice as shown by these thread dumps:
>> 
>> thread #26: tid = 0x0019, 0x00007fff84280124 libsystem_malloc.dylib`szone_size + 227, stop reason = signal SIGSTOP
>> frame #0: 0x00007fff84280124 libsystem_malloc.dylib`szone_size + 227
>> frame #1: 0x00007fff8427fed5 libsystem_malloc.dylib`free + 61
>> frame #2: 0x000000010ac95963 libjvm.dylib`os::free(memblock=0x00007fedc86226e0, memflags=mtInternal) + 307 at os.cpp:711
>> frame #3: 0x000000010a2afc54 libjvm.dylib`FreeHeap(p=0x00007fedc86226e0, memflags=mtInternal) + 52 at allocation.inline.hpp:93
>> frame #4: 0x000000010acf0a9f libjvm.dylib`PerfData::~PerfData(this=0x00007fedc8622650) + 63 at perfData.cpp:116
>> frame #5: 0x000000010acf0ae5 libjvm.dylib`PerfData::~PerfData(this=0x00007fedc8622650) + 21 at perfData.cpp:114
>> frame #6: 0x000000010acf163d libjvm.dylib`PerfDataManager::destroy() + 109 at perfData.cpp:287
>> frame #7: 0x000000010acf3f4d libjvm.dylib`perfMemory_exit() + 61 at perfMemory.cpp:74
>> frame #8: 0x000000010ac9bb0d libjvm.dylib`os::shutdown() + 13 at os_bsd.cpp:1130
>> frame #9: 0x000000010ac9bb55 libjvm.dylib`os::abort(dump_core=false) + 21 at os_bsd.cpp:1150
>> frame #10: 0x000000010a9188e7 libjvm.dylib`vm_abort(dump_core=false) + 39 at java.cpp:666
>> frame #11: 0x000000010aa4f1e7 libjvm.dylib`JVMCIRuntime::abort_on_pending_exception(exception=Handle @ 0x000070000175b208, message="Uncaught exception at /Users/dsimon/graal/graal-jvmci-8/src/share/vm/jvmci/jvmciCompiler.cpp:127", dump_core=false) + 167 at jvmciRuntime.cpp:992
>> frame #12: 0x000000010aa17017 libjvm.dylib`JVMCICompiler::compile_method(this=0x00007fedcb203050, method=0x000070000175b8d8, entry_bci=-1, env=0x000070000175b8f0) + 311 at jvmciCompiler.cpp:127
>> frame #13: 0x000000010a656cd2 libjvm.dylib`CompileBroker::invoke_compiler_on_method(task=0x00007fedc853ca30) + 1314 at compileBroker.cpp:2207
>> 
>> thread #23: tid = 0x0016, 0x00007fff91fcb122 libsystem_kernel.dylib`__semwait_signal_nocancel + 10, stop reason = signal SIGSTOP
>> frame #0: 0x00007fff91fcb122 libsystem_kernel.dylib`__semwait_signal_nocancel + 10
>> frame #1: 0x00007fff9578c318 libsystem_c.dylib`nanosleep$NOCANCEL + 188
>> frame #2: 0x00007fff957b62ce libsystem_c.dylib`usleep$NOCANCEL + 54
>> frame #3: 0x00007fff957e46e9 libsystem_c.dylib`abort + 139
>> frame #4: 0x00007fff8428c396 libsystem_malloc.dylib`szone_error + 626
>> frame #5: 0x000000010ac95963 libjvm.dylib`os::free(memblock=0x00007fedc8601cd0, memflags=mtInternal) + 307 at os.cpp:711
>> frame #6: 0x000000010a2afc54 libjvm.dylib`FreeHeap(p=0x00007fedc8601cd0, memflags=mtInternal) + 52 at allocation.inline.hpp:93
>> frame #7: 0x000000010acf0a9f libjvm.dylib`PerfData::~PerfData(this=0x00007fedc8601c60) + 63 at perfData.cpp:116
>> frame #8: 0x000000010acf0ae5 libjvm.dylib`PerfData::~PerfData(this=0x00007fedc8601c60) + 21 at perfData.cpp:114
>> frame #9: 0x000000010acf163d libjvm.dylib`PerfDataManager::destroy() + 109 at perfData.cpp:287
>> frame #10: 0x000000010acf3f4d libjvm.dylib`perfMemory_exit() + 61 at perfMemory.cpp:74
>> frame #11: 0x000000010ac9bb0d libjvm.dylib`os::shutdown() + 13 at os_bsd.cpp:1130
>> frame #12: 0x000000010ac9bb55 libjvm.dylib`os::abort(dump_core=false) + 21 at os_bsd.cpp:1150
>> frame #13: 0x000000010a9188e7 libjvm.dylib`vm_abort(dump_core=false) + 39 at java.cpp:666
>> frame #14: 0x000000010aa4f1e7 libjvm.dylib`JVMCIRuntime::abort_on_pending_exception(exception=Handle @ 0x0000700001452208, message="Uncaught exception at /Users/dsimon/graal/graal-jvmci-8/src/share/vm/jvmci/jvmciCompiler.cpp:127", dump_core=false) + 167 at jvmciRuntime.cpp:992
>> frame #15: 0x000000010aa17017 libjvm.dylib`JVMCICompiler::compile_method(this=0x00007fedcb203050, method=0x00007000014528d8, entry_bci=-1, env=0x00007000014528f0) + 311 at jvmciCompiler.cpp:127
>> frame #16: 0x000000010a656cd2 libjvm.dylib`CompileBroker::invoke_compiler_on_method(task=0x00007fedc862a320) + 1314 at compileBroker.cpp:2207
>> 
>> 
>> This webrev replaces calls to vm_abort() with before_exit() + vm_exit(). The latter is thread safe.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8165755
>> http://cr.openjdk.java.net/~dnsimon/8165755/
>> 
>> -Doug
> 