View mode: basic / threaded / horizontal-split · Log in · Help
May 22, 2006
when is the object destuctor called?
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.
May 22, 2006
Re: when is the object destuctor called?
"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.
May 22, 2006
Re: when is the object destuctor called?
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
May 22, 2006
Re: when is the object destuctor called?
"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.
May 22, 2006
Re: when is the object destuctor called?
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 +/
May 22, 2006
Re: when is the object destuctor called?
"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.
May 22, 2006
Re: when is the object destuctor called?
> 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.
May 22, 2006
Re: when is the object destuctor called?
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.
May 22, 2006
Re: when is the object destuctor called?
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.
May 22, 2006
Re: when is the object destuctor called?
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 +/
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home