This is a spin-off of bug 352846 comment 15. Using conservative GC would stop most if not all GC-hazards in SpiderMonkey. We should consider if performance penalty of using one is small enough compared with benefits.

It seems for me that a conservative GC for SpderMonkey does not require much efforts to create. The major required piece of infrastructure is scanning of the native stack which requires the knowledge of stack boundaries. Typically for that one has to use a platform-specific code, but SpiderMonkey can get away from it and require the embedding to tell the stack boundaries in the same way as embedding must report stack limit. With stack boundaries known to implement scanning one also need to know if a particular gc-thing candidate really belongs to GC-arena. On 32-bit platform one can use a an array of bites for that. Given 8K arenas, that would require in the worst case 2^32 /2^13/8 = 64K bytes array. On 64-bit platform (which one widely used VM does not support), a hash table or a digital tree may be necessary. With these 2 pieces of infrastructure a conservative GC is trivial.