On 16.07.2022 17:18, Rick McGuire wrote:
I am a serious -1 to this proposal. This is something with serious performance implications and
will only be misused by people who don't understand how garbage collection works. There, you no
longer need to worry about silent assent.
Indeed.
So, Rick, why do the Java programmers have the ability then? The implications on Java are exactly
the same: improper use of System.gc() would impede Java programs (and Java frameworks) accordingly?
Are ooRexx programmers by comparison regarded to be more stupid?
---rony
On Sat, Jul 16, 2022 at 11:12 AM 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
