May 24, 2012
On Thu, 2012-05-24 at 09:38 -0400, Steven Schveighoffer wrote: [...]
> However, I'd tend to believe Java implementations will attempt to invoke all finalizers of objects left on the heap at program shutdown.

As far as I am aware Java implementations do no finalization on exit unless System.runFinalizersOnExit(true) has been called. This method is deprecated since it can cause incorrect finalization. But like all things Java that have been deprecated, they never actually go away.

There is System.runFinalization() which executes finalize on all objects in the pending finalization queue.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


May 24, 2012
On 24-05-2012 14:48, Thor wrote:
> On Thursday, 24 May 2012 at 12:38:45 UTC, Alex Rønne Petersen wrote:
>> On 24-05-2012 14:33, Thor wrote:
>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> http://dlang.org/class.html#Destructor
>>>>
>>>> "The garbage collector is not guaranteed to run the destructor for all
>>>> unreferenced objects."
>>>>
>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>> programmer has to actually expect this to happen?
>>>>
>>>> I really, really hope that this is a documentation error or early
>>>> design decision that has since been rectified but with lack of
>>>> documentation updates.
>>>
>>> use "clear", or "scope (exit)" or "structs" or scoped!... etc.
>>
>> I know.
>>
>>>
>>> There could always be a false reference... so you cannot depend on
>>> automatically releasing resources in a class destructor.
>>>
>>
>> False pointers have nothing to do with it. The GC should free and
>> finalize all objects on shutdown, meaning the finalizer runs *sooner
>> or later*. If this is the case (which I do believe it is), then the
>> docs are very wrong.
>
> __gshared uint my_false_ptr;
>
> even if we are shutting down, the static references doesn't disappear...
> or did I miss something?
>

The GC should (and probably does) assume at shutdown that all objects are unreferenced, and therefore reclaim and finalize them.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 24, 2012
On 24-05-2012 15:49, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix@gmail.com> wrote:
>
>> Le 24/05/2012 14:54, Peter Alexander a écrit :
>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> http://dlang.org/class.html#Destructor
>>>>
>>>> "The garbage collector is not guaranteed to run the destructor for all
>>>> unreferenced objects."
>>>>
>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>> programmer has to actually expect this to happen?
>>>>
>>>> I really, really hope that this is a documentation error or early
>>>> design decision that has since been rectified but with lack of
>>>> documentation updates.
>>>
>>> I'm pretty sure it's the same in Java.
>>>
>>> Finalizers (a.k.a. class destructors) are practically useless.
>>
>> Java finalizer is a pretty bad design decision. Let's not reproduce
>> error made in Java in D's destructors.
>
> You actually need a finalizer if you want to have resources that aren't
> GC allocated.
>
> -Steve

But that doesn't mean we should have Java finalization. There are many different forms of finalization, and I do agree that Java is the worst of all of them.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 24, 2012
On 24-05-2012 14:43, Michel Fortin wrote:
> On 2012-05-24 12:21:01 +0000, Alex Rønne Petersen <alex@lycus.org> said:
>
>> Hi,
>>
>> http://dlang.org/class.html#Destructor
>>
>> "The garbage collector is not guaranteed to run the destructor for all
>> unreferenced objects."
>>
>> What the *hell*? So resources are allowed to arbitrarily leak and the
>> programmer has to actually expect this to happen?
>>
>> I really, really hope that this is a documentation error or early
>> design decision that has since been rectified but with lack of
>> documentation updates.
>
> I think it means that objects not collected when the program terminates
> will never be, and thus the destructor will not be called.

That's silly. Microsoft .NET and Mono have been running finalizers on runtime shutdown for a long time without problems.

>
> There's also the issue of false pointers that can prevent some objects
> from being collected.

Right, but I think if we guarantee finalization at shutdown, that shouldn't matter.

>
> More generally, you can't really count on the destructor being called
> because the GC is free to decide when to recycle memory. An
> implementation that never collects and always allocate new memory is a
> perfectly valid GC implementation, even though it might not be very
> practical in most cases.
>

Even such an implementation should free all memory at shutdown, and, at that point, run finalizers.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 24, 2012
On 24-05-2012 15:38, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 08:54:45 -0400, Peter Alexander
> <peter.alexander.au@gmail.com> wrote:
>
>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>> Hi,
>>>
>>> http://dlang.org/class.html#Destructor
>>>
>>> "The garbage collector is not guaranteed to run the destructor for
>>> all unreferenced objects."
>>>
>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>> programmer has to actually expect this to happen?
>>>
>>> I really, really hope that this is a documentation error or early
>>> design decision that has since been rectified but with lack of
>>> documentation updates.
>>
>> I'm pretty sure it's the same in Java.
>>
>> Finalizers (a.k.a. class destructors) are practically useless.
>
>  From Java spec:
>
> "The Java programming language does not specify how soon a finalizer
> will be invoked, except to say that it will happen before the storage
> for the object is reused"
>
> So yeah, there is no guarantee when a finalizer will be invoked.
>
> However, I'd tend to believe Java implementations will attempt to invoke
> all finalizers of objects left on the heap at program shutdown.
>
> I think D is the same too, as long as termination is normal (i.e. not
> from throwing an Error).


