> On Jun 13, 2017, at 3:26 PM, Karen Kinnear <karen.kinn...@oracle.com> wrote: > > 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)
> 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? I think you're misunderstanding my use of "direct" -- I mean "non-reference" (as opposed to "reference value", which is a pointer). A "value class" is a class with ACC_VALUE set. The only way to get one of those, per current spec, is by deriving it from a VCC, and, sure, "derived value class" is an appropriate term. A "direct value class type" is the Q type of a value class, whether that class is derived or otherwise (were "otherwise" a possibility). > 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. > 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. If there's one set of statics, I would say there is one class. This approach seems consistent with a model in which we eliminate "Foo$Value" as a class name and just have reference and value flavors of "Foo" instead. At that point, I would say that we only have one thing to load, link, and initialize, and resolution of Q types should trigger that just like resolution of L types. > 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? I think this describes the approach I've tried to specify. You have to load the VCC before defining the DVC, but otherwise we're talking about two independent classes. Good point, 'vbox' should be on the list of instructions that require initialization of the VCC. Linking of the VCC would be subject to the general rules for linking (5.8): must happen sometime after loading, sometime before initialization. Errors occur at a point in the program that "might, directly or indirectly, require linkage". 'vbox' would be one such point in a program. —Dan
