<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div class="markdown-here-wrapper" data-md-url="" style="" markdown-here-wrapper-content-modified="true">
      <p style="margin: 0px 0px 1.2em !important;">On 24/03/2023 19:07,
        Glavo wrote:</p>
      <div class="markdown-here-exclude">
        <blockquote type="cite" cite="mid:CAJL5A3=E+1pD7AKffx7pSMksq6jGWhL8B39XidPbO0+b8MW8zg@mail.gmail.com">
          <div>2. StructLayout must manually specify all padding</div>
          <div><br>
          </div>
          <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
            <div>Can we provide a convenient method for automatically
              padding between fields based on alignment?</div>
            <div>The current structLayout method is annoying for
              situations where you need to manually simulate the layout
              of a C struct.</div>
          </blockquote>
          <div><br>
          </div>
        </blockquote>
      </div>
      <p style="margin: 0px 0px 1.2em !important;">I'd like to return to
        this topic, since we have spent some more time thinking about
        it.</p>
      <p style="margin: 0px 0px 1.2em !important;">First, we have added
        extra eager checks (as also suggested by Michael) so that
        non-sensical layouts are ruled out at creation:</p>
      <p style="margin: 0px 0px 1.2em !important;"><a href="https://git.openjdk.org/panama-foreign/pull/824" class="moz-txt-link-freetext">https://git.openjdk.org/panama-foreign/pull/824</a></p>
      <p style="margin: 0px 0px 1.2em !important;">On the topic of
        adding a more user-friendly struct factory, I am less convinced
        that such an API really belongs in MemoryLayout. First, memory
        layouts are fairly general, and can be used to model things that
        are <b>not</b> C structs. Consider this:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code class="hljs language-java" style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;display: block; overflow-x: auto; padding: 0.5em; color: rgb(51, 51, 51); background: rgb(248, 248, 248) none repeat scroll 0% 0%; -moz-text-size-adjust: none;">       structLayout(JAVA_LONG, JAVA_INT)
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;">This layout is valid,
        and you can dereference both struct fields w/o issues using var
        handles. That said, the size of this layout (12) is not a
        multiple of its alignment (8), so if you nest this layout inside
        a sequence layout, you would get an IllegalArgumentException.
        But you might never need to create an array of these things, in
        which case a memory layout such as the one above is perfectly
        sensible. The C language, on the other hand, enforce specific
        constraints on its structs - one such constraint is that all
        struct layouts must have a size that is a multiple of their
        alignment. Which means that the above struct layout does not
        correspond to any C struct declaration. <i>And that’s ok</i>.</p>
    </div>
    On top of that, even if C structs and FFM struct layouts agreed
    100%, it would still make sense for memory layouts to expose a “raw”
    struct layout factory, for clients (maybe tools?) wanting to
    validate the correctness of their assumptions. <br>
    <div class="markdown-here-wrapper" data-md-url="" style="" markdown-here-wrapper-content-modified="true"> <br>
      <p style="margin: 0px 0px 1.2em !important;">So, for the time
        being, I think it would be better to keep the FFM API the way it
        is, and have all the various layout factories act transparently
        in a “what you see is what you get” manner. The existing
        factories are meant to be primitive building blocks, and their
        primary goal is to be predictable, general and easy to
        understand. (After all, any non-primitive factory we might add
        in the future <i>needs</i> to be explained in terms of some
        simpler factory).<br>
      </p>
      <p style="margin: 0px 0px 1.2em !important;">Does this mean that
        there will never be higher-level functionalities? Not
        necessarily, even though such functionalities might well end up
        falling outside the scope of JEP 442 (and its predecessor JEPs).
        Some work Per did in this area [1, 2] shows that there are
        functionalities that are useful when working with layouts, even
        though we might not necessarily have found the best place where
        to put them. Also, I believe at some point there will be some
        story for <em>transforming</em> a layout into another, so again
        there’s a question of where to put some canned transforms (e.g.
        to swap endianness of all value layouts in a layout). I think a
        “higher-level” factory for creating C-like layouts belong in the
        same place as these functionalities. They are nice-to-have, but
        not “primitive” enough, I think, to deserve a spot in the
        MemoryLayout class (evidence of that is that it is fairly easy
        to build such a factory externally [3]).</p>
      <p style="margin: 0px 0px 1.2em !important;">Maurizio</p>
      <p style="margin: 0px 0px 1.2em !important;">[1] - <a href="https://git.openjdk.org/panama-foreign/pull/715" class="moz-txt-link-freetext">https://git.openjdk.org/panama-foreign/pull/715</a><br>
        [2] - <a href="https://github.com/openjdk/panama-foreign/pull/695" class="moz-txt-link-freetext">https://github.com/openjdk/panama-foreign/pull/695</a><br>
        [3] - <a href="https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/src/java.base/share/classes/jdk/internal/foreign/Utils.java#L223" class="moz-txt-link-freetext">https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/src/java.base/share/classes/jdk/internal/foreign/Utils.java#L223</a></p>
      <div title="MDH:CiAgICA8cD48YnI+CiAgICA8L3A+CiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDI0LzAzLzIwMjMgMTk6MDcsIEdsYXZvIHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkNBSkw1QTM9RSsxcEQ3QUtmZng3cFNNa3NxNmpH
