[code-reflection] RFR: Model lifetimes of onnx session-related objects more explicitly

[Adam Pocock]

On Mon, 3 Mar 2025 14:34:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > There is an allocator concept too which I've ignored in the Java API but have had several requests to expose (it'll allow things like allocating directly onto the GPU, which is more useful when you can express GPU memory segments, not sure how to do that in the existing JNI based API), that maps more directly onto the arenas and I'd base the API around that if I was writing it today.
> 
> I see - I have seen allocators on the C API. I'm not sure those needs to be exposed -- I'd assume these are mostly there to allow e.g. allocating a tensor on the GPU (probably in a transparent fashion). For the Java API, it seems to me that the capabilities exposed by an ORTAllocator can be emulated by using memory segment + arena + reinterpret, and then use the tensor factory that accepts existing data:
> 
> https://onnxruntime.ai/docs/api/c/struct_ort_api.html#a2aad3ccd68c66d0b38bdb966467d9324

Yeah, I think it can be hidden for most use cases (the concept exists in the Java API but it's an internal implementation detail). The allocator is used in a bunch of other utility methods where it allocates strings & other objects in addition to tensor creation, but those can typically be put on the CPU default one.

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

PR Comment: https://git.openjdk.org/babylon/pull/332#issuecomment-2694655713