Initial feedback on Minimal Value Types 0.2 for discussion

Remi Forax forax at
Tue Mar 28 20:37:39 UTC 2017

Question, why a value type can not loss identity inside a method ? 
Is it true for local variable access ? for field access ? for static access ? 

V value = ... 
Object o = v; 
Object o2 = v; 
o == o2 ?? 

field.o = v; 
o == field.o ?? // what about the concurrent access 

Class.o = v; 
o == Class.o ?? 

I also wonder if it will not have an impact regarding OSR when part of the code is in the interpreter and part of the code is JITed. 


> De: "Karen Kinnear" <karen.kinnear at>
> À: "Bjorn B Vardal" <bjornvar at>
> Cc: valhalla-spec-experts at
> Envoyé: Mardi 28 Mars 2017 20:45:06
> Objet: Re: Initial feedback on Minimal Value Types 0.2 for discussion

> Summary notes from meeting 3/15/17:
> attendees: Brian, Doug Lea, Stas, Frederic, Bjorn, Tobias, Mr Simms, Vladimir I,
> Maurizio, Karen, John

> 1. Identity Major decision:
> Doug: It is ok if a value type box does NOT retain identity.
> Do not be overly concerned with sync, ===, hashcode. Let’s see if the benefits
> outweigh the problems.
> We need to set clear expectations for customers.

> ed. note: Maurizio clarified later that it is critical that a value type not
> lose identity within
> a given method, but it is ok to lose identity across methods.

> It is ok if the vm throws an exception - e.g. IllegalMonitorStateException when
> attempting to lock a Value Type,
> ok if we do that based on a command-line flag to not slow down normal execution.

> 2. Evolution approach
> can evolve experimental annex to JVMS - optional to implement, with minor change
> to classfile, byte codes, etc.
> no story for experimental JLS
> Doug suggested: could have an experimental javac documentation

> 3. vdefault/vwithfield
> - constructor as static factory method
> - vdefault - create 0-filled default value type
> - only valid within constructor
> - note a value type array - initial array allows default value to escape
> - vwithfield - copy-on-write a new value type with one modified field
> - allows final fields to be final (value type is immutable)
> - JIT can optimized via escape analysis
> - only within value class (which means both the value capable class and the DVT)

> 4. Requested Extensions:
> - exploring adding references - both IBM and Oracle believe customers will need
> this for use cases
> - support for VCC implementing interfaces - do users need this?
> - propose: go to Early Access without this and see if it is required

> - IBM and Oracle investigating
> - note: VM would do no magic boxing, and for MVT, would require boxing to invoke
> default methods
> 5. Packed Objects:
> AI: IBM - Doug requested a summary of differences between PackedObjects and MVT
> John note: Packed Objects have identity, others see changes through the
> reference

> 6. JVMS changes:
> AI: Oracle - need to propose a draft for the JVMS extensions

> 7. early access timing:
> Note: need to ensure that IBM and Oracle are in sync on Early Access timing

> Meeting March 29th - need to discuss any other Shady Values version 0.2 changes
> and
> timing.

> *** will need a Shady Values update ***

> thanks,
> Karen

>> On Mar 15, 2017, at 1:20 AM, Karen Kinnear < karen.kinnear at > wrote:

>> Summary notes from meeting 2/15/17 - embedded below, starting with #8

>> Meeting 3/16/17:
>> — there are a few more already identified topics to discuss
>> — welcome additional questions/suggestions
>> — a couple of topics to revisit (or perhaps put on an open issues list until we
>> have more information or feedback)

>> thanks,
>> Karen

>>> On Feb 10, 2017, at 9:47 AM, Karen Kinnear < karen.kinnear at > wrote:

>>> John - please correct

>>> Bjorn,

>>> Good question. This was news to us as well, so John will have the final word.

