Given there is a clean definition of the memory model for concurrent update of unboxed unions. There are a few usual solutions for the GC problem. Given that concurrent GCs have to eventually stop all threads to mark them, the issue boils down to stopping a thread at the right spot.
A cooperative thread stop is the easiest one and probably the most portable given how different ISAs are. It can be implemented with code patching, but on some targets like SPARC this is very hard due to delay slots. Another option is to record all tag setting code into a set of protected regions and not let the GC stop at them. Even a naive solution of restating the thread works well. We do that for managed allocators on mono and so far it has not shown to be a performance problem. Finally, the tag setting code can be restartable/reentrant and survive if the GC stops it in the middle. This is very tricky too, it's easy to have subtle races that takes weeks to identify and fix.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
