[Oorexx-devel] No calls to uninit inside a loop, even if GC. By design ?
While testing the WeakReference class, I observed that the calls to uninit are not triggered inside a loop, except when a security manager is in place. Is it a design decision to call checkUninitQueue only from RexxActivation::run when execution_state == RETURNED ? See http://oorexx.svn.sourceforge.net/viewvc/oorexx/sandbox/jlf/samples/gc/ The _readme.txt describes 4 test cases. testcase1.output.default.txt (with a security manager) one GC during the loops, uninits called during the loop (sounds good) testcase1.output.10_000.txt (no security manager) no GC during the loops, so uninits called when halting (ok). testcase1.output.100_000.txt (no security manager) one GC during the loop in step2, but NO call to uninit. Why ? The uninit are called AFTER the loop. testcase1.output.1000_000.txt (no security manager) several GC during the loops, but NO call to uninit. pendingUninits=18 (6 GC * 3 zombies) : I suppose it's not a problem to have 18 instead of 3 ? If I understand correctly, the only important information is pendingUninits 0, to decide when calling runUninits. Jean-Louis -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] No calls to uninit inside a loop, even if GC. By design ?
uninits are only processed at important boundaries, such as return from method calls. So if you have a tight loop that isn't making any method calls, then it is possible that these would not be processed until the loop completes. The security manager changes this dynamic by introducing some method call boundaries. Rick On Sun, Nov 6, 2011 at 7:11 PM, Jean-Louis Faucher jfaucher...@gmail.com wrote: While testing the WeakReference class, I observed that the calls to uninit are not triggered inside a loop, except when a security manager is in place. Is it a design decision to call checkUninitQueue only from RexxActivation::run when execution_state == RETURNED ? See http://oorexx.svn.sourceforge.net/viewvc/oorexx/sandbox/jlf/samples/gc/ The _readme.txt describes 4 test cases. testcase1.output.default.txt (with a security manager) one GC during the loops, uninits called during the loop (sounds good) testcase1.output.10_000.txt (no security manager) no GC during the loops, so uninits called when halting (ok). testcase1.output.100_000.txt (no security manager) one GC during the loop in step2, but NO call to uninit. Why ? The uninit are called AFTER the loop. testcase1.output.1000_000.txt (no security manager) several GC during the loops, but NO call to uninit. pendingUninits=18 (6 GC * 3 zombies) : I suppose it's not a problem to have 18 instead of 3 ? If I understand correctly, the only important information is pendingUninits 0, to decide when calling runUninits. Jean-Louis -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] No calls to uninit inside a loop, even if GC. By design ?
Indeed, the code in the loop was too simple. I added a call to a 2nd routine from inside the loop and now the uninit are called. In fact, it seems that at least one user-defined procedure/routine/method must be called to trigger the calls to uninit. If I use only predefined functions/methods inside the loop then no uninit is called (quick tests...). Thanks! Jean-Louis 2011/11/7 Rick McGuire object.r...@gmail.com uninits are only processed at important boundaries, such as return from method calls. So if you have a tight loop that isn't making any method calls, then it is possible that these would not be processed until the loop completes. The security manager changes this dynamic by introducing some method call boundaries. Rick On Sun, Nov 6, 2011 at 7:11 PM, Jean-Louis Faucher jfaucher...@gmail.com wrote: While testing the WeakReference class, I observed that the calls to uninit are not triggered inside a loop, except when a security manager is in place. Is it a design decision to call checkUninitQueue only from RexxActivation::run when execution_state == RETURNED ? See http://oorexx.svn.sourceforge.net/viewvc/oorexx/sandbox/jlf/samples/gc/ The _readme.txt describes 4 test cases. testcase1.output.default.txt (with a security manager) one GC during the loops, uninits called during the loop (sounds good) testcase1.output.10_000.txt (no security manager) no GC during the loops, so uninits called when halting (ok). testcase1.output.100_000.txt (no security manager) one GC during the loop in step2, but NO call to uninit. Why ? The uninit are called AFTER the loop. testcase1.output.1000_000.txt (no security manager) several GC during the loops, but NO call to uninit. pendingUninits=18 (6 GC * 3 zombies) : I suppose it's not a problem to have 18 instead of 3 ? If I understand correctly, the only important information is pendingUninits 0, to decide when calling runUninits. Jean-Louis -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
