GC fiber unfinished executions

[arnaud-lb]

Fixes #9735

[dstogov]

I don't object.

Unfortunately, this GC part becomes too complex and actually makes the idea of backup cycle collection completely inefficient. Classic mark-and-sweep GC might win now.

[trowski]

Based on my limited knowledge of the GC this looks good. Thanks for tackling this issue!

[arnaud-lb]

Unfortunately, this GC part becomes too complex and actually makes the idea of backup cycle collection completely inefficient.

Because it increases the size of the graph, right? or because of the get_gc handler overhead?

Classic mark-and-sweep GC might win now.

Classic mark-and-sweep would make destructor execution non deterministic though

[dstogov]

Unfortunately, this GC part becomes too complex and actually makes the idea of backup cycle collection completely inefficient.

Because it increases the size of the graph, right? or because of the get_gc handler overhead?

Because get_gc handler starts to copy stack slots to GC buffer. That is very similar to "mark roots" phase of mark-and-sweep.

Classic mark-and-sweep GC might win now.

Classic mark-and-sweep would make destructor execution non deterministic though

I know. Destructors and GC are conceptually incompatible.