www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - -nogc

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I've discussed something with Walter today and thought I'd share it here.

The possibility of using D without a garbage collector was always
looming and has been used to placate naysayers ("you can call malloc if
you want" etc.) but that opportunity has not been realized in a seamless
manner. As soon as you concatenate arrays, add to a hash, or create an
object, you will call into the GC.

So I'm thinking there should be a flag -nogc that enables a different
model of memory allocation. Here's the steps we need to take:

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.

4. The definition of Object in object_nogc.d includes a reference count
member for intrusive refcounting.

5. Define a Ref!(T) struct in object_nogc.d that does intrusive
reference counting against T using ctors and dtor.

6. At this point we already have a usable, credible no-gc offering: just
use object_nogc.d instead of object.d and instead of "new Widget(args)"
use "Ref!(Widget)(args)".

7. Add a -nogc option to the compiler. In that mode, the compiler
replaces automatically "T" -> "Ref!(T)" and "new T(args)" ->
"Ref!(T)(args)" for all classes T except inside
object_nogc.d. The exception, as Walter pointed out, is to avoid
infinite regression (how do you implement Ref if the reference you hold
inside will also be wrapped in Ref???)

8. Well with this all a very solid offering of D without garbage
collection would be available at a low cost!

One cool thing is that you can compile the same application with and
without GC and test the differences easily. That's bound to show a
number of interesting things!

A disadvantage is that -nogc must be global - you can't link a program
that's partially built with gc and partially without. This was a major
counter-argument to adding optional gc to C++.


Andrei
Apr 23 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
One simple possible solution: -nogc is to write C-like programs, with no automatic reference counting. It doesn't include the GC in the final executable (making it much smaller) and in such programs AAs and array concatenation and closures are forbidden (compilation error if you try to use them). "New" allocates using the C heap, and you have to use "delete" manually for each of them. This is simple. While adding a second memory management system, ref-counted, looks like an increase of complexity for both the compiler and the programmers.
1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
".Array!(T)"<
That has to be done with care an in a transparent way, not adding the Array name in the namespace, so you can create an Array youself, etc. Bye, bearophile
Apr 23 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
One simple possible solution: -nogc is to write C-like programs, with no automatic reference counting. It doesn't include the GC in the final executable (making it much smaller) and in such programs AAs and array concatenation and closures are forbidden (compilation error if you try to use them). "New" allocates using the C heap, and you have to use "delete" manually for each of them. This is simple. While adding a second memory management system, ref-counted, looks like an increase of complexity for both the compiler and the programmers.
I was thinking of starting from the opposite end - add the required tools first so we gain experience with them, and then integrate with the compiler.
 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
".Array!(T)"<
That has to be done with care an in a transparent way, not adding the Array name in the namespace, so you can create an Array youself, etc.
There shouldn't be any harm in using Array or AssocArray directly. Andrei
Apr 23 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:
 There shouldn't be any harm in using Array or AssocArray directly.
How about __Array or something? I already have a struct Array!()
Apr 24 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Robert Fraser, el 24 de abril a las 07:55 me escribiste:
 Andrei Alexandrescu wrote:
There shouldn't be any harm in using Array or AssocArray directly.
How about __Array or something? I already have a struct Array!()
How about std.array.Array or something? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Are you such a dreamer? To put the world to rights? I'll stay home forever Where two & two always makes up five
Apr 25 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 23 Apr 2009 15:08:43 +0400, bearophile <bearophileHUGS lycos.com> wrote:

 Andrei Alexandrescu:
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
One simple possible solution: -nogc is to write C-like programs, with no automatic reference counting. It doesn't include the GC in the final executable (making it much smaller) and in such programs AAs and array concatenation and closures are forbidden (compilation error if you try to use them). "New" allocates using the C heap, and you have to use "delete" manually for each of them. This is simple. While adding a second memory management system, ref-counted, looks like an increase of complexity for both the compiler and the programmers.
Same here. My version of -nogc would work as follows: 1) You mark a module as -nogc/realtime/whatever (similar to module(system) or module(safe)). module(nogc) some.module.that.doesnt.use.gc; 2) Array concatenations are not allowed, array.length is readonly, can't insert into AA, can't new objects (only malloc? this needs additional thoughts) 3) ... I believe this is an interesting way to explore. When one writes real-time/kernel-level/etc code that shouldn't leak, he should be very cautious and compiler should help him by restricting access to methods that potentially/certainly leak. But how would one ensure that? A simple idea would be to allow module(nogc) only access other modules that are marked as nogc, too. This will effectively disallow most (or all - at least in the beginning) parts of Phobos (for a reason!). But marking whole module as nogc is not very good. For example, I'd like to be able to read from and write to an existing array, but I should be unable to resize them. Thus, all the method of Array but a void Array.resize(size_t newSize) must be marked as safe/noleak/nogc/whatever (nogc is a good name here). Similarly, safe modules should be able to access other safe methods, to, and T* Array!(T).ptr() should not be among them. Thoughts?
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Thu, 23 Apr 2009 15:08:43 +0400, bearophile
 <bearophileHUGS lycos.com> wrote:
 
 Andrei Alexandrescu:
 The possibility of using D without a garbage collector was always
  looming and has been used to placate naysayers ("you can call
 malloc if you want" etc.) but that opportunity has not been
 realized in a seamless manner. As soon as you concatenate arrays,
 add to a hash, or create an object, you will call into the GC.
One simple possible solution: -nogc is to write C-like programs, with no automatic reference counting. It doesn't include the GC in the final executable (making it much smaller) and in such programs AAs and array concatenation and closures are forbidden (compilation error if you try to use them). "New" allocates using the C heap, and you have to use "delete" manually for each of them. This is simple. While adding a second memory management system, ref-counted, looks like an increase of complexity for both the compiler and the programmers.
Same here. My version of -nogc would work as follows: 1) You mark a module as -nogc/realtime/whatever (similar to module(system) or module(safe)). module(nogc) some.module.that.doesnt.use.gc; 2) Array concatenations are not allowed, array.length is readonly, can't insert into AA, can't new objects (only malloc? this needs additional thoughts)
I don't understand the appeal of this. I mean that means you'd have to write your own Array class to do anything about arrays anyway. So why not actually integrate it with the language?
 3) ...
 
 I believe this is an interesting way to explore. When one writes
 real-time/kernel-level/etc code that shouldn't leak, he should be
 very cautious and compiler should help him by restricting access to
 methods that potentially/certainly leak. But how would one ensure
 that?
 
 A simple idea would be to allow module(nogc) only access other
 modules that are marked as nogc, too. This will effectively disallow
 most (or all - at least in the beginning) parts of Phobos (for a
 reason!).
 
 But marking whole module as nogc is not very good. For example, I'd
 like to be able to read from and write to an existing array, but I
 should be unable to resize them.
