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

Bootstrap method consolidation



    • Enhancement
    • Status: Open
    • P3
    • Resolution: Unresolved
    • 12
    • tbd
    • hotspot
    • None


      Java uses of bootstrap methods for indy and condy, and is likely to
      further modify them. The code in the JVM and JDK needs consolidation.

      The JDK support code for BSMs is hard to read and maintain. Let's
      clean it up and simplify it. There should be a single BootstrapInfo
      struct in the JVM which expresses all BSM-related state, similar to
      the CallInfo and LinkInfo structs.

      The handshake from the JVM to JDK code is complicated and
      ill-documented. Let's simplify that also. If we regularize all BSM
      paths to use BootstrapCallInfo only, we will lose no generality or
      performance, and make the code easier to maintain and evolve.
      It will also be easier to evolve the JVM specification, with regard
      to bootstrap methods, if new behaviors can be expressed mainly
      at the JDK level, as the behaviors of the JDK processing BSCI

      As part of this, let's remove unused JVM paths and data fields. For
      example, the method_type field associated with the appendix field of
      an indy or method handle call is unused and just adds complexity and
      footprint. Also, while we are simplifying the CP support for such
      call sites, we can rename them to be about BSMs rather than about indy
      and condy, and we can share more indy and condy code in common.

      Let's also move bootstrap argument processing from MethodHandleNatives
      to the pre-existing (low-level, privileged) ConstantPool class. That
      also unlocks the capability for BSMs to gain direct access to CP

      Remove ConstantGroup; it was a bad idea. Instead, merge argument
      access into BootstrapCallInfo, back-ending to ConstantPool. Of
      course, the JVM should continue to pre-load argument lists.

      Adjust BSM argument access: remove copyArguments in favor of reusing
      the List.toArray protocol. Add an argumentRef API for direct access
      to BSM arguments in symbolic form. Also, add invocationTypeRef to
      support pre-resolved types (method and field), so that non-resolvable
      types can be processed.

      The Amber work has uncovered the need for new BSM modes which can omit
      metadata (lookup, name, type). Implement this as an open-ended
      "expression mode" to go with the legacy "push mode" and universal
      "BootstrapCallInfo" modes; this gives it some room to grow in the

      About half of this work is in the JVM, half in the lower levels of the JDK.
      New Java APIs can be rolled out over time, but need not be public at first.

      User-visible "expression mode" BSMs will be a feature of this work.

      Here's a prototype of these changes:


        Issue Links



              lfoltan Lois Foltan
              jrose John Rose
              0 Vote for this issue
              7 Start watching this issue