Swift ARC Doesn’t Scan the Heap — I Removed strong_release from SIL to Prove It

henry — Thu, 20 Aug 2026 07:35:56 +0000

Also available: Korean version · Source code and reproducible experiments

A source-to-runtime experiment with Swift 6.3.1: inspect ownership in SIL, delete one strong_release, measure the resulting leak, compare weak-reference lowering, and follow the call stack into the Swift runtime.

Swift ARC is sometimes explained as if it were a background service that periodically scans memory and frees objects that are no longer used. The word Automatic makes that story sound plausible, but it describes a tracing garbage collector more closely than Swift’s reference-counting model.

Swift ARC works differently:

The compiler analyzes ownership and value lifetimes.
It represents those rules with operations such as copy_value, destroy_value, strong_retain, and strong_release in SIL.
Those operations are lowered to runtime behavior such as swift_retain and swift_release.
When a release brings an object’s strong reference count to zero, destruction begins on that execution path.

There is no periodic heap traversal asking which objects are still reachable from a root set. Reference-count updates are driven by ownership events.

This repository checks that claim at four different layers:

Source → SILGen → SIL → LLVM IR
A causal intervention: delete exactly one object release
Runtime observations: deinit, maximum RSS, and an LLDB backtrace
Swift’s open-source reference-counting implementation

It also examines how weak storage is lowered and uses a strong reference cycle to contrast reference counting with tracing GC.

The result in one picture

Swift source ownership
        │
        ▼
SIL destroy/release operations
        │
        ▼
swift_release / refcount decrement
        │
        ├── count > 0 ──► object stays alive
        │
        └── count == 0 ─► deinit / destruction

Removing the strong_release for the test object broke that chain. Its deinit disappeared, and a repeated-allocation workload grew from roughly 2.5 MB to 145 MB maximum RSS.

Experiment environment

The checked-in patches were verified with:

Apple Swift version 6.3.1
Target: arm64-apple-macosx26.0
Xcode 26.4.1
macOS 26.5.1
Runtime loaded during execution: libswiftCore.dylib 6.3.2 (6.3.2.1.3)

SIL is an implementation-level representation. Instruction selection, temporary value numbers, and release placement may change between compiler versions or optimization settings. If a patch no longer applies on another toolchain, regenerate the SIL and locate the corresponding release again.

A short SIL primer

SIL, the Swift Intermediate Language, sits between Swift source and LLVM IR. It preserves Swift concepts—including types, calling conventions, generics, and ownership—at a level where the compiler can reason about them before lowering to LLVM.

This article observes the following pipeline:

Stage	Command	What to inspect
Swift source	`.swift`	Language-level scopes, `let`, and `weak`
Raw SIL	`swiftc -emit-silgen`	`@owned`, `@guaranteed`, `begin_borrow`, `destroy_value`
Canonical SIL	`swiftc -emit-sil -Onone -Xfrontend -disable-arc-opts`	`strong_release`, `load_weak`, `store_weak`
LLVM IR	`swiftc -emit-ir`	`swift_release`, `swift_weakLoadStrong`, and other runtime entry points
Machine code/runtime	Execute under LLDB	The decrement-to-`deinit` call path

-disable-arc-opts is an internal compiler option used here to make ARC operations easier to inspect. It is not a recommended production build setting. With ARC optimization enabled, the compiler may remove balanced retain/release pairs, move releases, transfer ownership through calling conventions, or inline runtime operations.

Experiment 1: Follow a local strong reference through the compiler

The relevant source from Examples/StrongReference.swift is intentionally small:

do {
    let object = TrackedObject(id: 1)
    consume(object)
    print("before scope end")
}

print("after scope")

TrackedObject prints from init and deinit, while consume is marked @inline(never) so that the object has an observable use.

Raw SIL: ownership and lifetime

The essential part of the -emit-silgen output is:

%37 = apply %36(...) : ... -> @owned TrackedObject
%38 = move_value [lexical] [var_decl] %37

