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 ...