[foreign] RFR 8208199: Revisit one interface per header file approach
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Aug 8 13:06:08 UTC 2018
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