[code-reflection] RFR: ONNX FFM Runtime initial work [v3]

Adam Sotona asotona at openjdk.org
Mon Feb 10 14:01:25 UTC 2025


On Mon, 10 Feb 2025 13:13:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor rename
>
> cr-examples/onnx/src/main/java/oracle/code/onnx/OnnxRuntime.java line 214:
> 
>> 212:         }
>> 213: 
>> 214:         public final class Session implements AutoCloseable {
> 
> There's another lifetime here - that of the session. I notice few things here:
> * you expect access to be single-threaded (otherwise, reusing the `ret` output segment will backfire)
> * you expect the session to be no longer used after the close method on session is closed
> 
> Both aspects could be modeled by having `Session` carry a new confined arena, and reinterpret the session segment to that arena (so that access is thread-confined, and only possible while the session is alive). When the session is closed, you  should call the confined arena close. You can also register (while reinterpreting) a manual cleanup action, to be invoked on the session segment when the confined arena is closed (e.g. to call `releaseSession`).
> 
> This will guarantee that no method on session can be called _after_ the session has been closed (note any such call will likely result in a JVM crash because of use-after-free, so that seems valuable?)

Yes, both assumptions are right.
Single `ret` design has been selected for simplicity and there are no constraints checked, so double-close will throw or maybe even kill JVM.
I have some ideas how to cache sessions for models and auto-close them with the environment, plus some other performance improvements.
However with Paul we agreed it is not a #1 priority for now. The design should stay simple for easy refactoring as the API will settle down with the use cases.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/311#discussion_r1949104293


More information about the babylon-dev mailing list