From sundar at openjdk.org  Wed Feb  1 11:18:15 2023
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 1 Feb 2023 11:18:15 GMT
Subject: RFR: Fix jextract after removal of support for sub-byte layouts
In-Reply-To: <Z0yHbeyHKwnH6ZUHwk17jWshskNawB4E8hDDJJbnhCE=.9229f48f-f4dd-4ccc-a533-ab105232d99b@github.com>
References: <Z0yHbeyHKwnH6ZUHwk17jWshskNawB4E8hDDJJbnhCE=.9229f48f-f4dd-4ccc-a533-ab105232d99b@github.com>
Message-ID: <_RJcpVprSq_lXiFgQ6PPhiXZllChXjTF55Zq7Q6QNpA=.3a41fc54-a11e-4caa-ab6f-cc4ffcd79603@github.com>

On Mon, 30 Jan 2023 21:50:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes some test failures which are caused by https://git.openjdk.org/panama-foreign/pull/766.
> 
> As that patch removes support for sub-byte layouts, we can no longer represent bitfields using group layouts (because we can no longer model group elements whose size is not a multiple off 8).
> 
> In reality, jextract isn't doing much with bitfields: it just generates a bunch of padding layouts of the right size and storing them into a group layout, but this layout, of course, cannot be used for access (because sub-byte layout doesn't work with VarHandles).
> 
> To fix this, I have added a new subtype of `Declaration.Variable` - namely, `Declaration.Bitfield` - this is like a variable - it has a name (but no layout), and has a type. On top of this, a `Bitfield` also stores an `offset` (relative to the contained) and a `width` (the size in bits of the bitfield).
> 
> Most of the changes in this patch are caused by the fact that the underlying IR for bitfields has changed (as described above). Since bitfields are still variables (whose kind is `BITFIELD`) and since variable of that kind are ignored by the jextract backend, nothing is going to change, really. That said, should we want to add bitfield accessors one day, all the info to generate the accessor should be available in the jextract IR.

LGTM

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

Marked as reviewed by sundar (Committer).

PR: https://git.openjdk.org/jextract/pull/101

From maurizio.cimadamore at oracle.com  Wed Feb  1 11:26:01 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 1 Feb 2023 11:26:01 +0000
Subject: jextract and bit fields
In-Reply-To: <0f263042-9186-50ae-18e3-50a00efd5496@oracle.com>
References: <CANwj8Zr=TWZ-DMDLb0q9rNOmCAf0Mz0vE6yyouHM6140Ux2Xzw@mail.gmail.com>
 <0f263042-9186-50ae-18e3-50a00efd5496@oracle.com>
Message-ID: <f5400956-9a27-575d-d699-87fa1935b128@oracle.com>

Hi Remy,
We have fixed a related issue here:

https://github.com/openjdk/jextract/pull/101

Hopefully this addresses your problem.

Cheers
Maurizio

On 30/01/2023 16:39, Maurizio Cimadamore wrote:
>
> Hey Remi,
> while jextract does not support bitfields, it should also not crash 
> when seeing them :-)
>
> I have tried extracting a simple header containing the struct in your 
> email using the jextract binary at [1].
>
> I could successfully extract it, and obtain a |my_struct| Java 
> wrapper, with this layout:
>
> |static final GroupLayout $struct$LAYOUT = MemoryLayout.structLayout( 
> MemoryLayout.structLayout( 
> MemoryLayout.paddingLayout(1).withName("foo"), 
> MemoryLayout.paddingLayout(31) ) ).withName("my_struct"); |
>
> As expected, the contents of the struct are just padding.
>
> That said, I?m beginnin to suspect that you are seeing this issue with 
> a more recent version of jextract, perhaps the one for the ?panama? 
> branch? We have made recent changes to how padding layouts are defined 
> - e.g. so that their size/alignment must be a multiple of 8. This 
> would cause the issue you are seeing.
>
> Maurizio
>
> On 30/01/2023 13:25, R?my Maucherat wrote:
>
>> Hi,
>>
>> When processing certain bit-fields, jextract produces an error:
>> "Invalid bitSize: 1"
>> In addition to not being really helpful (it took me some time to find
>> out what the problem was since no reference to a location is given,
>> nor that this is about a bit-field).
>>
>> A typical example causing the error is something like:
>> struct my_struct {
>>     unsigned int foo : 1;
>> };
>>
>> Obviously we don't have these sort of memory saving "smart" fancy
>> tricks in Java (which is probably good since they can cause serious
>> problems when misused ...).
>>
>> Is support for this planned eventually, or should bit-fields be
>> avoided for Panama compatibility ?
>>
>> Thanks !
>>
>> R?my
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20230201/f3572929/attachment.htm>

From mcimadamore at openjdk.org  Wed Feb  1 11:29:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 1 Feb 2023 11:29:17 GMT
Subject: Integrated: Fix jextract after removal of support for sub-byte layouts
In-Reply-To: <Z0yHbeyHKwnH6ZUHwk17jWshskNawB4E8hDDJJbnhCE=.9229f48f-f4dd-4ccc-a533-ab105232d99b@github.com>
References: <Z0yHbeyHKwnH6ZUHwk17jWshskNawB4E8hDDJJbnhCE=.9229f48f-f4dd-4ccc-a533-ab105232d99b@github.com>
Message-ID: <cN_8iAV551l-Wj9lVPEwVVqF0xOAF8KWrIQkdsby3jk=.00366ed7-122b-42f3-b4ee-b8efbf3cacca@github.com>

