Is there a way to turn off the GC (Garbage Collector) in D?
What if I want to manage all the memory by myself? Is this possible?

Tom

"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
> Is there a way to turn off the GC (Garbage Collector) in D?

Sure. www.digitalmars.com/d/phobos/std_gc.html


> What if I want to manage all the memory by myself? Is this possible?

Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html

In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
>
>
>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
>> Is there a way to turn off the GC (Garbage Collector) in D?
>
>Sure. www.digitalmars.com/d/phobos/std_gc.html
>
>
>> What if I want to manage all the memory by myself? Is this possible?
>
>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>
>

When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
program and still wan´t to use new & delete operators, just like C++? (some kind
of conditional GC), can I do that?

Sorry for my ignorance, I'm already loving this language though...

Tom

In article <djqf6b$1p11$1@digitaldaemon.com>, Tomás Rossi says...
>
>In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
>>
>>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
>>> Is there a way to turn off the GC (Garbage Collector) in D?
>>
>>Sure. www.digitalmars.com/d/phobos/std_gc.html
>>
>>
>>> What if I want to manage all the memory by myself? Is this possible?
>>
>>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>>
>>
>
>When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
>refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
>program and still wan´t to use new & delete operators, just like C++? (some kind
>of conditional GC), can I do that?

D has some behind the scenes extern(C) callbacks for when new and delete are called, arrays are manipulated, etc--see phobos/internal/gc/gc.d for the bulk of them.  If don't want the default GC to be compiled with your program then you will need to suppy stub implementations for these functions.  It may be enough to simply call malloc/realloc/free as appropriate.


Sean

Tomás Rossi wrote:
> In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
> 
>>
>>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message
>>news:djj8qd$1ain$1@digitaldaemon.com...
>>
>>>Is there a way to turn off the GC (Garbage Collector) in D?
>>
>>Sure. www.digitalmars.com/d/phobos/std_gc.html
>>
>>
>>
>>>What if I want to manage all the memory by myself? Is this possible?
>>
>>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>>
>>
> 
> 
> When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
> refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
> program and still wan´t to use new & delete operators, just like C++? (some kind
> of conditional GC), can I do that? 
> 
> Sorry for my ignorance, I'm already loving this language though... 
> 
> Tom

I wrote a phobos patch way back in the long-long ago that's probably outdated now... but it is theoretically a very simple patch.  It simply ripped out the GC implementation and used C's malloc and free; naively I might add.  Most of phobos is coded with use of the GC in mind, and is quite memory-leaky without it.  All the GC related code is in src/phobos/internal/gc/.

In article <djrbki$la6$1@digitaldaemon.com>, James Dunne says...
>
>Tomás Rossi wrote:
>> In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
>> 
>>>
>>>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
>>>
>>>>Is there a way to turn off the GC (Garbage Collector) in D?
>>>
>>>Sure. www.digitalmars.com/d/phobos/std_gc.html
>>>
>>>
>>>
>>>>What if I want to manage all the memory by myself? Is this possible?
>>>
>>>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>>>
>>>
>> 
>> 
>> When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
>> refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
>> program and still wan´t to use new & delete operators, just like C++? (some kind
>> of conditional GC), can I do that?
>> 
>> Sorry for my ignorance, I'm already loving this language though...
>> 
>> Tom
>
>I wrote a phobos patch way back in the long-long ago that's probably outdated now... but it is theoretically a very simple patch.  It simply ripped out the GC implementation and used C's malloc and free; naively I might add.  Most of phobos is coded with use of the GC in mind, and is quite memory-leaky without it.  All the GC related code is in src/phobos/internal/gc/.

