Dan,
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?
thanks,
Karen
> On Jun 7, 2017, at 2:43 AM, Dan Smith <daniel.sm...@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
