GC Destruction Order
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu May 21 05:28:38 PDT 2015
On 5/19/15 7:03 PM, bitwise wrote:
> On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>
>> On 5/19/15 5:07 PM, bitwise wrote:
>>> On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous at anonymous.com>
>>> wrote:
>>>
>>>> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>>>>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
>>>>> <destructionator at gmail.com> wrote:
>>>>>
>>>>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>>>>> Is this also true for D?
>>>>>>
>>>>>> Yes. The GC considers all the unreferenced memory dead at the same
>>>>>> time and may clean up the class and its members in any order.
>>>>>
>>>>> Ugh... I was really hoping D had something better up it's sleeve.
>>>>
>>>> It actually does, check out RefCounted!T and Unique!T in std.typecons.
>>>> They're sort of limited right now but undergoing a major revamp in
>>>> 2.068.
>>>
>>> Any idea what the plans are?. Does RefCounted become thread safe?
>>>
>>> Correct me if I'm wrong though, but even if RefCounted itself was
>>> thread-safe, RefCounted objects could still be placed in classes, at
>>> which point you might as well use a GC'ed class instead, because you'd
>>> be back to square-one with your destructor racing around on some random
>>> thread.
>>
>> With the current GC, yes. RefCounted needs to be thread safe in order
>> to use it. But if we change the GC, we could ensure destructors are
>> only called in the thread they were created in (simply defer
>> destructors until the next GC call in that thread).
>
> This seems like it could result in some destructors being delayed
> indefinitely.
That's already the case.
>>> I'm finding it hard to be optimistic about the memory model of D.
>>>
>>> The idea of marking absolutely everything in your program with "@nogc"
>>> just to make it safe is ludicrous.
>>
>> That makes no sense, the GC is not unsafe.
>>
>
> Maybe I worded that incorrectly, but my point is that when you're
> running with the GC disabled, you should only use methods marked with
> @nogc if you want to make sure your code doesn't leak right? that's a
> lot of attributes O_O
OK, I see your point. Yes, you need @nogc to not leak.
The point of @nogc was to ensure machine-checkable prevention of GC
calls. The idea is to put @nogc on main(), and then all your calls will
have to be @nogc. Where it absolutely comes in handy is compiler
generated GC calls that can be unexpected (e.g. closures). But I'd still
recommend not disabling the GC, as that is redundant, and having a stray
GC call will not leak if something somehow (roguely) uses the GC (there
are ways to do this). Alternatively, you can run a collection at
opportune times just in case.
It means you have to live with a subset of the language, and phobos
cannot support you 100%. We are working to ensure that it's @nogc as
much as possible.
-Steve
More information about the Digitalmars-d-learn
mailing list