On 16.07.2022 17:31, Rick McGuire wrote:
On Sat, Jul 16, 2022 at 11:25 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
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?
I have actually worked on JVMs and the developers (particularly the ones who work on memory
management) really hated that a decision was made early on to include this method. It causes
nothing but problems, not the least because very few users really understand what garbage
collection does.
Yes, I can understand that.
Yet, it has been a deliberate decision by the Java language designers to allow programmers to kick
the garbage collector (despite the burden may incur on the JVM developers and the Java runtime system).
If it were the source of "nothing but problems" gc() would have been deprecated for a long time.
Either the assumption does not hold that only "very few users really understand what garbage
collection does", or if it holds its benefits outweigh whatever burden gc() invocations may incur.
Are ooRexx programmers by comparison regarded to be more stupid?
I suspect they are equally as stupid (or really, more ignorant) as the Java users that misuse
this. I remain a firm -1. And frankly, I consider you to be the person most likely to misuse this
because you really don't understand garbage collection either.
Just to make one thing clear: I do not need gc() in the interpreter for myself as I have it already
available! :)
However, following the philosophy of REXX/Rexx to make it easy for the programmers to use the
programming language (and not necessarily for the implementers of the language itself), seeing what
kind of problems may come up that only can be solved by becoming able to kick the garbage collector
explicitly at certain points in time, I came up with the suggestion to add it to ooRexx. Normal
ooRexx programmes would mostlikely not be able to implement gc() on their own if they happen to need it.
The worst case scenario would be that some ooRexx programmer, despite knowing that it slows down
ooRexx nevertheless employs gc() in a busy loop. There would be no crash, but the ooRexx application
would get notably slowed down for that programmer. Would you really think that any normal, sane
programmer would code in this manner? Why should one patronize ooRexx programmers then?
---
If it were true, that kicking the garbage collector would be dangerous (or was even an error to
offer it in Java in the first place) then System.gc() would have been "deprecated for removal"
starting with (modular) Java 9 or later. This has not happened, cf. the JavaDocs of the latest
released Java 18/OpenJDK 18
<https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/System.html#gc()> .
(To see by comparison how in the Java world an annotation for "deprecated for removal" looks like,
cf. the JavaDocs for System.runFinalizersOnExit()
<https://docs.oracle.com/javase/9/docs/api/java/lang/System.html#runFinalizersOnExit-boolean->. )
---
Any of the garbage collecting languages/systems usually has the ability to let the programmer
run/kick off garbage collection. The major reason being that no garbage collecting system can
foresee - or for that matter optimize - all use-cases there are. Sometimes, especially in 7/24
deployments it may become necessary - depending on the garbage collector algorithms/heuristics - to
do an out-of-bound garbage collection cycle.
This is the reason why all modern programming languages empower their programmers to run the garbage
collector if the programmers see a need for it!
Cf.
* Java, e.g.
<https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/System.html#gc()>,
* C#, VB.Net, ... (.Net/CLR ), e.g.
<https://docs.microsoft.com/en-us/dotnet/api/system.gc.collect?view=net-6.0#System_GC_Collect>,
* Python, e.g. <https://docs.python.org/3/library/gc.html>,
* ...
Therefore the suggestion to empower ooRexx programmers as well as ooRexx is a modern program
language. I still think that it can be very important for ooRexx programmers, very much like TRACE
is very important for REXX/Rexx/ooRexx programmers which usually will not be employed in production,
but can be extremely helpful and important while developing/debugging REXX/Rexx/ooRexx programs.
ooRexx programmers are at least as savvy as Java, C#, VB.Net, Python
programmers ...
---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
