You’re right, it’s included in the Quick Actions 😉 Thanks, didn’t know this one!

Code snippet is provided probably in the newest VS, I discovered it after I read your post 😀
https://uploads.disquscdn.com/images/4291fb8a8c917ae048fd65877302645419ec403ef5c45434d1e2491a30e1f70b.png

Thanks for clarifications Konrad 😉
Hope it’s clearer now for Jim and everyone else interested.

`GC.SuppressFinalize` is designed to be called from user threads so its overhead needs to be as low as possible. Thus, the only thing it does is what documentation says – it sets single bit in an object header (look for `BIT_SBLK_FINALIZER_RUN` in CoreCLR if you are really interested). Any manipulation on finalization/fReachable queues would require synchronization between threads, the overhead of which we want to avoid.

This bit is then checked by the finalization thread but only for objects in finalization queue that just become unreachable – if set, it simply removes the object from the finalization queue instead of promoting it to fReachable queue.

The only way to call `GC.SuppressFinalize` on an object in fReachable queue is from its `Finalize` method which is obviously too late (finalization is just happenning). Bit would be set but it doesn’t matter as there is nothing that would interpret it afterwards.

Hey Jim,
good point.
Microsoft docs says: “This method sets a bit in the object header of obj, which the runtime checks when calling finalizers”

However if you think about it, in my implementation GC.SuppressFinalize(this) can be called either directly from code (when the object is still referenced by something, meaning the reference is present on the finalization queue) or by the “finalization thread”, when the reference will be already moved to fReachable queue. So I guess in fact it removes it either from the finalization queue or from fReachable queue, depending when the method is called.

On the other hand I don’t find any more details on a bit flag mentioned in Microsoft docs. The “GC cycle” is passed anyway – as I wrote “finalizable objects stay uncollected for at least 1 more GC round than “normal” objects”.

Anyway, the goal of calling GC.SuppressFinalize is to prevent your object to be finalized twice.

Is the object reference removed from the fReachable queue or the finalization queue, or both? Removing it from the fReachable queue doesn’t seem all that helpful, as the first opportunity to be GCed has already passed.

Hey Wojtek,
thanks for your comment! 🙂
As you know, Dispose is just a pattern and there may be multiple implementations, each one probably better for different use cases (it depends for example is your class is sealed or not). However, I’ve added the link you mentioned into the post so everyone can take a look on this implementation. I guess Microsoft contributors are worth trusting 😉 Thanks for pointing it out!

Can you also direct us to the VS snippet? What’s the name of it and how to use it?