[foreign-jextract] RFR: 8248560: Specify the behaviour of the ForeignLinker returned by CSupport::getSystemLinker (jextract part)

[Maurizio Cimadamore]

On Wed, 16 Sep 2020 14:58:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR contains the fixes needed for foreign-jextract branch after the refactor done by:
> https://github.com/openjdk/panama-foreign/pull/327
> This is mostly just a mechanical renaming from CSupport to CLinker.
> 
> The exception is that ClassConstantHelper had to be re-written to replace dynamic constants of ValueLayouts by
> references to the internal ABI classification fields, since they can not be references from generated code, resolving
> the current dynamic constants would result in an access error, but the static final constant fields in CLinker are
> freely accessible.  Also, since the platform specific constants are no longer publicly visible, jextract will generate
> classes that reference the layout constants for the current platform instead of a specific one.  Thanks,
> Jorn

Overall looks good. I'd like to clarify that where we are now is a bit of a transient state, since we now have layouts
(the ones in CLinker) which have "hidden" attributes, meaning that jextract has to replicate all the work that would be
otherwise done in `MemoryLayout::describeConstable()`.

I think that, longer term. we should probably move away from layout attributes, and embrace the possibility (which has
been requested at times) of making layout subclassable by clients. E.g. by sealing the MemoryLayout interface, but by
unsealing the various leaves, users will be able to define their own layout with whatever extra info they want to
attach on them (and jextract and the ABI support will be able to do the same).

So, while layout attributes seemed a promising unification for some of the things we had going, I'm growing less and
less convinced that they are the right answer for some of the problems we are seeing.

At the same time, completely abandoning layout attributes, while compelling, will also result in usability issues,
since now clients won't be able e.g. to attach extra information to ABI layouts, since, in that world, the subclass of
ValueLayout used by the ABI support  will likely be hidden.

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/panama-foreign/pull/329