Valhalla Minimal Value Types review invitation

[John Rose]

On Apr 19, 2017, at 8:16 AM, Bjorn B Vardal <bjornvar at ca.ibm.com> wrote:
> 
> I'm writing up my notes from the meeting, and I have a question about the box's no-arg constructor.  My notes say that this constructor is automatically provided and may not be replaced by the user. My understanding is that this is done in order to force the constructor to have the same behaviour as "vdefault; vunbox;".

Correct.  As in C#, a value type always has a system-supplied nullary constructor
which cannot be replaced by the user.  Given the ubiquitous access to "vdefault"
(by both the instruction and by sampling unassigned fields and array elements)
there is a huge potential performance cost (plus bootstrapping problems) if we
allow users to supply computed bit patterns at all variable creation points.
It's not just bit-blt, either, since if the computed patterns have non-null managed
pointers in them, the JVM is likely to have to issue extra card mark operations.
It's a mess, and not worth it, so we just say a default value looks like a fresh
object, before any of its fields are initialized.

> My question is, did we decide to restrict the accessibility of these constructors,

Yes, that's in the draft.

> and if so, what would be the reason to do this? As stated above, the default box can already be obtained by unboxing a default value.

In fact, all constructors must be private in a VCC.  The reason is to prevent
client code from calling "new VCC" directly (as "new;dup;invokespecial<init>").
That in turn prevents clients from creating their own fresh VCC identities.
It doesn't prevent those identities from coming into being other ways, but
makes it clear that there is no first-class API for creating a box that you can
view as "all your own".

Instead, VCC authors are forced to write factory methods.  And those will
typically never (well, maybe rarely) make guarantees about creating fresh
object identities.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170419/a4b1007a/attachment.html>