RFR: 7903597: Slim down RuntimeHelper

[Maurizio Cimadamore]

On Fri, 1 Dec 2023 22:37:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/main/resources/org/openjdk/jextract/impl/resources/RuntimeHelper.java.template line 27:
>> 
>>> 25:     static {
>>> 26:         SymbolLookup loaderLookup = SymbolLookup.loaderLookup();
>>> 27:         Linker linker = Linker.nativeLinker();
>> 
>> Question: with RuntimeHelper being so small now, and given one of the stated goal is to allow for better composition of different extractions, would it not be convenient to move all these definitions in the header class and ditch `RuntimeHelper` completely? If we do that, we might also avoid generating the varargs definitions unless we need them, so that the header class would only include minimal additional code.
>
> I thought about this, and I think the main question is: in which header class do we generate the helpers if we have multiple classes? I wasn't sure if we'd be happy with duplicating the helpers in every header class (users might complain about the duplication). But, maybe the majority of cases will only ever see a single header class, so there's still a benefit.
> 
> I'll take another look at that. The conditional code generation is also an interesting benefit.

If you mean multiple headers because of splitting, then there's a natural place where the code should be generated (which is the root of the header class inheritance hierarchy). If you mean multiple headers because... multiple jextract runs, I think it's ok if a couple of common helper functions get replicated in multiple extraction runs.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/150#discussion_r1413729078