On Mon, 6 Feb 2023 11:50:57 GMT, Doug Simon <dnsi...@openjdk.org> wrote:
>> Thanks for reporting this. @dougxc >> >> Yes. I encountered several jtreg failures with Graal, which is built with >> PAC-RET enabled JDK. >> >> As I see it, the straightforward fix is to disable JVMCI if >> `_rop_protection` is parsed as "true" finally, since Graal doesn't supports >> PAC-RET currently. >> That is similar to the way `JVMCIGlobals::check_jvmci_supported_gc` does, >> i.e. if one GC except `G1/Serial/Parallel` is configured, we disable JVMCI. >> WDYT > > 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. ------------- PR: https://git.openjdk.org/jdk/pull/6334
