Small query on CLinker

[Julian Waters]

Hi Maurizio, thanks for the reply,

I was thinking about language specific quirks being confined to specific
implementations while having CLinker being the language agnostic interface
too, from what I can tell quite a lot would have to be migrated from
CLinker (Or renamed Linker if it does end up as truly agnostic) to each
language specific file though (C_POINTER and TypeKind etc), I can't at the
moment tell if that would be feasible

best regards,
Julian

On Wed, Mar 23, 2022 at 8:18 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Julian,
> This question has come up, both internally and externally.
>
> I agree that CLinker is a pretty general abstraction and there's nothing
> in it that is too C specific. The concepts of taking a function
> descriptor and turning it into a method handle, or, conversely, taking a
> method handle and turning it into a function pointer are reusable across
> different languages.
>
> That said, there are a couple of ways in which language details can
> creep back in:
>
> * not all linkers might support the same set of layouts in the provided
> function descriptor. For instance, a language might not have support for
> by-reference arguments (so that ValueLayout.ADDRESS is not an option).
> Or a language might not support composite types (so struct/union layouts
> are not possible)
> * the support for variadic functions is pretty tied to how the ABI is
> defined; in C we have to know which arguments layouts in the function
> descriptor correspond to "variable arity" arguments, because the ABI
> needs to treat them differently.
>
> Of course, one option would be to make the javadoc of CLinker language
> agnostic (this is easy - 90% of the javadoc already is) - and move the
> language-dependent details in the linker factory (e.g. set of supported
> layouts/parameters, handling of variable arity, etc.)
>
> Thanks
> Maurizio
>
> On 23/03/2022 12:03, Julian Waters wrote:
> > Hi all,
> >
> > Small query about CLinker, would it be more appropriate to rename it (And
> > the systemCLinker method) to just "Linker" to better fit its role? It is
> > after all supposed to be an abstraction for any sort of foreign
> interface,
> > and I feel like the name CLinker would intuitively signify that it can
> > *only* work with C and nothing else. Or would this undermine the fact
> that
> > native calls have to follow the C ABI?
> >
> > best regards and have a great day,
> > Julian
>