Re: Initial feedback on Minimal Value Types 0.2 for discussion

[Brian Goetz]

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.


Somehow, this question is like the proverbial elephant -- everyone sees 
the answer they want :)  What I took away was: there is no need to do 
anything special now for identity.  Some objects have what we might call 
"accidental identity", such as the result of boxing an int to an 
Integer, or capturing a lambda.  This identity is real -- if we 
construct an object with accidential identity, the user can rely on its 
stability, synchronize on it, etc (even if we think this is silly.)  The 
model we should pursue for value boxes is like Integer -- they have 
accidental identity, and that's OK.


It would be useful in the long term to have tooling (like an -Xx flag) 
that lets us detect how often box types like Integer are synchronized upon.


More generally, rather than trying to smooth the rough edges of identity 
(e.g., with heisenboxes, or with identity-resistent boxes), a better 
approach is to instead strive for _less boxing_.  The exploration of U 
types promises to eliminate a category of box operations (by deferring 
them in the hopes they are not ultimately needed), and future efforts on 
generics over values also dramatically reduces the sources of boxing.  
Ultimately, we hope to get boxing down to the truly dynamically typed 
APIs -- such as reflection -- at which point accidental identity as a 
problem largely goes away.

Re: Initial feedback on Minimal Value Types 0.2 for discussion

[Karen Kinnear]

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 
>> <mailto: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 
>>> <mailto: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 
>>> <mailto:karen.kinn...@oracle.com>>
>>> Sent by: "valhalla-spec-experts" 
>>> <valhalla-spec-experts-boun...@openjdk.java.net 
>>> <mailto:valhalla-spec-experts-boun...@openjdk.java.net>>
>>> To: John Rose <john.r.r...@oracle.com <mailto:john.r.r...@oracle.com>>
>>> Cc: valhalla-spec-experts@openjdk.java.net 
>>> &

Re: Initial feedback on Minimal Value Types 0.2 for discussion

[Bjorn B Vardal]

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årdalJ9 Java Virtual Machine DeveloperIBM Runtimes
 
 
- Original message -From: Karen Kinnear Sent by: "valhalla-spec-experts" To: John Rose Cc: valhalla-spec-experts@openjdk.java.netSubject: Re: Initial feedback on Minimal Value Types 0.2 for discussionDate: 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  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 debuggersJohn: 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 modificationJohn: 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