I came across this sentence in the specification

"The garbage collector is not guaranteed to run the destructor for all unreferenced objects."

This made me wonder in what circumstances the destructor WONT bee called.
Basically I want to do this: An object stores a OpenGL texture (uint) and when the object gets collected/deleted I want to free the texture. I don't care about if the destructor will bee called on program exit, but I need some mechanism for freeing the textures during normal execution to prevent a video memory leak.

So I need to know if I can trust the destructor to do this or it their is some other mechanism I can use.

"Johan Granberg" <lijat.meREM@OVEgmail.com> wrote in message news:e4sj2e$43o$1@digitaldaemon.com...

> This made me wonder in what circumstances the destructor WONT bee called.

That's a bit difficult.  If you do something like this:

Crap c;

class Crap
{
 this()
 {
  writefln("ctor");
 }

 ~this()
 {
  writefln("dtor");
 }
}

static this()
{
 c = new Crap();
}

void main()
{

}

The dtor is never called.  It seems that any kind of global or static references (kept like this or kept in arrays / AAs) are never collected at the end of a program - this seems to be a bug.  It might not be, though, as Walter has said before that he doesn't believe that dtors should be called at the end of the program, as the OS will reclaim all the memory for the objects anyway.  I call this BS, as any non-trivial program will hold resources _other_ than memory, and will have to release external resources (like video resources, file handles, databases, etc).  In this case, he says to use RAII, but that's not a solution to things like this.

But if you call "delete" on an object, the dtor is called _right then_. Which is how I solved the problem.


> Basically I want to do this: An object stores a OpenGL texture (uint) and when the object gets collected/deleted I want to free the texture. I don't care about if the destructor will bee called on program exit, but I need some mechanism for freeing the textures during normal execution to prevent a video memory leak.
>
> So I need to know if I can trust the destructor to do this or it their is some other mechanism I can use.

I do a very similar thing, but in DirectX instead of OpenGL.  Basically, I keep an AA of all the instances of a resource-holding class (such as a texture class):

class Texture
{
    this()
    {
        // acquire texture interface
        textures[this] = this;
    }

    ~this()
    {
        // release texture interface
        textures.remove(this);
    }

    static Texture[Texture] textures;
}

Then, I have a static dtor which loops through all the textures and deletes them.

static this()
{
    foreach(Texture t; textures)
        delete t;
}

All instances are deleted.

This works well, and if the GC behavior is ever changed, this mechanism will still work.

On Tue, 23 May 2006 01:59:14 +1000, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:



> Then, I have a static dtor which loops through all the textures and deletes them.

I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.

-- 
Derek Parnell
Melbourne, Australia

"Johan Granberg" <lijat.meREM@OVEgmail.com> wrote in message news:e4sj2e$43o$1@digitaldaemon.com...
>I came across this sentence in the specification
>
> "The garbage collector is not guaranteed to run the destructor for all unreferenced objects."
>
> This made me wonder in what circumstances the destructor WONT bee called. Basically I want to do this: An object stores a OpenGL texture (uint) and when the object gets collected/deleted I want to free the texture. I don't care about if the destructor will bee called on program exit, but I need some mechanism for freeing the textures during normal execution to prevent a video memory leak.
>
> So I need to know if I can trust the destructor to do this or it their is some other mechanism I can use.

Personally I would not rely on the using the GC to manage anything other
than main memory. Why? If the user doubles their main memory but doesn't
change their graphics memory then the GC might decide to collect object less
often (since there's much more memory around) and so the graphics memory
fill up before the GC decides it needs to do a collection. The GC should
only be used to mange what it knows about: main memory. Anything else is a
latent bug that depends on the end user's system configuration.
Note that's actually why I don't have any destructors in Cx - they lull
programmers into a false sense of security. In Cx the GC manages main memory
and any other resource needs to be managed by the programmer.

Derek Parnell wrote:
> On Tue, 23 May 2006 01:59:14 +1000, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>> Then, I have a static dtor which loops through all the textures and deletes them.
> 
> I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.

IIRC, Walter's point was that objects that hold some important resources should be manually memory-managed anyway. The GC is not guaranteed to delete any objects, even these which aren't pointed to from a global reference. This is because of the way the GC works. Maybe with a next GC incarnation (e.g. a compacting one) *hint*, *hint*, we'll get stronger guarantees ;)

As for the texture example, they should be freed by some sort of a manager anyway - they have to be released before the rendering device anyway...

Oh, and a question to Jarrett: why are you holding textures in an associative array ? Just to be able to release textures in a O(log n) time ? If so, how about a double - linked list, like the one Chris presented recently on D.announce ? The AA seems weird :P


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

"Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message news:e4spkf$bq7$1@digitaldaemon.com...

> Oh, and a question to Jarrett: why are you holding textures in an associative array ? Just to be able to release textures in a O(log n) time ? If so, how about a double - linked list, like the one Chris presented recently on D.announce ? The AA seems weird :P

Fast insert, fast delete, easy to loop through, and most of all, it's built-in ;)  It's just how I implement a "set" with AAs - that is, no order necessary, just to keep track of all the items created and to be able to loop through them all.

> static this()
> {
>    foreach(Texture t; textures)
>        delete t;
> }
>
> All instances are deleted.
>
> This works well, and if the GC behavior is ever changed, this mechanism will still work.

Except there's the large downside that the textures will *only* be freed at program exit. If you delete one of the objects by hand you'll try to delete it again at exit which is an error and the GC will never collect the object since it is always referenced by the static array.

a correction to my post:

> If you delete one of the objects by hand you'll try to delete it again at exit which is an error

I missed the dtor that was removing the reference from the static AA.

Tom S wrote:
> Derek Parnell wrote:
>> I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.
Agrees.
> As for the texture example, they should be freed by some sort of a manager anyway - they have to be released before the rendering device anyway...
Ok I think I get it. The destructors should only bee used when objects is deleted manually. right?

But the answers in the thread raises another question.

> - they have to be released before the rendering device anyway...
Does this implies that the operating system does not reclaim video memory
at program exit? I have assumed that was the case but the answers in this thread left me uncertain.

Thanks for answering everybody.

Johan Granberg wrote:
> Tom S wrote:
>> Derek Parnell wrote:
>>> I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.
> Agrees.
>> As for the texture example, they should be freed by some sort of a manager anyway - they have to be released before the rendering device anyway...
> Ok I think I get it. The destructors should only bee used when objects is deleted manually. right?

That's what I'm doing. Otherwise dtors are just unreliable...


>> - they have to be released before the rendering device anyway...
> Does this implies that the operating system does not reclaim video memory
> at program exit? I have assumed that was the case but the answers in this thread left me uncertain.

From my experience, not all OSes do that... I've seen a few crashes due to the GPU running out of texture memory ;D


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/