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

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=


 case if you

 auto MyClass x =3D3D new MyClass;

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


 called when leaving scope.

 C


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

 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=

 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=

 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 =




 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

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?

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?

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...

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...

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...

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

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

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

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

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

 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

 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

 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


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


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


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


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


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


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


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...

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



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.

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

 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

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

 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

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


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


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


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


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


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


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


system should support a different garbage collector and deal with


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. I am aware that both Java and C# cannot make that guarantee, but I am pleased to 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