<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Apr 19, 2017, at 8:16 AM, Bjorn B Vardal <<a href="mailto:bjornvar@ca.ibm.com" class="">bjornvar@ca.ibm.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Arial, Helvetica, sans-serif; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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<span class="Apple-converted-space"> </span><span style="font-family: 'Courier New', Courier, monospace;" class="">"vdefault; vunbox;"</span>.</div></div></blockquote><div><br class=""></div>Correct.  As in C#, a value type always has a system-supplied nullary constructor</div><div>which cannot be replaced by the user.  Given the ubiquitous access to "vdefault"</div><div>(by both the instruction and by sampling unassigned fields and array elements)</div><div>there is a huge potential performance cost (plus bootstrapping problems) if we</div><div>allow users to supply computed bit patterns at all variable creation points.</div><div>It's not just bit-blt, either, since if the computed patterns have non-null managed</div><div>pointers in them, the JVM is likely to have to issue extra card mark operations.</div><div>It's a mess, and not worth it, so we just say a default value looks like a fresh</div><div>object, before any of its fields are initialized.</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" style="font-family: Arial, Helvetica, sans-serif; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">My question is, did we decide to restrict the accessibility of these constructors,</div></blockquote><div><br class=""></div><div>Yes, that's in the draft.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Arial, Helvetica, sans-serif; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote></div><br class=""><div class="">In fact, all constructors must be private in a VCC.  The reason is to prevent</div><div class="">client code from calling "new VCC" directly (as "new;dup;invokespecial<init>").</div><div class="">That in turn prevents clients from creating their own fresh VCC identities.</div><div class="">It doesn't prevent those identities from coming into being other ways, but</div><div class="">makes it clear that there is no first-class API for creating a box that you can</div><div class="">view as "all your own".</div><div class=""><br class=""></div><div class="">Instead, VCC authors are forced to write factory methods.  And those will</div><div class="">typically never (well, maybe rarely) make guarantees about creating fresh</div><div class="">object identities.</div><div class=""><br class=""></div><div class="">— John</div></body></html>