[code-reflection] RFR: Onnx subgraphs, lambda execution and BB removal [v3]

Paul Sandoz psandoz at openjdk.org
Wed Feb 26 17:34:07 UTC 2025


On Wed, 26 Feb 2025 16:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Onnx subgraphs, lambda execution and BB removal
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removal of Tensor::asByteBuffer

Nice cleanup. There is a bunch of raw type usage for `Tensor` we should cleanup.

cr-examples/onnx/src/test/java/oracle/code/onnx/MNISTDemo.java line 44:

> 42:     public static float[] loadConstant(String resource) {
> 43:         try {
> 44:             return MemorySegment.ofArray(MNISTDemo.class.getResourceAsStream(resource).readAllBytes())

We should use try-with-resources on `MNISTDemo.class.getResourceAsStream(resource)` so the resource is closed.

cr-examples/onnx/src/test/java/oracle/code/onnx/MNISTDemo.java line 52:

> 50: 
> 51:     public static Tensor<Float> cnn(Tensor<Float> inputImage) {
> 52:         return OnnxRuntime.execute(() -> {

I think it's preferable to eventually express the following:

OnnxRuntime.execute(() -> cnn(inputImage));

i.e. i would like to see that expression embedded in the drawing code.

This generally requires that we support invocations to other ONNX functions (or we inline when transforming), which we anyway should eventually work out.

For the case of a single method invocation it should be possible to take a short cut for now (for clues see `LambdaOp.methodReference` which we could refine). So i would recommend following up on the short cut and leaning into that so we can pull out the execute from the `cnn` method.

With this approach we still need to eventually workout the difference between initializers and inputs. I believe the former is the generally accepted way of representing constant input rather than more directly as constants in the graph.

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

PR Review: https://git.openjdk.org/babylon/pull/326#pullrequestreview-2645257454
PR Review Comment: https://git.openjdk.org/babylon/pull/326#discussion_r1972040058
PR Review Comment: https://git.openjdk.org/babylon/pull/326#discussion_r1972020840


More information about the babylon-dev mailing list