On 24.04.2022 19:57, Rick McGuire wrote:
A garbage collection is triggered any time an allocation request fails. At that time, all of the
unreferenced objects are swept up and repooled and the allocation request is retried. The uninits
on objects that have been identified as unreferenced will get run at the next "safe" boundary,
which is usually method termination.
Thank you.
Is there any gross estimate of the number of Rexx objects that need to be created until an
allocation request fails such that the garbage collector gets triggered?
Analyzing a few use cases (including Java web servers with ooRexx JSPs) where ooRexx gets used to
create the text to be sent back to Java which involves translating Rexx strings to Java strings if
using a Writer, otherwise to a Java byte array byte[] if using a Stream and passing that on.
In the case of a Java byte array a BSF ooRexx object gets created which proxies the Java byte array.
This ooRexx Java proxy will release the proxied Java byte array upon it being garbage collected by
ooRexx thru its uninit method. This makes that Java byte array eligible for garbage collection by
Java which usually does so within a fraction of a second.
---
To illustrate the Java garbage collector behaviour here the output of a Java test run (without Rexx
references), which allows for analyzing the effects of gc(), runFinalization() (gets removed from
newer Java version) and then sleeping for half a second after which all unreferenced Java objects
got removed (the code uses java.lang.ref.PhantomReference as the finalize() method got deprecated
and is slated to be removed from Java):
F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\source_java>java
org.rexxla.bsf.engines.rexx.RexxCleanupRef
RexxCleanupRef.main(): creating [123456] TestObjects and storing them in an
ArrayList ...
RexxCleanupRef [2022-04-24 20:32:34.318000000] [main(): before nullifying]
RefKind: Instances: Finalized: Not Yet Finalized:
-----------------------------------------------------------------------
[TEST].......: [ 123.456] [ 0] [ 123.456]
[REXX_ENGINE]: [ 0] [ 0] [ 0]
[REXX_PROXY].: [ 0] [ 0] [ 0]
-----------------------------------------------------------------------
Totals.......: [ 123.456] [ 0] [ 123.456]
... nullifying the ArrayList ...
RexxCleanupRef [2022-04-24 20:32:34.392000000] [after gc()]
RefKind: Instances: Finalized: Not Yet Finalized:
-----------------------------------------------------------------------
[TEST].......: [ 123.456] [ 145] [ 123.311]
[REXX_ENGINE]: [ 0] [ 0] [ 0]
[REXX_PROXY].: [ 0] [ 0] [ 0]
-----------------------------------------------------------------------
Totals.......: [ 123.456] [ 145] [ 123.311]
RexxCleanupRef [2022-04-24 20:32:34.412000000] [after runFinalization()]
RefKind: Instances: Finalized: Not Yet Finalized:
-----------------------------------------------------------------------
[TEST].......: [ 123.456] [ 16.544] [ 106.912]
[REXX_ENGINE]: [ 0] [ 0] [ 0]
[REXX_PROXY].: [ 0] [ 0] [ 0]
-----------------------------------------------------------------------
Totals.......: [ 123.456] [ 16.544] [ 106.912]
RexxCleanupRef [2022-04-24 20:32:34.465000000] [after gc()]
RefKind: Instances: Finalized: Not Yet Finalized:
-----------------------------------------------------------------------
[TEST].......: [ 123.456] [ 30.601] [ 92.855]
[REXX_ENGINE]: [ 0] [ 0] [ 0]
[REXX_PROXY].: [ 0] [ 0] [ 0]
-----------------------------------------------------------------------
Totals.......: [ 123.456] [ 30.601] [ 92.855]
main(): sleeping 500 ms
RexxCleanupRef [2022-04-24 20:32:34.982000000] [after sleeping 500 ms]
RefKind: Instances: Finalized: Not Yet Finalized:
-----------------------------------------------------------------------
[TEST].......: [ 123.456] [ 123.456] [ 0]
[REXX_ENGINE]: [ 0] [ 0] [ 0]
[REXX_PROXY].: [ 0] [ 0] [ 0]
-----------------------------------------------------------------------
Totals.......: [ 123.456] [ 123.456] [ 0]
[This class is responsible for releasing references to Rexx objects if the Java RexxProxy gets
garbage collected, as well as terminating a Rexx interpreter instance if its Java proxy gets garbage
collected.]
---
Currently it looks as if the BSF ooRexx objects that represent relatively large Java byte arrays do
not get garbage collected for quite a while on the Rexx side possibly causing problems on JVMs if
the Java byte arrays are large and do not get released by the BSF uninit method in a timely manner.
It would be certainly a *big* help, if it was possible - like in Java - to explicitly trigger a
garbage collection on the Rexx side. It would allow for releasing the held Java resources, in case
it becomes necessary. One possibility this would open is triggering it e.g. once every half second,
depending on the application's need.
Alternatively, if ooRexx would do additional garbage collection runs in short time intervals (like
every half a second, configurable) such problems could probably be effectively addressed.
---rony
On Sun, Apr 24, 2022 at 1:51 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
Trying to analyze runtime behaviours using a rexxtry.rex session in which
BSF objects get
created,
some of which do not get assigned to Rexx variables (and hence turning to
garbage after the
respective statement got executed).
Creating over and over BSF-ooRexx objects that do not get referenced and as
such are immediately
eligible to be destroyed by the garbage collector this seems to not be
taken place while the
rexxtry.rex program in which they got created executes. Ending the
rexxtry.rex session after a
while
will cause the garbage collector to run (having debug statements in the
uninit method) at that
point
in time.
So when does the garbage collector get triggered? Or asked differently:
what is needed to get the
garbage collector to run the uninit methods of orphaned Rexx objects?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
