Does the CLR garbage collection methodology mean it's safe to throw circular object references around?

I have a theory that the CLR garbage collection mechanism means that I can get away with circular references in my object hierarchy without creating deadlocks for teardown and garbage collection. Is this a safe a开发者_Go百科ssumption to make? (Target language VB.NET)

---

The .NET garbage collector is a generational mark and sweep collector. It does not use reference counting. So yes, it's safe to have circular references. Language is irrelevant

---

As per this article: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5109829.html

Circular reference is a problem that occurs when there are two objects that refer to each other. Let's say you have Class A that refers to Class B. If Class B also refers to Class A, then we have a circular reference. This happens in many situations. A typical example for this is a parent-child relationship between objects, where the child interacts with the parent object and also holds a reference to the parent object. This could lead to objects that would not get cleaned up until the application was shut down. The .NET way of garbage collection solves the problem of circular reference because the garbage collector is able to clean up any object that is reachable from the root.

EDIT:
Judging from this post: http://blogs.msdn.com/abhinaba/archive/2009/01/27/back-to-basics-reference-counting-garbage-collection.aspx it seems that .Net's garbage collection is not based on reference counting for garbage collection.

Another article worth reading (explains Garbage collection in detail) is this one: http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/