On Mon, 30 Jan 2023 21:50:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes some test failures which are caused by https://git.openjdk.org/panama-foreign/pull/766.
> 
> As that patch removes support for sub-byte layouts, we can no longer represent bitfields using group layouts (because we can no longer model group elements whose size is not a multiple off 8).
> 
> In reality, jextract isn't doing much with bitfields: it just generates a bunch of padding layouts of the right size and storing them into a group layout, but this layout, of course, cannot be used for access (because sub-byte layout doesn't work with VarHandles).
> 
> To fix this, I have added a new subtype of `Declaration.Variable` - namely, `Declaration.Bitfield` - this is like a variable - it has a name (but no layout), and has a type. On top of this, a `Bitfield` also stores an `offset` (relative to the contained) and a `width` (the size in bits of the bitfield).
> 
> Most of the changes in this patch are caused by the fact that the underlying IR for bitfields has changed (as described above). Since bitfields are still variables (whose kind is `BITFIELD`) and since variable of that kind are ignored by the jextract backend, nothing is going to change, really. That said, should we want to add bitfield accessors one day, all the info to generate the accessor should be available in the jextract IR.

This pull request has now been integrated.

Changeset: ddff2741
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/ddff27410fd30bcf25015bf9cdd297bcfde56416
Stats:     125 lines in 8 files changed: 80 ins; 21 del; 24 mod

Fix jextract after removal of support for sub-byte layouts

Reviewed-by: sundar

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

PR: https://git.openjdk.org/jextract/pull/101

From mcimadamore at openjdk.org  Fri Feb 10 17:46:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 Feb 2023 17:46:48 GMT
Subject: RFR: Update jextract to reflect latest API changes
Message-ID: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>

This patch refreshes the generated bindings to reflect the latest API changes in https://github.com/openjdk/panama-foreign/pull/787.

The changes are straightforward, and mostly consist in removing `.scope()` calls when creating upcalls, and with replacing some `SegmentScope` parameters with `Arena` ones.

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

Commit messages:
 - Polish test
 - Drop spurious changes
 - Fix test
 - Use target layouts for pointers
 - Add support for latest API changes

Changes: https://git.openjdk.org/jextract/pull/102/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=102&range=00
  Stats: 238 lines in 47 files changed: 91 ins; 24 del; 123 mod
  Patch: https://git.openjdk.org/jextract/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/102/head:pull/102

PR: https://git.openjdk.org/jextract/pull/102

From mcimadamore at openjdk.org  Fri Feb 10 17:55:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 Feb 2023 17:55:46 GMT
Subject: RFR: Update jextract to reflect latest API changes [v2]
In-Reply-To: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
References: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
Message-ID: <almAABKAYDeKoovh1TMKJkeKBH6m1585kyyJeww76qE=.76df7ff3-a5f5-4937-a0ae-a9717c3233d2@github.com>

> This patch refreshes the generated bindings to reflect the latest API changes in https://github.com/openjdk/panama-foreign/pull/787.
> 
> The changes are straightforward, and mostly consist in removing `.scope()` calls when creating upcalls, and with replacing some `SegmentScope` parameters with `Arena` ones.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'panama' into arena_lump
 - Revert spurious changes
 - Polish test
 - Drop spurious changes
 - Fix test
 - Use target layouts for pointers
 - Add support for latest API changes

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

Changes: https://git.openjdk.org/jextract/pull/102/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=102&range=01
  Stats: 102 lines in 34 files changed: 4 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jextract/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/102/head:pull/102

PR: https://git.openjdk.org/jextract/pull/102

From jvernee at openjdk.org  Fri Feb 10 19:07:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 10 Feb 2023 19:07:15 GMT
Subject: RFR: Update jextract to reflect latest API changes [v2]
In-Reply-To: <almAABKAYDeKoovh1TMKJkeKBH6m1585kyyJeww76qE=.76df7ff3-a5f5-4937-a0ae-a9717c3233d2@github.com>
References: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
 <almAABKAYDeKoovh1TMKJkeKBH6m1585kyyJeww76qE=.76df7ff3-a5f5-4937-a0ae-a9717c3233d2@github.com>
Message-ID: <8Pm7-EztDcD-PXv0JGxD-qNF8fLizE3wTf_lvNFoI_M=.903f8b99-af38-4d87-89b1-00bb8f6ea08e@github.com>

On Fri, 10 Feb 2023 17:55:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch refreshes the generated bindings to reflect the latest API changes in https://github.com/openjdk/panama-foreign/pull/787.
>> 
>> The changes are straightforward, and mostly consist in removing `.scope()` calls when creating upcalls, and with replacing some `SegmentScope` parameters with `Arena` ones.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'panama' into arena_lump
>  - Revert spurious changes
>  - Polish test
>  - Drop spurious changes
>  - Fix test
>  - Use target layouts for pointers
>  - Add support for latest API changes

src/main/java/org/openjdk/jextract/clang/libclang/RuntimeHelper.java line 82:

