AllocCheck.jl

When a hot loop requires multiple distinct allocations or complex types (like closures or multiple arrays), it is best practice to encapsulate these in a Workspace struct. This allows you to separate the setup logic from the execution logic.

By using a struct, you can easily determine the exact type required for check_allocs by calling typeof(workspace) after the setup phase. Even if the struct itself is immutable, it can contain mutable fields (like Vector or Matrix) that the hot loop modifies in-place.

Workflow:

1. Define a Workspace struct containing the necessary buffers.
2. Create a setup() function that returns an initialized Workspace.
3. Create a run!(workspace) function containing the hot loop.
4. Use check_allocs(run!, (typeof(workspace),)) to validate the loop.

struct Workspace
    cache1::Vector{Float64}
    cache2::Matrix{Float64}
end

function setup()
    return Workspace(zeros(100), zeros(100, 100))
end

function run!(workspace::Workspace)
    for i = eachindex(workspace.cache1)
        workspace.cache1[i] = 1.0
    end
end

# Verification
workspace = setup()
allocs = check_allocs(run!, (typeof(workspace),))
@test isempty(allocs)

In high-performance or real-time Julia code, a common pattern is to perform all necessary memory allocations in a 'preamble' phase, followed by a performance-sensitive 'hot loop' that must perform zero allocations to ensure predictable timing and avoid garbage collection.

To use AllocCheck.jl effectively for this pattern, you should refactor your code into two distinct parts:

1. A Preamble: A function that performs the initial allocations (e.g., creating vectors, matrices, or workspace structs).
2. A Hot Loop: A function (conventionally ending in ! to indicate in-place modification) that accepts the pre-allocated memory as arguments and performs the core computation without allocating.

You can then use check_allocs to verify that the hot loop function is indeed allocation-free.

using AllocCheck, Test

# 1. Define the hot loop that uses pre-allocated memory
function run_hot_loop!(logvector)
    for i = eachindex(logvector)
        @inbounds logvector[i] = 2.0 # Example computation
    end
end

# 2. Use check_allocs to verify it performs no allocations
# The second argument is a tuple of the types of the arguments passed to the function
allocs = check_allocs(run_hot_loop!, (Vector{Float64},))
@test isempty(allocs)

In safety-critical real-time systems, error-recovery logic must run with minimum latency. By default, check_allocs allows allocations that occur on the error path (allocations triggered by an exception). These allocations can trigger the Garbage Collector (GC), introducing unbounded latency before your recovery logic executes.

To guarantee low-latency recovery, follow this pattern:

1. Verify zero allocations: Use check_allocs to prove the function does not allocate memory except on exception paths.
2. Disable the GC: Manually disable the GC (GC.enable(false)) before entering the critical section.
3. Recover and Re-enable: Use a try...catch...finally block. Execute your recovery logic in the catch block and ensure the GC is re-enabled in the finally block to prevent system-wide issues.

function treading_lightly()
    a = 0.0
    GC.enable(false) # Turn off the GC before entering the loop
    try
        for i = 10:-1:-1
            a += sqrt(i) # This throws an error for negative values of i
        end
    catch
        exit_gracefully() # This function is supposed to run with minimum latency
    finally
        GC.enable(true) # Always turn the GC back on before exiting the function
    end
    a
end

exit_gracefully() = println("Calling mother")

using AllocCheck, Test
# Verify that the function does not allocate memory on the happy path
allocs = check_allocs(treading_lightly, ())
@test isempty(allocs)

Because check_allocs operates on types rather than values, it cannot know that a boolean argument like verbose::Bool will be false at runtime. If your function contains conditional logging (e.g., verbose && @info ...), check_allocs may report potential allocations even if the logging is never actually executed.

To prove a function does not allocate when logging is disabled, you must lift the value into the type domain using the Val{T} type. This encodes the value into the function's signature, allowing the compiler and check_allocs to see that the logging path is unreachable.

# 1. The problematic way: check_allocs sees 'Bool' and assumes potential allocation
@check_allocs function myfun(verbose::Bool)
    verbose && @info "log"
end
myfun(false) # May report allocations

# 2. The correct way: use Val{T} to encode the value in the type
function typed_myfun(::Val{verbose}) where verbose
    verbose && @info "log"
end

# Prove it allocates 0 bytes when verbose is false
length(check_allocs(typed_myfun, (Val{false},)))

# You can still use it with logging enabled:
typed_myfun(Val{true}())