RFR: 8315818: vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java fails on libgraal [v2]

[Tom Rodriguez]

On Thu, 7 Sep 2023 11:01:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Instead of eagerly initializing JVMCI for `-Xcomp`, this defers JVMCI compilations until JVMCI is initializable. In the case of libgraal, no compilations are deferred since libgraal is always initializable. For jargraal, it still has to wait until the VM has reached a certain initialization phase so as to avoid deadlocks bewteen the main thread and a compiler thread.
>> 
>> This allows tests such as `vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java` to succeed on libgraal, even when there is insufficient virtual memory to mmap libgraal. Failing to initialize libgraal in that scenario now results in a bailout instead of exiting the VM.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   instead of eagerly initializing JVMCI for -Xcomp, defer JVMCI compilations until JVMCI is initializable

Yes I like that much better.

src/hotspot/share/jvmci/jvmci.cpp line 58:

> 56: void jvmci_vmStructs_init() NOT_DEBUG_RETURN;
> 57: 
> 58: bool JVMCI::can_initialize_JVMCI() {

For the non libgraal case is this test really complete?  I guess I'm not convinced that the tests in this method are sufficient the safe init point.  Maybe it would be simpler to have a `JVMCI::_can_be_initialized` flag which is set at the correct point during the init steps in the same way that `CompileBroker::_initialized` is set.  Having the order explicitly spelled out there seems better than trying to infer it from other state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15602#issuecomment-1710628143
PR Review Comment: https://git.openjdk.org/jdk/pull/15602#discussion_r1319000141