GC for pure functions -- implementation ideas

[Timon Gehr]

Don wrote:

>>> The problem is, that inside a non-leaky pure function the general case
>>> for dynamic
>>> allocations might be just as complicated as in other parts of the program.
>
> Yes, but that only matters if that function is both extremely
> memory-inefficient AND long-lived. In which case you can fall back to
> the normal GC (or even a dedicated pure GC). I don't think you ever lose
> anything.

I think this idea has potential, I was only pointing out that maybe the compiler
should identify such garbage creating functions and use the normal GC for them by
default. It is not really a valid option to only restrict the size of the pure
heap (or even just the amount it can grow per call frame) and then fall back to
the normal GC, because a non-leaky pure function that behaves nicely may also need
a lot of memory.

Fawzi Mohamed wrote:
> Having several pools is also what is needed to remove the global lock in
> malloc, so that is definitely the way to go imho.

I agree. I don't like the fact that at the GC suspends all running threads while
collecting. But Hardware will probably be evolving towards Core-local RAM (several
_physical_ pools) anyways.