[foreign-memaccess+abi] RFR: 8301360: Add dereference layout paths to memory layout API [v2]

[Maurizio Cimadamore]

On Mon, 30 Jan 2023 21:40:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Sure - the layout accepting one needs to be restricted - I started off with only the other one (which doesn't need to be restricted), then added the layout accepting one, and forgot to add the restricted check. Any way - as a validation, do we agree that it is handy to have both forms? If you have a layout like A -> B -> A, there is no way to attach target layouts statically - which is the main reason why I added that variant.
>
> Yes, it seems good to have it for that case.

In the end, I've decided to drop the overload, at least for now. While it could be useful in some pathological situation, the other method should be good for the vast majority of cases. It occurred to me that there are other possible ways to attack the problem of cyclic references - for instance, we could still require a target layout on the address - but then just perform a "layout cast" when dereferencing (which then got me thinking as to whether a more general "cast element" would be required). For instance, it should always be _statically safe_ to cast a layout into another if the target layout is smaller, and if its alignment constraints are less strict (this ensures that no surprising exception might ever come out of the cast). Overall, I believe it would be better to think a bit more on this one.

-------------

PR: https://git.openjdk.org/panama-foreign/pull/776