Draft of spec for Minimal Value Types

Karen Kinnear karen.kinnear at oracle.com
Wed Jun 14 15:44:55 UTC 2017


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.smith at oracle.com> wrote:
>> On Jun 13, 2017, at 3:26 PM, Karen Kinnear <Karen.Kinnear at oracle.com <mailto:Karen.Kinnear at 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.

> —Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170614/474132fb/attachment.html>

More information about the valhalla-spec-experts mailing list