I think marking the entire application as gc or not is the most sensible option. It's also relatively simple to implement.
 Thus, all the method of Array but a void Array.resize(size_t newSize)
 must be marked as safe/noleak/nogc/whatever (nogc is a good name
 here).
 
 Similarly, safe modules should be able to access other safe methods,
 to, and T* Array!(T).ptr() should not be among them.
 
 Thoughts?
My ambition about mixing together gc and no-gc modules is smaller. In essence, I think C++ has shown that that's not an easy option. I want to have the opportunity to choose at application level whether I will be using gc or not. In my opinion, anything that gets into defining new qualifiers or storage classes is bound to cause too much aggravation. We already have enough of those. Andrei
Apr 23 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I don't understand the appeal of this. I mean that means you'd have to 
 write your own Array class to do anything about arrays anyway. So why 
 not actually integrate it with the language?
I think the main appeal is that the language then behaves almost like C, and lot of people know C already, so they don't have to learn more things, like using a reference counting GC (and its traps) too. Bye, bearophile
Apr 23 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 23 de abril a las 07:08 me escribiste:
 Andrei Alexandrescu:
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
One simple possible solution: -nogc is to write C-like programs, with no automatic reference counting. It doesn't include the GC in the final executable (making it much smaller) and in such programs AAs and array concatenation and closures are forbidden (compilation error if you try to use them). "New" allocates using the C heap, and you have to use "delete" manually for each of them. This is simple. While adding a second memory management system, ref-counted, looks like an increase of complexity for both the compiler and the programmers.
I definitely agree that -nogc should not imply reference counting garbarge collection. 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".
1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
".Array!(T)"<
That has to be done with care an in a transparent way, not adding the Array name in the namespace, so you can create an Array youself, etc.
srd.array.Array can be used, and leave T[] as a syntax sugar only (but you could also write std.array.Array!(T) instead). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Apr 23 2009
parent reply Brad Roberts <braddr puremagic.com> writes:
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. Later, Brad
Apr 23 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 23 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
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) ----------------------------------------------------------------------------
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 23 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
 
 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 ;)
Apr 23 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 23 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 23 de abril a las 13:27 me escribiste:
 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 it would be awesome to have some kind of hooks to instrument references read/writes so one can implement RC-based, partition-based GC (like generational) or incremental collectors. There were a proposal to make that some time ago by Frank Benoit: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35426 He proposed to add these hooks, with the default implementation being: ___ref_assign( void * trg, void * src ){ trg = src; } void* ___ref_read( void * src ){ return src; } I think you proposal of wrapping read/writes into a library defined type is an improvement over the Frank's proposal. (other proposals in that very same mail are as interesting as the read/write instrumentation)
 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.
I think WeakRef!T should be part of the GC, not object.d. The same goes for Ref!T. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Hey you, with you ear against the wall Waiting for someone to call out Would you touch me?
Apr 25 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== 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.
Apr 23 2009
parent Kagamin <spam here.lot> writes:
Sean Kelly Wrote:

 I've always been careful to say that array and
 AA operations will leak if linked against this lib.
You can remove leaking operations from druntime and leaking application won't link.
Apr 24 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 23 de abril a las 10:39 me escribiste:
 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.
