Initial feedback on Minimal Value Types 0.2 for discussion

[forax at univ-mlv.fr]

> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: forax at univ-mlv.fr
> Cc: "Karen Kinnear" <karen.kinnear at oracle.com>,
> valhalla-spec-experts at openjdk.java.net
> Envoyé: Mardi 28 Mars 2017 23:01:29
> Objet: Re: Initial feedback on Minimal Value Types 0.2 for discussion

> On 28/03/17 21:47, forax at univ-mlv.fr wrote:

>>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr> , "Karen Kinnear" <karen.kinnear at oracle.com>
>>> Cc: valhalla-spec-experts at openjdk.java.net
>>> Envoyé: Mardi 28 Mars 2017 22:43:36
>>> Objet: Re: Initial feedback on Minimal Value Types 0.2 for discussion

>>> What I really meant with that comment is that, I think we should expect that
>>> once boxed values are stored in locals, their identity stays the same.

>>> In other words:

>>> o == o

>>> should always be true, regardless of values, refs, boxing.
>> Ok, in that case, what about

>> (Object)v == (Object)v

> :-)

> That doesn't worry me. That is free to be as unstable as it is with numeric
> boxes today:

> int i1 = 42
> (Object)i1 == (Object)i1 //true

> int i2 = 42000
> (Object)i2 == (Object)i2 //false

> In other words - I'm ok with existing mode of failures - I'm not ok with _new_
> mode of failures, such as the ones I was describing.
it's worst than that, the JLS says that the value between -128 and 127 are shared, but did not say that the other values are not shared, 
you can test with 
java --XX:AutoBoxCacheMax=43000 ... 

so the anwser for 
(Object)i2 == (Object)i2 
is maybe true, maybe false. 

> Maurizio
Rémi 

>>> Maurizio
>> Rémi

>>> On 28/03/17 21:37, Remi Forax wrote:

>>>> 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.

>>>> Rémi

>>>>> De: "Karen Kinnear" <karen.kinnear at oracle.com>
>>>>> À: "Bjorn B Vardal" <bjornvar at ca.ibm.com>
>>>>> Cc: valhalla-spec-experts at openjdk.java.net
>>>>> 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 oracle.com > 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 oracle.com > 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 ca.ibm.com > 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 oracle.com >
>>>>>>>>> Sent by: "valhalla-spec-experts" <
>>>>>>>>> valhalla-spec-experts-bounces at openjdk.java.net >
>>>>>>>>> To: John Rose < john.r.rose at oracle.com >
>>>>>>>>> Cc: valhalla-spec-experts at openjdk.java.net
>>>>>>>>> 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 oracle.com > wrote:
>>>>>>>>>> (This is a resend of an email I sent to valhalla-dev at openjdk.java.net on January
>>>>>>>>>> 23)
>>>>>>>>>> Review of Minimal Value Types August 2016 Shady Edition (v 0.2)
>>>>>>>>>> http://cr.openjdk.java.net/~jrose/values/shady-values.html
>>>>>>>>>> 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 oracle.com > wrote:
>>>>>>>>>>> On Aug 31, 2016, at 11:59 PM, John Rose < john.r.rose at oracle.com > wrote:
>>>>>>>>>>>> I have updated of this document to reflect comments so far.
>>>>>>>>>>>> It is stored to CR (in place) and enclosed here.
>>>>>>>>>>>> — John

>>>>>>>>>>>> Link: http://cr.openjdk.java.net/~jrose/values/shady-values.html

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