>>> My assumption is that he means that:
>>> If you create an array of Value-Capable-Classes that you would not automagically
>>> also create an equivalent
>>> array of the Derived Value Types.
>>> That the MethodHandle APIs could explicitly, through new byte codes create
>>> arrays of the DVTs by passing a
>>> Derived Value Type as the “array ref” to anewarray or multianewarray.
>>> I presume that any explicit byte code generation by power users to go with this
>>> code could use the same mechanism.

>>> thanks,
>>> Karen

>>>> On Feb 9, 2017, at 10:56 PM, Bjorn B Vardal < bjornvar at > wrote:

>>>> Karen / John: Can you clarify this? Do you mean that they will only be flattened
>>>> when created using the reflection / MethodHandle API?
>>>> > John: MVT 1.0 will only flatten arrays reflectively
>>>> --
>>>> Bjørn Vårdal
>>>> J9 Java Virtual Machine Developer
>>>> IBM Runtimes

>>>>> ----- Original message -----
>>>>> From: Karen Kinnear < karen.kinnear at >
>>>>> Sent by: "valhalla-spec-experts" <
>>>>> valhalla-spec-experts-bounces at >
>>>>> To: John Rose < john.r.rose at >
>>>>> Cc: valhalla-spec-experts at
>>>>> Subject: Re: Initial feedback on Minimal Value Types 0.2 for discussion
>>>>> Date: Thu, Feb 9, 2017 6:31 PM

>>>>> Notes from discussion on Feb 01,2017. Feedback welcome.
>>>>> John - one question extracted at the top from the embedded notes.

>>>>>> 11. "interfaces (especially with default methods)"
>>>>>> - please change p.6 to clarify that there are no value type interfaces period.

>>>>> Ed note: There is a distinction here between
>>>>> 11a) defining an interface as a VCC with a derived DVT and
>>>>> 11b) whether the POJO which defines the VCC can implement interfaces. This
>>>>> discussion was about whether
>>>>> a POJO which defines the VCC can implement interfaces.
>>>>> John: MVT 1.0 : No value capable interfaces for JVMT 1.0.
>>>>> Ed note: was this the answer to 11a or 11b above please?

>>>>>> On Feb 9, 2017, at 5:43 PM, Karen Kinnear < karen.kinnear at > wrote:
>>>>>> (This is a resend of an email I sent to valhalla-dev at on January
>>>>>> 23)
>>>>>> Review of Minimal Value Types August 2016 Shady Edition (v 0.2)
>>>>>> Questions/Comments:
>>>>>> abbreviations used: VCC: value-capable class, DVT: derived value type
>>>>>> 1. Goals
>>>>>> -- might be worth adding to the bullets:
>>>>>> Allow use of existing toolchain where possible including IDEs and debuggers

>>>>> John: this is just a review comment, no discussion required.
>>>>>> 2. Features:
>>>>>> "Three" bytecode instructions ->"A small set of”

>>>>> John: just a text edit to encompass extensions in #12 below, not yet discussed
>>>>> as a group.
>>>>>> 3. Typically, value-capable classes will not be exported.
>>>>>> Is the reason for this to limit exposure since the expectation is that the
>>>>>> initial APIs and mechanisms will change?

>>>>> John: “yes”. This does not have to be enforced in the implementation.
>>>>> ed. note: perhaps we could remove this from the MVT specification.
>>>>>> 4. Value-capable classes: supporting methods
>>>>>> p.3 "This design endows both boxes and pure values with a common set of methods;
>>>>>> it "lifts" box methods
>>>>>> onto the derived values."
>>>>>> p.5 "The synthetic class has the given fields (unchanged) and has no methods"
>>>>>> p.5 "Meanwhile, all methods (and other class features) stay on the value-capable
>>>>>> class. The value type
>>>>>> proper is just a "dumb struct" containing the extracted fields"
>>>>>> - given that in the MVT model we are starting with a POJO box, and instance
>>>>>> methods that clearly
>>>>>> take an Object as a receiver, one proposal for the initial MVT approach would be
>>>>>> to have
>>>>>> all methods only supported by the box, and require boxing to invoke any methods
>>>>>> - so I think the first quote would need either removal or modification