Maybe it wasn't clear enough (and it's less clear even in you mail where you remove all context of my response) but what I said was in response to bearophile mail, which said (and I quote it again): One simple possible solution: -nogc is to write C-like programs, with no automatic reference counting. It doesn't include the GC in the final executable (making it much smaller) and in such programs AAs and array concatenation and closures are forbidden (compilation error if you try to use them). "New" allocates using the C heap, and you have to use "delete" manually for each of them. So, no, I'm not implying that one can use the "stub" GC implementation and just go and be happy and play with dynamic arrays and hashes and expect that memory get freed magically. Please read the message in its context before putting words in my mouth. Thanks. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Apr 23 2009
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:
 I've discussed something with Walter today and thought I'd share it here.
 
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
 
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
This means replacing a mark/sweep GC with a reference counting GC. I'd think that it would be better to have -nogc not use Ref(T) by default, and add another flag -refcount that implies -nogc and uses Ref(T) by default.
Apr 23 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christopher Wright wrote:
 Andrei Alexandrescu wrote:
 I've discussed something with Walter today and thought I'd share it here.

 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.

 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
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. Andrei
Apr 23 2009
parent Christopher Wright <dhasenan gmail.com> writes:
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.
Apr 23 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Christopher Wright wrote:
 Andrei Alexandrescu wrote:
 I've discussed something with Walter today and thought I'd share it here.

 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.

 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
This means replacing a mark/sweep GC with a reference counting GC. I'd think that it would be better to have -nogc not use Ref(T) by default, and add another flag -refcount that implies -nogc and uses Ref(T) by default.
A thought occurs. If you wanted to implement, say, a moving collector, it would be very useful to have some level of indirection instead of direct references (either using an ID for the actual address, or by using an opPostMove to notify the GC, if we ever get one.) So perhaps you could make "-nogc" alias to "-nogc=object_nogc", thus allowing people to replace Array(T), AA(K,V) and Ref(T) with their own. -- Daniel
Apr 23 2009
prev sibling next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
I am using D for a real time test system. There i have to make sure that
real time code does never use direct or indirect allocations.
I can use the GC in the non real time thread and at start up. I can
preallocate as much as I want. Just, it is not allowed in IRQ handler,
certainly.

What i did is, i patched the GC to have a callback in the allocation
function. My application can register for that callback and checks the
current thread. If it is a real time thread, an error is generated.

The disadvantage is, it is a runtime check. The advantage is, i can mix
code that can use the GC and code that can't.
Apr 23 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Frank Benoit wrote:
 I am using D for a real time test system. There i have to make sure that
 real time code does never use direct or indirect allocations.
 I can use the GC in the non real time thread and at start up. I can
 preallocate as much as I want. Just, it is not allowed in IRQ handler,
 certainly.
 
 What i did is, i patched the GC to have a callback in the allocation
 function. My application can register for that callback and checks the
 current thread. If it is a real time thread, an error is generated.
 
 The disadvantage is, it is a runtime check. The advantage is, i can mix
 code that can use the GC and code that can't.
Great. We need to mind this scenario (the right place is I think Ref). Andrei
Apr 23 2009
prev sibling parent ponec <aliloko gmail.com> writes:
I am also using D for real time applications (audio library, not embedded
systems). 

Since I'm ensuring allocation don't occur in a real-time loop, I'm quite happy
with the way the GC work. We have custom allocators, do we ? 
I mean, anything which is too slow could use pools anyway.


Frank Benoit Wrote:

 I am using D for a real time test system. There i have to make sure that
 real time code does never use direct or indirect allocations.
 I can use the GC in the non real time thread and at start up. I can
 preallocate as much as I want. Just, it is not allowed in IRQ handler,
 certainly.
 
 What i did is, i patched the GC to have a callback in the allocation
 function. My application can register for that callback and checks the
 current thread. If it is a real time thread, an error is generated.
 
 The disadvantage is, it is a runtime check. The advantage is, i can mix
 code that can use the GC and code that can't.
Apr 23 2009
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-04-23 06:58:38 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 I've discussed something with Walter today and thought I'd share it here.
 
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
Very true. It's pretty easy to call the GC without noticing in D.
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
 
 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).
That makes sense.
 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.
Couldn't that just be a version switch, such as `version (D_NO_GC)` and `version (D_GC)`. Then you can implement things differently in other modules too when there is or there isn't a GC.
 4. The definition of Object in object_nogc.d includes a reference count
 member for intrusive refcounting.
 
 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
 reference counting against T using ctors and dtor.
 
 6. At this point we already have a usable, credible no-gc offering: just
 use object_nogc.d instead of object.d and instead of "new Widget(args)"
 use "Ref!(Widget)(args)".
How's that going to work with scope classes? scope Widget = new Widget; scope Widget = Ref!(Widget)();
 7. Add a -nogc option to the compiler. In that mode, the compiler
 replaces automatically "T" -> "Ref!(T)" and "new T(args)" ->
 "Ref!(T)(args)" for all classes T except inside
 object_nogc.d. The exception, as Walter pointed out, is to avoid
 infinite regression (how do you implement Ref if the reference you hold
 inside will also be wrapped in Ref???)
