Filter AllocCheck jl_get_pgcstack_fallback false positive on aarch64#68
Draft
ChrisRackauckas-Claude wants to merge 1 commit into
Draft
Conversation
…rch64 On aarch64 (Apple Silicon, e.g. macos-latest) Julia 1.13 fetches the per-task GC stack pointer via jl_get_pgcstack_fallback instead of a TLS/register fast path. AllocCheck's whitelist (classify.jl) already treats the fast-path variants jl_get_pgcstack and jl_get_pgcstack_static as non-allocating, but omits the _fallback variant, so check_allocs conservatively reports it as an AllocatingRuntimeCall. This is a false positive: that call does not allocate. This caused the zero-allocation tests to fail only on the julia-pre / macos-latest (aarch64) CI job while passing on x86_64. Filter out only the jl_get_pgcstack_fallback AllocatingRuntimeCall before asserting emptiness; every other result (real AllocationSite, DynamicDispatch, or other allocating runtime call) still fails the test, so the zero-allocation invariant is fully preserved. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
julia pre/macos-latest(aarch64 / Apple Silicon) CI job fails the zero-allocation tests intest/alloc_tests.jlon Julia 1.13.0-rc1, while every other platform (x86_64 ubuntu/windows, all other Julia versions) passes.Root cause
On aarch64 the per-task GC stack pointer is fetched through
jl_get_pgcstack_fallbackrather than a TLS/register fast path.AllocCheckalready treats the fast-path variantsjl_get_pgcstackandjl_get_pgcstack_staticas non-allocating (seeclassify.jlfn_may_allocate), but its whitelist omits the_fallbackvariant. As a resultcheck_allocsconservatively reports it as anAllocatingRuntimeCall, producing a false positive. The call does not actually allocate; this is purely an artifact of AllocCheck's incomplete whitelist (still present in the latest AllocCheck 0.2.5).This is why the CI log shows, only on macos aarch64:
Fix
Add a small
real_allocshelper that strips only thejl_get_pgcstack_fallbackAllocatingRuntimeCallfrom thecheck_allocsresults before asserting emptiness. Every other result (a realAllocationSite, aDynamicDispatch, or any other allocating runtime call) still fails the test, so the zero-allocation invariant is fully preserved -- no test is weakened, skipped, or broadened. This only removes one documented tool false positive.Verification (local)
test/alloc_tests.jlon Julia 1.13.0-rc1 (x86_64 linux): 11/11 pass (matches the green CI jobs), confirming the change does not regress the passing path.real_allocsfilter against synthetic AllocCheck results:[jl_get_pgcstack_fallback]-> empty (the exact aarch64 case becomes green).[jl_get_pgcstack_fallback, AllocationSite]-> still non-empty (real allocation still caught).[jl_get_pgcstack_fallback, other AllocatingRuntimeCall]-> still non-empty (other runtime allocs still caught).The proper long-term fix is upstream in AllocCheck (add
get_pgcstack_fallbackto the non-allocating whitelist inclassify.jl); this PR makes the test robust in the meantime.Please ignore until reviewed by @ChrisRackauckas.