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

[David Holmes]

On 14/09/2016 8:13 PM, Doug Simon wrote:
>
>> On 14 Sep 2016, at 11:25, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 14/09/2016 5:53 PM, Doug Simon wrote:
>>>
>>>> On 14 Sep 2016, at 03:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> On 14/09/2016 12:41 AM, Doug Simon wrote:
>>>>> Hi David,
>>>>>
>>>>> Do you still have concerns with the webrev in its current form?
>>>>
>>>> Sorry, yesterday was "one of those days". :)
>>>
>>> No problem, we have those around here sometimes as well ;-)
>>>
>>>> tl;dr: Your actual final exit code matches what JVM_Halt does, so that is fine.
>>>>
>>>> Your overall initialization and termination approach raises several general concerns. From a usability perspective the idea that JVMCI can terminate the VM at some arbitrary point after application startup is quite alarming!
>>>
>>> It’s not completely arbitrary. Top tier compilation kicks in very soon after VM startup for all but HelloWorld type applications. Also, termination happens only due to incorrect  command line in which case I’d say termination is what’s normal/expected.
>>
>> Yes but people also expect bad command line options to be detected before anything else happens that is part of the application logic.
>
> I agree. However,
>
> a) I don’t see any way to avoid this without making JVMCI non-lazy (not an option),
> b) very little application logic can run before top tier compilation kicks in and
> c) there’s already configuration checking by the native compilers in a compiler thread that could cause the VM to exit after an app thread has started (even though the chances of this are tiny).
>
>>>> Looking at the initialization code I'm unclear why it isn't being serialized in some way at a level higher than the SystemDictionary - if it was then you wouldn't need the termination logic to deal with racing threads.
>>>
>>> I’m not sure I follow. JVMCI initialization is serialized on the initialization of the jdk.vm.ci.runtime.JVMCI class. Since class initialization errors are preserved, multiple compiler threads can see the same error so will each try to go down the termination path. It’s the latter race that needs serialization which is done now in JVMCICompiler::abort_on_pending_exception.
>>
>> The code I looked at has the initialization logic called from JVMCICompiler::compile_method. I can't say that isn't called from init of the JVMCI class, but it sure doesn't sound like it. :)
>
> That path is what triggers initialization of the JVMCI class:
>
> JVMCICompiler::compile_method -> JVMCIRuntime::get_HotSpotJVMCIRuntime -> JVMCIRuntime::initialize_JVMCI -> JVMCI.<clinit>
>
>>
>> If the thread that encounters the initial error is holding an initialization "lock" (Java monitor in JVMCI's case I expect) when it takes the termination path then there's no race in taking that path.
>
> The lock is released before returning from JVMCI.<clinit> so once we’re back in JVMCICompiler::compile_method, the compiler threads are no longer synchronized.
>
>> Anyway, just musing.
>
> Which means you’re ok with the current webrev?

Yes, that is what the tl;dr referred to :)

David

>
> -Doug
>