I'm just wondering, why wouldn't the compiler always use Ref!(T)? In the GC mode it'd simply resolve to a T, but if you wanted to experiment with another kind of GC -- say one which would require calling a notification function when writing a new value, such as the one in Objective-C 2.0 -- then you could. Hum, also, how would it work for pointers to things in memory blocks that are normally managed by the GC? Would those increment the reference count for the memory block?
 8. Well with this all a very solid offering of D without garbage
 collection would be available at a low cost!
 
 One cool thing is that you can compile the same application with and
 without GC and test the differences easily. That's bound to show a
 number of interesting things!
Indeed.
 A disadvantage is that -nogc must be global - you can't link a program
 that's partially built with gc and partially without. This was a major
 counter-argument to adding optional gc to C++.
Another disadvantage is that you change the reference semantics and capabilities. With a GC, you can create circular pointer references and it won't leak memory once you stop referencing them. Do that with reference counting and you'll have memory leaks all around. So with no GC, you have to have weak references if you're going to build tree structures where branches know about their parents (which is a pretty common thing). I'd suggest that weak references be put in the language so the compiler can replace them with WeakRef!(T) in no-GC mode and do something else in GC mode. Being in the language would just be some syntactic sugar that would make them more bearable in normal code. As for compatibility, it may be worth looking at how it has been done in Objective-C 2.0. Objective-C has always used reference counting. Version 2.0 brought a GC. When you build a library, you have to specify whether the resulting binary expects a GC, reference counting, or can work in both modes. Something that works in both mode incurs a slight overhead, but sometime the binary compatibility is just worth it. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 23 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 I've discussed something with Walter today and thought I'd share it here.
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
 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).
One of my concerns with this is what effect it would have on CTFE, templates, etc. One of the nice things about truly builtin arrays and AAs is that they fully work at compile time. I'd be for this idea only if we could guarantee that nothing with respect to arrays and AAs that works at compile time now would break if they were moved to object.
Apr 23 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 I've discussed something with Walter today and thought I'd share it here.
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
 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).
One of my concerns with this is what effect it would have on CTFE, templates, etc. One of the nice things about truly builtin arrays and AAs is that they fully work at compile time. I'd be for this idea only if we could guarantee that nothing with respect to arrays and AAs that works at compile time now would break if they were moved to object.
All compile-time stuff will remain unchanged. Only when it comes about generating code will the idea enter in action. Andrei
Apr 23 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 I've discussed something with Walter today and thought I'd share it here.
 
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
 
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
 
 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).
I like that translation since it can allow customization. How will the type system handle Array!(const(T)) and const(Array!T)? They're no longer implicitly convertible.
 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.
A version statement seems more powerful. Standard libraries may need changes too.
 4. The definition of Object in object_nogc.d includes a reference count
 member for intrusive refcounting.
That's still a method of garbage collecting! -nogc is kind of misleading...
 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
 reference counting against T using ctors and dtor.
 
 6. At this point we already have a usable, credible no-gc offering: just
 use object_nogc.d instead of object.d and instead of "new Widget(args)"
 use "Ref!(Widget)(args)".
Ick... Please make this hijack the default new behavior.
 7. Add a -nogc option to the compiler. In that mode, the compiler
 replaces automatically "T" -> "Ref!(T)" and "new T(args)" ->
 "Ref!(T)(args)" for all classes T except inside
 object_nogc.d. The exception, as Walter pointed out, is to avoid
 infinite regression (how do you implement Ref if the reference you hold
 inside will also be wrapped in Ref???)
 
 8. Well with this all a very solid offering of D without garbage
 collection would be available at a low cost!
 
 One cool thing is that you can compile the same application with and
 without GC and test the differences easily. That's bound to show a
 number of interesting things!
 
 A disadvantage is that -nogc must be global - you can't link a program
 that's partially built with gc and partially without. This was a major
 counter-argument to adding optional gc to C++.
 
 
 Andrei
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 I've discussed something with Walter today and thought I'd share it here.

 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.

 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:

 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).
I like that translation since it can allow customization. How will the type system handle Array!(const(T)) and const(Array!T)? They're no longer implicitly convertible.
We will need to accommodate multiple implicit conversions somehow anyway (e.g. multiple alias this entries). This is a great question because it illustrates how segregating arrays out of the language challenges the magic that made them "special" and democratizes good features such that other types can benefit of them too.
 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.
A version statement seems more powerful. Standard libraries may need changes too.
 4. The definition of Object in object_nogc.d includes a reference count
 member for intrusive refcounting.
That's still a method of garbage collecting! -nogc is kind of misleading...
Yah, I agree.
 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
 reference counting against T using ctors and dtor.

 6. At this point we already have a usable, credible no-gc offering: just
 use object_nogc.d instead of object.d and instead of "new Widget(args)"
 use "Ref!(Widget)(args)".
Ick... Please make this hijack the default new behavior.
Agreed. Andrei
Apr 23 2009
next sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Andrei Alexandrescu wrote:
 Jason House wrote:
 Andrei Alexandrescu Wrote:
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:

 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. 
<<snip>>
 
 We will need to accommodate multiple implicit conversions somehow anyway
 (e.g. multiple alias this entries). This is a great question because it
 illustrates how segregating arrays out of the language challenges the
 magic that made them "special" and democratizes good features such that
 other types can benefit of them too.
