Re:The Garbage Collection Handbook, 2nd Edition
by vlovich123 on Saturday April 08, 2023 @08:02PM
(#35498842)
Correct. But it’ll do it within functions in the same module.
> but it's deterministic after compilation time so I wouldn't call it a runtime optimization.
What do you mean? My understanding is that autoreleasepool is 100% at runtime. The compiler is not involved afaik except to know to register autorelease with the currently installed pool.
Re:The Garbage Collection Handbook, 2nd Edition
by astrange on Sunday April 09, 2023 @12:28AM
(#35500053)
> What do you mean? My understanding is that autoreleasepool is 100% at runtime. The compiler is not involved afaik except to know to register autorelease with the currently installed pool.
The compiler emits calls that always put something in the autorelease pool or always don't; there's no smart decisions at runtime that skips it or make the ordering of releases nondeterministic. A garbage collector runs whenever it feels like and so the ordering of finalizations changes.
Re:The Garbage Collection Handbook, 2nd Edition
by vlovich123 on Sunday April 09, 2023 @03:48PM
(#35505811)
Oh sure. You have to explicitly indicate which resources should go to the autoreleasepool. It’s not as magic as ARC. It’s also generally fallen out of favor at Apple as far as I could tell.
I'm not sure Swift supports "static library modules" so in practice any linked object consists of a single module.
> There actually is some elision that happens at runtime if you install an autoreleasepool if I recall correctly.
There is a trick in the ObjC ABI that elides autorelease-returns, but it's deterministic after compilation time so I wouldn't call it a runtime optimization.