Valhalla Minimal Value Types review invitation

Wed Apr 26 14:47:14 UTC 2017

> Next meeting: Wednesday April 26, 9am PT: 
> 
> NEW DIAL-IN: https://oracle.zoom.us/j/251372518 <https://oracle.zoom.us/j/251372518>
Rough initial cut at load/link/init proposal - one potential topic for today’s agenda.

Class Load, Link, Init Behavior Goals for VCC and DVT for Minimal Value Types 1.0:

MVT Assumptions:
VCC can not have a nullary constructor.
DVT does not have a <clinit> nor an <init> method.

Behavior Goals for contained value types for load, link, init:

I. Resolution of a VCC or DVT, i.e. classfile contains an LFoo or QFoo:
  Resolve a VCC: (LFoo)
    1. load VCC
       annotation based: derive DVT class with an internal name  - eagerly load DVT
    2. link VCC
       does not trigger linking of DVT
    3. initialization of VCC
       triggered by: new, static bytecodes
       does not trigger initialization of DVT

  Resolve a DVT: (QFoo)
    1. load DVT
       first load VCC, which derives and loads DVT

    2. link DVT
       first link VCC

    3. initialize DVT
       first initialize VCC
         what triggers initialization of DVT?
           normally: new, static bytecodes - these are invalid for DVT
           vdefault
           vunbox
           anewarray/multianewarray on a DVT element type

Open for Discussion:
  The proposal is that you must not only load a DVT element of an array, you must also link and
  initialize the DVT element.
  Otherwise you would need to link and initialize the DVT element on the first vaload,
  in case you did not perform a prior vastore.
  The verifier could ensure that you perform a prior vastore, in which case you would only
  need to load the DVT element of an array, not link and initialize it.

II. Instance creation of a DVT, DVT has no <init>
Creation of a default value type instance: which is all 0s in memory to represent
the 0 or 0.0 or null value for fields of the DVT

Triggered by:
  1) vdefault
  2) anewarray/multianewarray on a derived value type
    - creates a value array which is all 0s in memory representing the flattened
    elements of the array
    - which does not entail invoking any constructor on the VCC
  3) vunbox
  4) internal implementation details such as copying a DVT - all of which imply that
     the DVT is already initialized
It is required that the DVT is in the initialized state prior to the creation of a
default value type instance.

III. "uninitialized" value type/ partially initialized value type
There is no such thing as an uninitialized value type.
vdefault and anewarray/multianewarray can be invoked from anywhere.

QUESTION: vwithfield: is this restricted to invocation within the DVT?
(For MVT, this would also be within the VCC)
That would allow the wither or instance factory to decide whether
a partially initialized value type would be returned if there were
an exception.

IV. DVT in a Container: other object, other DVT
   Class contains a DVT  field
      - QUESTION: is this supported via bytecodes?

   For MVT, since we do not flatten DVT fields in objects or in other DVTs, then we
   do not require preloading of DVT classes used to define fields.

thanks,
Karen

> On Apr 21, 2017, at 3:14 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Next meeting: Wednesday April 26, 9am PT: 
> 
> NEW DIAL-IN: https://oracle.zoom.us/j/251372518 <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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170426/9bcf3dc8/attachment-0001.html>