GC invocation

[Leopold Toetsch]

The current Mark&Sweep collector runs strictly on demand, as well as the
copying collector for buffer memory. Both are triggered, when a lack of
resources is detected and are run immediately, from a probably deeply
nested C function.

This causes several problems:
1) we have to do stack walking
2) we have to scan CPU registers
3) it caues e.g. string memory to move under the code

1) is time consuming and can lead to false positives (conservative GC is
the keyword here - not a problem except a PMC is concerned that needs
timely destruction). Boehm has e.g. a "blacklist" of false positives.
2) is horribly machine dependent and not easy, look e.g. in Boehm's GC
sources: mach_dep.c - and it can produce false positives too.
3) needs that the programmer takes care not to cache any pointer into
string memory over code, that could cause GC (collect). It's a bit error
prone and causes slower code.

To work around that, I'd like to discuss a new scheme of GC invocation.

* on a lack of resources the allocation code allocates more
objects/memory and posts a GC_EVENT - or it posts the event before
resources are consumed entirely.
* This GC_EVENT gets handled at the run-loop level (as all events) So
there is no need to do stack walking or CPU register scanning.
* and as the run-loop is a safe point, where no code has pointers into
e.g. buffer memory, 3) is also no problem

Ponie, which isn't running the Parrot runloop yet, would need some extra
support, though.[1]

Comments welcome,
leo

[1] maybe instead of

Perl_runops_standard()

we could have:

Parrot_runcode(..) => loop: enternative # calls Perl_runops
if I0 goto loop

and the perl run loop drops back to Parrot e.g. at block exits ...