<snip>
 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
 reference counting against T using ctors and dtor.

 6. At this point we already have a usable, credible no-gc offering: just
 use object_nogc.d instead of object.d and instead of "new Widget(args)"
 use "Ref!(Widget)(args)".
Ick... Please make this hijack the default new behavior.
Agreed.
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’ve been lurking on these list for a while and have noticed a pattern: • Walter includes a useful feature (e.g., complex numbers) into the language itself for efficiency reasons. • Walter makes the language more powerful in some subtle but far-reaching way. • Someone re-implements the special feature as a library function, based on the language improvement. I’m just wondering what addition will––accidentally, of course––make the creation of new infix operators possible. ;-) —Joel Salomon
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 23 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 
 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.
I don't know. Here's what we need: 1. Create one heap object of type T with creation arguments args. Currently: new T(args), except when T is a variable-sized array in which case syntax is new T[arg] (only one arg allowed). It is next to impossible to create one heap object of fixed-size array type. 2. Create one array T[] of size s and initialize its elements from a range or generator function. Currently possible via a function that internally uses GC calls. 3. Create one array T[] of a size s and do not initialize content. Currently possible by calling GC functions. Probably not really needed because it's not that safe anyway. Andrei
Apr 23 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 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.
I don't know. Here's what we need: 1. Create one heap object of type T with creation arguments args. Currently: new T(args), except when T is a variable-sized array in which case syntax is new T[arg] (only one arg allowed). It is next to impossible to create one heap object of fixed-size array type.
Actually,
 new T[](size);
This works just fine. I do think that (new T[n]) should be of type T[n], not T[].
 2. Create one array T[] of size s and initialize its elements from a
 range or generator function. Currently possible via a function that
 internally uses GC calls.

 3. Create one array T[] of a size s and do not initialize content.
 Currently possible by calling GC functions. Probably not really needed
 because it's not that safe anyway.
 
 Andrei
Perhaps have these overloads for object.Array!(T)...
 new T[](size_t, T)
 new T[](size_t, S) if isInputRange!(S)
As for the uninitialised case, I don't think it's that important, either. <dreaming> That said... Assuming I'm allowed to make language changes, I'd be tempted to make void a valid type for variables and arguments, and also make it double as an expression. That is, void is a literal of type void with value void, the ONLY valid value for voids. Then, you could have:
 auto a = new T[](n, void);
I've always been annoyed that you can't have void variables or arguments; it always seems to complicate my beautiful generic code :'(
 ReturnTypeOf!(Fn) wrap(alias Fn)(ParameterTypeTuple!(Fn) args)
 {
     logf("> ",Fn.stringof,args);
     auto result = Fn(args);
     logf("< ",Fn.stringof,args);
 }
That works only so long as Fn doesn't return a void. And before anyone suggests it, this trick:
 return Fn(args);
only works in trivial cases; it doesn't help if you need to be able to DO something after the function call. </dreaming> -- Daniel
Apr 23 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 24 Apr 2009 08:47:49 +0400, Daniel Keep <daniel.keep.lists gmail.com>
wrote:

 Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 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.
I don't know. Here's what we need: 1. Create one heap object of type T with creation arguments args. Currently: new T(args), except when T is a variable-sized array in which case syntax is new T[arg] (only one arg allowed). It is next to impossible to create one heap object of fixed-size array type.
Actually,
 new T[](size);
This works just fine. I do think that (new T[n]) should be of type T[n], not T[].
 2. Create one array T[] of size s and initialize its elements from a
 range or generator function. Currently possible via a function that
 internally uses GC calls.

 3. Create one array T[] of a size s and do not initialize content.
 Currently possible by calling GC functions. Probably not really needed
 because it's not that safe anyway.

 Andrei
Perhaps have these overloads for object.Array!(T)...
 new T[](size_t, T)
 new T[](size_t, S) if isInputRange!(S)
I agree these overloads belong to Array.
 As for the uninitialised case, I don't think it's that important, either.

 <dreaming>

 That said...

 Assuming I'm allowed to make language changes, I'd be tempted to make
 void a valid type for variables and arguments, and also make it double
 as an expression.  That is, void is a literal of type void with value
 void, the ONLY valid value for voids.  Then, you could have:

 auto a = new T[](n, void);
This is a nice idea!
 I've always been annoyed that you can't have void variables or
 arguments; it always seems to complicate my beautiful generic code :'(

 ReturnTypeOf!(Fn) wrap(alias Fn)(ParameterTypeTuple!(Fn) args)
 {
     logf("> ",Fn.stringof,args);
     auto result = Fn(args);
     logf("< ",Fn.stringof,args);
return result;
 }
That works only so long as Fn doesn't return a void. And before anyone suggests it, this trick:
 return Fn(args);
only works in trivial cases; it doesn't help if you need to be able to DO something after the function call. </dreaming> -- Daniel
Yes, I've hit the same issue a lot of times, although scope(exit)/scope(success) usually helps.
Apr 24 2009
prev sibling parent Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 1. Create one heap object of type T with creation arguments args. 
 Currently: new T(args), except when T is a variable-sized array in which 
 case syntax is new T[arg] (only one arg allowed). It is next to 
 impossible to create one heap object of fixed-size array type.
