User model stacking: current status

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Tuesday, June 14, 2022 3:16:41 PM
> Subject: Re: User model stacking: current status

[...] 

>>> Summary:

>>> class B1 { }
>>> value class B2 { private class val { } }
>>> value class B3a { }
>>> non-atomic value class B3n { }

>>> Value class here is clearly the star of the show; all value classes are treated
>>> uniformly (ref-default, have a val); some value classes encapsulate the val
>>> type; some value classes further relax the integrity requirements of instances
>>> on the heap, to get better flattening and performance, when their semantics
>>> don't require it.

>>> It's an orthogonal choice whether the default is "val is private" and "val is
>>> public".
>> It makes B2.val a reality, but B3 has no sane default value otherwise it's a B3,
>> so B2.val should not exist.

> Let me try explaining again.

> All value types have .ref and .val types. They have the properties we've been
> discussing for a long time: ref types are references, and are therefore
> nullable and atomic; val types are direct values, are not nullable, and are
> _not necessarily_ atomic.

> We've been describing B2 classes as those with "no good default", but that
> doesn't mean that they can't have a .val type. It means we *can't trust
> arbitrary code to properly initialize a B2.val type.* Once initialized, B2.val
> is fine, and have the benefit of greater flatness. We explored language and VM
> features to ensure B2.val types are properly initialized, but that ran into the
> rocks.

> But we can allow the B2 class itself to mediate access to the .val type. This
> has two benefits:

> - We can get back some of the benefit of flattening B2.val types
> - Uniformity

> Here are two examples of where a B2 class could safely and beneficially use
> B2.val:

> value class Rational {
> Rational[] harmonicSeq(int n) {
> Rational.val[] rs = new Rational.val[n];
> for (int i=0; i<n; i++)
> rs[i] = new Rational(1, n);
> return rs;
> }
> }

> Here, we've made a _flat_ array of Rational.val, properly initialized it, and
> returned it to the user. THe user gets the benefit of flatness, but can't screw
> it up, because of the array store check. If Rational.val were illegal, then no
> array of rationals could be flat.
but you are leaking Rational.val as the class of the array, so one can write 
var array = Rational. harmonicSeq(3); 
var array2 = Arrays.copyOf(array, array.length + 1); 
var defaultValue = array2[array2.length - 1]; 

Currently we live in a world where apart of using jdk.unsupported, there is no way to get an uninitialized object even by reflection, 
you propose to shatter that idea and to allow to bypass the constructor and have access to the default value directly in the language. 

I think it may be reasonable to allow access to Rational.val through a specific reflection API but it means disallowing some methods like Arrays.copyOf() and add more like createAValueArrayFromAnExistingRefArray(), but accessing directly to B2.val is just a big security hole. 

> Similarly, a nestmate could take advantage of packing:

> value class Complex {
> value class C3 {
> Complex.val x, y, z;

> ...
> }

> C3 c3(Complex x, Complex y, Complex z) { return new C3(x, y, z); }

> }

> C3 gets the benefit of full flattening, which it can do because its in the nest;
> it can share the flattened instances safely with code outside the nest.

> (Access control is powerful thing.)
and it's hard to get it right. 

regards, 
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20220614/fd657101/attachment-0001.htm>