Andrei Alexandrescu, el 23 de abril a las 12:48 me escribiste:
> Brad Roberts wrote:
> >Leandro Lucarella wrote:
> >>Now in Tango/Druntime you already can use a dummy GC that all it does is calling C malloc/free for gc_malloc/gc_free, exactly for this purpose, so what -nogc should do in that case is just link against the "stub" GC instead to the "basic".
> >This claim really needs to stop.  You can't just swap from the normal gc
> >to the stub gc an expect your app to use malloc/free and behave exactly
> >as it did before.  No, it'll leak.  Free will never be called (outside
> >the rare case of an explicit delete).  Normal apps expect implicit
> >cleanup to be invoked by the gc which will never happen in the stub.
> >That's fine in tiny apps, or apps that carefully manage their own
> >memory, but then you weren't using the gc in the first place for those apps.
> 
> Totally agreed. I've always wondered what the purpose of the stub GC was in druntime. "We can implement an appallingly crappy allocation model" is the only message I'm getting.
> 
> Andrei

From the stub GC documentation:

	This module contains a minimal garbage collector implementation
	according to published requirements. This library is mostly
	intended to serve as an example, but it is usable in applications
	which do not rely on a garbage collector to clean up memory (ie.
	when dynamic array resizing is not used, and all memory allocated
	with 'new' is freed deterministically with 'delete').

I think being an example is just a good enough reason (it was useful for me at least). The other use you may like it or not, but is there.

And may I ask what it would happen if I do this with your "-nogc" proposal?

class A
{
	B b;
}

class B
{
	A a;
}

A a = new A;
a.b = new B;
a.b.a = a;

? Wont this leak? Are you planning to make a backup tracing collector to fix cycles maybe? Because I don't think using a naive reference counting will avoid leaks as easy as you put it...

RC is not *that* simple.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsq8jg$eda$2@digitalmars.com...
> Georg Wrede wrote:
>> Today really seems to be the lucky day of D!
>> So many pieces are clicking together!!
>> Oh, my!
>
> Also, I just gave my talk on ranges vs. iterators at ACCU. The audience is still "shell shocked" as Walter put it. I guess it went well :o).
>

I don't suppose there's going to be a video on that?

Leandro Lucarella wrote:
> And may I ask what it would happen if I do this with your "-nogc"
> proposal?
> 
> class A
> {
> 	B b;
> }
> 
> class B
> {
> 	A a;
> }
> 
> A a = new A;
> a.b = new B;
> a.b.a = a;
> 
> ? Wont this leak? Are you planning to make a backup tracing collector to
> fix cycles maybe? Because I don't think using a naive reference counting
> will avoid leaks as easy as you put it...
> 
> RC is not *that* simple.

Oh I absolutely agree. In short, what happens depends on how Ref is implemented. In essence what I suggest is not (a simplified method of) reference counting, it's a hook that allows various allocation/collection strategies to be implemented by knowledgeable people (hint,  hint) :o).

I think WeakRef!T would also have to be part of the offering inside object_whatever.d. Then the example above can be fixed for the refcounting case by making one of the references weak.


Andrei

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> Brad Roberts wrote:
> > Leandro Lucarella wrote:
> >
> >> Now in Tango/Druntime you already can use a dummy GC that all it does is calling C malloc/free for gc_malloc/gc_free, exactly for this purpose, so what -nogc should do in that case is just link against the "stub" GC instead to the "basic".
> >
> > This claim really needs to stop.  You can't just swap from the normal gc
> > to the stub gc an expect your app to use malloc/free and behave exactly
> > as it did before.  No, it'll leak.  Free will never be called (outside
> > the rare case of an explicit delete).  Normal apps expect implicit
> > cleanup to be invoked by the gc which will never happen in the stub.
> > That's fine in tiny apps, or apps that carefully manage their own
> > memory, but then you weren't using the gc in the first place for those apps.
> Totally agreed. I've always wondered what the purpose of the stub GC was in druntime. "We can implement an appallingly crappy allocation model" is the only message I'm getting.

It was originally intended as a demo for how to plug a new GC into the lib
when I wrote it for Tango.  I left it in place mostly because the DLL demo
for Win32 actually links this "stub" implementation, and it seemed preferable
to have something that would actually allocate memory than segfault if
the DLL startup code did things in a bad order.  A few people have wanted
to try and write a small footprint C-like app in D as well, so it's a handy if
not terribly user-friendly option for that sort of thing.  The few times I've
brought this up in the past, I've always been careful to say that array and
AA operations will leak if linked against this lib.

