GC hint for collection timing

[will....@gmail.com]

I recently recalled that someone in the Go Team—I forget who—said that the Go compiler slowed down a lot after converting from C to Go because the Go GC was freeing a lot of memory that the C code wasn't.

I wonder if an approach like that of memory regions (https://github.com/golang/go/discussions/70257) could be used to hint to the GC that memory allocated in a function doesn't need to be freed unless there is severe memory pressure.

For example (for lack of a better name):

func main() {

    runtime.DeferCollection(func() {

        runCommand()

    })

}

Will

[Amnon]

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

[Michael Pratt]

On Thu, Feb 27, 2025 at 5:56 PM Amnon <amn...@gmail.com> 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:27 UTC will....@gmail.com wrote:

I recently recalled that someone in the Go Team—I forget who—said that the Go compiler slowed down a lot after converting from C to Go because the Go GC was freeing a lot of memory that the C code wasn't.

I wonder if an approach like that of memory regions (https://github.com/golang/go/discussions/70257) could be used to hint to the GC that memory allocated in a function doesn't need to be freed unless there is severe memory pressure.

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).

I'm not sure I understand the rationale for targeting specific functions? If the allocations are unreachable, why does it matter whether they came from a DeferCollection function or not?

If you want a cache that might be cleared under memory pressure (like sync.Pool), that is something that is now possible to build with the weak package (https://pkg.go.dev/weak).

 

For example (for lack of a better name):

func main() {

    runtime.DeferCollection(func() {

        runCommand()

    })

}

Will

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2ebe77c1-7d62-4e5f-b300-1165e99cd477n%40googlegroups.com.

[Will Faught]

>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 rationale for targeting specific functions?

It was just a means of enabling the feature. Perhaps there are better approaches.

Will

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/QT_fp-FqAVM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CALoThU_1qcONrXA_%3DDK11RBvJqEez6BMHKOZEBXtexmrbXXdpQ%40mail.gmail.com.

[Robert Engels]

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 turned off. All of the memory will be reclaimed when the process dies. 

A much more complicated solution would be to target those areas of the compiler with off heap memory - but that’s a pain. 

On Feb 27, 2025, at 5:39 PM, Will Faught <wi...@willfaught.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAKbcuKj43NTWS5UFgFcuYpHU%3D20Z_%2B7fbNAOFAVDgPKn6mZ7kw%40mail.gmail.com.

[Robert Engels]

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 <ren...@ix.netcom.com> wrote:



[Robert Engels]

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 new pages. 

On Feb 27, 2025, at 5:51 PM, Robert Engels <ren...@ix.netcom.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/3B2684AE-4E0F-4687-8EE1-C16A115DFBE5%40ix.netcom.com.