It has been discovered that AddressSanitizer does not keep a 1:1 mapping
of which bytes are poisoned and which are not. This can cause issues for
allocations less than 8 bytes and where addresses straddle 8-byte
boundaries.
See the following link for more information:
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#mapping
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction in different orders than sequential order. These alternative
orders can often offer better SIMD hardware utilization.
Two different orders are added: pair-wise (operating on pairs of
adjacent elements) or bisection-wise (operating element-wise on the
first and last N/2 elements of the vector).
allocators
This adds various bindings to the asan runtime which can be used
to poison/unpoison memory handed out by various allocators. This
means we can catch use after free memory bugs when using operations
such as free_all during runtime.
Asan poisoning are added for the follow allocators in mem:
Arena (including temporary arenas)
Scratch
Stack
Small_Stack
Additionally a bug in the stack allocator was fixed to disallow freeing
in the middle of the stack (caught by the asan!).
I plan on adding support for all the allocators in core. This is just
a good starting point and were some of the easiest ones to implement
asan for.
`typeid` used to be a fancy index with extra metadata stored on it. Now it is direct hash of the type.
This is safe to do in practice since any possible collisions are checked at compile time AND the chances of having a 1% collision are around 1 in 600K (see the Birthday Paradox).
Therefore accessing a `^Type_Info` is now a hash table lookup with linear probing. The table is twice the size than necessary so prevent too much probing due to an overly dense hash table.
This affects `runtime.Arena` and `virtual.Arena`, but not currently
`mem.Arena`. These changes allow the last allocation that has been
made to be resized to a larger size by just extending their
allocation in-place, when there's sufficient room in the memory block to
do so.
Shrinking in place and re-using the rest of the allocation can be
supported using almost the same logic, but would require the memory to
be zeroed. Since this would add a additional cost that isn't currently
present, shrinking has not been changed.
