add SafeAllocator #31991

gooncreeper commented 2026年04月21日 00:50:58 +02:00

Closes #31186

Implements a thread-safe allocator with the following guarantees:

• deinit reports all leaks and frees all backing memory.
• All allocation mismatches result in either a panic or segmentation fault.
• Allocations from other SafeAllocator instances cause a panic (if Options.canary differ).
• Double frees and operation (resize, remap, and free) races panic or segmentation fault.

Given the backing allocator does not reuse memory, it does not reuse memory either and

• Most writes after free will segmentation fault or are eventually detected and panic.

std.heap.DebugAllocator has been deprecated (I have also deprecated std.heap.Check since this was its last usage and returning a usize leak count is a much cleaner approach).

General Design

Every allocation is trailed by an AllocFooter which contains metadata for the allocation and stack traces. It is protected by a checksum to catch corruption from allocation overwrites and report canary mismatches. An allocation's memory has a minimum alignment of AllocFooter so that the footer is at a fixed offset determined from the allocation size. An allocation's memory is stored either:

• Inside linearly-filled buckets for small allocations.
• Inside an allocation directly from the backing allocator.

To track allocations, each thread maintains a table of backing allocations. The table may be modified by other threads in the case of a producer-consumer operation, so the table is a linked list only expanded by creating new segments. Each thread maintains a linked list of free entries, which may contain entries from other threads' tables.

In the case of producer-consumer operations, acquire/release ordering is assumed to be provided externally. This is also assumed by all other thread-safe allocators that reuse memory as otherwise there would be data races on reuse of allocated memory.

Fuzz Tests

Two fuzz tests have also been added for the allocator. They check that there is no memory reuse, that returned memory is writable, and that it is not overwritten. The multi-threaded fuzz test spawns a number of worker threads which are used for all the test runs. I have run these tests extensively under TSAN.

Performance Measurements

Building the standard library tests with a RelaseSafe compiler build and -Ddebug-allocator:

Benchmark 1 (3 runs): ./master-out/bin/zig test --zig-lib-dir lib lib/std/std.zig -femit-bin=test --test-no-exec
 measurement mean ± σ min ... max outliers delta
 wall_time 29.4s ± 157ms 29.2s ... 29.5s 0 ( 0%) 0%
 peak_rss 2.24GB ± 3.49MB 2.23GB ... 2.24GB 0 ( 0%) 0%
 cpu_cycles 143G ± 999M 142G ... 144G 0 ( 0%) 0%
 instructions 268G ± 5.22M 268G ... 268G 0 ( 0%) 0%
 cache_references 13.1G ± 88.8M 13.0G ... 13.2G 0 ( 0%) 0%
 cache_misses 2.38G ± 30.7M 2.35G ... 2.41G 0 ( 0%) 0%
 branch_misses 634M ± 6.22M 629M ... 641M 0 ( 0%) 0%
Benchmark 2 (3 runs): ./branch-out/bin/zig test --zig-lib-dir lib lib/std/std.zig -femit-bin=test --test-no-exec
 measurement mean ± σ min ... max outliers delta
 wall_time 22.1s ± 88.6ms 22.0s ... 22.2s 0 ( 0%) ⚡- 24.7% ± 1.0%
 peak_rss 1.11GB ± 799KB 1.11GB ... 1.11GB 0 ( 0%) ⚡- 50.3% ± 0.3%
 cpu_cycles 136G ± 480M 136G ... 137G 0 ( 0%) ⚡- 4.4% ± 1.2%
 instructions 273G ± 2.07M 273G ... 273G 0 ( 0%) 💩+ 1.6% ± 0.0%
 cache_references 12.3G ± 71.3M 12.2G ... 12.4G 0 ( 0%) ⚡- 6.0% ± 1.4%
 cache_misses 2.02G ± 11.5M 2.01G ... 2.03G 0 ( 0%) ⚡- 14.9% ± 2.2%
 branch_misses 569M ± 2.65M 567M ... 572M 0 ( 0%) ⚡- 10.2% ± 1.7%

