www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Enforced nogc for dtors?

reply "bearophile" <bearophileHUGS lycos.com> writes:
If we keep class destructors in D, is it a good idea to require 
them to be  nogc?

This post comes after this thread in D.learn:
http://forum.dlang.org/thread/vlnjgtdmyolgoiofnfnl forum.dlang.org

Bye,
bearophile
May 04 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 4 May 2014 at 20:49:57 UTC, bearophile wrote:
 If we keep class destructors in D, is it a good idea to require 
 them to be  nogc?

 This post comes after this thread in D.learn:
 http://forum.dlang.org/thread/vlnjgtdmyolgoiofnfnl forum.dlang.org

 Bye,
 bearophile
Not sure that would be a good idea: "nogc" means "no interacting with the GC". In no way does it prevent accessing a ressource that itself is managed by the GC, which is what the original bug was about. Furthermore, classes *may* be deterministically desroyed, and preventing it from interacting with the GC, if only to remove scan pointers (think RefCounted/Array) would be needlessly restrictive.
May 05 2014
parent reply Orvid King via Digitalmars-d <digitalmars-d puremagic.com> writes:
Also, the  nogc for destructors is specific to the current GC, and is
a limitation that isn't really needed were destructors implemented
properly in the current GC.

On 5/5/14, monarch_dodra via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 On Sunday, 4 May 2014 at 20:49:57 UTC, bearophile wrote:
 If we keep class destructors in D, is it a good idea to require
 them to be  nogc?

 This post comes after this thread in D.learn:
 http://forum.dlang.org/thread/vlnjgtdmyolgoiofnfnl forum.dlang.org

 Bye,
 bearophile
Not sure that would be a good idea: "nogc" means "no interacting with the GC". In no way does it prevent accessing a ressource that itself is managed by the GC, which is what the original bug was about. Furthermore, classes *may* be deterministically desroyed, and preventing it from interacting with the GC, if only to remove scan pointers (think RefCounted/Array) would be needlessly restrictive.
May 05 2014
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Monday, 5 May 2014 at 14:17:04 UTC, Orvid King via 
Digitalmars-d wrote:
 Also, the  nogc for destructors is specific to the current GC, 
 and is a limitation that isn't really needed were destructors 
 implemented properly in the current GC.
How does one implement destructors (described below) properly in a garbage collector? I'm a bit puzzled by the recent storm over destructors. I think of garbage collected entities (classes in Java) as possibly having "finalizers", and scoped things as possibly having "destructors". The two concepts are related but distinct. Destructors are supposed to be deterministic, finalizers by being tied to a tracing GC are not. Java doesn't have stack allocated objects, but since 1.7 has try-'with resources' and AutoCloseable to cover some cases in RAII-like fashion. My terminology is from this http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html IMO, since D has a GC, and stack allocated structs, it would make sense to use different terms for destruction and finalization, so what you really want is to properly implement finalizers in your GC. I'm a lot more reluctant to use classes in D now, and I'd like to see a lot more code with nogc or compiled with a the previously discussed and rejected no runtime switch. Interestingly, Ada finalization via 'controlled' types is actually what we call destructors here. The Ada approach is interesting, but I don't know if a similar approach would fit well with D, which is a much more pointer intensive language.
May 05 2014
parent reply Orvid King via Digitalmars-d <digitalmars-d puremagic.com> writes:
The current GC cannot allocate within a destructor because of the fact
that it has to acquire a global lock on the GC before calling the
actual destructor, meaning that attempting to allocate or do anything
that requires a global lock on the GC is impossible, because the lock
has already been acquired by the thread. Admittedly this isn't the way
it actually fails, but it is the flaw in the design that causes it to
fail.

Destructors and finalizers are the same thing. They are declared the
same, function the same, and do the same things. In D, the
deterministic invocation of a destructor is a side-effect of the
optimization of allocations to occur on the stack rather than the
heap, whether this is done by the user by declaring a value a struct,
or by the compiler when it determines the value never escapes the
scope. Currently the GC doesn't invoke the destructor of a struct that
has been heap allocated, but I view this as a bug, because it is the
same thing as if it had been declared as a class instead, and a
destructor must take this into account, and not be dependent on the
deterministic destruction qualities of stack-allocated values.

On 5/5/14, Brian Rogoff via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 On Monday, 5 May 2014 at 14:17:04 UTC, Orvid King via
 Digitalmars-d wrote:
 Also, the  nogc for destructors is specific to the current GC,
 and is a limitation that isn't really needed were destructors
 implemented properly in the current GC.
