RFR: 8308764: Reporting errors from create_vm may crash [v5]
David Holmes
dholmes at openjdk.org
Tue Jun 6 22:30:54 UTC 2023
On Tue, 6 Jun 2023 15:16:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> I was later wondering the same thing. Here's my rationale for putting it here
>> instead of in the JNI code (i.e. agreeing with Coleen's suggestion).
>>
>> I think neither place is really correct. Failure to create and initialize the
>> VM ought to always propogate out to the JNI client to decide what to do about
>> the failure. But we don't do that, not only here but all over the place. These
>> (and many other) failures are treated as grounds for terminating the process
>> containing the VM, regardless of what else that process might be doing. This
>> limits the utility of the VM in ways similar to not being able to have
>> multiple VMs (at the same time or serially) in one process. Oh well.
>>
>> Given that, putting the vm_exit_during_initialization() in create_vm seems
>> simpler. It's not even clear create_vm should ever return failure with
>> canTryAgain false; maybe it should always terminate if there's a non-retryable
>> failure. But perhaps that's for a later day.
>
> I agree that init_globals2 isn't a great name. I failed to come up with
> something better, either now or when I added it. Anyone with something better
> should go for it.
Sorry but this is getting a bit out of hand. Rearranging the deckchairs really doesn't change anything. You could argue that everything should happen in create_vm so JNI_CreateJavaVM is just a minimal wrapper, but that is not what fixing this issue is about. All I'm trying to do here is avoid the crash when there is no longer a current thread.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14238#discussion_r1220465314
More information about the hotspot-runtime-dev
mailing list