On Tue, 7 Feb 2023 06:14:24 GMT, Hao Sun <hao...@openjdk.org> wrote: >> The problem with `JVMCIGlobals::check_jvmci_supported_gc` is that it does >> not give the compiler a chance to specify whether it supports a given GC. >> Instead, we want a JVMCI upcall like >> `jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.isGCSupported(int)`. > > Thanks for your reply. But I'm afraid I'm still a bit confused. > > 1) flag `_rop_protection` is set inside function `VM_Version::initialize()`. > The execution flow is `create_vm -> init_globals -> VM_Version_init -> > VM_Version::initialize()`. > 2) I suppose compilers (including JVMCI compiler) are initialized after > `init_global()` function. See > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/threads.cpp#L685~L707. > Hence I suppose we cannot call JVMCI methods before this site, right? > > If so, I'm afraid it's a bit late for VM to ask the compiler whether it > supports PAC-RET after the compiler initialization, and to disable PAC-RET if > the JVMCI compiler doesn't support it, mainly because some stubs are > generated already between `init_global()` and compiler initialization, and in > these stubs, flag `_rop_protection` is used to generate PAC-related code, > e.g., `SharedRuntime::generate_stubs() -> generate_deopt_blob() -> > protect_return_address()`. > > Please correct me if there is something I misunderstood. Thanks.
Ah ok, I did not pay attention to the VM lifecycle constraints in setting this flag. We could do the JVMCI check in `CompileBroker::compilation_init_phase2` but that would mean forcing eager initialization of JVMCI which, in turn, would impact VM startup. For now, we will just add a check into Graal that `UseBranchProtection` is not set, exiting the VM if it is. At the same time, we will work on adding support for this. ------------- PR: https://git.openjdk.org/jdk/pull/6334