>>>>> John: agreed.
>>>>> Karen: See #9 below: Evolved proposal would keep the POJO, which we call the
>>>>> Value Capable Class (VCC) unchanged,
>>>>> and derive a Derived Value Type (DVT) which would only contain a copy of the
>>>>> immutable instance fields, i.e. be
>>>>> a “dumb struct”.
>>>>> Bjorn: In this model, the source class would be the same as the box class, if we
>>>>> leave the instance fields in it. And we
>>>>> would box to invoke methods for the MVT 1.0 timeframe.
>>>>> John: Agreed.
>>>>> John: Longer-term - will want to invoke methods on values as soon as we can. We
>>>>> will need source support for that.
>>>>> John: Minimal Value Type (MVT) programming models:
>>>>> 1) source — only works for boxes
>>>>> 2) Method Handle reflection - for early adopters
>>>>> 3) bytecodes
>>>>> The MethodHandle/ValueFactory approach is clearly described.
>>>>> The language and byte code we will use longterm are still uncertain.
>>>>> Bjorn: What would be enabled by having all members in the value vs. just the
>>>>> [instance] fields in the value?
>>>>> Karen: Challenge is instance methods, where the type of the receiver is expected
>>>>> to be a VCC, not a DVT. This same
>>>>> expectation applies to any method called from the instance method, or any field
>>>>> in which the receiver is stored.
>>>>> John: we are using existing javac support, therefore we need to define value
>>>>> types indirectly, box first. This is not the longterm plan.
>>>>> MethodHandles will provide a direct way of speaking of the values. The
>>>>> MethodHandle runtime will spin byte codes.
>>>>> Maurizio: it is easy to just map the fields
>>>>> Karen: Methods are coded on the box. Static fields we left on the box. So we
>>>>> just lift the instance fields.
>>>>> John: We box the value to run methods. We want to preserve “vagueness”.
>>>>> Legacy code could misuse identity e.g. equals, hashcode, sync
>>>>> This only works for early adopters who are aware of value-capable-class
>>>>> identitylessness and implications
>>>>> Maurizio: If you pass the VCC to another method you are passing the box and no
>>>>> mechanical transformation is needed.
>>>>> Karen: You could have a problem if you were to pass the DVT as an argument when
>>>>> an object is expected
>>>>> John: clarify distinction between QType and LType
>>>>> QType: no identity, not nullable, not shared visible state, no sync, no
>>>>> reference equality
>>>>> LType: identity, nullable, shared visible state for sync and reference equality
>>>>> semantic mismatch: nulls, if_acmp_eq/ne
>>>>> MVT provides a short-term hack - which is ok for early adopters
>>>>> in future expect explicit boxes for QTypes which are LTypes which actually are
>>>>> identityful unlike the temporary VCCs
>>>>> Bjorn: differences between QTypes and LTypes like int and Integer, where only
>>>>> Integer provides methods?
>>>>> John: short-term there will be no methods on a DVT.
>>>>> longer-term value types will have methods
>>>>> verifier will not accept LType for a QType byte code
>>>>> Bjorn: if QType is a subset of an LType is it ok to convert?
>>>>> John: want ability farther future to have different behaviors and different
>>>>> stack representation.
>>>>> In progress, exploring possibly interpreter implementations, things like
>>>>> allowing the vm to buffer QTypes off the java heap
>>>>> presumes a universal type must declare whether it has identity or not
>>>>> Bjorn: with boxing and unboxing, if you say you have “no identity” do you still
>>>>> have something?
>>>>> John: must box to call a method, no one can rely on the identity so you can
>>>>> elide it.
>>>>> Ed note: this is only possibly temporarily because the value-capable-class is
>>>>> defined as not being able to rely on identity.
>>>>> This will not carry over to a more general value type approach if we wish to
>>>>> have value types box to identityful LTypes which
>>>>> can be used by existing code that is expecting a subtype of Object or an
>>>>> Interface as defined today.
>>>>> John: after MVT 1.0, exploring a union type, “UType” which is a common type that
>>>>> could contain either a QType or its corresponding
>>>>> LType

