>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 >> <https://groups.google.com/d/msgid/golang-nuts/2ebe77c1-7d62-4e5f-b300-1165e99cd477n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 > <https://groups.google.com/d/msgid/golang-nuts/CALoThU_1qcONrXA_%3DDK11RBvJqEez6BMHKOZEBXtexmrbXXdpQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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.
