www.digitalmars.com         C & C++   DMDScript  

D - Deterministic Destruction

reply resistor mac.com writes:
Do I remember hearing something around here about D supporting deterministic
destruction?  If so, could someone point me somewhere to find more information
about it?

Thanks, Owen
Mar 29 2004
next sibling parent C <dont respond.com> writes:
I think using the auto keyword gives it to you.

C

On Mon, 29 Mar 2004 18:08:18 +0000 (UTC), <resistor mac.com> wrote:


 Do I remember hearing something around here about D supporting 
 deterministic
 destruction?  If so, could someone point me somewhere to find more 
 information
 about it?

 Thanks, Owen




-- 
D Newsgroup.
Mar 29 2004
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
resistor mac.com wrote:


 Do I remember hearing something around here about D supporting deterministic
 destruction?  If so, could someone point me somewhere to find more information
 about it?
 
 Thanks, Owen
 
 


Do you mean 'Explicit Class Instance Allocation'?
Look at the Memory Management page of the docs. You can make your
own new and delete functions.

Lars Ivar Igesund
Mar 29 2004
parent reply C <dont respond.com> writes:
I think he means knowing when the destructor will get called, in which =

case if you

auto MyClass x =3D new MyClass;

it will allocate it on the stack and your destructor is guaranteed to =

called when leaving scope.

C

On Mon, 29 Mar 2004 22:06:09 +0100, Lars Ivar Igesund =

<larsivar igesund.net> wrote:


 resistor mac.com wrote:


 Do I remember hearing something around here about D supporting =





 deterministic
 destruction?  If so, could someone point me somewhere to find more =





 information
 about it?

 Thanks, Owen


 Do you mean 'Explicit Class Instance Allocation'?
 Look at the Memory Management page of the docs. You can make your
 own new and delete functions.

 Lars Ivar Igesund




-- =

D Newsgroup.
Mar 29 2004
parent reply larry cowan <larry_member pathlink.com> writes:
In article <opr5nagnd5ehmtou localhost>, C says...

I think he means knowing when the destructor will get called, in which =

case if you

auto MyClass x =3D new MyClass;

it will allocate it on the stack and your destructor is guaranteed to =

called when leaving scope.

C


.. But if he means that he wants to force a destruct to return the space
immediately, then he will have to use C's malloc/calloc/free as "extern C", and
even then it will not go back to the system at large until the program
terminates - it stays as part of the process space.  We have discussed this
before.
Current garbage collection doesn't return the space to the OS, and even with
"auto" it waits until the next GC cycle - partly an operating system thing, but
if the pages stay unreferenced they will page out and no real memory will be in
use - only page file size is required.  For small real operating systems without
virtual memory, the problem has not yet been dealt with, but there the operating
system should support a different garbage collector and deal with malloc/free
differently.


On Mon, 29 Mar 2004 22:06:09 +0100, Lars Ivar Igesund =

<larsivar igesund.net> wrote:


 resistor mac.com wrote:


 Do I remember hearing something around here about D supporting =





 deterministic
 destruction?  If so, could someone point me somewhere to find more =





 information
 about it?

 Thanks, Owen


 Do you mean 'Explicit Class Instance Allocation'?
 Look at the Memory Management page of the docs. You can make your
 own new and delete functions.

 Lars Ivar Igesund




-- =

D Newsgroup.
Mar 29 2004
next sibling parent C <dont respond.com> writes:
 Current garbage collection doesn't return the space to the OS


Nor do C/C++, =

http://wwwcgi.rdg.ac.uk:8081/cgi-bin/cgiwrap/wsi14/poplog/man/3C/realloc=
 , =

or non GC systems.


 and even with
 "auto" it waits until the next GC cycle


Hmm , this goes against my understanding, does auto not allocate room on=
 =

the stack ?  Does anyone have the PDF link for the D manual, i cant find=
 =

things on the docs without searching every page.



 For small real operating systems without
 virtual memory, the problem has not yet been dealt with, but there the=


 =


 operating
 system should support a different garbage collector and deal with =



 malloc/free
 differently.


Yes, i think the GC is replaceable, so shouldn't be a problem i dont thi=
nk.

C



On Tue, 30 Mar 2004 00:03:21 +0000 (UTC), larry cowan =

<larry_member pathlink.com> wrote:


 In article <opr5nagnd5ehmtou localhost>, C says...

 I think he means knowing when the destructor will get called, in whic=




h =3D

 case if you

 auto MyClass x =3D3D new MyClass;

 it will allocate it on the stack and your destructor is guaranteed to=




 =3D

 called when leaving scope.

 C


 .. But if he means that he wants to force a destruct to return the spa=


ce

 immediately, then he will have to use C's malloc/calloc/free as "exter=