>>>>>> 5. Value bytecodes
>>>>>> p.11 "Method handles and invokedynamic will always allow bytecode to invoke
>>>>>> methods on Q-types".
>>>>>> - is this still accurate in the context above? I know the comment says that
>>>>>> internally
>>>>>> the MH might box the Qtype, but do we still want to support MH and indy to
>>>>>> appear to invoke methods on Q-types?

>>>>> Ed note: I don’t if we answered this question.
>>>>>> 6. Restrictions on the POJO:
>>>>>> A. It would help to have a bulleted list of restrictions
>>>>>> B. Clarify error/exception to throw - perhaps ClassFormatError for all of these?
>>>>>> C. Request to not support VCC on interfaces at all for MVT 1.0
>>>>>> I know the restrictions are intermixed in the text today. This is what I
>>>>>> extracted:
>>>>>> (p.3-4, 6)
>>>>>> VCC (and probably going forward)
>>>>>> 1. VCC superclass must be Object (and should be omitted)
>>>>>> 2. the class must be final
>>>>>> 3. all fields must be final
>>>>>> - please clarify - all instance fields must be final

>>>>> John: yes
>>>>>> 4. all constructors private

>>>>> Maurizio: why?
>>>>> Note that there is NO constructor for the DVT. It can be created via a vunbox or
>>>>> vdefault + vwithfield
>>>>> John: ok to change the spec so the VCC constructor is not limited to being
>>>>> private.
>>>>>> 5. must replace equals, hashcode, toString (with current Object syntax)
>>>>>> 6. may not use any methods provided on Object
>>>>>> specifically: may not use clone, finalize, wait, notify, notifyAll (directly)
>>>>>> 7. may use getClass
>>>>>> MVT 1.0 additional limitations
>>>>>> 9. may contain primitive instance fields, but no reference instance fields
>>>>>> - please update document to clarify this restriction is for instance fields only

>>>>> Karen: both IBM and Oracle JVM engineers are interested in an optional extension
>>>>> to support
>>>>> references instance fields.
>>>>> Maurizio: If only primitives allowed, then no support for generics is needed.
>>>>> Clarification for Karen: statics can have generics with erasure today, but can
>>>>> not mention type variables. (thanks :-)
>>>>> Bjorn: With today’s erased generics, this is not a problem
>>>>> John: Ok to explore having references in instance fields, generics are ok. No
>>>>> type variables in instance fields
>>>>> and no “any” generics.

>> 2/15/17: rediscussed:
>> Maurizio - higher perceived benefit to users to have reference fields in VCC/DVT
>> - e.g. Strings
>> John concern: hard to do embedded references in values
>> Mr Simms: almost have it now
>> — agreed: let’s give it a short

>>>>>> 10. may not contain generic instance fields
>>>>>> - please update document to clarify this restriction is for instance fields only
>>>>>> - it is my understanding that you can’t have generic static fields at all
>>>>>> 11. "interfaces (especially with default methods)"
>>>>>> - please change p.6 to clarify that there are no value type interfaces period.

>>>>> Ed note: There is a distinction here between
>>>>> 11a) defining an interface as a VCC with a derived DVT and
>>>>> 11b) whether the POJO which defines the VCC can implement interfaces. This
>>>>> discussion was about whether
>>>>> a POJO which defines the VCC can implement interfaces.
>>>>> Karen: concern about setting expectations. Current interfaces assume identity.
>>>>> Maurizio: could always box to call interface methods.
>>>>> John: Question: do early adopters need interfaces?
>>>>> Vladimir Ivanov: Yes
>>>>> note: Vector API has no benefits using MVT 1.0.
>>>>> Ed note: later email clarification from Vlad:
>>>>> Interface-based Vector API version [1] does not benefit from MVT 1.0. All
>>>>> operations are expressed as interface
>>>>> calls and require vector boxes.
>>>>> That is out of scope for MVT 1.0.
>>>>> Vectors exploring an alternative API, exposing operations as MethodHandles. This
>>>>> is less convenient to use, but
>>>>> allows experimenting to find performance benefits.
>>>>> John: MVT: box to get to methods. Longterm get to call I.defaultmethod without
>>>>> boxing
>>>>> Ed. note: Interface default method will need restrictions.
>>>>> John: MVT 1.0 : No value capable interfaces for JVMT 1.0.
>>>>> Ed note: was this the answer to 11a or 11b above please?