%40 = begin_borrow %38
%42 = apply %41(%40) : ... (@guaranteed TrackedObject) -> ()
end_borrow %40

destroy_value %38

What each operation means:

@owned: the value carries independent ownership and must be consumed exactly once along every control-flow path.
move_value [lexical]: establishes the lexical lifetime corresponding to the local object variable.
begin_borrow / end_borrow: lends the object to consume without transferring or duplicating ownership.
destroy_value: ends the owned value’s lifetime. At this abstraction level, the compiler expresses value destruction rather than requiring a literal swift_release call.

The SIL ownership specification defines the same invariant: an owned value must be consumed exactly once, either by destroy_value or another consuming instruction.

Canonical SIL: the concrete object release

After ownership lowering, the same lifetime ending becomes more concrete:

%32 = apply %31(...) : ... -> @owned TrackedObject
debug_value %32, let, name "object"

%35 = apply %34(%32) : ... (@guaranteed TrackedObject) -> ()

// Code for print("before scope end")

strong_release %32

// Code for print("after scope")

The source never calls release(object). The compiler materialized strong_release %32 from the source-level lifetime rules.

The official SIL instruction reference defines strong_release as decrementing the referenced heap object’s strong count. If the count reaches zero, the object is destroyed; object memory is deallocated once the relevant strong and unowned counts permit it.

At the LLVM IR layer, this becomes:

call void @swift_release(ptr %object)

That gives us a traceable chain from source lifetime to a runtime reference-count operation.

Experiment 2: Delete one `strong_release`

SIL/remove-object-release.patch removes exactly one line:

-  strong_release %32

The allocation, object use, print statements, destructor, and all other SIL remain unchanged. The original and modified SIL are then compiled back into separate executables.

Original SIL:

before scope
init(1)
consume(1)
before scope end
deinit(1)
after scope

With the object’s strong_release removed:

before scope
init(1)
consume(1)
before scope end
after scope

deinit(1) is gone. The scope ends and later statements execute, but the runtime does not rediscover and collect the object afterward. The ownership event that would have decremented its strong count is missing.

For consistency of symbols and module context, this reproduction command passes the same module name that generated the SIL:

xcrun swiftc \
    -module-name ARCLab \
    Build/SIL/StrongReference.leaky.sil \
    -o Build/Binaries/strong-leaky

With Swift 6.3.1, this artifact also compiles when the module name is omitted or changed. Reusing the name is therefore a consistency choice for this experiment, not a general requirement for recompiling textual SIL.

Experiment 3: Turn the missing release into measurable heap growth

The missing deinit demonstrates that the object lifetime did not end, but a memory-usage comparison makes the consequence more visible.

Examples/MemoryGrowth.swift creates 512 Payload objects. Each object owns a distinct 256 KiB array buffer. In the normal SIL, each loop iteration ends with a strong_release of the local payload. SIL/remove-payload-release.patch removes only that release.

Repeated verification on 2026-08-20 produced approximately:

Executable	Maximum RSS
Original SIL	about 2.5 MB
`strong_release` removed	about 145 MB

The absolute values depend on the operating system, allocator, and machine state. The important property is experimental control: both executables perform the same allocations and workload, while one object release is the only intentional difference.

Same allocation size
Same object use
Same iteration count
        │
        └── Only strong_release changes
                     │
                     ├── Present: buffers are reclaimed across iterations
                     └── Removed: buffers accumulate

This is a causal intervention, not merely a timing correlation.

Experiment 4: What changes for a weak reference?

Examples/WeakReference.swift stores its target like this:

final class WeakObserver {
    weak var target: WeakTarget?
}

Getter: `load_weak`

The synthesized getter contains:

sil ... WeakObserver.target.getter
    : $@convention(method) (@guaranteed WeakObserver)
      -> @owned Optional<WeakTarget> {
bb0(%0 : $WeakObserver):
  %2 = ref_element_addr %0, #WeakObserver.target
  %3 = begin_access [read] [dynamic] %2
  %4 = load_weak %3
  end_access %3
  return %4
}

