Dear Rony, I assume this functionality can not be made a library (like orxutils et al) but need to be included in the build process, right? IF not included/accepted in the trunk I suggest you put all the necessary files in an entry under tools and document how to make it work. In this way anyone who wants to give it a try can do so without affecting the official builds.
As someone pointed out this seems to be a substantial effort and we should keep it in the SVN repository. Hälsningar/Regards/Grüsse, ooRexx oor...@jonases.se > On 16. Jul 2022, at 17:11, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > > While debugging (for almost two months) ooRexx and BSF4ooRexx/Java it was > almost impossible to determine the source of some memory leaks. > > The reason was not being able to rely on the garbage collector having run at > a specific point in time such that all objects that have no references > anymore get garbage collected and if uninit methods present have them run. > Only then would an analysis become really possible. > > As it is possible with Java to kick the Java garbage collector in order to > get at a stable state with regards to garbage collecting Java objects a gc() > for ooRexx would make it possible to arrive at the same ability for ooRexx: > to become able to arrive at a stable state at a certain point in time. Only > then would it become possible to assess where the sources of memory leaks are > rooted: on the ooRexx side or on the Java side. > > Consider also the runtime dynamics in this context: there are cross > calls/invocations, even on different ooRexx and on different Java > threads at the same time (which all need to be controlled/synchronized while > debugging). > > In the end I created a gc() built in function in my "personal ooRexx > interpreter" ;) to become able to debug ooRexx and Java/BSF4ooRexx to help > identify all such locations and determine which side is responsible for > keeping references that should have been freed. While debugging quite a lot > of programs got created that would excercise gc() and java.lang.System.gc() > allowing to determine the various sources of memory leaks (ooRexx and Java > side) and thereby becoming able to address them and test the solutions. > Again, without gc on the ooRexx side this would not have been possible! > > --- > > For everyone who has such a need (to debug complex interactions with external > function libraries with observed memory leaks) it is mandatory to have the > ability in ooRexx available to kick off the ooRexx garbage collector to > achieve a stable state. > > Therefore proposing to add a gc() BIF (built-in-function) to ooRexx to enable > debugging in such dynamic native peer systems/environments. > > As any garbage collector run is relatively expensive it is necessary to warn > any ooRexx programmer from using the gc() BIF in regular programs and make > sure they only consider its use for debugging only. This may be achieved by > creating a documentation that communicates this fact clearly/explicitly, > maybe something along the lines: > > "Warning: this function should only be used for developers who explicitly > have a very special need of debugging memory leaks with external function > libraries! > Do not use this function in regular ooRexx applications as each explicit > invocation of this function is very expensive and may slow down the execution > of your ooRexx application considerably! > This function will kick off the ooRexx garbage collector out-of-bounds and > finalize all objects that have no references at that particular point in time > and run their uninit methods if present. > Remark: the ooRexx garbage collector will get invoked by the interpreter at > well defined states and will thereby make sure that the programs will execute > as efficiently as possible. Therefore there is no need - other than for > debugging - to explicitly invoke the garbage collector out-of-bounds." > Of course, not being a native English speaker the above draft for the > documentation text may need to be rephrased to be more clear. However, it > should be clear for everyone that the ooRexx gc() BIF is not meant to be used > for production. > > ---rony > > > > > _______________________________________________ > 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
