Aleks, I have been doing quite a bit of work on the memory management. In most cases it should be a lot better but there's scope for some tuning. I'm planning to come back to that in due course. If you want a stable platform you should really stick with the last release rather than SVN.
With a garbage-collector there is always a trade-off between memory and GC time. The larger the heap compared to the actual amount of heap space used by the application the less frequently the system needs to garbage-collect and so the faster the application. This is true at least up to the point where the heap exceeds the available real memory and starts to swap heavily. These days most people have several gigabytes on their machines.
You can control the heap size by using the -H argument which takes a heap size in mega-bytes. This is the initial size; the heap may grow larger if needed, but using a smaller value may work better if you're short of real memory.
Incidentally, unless you are using Poly/ML on a very obscure architecture there is no "interpreter". It's all compiled to machine code.
Regards, David
On 07/06/2011 16:12, Aleks Kissinger wrote:
I've just updated to the latest SVN of poly, and my compile times have ballooned up. Prodding it a bit, it looks to me like there's a memory leak in the interpreter.
Here's what I do to get it to happen:
- Fire up poly and load a modest heap (59 megs) containing about 100
structures and functors. top shows poly's RAM usage goes to a little over 59 megs. 2. Run some pretty functor-heavy code, including some code that looks (essentially) like this:
structure Structure1 = Functor1(....); structure Structure2 = Functor2(structure Foo = Structure1); structure Structure3 = struct open Structure1; Structure2; end structure Structure4 = Structure3 : SIG
Admittedly, these are some pretty big structs, and poly's RAM usage hits over a gig, and doesn't go back down once execution is finished. "PolyML.fullGC ();" seems to have no effect.
- Save the heap, still< 70 megs.
- Close and open poly w new heap, RAM usage still< 70 megs
So, the compile-time slowness seems to be poly filling the system's RAM and starts swapping pages. I included the code above on the off chance there's some cyclic dependency between the structs that keeps some junk from being garbage collected.
I can give SVN links if you want to see the offending code itself, but its part of a pretty large project, so I don't know how helpful that would be.
Thanks! Aleks _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml