#670: Rearranging the GC interface
-------------------------+--------------------------------------------------
Reporter: whiteknight | Owner:
Type: RFC | Status: new
Priority: normal | Milestone: 1.5
Component: none | Version: 1.1.0
Severity: medium | Keywords: gc
Lang: | Patch:
Platform: |
-------------------------+--------------------------------------------------
I'd like to propose a change to the GC API, and want some input before I
start putting in deprecation notices.
The current function to start the GC process is
"Parrot_gc_mark_and_sweep", formerly Parrot_do_gc_run I think. I would
like to maybe deprecate this function and replace it with 3 new ones
instead:
1) Parrot_gc_mark
2) Parrot_gc_sweep
3) Parrot_gc_increment
The Parrot_gc_mark and Parrot_gc_sweep functions together would do what
Parrot_gc_mark_and_sweep do today, but would allow for GCs that break
these two phases up in a non-stop-the-world kind of way. These two would
map to two separate function pointers in the Arenas struct, so the GC
cores can implement these functions separately (even if they always run
together).
The third function Parrot_gc_increment would be called regularly, such as
when the scheduler checks it's task. For non-incremental GCs this would be
a noop, but for incremental ones it would run a portion of the GC
sequence. This way we can get the work done without waiting for the header
allocation functions to initiate the sweep when we run out of memory.
Comments?
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/670>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