V2hMOEIzOVhpZFBiTzArYjhNVzh6Z0BtYWlsLmdtYWlsLmNvbSI+CiAgICAgIDxkaXY+Mi4mbmJz
cDtTdHJ1Y3RMYXlvdXQgbXVzdCBtYW51YWxseSBzcGVjaWZ5IGFsbCBwYWRkaW5nPC9kaXY+CiAg
ICAgIDxkaXY+PGJyPgogICAgICA8L2Rpdj4KICAgICAgPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij4KICAgICAgICA8ZGl2PkNhbiB3
ZSBwcm92aWRlIGEgY29udmVuaWVudCBtZXRob2QgZm9yIGF1dG9tYXRpY2FsbHkKICAgICAgICAg
IHBhZGRpbmcgYmV0d2VlbiBmaWVsZHMgYmFzZWQgb24gYWxpZ25tZW50PzwvZGl2PgogICAgICAg
IDxkaXY+VGhlIGN1cnJlbnQgc3RydWN0TGF5b3V0IG1ldGhvZCBpcyBhbm5veWluZyBmb3Igc2l0
dWF0aW9ucwogICAgICAgICAgd2hlcmUgeW91IG5lZWQgdG8gbWFudWFsbHkgc2ltdWxhdGUgdGhl
IGxheW91dCBvZiBhIEMgc3RydWN0LjwvZGl2PgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxk
aXY+PGJyPgogICAgICA8L2Rpdj4KICAgIDwvYmxvY2txdW90ZT4KICAgIDxwPldlIGhhdmUgYmVl
biB0aGlua2luZyBhYm91dCB0aGlzIGZvciBzb21lIHRpbWUuPC9wPgogICAgPHA+Rmlyc3QsIHdl
IGhhdmUgYWRkZWQgZXh0cmEgZWFnZXIgY2hlY2tzIChhcyBhbHNvIHN1Z2dlc3RlZCBieQogICAg
ICBNaWNoYWVsKSBzbyB0aGF0IG5vbi1zZW5zaWNhbCBsYXlvdXRzIGFyZSBydWxlZCBvdXQgYXQg
Y3JlYXRpb246PC9wPgogICAgPHA+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl
Zj0iaHR0cHM6Ly9naXQub3Blbmpkay5vcmcvcGFuYW1hLWZvcmVpZ24vcHVsbC84MjQiPmh0dHBz
Oi8vZ2l0Lm9wZW5qZGsub3JnL3BhbmFtYS1mb3JlaWduL3B1bGwvODI0PC9hPjwvcD4KICAgIDxw
Pk9uIHRoZSB0b3BpYyBvZiBhZGRpbmcgYSBtb3JlIGZyaWVuZGx5IHN0cnVjdCBmYWN0b3J5LCB3
aGlsZSBJCiAgICAgIHN5bXBhdGhpemUsIEkgdGhpbmsgdGhlIGZ1bmN0aW9uYWxpdHkgaW4gTWVt
b3J5TGF5b3V0IGlzIG1lYW50IHRvCiAgICAgIGJlICJwcmltaXRpdmUiIC0gZS5nLiBpdCBnaXZl
cyB5b3UgdGhlIGJhc2ljIGJ1aWxkaW5nIGJsb2NrcyBmb3IKICAgICAgY29uc3RydWN0aW5nIGxh
eW91dHMuIFRoZSBNZW1vcnkgTGF5b3V0IEFQSSBpcyBhIGdlbmVyYWwgQVBJLCBhbmQKICAgICAg
bm90IGFsbCBzdHJ1Y3QgbGF5b3V0cyBjb3JyZXNwb25kIHRvIHdlbGwtZm9ybWVkIEMgc3RydWN0
CiAgICAgIGRlZmluaXRpb25zLiBDb25zaWRlciB0aGlzOjwvcD4KICAgIDxwPmBgYGphdmE8YnI+
CiAgICAgIHN0cnVjdExheW91dChKQVZBX0xPTkcsIEpBVkFfSU5UKTxicj4KICAgICAgYGBgPC9w
PgogICAgPHA+VGhpcyBsYXlvdXQgaXMgdmFsaWQsIGFuZCB5b3UgY2FuIGRlcmVmZXJlbmNlIGJv
dGggZmllbGRzIHcvbwogICAgICBpc3N1ZXMuIFRoYXQgc2FpZCwgdGhlIHNpemUgb2YgdGhpcyBs
YXlvdXQgKDEyKSBpcyBub3QgYSBtdWx0aXBsZQogICAgICBvZiBpdHMgYWxpZ25tZW50ICg4KSwg
c28gaWYgeW91IHRyeSB0byBuZXN0IHRoaXMgbGF5b3V0IGluc2lkZSBhCiAgICAgIHNlcXVlbmNl
IGxheW91dCwgeW91IHdvdWxkIGdldCBhbiBJbGxlZ2FsQXJndW1lbnRFeGNlcHRpb24uIEJ1dAog
ICAgICB5b3UgbWlnaHQgbmV2ZXIgbmVlZCB0byBjcmVhdGUgYW4gYXJyYXkgb2YgdGhlc2UgdGhp
bmdzIC0gbWF5YmUKICAgICAgdGhlcmUncyBvbmx5IG9uZSBvZiB0aGVzZSB0aGluZ3MgLSB0aGUg
TWVtb3J5IExheW91dCBBUEkgaXMgbm90CiAgICAgIHRvbyBvcGluaW9uYXRlZCBvbiBob3cgdGhl
c2UgdGhpbmdzIHNob3VsZCBiZSB1c2VkLiBUaGUgQwogICAgICBsYW5ndWFnZSwgb24gdGhlIG90
aGVyIGhhbmQsIGVuZm9yY2Ugc3BlY2lmaWMgY29uc3RyYWludHMgb24gaXRzCiAgICAgIHN0cnVj
dHMgLSBvbmUgc3VjaCBjb25zdHJhaW50IGlzIHRoYXQgYWxsIHN0cnVjdCBsYXlvdXRzIG11c3Qg
aGF2ZQogICAgICBhIHNpemUgdGhhdCBpcyBhIG11bHRpcGxlIG9mIHRoZWlyIGFsaWdubWVudC4g
V2hpY2ggbWVhbnMgdGhhdCB0aGUKICAgICAgYWJvdmUgc3RydWN0IGxheW91dCBkb2VzIG5vdCBj
b3JyZXNwb25kIHRvIGFueSBDIHN0cnVjdAogICAgICBkZWNsYXJhdGlvbi4gQW5kIHRoYXQncyBv
ay48L3A+PHA+T24gdG9wIG9mIHRoYXQsIGV2ZW4gaWYgQyBzdHJ1Y3RzIGFuZCBGRk0gc3RydWN0
IGxheW91dHMgYWdyZWVkIDEwMCUsIGl0IHdvdWxkIHN0aWxsIG1ha2Ugc2Vuc2UgZm9yIHRoZSBs
YXlvdXQgQVBJIHRvIGV4cG9zZSBhbiAicmF3IiBzdHJ1Y3QgbGF5b3V0IGZhY3RvcnksIGZvciBj
bGllbnRzIChtYXliZSB0b29scykgd2FudGluZyB0byB2YWxpZGF0ZSB0aGUgY29ycmVjdG5lc3Mg
b2YgdGhlaXIgYXNzdW1wdGlvbnMuPC9wPjxwPlNvLCBmb3IgdGhlIHRpbWUgYmVpbmcsIEkgdGhp
bmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGtlZXAgdGhlIEZGTSBBUEkgdGhlIHdheSBpdCBpcywg
YW5kIGhhdmUgYWxsIHRoZSB2YXJpb3VzIGxheW91dCBmYWN0b3JpZXMgYWN0IHRyYW5zcGFyZW50
bHkgaW4gYSAid2hhdCB5b3Ugc2VlIGlzIHdoYXQgeW91IGdldCIgbWFubmVyLiBUaGVzZSBhcmUg
dGhlIGJ1aWxkaW5nIGJsb2NrcyBhZnRlciBhbGwsIHNvIHRoZXkgc2hvdWxkIGJlIGVhc3kgdG8g
ZXhwbGFpbiBhbmQgdG8gdW5kZXJzdGFuZC48L3A+PHA+RG9lcyB0aGlzIG1lYW4gdGhhdCB0aGVy
ZSB3aWxsIG5ldmVyIGJlIGhpZ2hlci1sZXZlbCBmdW5jdGlvbmFsaXRpZXM/IE5vdCBuZWNlc3Nh
cmlseS4gSSB0aGluayB0aGVyZSBpcyBhIGxvbmctaXNoIHN0cmluZyB0byBwdWxsIG9uIHRoZSBs
YXlvdXQgQVBJLiBTb21lIHdvcmsgUGVyIGRpZCBpbiB0aGlzIGFyZWEgWzEsIDJdIHNob3dzIHRo
YXQgdGhlcmUgYXJlIGZ1bmN0aW9uYWxpdGllcyB0aGF0IGFyZSB1c2VmdWwgd2hlbiB3b3JraW5n
IHdpdGggbGF5b3V0cywgYnV0IHRoYXQgd2UgbWlnaHQgbm90IG5lY2Vzc2FyaWx5IGhhdmUgZm91
bmQgdGhlIGJlc3QgcGxhY2Ugd2hlcmUgdG8gcHV0IHRoZW0uIEFsc28sIEkgYmVsaWV2ZSBhdCBz
b21lIHBvaW50IHRoZXJlIHdpbGwgYmUgc29tZSBzdG9yeSBmb3IgX3RyYW5zZm9ybWluZ18gYSBs
YXlvdXQgaW50byBhbm90aGVyLCBzbyBhZ2FpbiB0aGVyZSdzIGEgcXVlc3Rpb24gb2Ygd2hlcmUg
dG8gcHV0IHNvbWUgY2FubmVkIHRyYW5zZm9ybXMgKGUuZy4gdG8gc3dhcCBlbmRpYW5uZXNzIG9m
IGFsbCB2YWx1ZSBsYXlvdXRzIGluIGEgbGF5b3V0KS4gSSB0aGluayBhICJoaWdoZXItbGV2ZWwi
IGZhY3RvcnkgZm9yIGNyZWF0aW5nIEMtbGlrZSBsYXlvdXRzIGJlbG9uZyBpbiB0aGUgc2FtZSBw
bGFjZSBhcyB0aGVzZSBmdW5jdGlvbmFsaXRpZXMuIFRoZXkgYXJlIG5pY2UtdG8taGF2ZSwgYnV0
IG5vdCAicHJpbWl0aXZlIiBlbm91Z2gsIEkgdGhpbmssIHRvIGRlc2VydmUgYSBzcG90IGluIHRo
ZSBNZW1vcnlMYXlvdXQgY2xhc3MgKGV2aWRlbmNlIG9mIHRoYXQgaXMgdGhhdCBpdCBpcyBmYWly
bHkgZWFzeSB0byBidWlsZCBzdWNoIGEgZmFjdG9yeSBleHRlcm5hbGx5IFszXSkuPC9wPjxwPk1h
dXJpemlvPC9wPjxwPlsxXSAtIGh0dHBzOi8vZ2l0Lm9wZW5qZGsub3JnL3BhbmFtYS1mb3JlaWdu
L3B1bGwvNzE1PGJyPlsyXSAtIGh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuamRrL3BhbmFtYS1mb3Jl
aWduL3B1bGwvNjk1PGJyPlszXSAtIGh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuamRrL3BhbmFtYS1m
b3JlaWduL2Jsb2IvZm9yZWlnbi1tZW1hY2Nlc3MlMkJhYmkvc3JjL2phdmEuYmFzZS9zaGFyZS9j
bGFzc2VzL2pkay9pbnRlcm5hbC9mb3JlaWduL1V0aWxzLmphdmEjTDIyMzxicj48L3A+PHA+PGJy
        PjwvcD48cD48YnI+PC9wPgogICAgPHA+PGJyPgogICAgPC9wPgogIAoK" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;">​</div>
    </div>
  </body>
</html>