Closes #31186 Implements a thread-safe allocator with the following guarantees: * `deinit` reports all leaks and frees all backing memory. * All allocation mismatches result in either a panic or segmentation fault. * Allocations from other `SafeAllocator` instances cause a panic (if `Options.canary` differ). * Double frees and operation (resize, remap, and free) races panic or segmentation fault. Given the backing allocator does not reuse memory, it does not reuse memory either and * Most writes after free will segmentation fault or are eventually detected and panic. `std.heap.DebugAllocator` has been deprecated (I have also deprecated `std.heap.Check` since this was its last usage and returning a `usize` leak count is a much cleaner approach). ## General Design Every allocation is trailed by an `AllocFooter` which contains metadata for the allocation and stack traces. It is protected by a checksum to catch corruption from allocation overwrites and report canary mismatches. An allocation's memory has a minimum alignment of `AllocFooter` so that the footer is at a fixed offset determined from the allocation size. An allocation's memory is stored either: * Inside linearly-filled buckets for small allocations. * Inside an allocation directly from the backing allocator. To track allocations, each thread maintains a table of backing allocations. The table may be modified by other threads in the case of a producer-consumer operation, so the table is a linked list only expanded by creating new segments. Each thread maintains a linked list of free entries, which may contain entries from other threads' tables. In the case of producer-consumer operations, acquire/release ordering is assumed to be provided externally. This is also assumed by all other thread-safe allocators that reuse memory as otherwise there would be data races on reuse of allocated memory. ## Fuzz Tests Two fuzz tests have also been added for the allocator. They check that there is no memory reuse, that returned memory is writable, and that it is not overwritten. The multi-threaded fuzz test spawns a number of worker threads which are used for all the test runs. I have run these tests extensively under TSAN. ## Performance Measurements Building the standard library tests with a RelaseSafe compiler build and `-Ddebug-allocator`: ``` Benchmark 1 (3 runs): ./master-out/bin/zig test --zig-lib-dir lib lib/std/std.zig -femit-bin=test --test-no-exec measurement mean ± σ min ... max outliers delta wall_time 29.4s ± 157ms 29.2s ... 29.5s 0 ( 0%) 0% peak_rss 2.24GB ± 3.49MB 2.23GB ... 2.24GB 0 ( 0%) 0% cpu_cycles 143G ± 999M 142G ... 144G 0 ( 0%) 0% instructions 268G ± 5.22M 268G ... 268G 0 ( 0%) 0% cache_references 13.1G ± 88.8M 13.0G ... 13.2G 0 ( 0%) 0% cache_misses 2.38G ± 30.7M 2.35G ... 2.41G 0 ( 0%) 0% branch_misses 634M ± 6.22M 629M ... 641M 0 ( 0%) 0% Benchmark 2 (3 runs): ./branch-out/bin/zig test --zig-lib-dir lib lib/std/std.zig -femit-bin=test --test-no-exec measurement mean ± σ min ... max outliers delta wall_time 22.1s ± 88.6ms 22.0s ... 22.2s 0 ( 0%) ⚡- 24.7% ± 1.0% peak_rss 1.11GB ± 799KB 1.11GB ... 1.11GB 0 ( 0%) ⚡- 50.3% ± 0.3% cpu_cycles 136G ± 480M 136G ... 137G 0 ( 0%) ⚡- 4.4% ± 1.2% instructions 273G ± 2.07M 273G ... 273G 0 ( 0%) 💩+ 1.6% ± 0.0% cache_references 12.3G ± 71.3M 12.2G ... 12.4G 0 ( 0%) ⚡- 6.0% ± 1.4% cache_misses 2.02G ± 11.5M 2.01G ... 2.03G 0 ( 0%) ⚡- 14.9% ± 2.2% branch_misses 569M ± 2.65M 567M ... 572M 0 ( 0%) ⚡- 10.2% ± 1.7% ```

andrewrk commented 2026年04月21日 01:02:28 +02:00

A nice followup here would be modifying lib/c/malloc.zig to choose this allocator in Debug and ReleaseSafe modes as the backing allocator for malloc, free, etc.

A nice followup here would be modifying `lib/c/malloc.zig` to choose this allocator in Debug and ReleaseSafe modes as the backing allocator for `malloc`, `free`, etc.

gooncreeper commented 2026年04月23日 02:40:57 +02:00

Made a small change to the design: the bucket and allocation list sizes are now runtime configurable and use std.heap.pageSize for their defaults. The main motivation was to decrease the memory usage and amount of work for the fuzz tests by using a small value, though this should also be useful elsewhere. The performance hit was only about 1% overall.

Also updated libzigc to now use SafeAllocator when applicable.

