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.kinn...@oracle.com> > À: "Bjorn B Vardal" <bjorn...@ca.ibm.com> > Cc: valhalla-spec-experts@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.kinn...@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.kinn...@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 < bjorn...@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.kinn...@oracle.com > >>>>> Sent by: "valhalla-spec-experts" < >>>>> valhalla-spec-experts-boun...@openjdk.java.net > >>>>> To: John Rose < john.r.r...@oracle.com > >>>>> Cc: valhalla-spec-experts@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.kinn...@oracle.com > >>>>>> wrote: >>>>>> (This is a resend of an email I sent to valhalla-...@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.r...@oracle.com > wrote: >>>>>>> On Aug 31, 2016, at 11:59 PM, John Rose < john.r.r...@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.
