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
