Valhalla EG notes Jan 16, 2019

[Karen Kinnear]

I see two options proposed:

Option 1: RefObject, ValObject - classes
   VM at class definition time replaces superclass of all existing classes from Object -> RefObject
   VM translates:
         new Object -> treated as Object.new() { returns RefObject.new() } // assume old code only wants references here
   risk: existing getClass.getSuper() assumptions

Questions:
   How would the VM translate new Object[] ?
     - we might want existing code to be able to handle all subtypes of the top type in the existing arrays
     - or erased generics will break

   If I wanted to instantiate a new top type which could hold either RefObject or ValObject, how would I do that?
   Object.new()? Object.newObject()

 Option 2: RefObject, ValObject - interfaces
   VM at class definition adds RefObject to all existing classes
   value classes required to declare ValObject as superinterface

   ackwardness: VM needs special behaviors for Object.wait, Object.notify - if dynamically a ValObject, throw IMSE
     instead of having that obvious from the implementation in a superclass.

Are there other concerns here?
This seems cleaner to me - especially since I also believe that synchronization on ValObjects will also require
special handling - which will be vm implementations rather than visible in java sources (exact plan is TBD).


Remi - L/Q signatures are orthogonal to the type hierarchy - they declare null-free or null-tolerant
   so Point.val and Point.box are both subclasses of ValObject

thanks,
Karen

> On Jan 30, 2019, at 10:21 AM, forax at univ-mlv.fr wrote:
> 
> 
> 
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Karen Kinnear" <karen.kinnear at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 30 Janvier 2019 00:29:01
> Objet: Re: Valhalla EG notes Jan 16, 2019
> On Jan 29, 2019, at 11:10 AM, Remi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>> wrote:
> 
> currently the result of the expression "new Object()" is a reference type, so it should be a RefObject, but we have created an Object not a RefObject,
> so it's at best weird.
> 
> I'd like to rationalize this in two steps.
> 
> First, allow `new I(x…)` where `I` is an interface,
> to be treated as shorthand for `I.F(x…)` where
> the method `F` is somehow declared by `I` as
> its canonical factory.  I'm thinking `List.of` is
> a good one.  (Maybe also extend this rule to classes
> with non-public constructors.)
> 
> Second, since `Object` is an honorary interface,
> change the meaning of `new Object()` to be
> `Object.newReference()` (or some such), by
> having `Object` declare `newReference` (of
> no arguments) as its canonical factory.
> 
> Moving `new` statements to factories is coherent,
> also, with changing the translation strategy for Java
> to deprecate the new/init dance outside of the class
> being constructed, and eventually make it illegal in
> bytecode outside of the nest of the class being made.
> In other words, if I could go back in a time machine
> and rewrite the translation strategy, I'd insist that
> each class (or the JVM itself) would define a canonical
> factory for each constructor of that class, and require
> all other classes to allocate via the canonical factory.
> The new/init dance would be legal inside the class
> but nowhere else.  That attack surface has been a
> painful one.  And value types have to use factories
> from the get-go, so we've got to figure it out sooner
> or later.  The name of the canonical factory can be,
> in fact, fixed as '<init>'.
> 
> so new Object() <==> Object.new() and
> class Object {
>   ...
>   public static Object new() { return ReferenceObject.new(); }
> }
> and the translation new Object() to Object.new() has to be done by the VM because there is already a lot of code that do a new Object().
> 
> 
> — John
> 
> 
> I think i still prefer having interfaces Val/Ref instead of classes, these interfaces can be injected by the VM, at least the Ref interface can be injected, for the Val interface, we can requires all value types to implement that interface.
> 
> Another question, we have two representations of a value class, the real value class and the nullable value class, the Q and the L classes, Point.val and Point.box, does Point.box a subtype of Val/ValObject ?
> 
> Rémi