Thanks Robert and Michael, this is helpful. I think my use case falls in the "backend web service" sense of cache category, and should probably not rely on weak pointers.
For me the appeal was "Build a cache without worrying about capacity. Let random items vanish when the runtime is getting short on memory". It's probably wiser however to build a cache with explicit limits on size, and implement my own eviction logic like LRU. My backend might run on a 512MB VM, or 1GB, or 2GB, so I'll have to figure out the appropriate cache size, depending on the current VM. Le lundi 14 avril 2025 à 17:46:52 UTC+2, Michael Knyszek a écrit : > I think it depends on your definition of cache. Caching the result of some > computation that is related to the lifetime of a variable (but for any > number of reasons needs to be decoupled from it) isn't necessarily a > canonicalization map, but weak pointers may still be the right tool. I'm > not sure what else to call such use-cases. (I originally agreed with Robert > and I was originally much more specific in the documentation, but I think > others were right that "cache" can cover a lot of other valid use-cases.) > > On Monday, April 7, 2025 at 12:03:59 PM UTC-4 robert engels wrote: > > I think the documentation is incorrect. > > > Normally, weak pointers are used to break retain cycles in a system that > uses references to implement garbage collection. Since Go has a tracing GC > this isn’t necessary. > > Usually, a “soft” reference, not a “weak” reference is used to implement > caches. A “soft” reference being one that the GC can free if memory is > needed and it is otherwise unreachable - but typically only releases it > under memory pressure. > > With a tracing GC, weak references are typically more useful for > canonicalized maps - that is given a key you always want to return the same > instance of the object, but if there are no longer any references to the > object, the key (and value) can be removed from the map - which is sort of > a cache, but not in the widely used sense. > > With Go, implementing a LRU+ cache using standard references is typically > all that is needed. > > +1. For the "backend web service" sense of cache, this is completely > correct. It's not really intended for that kind of cache. I suppose the > docs could call that out more clearly. > > > On Apr 7, 2025, at 10:21 AM, Val Deleplace <delepl...@gmail.com> wrote: > > "The primary use-cases for weak pointers <https://pkg.go.dev/weak#Pointer> > are for implementing caches" > > I'm trying to create objects and insert a weak pointer to each of them in > a slice. The slice then contains the only reference to each object, thus it > is possible for each pointer's value to become nil anytime, and the > objects' memory garbage collected. > > In practice, on my laptop (macOS, go 1.24.1) the weak pointers tend to > become nil very fast, before I'm finished inserting 400 objects in the > slice, which seems to be "as soon as the object becomes unreachable". > While this observation is consistent with the documentation, I'm wondering > how I can effectively build a cache when the data tends to go away as soon > as it is inserted? > > Keep in mind that if that's *all* your program is doing, you're going to > hit GC cycles quite quickly which will quickly collect everything. Context > matters a lot here. > > > Here is my code <https://go.dev/play/p/mKxiOvI_IJh>, which behaves a bit > differently in the playground but the general observation remains. > > -- > 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/1a129699-ce4a-4deb-bb83-ea2fa484d83bn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/1a129699-ce4a-4deb-bb83-ea2fa484d83bn%40googlegroups.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/9a427126-af3c-4695-8294-0ffdb8a9b61dn%40googlegroups.com.
