Release native resources from Java via AutoCloseable

[oliviercailloux]

Reading #100, it seems that by design OR-Tools does not provide a way to explicitly close solvers and release native resources created by the JNI calls. Finalizers are supposed to take care of this, AFAIU.

This is rather unusual in Java, and, if I dare to say, is usually considered incorrect. Bloch’s Effective Java explains it in detail in Item 8 (of the 3rd edition).

As a summary: “Finalizers are unpredictable, often dangerous, and generally unnecessary. Their use can cause erratic behavior, poor performance, and portability problems. Finalizers have a few valid uses, which we’ll cover later in this item, but as a rule, you should avoid them. (…) C++ programmers are cautioned not to think of finalizers or cleaners as Java’s analogue of C++ destructors.”

The normal mechanism is to implement AutoCloseable and let your users close resources when they know they don’t need them any more.

[lperron]

actually, we do not implement anything. Swig does. I would not think that swig is incorrect. #100 was about the destructor not being wrapped by swig, which was fixed. Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53 00 Le ven. 1 févr. 2019 à 03:56, Olivier Cailloux <notifications@github.com> a écrit :

…

Reading #100 <#100>, it seems that by design OR-Tools does not provide a way to explicitly close solvers and release native resources created by the JNI calls. Finalizers are supposed to take care of this, AFAIU. This is rather unusual in Java, and, if I dare to say, is usually considered incorrect. Bloch’s Effective Java <https://www.amazon.com/Effective-Java-Joshua-Bloch/dp/0134685997> explains it in detail in Item 8 (of the 3rd edition). As a summary: “Finalizers are unpredictable, often dangerous, and generally unnecessary. Their use can cause erratic behavior, poor performance, and portability problems. Finalizers have a few valid uses, which we’ll cover later in this item, but as a rule, you should avoid them. (…) C++ programmers are cautioned not to think of finalizers or cleaners as Java’s analogue of C++ destructors.” The normal mechanism is to implement AutoCloseable and let your users close resources when they know they don’t need them any more. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1040>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKj17fP61h2Zq6a6fl-UxN_Rhy6Sn7qXks5vI6zBgaJpZM4adj6c> .

[oliviercailloux]

Swig only does what the developer tells it to do. My arguments have not been answered or even considered.

[lperron]

I do not know. I do not write anything related to memory management in my swig code. Please tell me what I should do. Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53 00 Le ven. 1 févr. 2019 à 14:25, Olivier Cailloux <notifications@github.com> a écrit :

…

Swig only does what the developer tells it to do. My arguments have not been answered or even considered. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1040 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKj17UJ7DQMzcAahv57K-LMcUhdF0eEUks5vJEBggaJpZM4adj6c> .

[oliviercailloux]

I am afraid I do not have a ready made solution for you… I only wanted to draw attention to this possible problem, not claim that I am ready to solve it. Solving it would require, I think, not huge time and effort, but still, probably some significant time and effort and some planning and thinking about a few API changes.

I am sure that at Google you do have very experimented developers in Java that will be able to help. (I am a happy user of Guava.)

[lperron]

Actually, I am mimicking java swig usage at Google. I have not seen any complex memory management code, and I search the web for "java swig autocloseable" and did not find any reference. Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53 00 Le ven. 1 févr. 2019 à 15:11, Olivier Cailloux <notifications@github.com> a écrit :

…

I am afraid I do not have a ready made solution for you… I only wanted to draw attention to this possible problem, not claim that I am ready to solve it. Solving it would require, I think, not huge time and effort, but still, probably some significant time and effort and some planning and thinking about a few API changes. I am sure that at Google you do have very experimented developers in Java that will be able to help. (I am a happy user of Guava <https://github.com/google/guava/wiki>.) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1040 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKj17WLglTqID-TvnoUfHzvM8yY9lMDdks5vJEsZgaJpZM4adj6c> .

[oliviercailloux]

Indeed the SWIG doc itself suggests to leave the GC mechanism reclaim memory automatically. That runs exactly counter the advice of Bloch (which, I think, has good arguments to defend his point of view, whereas SWIG does not argue on that topic). Perhaps the SWIG people would consider Bloch too perfectionist on that topic? (Or perhaps they simply didn’t think about his arguments.) OTOH, LP is precisely a domain where performance and good memory management matter. I’d suggest you to read the item I cited in my first post and decide.

If you opt for explicit possibility of releasing resources, I think you simply have to add explicit method calls that release resources and that your users can call through a method called “close” (by convention and because it allows the object to implement AutoCloseable). I don’t think any of this would be special to SWIG, that would just be normal method calls through JNI (wrapped by SWIG, of course). Perhaps this can help? I don’t know much about SWIG so I may be wrong.

FWIW, CPLEX allows to close resources from Java. But as it’s not open source, I’m not sure how much you can learn from this. At least the high level API is available for study.

[lperron]

Thanks for the insight.
Unless someone come with a compelling example that demonstrates this is the only solution, I will not complexify my swig code. This is already too much of a burden.