[foreign-memaccess+abi] RFR: 8310362: Improve composability of handle derived from layouts [v3]

[Maurizio Cimadamore]

On Thu, 22 Jun 2023 21:15:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've uploaded a new version which attempts to improve this by merging the two paragraphs about offset computation. I'm not sure which version is better, though... Given the length of the text, I feel like we need _some_ kind of concept that refers to sections of a path which don't contain dereference path elements.
>
> I agree that the text is still not optimal. I'd like to think about it some more, and maybe I can come up with some more concrete suggestions.

Looking at this some more, here are some things which, I believe, can be improved:

* The text is unnecessarily speaking about _addresses_. This forces us to define an abstract function to compute the base address of a segment (we need to, since heap segments have a virtualized base). In reality, all this is unnecessary - there's just segments and offsets, we don't really care about the address.
* Ignoring dereference handles, the behavior of the var handle is straightforward: we just derive an offset into the segment by calling `offsetHandle` (all the indices are passed and validated there). Then it's as if we called MS::get with the target (value) layout and provided the offset obtained as above. Perhaps, relying on MS::get is suspicious here, as we're on a more primitive level - but I think just saying "accessing a value whose type is the carrier of the target layout, at the offset computed as XYZ in the provided segment" is ok (and that is what happens). I don't think there is a need to provide formulas.
* I realize that we're hand-waving a bit for when the target layout is an AddressLayout - in that case the resulting segment has certain size characteristics, which depend on the target layout of the address - and we should say that.
* As for dereference path elements (assuming we want to keep them, which I'm less sure about), we could use the existing structure where first we explain what happens when there's no dereference path element. Then, we could explain what happens when there's dereference path elements by saying that we split the path into multiple "chunks" (this is similar to what you have done earlier), and that we compute the var handle for each chunk, and show how things are wired together (at this point we should have explained all the concepts we needed for this).

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

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/840#discussion_r1239639544