ref_element_addr obtains the address of the target property inside the observer.
begin_access [read] begins a read access scope for that storage.
load_weak safely reads the weak slot.
The getter returns @owned Optional<WeakTarget>. That does not mean the field persistently owns the target. If the target is alive at load time, the operation produces a temporary strong result that the caller can use safely.

In LLVM IR, load_weak lowers to:

%target = call ptr @swift_weakLoadStrong(ptr %weakStorage)

The name is descriptive: load from weak storage and, if the target is still alive, return a strong reference. This prevents a concurrent deallocation from turning the read into an invalid pointer.

Setter: `store_weak`

The synthesized setter contains:

%5 = ref_element_addr %1, #WeakObserver.target
%6 = begin_access [modify] [dynamic] %5
store_weak %0 to %6
end_access %6

The property’s persistent storage operation is store_weak, not a strong-property assignment that keeps the target retained.

You may still see balanced retain_value %0 and release_value %0 operations around the setter parameter. They protect temporary values during the call; they do not make WeakObserver.target a persistent strong owner.

Destroying weak storage

With this toolchain, the synthesized WeakObserver.deinit contains:

%2 = ref_element_addr %0, #WeakObserver.target
%3 = begin_access [deinit] [static] %2
destroy_addr %3
end_access %3

There is no literal destroy_weak instruction in this canonical SIL output. The type-aware destroy_addr is lowered further, and LLVM IR contains:

call void @swift_weakDestroy(ptr %weakStorage)

Instruction spelling can vary by compiler stage and version. For Swift 6.3.1, the observed mapping is:

Meaning	Canonical SIL	LLVM IR/runtime
Initialize weak storage	`store_weak ... [init]`	`swift_weakInit`
Assign weak storage	`store_weak`	`swift_weakAssign`
Read weak storage	`load_weak`	`swift_weakLoadStrong`
Destroy weak storage	`destroy_addr`	`swift_weakDestroy`

The runtime result matches the ownership model:

target init(2)
before nil: Optional(2)
target deinit(2)
after nil: nil

For native Swift objects, forming a weak reference may create a side table. Weak variables use that side table to observe whether the target is still alive. The lifecycle comments in RefCount.h describe the strong, unowned, and weak counts, along with the side-table states.

One important nuance: deinit and the final release of every related allocation are not necessarily the same instant. A strong count of zero begins deinitialization. Outstanding unowned references may extend the object allocation’s lifetime, and outstanding weak references may keep the side table alive even longer. That state machine is still event-driven reference counting, not tracing GC.

How can we show there is no periodic traversal?

A finite experiment cannot mathematically prove the universal negative “no hidden loop exists anywhere.” Waiting ten seconds and observing an object still alive leaves an easy objection: perhaps the hypothetical period is eleven seconds.

A stronger computing argument combines evidence from independent layers.

1. Observe the compiler artifact

The source lifetime becomes destroy_value, then strong_release, then swift_release. This positively identifies the mechanism that initiates destruction.

2. Remove only that cause

Deleting one strong_release removes deinit and changes maximum RSS from approximately 2.5 MB to 145 MB under the same workload. The result tracks the ownership event directly.

3. Inspect the runtime call stack

Breaking on TrackedObject.deinit produces this stack:

TrackedObject.deinit
TrackedObject.__deallocating_deinit
_swift_release_dealloc
RefCounts<...>::doDecrementSlow<...>
runStrongReferenceExperiment
main

The destructor is not entered from a collector thread or timer callback. It is reached on the main thread through the decrement path initiated by runStrongReferenceExperiment. The swift_release wrapper may be inlined and therefore absent as a separate frame, but doDecrementSlow and _swift_release_dealloc remain visible.

4. Read the runtime control flow