Made a small change to the design: the bucket and allocation list sizes are now runtime configurable and use `std.heap.pageSize` for their defaults. The main motivation was to decrease the memory usage and amount of work for the fuzz tests by using a small value, though this should also be useful elsewhere. The performance hit was only about 1% overall. Also updated libzigc to now use `SafeAllocator` when applicable.

alexrp commented 2026年04月24日 08:27:32 +02:00

I canceled the current CI run on this because the OOMs are causing other jobs on the same machines to fail.

I'm not sure if it's a bug in this PR or you just need to bump some max_rss values.

I canceled the current CI run on this because the OOMs are causing other jobs on the same machines to fail. I'm not sure if it's a bug in this PR or you just need to bump some `max_rss` values.

gooncreeper commented 2026年04月26日 19:04:27 +02:00

Just pushed an update that decreases memory usage by ~15%. For libzigc I disabled storing stack traces since they are usually unreachable, so memory usage should be even less. The increased memory usage was certainly from the libzigc upgrade since the compiler uses it when linking libc, so hopefully this reduces memory usage enough. Feel free to cancel the CI if it OOMs again.

Just pushed an update that decreases memory usage by ~15%. For libzigc I disabled storing stack traces since they are usually unreachable, so memory usage should be even less. The increased memory usage was certainly from the libzigc upgrade since the compiler uses it when linking libc, so hopefully this reduces memory usage enough. Feel free to cancel the CI if it OOMs again.

gooncreeper commented 2026年04月26日 20:50:37 +02:00

The memory usage was much better, but still higher then the current max rss values. I am going to omit the libzigc upgrade for now and leave it as a followup to reduce the scope of this PR.

The memory usage was much better, but still higher then the current max rss values. I am going to omit the libzigc upgrade for now and leave it as a followup to reduce the scope of this PR.

andrewrk commented 2026年04月26日 22:11:50 +02:00

Good plan.

Good plan.

andrewrk commented 2026年05月02日 20:23:09 +02:00

It's not obvious the connection between the CI failure and this patchset, but I do think it is being caused by it or at least a latent bug being exposed:

mq test-modules
 mq test-std
 mq run test std-wasm32-wasi-none-lime1-Debug-selfhosted-no-lld 3003 pass, 120 skip, 1 fail (3124 total)
error: 'fmt.float.test.format f80' failed:
 expected 604462909807314587353088, found 226854911280625440821279802516316356608
failed command: wasmtime --dir=. -Sinherit-env /home/ci/.cache/act/9bcf39a5166eb613/hostexecutor/zig-local-cache/o/8d2d81fd7af81bb3bb380ba47b5ae273/test.wasm --cache-dir=/home/ci/.cache/act/9bcf39a5166eb613/hostexecutor/zig-local-cache --seed=0x77916c54 --listen=-

note that:

>>> hex(604462909807314587353088)
'0x80000000000000000000'
>>> hex(226854911280625440821279802516316356608)
'0xaaaaaaaaaaaa80000000000000000000'

It's not obvious the connection between the CI failure and this patchset, but I do think it is being caused by it or at least a latent bug being exposed: ``` mq test-modules mq test-std mq run test std-wasm32-wasi-none-lime1-Debug-selfhosted-no-lld 3003 pass, 120 skip, 1 fail (3124 total) error: 'fmt.float.test.format f80' failed: expected 604462909807314587353088, found 226854911280625440821279802516316356608 failed command: wasmtime --dir=. -Sinherit-env /home/ci/.cache/act/9bcf39a5166eb613/hostexecutor/zig-local-cache/o/8d2d81fd7af81bb3bb380ba47b5ae273/test.wasm --cache-dir=/home/ci/.cache/act/9bcf39a5166eb613/hostexecutor/zig-local-cache --seed=0x77916c54 --listen=- ``` note that: ``` >>> hex(604462909807314587353088) '0x80000000000000000000' >>> hex(226854911280625440821279802516316356608) '0xaaaaaaaaaaaa80000000000000000000' ```

pavelverigo commented 2026年05月03日 22:56:38 +02:00

You can skip failing test using if (builtin.zig_backend == .stage2_wasm) return error.SkipZigTest; or wait until #35192 merged and do rebase.

You can skip failing test using `if (builtin.zig_backend == .stage2_wasm) return error.SkipZigTest;` or wait until #35192 merged and do rebase.

gooncreeper commented 2026年05月04日 00:38:27 +02:00

Thanks, that is my plan. However, more troublesome is the powerpc failure / regression. I seem to be able to reproduce it; I just need to find some more time to debug it and come up with a solution or workaround. Its not really possible to just skip certain tests for that since it affects everything.

