I started to look into the GC crashes with the perlhash tests. I'm not sure I found the exact problem, but I found a bunch of dangerous things that were being done, and could possibly cause the GC problems.
restore_invariants is an ugly hack that is prone to error. You have to remember to restore_invariants after *any* header retrieval or memory allocation, or anything that could cause that. For example, take hash_delete. It restores invariants properly at the start of the procedure. But if you'll notice down below in the body, it uses string_compare. Due to transcoding issues, that can trigger a full GC, which means you need to restore_invariants inside that loop. And that invalidates your 'chain' which you've already placed on the local C stack, and restore_invariants can't fix that. Same thing with hash_put, which calls find_bucket, which also calls string_compare, with all the same problems. And same deal with hash_get, which calls hash_lookup, which calls find_bucket, etc. I think you should go for an index-based approach to the hashtable problem, to make this work nice and easily. If your concerned about code clarity, I'd be happy to try and go in and attempt to clean things up. Probably just needs a little macro usage to abstract out your hashtable futzoring. (Just one level of macros, no need to worry. ;) Thoughts? Mike Lambert
