Need help with finalization issue.

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

John - 02 Sep 2006 02:51 GMT

I have a scene graph where geometry nodes contain references to shared
geometry data. Imagine a graph where there's several instances of a
barrel; each barrel has its own 3D transform and a reference to the same
geometry object. This geometry object in turn references the index and
vertex buffers for the geometry.

Now, I want to delete some of these barrels. I simply dereference these
objects no problem. If I want, I can call IDispose.Dispose() on them.
The problem comes in where I want to know when there are no more barrels
so that I can call Dispose on my vertex and index buffer! I can not
figure out a way to do this except to actually add some type of
reference counting in the geometry data object itself and keep track of
that manually, and I'm not even sure that'll work. Of course I have
this same issue not just with the index and vertex buffers but with
textures as well.

I fear that if I need to use reference counting, that almost entirely
defeats the purpose of using the .net framework in the first place. So,
I'm trying to figure out the correct pattern to solve this problem
without switching to C++.

Thoughts?

Reply to this Message

Jon Shemitz - 02 Sep 2006 04:47 GMT

> The problem comes in where I want to know when there are no more barrels
> so that I can call Dispose on my vertex and index buffer! I can not
> figure out a way to do this except to actually add some type of
> reference counting in the geometry data object itself and keep track of
> that manually, and I'm not even sure that'll work.

One obvious alternative is to use double linking: every geometry
object contains a list of nodes that that refer to it. (Of course,
this is basically just a more expensive form of reference counting.)

> I fear that if I need to use reference counting, that almost entirely
> defeats the purpose of using the .net framework in the first place. So,
> I'm trying to figure out the correct pattern to solve this problem
> without switching to C++.

Do you really need to Dispose of these geometry objects at all? Once
there are no references to a given geometry object, the gc will
reclaim it - and its vertex and index buffers. You don't need to call
Dispose to free memory; you only need to Dispose to do things like
closing handles.

Signature

.NET 2.0 for Delphi Programmers www.midnightbeach.com/.net
Delphi skills make .NET easy to learn Great reviews & good sales.

Reply to this Message

John - 02 Sep 2006 05:14 GMT

>> The problem comes in where I want to know when there are no more barrels
>> so that I can call Dispose on my vertex and index buffer! I can not
[quoted text clipped - 16 lines]
> Dispose to free memory; you only need to Dispose to do things like
> closing handles.

Hi Jon -

Thanks for the reply.

Sadly, my example is simplified. In reality, I'm trying to unload a
substantial amount of geometry so that I can load in lower
level-of-detail models, and loading in entirely new pieces of geometry.
This requires me to unload the unused geometry immediately, otherwise
the video card will just run out of memory. Since I can't tell if the
geometry data object is still needed, I can't unload it.

The GC doesn't seem to realize that it needs to unload some of this
stuff because the objects seem to have much smaller memory footprints
than they actually do, and even if the GC did know how big they are it
doesn't understand that there are seperate memory resource pools. Also
calling GC::Collect() doesn't seem to be cleaning them up either.

- John

Reply to this Message

Barry Kelly - 02 Sep 2006 15:52 GMT

> The GC doesn't seem to realize that it needs to unload some of this
> stuff because the objects seem to have much smaller memory footprints
> than they actually do

BTW, this is the reason for GC.AddMemoryPressure() and
GC.RemoveMemoryPressure() in .NET 2. You have to tell the GC in your
constructor / reallocate / finalize methods.

> and even if the GC did know how big they are it
> doesn't understand that there are seperate memory resource pools.

> Also
> calling GC::Collect() doesn't seem to be cleaning them up either.

I'm not sure exactly what this refers to: do you mean that your objects
are being kept alive from somewhere? Or does it mean that you haven't
implemented finalization on your objects properly?

FWIW, manual resource management hasn't gone away. When the resource
isn't managed memory, you've still got to do it yourself, using
IDisposable, 'using', C++/CLI & smart pointers & RAII, etc. To get good
performance in a number of scenarios I've found it necessary to reinvent
the memory allocator etc. YMMV.

-- Barry

Signature

http://barrkel.blogspot.com/

Reply to this Message

Jon Shemitz - 02 Sep 2006 17:10 GMT

> Sadly, my example is simplified. In reality, I'm trying to unload a
> substantial amount of geometry so that I can load in lower
> level-of-detail models, and loading in entirely new pieces of geometry.
> This requires me to unload the unused geometry immediately, otherwise
> the video card will just run out of memory. Since I can't tell if the
> geometry data object is still needed, I can't unload it.

In other words, you have to do some cleanup on the video card when you
are done with a geometry object?

If all the vertex and index buffers are actually unmanaged resources
on the video card, one alternative to reference counting is to rely on
finalizers. Normally, this is an expensive no-no, but if resurrection
costs are low (because the geometry objects contain no references to
other managed memory) finalization may be cheaper and more reliable
than reference counting, and the biggest issue may be the lag between
delinking a geometry object and actually freeing the associated video
memory.

> The GC doesn't seem to realize that it needs to unload some of this
> stuff because the objects seem to have much smaller memory footprints
> than they actually do, and even if the GC did know how big they are it
> doesn't understand that there are seperate memory resource pools. Also
> calling GC::Collect() doesn't seem to be cleaning them up either.

I'm not at all sure what you mean, here: the gc is very good at
tracing dependencies, and WILL reclaim a whole object graph when you
no longer refer to the root.

Signature

.NET 2.0 for Delphi Programmers www.midnightbeach.com/.net
Delphi skills make .NET easy to learn Great reviews & good sales.

Reply to this Message

Rate this thread:

Need help with finalization issue.

Free Magazines