You can create it. new T[arg] does just that. You can't *use* it. T[5]* arr=something; arr[3]; //wrong (*arr)[3]; //ok And as it was said, current new syntax allows arguments for array new.
Apr 24 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 We will need to accommodate multiple implicit conversions somehow anyway 
 (e.g. multiple alias this entries). This is a great question because it 
 illustrates how segregating arrays out of the language challenges the 
 magic that made them "special" and democratizes good features such that 
 other types can benefit of them too.
Making things more orthogonal can be quite useful and it allows more flexibility, but having common things implemented as magic is sometimes good because you need less knowledge to use the language, you need less time to understand code written by other people (because there are less general ways to do something), and this allows for more sharing of code, and you may cover most of the common usages anyway. So the risk of making things more orthogonal is to over-generalize. Scheme language (that is very orthogonal) shows this failure very well, this is a related quotation:
In practice Scheme follows exactly the opposite route: there are dozens of
different and redundant object systems, module systems, even record systems,
built just by piling up feature over feature. So the minimalism of the core
language is just a lie or at best a red herring (the core language can be
minimalistic, but the core language is basically useless for any real life
job).<
The Axioms of C++0x (that in theory the compiler can use to perform optimizations, according to Wikipedia http://en.wikipedia.org/wiki/C++0x#Axioms ) show one example of over-generalization. I think the D2 language may offer just few common Axioms (commutativity, etc), allowing most of the usages of Axioms and avoiding lot of compiler complexity to support them in general. Bye, bearophile
Apr 23 2009
parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
bearophile wrote:
 Making things more orthogonal can be quite useful and it allows more
flexibility, but having common things implemented as magic is sometimes good
because you need less knowledge to use the language, you need less time to
understand code written by other people (because there are less general ways to
do something), and this allows for more sharing of code, and you may cover most
of the common usages anyway. So the risk of making things more orthogonal is to
over-generalize. Scheme language (that is very orthogonal) shows this failure
very well, this is a related quotation:
 
 In practice Scheme follows exactly the opposite route: there are dozens of
different and redundant object systems, module systems, even record systems,
built just by piling up feature over feature. So the minimalism of the core
language is just a lie or at best a red herring (the core language can be
minimalistic, but the core language is basically useless for any real life
job).<
The difference here is that a core of these semi-magic features is standard. You’ll never write “std.Array!(T)” in real code; you’d use “T[]”. You might still replace the core library with custom versions of Object &c., but you ought not to be tempted to do so. —Joel Salomon
Apr 23 2009
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 I've discussed something with Walter today and thought I'd share it here.

 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.

 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:

 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).
I like that translation since it can allow customization. How will the type system handle Array!(const(T)) and const(Array!T)? They're no longer implicitly convertible.
We will need to accommodate multiple implicit conversions somehow anyway (e.g. multiple alias this entries). This is a great question because it illustrates how segregating arrays out of the language challenges the magic that made them "special" and democratizes good features such that other types can benefit of them too.
This is something I've given thought to in the past. The basic requirement for x!(const(T),U) to be implicitly convertible to const(x!(T,U)) is: 1. Member variables match in physical loxation, quantity. 2. Member variables in both x!(T,U) and x!(const(T),U) are both implicitly convertible to normal const versions 3. Const member functions must have identical behavior
 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.
A version statement seems more powerful. Standard libraries may need changes too.
 4. The definition of Object in object_nogc.d includes a reference count
 member for intrusive refcounting.
That's still a method of garbage collecting! -nogc is kind of misleading...
Yah, I agree.
 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
 reference counting against T using ctors and dtor.

 6. At this point we already have a usable, credible no-gc offering: just
 use object_nogc.d instead of object.d and instead of "new Widget(args)"
 use "Ref!(Widget)(args)".
Ick... Please make this hijack the default new behavior.
Agreed. Andrei
Apr 23 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
No printable comment on that one...
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
Today really seems to be the lucky day of D! So many pieces are clicking together!! Oh, my!
 7. Add a -nogc option to the compiler. In that mode, the compiler
 replaces automatically "T" -> "Ref!(T)" and "new T(args)" ->
 "Ref!(T)(args)" for all classes T except inside
 object_nogc.d. 
Of course.
 The exception, as Walter pointed out, is to avoid
 infinite regression (how do you implement Ref if the reference you hold
 inside will also be wrapped in Ref???)
I wish you'd elaborate.
 A disadvantage is that -nogc must be global - you can't link a program
 that's partially built with gc and partially without. This was a major
 counter-argument to adding optional gc to C++.
