Valhalla Minimal Value Types review invitation

[Karen Kinnear]

Next meeting: Wednesday April 26, 9am PT: 

NEW DIAL-IN: https://oracle.zoom.us/j/251372518
(you don’t need a zoom account - apologies for last meeting)

Notes from the April 12, 2017 Minimal Value Types (MVT) review meeting:
attendees: Ian Graves (Intel), Bjorn Vardal (IBM), Dan Heidinga (IBM), Doug Lea,
Oracle: John Rose, Brian Goetz, Vladimir Ivanov, Karen Kinnear


Thank you John for the update from 0.2 to 0.3 Shady values. Highlights:
1. implementation related changes (e.g. # byte codes)
2. References in value capable class (VCC)/derived value type (DVT)- leaving this open to the implementation teams as a potential extension
to MVT - both Ian and Doug say they are ok with just primitives at this time
3. Simplified initial Derived Value Type to just contain instance fields, no <clinit>, <init>, no other methods, no static fields
    simplifies implementation, access to static fields or any methods requires boxing
4. New section on boxing, unboxing and borrowing

AI: John:  there were additional notes in the earlier email summary which still need to be incorporated into an update.

Brief summary of incubator/experimental approach:
Exploring expanding the JEP 11 Incubator Modules to allow for a small number of Incubator VM Features which would 
require JVM Specification changes. Key is to set expectations both with JVMS implementors of the optionality of specific incubator 
features, and with users that these are experimental, perhaps via command line switches and warning.
Our goal is to improve our early adopter feedback cycle still within a manageable level.

Early Access:
Goal is to provide an early access binary early summer, so a few early adopters can give us feedback as to
usefulness of the model and what is missing. The expectation is that we will have more performance optimizations to
add after Early Access, and actually hope to get some use cases to guide our optimizations.
Intel’s Ian Graves and Doug Lea have offered to be early adopters.

Discussion:
1. Type bytecode prefix plans?
Not in the MVT timeframe.
AI John: to remove from Shady
Supported byte codes will be:
  vload, vstore, vaload, vastore, vreturn, vdefault, vwithfield, vgetfield (get a field from a value type), vbox, vunbox
  byte codes that will allow an operand of a value type: anewarray, multianewarray

2. Interface support
Yes: VCC may implement interfaces. For MVT, it will be required to box to invoke any interface methods.
invoke interface may not take a QType for a receiver

3. Do we need to restrict vdefault to being called from within the owning derived value type?
Answer: No. vdefault can be accessed from anywhere.

vdefault does not run a user-supplied constructor. vdefault creates a value type which is all 0’s in memory
which is treated as containing the default values of 0, 0.0, null, for each of its fields. This is done for both
performance and security. We are defining the default value type as “initialized” by the nullary constructor,
so from a verification perspective this is considered initialized.

Ed. note: expanding creation of a default value type instance:

Creation of a default value type instance: which is all 0’s in memory to represent the 0 or 0.0 or null value for fields of the dvt
1) bytecode vdefault
2) anewarray/multianewarray on a derived value type
    - creates a value array which is all 0’s in memory representing the flattened elements of the array
    - which does not entail invoking any constructor on the VCC
3) vaload of an element from a value array (which then copies the contents)
3) getfield of a derived value type field (which then copies the contents)
4) vwithfield (which then copies the contents)
5) internal implementation details such as copying a DVT from registers, stack, off-heap storage, …

4. <clinit>, <init>
For MVT, the DVT does NOT have any methods including a <clinit> or an <init>
Note that any creation of a default value type instance should ensure that the derived value type
is “initialized”, which implies that the VCC has run <clinit>. This may be done explicitly or by construction.

AI: Karen:  send out an initial load/link/init proposal

Open Issues:
1. java.lang.Reflect support
 Initial proposal is to see if we can not support reflection on derived value types, but require boxing.
AI: implementors - see if the MethodHandle optimized paths require reflection for internal implementation.
Early Access should give us some initial feedback from our users.

2. JVMTI support
AI: Implementors - what support can we offer without changing the JVMTI APIs

3. Draft JVMS extensions
AI: Dan Smith

thanks,
Karen

p.s. a couple of notes below
> On Apr 19, 2017, at 11:22 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Apr 19, 2017, at 8:16 AM, Bjorn B Vardal <bjornvar at ca.ibm.com <mailto:bjornvar at ca.ibm.com>> wrote:
>> 
>> I'm writing up my notes from the meeting, and I have a question about the box's no-arg constructor.  My notes say that this constructor is automatically provided and may not be replaced by the user. My understanding is that this is done in order to force the constructor to have the same behaviour as "vdefault; vunbox;”.
Did you mean "vdefault;vbox;” ? As in vdefault always creates a DVT, not a VCC.
> 
> Correct.  As in C#, a value type always has a system-supplied nullary constructor
> which cannot be replaced by the user.  Given the ubiquitous access to "vdefault"
> (by both the instruction and by sampling unassigned fields and array elements)
> there is a huge potential performance cost (plus bootstrapping problems) if we
> allow users to supply computed bit patterns at all variable creation points.
> It's not just bit-blt, either, since if the computed patterns have non-null managed
> pointers in them, the JVM is likely to have to issue extra card mark operations.
> It's a mess, and not worth it, so we just say a default value looks like a fresh
> object, before any of its fields are initialized.
> 
>> My question is, did we decide to restrict the accessibility of these constructors,
> 
> Yes, that's in the draft.
> 
>> and if so, what would be the reason to do this? As stated above, the default box can already be obtained by unboxing a default value.
Just checking that I get this - vdefault can be called from anywhere.
A VCC constructor must be private - because we want to move to a factory method
model.
Longer term, post-MVT, valhalla value types for which we will have javac support and
will derive the box from the value type - those constructors would also be private.

thanks,
Karen
> 
> In fact, all constructors must be private in a VCC.  The reason is to prevent
> client code from calling "new VCC" directly (as "new;dup;invokespecial<init>").
> That in turn prevents clients from creating their own fresh VCC identities.
> It doesn't prevent those identities from coming into being other ways, but
> makes it clear that there is no first-class API for creating a box that you can
> view as "all your own”.
> 
> Instead, VCC authors are forced to write factory methods.  And those will
> typically never (well, maybe rarely) make guarantees about creating fresh
> object identities.

> 
> — John