MVT April 26th notes

Karen Kinnear karen.kinnear at
Wed Apr 26 19:49:09 UTC 2017

Next meeting May 10th: dial-in:

Notes from April 26:
Attendees: Remi, Dan H, Bjorn, Doug, John, Vladimir, Frederic, Karen

1. John - please update Shady
2. All - please review email rough proposal for load/link/init behavior for MVT
3. Karen: work with Dan Smith to get him initial proposals for JVMS extensions for
   new bytecodes for chapters 4 and 6 and load/link/init for chapter 5
   get early drafts distributed for more general early review

1. Bjorn: Concern about new bytecodes
  - concern about limited available bytecodes for future
  - concern about tooling ecosystem - would it be better if we moved to an expected
    preferred form sooner, i.e. typed bytecodes?

Karen, Bjorn: both VM implementations use some bytecodes for internal quickening
Frederic: with typed bytecodes, the constant pool changes become more complex, which also
would be seen by the tooling ecosystem.

Remi: what if we had an experimental prefix?
John: Even if we moved to typed bytecodes today, we would still expect changes
  note: values are inherently polymorphic post MVT - e.g. interface support
  looking at a 6th BasicType. Interpreter will need to have full type information with the type,

2. Karen: MVT interface support
Last time we agreed that we need to support interfaces for MVT
Can we assume VCC will implement the interface and the DVT will NOT implement the interface

John: yes.

3. Karen: Do we have a need for a QFoo in a field descriptor?
We support QFoo in a method descriptor as well as [QFoo in a field descriptor.
Concern: reflection and tooling exposure to value types
Lesser concern: implementation complexity

Remi: If play with optional, want to store in a field (note: not supported today)
Remi: monad - not want to pay abstraction

Frederic: workaround is to use an array of 1 element
          given we are not flattening, there are no density or lack of indirection benefits of supporting
Doug: Ask Scala folks or Martin Hadusky (sp?)
John: propose as side project - i.e. target of opportunity, but not planned for MVT
Bjorn, Karen: have experimented with it, ok as side project

4. new root type for values
We needed this internally for LambdaForms to avoid specializing per value type.
Initially we are calling this java/lang/__Value
At this point this is not a global root, but a root for value types only
Exposing this so that MethodHandles can use this is a big step.

Packed Objects - initially were in a separate hierarchy, this was painful, so later rolled back in
Doug: "any" as a top type, folks will want exposure. This will change rules for dispatch and overload
   - looks inevitable
John: plan for longer term - If we were to add a QObject, which is a top type for all QTypes
      then a UType which is a tagged union of Q and L types (and maybe primitives?)
      we could perhaps expose LTypes with a different tag bit to the user
      note: LTypes can be null
            QTypes - not nullable, no guaranteed identity, immutable
            UType - might be nullable, or it might have identity - don't count on it, but must preserve it if
                    it carries an LType
Doug: could do monads with this scheme, could help switches and pattern matching
Remi: with Value Types already have tuples, do you still need a UType?

5. question from last tim about verifier checking for complete instances of values before letting them go.
John's answer: No - verification is not needed here. See next update of Shady.

[ed note: see load/link/init email proposal - I think we are in agreement that there is no such thing
as an uninitialized value type]

6. Packed Objects - See email from Bjorn on Packed Objects vs. Minimal Value Types
  Bjorn walked us through highlights - email questions welcome

minor notes: MVT allows off heap allocation today
Keep an eye on Method Builder recipes with bootstramethods to help with issues like generating equals, hashcode
etc. boilerplate

How did customers for PackedObjects repond to some of the accidental identity issues?
  - expectations of Object behaviors were a surprise, e.g. test cases failed due to accidental updates to a
  - in general customers got good results
    - e.g. power users explicitly controlled layout

John: Look into Panama experiments on persistent memory data structures

7. Nestmates
Can jvmti retransform change nestmate information?
Response: NO
Can you grow the membership list?
Not via retransform, run into issues if the member has already been loaded.

Remi: need to dynamically add to the nest
Karen: yes - if the host has defined a rule rather than a list (more advanced)
John: yes - see Lookup.defineClass - initially in 9, extending in future to allow
      temporary classes as well as adding nest members
(ed. note - thank you for the reminder John - using the Lookup Private access mode as
the author allowing classes as they are defined to be added to a nest)

Constant pool (CP)  patching plans?
John:goal is to not patch the CP, but rather find a way to pass user data
Dan: happier with a patch to a single field rather than CP extensions

John: head's up on another issue exp[loring - thread confinement
   - how to ensure that we can protect thread bound data - e.g. ByteBuffers in Panama
   - want first accessor as owner, other accessors, even readers to get an error rathern than block or race


> On Apr 26, 2017, at 10:47 AM, Karen Kinnear <karen.kinnear at> wrote:
>> Next meeting: Wednesday April 26, 9am PT: 
>> NEW DIAL-IN: <>
> 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 <mailto:karen.kinnear at>> wrote:
>> Next meeting: Wednesday April 26, 9am PT: 
>> NEW DIAL-IN: <>
>> (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 <mailto:john.r.rose at>> wrote:
>>> On Apr 19, 2017, at 8:16 AM, Bjorn B Vardal <bjornvar at <mailto:bjornvar at>> 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

More information about the valhalla-spec-observers mailing list