[Oberon] Garbage

[Thomas Frey]

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 at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://www.mail.inf.ethz.ch/lists/listinfo/oberon