It's unclear to me how this could be useful. It is true that uintptr is not looked at by the garbage collector. This will definitely reduce your GC costs. But there is no way (that I know of) to convert your uintptr back into a *Object that is safe.
Because uintptr is ignored by the GC it won't keep the memory it points to alive. So the *Object could, and very likely will, be collected as garbage. As noted above the sync.Pool is allowed to discard things that it is pooling. The last time I read the details the strategy was to clear _everything_ in the pool during a GC run. You can avoid this by going old-fashioned and using a `chan *Object` as your pool. Assuming, you are storing these things in the channel at the same time you are storing their `uintptr`s in the map they won't be recovered by the garbage collector. This will probably work. But, critically _only_ with the non-moving GC that Go uses currently. There is a reasonable chance that Go, or some implementation of Go, will adopt a moving garbage collector. Then your `uintptr`s would potentially point to an old memory location after a GC run. On Thursday, 27 September 2018 16:39:48 UTC+2, Robert Engels wrote: > > No offense, sorry for high jacking, I was trying to counter point their > usefulness, as a way to limit additional resources being spent to improve > GC when using them, since I think their application is error prone in many > most? cases. > > > On Sep 27, 2018, at 9:30 AM, Peter Mogensen <a...@one.com <javascript:>> > wrote: > > > > > > > >> On 09/27/2018 04:20 PM, Ian Davis wrote: > >> > >> https://github.com/golang/go/issues/23199 describes another gotcha > when using pools: pinning of memory buffers. > >> > > > > Yes... that's a good point for people considering to use sync.Pool. > > > > For the purpose of this question however, let's assume the decision to > > use sync.Pool for the actual objects already has been taken and that > > knowing when to call Put() is not an issue. > > We can also perfectly assume that the pool managed objects are NOT of > > variable size (as in the above link) and do not use growing buffers, > > either by bytes.Buffer or by using append() ... which is actually the > > case for my current code. > > > > I hope I'm not rude, when I try to steer this thread back on topic and > > avoid that it degenerates to a discussion of whether sync.Pool is hard > > to use in general - which was not the intention of my original question > > regarding the fix in https://go-review.googlesource.com/c/go/+/3288 > > > > Well meaning, > > Peter > > > > -- > > 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 <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > -- 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. For more options, visit https://groups.google.com/d/optout.
