Draft of spec for Minimal Value Types

Karen Kinnear karen.kinnear at oracle.com
Tue Jun 13 21:26:34 UTC 2017


Many thanks for writing this optional JVMS draft so early so we can iron out issues together.

I wanted to follow up specifically on the load/link/init relationships for the Value Capable Class (VCC) and the derived Value Class (DVC) to use
the terms in this JVMS draft. (Note: direct value class is the longer term directly defined value class which I have been calling a Valhalla Value Type VVT)

I think we are all in agreement that a reference to a DVC must first pre-load the VCC just as it has to pre-load supertypes.

The question arises about linking and initialization.

So to clarify, the DVC does not have any methods, including <clinit> today, and does not have any statics.
  So linking of the DVC itself does nothing.
  So initialization of the DVC itself does nothing.

I think there are two models we would use here.

Option 1: super-type model for root class relative to derived class: pre-link and pre-init VCC when linking or initialization the DVC

Conceptually I think of a DVC and VCC as sharing one set of statics, and a value class instance today as a “copy” of the instance
fields of a VCC instance. 

So I think people would expect that the statics of the root class were initialized before any instance
was created or operated on. 

And you would expect to link (e.g. verify) the root class before you let someone create or play
with a derived class. If we did this in a different order, we could be operating on value types derived from invalid class files.

Longer-term it is not clear if we will have a root class and a derived class, or conceptually one class file with two derived
classes, but I believe the expectation is that there will continue to be one set of statics, so I would expect the statics to need
to be initialized before either derived class created an instance.

          Longer-term it is expected that we will have a single source file with methods that must be verified before either class can
be used.

Option 2: lazy initialization, lazy linking

Alternatively we could not initialize the VCC until any of the current instructions either reference a static or create an instance.
Note: I would expect vbox to be added to the instructions requiring initialization in this case since it creates an instance of the VCC

Even in this case I would continue to require initialization and linking according to the rules you state, e.g. adding initialization
based on vdefault, anewarray, multianewarray even if they do nothing other than a state change.

I do not know in this case how to handle verification errors in the VCC - i.e. are you still free to operate on the DVC?
What happens when you try to vbox?

Detailed question:
In JVMS 5.5 Initialization in your draft - is it intentional that for anewarray and multianewarray that you mention a direct value class type
 - which in your terminology I believe is the future “valhalla value type” which is directly defined but not derived from a VCC. So that
you would not trigger initialization for these instructions for a derived value class?
Would that be the same for vdefault also then?


> On Jun 7, 2017, at 2:43 AM, Dan Smith <daniel.smith at oracle.com> wrote:
> Please see the following for a set of changes to JVMS to support our value types prototyping efforts.
> http://cr.openjdk.java.net/~dlsmith/values.html
> The intent is to reference this document in an umbrella JSR as a set of features that may be optionally implemented by a JVM without any compatibility promises for future versions. (This is in the spirit of Incubator Modules, JEP 11.)
> Some details are still being ironed out, but I wanted to share with a broader audience. Feedback is welcome!
> Thanks,
> Dan

More information about the valhalla-spec-observers mailing list