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. 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. Rick > ---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 >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
