[.net] Forgive my ignorance but shouldn't it implemented a reference counter?

Started by
19 comments, last by Talonius 18 years, 1 month ago
Quote:Original post by Vexorian
The question was: Why the lack of an "auto destroy object when nothing is referencing to it" system?

Because the garbage collector knows what its doing. The whole idea is that you don't worry about garbage collection in general, you just get things working. By adding a second type of garbage collection, you greatly increase the complexity of the programs, which removes the entire reason for it to exist in the first place.

Also, keep in mind that deallocation isn't free. Whenever possible, you want to deallocate lots of memory all at once, it stands to make later allocations cheaper.

CM
Advertisement
Well, I guess it is possible to implement a reference counting & releasing object by using unsafe code...

But I am sure you are better of with assuming the GC is smarter than you ;)
Also, the way .NET is built, you can't simply collect a single object and leave it at that. An entire generation needs to be resolved at once.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
My master's thesis: Introducing reference counting into the Common Language Runtime.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
Quote:Original post by Vexorian
I am having some problems memory management aside.

Are you actually having problems or do you just think you have problems?

--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
Also realize that C# ~MyClass() is not the same as a C++ ~MyClass(). The former is a finalizer, and results in the object getting queued up and the finalizer executed in a separate thread at an undetermined time. A C++ destructor, in contrast, is executed in a much more deterministic manner (at the end of scope, upon delete, etc.).

Read this excellent MSDN blog post by Rico Mariani for more information.

Quote:the Employee Object created there is only pointed by the e variable and I eventually set e to null. According to my logic the framework should note that there is nothing pointing to that employee and free the memory .

But it doesn't, the object is destroyed once the program ends.


Based on the blog post, the mere act of adding a finalizer will cause the Employee object to be promoted to the next generation, which is collected less frequently.

If you're truly having performance problems (i.e. you're experiencing actual slowdowns while playing your game), use CLR Profiler or some other performance measuring tool to find out where the problems are. Don't waste time guessing. Instead, have fun coding :D

Quote:Original post by Arild Fines
My master's thesis: Introducing reference counting into the Common Language Runtime.


That is AMAZING Arild! You are so clever! is greatly humbled by his gracious presence
A couple more comments, and I'm sure you're not going to like this :)

From my understanding one way to write games under .Net is to avoid having the garbage collector coming up at all. Tricks involve keeping things in the stack by using unboxed structures rather than reference types, and reusing allocated reference elements rather than allocating new ones.

I remember a while ago in VB 2002 that I was scratching my head trying to figure out why didn't the garbage collector clean up an object from which I had removed all references to from my code and then called gc.collect (with different generation levels, and several times)

It turned out that an optimization had created a copy of the variable that had originally pointed to the object, and that copy was just being allowed to fall out of scope and stack at the end of the method, but obviously I had code in the same method waiting for the destruction of the object :).

Basically, this is hard to accept, and kind of a philosophical step, but it seems to be easier to accept garbage collection as not being predictable, and code accordingly, expecting either slowdowns (which can be acceptable in non real time games, such as board games), or avoiding it at all.
who has seen actual freezes in a game when the garbage collector runs?

i have not, and the gc runs quite often in my game due to lazy coding.
Quote:Original post by Arild Fines
Quote:Original post by Vexorian
I am having some problems memory management aside.

Are you actually having problems or do you just think you have problems?


It seems my language module was not working at all yesterday, the thread's title is senseless and I actually said that.

What I meant in the beginning is that I loved C# features but I was having problems to understand/like its memory management.

After some explanations I was convinced that it was not such a bad problem as I thought.

cody: I have seen it happen in one of the first .net demo programs I've seen. It was one of SDL.net demos which dealt with GUI and fonts, in some of its section moving fonts caused a very large memory usage and eventually the demo kept freezing and freezing constantly.

I now think that it was a problem with the demo's code and that it should be possible to avoid those.

I am into 2D puzzle games anyways so I don't really need the fastest performance ever. My prediction is that .net will keep getting faster and it would probably be much faster in vista which everybody will have to get because it is going to be the only OS with directx 10
------ XYE - A new edition of the classic Kye

This topic is closed to new replies.

Advertisement