[foreign] RFR 8208199: Revisit one interface per header file approach
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Wed Aug 8 13:54:24 UTC 2018
Yes, good catch! That should be removed. i.e., NativeHeader should be
enforced for all interfaces transitively.
-Sundar
On 08/08/18, 6:43 PM, Maurizio Cimadamore wrote:
> 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