The source in this experiment was compiled with Swift 6.3.1, while the executable loaded the macOS-provided libswiftCore.dylib 6.3.2. The code below uses HeapObject.cpp from the closest public implementation, swift-6.3.2-RELEASE. This is not a claim that Apple’s shipped binary was built from that exact source revision; it verifies that the public control flow matches the path observed in LLDB.

object->refCounts.decrementAndMaybeDeinit(1);

The zero-count slow path in RefCount.h from swift-6.3.2-RELEASE transitions the object into deinitialization and calls:

_swift_release_dealloc(getHeapObject());

Finally, _swift_release_dealloc invokes the metadata destroy function:

asFullMetadata(object->metadata)->destroy(object);

The implementation’s control flow is explicit:

release event → decrement → zero check → destroy

5. Use a reference cycle as a distinguishing case

Examples/ReferenceCycle.swift creates two nodes that own each other, then removes every external strong reference:

first?.next = second
second?.next = first

first = nil
second = nil

The objects are unreachable from the program, but each still has one strong reference from the other node:

first  --strong--> second
  ^                  |
  |------strong------|

A tracing collector reasons about reachability from roots. ARC reasons about strong reference counts. Neither count reaches zero in this cycle, so neither deinit runs:

init(first)
init(second)
external references released
wait finished; no deinit was called

The sleep is not proof by itself. The stronger point is that the result can be derived by accounting for each retain and release: both final counts remain nonzero, and the runtime observation matches that calculation.

Prior art—and what this experiment adds

This article should not claim that modifying SIL to study object deallocation is a new idea. After conducting this experiment independently, I found one particularly close precedent.

In the 2023 Swift Forums thread “SIL strong_release behavior”, the author generated SIL, removed the dealloc_ref inside __deallocating_deinit, and observed a leak with Apple’s leaks tool. Joe Groff explained that reaching a strong count of zero invokes __deallocating_deinit; that function is then responsible for invoking deinit, destroying stored properties, and deallocating the object’s memory.

That experiment and this repository modify different links in the same lifecycle:

2023 Swift Forums experiment	This experiment
Removes `dealloc_ref` inside the deallocating destructor	Removes the earlier `strong_release` ownership event
Observes the result with `leaks`	Compares `deinit` output and maximum RSS: ~2.5 MB → 145 MB
Focuses on strong-reference deallocation	Compares strong and weak lowering in SIL and LLVM IR
Explains the SIL destructor relationship	Captures `doDecrementSlow → _swift_release_dealloc → deinit` in LLDB
Investigates one surprising result	Packages the hypothesis as a reproducible source-to-runtime repository

There is also a direct historical confirmation of the “no explicit periodic GC phase” model. In the 2016 Swift compiler discussion “Questions about ARC”, a participant asked whether Swift used immediate reference counting without an explicit garbage-collection phase. Swift developer Roman Levenstein confirmed that understanding. The same thread notes that ARC updates can still be coalesced or optimized; that does not turn the runtime into a tracing collector.

The contribution here is therefore not the first observation that SIL controls object destruction. It is the combination of:

directly removing the strong_release that ends the object lifetime,
measuring the same workload with and without that release,
explaining weak storage across SIL and LLVM IR,
capturing the runtime decrement-to-destructor stack, and
publishing the complete process as a reproducible experiment.

Important limitations and common traps

The exact source line for `deinit` is not fixed

Event-driven reference counting does not imply that a release must remain at the closing brace shown in source. The optimizer may shorten a lifetime after its last use, subject to lexical-lifetime and deinit-barrier rules. Use withExtendedLifetime(_:) when a lifetime must be explicitly extended.

Retains and releases do not always survive as function calls

The compiler may eliminate balanced operations, transfer ownership through calling conventions, or inline runtime functions. Do not expect every source reference to produce a visible one-to-one swift_retain / swift_release pair in final assembly.

`autoreleasepool` is not tracing GC

Objective-C interoperability can delay releases for autoreleased objects until a pool drains. That batches registered ownership operations; it does not scan the heap for unreachable objects.

