I added explicit support for ASAN poisoning, but it was not partic…ularly valuable in any way, so I:
Added a tremendous amount of heap checking.
I used this to find and fix:
Hash value caching moved from the con4m object header into the alloc header. This way, any GC'd pointer will have its hash value cached. Not doing it that way was an oversight. And, as a result, occasionally something would be in a dict or set, but the hash value was based on its OLD pointer value, so a collection would give the same value a new hash. Not many things like this are used as keys right now, but one was the module worklist at the top level, so if a collect happened at the wrong time, you could end up in an infinite loop, because some module was never going to get removed from the set (but could always be retrieved from it). To test this out, I lowered the starting heap size all the way down to 1K to try to trigger the problem as much as possible (tho the heap doubles in size if, after the previous collect, there's deemed not sufficient space). Amazingly it didn't slow things down.
Heap checking (enabled in debug builds) includes:
Full sweep of the heap after collection looking for garbage that might not be garbage.
Guards AFTER each allocation (already existed before).
Checking of guards during collections.
A ring buffer of recent allocs; guards are checked after each allocation for anything in the ring buffer.
Also along the way:
Don't exit the longjmp context before throwing an error....
Get parsing working on switch statements again; next get need to fix the code gen (codegen still not done; coming next).
Use __builtin_frame_address(0) instead of a local variable.
Hash value caching moved from the con4m object header into the alloc header. This way, any GC'd pointer will have its hash value cached. Not doing it that way was an oversight. And, as a result, occasionally something would be in a dict or set, but the hash value was based on its OLD pointer value, so a collection would give the same value a new hash. Not many things like this are used as keys right now, but one was the module worklist at the top level, so if a collect happened at the wrong time, you could end up in an infinite loop, because some module was never going to get removed from the set (but could always be retrieved from it). To test this out, I lowered the starting heap size all the way down to 1K to try to trigger the problem as much as possible (tho the heap doubles in size if, after the previous collect, there's deemed not sufficient space). Amazingly it didn't slow things down.
Heap checking (enabled in debug builds) includes:
Also along the way:
Closes #71