> 80: 
> 81:     static MemorySegment lookupGlobalVariable(String name, MemoryLayout layout) {
> 82:         return SYMBOL_LOOKUP.find(name).orElse(null).asUnbounded().asSlice(0, layout.byteSize());

I note that his is different from the template, which returns `null` if the symbol can not be found as well. I'm not sure if that was intentional.

test/jtreg/generator/test8246341/LibTest8246341Test.java line 59:

> 57:                 assertEquals(argv.getAtIndex(C_POINTER, 1).asUnbounded().getUtf8String(0), "python");
> 58:                 assertEquals(argv.getAtIndex(C_POINTER, 2).asUnbounded().getUtf8String(0), "javascript");
> 59:                 assertEquals(argv.getAtIndex(C_POINTER, 3).asUnbounded().getUtf8String(0), "c++");

Is `asUnbounded` really needed here? Looking at the layout of `C_POINTER`, it has an unbounded  target layout attached:


final class Constants$root {
...
    static final OfAddress C_POINTER$LAYOUT = ADDRESS.withBitAlignment(64).withTargetLayout(MemoryLayout.sequenceLayout(Constants$root.C_CHAR$LAYOUT));
}

test/jtreg/generator/test8246341/LibTest8246341Test.java line 72:

> 70:             addr.set(C_POINTER, 0, MemorySegment.NULL);
> 71:             fillin(addr);
> 72:             assertEquals(addr.get(C_POINTER, 0).asUnbounded().getUtf8String(0), "hello world");

And here?

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

PR: https://git.openjdk.org/jextract/pull/102

From mcimadamore at openjdk.org  Mon Feb 13 11:06:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Feb 2023 11:06:23 GMT
Subject: RFR: Update jextract to reflect latest API changes [v3]
In-Reply-To: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
References: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
Message-ID: <y7I3zPivl4ce3Krj3cOhrbunV7GjekGZPf1WSb1wm_o=.0f962fce-3314-4be5-8cf2-0dcffff8d907@github.com>

> This patch refreshes the generated bindings to reflect the latest API changes in https://github.com/openjdk/panama-foreign/pull/787.
> 
> The changes are straightforward, and mostly consist in removing `.scope()` calls when creating upcalls, and with replacing some `SegmentScope` parameters with `Arena` ones.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/102/files
  - new: https://git.openjdk.org/jextract/pull/102/files/b7dac876..9ce82795

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=102&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=102&range=01-02

  Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jextract/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/102/head:pull/102

PR: https://git.openjdk.org/jextract/pull/102

From jvernee at openjdk.org  Tue Feb 14 13:15:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Feb 2023 13:15:18 GMT
Subject: RFR: Update jextract to reflect latest API changes [v3]
In-Reply-To: <y7I3zPivl4ce3Krj3cOhrbunV7GjekGZPf1WSb1wm_o=.0f962fce-3314-4be5-8cf2-0dcffff8d907@github.com>
References: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
 <y7I3zPivl4ce3Krj3cOhrbunV7GjekGZPf1WSb1wm_o=.0f962fce-3314-4be5-8cf2-0dcffff8d907@github.com>
Message-ID: <zhnvaI0jspXmptN01N2Bu9RlRS8I5jk_InpjacZpxg8=.da2f37ec-b6cf-4fce-a14e-190d4f786fb8@github.com>

On Mon, 13 Feb 2023 11:06:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch refreshes the generated bindings to reflect the latest API changes in https://github.com/openjdk/panama-foreign/pull/787.
>> 
>> The changes are straightforward, and mostly consist in removing `.scope()` calls when creating upcalls, and with replacing some `SegmentScope` parameters with `Arena` ones.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jvernee (no project role).

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

PR: https://git.openjdk.org/jextract/pull/102

From mcimadamore at openjdk.org  Tue Feb 14 13:50:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 14 Feb 2023 13:50:18 GMT
Subject: Integrated: Update jextract to reflect latest API changes
In-Reply-To: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
References: <0OQ8mWbkS8kUiIosqYJXAKpAsa0gKr2Gnyv362vVCII=.7320c9fa-e27e-4736-b26f-7c7f4aa6a6e9@github.com>
Message-ID: <vpQ63_7Id1-T5meTN3TcF4a1G_-wzBsLNGlIDJo2Qlw=.ef0e4caf-88fd-4577-8648-ad0d8c6f57ac@github.com>

On Fri, 10 Feb 2023 17:40:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch refreshes the generated bindings to reflect the latest API changes in https://github.com/openjdk/panama-foreign/pull/787.
> 
> The changes are straightforward, and mostly consist in removing `.scope()` calls when creating upcalls, and with replacing some `SegmentScope` parameters with `Arena` ones.

This pull request has now been integrated.

Changeset: e88e3685
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/e88e3685654fbed04bced03d10269d5c63fda310
Stats:     103 lines in 34 files changed: 6 ins; 3 del; 94 mod

Update jextract to reflect latest API changes

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jextract/pull/102

From sundar at openjdk.org  Thu Feb 16 12:07:40 2023
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 16 Feb 2023 12:07:40 GMT
Subject: Integrated: sample fixes for Arena API change.
Message-ID: <b5WxiB-i2_Y8sP9P7N3aqvpaFpjieZRaF6-6r1zHQPI=.bcc261e3-f882-4880-8a71-c3ec53707cfe@github.com>

All samples run fine on MacOS (except for OpenGL which has been broken on Mac for a while now)

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

Commit messages:
 - sample fixes for Arena API change.

Changes: https://git.openjdk.org/jextract/pull/103/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=103&range=00
  Stats: 56 lines in 27 files changed: 3 ins; 0 del; 53 mod
  Patch: https://git.openjdk.org/jextract/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/103/head:pull/103

PR: https://git.openjdk.org/jextract/pull/103

From mcimadamore at openjdk.org  Thu Feb 16 12:07:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 12:07:42 GMT
Subject: Integrated: sample fixes for Arena API change.
In-Reply-To: <b5WxiB-i2_Y8sP9P7N3aqvpaFpjieZRaF6-6r1zHQPI=.bcc261e3-f882-4880-8a71-c3ec53707cfe@github.com>
References: <b5WxiB-i2_Y8sP9P7N3aqvpaFpjieZRaF6-6r1zHQPI=.bcc261e3-f882-4880-8a71-c3ec53707cfe@github.com>
Message-ID: <nVe3XvGJq0WGKBgBi0IDTQZOVi6dMADbQVzJCzAPeco=.f0c857d7-1363-4636-9880-addb92968659@github.com>

On Thu, 16 Feb 2023 11:58:01 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> All samples run fine on MacOS (except for OpenGL which has been broken on Mac for a while now)

Marked as reviewed by mcimadamore (Committer).

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

PR: https://git.openjdk.org/jextract/pull/103

From sundar at openjdk.org  Thu Feb 16 12:07:42 2023
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 16 Feb 2023 12:07:42 GMT
Subject: Integrated: sample fixes for Arena API change.
In-Reply-To: <b5WxiB-i2_Y8sP9P7N3aqvpaFpjieZRaF6-6r1zHQPI=.bcc261e3-f882-4880-8a71-c3ec53707cfe@github.com>
References: <b5WxiB-i2_Y8sP9P7N3aqvpaFpjieZRaF6-6r1zHQPI=.bcc261e3-f882-4880-8a71-c3ec53707cfe@github.com>
Message-ID: <auRkLy1EcNiCUnxdWq6-xr-4KZOeVKf4qUXAcQGGUSs=.8a423ae5-1d06-463a-81c4-c62b1682f3a3@github.com>

On Thu, 16 Feb 2023 11:58:01 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> All samples run fine on MacOS (except for OpenGL which has been broken on Mac for a while now)

This pull request has now been integrated.

Changeset: 4863194d
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/4863194ddd5cdfda0b0160cf51cde30fa022187b
Stats:     56 lines in 27 files changed: 3 ins; 0 del; 53 mod

sample fixes for Arena API change.

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jextract/pull/103

From mcimadamore at openjdk.org  Thu Feb 16 17:41:35 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 17:41:35 GMT
Subject: RFR: Tweak jextract to reflect changes to `MemorySegment::ofAddress`
Message-ID: <Xx4bqSYWjLJQoGL26Ys1QULp7lKno8QS7XBl2PiOtys=.aeeb8c07-4782-4876-834e-5ca41f7a93fe@github.com>

This patch brings jextract in sync with the API changes in https://git.openjdk.org/panama-foreign/pull/797.

The changes are mostly trivial and, luckily, jextract bindings already shield developers from having to call `MemorySegment::ofAddress` manually, so not a lot of test changes were required.

I've also updated the samples (but I could not test them as my environment is not setup to do that). We will fix up samples issues later (if needed).

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

Commit messages:
 - Fix samples
 - Merge branch 'panama' into reinterpret
 - Initial push

Changes: https://git.openjdk.org/jextract/pull/105/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=105&range=00
  Stats: 44 lines in 20 files changed: 2 ins; 1 del; 41 mod
  Patch: https://git.openjdk.org/jextract/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/105/head:pull/105

PR: https://git.openjdk.org/jextract/pull/105

From jvernee at openjdk.org  Thu Feb 16 18:44:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Feb 2023 18:44:53 GMT
Subject: RFR: Tweak jextract to reflect changes to
 `MemorySegment::ofAddress`
In-Reply-To: <Xx4bqSYWjLJQoGL26Ys1QULp7lKno8QS7XBl2PiOtys=.aeeb8c07-4782-4876-834e-5ca41f7a93fe@github.com>
References: <Xx4bqSYWjLJQoGL26Ys1QULp7lKno8QS7XBl2PiOtys=.aeeb8c07-4782-4876-834e-5ca41f7a93fe@github.com>
Message-ID: <T7uLItBgS_vp5j1F9iH9_Qc2daQynT1QCowultlUcws=.1b756aca-bda2-47f9-8a40-9f604a3b4a0f@github.com>

On Thu, 16 Feb 2023 17:36:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch brings jextract in sync with the API changes in https://git.openjdk.org/panama-foreign/pull/797.
> 
> The changes are mostly trivial and, luckily, jextract bindings already shield developers from having to call `MemorySegment::ofAddress` manually, so not a lot of test changes were required.
> 
> I've also updated the samples (but I could not test them as my environment is not setup to do that). We will fix up samples issues later (if needed).

Marked as reviewed by jvernee (no project role).

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

PR: https://git.openjdk.org/jextract/pull/105

From mcimadamore at openjdk.org  Thu Feb 16 19:22:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 19:22:53 GMT
Subject: Integrated: Tweak jextract to reflect changes to
 `MemorySegment::ofAddress`
In-Reply-To: <Xx4bqSYWjLJQoGL26Ys1QULp7lKno8QS7XBl2PiOtys=.aeeb8c07-4782-4876-834e-5ca41f7a93fe@github.com>
References: <Xx4bqSYWjLJQoGL26Ys1QULp7lKno8QS7XBl2PiOtys=.aeeb8c07-4782-4876-834e-5ca41f7a93fe@github.com>
Message-ID: <MNA8WJNs5UlGKqDcequZzlK8n9vJp6kfPWKE6jI3YRI=.3efdace1-151f-460b-86ea-5f61500cb1a7@github.com>

On Thu, 16 Feb 2023 17:36:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch brings jextract in sync with the API changes in https://git.openjdk.org/panama-foreign/pull/797.
> 
> The changes are mostly trivial and, luckily, jextract bindings already shield developers from having to call `MemorySegment::ofAddress` manually, so not a lot of test changes were required.
> 
> I've also updated the samples (but I could not test them as my environment is not setup to do that). We will fix up samples issues later (if needed).

This pull request has now been integrated.

Changeset: 1d2f9317
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/1d2f9317bc0274112b48bdcc5c1b0786cad9f04a
Stats:     44 lines in 20 files changed: 2 ins; 1 del; 41 mod

Tweak jextract to reflect changes to `MemorySegment::ofAddress`

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jextract/pull/105

From jvernee at openjdk.org  Thu Feb 16 21:50:52 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Feb 2023 21:50:52 GMT
Subject: RFR: 8302693: TestDocComments fails on Windows
Message-ID: <zjAvGlSClBNJbstlabJEd_2dfVTlT5hABxwLafiAOWU=.ede20655-8461-424a-a0c7-943b4017e709@github.com>

TestDocComments fails on Windows because it's trying to `typedef` `size_t` with the type `unsigned long`, which is different from the type Windows uses for `size_t`: `unsigned long long`.

Using the latter works accross supported platforms though.

(I've also amended the testing framework code to print out jextract output in case of a failure)

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

Commit messages:
 - fix win failure of TestDocComments

Changes: https://git.openjdk.org/jextract/pull/106/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=106&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-8302693
  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jextract/pull/106.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/106/head:pull/106

PR: https://git.openjdk.org/jextract/pull/106

From mcimadamore at openjdk.org  Fri Feb 17 03:21:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Feb 2023 03:21:25 GMT
Subject: RFR: 8302693: TestDocComments fails on Windows
In-Reply-To: <zjAvGlSClBNJbstlabJEd_2dfVTlT5hABxwLafiAOWU=.ede20655-8461-424a-a0c7-943b4017e709@github.com>
References: <zjAvGlSClBNJbstlabJEd_2dfVTlT5hABxwLafiAOWU=.ede20655-8461-424a-a0c7-943b4017e709@github.com>
Message-ID: <n2k2eGQTTzG9DhWi6cJHnVr0ObLpNre2efAq371fT8A=.4d512a7f-f982-4de9-9130-7d25dfb0766c@github.com>

On Thu, 16 Feb 2023 21:38:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> TestDocComments fails on Windows because it's trying to `typedef` `size_t` with the type `unsigned long`, which is different from the type Windows uses for `size_t`: `unsigned long long`.
> 
> Using the latter works accross supported platforms though.
> 
> (I've also amended the testing framework code to print out jextract output in case of a failure)

Marked as reviewed by mcimadamore (Committer).

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

PR: https://git.openjdk.org/jextract/pull/106

From sundar at openjdk.org  Fri Feb 17 13:24:51 2023
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 17 Feb 2023 13:24:51 GMT
Subject: RFR: fixed samples for API change MemorySegment.slice -> asSlice and
 to re-extract libjimage binding
Message-ID: <FQmOKXt1Q5F7VU1i0chDcSoRnF2_kiNVCGgAW6BSrX0=.c617fad3-32cd-40c9-b50f-4520b57af187@github.com>

fixed samples for API change MemorySegment.slice -> asSlice and to re-extract libjimage binding

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

Commit messages:
 - fixed samples for API change MemorySegment.slice -> asSlice and to re-extract libjimage binding

Changes: https://git.openjdk.org/jextract/pull/108/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=108&range=00
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/108.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/108/head:pull/108

PR: https://git.openjdk.org/jextract/pull/108

From jvernee at openjdk.org  Fri Feb 17 13:31:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 13:31:59 GMT
Subject: RFR: fixed samples for API change MemorySegment.slice -> asSlice
 and to re-extract libjimage binding
In-Reply-To: <FQmOKXt1Q5F7VU1i0chDcSoRnF2_kiNVCGgAW6BSrX0=.c617fad3-32cd-40c9-b50f-4520b57af187@github.com>
References: <FQmOKXt1Q5F7VU1i0chDcSoRnF2_kiNVCGgAW6BSrX0=.c617fad3-32cd-40c9-b50f-4520b57af187@github.com>
Message-ID: <QguoFPUTlGx0u4m6DE_6GcyJhzfkXwahggxG57aHH0s=.7a6e6e17-7341-429c-a9db-c145c84ecd10@github.com>

On Fri, 17 Feb 2023 13:08:23 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> fixed samples for API change MemorySegment.slice -> asSlice and to re-extract libjimage binding

Marked as reviewed by jvernee (no project role).

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

PR: https://git.openjdk.org/jextract/pull/108

From sundar at openjdk.org  Fri Feb 17 13:32:00 2023
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 17 Feb 2023 13:32:00 GMT
Subject: Integrated: fixed samples for API change MemorySegment.slice ->
 asSlice and to re-extract libjimage binding
In-Reply-To: <FQmOKXt1Q5F7VU1i0chDcSoRnF2_kiNVCGgAW6BSrX0=.c617fad3-32cd-40c9-b50f-4520b57af187@github.com>
References: <FQmOKXt1Q5F7VU1i0chDcSoRnF2_kiNVCGgAW6BSrX0=.c617fad3-32cd-40c9-b50f-4520b57af187@github.com>
Message-ID: <Ta7wxdQCkeOnDkmE1eKnEYb_bbiL9wRcs7kJJgZQWQc=.d6759a64-cdfd-48ef-a53d-f5513720678e@github.com>

On Fri, 17 Feb 2023 13:08:23 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> fixed samples for API change MemorySegment.slice -> asSlice and to re-extract libjimage binding

This pull request has now been integrated.

Changeset: 8f412795
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/8f412795eea509f233d2ae30bafff4452dc0b6bb
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

fixed samples for API change MemorySegment.slice -> asSlice and to re-extract libjimage binding

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jextract/pull/108

From jvernee at openjdk.org  Fri Feb 17 15:17:50 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 15:17:50 GMT
Subject: RFR: 7903436: Changes needed for jdk20-based makefile build
Message-ID: <xolLfSKF-0szMJoY92mqCqlt_qx3SKIt_iE-WZ0z45E=.a15ce7a9-783d-40c2-8fe4-6b39a500a601@github.com>

These are the changes for jdk20-based makefile builds. Just 2 simple version bumps

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

Commit messages:
 - update Java version in makefiles for jdk20

Changes: https://git.openjdk.org/jextract/pull/107/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=107&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903436
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/107.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/107/head:pull/107

PR: https://git.openjdk.org/jextract/pull/107

From mcimadamore at openjdk.org  Fri Feb 17 15:55:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Feb 2023 15:55:20 GMT
Subject: RFR: 7903437: Improve translation strategy for function pointers
Message-ID: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>

The current translation stragegy for function pointers is not very efficient. Every time a lambda expression is turned into an upcall stub, a new method handle lookup is performed, which is quite a slow operation.

This patch improves the translation strategy so that the lookup is only performed once. For instance, considering the following `typedef`:


typedef void (*cb)(int, int);


jextract will generate the following functional interface:


import static java.lang.foreign.ValueLayout.*;
/**
 * {@snippet :
 * void (*cb)(int,int);
 * }
 */
public interface cb {

    void apply(int _x0, int _x1);
    static MemorySegment allocate(cb fi, Arena scope) {
        return RuntimeHelper.upcallStub(constants$0.cb_UP$MH, fi, constants$0.cb$FUNC, scope);
    }
    static cb ofAddress(MemorySegment addr, Arena arena) {
        MemorySegment symbol = addr.reinterpret(arena.scope(), null);
        return (int __x0, int __x1) -> {
            try {
                constants$0.cb_DOWN$MH.invokeExact(symbol, __x0, __x1);
            } catch (Throwable ex$) {
                throw new AssertionError("should not reach here", ex$);
            }
        };
    }
}


Where the constants are defined as follows:


    static final FunctionDescriptor cb$FUNC = FunctionDescriptor.ofVoid(
        Constants$root.C_INT$LAYOUT,
        Constants$root.C_INT$LAYOUT
    );
    
    static final FunctionDescriptor cb_UP$FUNC = FunctionDescriptor.ofVoid(
        Constants$root.C_INT$LAYOUT,
        Constants$root.C_INT$LAYOUT
    );
    
    static final MethodHandle cb_UP$MH = RuntimeHelper.upcallHandle(cb.class, "apply", constants$0.cb_UP$FUNC);
    
    static final FunctionDescriptor cb_DOWN$FUNC = FunctionDescriptor.ofVoid(
        Constants$root.C_INT$LAYOUT,
        Constants$root.C_INT$LAYOUT
    );
    
    static final MethodHandle cb_DOWN$MH = RuntimeHelper.downcallHandle(
        constants$0.cb_DOWN$FUNC
    );


And, where `RuntimeHelper::upcallHandler` is defined as follows:


static MethodHandle upcallHandle(Class<?> fi, String name, FunctionDescriptor fdesc) {
        try {
            return MH_LOOKUP.findVirtual(fi, name, fdesc.toMethodType());
        } catch (Throwable ex) {
            throw new AssertionError(ex);
        }
    }


This allows to perform the method handle lookup only once. This means that when creating an upcall stub, we only have to `bind` the functional interface instance to the method handle, and then create an upcall stub with the resulting handle. Both operations should be fast after the first time, because of caching.

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

Commit messages:
 - Remove redundant import
 - Initial push

Changes: https://git.openjdk.org/jextract/pull/109/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=109&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903437
  Stats: 41 lines in 4 files changed: 28 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jextract/pull/109.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/109/head:pull/109

PR: https://git.openjdk.org/jextract/pull/109

From jvernee at openjdk.org  Fri Feb 17 19:55:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 19:55:00 GMT
Subject: RFR: 7903437: Improve translation strategy for function pointers
In-Reply-To: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
References: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
Message-ID: <BIUNE1rV6mIY0Sut9vOaQCWDQmczrcISs307hCWO7_8=.2faf9d6f-b2cb-4edf-b124-f89c98c0a654@github.com>

On Fri, 17 Feb 2023 15:32:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The current translation stragegy for function pointers is not very efficient. Every time a lambda expression is turned into an upcall stub, a new method handle lookup is performed, which is quite a slow operation.
> 
> This patch improves the translation strategy so that the lookup is only performed once. For instance, considering the following `typedef`:
> 
> 
> typedef void (*cb)(int, int);
> 
> 
> jextract will generate the following functional interface:
> 
> 
> import static java.lang.foreign.ValueLayout.*;
> /**
>  * {@snippet :
>  * void (*cb)(int,int);
>  * }
>  */
> public interface cb {
> 
>     void apply(int _x0, int _x1);
>     static MemorySegment allocate(cb fi, Arena scope) {
>         return RuntimeHelper.upcallStub(constants$0.cb_UP$MH, fi, constants$0.cb$FUNC, scope);
>     }
>     static cb ofAddress(MemorySegment addr, Arena arena) {
>         MemorySegment symbol = addr.reinterpret(arena.scope(), null);
>         return (int __x0, int __x1) -> {
>             try {
>                 constants$0.cb_DOWN$MH.invokeExact(symbol, __x0, __x1);
>             } catch (Throwable ex$) {
>                 throw new AssertionError("should not reach here", ex$);
>             }
>         };
>     }
> }
> 
> 
> Where the constants are defined as follows:
> 
> 
>     static final FunctionDescriptor cb$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final FunctionDescriptor cb_UP$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final MethodHandle cb_UP$MH = RuntimeHelper.upcallHandle(cb.class, "apply", constants$0.cb_UP$FUNC);
>     
>     static final FunctionDescriptor cb_DOWN$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final MethodHandle cb_DOWN$MH = RuntimeHelper.downcallHandle(
>         constants$0.cb_DOWN$FUNC
>     );
> 
> 
> And, where `RuntimeHelper::upcallHandler` is defined as follows:
> 
> 
> static MethodHandle upcallHandle(Class<?> fi, String name, FunctionDescriptor fdesc) {
>         try {
>             return MH_LOOKUP.findVirtual(fi, name, fdesc.toMethodType());
>         } catch (Throwable ex) {
>             throw new AssertionError(ex);
>         }
>     }
> 
> 
> This allows to perform the method handle lookup only once. This means that when creating an upcall stub, we only have to `bind` the functional interface instance to the method handle, and then create an upcall stub with the resulting handle. Both operations should be fast after the first time, because of caching.

Should we generate the clang bindings with this new translation strategy as well?

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

PR: https://git.openjdk.org/jextract/pull/109

From mcimadamore at openjdk.org  Fri Feb 17 21:55:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Feb 2023 21:55:46 GMT
Subject: RFR: 7903437: Improve translation strategy for function pointers
In-Reply-To: <BIUNE1rV6mIY0Sut9vOaQCWDQmczrcISs307hCWO7_8=.2faf9d6f-b2cb-4edf-b124-f89c98c0a654@github.com>
References: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
 <BIUNE1rV6mIY0Sut9vOaQCWDQmczrcISs307hCWO7_8=.2faf9d6f-b2cb-4edf-b124-f89c98c0a654@github.com>
Message-ID: <C1l4QzgS8pfDOoRynGOlMs2s5lCfYUgbx5cUSXON7YM=.60d37ea6-2434-444e-a880-4f861d6744b3@github.com>

On Fri, 17 Feb 2023 19:52:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Should we generate the clang bindings with this new translation strategy as well?

Yes, but I think it would be better to do that separately, as that adds some noise (also because of other changes caused by the API update).

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

PR: https://git.openjdk.org/jextract/pull/109

From jvernee at openjdk.org  Fri Feb 17 22:01:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 22:01:48 GMT
Subject: RFR: 7903437: Improve translation strategy for function pointers
In-Reply-To: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
References: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
Message-ID: <QPB1kN59GtzX23WV52P4CxrmryNLDcwB0aVz-V4-gSs=.801bfdd0-bbcc-4052-9f56-7ea33e6a354d@github.com>

On Fri, 17 Feb 2023 15:32:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The current translation stragegy for function pointers is not very efficient. Every time a lambda expression is turned into an upcall stub, a new method handle lookup is performed, which is quite a slow operation.
> 
> This patch improves the translation strategy so that the lookup is only performed once. For instance, considering the following `typedef`:
> 
> 
> typedef void (*cb)(int, int);
> 
> 
> jextract will generate the following functional interface:
> 
> 
> import static java.lang.foreign.ValueLayout.*;
> /**
>  * {@snippet :
>  * void (*cb)(int,int);
>  * }
>  */
> public interface cb {
> 
>     void apply(int _x0, int _x1);
>     static MemorySegment allocate(cb fi, Arena scope) {
>         return RuntimeHelper.upcallStub(constants$0.cb_UP$MH, fi, constants$0.cb$FUNC, scope);
>     }
>     static cb ofAddress(MemorySegment addr, Arena arena) {
>         MemorySegment symbol = addr.reinterpret(arena.scope(), null);
>         return (int __x0, int __x1) -> {
>             try {
>                 constants$0.cb_DOWN$MH.invokeExact(symbol, __x0, __x1);
>             } catch (Throwable ex$) {
>                 throw new AssertionError("should not reach here", ex$);
>             }
>         };
>     }
> }
> 
> 
> Where the constants are defined as follows:
> 
> 
>     static final FunctionDescriptor cb$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final FunctionDescriptor cb_UP$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final MethodHandle cb_UP$MH = RuntimeHelper.upcallHandle(cb.class, "apply", constants$0.cb_UP$FUNC);
>     
>     static final FunctionDescriptor cb_DOWN$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final MethodHandle cb_DOWN$MH = RuntimeHelper.downcallHandle(
>         constants$0.cb_DOWN$FUNC
>     );
> 
> 
> And, where `RuntimeHelper::upcallHandler` is defined as follows:
> 
> 
> static MethodHandle upcallHandle(Class<?> fi, String name, FunctionDescriptor fdesc) {
>         try {
>             return MH_LOOKUP.findVirtual(fi, name, fdesc.toMethodType());
>         } catch (Throwable ex) {
>             throw new AssertionError(ex);
>         }
>     }
> 
> 
> This allows to perform the method handle lookup only once. This means that when creating an upcall stub, we only have to `bind` the functional interface instance to the method handle, and then create an upcall stub with the resulting handle. Both operations should be fast after the first time, because of caching.

> > Should we generate the clang bindings with this new translation strategy as well?
> 
> Yes, but I think it would be better to do that separately, as that adds some noise (also because of other changes caused by the API update).

Good point.

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

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.org/jextract/pull/109

From mcimadamore at openjdk.org  Fri Feb 17 23:57:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Feb 2023 23:57:45 GMT
Subject: Integrated: 7903437: Improve translation strategy for function
 pointers
In-Reply-To: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
References: <S9P116QwV1w2OSn8Do9ws6yNaBQw2fT6h1aUaS25aoQ=.ed69f96b-414a-4d1b-97ef-ee8005598dfb@github.com>
Message-ID: <b6WxGuGH7PAutHK7a5PpdaQKLh72AQs3vssKeGIL8cU=.b21eeffa-4f84-4230-970b-61479ded9381@github.com>

On Fri, 17 Feb 2023 15:32:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The current translation stragegy for function pointers is not very efficient. Every time a lambda expression is turned into an upcall stub, a new method handle lookup is performed, which is quite a slow operation.
> 
> This patch improves the translation strategy so that the lookup is only performed once. For instance, considering the following `typedef`:
> 
> 
> typedef void (*cb)(int, int);
> 
> 
> jextract will generate the following functional interface:
> 
> 
> import static java.lang.foreign.ValueLayout.*;
> /**
>  * {@snippet :
>  * void (*cb)(int,int);
>  * }
>  */
> public interface cb {
> 
>     void apply(int _x0, int _x1);
>     static MemorySegment allocate(cb fi, Arena scope) {
>         return RuntimeHelper.upcallStub(constants$0.cb_UP$MH, fi, constants$0.cb$FUNC, scope);
>     }
>     static cb ofAddress(MemorySegment addr, Arena arena) {
>         MemorySegment symbol = addr.reinterpret(arena.scope(), null);
>         return (int __x0, int __x1) -> {
>             try {
>                 constants$0.cb_DOWN$MH.invokeExact(symbol, __x0, __x1);
>             } catch (Throwable ex$) {
>                 throw new AssertionError("should not reach here", ex$);
>             }
>         };
>     }
> }
> 
> 
> Where the constants are defined as follows:
> 
> 
>     static final FunctionDescriptor cb$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final FunctionDescriptor cb_UP$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final MethodHandle cb_UP$MH = RuntimeHelper.upcallHandle(cb.class, "apply", constants$0.cb_UP$FUNC);
>     
>     static final FunctionDescriptor cb_DOWN$FUNC = FunctionDescriptor.ofVoid(
>         Constants$root.C_INT$LAYOUT,
>         Constants$root.C_INT$LAYOUT
>     );
>     
>     static final MethodHandle cb_DOWN$MH = RuntimeHelper.downcallHandle(
>         constants$0.cb_DOWN$FUNC
>     );
> 
> 
> And, where `RuntimeHelper::upcallHandler` is defined as follows:
> 
> 
> static MethodHandle upcallHandle(Class<?> fi, String name, FunctionDescriptor fdesc) {
>         try {
>             return MH_LOOKUP.findVirtual(fi, name, fdesc.toMethodType());
>         } catch (Throwable ex) {
>             throw new AssertionError(ex);
>         }
>     }
> 
> 
> This allows to perform the method handle lookup only once. This means that when creating an upcall stub, we only have to `bind` the functional interface instance to the method handle, and then create an upcall stub with the resulting handle. Both operations should be fast after the first time, because of caching.

This pull request has now been integrated.

Changeset: dfafbbe7
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/dfafbbe7d6ab3c190dae5519236bef718fd10755
Stats:     41 lines in 4 files changed: 28 ins; 2 del; 11 mod

7903437: Improve translation strategy for function pointers

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jextract/pull/109

From pminborg at openjdk.org  Mon Feb 20 08:56:42 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Feb 2023 08:56:42 GMT
Subject: RFR: Add path independence [v2]
In-Reply-To: <sF8Wi82un7AW3micwsMGbspGDZyXEFQpgMiyTav5XkM=.05edda59-c34a-49cf-a51e-4448c9002cc7@github.com>
References: <sF8Wi82un7AW3micwsMGbspGDZyXEFQpgMiyTav5XkM=.05edda59-c34a-49cf-a51e-4448c9002cc7@github.com>
Message-ID: <qv5gEJqNNhTnuTGZXL1U60QFTIwvnAZQUN_n4k8QRH0=.b2b52c3c-1aa3-474a-9788-4821fb5c8655@github.com>

> This small PR incorporated feedback from the original PR: https://github.com/openjdk/jextract/pull/66 made after it was integrated.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge panama and mention specific version
 - Add path independence

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

Changes: https://git.openjdk.org/jextract/pull/68/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=68&range=01
  Stats: 13 lines in 4 files changed: 6 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jextract/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/68/head:pull/68

PR: https://git.openjdk.org/jextract/pull/68