Well, IMHO, that's life. Can't win them all, all of the time. So let's live with it. One might of course try to figure out a way to have the linker recognize this, or even *simpler*, the runtime might barf on it!!
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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). Andrei
Apr 23 2009
parent "Nick Sabalausky" <a a.a> writes:
"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?
Apr 23 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 23 de abril a las 05:58 me escribiste:
 I've discussed something with Walter today and thought I'd share it here.
 
 The possibility of using D without a garbage collector was always
 looming and has been used to placate naysayers ("you can call malloc if
 you want" etc.) but that opportunity has not been realized in a seamless
 manner. As soon as you concatenate arrays, add to a hash, or create an
 object, you will call into the GC.
 
 So I'm thinking there should be a flag -nogc that enables a different
 model of memory allocation. Here's the steps we need to take:
 
 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.
 
 4. The definition of Object in object_nogc.d includes a reference count
 member for intrusive refcounting.
 
 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
 reference counting against T using ctors and dtor.
Oh! So you mean -nomarksweep then, right? Rerence counting *is* a garbage collection algorithm.
 6. At this point we already have a usable, credible no-gc offering: just
 use object_nogc.d instead of object.d and instead of "new Widget(args)"
 use "Ref!(Widget)(args)".
 
 7. Add a -nogc option to the compiler. In that mode, the compiler
 replaces automatically "T" -> "Ref!(T)" and "new T(args)" ->
 "Ref!(T)(args)" for all classes T except inside
 object_nogc.d. The exception, as Walter pointed out, is to avoid
 infinite regression (how do you implement Ref if the reference you hold
 inside will also be wrapped in Ref???)
 
 8. Well with this all a very solid offering of D without garbage
 collection would be available at a low cost!
Besides this not being "non gc D", seems like a good idea. If I know there were any chance that RC had a chance to be accepted in the D, I would included it in my thesis.
 One cool thing is that you can compile the same application with and
 without GC and test the differences easily. That's bound to show a
 number of interesting things!
Please, stop calling it "without GC", is really confusing =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Apr 23 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Oh! So you mean -nomarksweep then, right? Rerence counting *is* a garbage
 collection algorithm.
Probably the best way is to express it as a positive: -object=object_marksweep.d -object=object_refcount.d -object=object_generational.d The point is that changing the relatively small object.d enables various fundamental approaches to allocation.
 8. Well with this all a very solid offering of D without garbage
 collection would be available at a low cost!
Besides this not being "non gc D", seems like a good idea. If I know there were any chance that RC had a chance to be accepted in the D, I would included it in my thesis.
Walter?
 One cool thing is that you can compile the same application with and
 without GC and test the differences easily. That's bound to show a
 number of interesting things!
Please, stop calling it "without GC", is really confusing =)
I agree. Andrei
Apr 23 2009
prev sibling next sibling parent reply Craig Black <cblack ara.com> writes:
Being able to switch between different GC's would be incredibly useful!  Have
you given any thought to removing GC completely?  It seems it would require
much more work in the code that the compiler generates.  It would also probably
require additional work in the standard library.  Even so, this may be
something that is worth pursuing.  What do you think?

-Craig
Apr 23 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Craig Black wrote:
 Being able to switch between different GC's would be incredibly
 useful!  Have you given any thought to removing GC completely?  It
 seems it would require much more work in the code that the compiler
 generates.  It would also probably require additional work in the
 standard library.  Even so, this may be something that is worth
 pursuing.  What do you think?
 
 -Craig
I think we should make that possible. Andrei
Apr 23 2009
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
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?
Apr 23 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 23 2009
parent reply dennis luehring <dl.soluz gmx.net> writes:
Andrei Alexandrescu schrieb:
 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.
not only iterating is awfully slow - also the pushing of data (i can clearly say that my simple stl container based volume simulation is nearly not debugable because of the amount of data needed to get into an debugable state) - so im working only with release versions - and start to convert my (c++)modules into relaseable c-interfaced dlls (just to be able to debug the main-code) - and this situation is an absolut prototyping no-go please: always test if your extensions to containers do not harm the "debugging" speed - the stl is best example of killing this part of prototype-test-programm-cycle
Apr 23 2009
parent reply dennis luehring <dl.soluz gmx.net> writes:
dennis luehring schrieb:
 Andrei Alexandrescu schrieb:
 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.
not only iterating is awfully slow - also the pushing of data (i can clearly say that my simple stl container based volume simulation is nearly not debugable because of the amount of data needed to get into an debugable state) - so im working only with release versions - and start to convert my (c++)modules into relaseable c-interfaced dlls (just to be able to debug the main-code) - and this situation is an absolut prototyping no-go please: always test if your extensions to containers do not harm the "debugging" speed - the stl is best example of killing this part of prototype-test-programm-cycle
does that also mean that strings are getting template based? what amount of debug-code will produce this? like with the stl (or boost) - zillion megabytes for 9 lines of code? and i can throw away my debugger (if D will get a good one) im always shocked when looking at the stl/boost based assembler code in debug releases - does D generate less code?
Apr 23 2009
parent reply dennis luehring <dl.soluz gmx.net> writes:
On 24.04.2009 08:24, dennis luehring wrote:
 dennis luehring schrieb:
 Andrei Alexandrescu schrieb:
 dennis luehring wrote:
 Andrei Alexandrescu schrieb:
