-
Bug
-
Resolution: Fixed
-
P4
-
repo-valhalla
-
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).
- 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).
- relates to
-
JDK-8266466 [lworld] Enhance javac to consume unified primitive class files generated under the option -XDunifiedValRefClass
-
- Resolved
-
-
JDK-8267597 [lworld] Withdraw all support for bifurcated class generation for primitive classes
-
- Resolved
-