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

David Holmes david.holmes at oracle.com
Mon Sep 12 01:24:22 UTC 2016 

On 10/09/2016 6:29 AM, Coleen Phillimore wrote:
> On 9/9/16 3:31 PM, Doug Simon wrote:
>> Is vm_exit_during_initialization still the right choice when this
>> could be after VM initialization? JVMCI initialization is lazy and can
>> happen after the application has started.
>
> I don't actually know then.  vm_exit tries to get threads to a safepoint
> first, but vm_abort(false) just shuts down the jvm. There aren't a lot
> of places we terminate the jvm.  Maybe David Holmes knows.

If JVMCI initialization is lazy and can happen after the application is 
started, why should it be a fatal error to fail to initialize it? How is 
the initialization triggered? Is there a synchronous call that could 
throw an exception? How does the user know that initialization failure 
will result in termination?

Can you not at least eagerly validate command-line options during VM 
initialization, even if you don't actually initialize JVMCI fully?

That aside it sounds like you want JVMCI initialization to do the 
equivalent of either Runtime.exit or Runtime.halt, depending on the 
exact termination semantics you want. If you call vm_exit directly then 
you get something like Runtime.halt

David
-----

> Coleen
>
>>
>> Sent from my iPhone
>>
>>> On Sep 9, 2016, at 9:23 PM, Coleen Phillimore
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>> I think you want vm_exit_during_initialization() for that. Definitely
>>> not vm_abort, cause then it looks like an internal error/crash.
>>>
>>> Coleen
>>>
>>>> On 9/9/16 2:33 PM, Doug Simon wrote:
>>>> 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
>

More information about the hotspot-dev mailing list