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

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

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • repo-valhalla
    • repo-valhalla
    • tools
    • generic
    • generic

      Requirements:

          - 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).

            sadayapalam Srikanth Adayapalam (Inactive)
            sadayapalam Srikanth Adayapalam (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: