There really shouldn't be an difference in the garbage collector on 64-bit
vs 32.bit. The code itself is really independent of the size of the
objects, but that's not a definitive statement that there might not be
something strange going on.
You might try rebuilding with _DEBUG and VERBOSE_GC defined. This will
dump a lot of GC statistics that might give a clue as to the problem area.
Rick
On Wed, Aug 8, 2012 at 3:32 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
> I was going to bring this up, but probabaly after I had done some more
> testing. However since /hex just brought up SysFileTree, I'll do it
> now.
>
> I had wanted to include the new SysFileTree code in 4.1.2 because it
> definitely fixes some reproducible bugs in Linux.
>
> In Windows, I gave a version to Jerry, the submitter of the Windows
> bug, a version of ooRexx that had SysFileTreeB() and SysFileTree().
> He tested it for a week and was able to reproduce the bug using
> SysFileTree 4 times in a week of testing, and never using
> SysFileTreeB(). Not conclusive, but an indication that the new code
> might fix the Windows bug. I myself tested a lot that the newer
> version produces the same results as the old version.
>
> However, on Friday I discovered what I thought might be a memory leak
> on Windows. So I won't put it in 4.1.2, but the new version does
> exist in trunk.
>
> What I did was put a simple routine that does a SysFileTree search for
> all files on my system in an endless loop. The returned stem from 1
> iteration holds about 300,000 file names in the long format.
>
> On a Windows 64-bit system, memory used by rexx.exe keeps increasing
> until at 98% of total memory had to kill it. I have 4 GB of memory
> and the Rexx process used up to about 3,500 MB of it before I killed
> it.
>
> Since in the new version, there is the possibility of a lot more
> dynamically allocated memory, I first thought I had a memory leak
>
> But, these facts make me wonder if it might be something else:
>
> Running the exact same source code and same test on a Windows 32-bit
> machine. Memory used by the Rexx process rose to about 2400 MB and
> then stayed there. The system also has 4 GB of memory. I ran the
> test program for 48 hours and then quit because the memory had stayed
> steady for about 46 hours. Whereas on the 64-bit system, memory maxed
> out after about, I don't know exactly, but about 4 to 7 hours.
>
> I have a trial version of Purify that only runs on 32-bit. I ran the
> test program under it. Running one iteration, Purify report a memory
> loss of 28 bytes. Running 200 iterations, Purify reported a memory
> loss of, 28 bytes. Since it is a trial version it doesn't report
> where the memory loss happened. So the 28 bytes might not have even
> been allocated in SysFileTree.
>
> Originally in the code I was going to raise a condition if a string
> was longer than the static buffers. I ran that code a lot on the same
> 64-bit system and a condition was never raised. In the newer version,
> I replaced all the possible raised condition code with code that
> dynamically allocates memory.
>
> Therefore, in the current code, it seems possible that no dynamic
> memory is allocated to begin with. Making a memory leak in the new
> code unlikely to be the culprit. That's my next step, is to put a
> print out every time memory is allocated, and see if it actually
> happens. I still have to do that.
>
> However it's odd that the same memory problem doesn't happen on a
> 32-bit system. I wonder if the problem is with the garbage collector
> on 64-bit?
>
> --
> Mark Miesfeld
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
