[foreign] RFR Add sizeof method to Struct type

[Samuel Audet]

BTW, how memory gets allocated isn't limited to alignment. With CUDA, 
for example, we need to allocate pinned host memory, and that needs to 
be done through the video driver. How does ScopeImpl and friends deal 
with this? JavaCPP simply sees it as another C++ resource that we can 
manage the same way as anything else:
http://bytedeco.org/news/2018/07/17/bytedeco-as-distribution/

Samuel

On 07/27/2018 03:32 AM, John Rose wrote:
> 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
>