n =


 C", and
 even then it will not go back to the system at large until the program=



 terminates - it stays as part of the process space.  We have discussed=


 =


 this
 before.
 Current garbage collection doesn't return the space to the OS, and eve=


n =


 with
 "auto" it waits until the next GC cycle - partly an operating system =



 thing, but
 if the pages stay unreferenced they will page out and no real memory =



 will be in
 use - only page file size is required.  For small real operating syste=


ms =


 without
 virtual memory, the problem has not yet been dealt with, but there the=


 =


 operating
 system should support a different garbage collector and deal with =



 malloc/free
 differently.


 On Mon, 29 Mar 2004 22:06:09 +0100, Lars Ivar Igesund =3D

 <larsivar igesund.net> wrote:


 resistor mac.com wrote:


 Do I remember hearing something around here about D supporting =3D





 deterministic
 destruction?  If so, could someone point me somewhere to find more =








=3D

 information
 about it?

 Thanks, Owen


 Do you mean 'Explicit Class Instance Allocation'?
 Look at the Memory Management page of the docs. You can make your
 own new and delete functions.

 Lars Ivar Igesund




 -- =3D

 D Newsgroup.






-- =

D Newsgroup.
Mar 30 2004
prev sibling parent reply resistor mac.com writes:
Actually, I meant is it possible to guarantee the destruction of an object at a
specific time.  Example

Thing t = new Thing();
t.doStuffAndAcquireUniqueResources();
delete t;
t = new Thing();

Is there any way to guarantee that t has been destructed by the time the new t
is created, or does the delete not take effect until the next GC sweep comes
around?

Owen

In article <c4adg9$14g1$1 digitaldaemon.com>, larry cowan says...

In article <opr5nagnd5ehmtou localhost>, C says...

I think he means knowing when the destructor will get called, in which =

case if you

auto MyClass x =3D new MyClass;

it will allocate it on the stack and your destructor is guaranteed to =

called when leaving scope.

C


.. But if he means that he wants to force a destruct to return the space
immediately, then he will have to use C's malloc/calloc/free as "extern C", and
even then it will not go back to the system at large until the program
terminates - it stays as part of the process space.  We have discussed this
before.
Current garbage collection doesn't return the space to the OS, and even with
"auto" it waits until the next GC cycle - partly an operating system thing, but
if the pages stay unreferenced they will page out and no real memory will be in
use - only page file size is required.  For small real operating systems without
virtual memory, the problem has not yet been dealt with, but there the operating
system should support a different garbage collector and deal with malloc/free
differently.


On Mon, 29 Mar 2004 22:06:09 +0100, Lars Ivar Igesund =

<larsivar igesund.net> wrote:


 resistor mac.com wrote:


 Do I remember hearing something around here about D supporting =





 deterministic
 destruction?  If so, could someone point me somewhere to find more =





 information
 about it?

 Thanks, Owen


 Do you mean 'Explicit Class Instance Allocation'?
 Look at the Memory Management page of the docs. You can make your
 own new and delete functions.

 Lars Ivar Igesund




-- =

D Newsgroup.
Mar 30 2004
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
resistor mac.com wrote:


 Actually, I meant is it possible to guarantee the destruction of an object at a
 specific time.  Example
 
 Thing t = new Thing();
 t.doStuffAndAcquireUniqueResources();
 delete t;
 t = new Thing();
 
 Is there any way to guarantee that t has been destructed by the time the new t
 is created, or does the delete not take effect until the next GC sweep comes
 around?


<snip top of upside-down reply>

Of course it destructs there and then.  What else would delete do?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 30 2004
parent reply resistor mac.com writes:
Mark it as destruct-able and wait for the next GC sweep...

Owen

In article <c4c9h8$153b$1 digitaldaemon.com>, Stewart Gordon says...

resistor mac.com wrote:


 Actually, I meant is it possible to guarantee the destruction of an object at a
 specific time.  Example
 
 Thing t = new Thing();
 t.doStuffAndAcquireUniqueResources();
 delete t;
 t = new Thing();
 
 Is there any way to guarantee that t has been destructed by the time the new t
 is created, or does the delete not take effect until the next GC sweep comes
 around?


<snip top of upside-down reply>

Of course it destructs there and then.  What else would delete do?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 30 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
resistor mac.com wrote:


 Mark it as destruct-able and wait for the next GC sweep...


<snip top of upside-down reply>

That's done by removing all references to it.  If delete merely did 
that, then in your example it would have no effect at all, assuming of 
course that your constructor and doStuffAndAcquireUniqueResources don't 
create references to the object that may still be reachable from elsewhere.

The purpose of GC is to determine what's reachable and what isn't, and 
destruct and deallocate what isn't.  If it also served as somewhere to 
postpone explicit destruction, it would be a pointless complexity IMO.

