Dan, Thank you for the responses. Summary - we are good with the current JVMS description of decoupling VCC and DVC initialization and linking as long as you add vbox to require initialization of the VCC.
> On Jun 13, 2017, at 6:51 PM, Dan Smith <daniel.sm...@oracle.com> wrote: > >> On Jun 13, 2017, at 3:26 PM, Karen Kinnear <karen.kinn...@oracle.com >> <mailto: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). My misunderstanding. Thank you for clearing up the terminology - I will make a new cheat sheet :-) > >> 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. There is one set of statics. From an implementation standpoint - the hotspot JVM would like to keep the Foo$Value for Early Access since there would be too many changes internally to handle the transition from name/class loader pair to the triple of name/mode/class loader. We can explore this again after Early Access. > >> 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. thanks, Karen > > —Dan
