Disabling Garbage Collection

[mcmah309]

Disabling garbage collection either dynamically or during compilation would open up new performance opportunities. And if rust signatures are ever emitted to call otter functions, it would make users more inclined to integrated into existing rust projects if they are concerned about gc overhead. Possible options:

• Compilation: Useful to make binary and library functions essentially work like arenas

• Dynamically: For heavy workloads. Objects allocated while GC is disabled are still tracked, just not collected.

fn main():
    gc_disable()
# Do some work
    gc_enable() # If never re-enabled, then essentially the whole program or library function works like an arena

• Arenas: Support arenas directly. Any arguments to an arena function are owned by the calling function and any returned values become owned by the calling function. It would require any value returned by the arena to be clonable, since if called by a non-arena function then the value should be cloned before the arena is freed. Every non-arena to arena call creates a new arena.

arena fn main():
   # Do some work

[Merc6]

Could be interesting, but at the same time, introducing a new keyword for what I'm assuming disables gc, and then enables some sort of arena allocation, might be too much. I'm not against being able to change up allocators though, I think a more scalable approach could be the default global allocator being garbage collected, then you could have special other allocators-such as Arena-be opt in, similar to a more zig-like approach

[mcmah309]

Maybe allowing switching the allocator at function invocation would be nice and it would apply to the entire scope

fn func():
    todo()

let value = arena func()
# Or block syntax
let value = arena:
    func()

Something like

fn main():
    arena:
        # Code here
fn lib_function(value: str) -> str:
    arena:
        # Code here

Could optimized to disable gc altogether.

I am against it becoming too verbose though - e.g. allocators having to be passed to each function explicitly. Given the design of the language, I am not sure if other allocators besides arena would be useful. Thus an arena keyword may be fine.

[Merc6]

See I think there's a few issues with your approach; first being that the arena keyword can be slapped wherever, sure syntactically it looks cool, but it implies a global arena, and unless all the arena can hold is pointers, that arena can only hold one type. Next is how do you cleanup the memory used by the arena, you can't just say it'll get cleaned up at the end of the scope, because then it'd be pretty useless, and you can't say it gets cleaned up after the program runs, because the os will clean it up, that's not actually cleaning up the memory, that's just a memory leak. As for my approach not being fit for the language, I completely agree, but neither does manual memory management as a whole realistically fit. The next best approach I see is that you can create some sorta allocator at the top of a file scope, and functions can just use it like a global variable with &mut access. Even then, you can't just say everything gets allocated to it, so you'd still have to pass it around in some way, or use some syntactic sugar

[mcmah309]

first being that the arena keyword can be slapped wherever,

Yes that is fine.

sure syntactically it looks cool, but it implies a global arena, and unless all the arena can hold is pointers, that arena can only hold one type.

It does not imply a global arena. It implies a scoped arena. Arenas can hold many types, it does not have to hold just one type.

how do you cleanup the memory used by the arena, you can't just say it'll get cleaned up at the end of the scope, because then it'd be pretty useless

That's the entire point of an arena. And anything you want to return from it gets cloned into the outer allocator.

I think you may be confusing terms or do not understand what and arena allocator is. All an arena is, is an allocator in which everything is freed at once. Each arena scope has it's own allocator. The point of using an arena is you don't need the overhead of garbage collection - e.g. cycle checks to determine when to free unreachable memory.

[Merc6]

I get what you're going for, but I think there's some conceptual drift here around what arenas actually are and how they'd fit in. An arena isn't just an allocator that frees everything at once. it's a contiguous lock of memory that tracks how much has been used and where new allocations can go. It still needs to know object sizes, alignment, and type layout unless everything stored is a pointer or uniformly sized. Saying "Arenas can hold many types . . ." isn't really true unless the arena only stores references, which undercuts the whole point of fast, linear allocation.

A scoped arena keyword also doesn't make sense for this language model. If it's just there to disable garbage collection for a few lines, that's effectively a manual GC toggle - something you'd handle at the allocator level, not in syntax. And if the arena truly frees its memory at the end of a block, anything borrowed or passed by reference instantly becomes invalid. That's a lifetime hazard unless every value is cloned or promoted out. which erases any performance gain the arena was meant to provide.

[mcmah309]

It still needs to know object sizes, alignment, and type layout unless everything stored is a pointer or uniformly sized.

No it does not. Each alloc invocation passes this information based on the type at compile time

Saying "Arenas can hold many types . . ." isn't really true unless the arena only stores references, which undercuts the whole point of fast, linear allocation.

Why can it only store references? I have built arenas that can store many different types. I don’t know what you are talking about.