If you use delete, you're supposed to know what you're doing, i.e. that 
there are definitely no further references to the object elsewhere.  In 
which case it will be picked up by the GC anyway.  That's the whole 
point of GC.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 31 2004
parent reply resistor mac.com writes:
It's not a problem of references to the Object, but to resources the object
might acquire.  Suppose for a 
moment that the object is being used for database connections.  Databases only
support a limited 
number of connections at a time, so it's important for me to know for certain
that the connection held 
by the first object has been released by the time the second object is created.
Provided I release the 
connection in the destructor, I need to know if it is guaranteed to be run
before the second object is 
created.  It sounds like this is true, but it was also a possibility that the
object was just marked as 
delete-able and then it waited for the next GC sweep, and in my example this
would not be equivalent.

Owen

In article <c4e5m3$13nb$1 digitaldaemon.com>, Stewart Gordon says...

resistor mac.com wrote:


 Mark it as destruct-able and wait for the next GC sweep...


<snip top of upside-down reply>

That's done by removing all references to it.  If delete merely did 
that, then in your example it would have no effect at all, assuming of 
course that your constructor and doStuffAndAcquireUniqueResources don't 
create references to the object that may still be reachable from elsewhere.

The purpose of GC is to determine what's reachable and what isn't, and 
destruct and deallocate what isn't.  If it also served as somewhere to 
postpone explicit destruction, it would be a pointless complexity IMO.

If you use delete, you're supposed to know what you're doing, i.e. that 
there are definitely no further references to the object elsewhere.  In 
which case it will be picked up by the GC anyway.  That's the whole 
point of GC.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 31 2004
parent reply larry cowan <larry_member pathlink.com> writes:
The garbage collector is simply a memory management tool - it doesn't do things
like actively break connections (though if open, they probably will crash after
the GC has been by if there were no external memory references).  If you need to
do so, write your own delete and do your other resource disconnects there - if
called explicitly the delete will be run when called (doing its thing) and then
the associated memory is marked for the GC to pick up on its next pass.
"Garbage collection kicks in only when memory gets tight. When memory is not
tight, the program runs at full speed and does not spend any time freeing
memory."(Dspec)  If not called explicitly, the GC will eventually do it when
appropriate, or if you make the class auto, the delete will run when the
instance is goes out of scope.

Enough?  

In article <c4f06s$2dvk$1 digitaldaemon.com>, resistor mac.com says...

It's not a problem of references to the Object, but to resources the object
might acquire.  Suppose for a 
moment that the object is being used for database connections.  Databases only
support a limited 
number of connections at a time, so it's important for me to know for certain
that the connection held 
by the first object has been released by the time the second object is created.
Provided I release the 
connection in the destructor, I need to know if it is guaranteed to be run
before the second object is 
created.  It sounds like this is true, but it was also a possibility that the
object was just marked as 
delete-able and then it waited for the next GC sweep, and in my example this
would not be equivalent.

Owen

In article <c4e5m3$13nb$1 digitaldaemon.com>, Stewart Gordon says...

resistor mac.com wrote:


 Mark it as destruct-able and wait for the next GC sweep...


<snip top of upside-down reply>

That's done by removing all references to it.  If delete merely did 
that, then in your example it would have no effect at all, assuming of 
course that your constructor and doStuffAndAcquireUniqueResources don't 
create references to the object that may still be reachable from elsewhere.

The purpose of GC is to determine what's reachable and what isn't, and 
destruct and deallocate what isn't.  If it also served as somewhere to 
postpone explicit destruction, it would be a pointless complexity IMO.

If you use delete, you're supposed to know what you're doing, i.e. that 
there are definitely no further references to the object elsewhere.  In 
which case it will be picked up by the GC anyway.  That's the whole 
point of GC.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 31 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
If you need deterministic release of resources, make the class an auto
class, and D will RAII it for you.

"larry cowan" <larry_member pathlink.com> wrote in message
news:c4f1lv$2gap$1 digitaldaemon.com...

 The garbage collector is simply a memory management tool - it doesn't do


things

 like actively break connections (though if open, they probably will crash


after

 the GC has been by if there were no external memory references).  If you


need to

 do so, write your own delete and do your other resource disconnects


there - if

 called explicitly the delete will be run when called (doing its thing) and


then

 the associated memory is marked for the GC to pick up on its next pass.
 "Garbage collection kicks in only when memory gets tight. When memory is


not

 tight, the program runs at full speed and does not spend any time freeing
 memory."(Dspec)  If not called explicitly, the GC will eventually do it


when

 appropriate, or if you make the class auto, the delete will run when the
 instance is goes out of scope.

 Enough?

 In article <c4f06s$2dvk$1 digitaldaemon.com>, resistor mac.com says...

It's not a problem of references to the Object, but to resources the




object

might acquire.  Suppose for a
moment that the object is being used for database connections.  Databases




