[foreign] RFR 8208199: Revisit one interface per header file approach
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Aug 8 13:13:46 UTC 2018
Some binder comments too (related to the changes in HeadeImplGenerator)
1) are we expecting a header interface to implement something other than
another header interface?
2) isn't there a bug lurking here? Suppose I do
Libraries.bind(String.class), now, there's no NativeHeader in here, so
that will just 'do nothing' ? (as opposed to e.g. fail with exception)
Maurizio
On 08/08/18 14:06, Maurizio Cimadamore wrote:
>
>
> On 08/08/18 13:25, Sundararajan Athijegannathan wrote:
>> May I suggest that we go with the current scheme (which is minimal
>> changes) and revisit based on use-cases?
> While I'm fine with the changes, and I agree that they are 'minimal',
> I'm also worried that they add a new design dimension that is not
> fully explored. Some of the issues with the approach are the lack of
> granularity in specifying the set of headers to be 'followed', as well
> as the fact that this new multi-header mode completely invalidates the
> assumptions of unresolved layout resolution - the assumption there was
> that any layout mentioned in a class C could be resolvable by looking
> at the outermost enclosing class of C (**).
>
> My feeling is that we have both missing metadata and missing jextract
> options here.
>
> (**) Consider this example:
>
> //a.h
> import "b.h"
>
> void fn(struct S);
>
> //b.h
> struct S { int i; };
>
> If you extract this with jextract, you get two headers, one for 'a'
> and one for 'b'. The function descriptor for 'fn', which is in
> 'a.class' will refer to the layout of S, which is in B.class. With
> your patch, a.class will also 'implement' b.class. Here, the resolver
> for a.class knows nothing about S. The only way to support this
> resolution is via ad-hoc prescanning of all classes in the signatures
> of a.class (which we currently do, but it's a mouthful, design-wise).
>
> My hope here is to come up with a mechanism to specify related headers
> both from a point of view of jextract flag (e.g. so that jextract will
> follow headers), but also in a way so that the information about the
> header relationship is preserved at runtime into some metadata; that
> way, the information can be used to perform layout resolution in a
> precise and well-defined way.
>
> While this patch defines no additional metadata, one could argue that
> the injected subtyping relationship it provides is, itself, some form
> of metadata we could exploit during resolution. And, using inheritance
> has the obvious advantage of exposing a model that 'makes sense' for
> Java users.
>
> With all these things in mind, let's give this code a try - and see if
> we can fit a story for better layout resolution on top of it.
>
> Cheers
> Maurizio
>
>
More information about the panama-dev
mailing list