>> I believe John agreed that we can not use a VCC/DVT to define an interface

>> Open Question:
>> Do we need VCC/DVT to support interfaces and require boxing to invoke default
>> methods?
>> Perhaps try early access without support for interfaces and get feedback?

>> Concerns: existing interfaces with default methods - assume identity
>> Longer-term interfaces that can be implemented by valhalla value types will need
>> to be
>> special interfaces which support UTypes - union of LType and QType - so that
>> they
>> can be implemented by references or by value types.
>> UType - must not assume identity, must retain identity if it has it
>> QType - not assume identity
>> LType - must preserve identity
>> John/Brian - outline of road ahead - post MVT 1.0 - looking at a potential
>> carrier or wrapper for
>> an “any” type
>> Dan: If a local is a UType - will enforce single type through program?
>> John: simple answer - not fixed type slots
>> Dan: verification issues
>> John: like a cast - must be explicit in byte codes and it might fail
>> LType-> UType always valid, UType-> LType might fail

>>>>> John: longer-term:
>>>>> L-Type: always identity
>>>>> Q- Type: never identity
>>>>> U-Type: do not assume identity, must preserve identity

>>>>>> 12. 0.2 version states: may not contain a value class as an instance field
>>>>>> - see below for further discussion

>>>>>> 7. potential extensions:
>>>>>> 12. 0.2 version states: value class may not contain a value class as an instance
>>>>>> field
>>>>>> - we would like to propose supporting this - perhaps as an optional extension?
>>>>>> - we would need to add an exception for handling circularity
>>>>>> - note: no way to express this in java, but you could express in a classfile

>>>>> John: NO for MVT 1.0. Potential ambiguity whether the field contains a value
>>>>> capable class or a derived value type
>>>>> javac just deals with boxes, so no flattening here. Wants same layouts whether
>>>>> boxed or not.
>>>>> John: MVT 1.0 will only flatten arrays reflectively
>>>>> End of discussion
>>>>> thanks,
>>>>> Karen
>>>>> =======

>>>>>> 8. Splitting the value type from the object type
>>>>>> Propose not using the nested class approach, to not tie us into this
>>>>>> relationship longer term
>>>>>> - so remove example and the "looks like an inner class"
>>>>>> - note: a key point here is how the user generating bytecodes would know the
>>>>>> generated name of the DVT
>>>>>> This will need further discussion.
>>>>>> In the constant pool, references can use Qpackage.Class; rather than
>>>>>> Lpackage.Class;
>>>>>> Are there requirements for java sources to be able to refer to the derived value
>>>>>> type by name?
>>>>>> e.g. Class.forName()? If not, then perhaps the temporary naming convention could
>>>>>> be kept internal?

>> #8: not use nested class relationship between VCC and DVT:
>> Bjorn: not an issue either way
>> *** remove from spec: Does not belong in the spec - this is an implementation
>> detail
>> We don’t want to expose this as a nested class
>> - reflection might expose differently
>> - private static member access needs special handling, but not via javac
>> trampolines
>> - Minimal Value Types will to have nest mate support
>> Note: box must be in the same package & module
>> Need a way to mark the DVT - e.g. ACC_VALUE (other options ok)

>> Note : DVT name should not be exposed. Ok to use unsafe.defineAnonymousClass
>> to generate the DVT. The VM generates the DVT.
>> API ValueType.valueclass() returns, but doesn’t need to know how generated

