Uploaded image for project: 'CCC Migration Project'
  1. CCC Migration Project
  2. CCC-8172261

[JVMTI] Specification for early VM start event needs to lower expectations in relation to class loading

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      This is a spec only change and so has no risk in terms of using JVM TI.
    • Interface Kind:
      Other
    • Scope:
      SE

      Description

      Summary

      The specification for the early VM start event needs to make it clearer that the ability to load classes may not exist at the time of the event.

      Problem

      The JVM TI VMStart event has always been somewhat naively over-optimistic in what is allowed once the "start phase" has been entered:

      " At this time JNI is live but the VM is not yet fully initialized. Once this event is generated, the agent is free to call any JNI function."

      This suggests that any JNI function can be called, even if the VM is not yet fully initialized, which is simply not a practical reality in current JVM implementations. In particular, loading and/or initializing classes before the core platform classes have been initialized is rarely possible and can easily crash the VM.

      In JDK-8142968, with the introduction of the Module system, it was recognized that things would be even more problematic if class loading was attempted before the module system was initialized, and the concept of the "early VM start event" was introduced. This event is triggered at the same early point in VM initialization as before, but only if the can_generate_early_vmstart capability is held. Otherwise the VM start event is delayed until after the module system (and numerous other parts of the VM) has been initialized.

      The updated VMStart specification described this and tried to clarify what was possible during the "early VM start":

      "The timing of this event may depend on whether the agent has added the can_generate_early_vmstart capability or not. If the capability has been added then the VM posts the event as early as possible. The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base. Agents that do load-time instrumentation in this phase must take great care when instrumenting code that potentially executes in this phase. Care should also be taken with JNI FindClass as it may not be possible to load classes that are not in the java.base module. If the capability has not been added then the VM delays posting this event until it is capable of loading classes in modules other than java.base or the VM has completed its initialization."

      Unfortunately this is still overly-optimistic as even classes in the base module may not be successfully loaded and/or initialized at the early VM start time.

      Given we have introduced this notion of an early VM start event, it seems appropriate to lower the expectations as to what may and may not be achievable at this time. Specifically that any attempt at class loading, or initialization, may fail, even to the extent of triggering a JVM crash.

      Solution

      Explicitly allow for the possibility that arbitrary class loading during this "early VM start" time may fail in extreme ways.

      Extend:

      The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base.

      to read:

      The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base, or even arbitrary classes in java.base.


      Replace:

      Care should also be taken with JNI FindClass as it may not be possible to load classes that are not in the java.base module.

      with:

      Extreme care should also be taken with JNI FindClass as it may not be possible to load classes, and attempts to do so may result in unpredictable behavior, maybe even stability issues on some VM implementations.

      Specification

      Extend:

      The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base.

      to read:

      The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base, or even arbitrary classes in java.base.

      Replace:

      Care should also be taken with JNI FindClass as it may not be possible to load classes that are not in the java.base module.

      with:

      Extreme care should also be taken with JNI FindClass as it may not be possible to load classes, and attempts to do so may result in unpredictable behavior, maybe even stability issues on some VM implementations.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dholmes David Holmes
              Reporter:
              dholmes David Holmes
              Reviewed By:
              Alan Bateman, Serguei Spitsyn
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: