[foreign] RFR Add sizeof method to Struct type

John Rose john.r.rose at oracle.com
Thu Jul 26 18:32:16 UTC 2018


On Jul 26, 2018, at 9:40 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Updated webrev: http://cr.openjdk.java.net/~sundar/8208284/webrev.01/
> 
> Left a FIXME comment in ScopeImpl.allocateStruct and removed alignment in Struct.sizeof

I agree with how it came out:  The layout has the responsibility for exactly specifying
size (down to the bit level, IMO), and there's no reason to adjust that.  The C compiler
will align up to the largest alignment requirement, so struct { char x; short y; char z; }
will align up to 6 bytes (not 8) with two chars of padding.  This is the C compiler's
job, and other languages won't use the same rules; ASN.1 packed rules bit-packs
stuff, for example.

I don't think the alignUp is needed unless the underlying allocate call is sensitive to
unaligned sizes, like sizeof=6 in the example above.  It probably isn't.

In general, when we are allocating our own envelopes for data, as with
allocateStruct, we might add our own padding around the data; one possible
goal is to de-alias cache line usages, and another is to put tripwire words
around the object (front and back) to help spot OOB access.  The C compiler
won't know or care.  This can be a debug-oriented or performance-oriented
control in our runtime.

Another point:  There is a latent bug in allocateStruct, which is that it makes a
quiet assumption that everybody has agreed to use some largest possible
alignment for new storage blocks.  If you work down the stack, it will turn out
to be 64 bits, probably.  But some types have more strict alignment requirement.
To handle such types (vectors) we will need to push alignment requirements
from the C frontend (and other layout generators), through the layout schemas,
and into allocateStruct.  At present those wires are not connected.

— John


More information about the panama-dev mailing list