One other note, it often works for large programs as well if you control the access pattern, as the OS will page out based on LRU so you can just keep allocating and never free… until you end. To make this work you sometimes need a special allocator so that old pages aren’t touched when allocating
Btw this technique is common place for small utility programs - it is often harder to code the object life cycle in a complicated tree - so just don’t free until the process ends. Which is why GC is so beneficial for most programs. On Feb 27, 2025, at 5:47 PM, Robert Engels wrote:This is a perfec
This is a perfect case of weak references BUT these are still objects the GC needs to track, etc. A better solution for a compiler, is that if the original code did not need to free - and that was a substantial amount of the compiler garbage to make a difference - just run the compiler with GC turn
>GOMEMLIMIT (https://go.dev/doc/gc-guide#Memory_limit) applies this idea to
all allocations. (GC doesn't need to run if there is lots of headroom).
Isn't that only useful if there's a limit, and you know what it is? That
isn't the case for the Go command in general.
>I'm not sure I understand the
On Thu, Feb 27, 2025 at 5:56 PM Amnon wrote:
> Go nearly had Arenas a few years ago. And I think they are still used in
> Google.
> But they were pulled because the polluted the API's of too many libraries.
> See https://github.com/golang/go/issues/51317
> On Thursday, 27 February 2025 at 07:55:2
Go nearly had Arenas a few years ago. And I think they are still used in
Google.
But they were pulled because the polluted the API's of too many libraries.
See https://github.com/golang/go/issues/51317
On Thursday, 27 February 2025 at 07:55:27 UTC will@gmail.com wrote:
> I recently recalled t
