Re: [go-nuts] Re: GC hint for collection timing

[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 <w...@willfaught.com> wrote:  >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 On Thu, Feb 27, 2025 at 3:03 PM 'Michael Pratt' via golang-nuts <golang-nuts@googlegroups.com> wrote: On Thu, Feb 27, 2025 at 5:56 PM Amnon <amno...@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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2ebe77c1-7d62-4e5f-b300-1165e99cd477n%40googlegroups.com. -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CALoThU_1qcONrXA_%3DDK11RBvJqEez6BMHKOZEBXtexmrbXXdpQ%40mail.gmail.com. -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAKbcuKj43NTWS5UFgFcuYpHU%3D20Z_%2B7fbNAOFAVDgPKn6mZ7kw%40mail.gmail.com. -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/D9256EC4-498F-4632-969E-F31CCE0FD607%40ix.netcom.com.