More detail than I had intended on Layout description language.

[Angela Lin]

David Chase <david.r.chase at oracle.com> wrote on 11/18/2014 06:28:35 PM:

> From: David Chase <david.r.chase at oracle.com>
> To: Angela Lin/Ottawa/IBM at IBMCA
> Cc: panama-spec-experts at openjdk.java.net, IBM Panama Spec Group
> <IBM_Panama_Spec_Group%IBMCA at ca.ibm.com>
> Date: 11/18/2014 06:28 PM
> Subject: Re: More detail than I had intended on Layout description
language.
>
>
> On 2014-11-18, at 5:31 PM, Angela Lin <angela_lin at ca.ibm.com> wrote:
>
> >
> > Some aspects I'd like to highlight from Tobi's email:
> >
> > 1. LDL/NFD, by default, should describe exact memory layout on the
> > execution platform. In particular:
> > - Fields must have explicitly specified width. So, if the LDL/NFD
models a
> > C struct that contains a void*, the size of the void* has to be known
> > up-front.
> > - No automatic padding or alignment.
> > - Fields either have explicitly specified offset, or are laid out in
the
> > order of specification.
> > - Native endian.
> >
> > This implies that the descriptor for, say, a C struct, may not be
portable
> > across all platforms. If the descriptor models a data structure that is
> > shared with a native library, then the descriptor is tied to the
particular
> > native library binary. I think this is consistent with David's earlier
> > statement:
> >> So, since the Java-side behavior should be different, I think that
> >> the little language inputs
> >> (the output of the libclang-based tool) should be different
> >> depending on platform ? the
> >> offsets will need to be described in ways that make conform to
> >> Java?s expectations.
>
> I think what you are saying is consistent, but I didn?t get that
> from Tobi?s email,
> so I?ll reread it more carefully.  The language surrounding
> ?pointer? in particular
> made me think that he was approaching it differently.

Tobi's email refers to our attempt to implement a portable "pointer" type
in the LDL. It's an interesting option to consider, but I'm not sure we
want to deal with the knock-on effects of supporting this. For example, how
do we align the pointer field (in the LDL) if we don't know its size?
What's the impact on the layout nesting or extension features?

If we decide that LDL is not platform-independent, then "pointer" doesn't
seem as useful.

> Was I correct in seeing that it is proposed to attach LDL to
> interfaces with annotations?

Yes, we proposed this. However, we're certainly open to alternatives.

Since LDL is not platform-independent, if the LDLs are attached to the
generated Java interfaces, then the Java interfaces are also not
platform-independent. Is this is good or bad?

> My snap reaction is that?s a good idea, even if it does perhaps push
> the LDL back into text.
>
> And I think (based on discussions at this end) that being able to treat
these
> things as native-resident references is priority #1, but I?m not
> sure that the only
> priority.

Could you clarify the terminology "native-resident reference"?

> But I will look again.  (A bug with a deadline is currently grabbingmost
of my
> attention, unfortunately).
>
> Also, I think we might need alignment specification, especially
> considering possible
> GPU applications.  It?s not necessarily for padding purposes, but it
> is required to ensure
> that memory is properly allocated and placed ? for example, can I
> allocate a 64-bit quantity
> on an 8-bit boundary?  How am I told that I cannot do this?

For start alignment, I think you're right. Again, I would propose starting
with an explicit descriptor attribute, i.e. "the layout must start at an
alignment of x".

Angela