<div dir="ltr">For your information, John Rose has recently written a few essays on layout of flattened values in the VM: <a href="https://cr.openjdk.org/~jrose/values/flattened-values.html">https://cr.openjdk.org/~jrose/values/flattened-values.html</a><div>Also another recent article discussing loose consistency (old "primitive classes"): <a href="https://cr.openjdk.org/~jrose/values/loose-consistency.html">https://cr.openjdk.org/~jrose/values/loose-consistency.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 22, 2024 at 9:37 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <font size="4" face="monospace">There are no restrictions in the
      specification.  However, the object layout algorithm is already
      quite complicated, so it is possible there will be implementation
      limitations, at least at first.  </font><br>
    <br>
    <div>On 5/19/2024 12:18 AM, John Bossons
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Thanks for the confirmation. Good news!
        <div><br>
        </div>
        <div>As to 'no restrictions' re size (horizontal - number of
          fields), fine. But what about depth (vertical - fields that
          are value objects that in turn contain fields that are value
          objects etc. all the way down)? No constraint on depth of
          nesting? </div>
        <div>
          <div><br>
          </div>
          <div><br>
            <div><br>
            </div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sat, May 18, 2024 at
          8:21 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div> <font size="4" face="monospace">Amazingly, yes,
              value-capable abstract classes can have fields.  We
              thought for many years this would never be possible; the
              Great Initialization Alignment (eliminating `vnew` and
              `withfield` in favor of the `new` and `putfield` approach)
              made this possible.  <br>
              <br>
              The language imposes no restrictions on the number of
              fields of value types.  The VM reserves the right to
              flatten, or not, based on its whims.  One likely whim is
              that "large" values are usually not worth flattening.  But
              this is invisible to the user; the semantics are the same
              whether or not the object is flattened.<br>
            </font><br>
            <div>On 5/18/2024 1:24 PM, John Bossons wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div>Thanks for making this so very clear.</div>
                <div><br>
                </div>
                Two questions/issues:
                <div>(1) It would be helpful to include more on the
                  properties of abstract value classes (AVCs) -- perhaps
                  a labelled subsection? A specific question not dealt
                  with explicitly in the current version: Can an AVC
                  have an instance field, now that a value class
                  utilizes the Flexible Constructor Bodies JEP? (The
                  alternative is  repetition of that field definition
                  and accessor in every subtype, which is potentially
                  error-prone). </div>
                <div>(2) It would also be helpful to include some
                  commentary on limitations.</div>
                <div>Specifically, although it is clear that the purpose
                  is more efficiently defined SMALL value objects, (a)
                  How big is 'small'? And (b) will the compiler accept
                  value types of any size, no matter how deep?</div>
                <div><br>
                </div>
                <div>John</div>
                <div>
                  <div><br>
                  </div>
                  <br>
                  <div dir="ltr" class="gmail_signature">
                    <div dir="ltr">Phone:  (416) 450-3584 (cell)</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      <span class="gmail_signature_prefix">-- </span><br>
      <div dir="ltr" class="gmail_signature">
        <div dir="ltr">Phone:  (416) 450-3584 (cell)</div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>