This shouldn't just be an implementation detail IMO. It should be a documented feature.

>
> -Steve

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 24, 2012
On 24-05-2012 16:00, Michel Fortin wrote:
> On 2012-05-24 13:38:01 +0000, "Steven Schveighoffer"
> <schveiguy@yahoo.com> said:
>
>> However, I'd tend to believe Java implementations will attempt to invoke
>> all finalizers of objects left on the heap at program shutdown.
>
> In Java you can call System.runFinalizersOnExit(true), but the default
> is false and this method has been deprecated because unsafe in
> multithreaded environments.
>
> <http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#runFinalization()>
>
>
>

It's only deprecated because Java's way of handling threading and finalization is apparently completely broken. See C# and the CLR for a system that actually works.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 24, 2012
On 24-05-2012 16:03, Russel Winder wrote:
> On Thu, 2012-05-24 at 09:38 -0400, Steven Schveighoffer wrote:
> [...]
>> However, I'd tend to believe Java implementations will attempt to invoke
>> all finalizers of objects left on the heap at program shutdown.
>
> As far as I am aware Java implementations do no finalization on exit
> unless System.runFinalizersOnExit(true) has been called. This method is
> deprecated since it can cause incorrect finalization. But like all
> things Java that have been deprecated, they never actually go away.
>
> There is System.runFinalization() which executes finalize on all objects
> in the pending finalization queue.
>

We should really expose a waitForFinalizers() function in core.memory.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 24, 2012
On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 24-05-2012 15:49, Steven Schveighoffer wrote:
>> On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix@gmail.com> wrote:
>>
>>> Le 24/05/2012 14:54, Peter Alexander a écrit :
>>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>>> Hi,
>>>>>
>>>>> http://dlang.org/class.html#Destructor
>>>>>
>>>>> "The garbage collector is not guaranteed to run the destructor for all
>>>>> unreferenced objects."
>>>>>
>>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>>> programmer has to actually expect this to happen?
>>>>>
>>>>> I really, really hope that this is a documentation error or early
>>>>> design decision that has since been rectified but with lack of
>>>>> documentation updates.
>>>>
>>>> I'm pretty sure it's the same in Java.
>>>>
>>>> Finalizers (a.k.a. class destructors) are practically useless.
>>>
>>> Java finalizer is a pretty bad design decision. Let's not reproduce
>>> error made in Java in D's destructors.
>>
>> You actually need a finalizer if you want to have resources that aren't
>> GC allocated.
>>
>> -Steve
>
> But that doesn't mean we should have Java finalization. There are many different forms of finalization, and I do agree that Java is the worst of all of them.

I only found one definition for finalizer on wikipedia, and it fits D's definition.

What I think we need is a dispose pattern for objects, like Tango has.

-Steve
May 24, 2012
On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
> The GC should (and probably does) assume at shutdown that all objects
> are unreferenced, and therefore reclaim and finalize them.

They may refer to one another.

Andrei

May 24, 2012
On 24-05-2012 16:53, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen <alex@lycus.org>
> wrote:
>
>> On 24-05-2012 15:49, Steven Schveighoffer wrote:
>>> On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix@gmail.com>
>>> wrote:
>>>
>>>> Le 24/05/2012 14:54, Peter Alexander a écrit :
>>>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> http://dlang.org/class.html#Destructor
>>>>>>
>>>>>> "The garbage collector is not guaranteed to run the destructor for
>>>>>> all
>>>>>> unreferenced objects."
>>>>>>
>>>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>>>> programmer has to actually expect this to happen?
>>>>>>
>>>>>> I really, really hope that this is a documentation error or early
>>>>>> design decision that has since been rectified but with lack of
>>>>>> documentation updates.
>>>>>
>>>>> I'm pretty sure it's the same in Java.
>>>>>
>>>>> Finalizers (a.k.a. class destructors) are practically useless.
>>>>
>>>> Java finalizer is a pretty bad design decision. Let's not reproduce
>>>> error made in Java in D's destructors.
>>>
>>> You actually need a finalizer if you want to have resources that aren't
>>> GC allocated.
>>>
>>> -Steve
>>
>> But that doesn't mean we should have Java finalization. There are many
>> different forms of finalization, and I do agree that Java is the worst
>> of all of them.
>
> I only found one definition for finalizer on wikipedia, and it fits D's
> definition.
>
> What I think we need is a dispose pattern for objects, like Tango has.
>
> -Steve

Just look at /usr/include/gc/gc.h (from libgc, the Boehm-Demers-Weiser GC). It has 3 (if not 4) different kinds of finalization. To be specific, the finalization I believe we need is the *_no_order behavior. This is the behavior C# and the CLR follow.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org