GC: Yeah, everybody "knows" how it works. How does it?

[Leandro Lucarella]

dsimcha, el  7 de mayo a las 16:57 me escribiste:
> == Quote from Leandro Lucarella (llucax at gmail.com)'s article
> > (from the bottom up, in chronological order, of course)
> > If you want to know why you don't have ordering guarantees, it's because
> > when the "garbage" is swept, you don't do it by following the connectivity
> > graph (as you do when you mark the memory). You can't do it even if you
> > want to, because you don't have roots to the garbage (that's why it's
> > garbage in the first place =). And if you can manage to follow the "old"
> > connectivity graph for some magical reason, you still have problems with
> > cycles. What if eve have a reference to adam too? What do you destroy
> > first? Huston, we have a problem =)
> 
> True, but I wish the GC would allow referencing subobjects for the following very
> important but very restricted case, just to get around false pointer issues.  It
> seems to work in practice anyhow, so all that would have to happen is for it to be
> "officially" sanctioned, so that it's not labeled as undefined behavior and thus
> arbitrarily dangerous:
> 
> 1.  You're only referencing sub-objects to explicitly delete them.
> 2.  These sub-objects are guaranteed to have no more real references and *should*
> be freed, but may have false pointers.  If they're large enough, they will have
> false pointers with high probability.
> 3.  These sub-objects contain no finalizers of their own, so the finalizer can't
> get run twice.  Calling delete just frees memory.
> 
> Example:
> 
> class Foo {
>     // hugeArray either never escapes or we assume that the lifetime
>     // of any escapes is less than the lifetime of the class instance.
>     uint[] hugeArray;
> 
>     this() {
>         hugeArray = new uint[50_000_000];
>     }
> 
>     ~this() {
>         // There are no more real references to hugeArray, since
>         // it never escapes this class instance, but it is likely
>         // to have false references because it's so huge.
>         // Tell the GC that it is ok to delete it anyhow.
>         delete hugeArray;
>     }
> }

What's wrong with explicit memory managemente (malloc/free) in that
particular case?


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
now self-employed, concerned (but powerless),
an empowered and informed member of society (pragmatism not idealism),
will not cry in public, less chance of illness,
tires that grip in the wet (shot of baby strapped in back seat),