RFR: 8315818: vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java fails on libgraal [v2]
Tom Rodriguez
never at openjdk.org
Thu Sep 7 19:33:42 UTC 2023
On Thu, 7 Sep 2023 19:08:32 GMT, Doug Simon <dnsimon at openjdk.org> wrote:
>> 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.
>
> We've been running this code for a long time (Graal unit tests on jargraal, Native Image building of libgraal etc) so I don't see any reason to double-guess its correctness now. I suggest we leave it as is and address problems when/if they show up.
Ok.
>> src/hotspot/share/runtime/threads.cpp line 748:
>>
>>> 746: #if INCLUDE_JVMCI
>>> 747: if (force_JVMCI_initialization) {
>>> 748: JVMCI::initialize_compiler(CHECK_JNI_ERR);
>>
>> Does anything bad happen if force_JVMCI_initialization is true and we end up initializing the compiler from the compile broker thread instead? I guess that would be adding Xcomp to the the other flags that force initialization.
>
> Both `JVMCIPrintProperties` and `JVMCILibDumpJNIConfig` explicitly do the equivalent of `System.exit()` once they've performed their task so I don't think it matters which thread triggers the task. I don't think it will cause any problems for `EagerJVMCI` either. In fact, I don't think we really need `EagerJVMCI` any more as it's only purpose was to make `JVMCIPrintProperties` guaranteed to do something.
Ok.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15602#discussion_r1319037238
PR Review Comment: https://git.openjdk.org/jdk/pull/15602#discussion_r1319037620
More information about the hotspot-runtime-dev
mailing list