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

[lworld] Provide experimental support for generating a single class file per primitive class



    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: repo-valhalla
    • Fix Version/s: repo-valhalla
    • Component/s: tools
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:



          - Provide an experimental mode controlled by a javac command line option (off by default), under which javac will translate a primitive class (say class Point) into a single class file (Point.class) artifact instead of the present two class file scheme (Point$ref.class and Point$val.class/Point.class)

          - On the language side, Point.val and Point.ref will continue to be two distinct types standing for the value projection and reference projection. But javac backend would generate a single class file Point.class as output

         - The class file will use L/Q forms to denote the two variants in descriptors. That is, in field and method signatures, today’s "LPoint$ref;" and "QPoint$val;"/"QPoint;" will become respectively "LPoint;" and "QPoint;”.

          - For places where we need conversion between the two types (QFoo and LFoo) we will issue casts.

          - ATM, a cast takes a class info, not a descriptor. There's a proposal on the table to emit a special class info that uses a
      descriptor in the Utf8 of a class

          - The CONSTANT_Class_info syntax would be the following: To express the L-type (Point.ref) the CONSTANT_Class_info contains an index to an Utf-8 with the name of the class “Point”. And to express the Q-type (Point) the CONSTANT_Class_info contains an index to an Utf-8 with a full descriptor “QPoint;”

          - A CONSTANT_Class_info with the descriptor can be used by any bytecode that needs to make the distinction between the L-type and the Q-type: checkcast, instanceof, anewarray, ldc.

          - Should defaultvalue use a class name or a descriptor is TBD, but this is not a big deal, because there’s no ambiguity in the semantic.

          - At this point, the model is not using type restrictions, the Q marker in descriptor continues to mean the same thing: non-nullable reference to a primitive object. This means, the produced bytecodes will continue to be verified by the JVM with the same rules as today.

          - There are no additional attributes to be generated.

          - One constraint from the VM side is that we cannot simply switch to the current model to the L/Q model in a single step, there’re too many components to be updated. So, instead of breaking the repo for weeks, we’d like to have flag in javac to generate class files with the L/Q model, so we can start working on the transition, without breaking the main branch and impacting the works in progress (especially from the community).


          Issue Links



              sadayapalam Srikanth Adayapalam
              sadayapalam Srikanth Adayapalam
              0 Vote for this issue
              6 Start watching this issue