RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread

Doug Simon dnsimon at openjdk.java.net
Mon Apr 18 09:16:33 UTC 2022


On Mon, 18 Apr 2022 04:39:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Without that cast, I get this compiler error:
>
> I forgot that `_shared_library_javavm` is declared `volatile JavaVM*`.  So what's needed is a const_cast to discard the volatile.  But why is it pointer to volatile?  I'm not seeing any reason for that; the out argument for `JNI_CreateJavaVM` doesn't specify volatile.  I wonder if it's supposed to instead be `JavaVM* volatile` to (attempt to, though maybe not correctly) support unlocked reads with concurrent locked writes?

It is declared volatile for correct double checked locking in the code prior to this PR:

JNIEnv* JVMCIRuntime::init_shared_library_javavm() {
  JavaVM* javaVM = (JavaVM*) _shared_library_javavm;
  if (javaVM == NULL) {
    MutexLocker locker(JVMCI_lock);
    // Check again under JVMCI_lock
    javaVM = (JavaVM*) _shared_library_javavm;
    if (javaVM != NULL) {
      return NULL;
    }

However, now that `JVMCIRuntime::_lock` is acquired at the entry to `JVMCIRuntime::init_shared_library_javavm` there is indeed no longer a need for it to be volatile.

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

PR: https://git.openjdk.java.net/jdk/pull/8262


More information about the hotspot-dev mailing list