tweaking layout API to work on bytes instead of bits

[Pedro Lamarão]

In my experiments, IIRC two or three times I had a bug caused by passing a
byte quantity where a bit quantity was expected. This is something I have
observed many times in programming security APIs, where sometimes key sizes
are expressed in bytes, sometimes in bits. Types are always int and the
compiler never complains. I welcome this change.


Em ter., 16 de mai. de 2023 às 11:22, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> escreveu:

> Hi,
> as we're going through the FFM API with a finer comb, we were reminded
> again of an asymmetry between memory segments and memory layouts. Memory
> segments are expressed as "bag of bytes". All their sizes and offsets
> are expressed in number of bytes, which obviously makes sense given that
> (a) memory addressing is byte-oriented and (b) ByteBuffer API also works
> that way (so changing it would make transition from BB a lot more painful).
>
> On the other hand, memory layouts are expressed in bits. The historical
> reasons for this can be found in John's great LDL document [1].
> Essentially, the layout language proposed in the LDL document was
> originally intended to model both memory **and** registers. That said,
> the memory layout API is firmly in the territory of modelling memory
> structure/dereference, so it seems that ship has sailed already. If we
> want to talk about sub-byte structure, we could still do so, in the
> future, by adding a dedicated API for "register layouts" (e.g. so that a
> JAVA_INT could be associated with a sub-byte layout which indicates how
> the 32 bits are partitioned and used).
>
> While this asymmetry can rarely be observed in practice, it is
> bothersome for a number of reasons:
>
> * Factories accepting layouts (e.g.
> SegmentAllocator::allocate(MemoryLayout)) cannot be expressed as simple
> sugar for factories expressed in byte size/alignment (e.g.
> SegmentAllocator::allocate(long, long)). That is, there is always some
> segments that can be allocated in one factory which can't be allocated
> in the other.
>
> * Var handles generated using the memory layout API have different
> constraints from those generated directly from MethodHandles. The latter
> just accepts a byte offset (in sync with what memory segments do), while
> the former perform all internal computation, as well as range checking,
> in bits - which again leads to asymmetries.
>
> We would like to rectify this asymmetry now (possibly in Java 21).
> Here's a draft PR that does just that:
>
> https://github.com/openjdk/jdk/pull/14013
>
> While tedious, in reality there's not much that leaks outside the API
> and tests because:
>
> * Clients access value layouts using one of the ready-made constants
> (e.g. ValueLayout.JAVA_INT or, ValueLayout.JAVA_INT_UNALIGNED for
> unaligned access)
> * I suspect clients are only using methods such as
> MemoryLayout::byteSize() and MemoryLayout::byteAlignment() already
>
> There is however, some compatibility surface as well:
>
> * The factory for padding layouts will need to take a byte size, not a
> bit one (but note that we already required the bit size to be multiple
> of 8, so no real change). This is by far the most annoying, because
> existing code will "not get the memo", and, if unchanged, will end up
> creating padding layouts that are too big.
> * Instead of using MemoryLayout::withBitAlignment, clients will need to
> use MemoryLayout::withByteAlignment. Since this will result in a
> compilation error (and since the method name says "byte" and not "bit"),
> I believe that, while annoying, this poses far less issues.
>
> Of course code that works against jextract bindings won't need any
> updates, but bindings will need to be re-generated to have paddings and
> alignments expressed in bits, not bytes.
>
> I believe that, on the whole, these changes are rather sensible - having
> segments and layouts using different "currencies" seems like a recipe
> for future trouble. Of course if there are some objections, we'd like to
> hear from you.
>
> Thanks
> Maurizio
>
> [1] - https://cr.openjdk.org/~jrose/panama/minimal-ldl.html
>
>

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230517/e8c07868/attachment.htm>