There is a new library for ooRexx in development by one of my students, where objects from the other
side get proxied in registries. For debugging, it is necessary to be able to kick off a garbage
collection run.
However, as has been pointed out and discussed, it has been seen as dangerous for the performance of
ooRexx programs if ooRexx programmers use such a feature wrongly (e.g., too many times at the wrong
place, etc.).
My take would be that if programmers are made aware of that potential problem and strongly advised
not to use it for regular programs, only for situations where it becomes important that external
resources get freed that are held by Rexx objects that became garbage but do not get garbage
collected in a timely manner.
Maybe an approach like this can be acceptable?
* define a gc() built-in function that works by default in a debug version of
ooRexx (i.e.,
RexxInfo~debug yields .true) and returns .true to indicate that the BIF got
carried out,
* invoking some gc() on the release version of ooRexx (i.e., RexxInfo~debug
yields .false) does
not invoke the garbage collector and returns therefore .false.
o for very rare, special situations (like freeing external resources as
timely as possible if
Rexx objects pinning them down turn to garbage) it may make sense to
allow gc() to be run on
a release version; in order to make this explicit one could think of
allowing an argument
like "EMERGENCY" (intentionally in uppercase and spelled out), but only
for the release
version, which would indeed invoke the garbage collection on a release
version as well and
then return .true to indicate it. This would inhibit a mistakenly usage
of gc(). If one
leaves the gc() invocation from the debug version, it would not run the
garbage collector by
default on a release version. If, however, a programmer needs a garbage
collection in the
release version, it must be "cumbersomely" invoked, such that this can
only happen
intentionally.
What do you think? Any comments?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