Thanks, that is my plan. However, more troublesome is the powerpc failure / regression. I seem to be able to reproduce it; I just need to find some more time to debug it and come up with a solution or workaround. Its not really possible to just skip certain tests for that since it affects everything.

andrewrk commented 2026年05月04日 01:28:25 +02:00

@alexrp can you help out with this powerpc64 failure? It looks like a bug in LLVM powerpc backend.

Personally, I would rather remove powerpc from our CI than block this PR on an LLVM bug.

@alexrp can you help out with this powerpc64 failure? It looks like a bug in LLVM powerpc backend. Personally, I would rather remove powerpc from our CI than block this PR on an LLVM bug.

alexrp commented 2026年05月04日 02:11:34 +02:00

Seems like you're really not getting along with LLVM's PowerPC backend today.

Reduction: https://github.com/llvm/llvm-project/issues/195561

Workaround:

diff --git a/test/tests.zig b/test/tests.zig
index 28cb147cf8..bdf3e596d8 100644
--- a/test/tests.zig
+++ b/test/tests.zig
@@ -2614,6 +2614,10 @@ fn addOneModuleTest(
 if (mem.eql(u8, options.name, "compiler-rt") or mem.eql(u8, options.name, "libc")) {
 these_tests.root_module.stack_protector = false;
 }
+ // https://github.com/llvm/llvm-project/issues/195561
+ if (target.cpu.arch.isPowerPC()) {
+ these_tests.root_module.stack_protector = false;
+ }
 if (options.build_options) |build_options| {
 these_tests.root_module.addOptions("build_options", build_options);
 }

However, after that we run into this: https://github.com/llvm/llvm-project/issues/195562

Workaround:

diff --git a/test/behavior/vector.zig b/test/behavior/vector.zig
index 777730345e..987941798c 100644
--- a/test/behavior/vector.zig
+++ b/test/behavior/vector.zig
@@ -748,6 +748,7 @@ test "vector reduce operation" {
 if (builtin.zig_backend == .stage2_spirv) return error.SkipZigTest;
 if (builtin.zig_backend == .stage2_c and builtin.cpu.arch.isArm()) return error.SkipZigTest;
 if (builtin.zig_backend == .stage2_riscv64) return error.SkipZigTest;
+ if (builtin.zig_backend == .stage2_llvm and builtin.cpu.arch.isPowerPC()) return error.SkipZigTest; // https://github.com/llvm/llvm-project/issues/195562
 if (builtin.zig_backend == .stage2_llvm and builtin.cpu.arch.isSPARC()) return error.SkipZigTest; // https://github.com/ziglang/zig/issues/23719
 
 const S = struct {

Seems like you're really not getting along with LLVM's PowerPC backend today. Reduction: https://github.com/llvm/llvm-project/issues/195561 Workaround: ```diff diff --git a/test/tests.zig b/test/tests.zig index 28cb147cf8..bdf3e596d8 100644 --- a/test/tests.zig +++ b/test/tests.zig @@ -2614,6 +2614,10 @@ fn addOneModuleTest( if (mem.eql(u8, options.name, "compiler-rt") or mem.eql(u8, options.name, "libc")) { these_tests.root_module.stack_protector = false; } + // https://github.com/llvm/llvm-project/issues/195561 + if (target.cpu.arch.isPowerPC()) { + these_tests.root_module.stack_protector = false; + } if (options.build_options) |build_options| { these_tests.root_module.addOptions("build_options", build_options); } ``` However, after that we run into this: https://github.com/llvm/llvm-project/issues/195562 Workaround: ```diff diff --git a/test/behavior/vector.zig b/test/behavior/vector.zig index 777730345e..987941798c 100644 --- a/test/behavior/vector.zig +++ b/test/behavior/vector.zig @@ -748,6 +748,7 @@ test "vector reduce operation" { if (builtin.zig_backend == .stage2_spirv) return error.SkipZigTest; if (builtin.zig_backend == .stage2_c and builtin.cpu.arch.isArm()) return error.SkipZigTest; if (builtin.zig_backend == .stage2_riscv64) return error.SkipZigTest; + if (builtin.zig_backend == .stage2_llvm and builtin.cpu.arch.isPowerPC()) return error.SkipZigTest; // https://github.com/llvm/llvm-project/issues/195562 if (builtin.zig_backend == .stage2_llvm and builtin.cpu.arch.isSPARC()) return error.SkipZigTest; // https://github.com/ziglang/zig/issues/23719 const S = struct { ```

gooncreeper commented 2026年05月04日 04:00:19 +02:00

Thanks so much for the help; you reduced those magnitudes faster than I would have.

Thanks so much for the help; you reduced those magnitudes faster than I would have.

alexrp commented 2026年05月05日 03:47:46 +02:00

For the latest failure:

diff --git a/test/tests.zig b/test/tests.zig
index 28cb147cf8..983f434d37 100644
--- a/test/tests.zig
+++ b/test/tests.zig
@@ -2855,6 +2855,11 @@ pub fn addCAbiTests(b: *std.Build, options: CAbiTestOptions) *Step {
 .max_rss = options.max_rss,
 });
 
+ // https://github.com/llvm/llvm-project/issues/195561
+ if (target.cpu.arch.isPowerPC()) {
+ test_step.root_module.stack_protector = false;
+ }
+
 // This test is intentionally trying to check if the external ABI is
 // done properly. LTO would be a hindrance to this.
 test_step.lto = .none;

Hopefully that gets this PR across the finish line.

For the latest failure: ```diff diff --git a/test/tests.zig b/test/tests.zig index 28cb147cf8..983f434d37 100644 --- a/test/tests.zig +++ b/test/tests.zig @@ -2855,6 +2855,11 @@ pub fn addCAbiTests(b: *std.Build, options: CAbiTestOptions) *Step { .max_rss = options.max_rss, }); + // https://github.com/llvm/llvm-project/issues/195561 + if (target.cpu.arch.isPowerPC()) { + test_step.root_module.stack_protector = false; + } + // This test is intentionally trying to check if the external ABI is // done properly. LTO would be a hindrance to this. test_step.lto = .none; ``` Hopefully that gets this PR across the finish line.

runewalsh commented 2026年05月27日 10:50:21 +02:00

Some time ago I did a similar thing for FPC, and for stack traces I used a structure (heaptrc.pp:StackTracesRegistry; which relies on StackTrace; which relies on VarInt) that stores them compressed and deduplicated. Perhaps you’d like to do the same? :)

Compression is achieved by delta encoding the code pointers within each stack trace, then storing them as zigzag-encoded varints. Functions that call one another are often physically close, resulting in small, often 2-byte differences, and even when they are not, they rarely require the full 8 bytes. This saves ×ばつ on average.

Deduplication is complex and requires heavy synchronization, but saves another ×ばつ (for FPC compiling itself), stacking with compression for a total of ×ばつ. In absolute numbers, this reduces 1.2 GB of stack traces (or 10 GB when naively allocating the maximum trace size, which was 64 pointers) to 80 MB.

Come to think of it, such a StackTracesRegistry could in principle be thread-local, but that would reduce the effectiveness of deduplication depending on the workload.

Some time ago I did a [similar thing](https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1278) for FPC, and for stack traces I used a structure ([`heaptrc.pp:StackTracesRegistry`](https://gitlab.com/freepascal.org/fpc/source/-/blob/3989b8927cf67a516a4ab309c124577e40036ded/rtl/inc/heaptrc.pp#L746); which relies on [`StackTrace`](https://gitlab.com/freepascal.org/fpc/source/-/blob/3989b8927cf67a516a4ab309c124577e40036ded/rtl/inc/heaptrc.pp#L678); which relies on [`VarInt`](https://gitlab.com/freepascal.org/fpc/source/-/blob/3989b8927cf67a516a4ab309c124577e40036ded/rtl/inc/heaptrc.pp#L529)) that stores them compressed and deduplicated. Perhaps you’d like to do the same? :) Compression is achieved by delta encoding the code pointers within each stack trace, then storing them as zigzag-encoded varints. Functions that call one another are often physically close, resulting in small, often 2-byte differences, and even when they are not, they rarely require the full 8 bytes. This saves ×ばつ on average. Deduplication is complex and requires heavy synchronization, but saves another ×ばつ (for FPC compiling itself), stacking with compression for a total of ×ばつ. In absolute numbers, this reduces 1.2 GB of stack traces (or 10 GB when naively allocating the maximum trace size, which was 64 pointers) to 80 MB. Come to think of it, such a `StackTracesRegistry` could in principle be thread-local, but that would reduce the effectiveness of deduplication depending on the workload.