From nbenalla at openjdk.org Wed Jun 25 16:03:18 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 25 Jun 2025 16:03:18 GMT Subject: RFR: 7904049: Add LLM inference example to jextract samples Message-ID: Please review this PR to add an LLM inference example to the jextract samples. Thanks! ------------- Commit messages: - onnx inference example Changes: https://git.openjdk.org/jextract/pull/285/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=285&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904049 Stats: 186 lines in 4 files changed: 186 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jextract/pull/285.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/285/head:pull/285 PR: https://git.openjdk.org/jextract/pull/285 From mcimadamore at openjdk.org Wed Jun 25 16:10:42 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 25 Jun 2025 16:10:42 GMT Subject: RFR: 7904049: Add LLM inference example to jextract samples In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 15:58:28 GMT, Nizar Benalla wrote: > Please review this PR to add an LLM inference example to the jextract samples. > > Thanks! samples/onnx/OnnxGenerator.java line 125: > 123: public void close() throws Exception { > 124: arena.close(); > 125: OgaDestroyGenerator(generator); I wonder if we should `MemorySegment::reinterpret` to associate cleanup action to the various segments -- and then just call `arena.close()` from here? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/285#discussion_r2167093284 From mcimadamore at openjdk.org Wed Jun 25 16:10:42 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 25 Jun 2025 16:10:42 GMT Subject: RFR: 7904049: Add LLM inference example to jextract samples In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 16:07:00 GMT, Maurizio Cimadamore wrote: >> Please review this PR to add an LLM inference example to the jextract samples. >> >> Thanks! > > samples/onnx/OnnxGenerator.java line 125: > >> 123: public void close() throws Exception { >> 124: arena.close(); >> 125: OgaDestroyGenerator(generator); > > I wonder if we should `MemorySegment::reinterpret` to associate cleanup action to the various segments -- and then just call `arena.close()` from here? (this could be achieved by passing a cleanup action to `call` and then calling reinterpret from there with the cleanup action) ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/285#discussion_r2167095242 From nbenalla at openjdk.org Mon Jun 30 10:16:35 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 30 Jun 2025 10:16:35 GMT Subject: RFR: 7904049: Add LLM inference example to jextract samples [v2] In-Reply-To: References: Message-ID: <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com> > Please review this PR to add an LLM inference example to the jextract samples. > > Thanks! Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: use `MemorySegment::reinterpret` to clean up objects modify compile script slightly ------------- Changes: - all: https://git.openjdk.org/jextract/pull/285/files - new: https://git.openjdk.org/jextract/pull/285/files/84ee7762..b023e0a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=285&range=01 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=285&range=00-01 Stats: 21 lines in 2 files changed: 8 ins; 6 del; 7 mod Patch: https://git.openjdk.org/jextract/pull/285.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/285/head:pull/285 PR: https://git.openjdk.org/jextract/pull/285 From nbenalla at openjdk.org Mon Jun 30 16:25:38 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 30 Jun 2025 16:25:38 GMT Subject: RFR: 7904051: Jextract should generate symbols in the same class consistently Message-ID: Copying the bug description: > A symbol, depending on the order that clang found it will not necessarily be in the same class every time. The IDE works against you here, when you navigate to a symbol and it exists in header number 4 for example, it will sometimes automatically import header number 4 so you have to go and change it because you want to get it from the top level class. >If you don't do that, you build a dependency for your platform into the generated code. >The symbols not being consistent across platforms can be fixed by sorting the symbols. Very simple change, done in a way to not break existing code as a simple sort would've changed the names of variables in the generated code. There was a test case that had to be updated. ------------- Commit messages: - sort symbols and update test case Changes: https://git.openjdk.org/jextract/pull/286/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=286&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904051 Stats: 8 lines in 2 files changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jextract/pull/286.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/286/head:pull/286 PR: https://git.openjdk.org/jextract/pull/286