So, I'm tied to use GC if I want to take advantage of any of the Phobos benefits. GC will be there, compiled with the rest no matter if I use it or not. :'( that's so sad. I must admit i have issues... DON'T FULLY TRUST GARBAGE COLLECTORS YET.

On the other hand, i'm wondering, if D is a language that claims it can be used to write OSs (we all know OS code, or much of it, need to be very efficient), i dont think using GC in this code would be such a good idea. Probably OS would yet be implemented with malloc/free, because that way, you still have "some" control on what it happens... Ok, there is my mistrust in GC again. :P

Regards

Tom

In article <djs1hd$dkv$1@digitaldaemon.com>, Tomás Rossi says...
>
>In article <djrbki$la6$1@digitaldaemon.com>, James Dunne says...
>>
>>Tomás Rossi wrote:
>>> In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
>>> 
>>>>
>>>>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
>>>>
>>>>>Is there a way to turn off the GC (Garbage Collector) in D?
>>>>
>>>>Sure. www.digitalmars.com/d/phobos/std_gc.html
>>>>
>>>>
>>>>
>>>>>What if I want to manage all the memory by myself? Is this possible?
>>>>
>>>>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>>>>
>>>>
>>> 
>>> 
>>> When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
>>> refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
>>> program and still wan´t to use new & delete operators, just like C++? (some kind
>>> of conditional GC), can I do that?
>>> 
>>> Sorry for my ignorance, I'm already loving this language though...
>>> 
>>> Tom
>>
>>I wrote a phobos patch way back in the long-long ago that's probably outdated now... but it is theoretically a very simple patch.  It simply ripped out the GC implementation and used C's malloc and free; naively I might add.  Most of phobos is coded with use of the GC in mind, and is quite memory-leaky without it.  All the GC related code is in src/phobos/internal/gc/.
>
>So, I'm tied to use GC if I want to take advantage of any of the Phobos benefits. GC will be there, compiled with the rest no matter if I use it or not. :'( that's so sad. I must admit i have issues... DON'T FULLY TRUST GARBAGE COLLECTORS YET.
>
>On the other hand, i'm wondering, if D is a language that claims it can be used to write OSs (we all know OS code, or much of it, need to be very efficient), i dont think using GC in this code would be such a good idea. Probably OS would yet be implemented with malloc/free, because that way, you still have "some" control on what it happens... Ok, there is my mistrust in GC again. :P
>
>Regards
>
>Tom

Well, as stated before, with D you can use malloc/free as much as you want and even develop a lib. with non-GC'd functions when it makes sense (and take advantage of the GC for the rest) or for that matter just use C libraries when needed. With other contemporary languages like C# and Java you're much more limited in this area.

I used to feel the same about the GC as you do, but have come around to believe that a good GC can perform really well if the programmer doesn't abuse it.

The primary problem with Java and .Net software is that the GC *makes* it easy to 'abuse' and also because of some language of their features like not allowing OOP UDT's to be allocated on the stack as C++ and D do.

Don't take my word for it - get a Java or C# implementation with a mature allocator/GC system and benchmark allocating a bunch of strings and UDT objects with it, and then do the same with equivalent (heap alloc) code in C++. In many cases, the GC will perform at least as well -- even when enough memory is allocated to force a couple of GC's during the test.

D's GC is non-sophisticated because it is immature, but it'll improve to the level of the Java and C# GC's, probably very quickly after D 1.0 is released if not sooner.

Besides, D has things like stack-allocated UDT's, easy array slicing, overrideable new/delete and de/allocators and copy-on-write library functions that make things a lot easier on a GC than Java and/or .Net; so a slow GC is less likely to cause as many problems.

Tomás Rossi wrote:
> Is there a way to turn off the GC (Garbage Collector) in D?
> What if I want to manage all the memory by myself? Is this possible?
> 
> Tom

GC is not as much as a bottleneck as you might think. Write some memory intensive programs and compare them to C++.

In article <djs827$jjj$1@digitaldaemon.com>, Dave says...
>
>In article <djs1hd$dkv$1@digitaldaemon.com>, Tomás Rossi says...
>>
>>In article <djrbki$la6$1@digitaldaemon.com>, James Dunne says...
>>>
>>>Tomás Rossi wrote:
>>>> In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
>>>> 
>>>>>
>>>>>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
>>>>>
>>>>>>Is there a way to turn off the GC (Garbage Collector) in D?
>>>>>
>>>>>Sure. www.digitalmars.com/d/phobos/std_gc.html
>>>>>
>>>>>
>>>>>
>>>>>>What if I want to manage all the memory by myself? Is this possible?
>>>>>
>>>>>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>>>>>
>>>>>
>>>> 
>>>> 
>>>> When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
>>>> refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
>>>> program and still wan´t to use new & delete operators, just like C++? (some kind
>>>> of conditional GC), can I do that?
>>>> 
>>>> Sorry for my ignorance, I'm already loving this language though...
>>>> 
>>>> Tom
>>>
>>>I wrote a phobos patch way back in the long-long ago that's probably outdated now... but it is theoretically a very simple patch.  It simply ripped out the GC implementation and used C's malloc and free; naively I might add.  Most of phobos is coded with use of the GC in mind, and is quite memory-leaky without it.  All the GC related code is in src/phobos/internal/gc/.
>>
>>So, I'm tied to use GC if I want to take advantage of any of the Phobos benefits. GC will be there, compiled with the rest no matter if I use it or not. :'( that's so sad. I must admit i have issues... DON'T FULLY TRUST GARBAGE COLLECTORS YET.
>>
>>On the other hand, i'm wondering, if D is a language that claims it can be used to write OSs (we all know OS code, or much of it, need to be very efficient), i dont think using GC in this code would be such a good idea. Probably OS would yet be implemented with malloc/free, because that way, you still have "some" control on what it happens... Ok, there is my mistrust in GC again. :P
>>
>>Regards
>>
>>Tom
>
>Well, as stated before, with D you can use malloc/free as much as you want and even develop a lib. with non-GC'd functions when it makes sense (and take advantage of the GC for the rest) or for that matter just use C libraries when needed. With other contemporary languages like C# and Java you're much more limited in this area.
>
>I used to feel the same about the GC as you do, but have come around to believe that a good GC can perform really well if the programmer doesn't abuse it.
>
>The primary problem with Java and .Net software is that the GC *makes* it easy to 'abuse' and also because of some language of their features like not allowing OOP UDT's to be allocated on the stack as C++ and D do.

Do you mean that not allowing you to allocate your objects in the stack is the abuse? Is there another way you can abuse of GC?

>Don't take my word for it - get a Java or C# implementation with a mature allocator/GC system and benchmark allocating a bunch of strings and UDT objects with it, and then do the same with equivalent (heap alloc) code in C++. In many cases, the GC will perform at least as well -- even when enough memory is allocated to force a couple of GC's during the test.

I don't know if i can benchmark a compiled language (C++) vs. an intepreted one (like C# or Java). I mean, i really don't know if the results will really help me to extract any conclusions. Even though the comparisons between a GCd language and a non-GCd one would be done in that case, i wouldn't really know when the differences would be caused by GC or by the intrinsic efficiency due to compiled/interpreted nature of each language.

>D's GC is non-sophisticated because it is immature,

I didn't know this... but now that you warned me, i have to tell you: "that makes me feel so relieved!" :P

>but it'll improve to the
>level of the Java and C# GC's, probably very quickly after D 1.0 is released if
>not sooner.

Hope so.

>Besides, D has things like stack-allocated UDT's, easy array slicing, overrideable new/delete and de/allocators and copy-on-write library functions that make things a lot easier on a GC than Java and/or .Net; so a slow GC is less likely to cause as many problems.

Ok, i know i'm a little paranoid and obsessive about efficiency when programming, but all the other very nice features of D that you're referring to are just the ones that i like very much and that's why i'm worried about the features that makes me "distrust" of the language performance (e.g. the GC). I have no doubts i will make use of it (the GC) in the most of my future D projects, but it would be SO NICE if it could be completely turned off in a transparent way for other kind of projects (and also have a non-GC-based Phobos, i know this will not happen, it's an utopia, but luckily dreaming is still free) :D.

Regards



Tom

In article <djtcfe$1qr4$1@digitaldaemon.com>, Tomás Rossi says...
>
>In article <djs827$jjj$1@digitaldaemon.com>, Dave says...
>>
>>In article <djs1hd$dkv$1@digitaldaemon.com>, Tomás Rossi says...
>>>
>>>In article <djrbki$la6$1@digitaldaemon.com>, James Dunne says...
>>>>
>>>>Tomás Rossi wrote:
>>>>> In article <djjic8$1ipg$2@digitaldaemon.com>, Walter Bright says...
>>>>> 
>>>>>>
>>>>>>"Tomás Rossi" <Tomás_member@pathlink.com> wrote in message news:djj8qd$1ain$1@digitaldaemon.com...
>>>>>>
>>>>>>>Is there a way to turn off the GC (Garbage Collector) in D?
>>>>>>
>>>>>>Sure. www.digitalmars.com/d/phobos/std_gc.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>>What if I want to manage all the memory by myself? Is this possible?
>>>>>>
>>>>>>Yes. You can even use C's malloc/free. See www.digitalmars.com/d/memory.html
>>>>>>
>>>>>>
>>>>> 
>>>>> 
>>>>> When disabling GC (std.gc.disable()) I just inhibit the GC cycles but, what if I
>>>>> refuse to use the GC at all? what if I DON´T WANT the GC to be compiled with my
>>>>> program and still wan´t to use new & delete operators, just like C++? (some kind
>>>>> of conditional GC), can I do that?
>>>>> 
>>>>> Sorry for my ignorance, I'm already loving this language though...
>>>>> 
>>>>> Tom
>>>>
>>>>I wrote a phobos patch way back in the long-long ago that's probably outdated now... but it is theoretically a very simple patch.  It simply ripped out the GC implementation and used C's malloc and free; naively I might add.  Most of phobos is coded with use of the GC in mind, and is quite memory-leaky without it.  All the GC related code is in src/phobos/internal/gc/.
>>>
>>>So, I'm tied to use GC if I want to take advantage of any of the Phobos benefits. GC will be there, compiled with the rest no matter if I use it or not. :'( that's so sad. I must admit i have issues... DON'T FULLY TRUST GARBAGE COLLECTORS YET.
>>>
>>>On the other hand, i'm wondering, if D is a language that claims it can be used to write OSs (we all know OS code, or much of it, need to be very efficient), i dont think using GC in this code would be such a good idea. Probably OS would yet be implemented with malloc/free, because that way, you still have "some" control on what it happens... Ok, there is my mistrust in GC again. :P
>>>
>>>Regards
>>>
>>>Tom
>>
>>Well, as stated before, with D you can use malloc/free as much as you want and even develop a lib. with non-GC'd functions when it makes sense (and take advantage of the GC for the rest) or for that matter just use C libraries when needed. With other contemporary languages like C# and Java you're much more limited in this area.
>>
>>I used to feel the same about the GC as you do, but have come around to believe that a good GC can perform really well if the programmer doesn't abuse it.
>>
>>The primary problem with Java and .Net software is that the GC *makes* it easy to 'abuse' and also because of some language of their features like not allowing OOP UDT's to be allocated on the stack as C++ and D do.
>
>Do you mean that not allowing you to allocate your objects in the stack is the abuse? Is there another way you can abuse of GC?
>

Well, that's part of it - just about everything has to be allocated on the heap, but in C++ you can allocate class objects on the stack and D you can use structs for some OOP features (and you can in C# too). Most of the "abuse" is just because the GC makes it easy to "allocate and forget" about managing resources. I suppose this will happen with any GC, but with Java it's really been hard on its performance reputation.

>>Don't take my word for it - get a Java or C# implementation with a mature allocator/GC system and benchmark allocating a bunch of strings and UDT objects with it, and then do the same with equivalent (heap alloc) code in C++. In many cases, the GC will perform at least as well -- even when enough memory is allocated to force a couple of GC's during the test.
>
>I don't know if i can benchmark a compiled language (C++) vs. an intepreted one (like C# or Java). I mean, i really don't know if the results will really help me to extract any conclusions. Even though the comparisons between a GCd language and a non-GCd one would be done in that case, i wouldn't really know when the differences would be caused by GC or by the intrinsic efficiency due to compiled/interpreted nature of each language.
>

JIT's are getting pretty good, and since your dealing with heap allocation that will be the bottleneck so the comparison will tell you more about the allocator/GC than the machine code optimizations.

>>D's GC is non-sophisticated because it is immature,
>
>I didn't know this... but now that you warned me, i have to tell you: "that makes me feel so relieved!" :P
>
>>but it'll improve to the
>>level of the Java and C# GC's, probably very quickly after D 1.0 is released if
>>not sooner.
>
>Hope so.
>
>>Besides, D has things like stack-allocated UDT's, easy array slicing, overrideable new/delete and de/allocators and copy-on-write library functions that make things a lot easier on a GC than Java and/or .Net; so a slow GC is less likely to cause as many problems.
>
>Ok, i know i'm a little paranoid and obsessive about efficiency when

That's a good thing IMHO - I think "slowness" is a "bug" and usually a lot harder to fix than most other bugs once a large program is getting close to being done. Users complain about crashes, but they *bitch* about slowness <g>

>programming, but all the other very nice features of D that you're referring to are just the ones that i like very much and that's why i'm worried about the features that makes me "distrust" of the language performance (e.g. the GC). I have no doubts i will make use of it (the GC) in the most of my future D projects, but it would be SO NICE if it could be completely turned off in a transparent way for other kind of projects (and also have a non-GC-based Phobos, i know this will not happen, it's an utopia, but luckily dreaming is still free) :D.
>
>Regards
>
>
>
>Tom