RFR: 7903597: Slim down RuntimeHelper
Jorn Vernee
jvernee at openjdk.org
Mon Dec 4 11:42:12 UTC 2023
On Mon, 4 Dec 2023 11:17:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> 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.
For fields that is not possible though, since we have to put those at the start of the header class to avoid illegal forward references, but we don't know when we create the first header class whether we are going to need multiple header classes. When we have only 1 header class, the first header is the 'root' into which the helpers should go, when we have multiple headers, the second header class is the root.
I think maybe it's simpler to just generate the helper methods and fields like `SYMBOL_LOOKUP` once per header class. Or use static methods with embedded Holder classes for the fields. We could also have a special last header that everything else inherits, i.e. just have the last header extend RuntimeHelper essentially. But when I got to that point in my thought process, I thought: why not just keep RuntimeHelper then.
-------------
PR Review Comment: https://git.openjdk.org/jextract/pull/150#discussion_r1413752108
More information about the jextract-dev
mailing list