To my knowledge there is no leak in the memory management. What I have seen before is objects being kept alive by the speculative stack and register marking. If an object that is no longer in real use is speculatively kept alive, all the objects it references are kept alive, too. This can in some situations result in large numbers of objects that are kept alive for a random time. Large tree-like structures with parent pointers are especially susceptible to this kind of problem since it only needs one of many object to be spuriously kept alive to pin the entire structure. You can test if this is your problem by running the object tracker (it causes a periodic GC every few seconds and increases the chance of the spurious reference to disappear) if the memory consumtion goes down some time after the termination of your program, then it likely is this problem. If this is not the case, then there is probably an object (with lots of (in)direct references) that is still referenced by some global variable (eg. list) or a display space object that is still in the display space. The problem with speculative marking should be solved in the compiler and the runtime using meta-information instead of heuristics to know where the pointers are at GC time. I dont know if a fix to this issue is planned. It should probably be addressed if/when the system is ported to 64bit. --Thomas Soren Renner wrote:

If one is running a very recent crazy-fresh bluebottle, and one is leaking memory, so that every time one runs one's experimental realtime raytracer it leaves the heap with less free space, what should one do? Hypothetically? -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://www.mail.inf.ethz.ch/lists/listinfo/oberon