Andrei Alexandrescu schrieb:
> 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
> ".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
> superdan suggested that when he wasn't busy cursing :o).
> 
> 2. Do the similar thing for associative arrays.
> 
> 3. Have two object.d at hand: one is "normal" and uses garbage
> collection, the other (call it object_nogc.d) has an entirely different
> definition for arrays, hashes, and Object.

question about debug code speed:

a far as i understand it now is the code-speed of (assoc) arrays independent from the debug-code-generator because of the buildinness

i ask because i hate the speed of std::vectors/maps at debug-time
especially when it comes to large datasets - my major slowdown in prototype development comes then from the awfully slow stl containers - does D suffer from this - or will it, when you add this extension?

> I think WeakRef!T would also have to be part of the offering inside object_whatever.d. Then the example above can be fixed for the refcounting case by making one of the references weak.

Now I wonder if the weak ref thread has (indirectly) caused the no gc thread. Have you and/or Walter and/or Sean decided that weakref is sufficiently tied to the gc that is should be part of the D standard libraries?

PS: I discovered recently that wikipedia says D has no support for weak references. It's always good to remove negative points about a language ;)

Andrei Alexandrescu wrote:
> Joel C. Salomon wrote:
>> Just as (1) & (2) point to a way to remove the “magic” of built-in
>> arrays & hash-tables, so too might (5) & (6) point to a way of replacing
>> the “new T(args)” syntax with something cleaner?  Not that
>> “new!(T)(args)” looks nicer than the current syntax, but is it perhaps a
>> better fit with the rest of the language?
> 
> I agree. new sucks.
> 
> Andrei

Oh I don't know, I rather like being able to allocate stuff on the heap.
 I mean, if I didn't, the poor heap would probably be very lonely.

Poor, poor oft-maligned heap; all because he's a bit slower than stack allocation and needs to be cleaned up after.  He's trying to help, you know!

Joking aside, what do you have in mind?  Every solution I come up with ends up being more or less the same (except with the 'new' keyword in a different place) or worse.

  -- Daniel

Andrei Alexandrescu wrote:
> Christopher Wright wrote:
>> This means replacing a mark/sweep GC with a reference counting GC.
> 
> It just means that certain types and constructs are rewritten. The exact strategy depends on how Ref, Array, and AssocArray are defined.
> 
> Probably a good approach is to simply rewrite anything anyway and have Ref vanish in gc mode by means of e.g. alias this.
> 
> So this means that we only need a flag -object=/path/to/object.d after all.

Well, sure, if you're going for the *entirely* general solution :)

I like it, by the way. It would also make it easier to deal with the builtin aggregate types via reflection, if Array and AssocArray were in object.d.

Anyway, if D supported implicit refcounting as well as mark/sweep, that's a lot closer to supporting any random allocation scheme I might dream up.

Also, it might be good to separate object.d into several modules in that case. That might not be so fun from the compiler's view or an efficiency standpoint, though.

Jason House wrote:
> 
>> I think WeakRef!T would also have to be part of the offering inside
>>  object_whatever.d. Then the example above can be fixed for the refcounting case by making one of the references weak.
> 
> Now I wonder if the weak ref thread has (indirectly) caused the no gc
> thread. Have you and/or Walter and/or Sean decided that weakref is
> sufficiently tied to the gc that is should be part of the D standard
> libraries?

I haven't followed that closely, but then you never know how the mind works.

> PS: I discovered recently that wikipedia says D has no support for
> weak references. It's always good to remove negative points about a
> language ;)

Yes, weak references should be in there. I learned today that Java has also soft references, which the gc can collect and nullify when on low memory conditions.


Andrei

dennis luehring wrote:
> Andrei Alexandrescu schrieb:
>> 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
>> ".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
>> superdan suggested that when he wasn't busy cursing :o).
>>
>> 2. Do the similar thing for associative arrays.
>>
>> 3. Have two object.d at hand: one is "normal" and uses garbage
>> collection, the other (call it object_nogc.d) has an entirely different
>> definition for arrays, hashes, and Object.
> 
> question about debug code speed:
> 
> a far as i understand it now is the code-speed of (assoc) arrays independent from the debug-code-generator because of the buildinness
> 
> i ask because i hate the speed of std::vectors/maps at debug-time
> especially when it comes to large datasets - my major slowdown in prototype development comes then from the awfully slow stl containers - does D suffer from this - or will it, when you add this extension?

I think we'll be in better shape than debug stl because ranges are inherently cheaper to check. But only testing will tell.

Andrei