>> Goal: VM’s problem to resolve QPoint descriptor reference to DVT for Point
>> *** add to spec: requirement: not want byte code to resolve LPoint$12345 (i.e.
>> a temporary name) - want ClassNotFound here

>>>>>> 9. Splitting the value type from the object type
>>>>>> p.5 "The original class is given a new synthetic field of the new value type, to
>>>>>> hold the state for the original class".
>>>>>> - to simplify implementation, and allow experiments which go beyond the initial
>>>>>> MVT plans, we propose
>>>>>> * that the VCC is left untouched
>>>>>> * the DVT has a copy of the immutable instance fields
>>>>>> - We think this qualifies as "any equivalent technique" on p.5
>>>>>> - the quote above would need modifying or removing

>> Agreed.

>>>>>> 10. Scoping of these features
>>>>>> - exploring adding class file capability bits for experimental features, as a
>>>>>> versioning approach
>>>>>> - we will want to pin this down later in the cycle

>> Brainstormed possibility of adding capability bits in minor version. Would need
>> to go through JCP.
>> editor’s note: may need to revisit this - turns out minor version 45.3 was
>> already used and set a precedent
>> that changes in a minor version would all be present in follow-on major
>> versions. So probably not in scope for MVT.

>>>>>> 11. JVM changes to support Q-types
>>>>>> - "So when the class loader loads an object whose fields are Q_types, it must
>>>>>> resolve (and perhaps load)
>>>>>> the classes of those Q_types, ..."
>>>>>> - for instance fields that are Q-types, I believe we need to explicitly specify
>>>>>> temporary JVMS load/link/init rules
>>>>>> (I will propose an early draft in a later email).
>>>>>> - e.g. Specifically, for instance fields that are Q-types, we would propose
>>>>>> requiring eager loading of the Q-types,
>>>>>> modifying JVMS 5.3.5 Deriving a Class from a class File Representation. Bullets
>>>>>> 3 and 4 described eager resolution
>>>>>> of the direct superclass and direct superinterfaces. The expectation is that an
>>>>>> additional bullet would be added
>>>>>> for direct instance fields that are Q-types.
>>>>>> - note that this change would make it the JVM's responsibility, not the class
>>>>>> loaders' responsibility,
>>>>>> to resolve the classes of those Q-types.
>>>>>> Note: in the JVMS load/link/init rules I will also propose VCC/DVT
>>>>>> load/link/init requirements.

>> Note: there are two discussions here relative to load/link/init rules.
>> One is for the DVT/VCC relationship.
>> Karen: always load VCC first
>> Bjorn: if MH API: always create VCC first
>> AI: Karen - send load/link/init proposal for MVT

>> Another is for flattening. Note VCC and DVT have the same field reference types,
>> which means no
>> QType fields, so no flattened fields in a DVT.

>> Note: VCC can not mention QTypes in source, since javac can not translate.

>> Bjorn: Can we use QTypes in descriptors of methods and fields if we spin byte
>> codes?
>> John: MethodHandles work with QTypes, therefore need an internal translation,
>> therefore need to
>> handle QTypes in descriptors, therefore ok to spin byte codes like MethodHandles
>> can.

>> This is not a gating goal for MVT, but is not forbidden.

>> Is it ok to flatten a QType field?

>> Maurizio:
>> VCC->DVT can NOT change descriptor, therefore can not contain a QType.

>> John: For MethodHandles and classes spun from byte codes with QType fields,
>> it is ok to flatten the QType.
>> - implementation choice.
>> - not required, but ok if not hard

>> (ed. note: I have other notes on flattening which I can not translate - if
>> others have notes
>> on non-array flattening please let me know)

>> We will however support flattening for arrays.
>> Ed note: thanks to Mr. Simms - he realized we need to initialize (and therefore
>> link) any value type that
>> is the element type for anewarray/multianewarray.

>> Array flattening:
>> this will not be done automagically
>> flatten array only if explicitly an array of value types, i.e.
>> anewarray/multianewarray with a DVT as the
>> objectref