How does one implement destructors (described below) properly in a garbage collector? I'm a bit puzzled by the recent storm over destructors. I think of garbage collected entities (classes in Java) as possibly having "finalizers", and scoped things as possibly having "destructors". The two concepts are related but distinct. Destructors are supposed to be deterministic, finalizers by being tied to a tracing GC are not. Java doesn't have stack allocated objects, but since 1.7 has try-'with resources' and AutoCloseable to cover some cases in RAII-like fashion. My terminology is from this http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html IMO, since D has a GC, and stack allocated structs, it would make sense to use different terms for destruction and finalization, so what you really want is to properly implement finalizers in your GC. I'm a lot more reluctant to use classes in D now, and I'd like to see a lot more code with nogc or compiled with a the previously discussed and rejected no runtime switch. Interestingly, Ada finalization via 'controlled' types is actually what we call destructors here. The Ada approach is interesting, but I don't know if a similar approach would fit well with D, which is a much more pointer intensive language.
May 05 2014
next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via 
Digitalmars-d wrote:
 Destructors and finalizers are the same thing.
That is exactly the point that I am arguing against. That they are confused in D (or 'unified', if you think is a good thing) I accept, but I think it's a language design error, or at least an unfortunate omission. Did you read the citation I provided? I think Boehm's argument is convincing; you've provided no rebuttal. The entire brouhaha going on now is because they're different: we assume that destructors will be called at a precise time so we can use them to manage constrained resources and we don't know that about finalizers.
May 05 2014
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 5 May 2014 at 18:32:30 UTC, Brian Rogoff wrote:
 On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via 
 Digitalmars-d wrote:
 Destructors and finalizers are the same thing.
That is exactly the point that I am arguing against. That they are confused in D (or 'unified', if you think is a good thing) I accept, but I think it's a language design error, or at least an unfortunate omission. Did you read the citation I provided? I think Boehm's argument is convincing; you've provided no rebuttal. The entire brouhaha going on now is because they're different: we assume that destructors will be called at a precise time so we can use them to manage constrained resources and we don't know that about finalizers.
+1
May 06 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 May 2014 at 18:32:30 UTC, Brian Rogoff wrote:
 On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via 
 Digitalmars-d wrote:
 Destructors and finalizers are the same thing.
That is exactly the point that I am arguing against. That they are confused in D (or 'unified', if you think is a good thing) I accept, but I think it's a language design error, or at least an unfortunate omission.
Yes, if the compiler doesn't know the conceptual parent-child relationship. e.g.: the parent-connection may close before the child-transaction has flushed/commited. In order to prevent this you can introduce (or deduce if you have the semantics of ownership) parent-pointers from child to parent and only allow parent roots to have their destructors called. The result is that the parent-root-tree is not released until all destructible children are ready. Having class objects on a separate heap with finalizer support could be reasonable if the class construct is viewed as an application-level construct and not a system-level construct. With a dedicated finalizer datastructure you can record finalization dependencies at the cost of a heavier runtime. However, I think not calling destructors at all for GC memory is the better (more nimble) approach for a system level programming language. *shrug*
May 06 2014
parent reply Orvid King via Digitalmars-d <digitalmars-d puremagic.com> writes:
I actually don't think finalizers are an issue in the GC, but I do
agree that there should be a way to ensure that a value is
deterministically finalized. The thing is though, that's currently
possible by simply declaring the value as a struct, unless it's been
heap allocated, in which case we do the best we can.

On 5/6/14, via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 On Monday, 5 May 2014 at 18:32:30 UTC, Brian Rogoff wrote:
 On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via
 Digitalmars-d wrote:
 Destructors and finalizers are the same thing.
That is exactly the point that I am arguing against. That they are confused in D (or 'unified', if you think is a good thing) I accept, but I think it's a language design error, or at least an unfortunate omission.
Yes, if the compiler doesn't know the conceptual parent-child relationship. e.g.: the parent-connection may close before the child-transaction has flushed/commited. In order to prevent this you can introduce (or deduce if you have the semantics of ownership) parent-pointers from child to parent and only allow parent roots to have their destructors called. The result is that the parent-root-tree is not released until all destructible children are ready. Having class objects on a separate heap with finalizer support could be reasonable if the class construct is viewed as an application-level construct and not a system-level construct. With a dedicated finalizer datastructure you can record finalization dependencies at the cost of a heavier runtime. However, I think not calling destructors at all for GC memory is the better (more nimble) approach for a system level programming language. *shrug*
May 06 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 6 May 2014 at 12:36:04 UTC, Orvid King via 
Digitalmars-d wrote:
 possible by simply declaring the value as a struct, unless it's 
 been heap allocated, in which case we do the best we can.
Best effort is worse than no effort...
May 06 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 05.05.2014 19:46, schrieb Orvid King via Digitalmars-d:
 The current GC cannot allocate within a destructor because of the fact
 that it has to acquire a global lock on the GC before calling the
 actual destructor, meaning that attempting to allocate or do anything
 that requires a global lock on the GC is impossible, because the lock
 has already been acquired by the thread. Admittedly this isn't the way
 it actually fails, but it is the flaw in the design that causes it to
 fail.
This is precisely the point. I see this whole discussion as going around in circles instead of fixing the GC. Which is fine, assuming that at the end of the day, D gets a sound automatic memory management model, be it RC/GC/compiler dataflow based, which doesn't keep be questioned all the time. Otherwise, I see this as the second coming of Tango vs Phobos. -- Paulo
May 05 2014