Weak references are not free

A weak field does not persistently increment its target’s strong count, but weak storage still requires runtime bookkeeping, side-table state, and safe concurrent loads. “Does not own” is not the same as “has no runtime cost.”

Reproduce the experiments

Requirements:

macOS
Xcode command-line tools
a Swift toolchain close enough to the verified version for the textual SIL patches to apply

Run everything:

./Scripts/run-experiments.sh

The script:

Generates raw SIL, canonical SIL, and LLVM IR under Build/SIL.
Applies the patches that remove the selected strong_release operations.
Compiles the original and modified SIL into separate executables.
Runs the strong, weak, and cycle experiments.
Reports maximum RSS for the repeated-allocation workload.

Capture the release-to-deinit call stack:

./Scripts/capture-release-stack.sh

Search the generated artifacts directly:

rg -n 'destroy_value|strong_release' Build/SIL/StrongReference.*.sil
rg -n 'load_weak|store_weak' Build/SIL/WeakReference.*.sil
rg -n 'swift_release|swift_weak' Build/SIL/*.ll

Conclusion

The Automatic in Swift ARC does not mean that the runtime periodically walks the heap. It means developers do not manually write every retain and release: the compiler derives ownership operations from the program’s lifetime rules, and the runtime applies the resulting reference-count state transitions.

In these experiments:

Source ownership became SIL destruction and release operations.
Removing one strong_release removed deinit and caused measurable heap growth.
LLDB connected the decrement slow path directly to the deallocating destructor.
Weak properties lowered through dedicated weak-storage operations and side-table runtime calls.
A strong cycle remained allocated because its reference counts never reached zero, even after the objects became unreachable.

That is the right mental model for Swift ARC: not periodic cleanup, but compiler-generated ownership operations driving runtime reference-count transitions.

DEV Community: henry

Swift ARC Doesn’t Scan the Heap — I Removed strong_release from SIL to Prove It

The result in one picture

Experiment environment

A short SIL primer

Experiment 1: Follow a local strong reference through the compiler

Raw SIL: ownership and lifetime

Canonical SIL: the concrete object release

Experiment 2: Delete one `strong_release`

Experiment 3: Turn the missing release into measurable heap growth

Experiment 4: What changes for a weak reference?

Getter: `load_weak`

Setter: `store_weak`

Destroying weak storage

How can we show there is no periodic traversal?

1. Observe the compiler artifact

2. Remove only that cause

3. Inspect the runtime call stack

4. Read the runtime control flow

5. Use a reference cycle as a distinguishing case

Prior art—and what this experiment adds

Important limitations and common traps

The exact source line for `deinit` is not fixed

Retains and releases do not always survive as function calls

`autoreleasepool` is not tracing GC

Weak references are not free

Reproduce the experiments

Conclusion

References

DEV Community: henry

Swift ARC Doesn’t Scan the Heap — I Removed strong_release from SIL to Prove It

The result in one picture

Experiment environment

A short SIL primer

Experiment 1: Follow a local strong reference through the compiler

Raw SIL: ownership and lifetime

Canonical SIL: the concrete object release

Experiment 2: Delete one strong_release

Experiment 3: Turn the missing release into measurable heap growth

Experiment 4: What changes for a weak reference?

Getter: load_weak

Setter: store_weak

Destroying weak storage

How can we show there is no periodic traversal?

1. Observe the compiler artifact

2. Remove only that cause

3. Inspect the runtime call stack

4. Read the runtime control flow

5. Use a reference cycle as a distinguishing case

Prior art—and what this experiment adds

Important limitations and common traps

The exact source line for deinit is not fixed

Retains and releases do not always survive as function calls

autoreleasepool is not tracing GC

Weak references are not free

Reproduce the experiments

Conclusion

References

Experiment 2: Delete one `strong_release`

Getter: `load_weak`

Setter: `store_weak`

The exact source line for `deinit` is not fixed

`autoreleasepool` is not tracing GC