does that also mean that strings are getting template based? what amount of debug-code will produce this? like with the stl (or boost) - zillion megabytes for 9 lines of code? and i can throw away my debugger (if D will get a good one) im always shocked when looking at the stl/boost based assembler code in debug releases - does D generate less code?
but i still like the idea of getting more generic at the base :-) the result will less special cases for the compiler and no that-can-only-the-compiler-do scenarios but the downside - are the error messages then still that informative and what is the code bloat in the end - but maybe walter found a way to code-specialize the Array!/Assoc! (i hope to see better initalizers then - maybe static ones :-]) stuff for the standard datatypes - and then everything is fine ... still waiting for D 3 - the concurrency wonderland ...
Apr 24 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
dennis luehring wrote:
 On 24.04.2009 08:24, dennis luehring wrote:
 dennis luehring schrieb:
 Andrei Alexandrescu schrieb:
 dennis luehring wrote:
 Andrei Alexandrescu schrieb:
does that also mean that strings are getting template based? what amount of debug-code will produce this? like with the stl (or boost) - zillion megabytes for 9 lines of code? and i can throw away my debugger (if D will get a good one) im always shocked when looking at the stl/boost based assembler code in debug releases - does D generate less code?
but i still like the idea of getting more generic at the base :-) the result will less special cases for the compiler and no that-can-only-the-compiler-do scenarios but the downside - are the error messages then still that informative and what is the code bloat in the end - but maybe walter found a way to code-specialize the Array!/Assoc! (i hope to see better initalizers then - maybe static ones :-]) stuff for the standard datatypes - and then everything is fine ... still waiting for D 3 - the concurrency wonderland ...
Let's take an example. Code for Array!(char) and Array!(ubyte) are probably going to be exactly identical. Of course, it's very hard for the compiler to know that. It sees two distinct types. Simply looking at the template arguments doesn't help thanks to static if. The real question is: is the generated machine code identical? If it is, there's probably no benefit in having multiple versions of it. I know it's been said a bazillion times already, but maybe we should look at replacing OPTLINK, and adding a "collapse identical code sections" option while we're at it. :P -- Daniel
Apr 24 2009
parent reply Walter Bright <newshound digitalmars.com> writes:
== Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 I know it's been said a bazillion times already, but maybe we should
 look at replacing OPTLINK, and adding a "collapse identical code
 sections" option while we're at it.  :P
Fixing optlink is a worthy goal, but that is only one platform. D has to work with linkers on many platforms, and relying on such a solution existing across linkers we have no control over is not practical.
Apr 25 2009
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, if they're in the same section, the compiler _could_ detect this 
itself, couldn't it?  I mean, it already does an optimization pass 
before the codegen, it could theoretically do another collapse pass 
after that.

I don't know how easy that would be, or if it would be worth it, but it 
would cover all platforms at that point.

-[Unknown]


Walter Bright wrote:
 == Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 I know it's been said a bazillion times already, but maybe we should
 look at replacing OPTLINK, and adding a "collapse identical code
 sections" option while we're at it.  :P
Fixing optlink is a worthy goal, but that is only one platform. D has to work with linkers on many platforms, and relying on such a solution existing across linkers we have no control over is not practical.
Apr 25 2009
prev sibling next sibling parent reply Christian Kamm <kamm-removethis andthis.incasoftware.andthis.de> writes:
Andrei Alexandrescu Wrote:
 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).
While I'd support such a rewriting of builtin arrays and associative arrays, it comes at a cost: one template instantiation per contained type, which will lead to more code and TypeInfo / ClassInfo initializers than the current implementation requires. Can you come up with a solution that can seamlessly switch between RTTI based containers and templated containers?
Apr 24 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christian Kamm wrote:
 Andrei Alexandrescu Wrote:
 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).
While I'd support such a rewriting of builtin arrays and associative arrays, it comes at a cost: one template instantiation per contained type, which will lead to more code and TypeInfo / ClassInfo initializers than the current implementation requires. Can you come up with a solution that can seamlessly switch between RTTI based containers and templated containers?
Good question. I don't know how the typeinfo could go away, but right now we're in that boat already - each T[] has its own typeinfo. Implementation-wise, there are techniques to reduce code bloating. Andrei
Apr 24 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 24 Apr 2009 11:57:45 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Christian Kamm wrote:
 Andrei Alexandrescu Wrote:
 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).
While I'd support such a rewriting of builtin arrays and associative arrays, it comes at a cost: one template instantiation per contained type, which will lead to more code and TypeInfo / ClassInfo initializers than the current implementation requires. Can you come up with a solution that can seamlessly switch between RTTI based containers and templated containers?
Good question. I don't know how the typeinfo could go away, but right now we're in that boat already - each T[] has its own typeinfo. Implementation-wise, there are techniques to reduce code bloating.
Yes, but each T[] does not have it's own sort routine. With a template, that would not be the case (I think). Not that I think the current way is the best, just pointing out a difference. -Steve
Apr 24 2009
prev sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Thu, 23 Apr 2009 13:58:38 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 [snip]
Yes please. D's GC sometimes just gets in the way, and you end up managing most memory manually. Just don't forget to have a version(nogc) ! -- Best regards, Vladimir mailto:thecybershadow gmail.com
Apr 24 2009