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.) —-rony Rony G. Flatscher (mobil/e) _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