only

support a limited
number of connections at a time, so it's important for me to know for




certain

that the connection held
by the first object has been released by the time the second object is




created.

Provided I release the
connection in the destructor, I need to know if it is guaranteed to be




run

before the second object is
created.  It sounds like this is true, but it was also a possibility that




the

object was just marked as
delete-able and then it waited for the next GC sweep, and in my example




this

would not be equivalent.

Owen

In article <c4e5m3$13nb$1 digitaldaemon.com>, Stewart Gordon says...

resistor mac.com wrote:


 Mark it as destruct-able and wait for the next GC sweep...


<snip top of upside-down reply>

That's done by removing all references to it.  If delete merely did
that, then in your example it would have no effect at all, assuming of
course that your constructor and doStuffAndAcquireUniqueResources don't
create references to the object that may still be reachable from






elsewhere.

The purpose of GC is to determine what's reachable and what isn't, and
destruct and deallocate what isn't.  If it also served as somewhere to
postpone explicit destruction, it would be a pointless complexity IMO.

If you use delete, you're supposed to know what you're doing, i.e. that
there are definitely no further references to the object elsewhere.  In
which case it will be picked up by the GC anyway.  That's the whole
point of GC.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.
Apr 02 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Matthew wrote:

 If you need deterministic release of resources, make the class an auto
 class, and D will RAII it for you.


<snip>

You don't need to make the class auto.  You just need to declare object 
references as auto.  Which you'll need to do anyway if you make the 
class auto.

Of course, if you want to make sure that the class uses RAII wherever 
it's used, _then_ you'd declare the class auto.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
on the 'group where everyone may benefit.
Apr 08 2004
prev sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
It'd be easier just to try it out <g>

Explicitly invoking delete on an object does indeed invoke the destructor at
that point in time.

On a related note; some languages (including Java) do not guarantee the
destructor will *ever* be invoked. D is not like that, and the tradeoff is
this: if you have several million live objects when your program exits,
there will be several million destructor calls. I don't think this is
optimized in any way (for classes without an explicit destructor) ... but is
it even worth bothering about?

- Kris


<resistor mac.com> wrote in message news:c4c3o8$rg4$1 digitaldaemon.com...

 Actually, I meant is it possible to guarantee the destruction of an object


at a

 specific time.  Example

 Thing t = new Thing();
 t.doStuffAndAcquireUniqueResources();
 delete t;
 t = new Thing();

 Is there any way to guarantee that t has been destructed by the time the


new t

 is created, or does the delete not take effect until the next GC sweep


comes

 around?

 Owen

 In article <c4adg9$14g1$1 digitaldaemon.com>, larry cowan says...

In article <opr5nagnd5ehmtou localhost>, C says...

I think he means knowing when the destructor will get called, in which =

case if you

auto MyClass x =3D new MyClass;

it will allocate it on the stack and your destructor is guaranteed to =

called when leaving scope.

C


.. But if he means that he wants to force a destruct to return the space
immediately, then he will have to use C's malloc/calloc/free as "extern




C", and

even then it will not go back to the system at large until the program
terminates - it stays as part of the process space.  We have discussed




this

before.
Current garbage collection doesn't return the space to the OS, and even




with

"auto" it waits until the next GC cycle - partly an operating system




thing, but

if the pages stay unreferenced they will page out and no real memory will




be in

use - only page file size is required.  For small real operating systems




without

virtual memory, the problem has not yet been dealt with, but there the




operating

system should support a different garbage collector and deal with




malloc/free

differently.


On Mon, 29 Mar 2004 22:06:09 +0100, Lars Ivar Igesund =

<larsivar igesund.net> wrote:


 resistor mac.com wrote:


 Do I remember hearing something around here about D supporting =





 deterministic
 destruction?  If so, could someone point me somewhere to find more =





 information
 about it?

 Thanks, Owen


 Do you mean 'Explicit Class Instance Allocation'?
 Look at the Memory Management page of the docs. You can make your
 own new and delete functions.

 Lars Ivar Igesund




-- =

D Newsgroup.
Mar 31 2004
parent resistor mac.com writes:
Explicitly invoking delete on an object does indeed invoke the destructor at
that point in time.

On a related note; some languages (including Java) do not guarantee the
destructor will *ever* be invoked. D is not like that, and the tradeoff is
this: if you have several million live objects when your program exits,
there will be several million destructor calls. I don't think this is
optimized in any way (for classes without an explicit destructor) ... but is
it even worth bothering about?


That's exactly what I was asking.  Thanks.


know that D does.  
Like I said, when the object is holding a critical resource (like a database
connection), it is important to 
be able to guarantee that the destructor is being called when I think it is.
You're right that I could just 
make an example for it, but that would not have told me if it was a language
feature or an 
implementation detail.

Owen
Mar 31 2004