>> TODO: open questions - need to investigate:
>> - Need to check how core reflection would deal with seeing an object that is a
>> DVTarray
>> - What does core reflection do if handed the j.l.Class for a DVT?
>> - Class.forName should not be able to find a j.l.Class for a DVT

>>>>>> 12. value bytecodes
>>>>>> - the following are useful in the MethodHandle implementation, and likely to be
>>>>>> useful for direct bytecode access
>>>>>> - we would like to propose the following as the minimal bytecode set:
>>>>>> in addition to vload, vstore, vreturn (and slot-specific variants)
>>>>>> - vdefault/vwithfield

>> open issue
>> Maurizio: nice on paper
>> In practice: challenges - vwithfield write to final field
>> note: all fields in DVT are final

>> If we do not provide vdefault/vwithfield, but only provide vbox/vunbox
>> MethodHandles will use unsafe to set fields and then unbox
>> ed. note - need to revisit

>>>>>> - vbox/vunbox

>> YES
>> Dan: what about a2b vs. vbox/vunbox?
>> ed note: we initially investigated a general a2b and we don’t yet have a good
>> way to define a CONSTANT_Type
>> or equivalent which we would need, so we found it easier to explicitly do
>> vbox/vunbox. (need to bring up in next meeting)

>>>>>> - vaload/vastore

>> YES

>>>>>> - vgetfield (fetch a field from a value type)

>> YES

>>>>>> - NOT vcmp_eq/ne (equality can be implemented as component-wise comparison)
>>>>>> clarify that for MVT 1.0, statics are only available through the box. (TODO:
>>>>>> where does this go in shady?)
>>>>>> 13. value bytecodes
>>>>>> - open issue
>>>>>> - typed prefix vs. vbytecodes for initial prototype
>>>>>> 14. Value bytecodes
>>>>>> use of Qtype as class component:
>>>>>> "Initially the only valid use of a Q-type [is] as the class component of a
>>>>>> CONSTANT_Methodref or CONSTANT_Fieldref
>>>>>> is as a CONSTANT_MethodHandle constant."
>>>>>> - if we extend the bytecodes as above, and we disallow anyone (MethodHandles,
>>>>>> bytecodes) from invoking methods on Qtypes, we
>>>>>> could modify this to disallow Q-types for CONSTANT_Methodref or
>>>>>> CONSTANT_InterfaceMethodRef completely.
>>>>>> - but perhaps you want the MethodHandles to be able to invoke methods on DVTs by
>>>>>> dynamically boxing them. This works as long
>>>>>> as the methods don't assume identity.
>>>>>> 15. Q-types and bytecodes
>>>>>> We propose modifying anewarray and multianewarray to allow operands that are
>>>>>> Q-types.
>>>>>> 16. Value Type Reflection
>>>>>> With the proposed modifications in #8 above: i.e. leaving the VCC untouched and
>>>>>> copying the
>>>>>> instance fields to the DVT, the VCC now matches the source file.
>>>>>> So Class.forName() would return the VCC which is the original POJO which fits
>>>>>> the backward compatibility model.
>>>>>> So we don't need a separate SourceClass, but leaving it in the proposal provides
>>>>>> implementation flexibility.
>>>>>> 17. Q-type method handles & behaviors "possible bytecode"
>>>>>> might want to change vnew to vdefault
>>>>>> these are samples and evolving, so maybe not worth changing
>>>>>> I did not do this level of detailed review for the Future Work yet.
>>>>>> thanks,
>>>>>> Karen

>>>>>>> On Sep 1, 2016, at 8:08 PM, John Rose < john.r.rose at > wrote:
>>>>>>> On Aug 31, 2016, at 11:59 PM, John Rose < john.r.rose at > wrote:
>>>>>>>> I have updated of this document to reflect comments so far.
>>>>>>>> It is stored to CR (in place) and enclosed here.
>>>>>>>> — John

>>>>>>>> Link:

>>>>>>>> <shady-values.html>
>>>>>>> I have updated the document again with small corrections and clarifications.

More information about the valhalla-spec-observers mailing list