For what it's worth, a bit of "memory management" on structures in many cases is very ok (not sure if in your case). So for your cyclic structure with finalizers, requiring the user of your code to call some "Finalize()" method (some destructor method you define) that manually breaks the cycle, often is an ok solution. Fundamentally, it's the same as requiring someone to call Close() on an opened file (or any other resource, like sockets, db connections, etc).
As an anecdote, previously when I was doing C++ I was a big fan of referenced counted smart pointers (`shred_ptr<>`), which gets most of the benefit of GC, but with a much lower cost. They required manually breaking cycles, which I didn't find to be an issue at all in the great majority of the cases. On Monday, November 6, 2023 at 11:01:04 AM UTC+1 Jan wrote: > I was very surprised by this behavior of SetFinalizer: and indeed if you > remove the SetFinalizer one can see that s1 is freed, because the memory > reported by `m.HeapAlloc` goes back down. > > I think you already have the answer: the block that has the cycle (s1 and > s2) have a SetFinalizer set, and it will never run, per documentation (I > had never paid attention to this). > > A suggestion to work around would be to move the stuff that needs a > "Finalizer" to a leaf node, as in: > > https://go.dev/play/p/WMMTdAza6aZ > > But I understand this is not a solution if the finalizer needs to access > the S1 (so, if the finalizer function needs any information that is not > self-contained in `S1Data` in my example). > On Sunday, November 5, 2023 at 4:01:14 PM UTC+1 Soren Yang wrote: > >> As shown in the following code: >> >> cyclic structure with finalizer <https://go.dev/play/p/Fn_h08y-L6b> >> >> The s1 & s2 didn't been free, and finalizer didn't run. But when enable >> the line which have been commented, all run as expected（s1 & s2 been free）。 >> >> I have seen the comment in runtime.SetFinalizer： If a cyclic structure >> includes a block with a finalizer, that cycle is not guaranteed to be >> garbage collected and the finalizer is not guaranteed to run, because there >> is no ordering that respects the dependencies. >> >> But why it haven't been free in first code？ >> > -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/8caf932b-d9b4-45ae-b195-a8f323456665n%40googlegroups.com.
