Description
A big issue with garbage collection is that it takes so long and it's monolithic so when it runs, it must finish before releasing control back to the VM for the next bytecode.
It would be nice if the user had the option to execute gc in chunks so that instead of one big timing hit, you could spread out the overhead: each time gc.collect() ran, it would take execute a portion of the code(while taking more calls to actually finish the job).
The main motivation is to reduce jitter.
If garbage collection needs to take X ms it's better (for most cases?) that those X ms be spread out over a bunch of calls and interspersed with the executing bytecodes.
Of course, if you've run out of memory and need to finish the gc immediately, then of course you'll have to take the hit and finish the remaining gc operations but I think the average user will still see a benefit overall.
Implicitly this is about the timing but I'm not suggesting that we directly check some timer to determine when "enough work has been done for this iteration". Rather, a macro (in mpconfig.h) should be defined and set by user that roughly defines "how many calls to split up gc.collect() into".
However, we first need to figure out which gc.collect() operations need to be atomic with respect to the two operations the user can perform: allocation and freeing.