You must create a garbage collector & tell Giggle about it early in the program, & you can't change it after that. Why doesn't Giggle allow the garbage collector to change at run-time?
I'm not precluding the idea of multiple, simultaneous garbage collection objects at run-time, but it's not a current priority.
I guess the main reason is that it would introduce the ``Mixing-up Algorithms'' (14.2) problem, & since the only motivation I can see for having more than one garbage collector at run-time is as an optimisation, I don't think the cost of solving the design problems justifies the benefit.
The only reason I can imagine for having more than one garbage collector at run-time is as an optimisation. As your program runs, you'll might know sections of your program that will create a bunch of objects that could be considered local to that section. In other words, you know that, upon leaving that section of your program, all those objects could be destroyed. You know this is true, so you don't see a need to do a full, potentially expensive, garbage collection at run-time to determine it. So if all those objects had been created in a garbage collector that knew about just those objects, & if that garbage collector was deleted when you exited that section of your program, all the objects created in that section of your program would be deleted. Objects created elsewhere wouldn't factor into the special section's garbage collector's consideration14.1, & the objects created in that special section won't factor into consideration by other garbage collectors.
On the one hand, it could work, & such an optimisation would be nice, since garbage collection can slow things down.
On the other hand, the point of garbage collection is to reduce development costs, but using this kind of special section, local garbage collector could create some difficult bugs which could increase development costs. Also, as your special sections change, you'd have to update the code that creates & destroyes your local garbage collectors, again increasing development costs.
One such difficult bug would occur if you created an object from within the special section & under control of the local garbage collector, but that object was referenced by parts of the program that should be using another garbage collector. This might happen if your special section called functions that created objects & gave their addresses to objects that the local garbage collector didn't know about. So when the local garbage collector was deleted, it would delete its objects, but it really shouldn't delete all of them because they were still referenced by objects the local garbage collector didn't know about. You could solve the problem by adding ``conditional shutd-down object deletion'' or ``meta-collector collection'' logic to the garbage collector, but I mean, really now, this is a throw-back to the same problems of determining when we can delete an object that we had before we were using general purpose garbage collection, anyway.
In the biggest, most theoretical picture of it all, you don't have or need garbage collection at all. There is a space which contains objects. You create objects (always in that space). You use them until you are done, & then you stop using them. Over time, some objects in the space become unreachable because they are not reached by any object that is reachable by your program. Objects are never deleted.14.2
In a less big, less theoretical picture, reality dictates that the object space's size is limited. We need to recycle the object space as we can. The way to do that is to determine which objects are unreachable & destroy them. That's the function of a garbage collector. It monitors the objects in the space, determines which are unreachable, & destroyes them so the portion of the object space they occupied can be recycled.
In the not-nearly-big reality, garbage collection can have a cost.
Anyway, my point is that there's just one object space, so just one garbage collector is needed to monitor it. Having more garbage collectors artificially partitions the object space. It's an optimisation, but it can increase development costs, which if we were willing to do, we wouldn't need a garbage collector.
Instead of multiple garbage collectors, consider manual deletion as an optimisation (11.2).