viirya edited a comment on issue #1425: URL: https://github.com/apache/arrow-rs/issues/1425#issuecomment-1065344760
> Let me put in another way. > > Let's say in Java you create an ArrowArray and import in this lib using try_from_raw API, and this API clone the ArrowArray, which means **_there will be two struct point to the same data_**, one is in Jave another is in rust. Then > > 1. If you free the pointer in Java(which by design will also free all the data it point to), it will be seg fault in rust if you try to access it; > > 2. And you just can't hold the Java's pointer until it's used/freed by rust, because you don't when it will be used. So it's a memory leak. > > > I bet currently in your Java program there is memory leak because of these. > I'm not sure if you really use this FFI between Java and Rust. We have real use case to use it in an internal project. We found this issue and the fix works very well after upgrading to latest version. And, no, I don't detect memory leak there. Let me explain more. First, of course if you free the pointer in Java, you will release the data and Rust cannot access it anymore. If you really want to free it, make sure to clear up the release field in the struct. This is easy to do with Java FFI API. In our case, the struct in Java won't be released until the arrays are exhausted by Rust. So we don't even need to do that. In contrast, I don't know what you describe will work better. Let's say we don't clone it, then in Java and Rust, there is only one struct. So, if you free the pointer in Java, it still releases the data, isn't? The only possible is to check the release field of the struct to know if the struct is released or not by Rust. You even cannot mark it released. I don't see there is any better point. The only missing piece, here, is that we need to mark the source struct released in Rust side. This is required by ["Moving an array](https://arrow.apache.org/docs/format/CDataInterface.html#moving-an-array)" which talks about the case to clone the struct. I can do it later. > I think the way to fix your issue is to change the Java API design, to let other language like rust to pass in a FFI_ArrowArray::empty() struct pointer, and populate data into this struct, and let rust handle the memory itself. That's why I say "the one who allocate it should free it" Although I think this will work but I don't think it is a good idea. By doing that, it means to add an additional JNI call to Rust side to get the empty struct pointer. We're likely to have less JNI call as possible. I agree that the struct should be released by who allocates it. Actually you cannot free Java struct in Rust, and vice versa. I don't think we did this or intend to do it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
