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/ed3f71ce-33c8-4711-8a98-ae2409a33764n%40googlegroups.com.
