On Wed, Jul 6, 2022 at 3:03 PM Rony <rony.flatsc...@wu.ac.at> wrote: > While debugging potential memory leaks I could narrow one down to the > currently not tested hypothesis that if interpreter instances get > terminated it may be the case that either the .local contained objects or > the destination objects of the .local monitors do not release the > references such that no uninit method runs. > > Background: in BSF4ooRexx whenever a ScriptEngine instance gets created an > ooRexx interpreter instance gets created in which the .local monitors get > redirected to Java‘s System.in, System.out and System.err. This occurs by > wrapping up these Java objects as BSF objects which then get used to set > the destinations for the .input, .output, .error, .traceoutput and > .debuginput monitors. Upon termination of these ooRexx interpreter instance > these BSF objects should get unreferenced such that their uninit methods > can run which remove the reference to their peer Java objects in the Java > registry, allowing them to be garbage collected on the Java side. This > seems to not happen. > > After having come up with a Java registry analyze class plus a garbage > collector BIF on the ooRexx side I have become able to get a raw overview > about the area where running hundreds, if not thousands of ooRexx > interpreter instances (each JSP request will cause an ooRexx interpreter > instance to be created to process the Rexx-JSPs) causes continuous memory > consumption on the Java side. Carrying out the redirections of the .local > monitors manually to and from Java shows that the reference counting via > the uninit works and no memory leaks occur. > > So, is it possible that either .local or the destination objects of the > contained monitors do not get freed if an ooRexx interpreter instance gets > terminated? (Thinking about this, I need to verify tomorrow that the > instances get explicitly terminated, did not double-check that today.) >
The reference to the .local directory is most definitely released upon instance termination. Note, however, that this happens AFTER the end-of-instance garbage collection and uninit pass, since it is necessary to run the uninit methods in a fully functional interpreter instance. And NO, adding an additional garbage collection cycle after that is not the answer. GC cycles are very expensive and really should be avoided as much as possible. Rick > > —-rony > > Rony G. Flatscher (mobil/e) > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
