Does this behaviour mean that, those memory will never be freed and keep piling on ? That can be disastrous.
On Monday, November 6, 2023 at 3:39:50 PM UTC+5:30 Jan wrote: > 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/3df79a33-c5bb-46e2-969e-7db76e66ce94n%40googlegroups.com.
