HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/csv; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 01:30:49 GMT Content-length: 1368 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,lang,patch,platform 670,Rearranging the GC interface,whiteknight,,"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?",RFC,closed,normal,,GC,1.1.0,medium,invalid,gc,,,, " /> <