Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8310218

Add support for scoping of libjvmci handles

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P3 P3
    • tbd
    • 22
    • hotspot

      JVMCI Java code directly accesses managed HotSpot resources (e.g., Metadata* and oop values).

      To ensure Metadata* access is safe, handles are used. This mechanism is documented by the MetadataHandles C++ class in metadataHandles.hpp file [1].

      To ensure oop access is safe, the mechanism used depends on whether the JVMCI Java code is executing in the HotSpot heap (i.e., jarjvmci) or in a Native Image shared library (i.e., libjvmci).

      jarjvmci: a DirectHotSpotObjectConstantImpl instance has a direct reference to the oop as an Object field [2].
      libjvmci: an IndirectHotSpotObjectConstantImpl stores a handle (i.e. jobject) value in a long field [3].
      Currently, libjvmci code releases handles with Native Image weak reference processing. See the javadoc for jdk.vm.ci.hotspot.HandleCleaner [4].

      That is, a handle is deleted by a cleaner some time after the libjvmci object associated with the cleaner is garbage collected.
      The problem with this approach is that it keeps handles alive longer than strictly necessary. For example, a handle is created when compiling a method that accesses the value of a compile-time object constant (e.g. a static final field). Once the compiled code is installed, the handle could be deleted. However, the libjvmci object wrapping the handle may only be garbage collected much later, thus delaying the deletion of handle. This can cause problems due to delaying HotSpot class unloading. For example, the scaladacapo:scalatest benchmark can have a noticeable slowdown since it is a workload that is continually creating class loaders and doing class loading.

      To address this delayed resource reclamation, a mechanism is needed to better scope the lifetime of these handles. A natural scope is a single JVMCI compilation. This issue exists to introduce such a scoping mechanism.

      [1] https://github.com/openjdk/jdk/blob/44a8aa0691f046d720a789a89c9039a010658f0c/src/hotspot/share/jvmci/metadataHandles.hpp#L113-L119
      [2] https://github.com/openjdk/jdk/blob/44a8aa0691f046d720a789a89c9039a010658f0c/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/DirectHotSpotObjectConstantImpl.java#L50
      [3] https://github.com/openjdk/jdk/blob/44a8aa0691f046d720a789a89c9039a010658f0c/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/IndirectHotSpotObjectConstantImpl.java#L45
      [4] https://github.com/openjdk/jdk/blob/44a8aa0691f046d720a789a89c9039a010658f0c/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HandleCleaner.java#L27-L38

            dnsimon Douglas Simon
            dnsimon Douglas Simon
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: