Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rony G. Flatscher]

Dear P.O.,

On 20.07.2022 08:25, ooRexx wrote:
I assume this functionality can not be made a library (like orxutils et al) but need to be 
included in the build process, right? IF not included/accepted in the trunk I suggest you put all 
the necessary files in an entry under tools and document how to make it work. In this way anyone 
who wants to give it a try can do so without affecting the official builds.


Well, this would be some special location then, like "unaccepted, but useful" features and I would 
doubt that this was really helpful for anyone as a person needs to be aware of that. It is better 
not to make things more complicated.


As someone pointed out this seems to be a substantial effort and we should keep it in the SVN 
repository.


Well there was some effort to figure it out. The patch is actually rather short 
and simple.

Maybe I do the same as for the concurrent trace and file a RFE with the patch. This way the RFE is 
documented and whoever needs the patch can fetch and apply it from there.


There are situations (mostly debugging, but not only), where gc() is important, 
also for ooRexx.

---rony





On 16. Jul 2022, at 17:11, Rony G. Flatscher  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

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[ooRexx]

Dear Rony,

I assume this functionality can not be made a library (like orxutils et al) but 
need to be included in the build process, right? IF not included/accepted in 
the trunk I suggest you put all the necessary files in an entry under tools and 
document how to make it work. In this way anyone who wants to give it a try can 
do so without affecting the official builds.

As someone pointed out this seems to be a substantial effort and we should keep 
it in the SVN repository.

Hälsningar/Regards/Grüsse,
ooRexx
oor...@jonases.se



> On 16. Jul 2022, at 17:11, Rony G. Flatscher  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

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rony G. Flatscher]

On 17.07.2022 21:00, Michael Lueck wrote:

Greetings ooRexx'ers,

Rony G. Flatscher 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.



I note this as a considerable effort put forth by Rony.


Rick McGuire wrote:
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.




I hear your concern, Rick.


Rony, would it be possible to put a custom call to System.gc() in a "for debug version" of ooRexx, 
obtain your sought after debug information of what is going on with calls to System.gc() in use, 
thus with clearer vision of what valid objects are in memory, be able to more precisely pinpoint 
the behavior bug you seek after? As, if the bug in ooRexx code actually exists, I would not think 
a call to System.gc() would so tamper with the memory that it would distort the root of the 
problem, or also hopefully not make the problem be masked / disappear altogether.


Just thoughts...


Yes, that would be possible.

---rony






___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Michael Lueck]

Greetings ooRexx'ers,

Rony G. Flatscher 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.



I note this as a considerable effort put forth by Rony.


Rick McGuire wrote:
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.




I hear your concern, Rick.


Rony, would it be possible to put a custom call to System.gc() in a "for debug version" of ooRexx, obtain your sought after debug information of what is going on with calls to System.gc() in use, thus 
with clearer vision of what valid objects are in memory, be able to more precisely pinpoint the behavior bug you seek after? As, if the bug in ooRexx code actually exists, I would not think a call to 
System.gc() would so tamper with the memory that it would distort the root of the problem, or also hopefully not make the problem be masked / disappear altogether.


Just thoughts...

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rony G. Flatscher]

On 16.07.2022 17:31, Rick McGuire wrote:


On Sat, Jul 16, 2022 at 11:25 AM Rony G. Flatscher  
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 
 .


(To see by comparison how in the Java world an annotation for "deprecated for removal" looks like, 
cf. the JavaDocs for System.runFinalizersOnExit() 
. )


---

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.
   
,

 * C#, VB.Net, ... (.Net/CLR ), e.g.
   
,

 * Python, e.g. ,

 * ...

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 
 wrote:

While debugging (for almost two months) ooRexx and 

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rick McGuire]

On Sat, Jul 16, 2022 at 11:25 AM Rony G. Flatscher 
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
>>
>
> 

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rony G. Flatscher]

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  
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

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rick McGuire]

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.

Rick

On Sat, Jul 16, 2022 at 11:12 AM Rony G. Flatscher 
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

[Oorexx-devel] Ad debugging garbage collection dependent resources

[Rony G. Flatscher]

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