A scoped arena keyword also doesn't make sense for this language model. If it's just there to disable garbage collection for a few lines, that's effectively a manual GC toggle - something you'd handle at the allocator level, not in syntax.

It doesn’t disable gc if not used at the top level. Everything inside the block just uses a scoped arena allocator and isn’t touched by gc. Which probably makes more sense in the language since the returned value needs to be cloned out at the end and the rest of the program use gc again (or what is in the outer scope). It’s possible to do manually by setting and passing around allocators, but more likely to get wrong and cause UB.

And if the arena truly frees its memory at the end of a block, anything borrowed or passed by reference instantly becomes invalid. That's a lifetime hazard unless every value is cloned or promoted out. which erases any performance gain the arena was meant to provide.

Only the returned value needs to be deeply cloned out which is trivial.

[Merc6]

The allocator passing size and alignment "at compile time" doesn't eliminate the need for the arena to handle that info dynamically. You can't linearly bump a pointer safely without knowing the size and alignment of what's being placed. That data always flows through runtime, even if statically known at the call site. Otherwise you'd need a distinct arena per type and alignment requirement, which defeats the purpose.

As for "arenas that can store many different types," sure, but only by erasing type information. You're either writing untyped memory and reinterpreting it, or you're storing boxed references to data that lives elsewhere. Both models still boil down to the arena not owning a typed layout, which is fine, but then you're not getting the safety or efficiency benefits you think you are.

The "scoped arena" idea sounds more like a region-based lifetime system baked into syntax than a true allocator choice. In a GC language, that means juggling two incompatible lifetime models; being, lexical scopes and heap tracing. Saying "only the returned value needs to be deeply cloned out" is oversimplified - anything indirectly reachable from that value also needs cloning. Deep copies aren't free, especially once you introduce nested references or cyclic data.

[mcmah309]

The allocator passing size and alignment "at compile time" doesn't eliminate the need for the arena to handle that info dynamically. You can't linearly bump a pointer safely without knowing the size and alignment of what's being placed.

Yes.

That data always flows through runtime, even if statically known at the call site.

Not sure exactly what you mean here.

As for "arenas that can store many different types," sure, but only by erasing type information. You're either writing untyped memory and reinterpreting it,

Exactly.

you're not getting the safety or efficiency benefits you think you are.

How so? The way I see it is you don’t need reference counting or cycle checks anymore.

The "scoped arena" idea sounds more like a region-based lifetime system baked into syntax than a true allocator choice.

Yes it’s not as simple as “just swap out the allocator”

In a GC language, that means juggling two incompatible lifetime models; being, lexical scopes and heap tracing. Saying "only the returned value needs to be deeply cloned out" is oversimplified - anything indirectly reachable from that value also needs cloning.

Yes.

Deep copies aren't free, especially once you introduce nested references or cyclic data.

Not free, but usually cheap. A single gc cycle check is likely more expensive.

[Merc6]

Right, so the allocator knowing the size/alignment at the call-site doesn't mean the arena doesn't need to handle it. That info still has to flow into the runtime call because the arena logic - bumping the pointer, applying alignment padding, checking capacity, etc - all happens dynamically. You can monomorphize alloc sites per type, but that just shifts the cost to code size; the arena still needs to know how to place the object at runtime.

Then I said that "data always flows through runtime," that's what I mean - compile-time info doesn't eliminate runtime bookkeeping, it just reduces indirection.

On the "many types" part - yes, an arena can hold multiple object kinds, but only by erasing type info or using tagged storage. That's fine, but it means you're losing type safety at the storage level. You're effectively writing bytes into untyped memory and reinterpreting them later At that point, the arena's performance gain depends entirely on your allocation pattern being cache-friendly and short-lived.

That's also why I said you're not necessarily getting the safety or efficiency you think you are. Arenas shine when you can linearly allocate objects that die together - thing ASTs, ot temporary buffers - not as a general-purpose heap replamement. In a GC language, you're mixing two lifetime models; lexical scopes (arena frees) and tracing reachability. That's messy by design, since anything escaping the scope either needs deep cloning or manual promotion into GC space.

And yeah, deep copies can be cheap compared to a full GC cycle, but that assumes the data you're cloning is shallow and non-graph-like. The more nested or interconnected the data, the more that assumption breaks. So it's not that arenas are wrong - just that their benefits shrink fast once you bring GC semantics into the picture

[jonathanmagambo]

sorry ive been very busy but i'll be reading this soon and getting back to you guys

[jonathanmagambo]

Good points on both sides, arenas can offer big wins for short-lived allocations, but mixing them with a GC definitely gets tricky. I think a scoped or opt-in model (like region allocation for temp data) could make sense in Otter, as long as it’s isolated from GC-managed objects. Might be worth experimenting with both approaches later on.