Garbage collectors suck for games

Thanks, I understand now. Let me ask you why exactly do you need to know which instance created which other instance? Which problems would it solve? I recognise the value in determining object life-time, etc. but aside from plumbing what are the advantages you are thinking about. See below, calling unmanaged code.

Hate COM. But WCF, WPF, even WinForms in some places are highly abstract so some measure of dynamic type validation must happen.

Sure, no argument there but I doubt any other framework of this size and capability is much better heh. Btw, have you looked at .NET 4 in this regard?

I haven't had many opportunities/need to employ P/Invoke and marshalling. Mostly because any time I have to look at MFC and even SDK code I get flashbacks to the bad c++ days. I mostly use it for the 7/Vista bling-bling MS keeps leaving out of WinForms. Since you need lower level access, you'll definitely require more flexibility and more information on the object tree.

I take it you don't like having to debug why your program crashes reading from disk with a null exception only 10% of the time. Dispose is Chaotic Evil. I'd rather have objects taking up memory, than trying to subvert the GC and blowing up in my face!

Physical RAM? How odd.

 

Just anote on the .net GC, unmanaged interop and memory usage.

My biggest problem is the totally passive way it does collection, it will wait until it gets within some threshold of the limit before freeing objects.

You can actually restrict the maximum ammount of memory the .Net runtime will use, but you have to write a host. It's <100 lines of C++.

If the runtime was killed it was because it couldn't allocate enough memoy for the "Out Of Memory" exception to be thrown. This means that the GC could not free any memory, so you had a leak.

If you're making calls into unmanaged code, especially through COM interop with pinned memory, it's extremely easy to write leaks, they are extremely hard to track down.

Having had to write COM wrappers for external libraries, it's astonishing to me how PInvoke just works most of the time.

 

Except it doesn't happen, the OutOfMemoryException is singleton it won't fail to be thrown, any unhandled exception will cause Windows to terminate it, even an OutOfMemoryException in the handler of a OutOfMemoryException wich tried to allocate a new object.

 

Introducing a global parent property would be highway one into leak hell. In order to have an object safely collected by the GC you would have to delete all references to that object and null the owner property. As long as ownership is clear that might not be a problem, but when objects start getting passed around between domain code, framework code and third-party libraries things would get ugly in no time. And I haven't even mentioned the non-obvious cases like anonymous delegates that get passed around. So, sorry, but dumb idea.

And what do you mean with "it uses reflection instead"? Where does .NET use reflection in order to find an owner object?

Sounds like a leak to me.

You can actually influence (lower) the threshold by calling GC.AddMemoryPressure(). It's far from perfect, but it's a start.

 

UnrealScript?

There is no denying you have to treat a garbage collected language differently.

All my experience with .net is that memory isn't your problem unless you have done something badly wrong, whereas (for example) managed<->unmanaged transitions will kill performance.

 

Is that dificult to pass "this" as a parameter during object creation?

I don't know how complex .docx are (other say they are ridiculous complex tought) and even if there is the need for children objects to comunicate to parents by means other than return values and exceptions, letting the children to have a reference to a parent is something I usually avoid for several reasons and so I see several reason to this not be the default behavior.

 

It could perhaps be more explicit, but I would assume that returning a smart pointer is handing off ownership (or at least offering it), returning a ref is not. I think the semantic suggestion here is probably just as valuable as the functionality.

 

The issue is that returning a smart pointer often isn't handing off ownership, it's just returning a smart pointer. Any none trivial set of structures will usually result in smart pointers creating ref loops, because they tend to be used as safe references in classes rather than actual indicators of strong ownership.

With garbage collectors there is no real delineation between strong ownership and just references to the object, because ref loops don't generally cause leaks (though it's quite possible to write leaks). I do agree that it's still important to understand ownership at a semantic level even in a GC language.

I personally work around the ownership issue in C/C++ by using API conventions, if a function takes a ** to a class as an output it's assumed the caller is responsible for cleanup, otherwise the creator is responsible for cleanup.

I've wasted more hours of my life cleaning up dangling pointer bugs than I would care to count, it's too easy a bug to write, has often totally random symptoms and often extremly difficult to find.

 

How?

 

Dangling references that trace back to top level references.

 

And how this would happen? I mean, in a decent GC?

 

No it's not a GC error, it's a user error.
The classic one is someone creates a manager class of some sort, and never removes things from the manager. The manager retains a ref, even though the resource is no longer in use. You can argue whether it's the same sort of leak or not. But the effect is the same, something that is no longer in use hangs around indefinitely.

 

I'm clearly missing some nuance of the discussion here, but why not dynamic_cast in this situation? You are trying to ref the parent, correct?

 

About garbage collection and performance:

1) Reference counting has big performance overhead
Every time you are taking new refs to object or removing ref, you have overhead. When doing function calls with the obejcts you practically always do it. And as the overhead of removing a ref includes if (refcount == 0) brach, it's much worse for performance than simple update of value.

And if you try to use ref counting with objects that were not designed for it(not derived from some recountable base class/template), you have to add an additional intermediate layer which means you have 2-level memory references which makes those objects slower to use.

2) generational garbage collection makes memory allocation much faster.
If you have a generational garbage collection, malloc() is just one addition and comparison (actually the whole malloc overhead is same as the overhead of removing reference when ref counting)

3) There are real-time garbage collectors.
If you are using real-time garbage collector, there are NONE of those "GC pauses" people seem to be so afraid of.

 

Fight slight slowdown with much bigger slowdown?