www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compile without GC support

reply Heinz <malagana15 yahoo.es> writes:
Hi, i'm a D newbie. I want to know how to compile an exe and a dll
without garbage collector. I never add code related to the GC but
when i compile my programs, Does the GC get included in my
resulting compilation, making mi file bigger?

Thanx.
Dec 09 2006
parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Heinz wrote:

 Hi, i'm a D newbie. I want to know how to compile an exe and a dll
 without garbage collector. I never add code related to the GC but
 when i compile my programs, Does the GC get included in my
 resulting compilation, making mi file bigger?
 
 Thanx.


Currently, there's no way to do this since the GC is part of the 
standard library, which always gets linked in.

You might want to take a look at Ares, which seperates the standard 
library and GC, from what I remember.

	-- Daniel
Dec 09 2006
parent reply Heinz <malagana15 yahoo.es> writes:
Thanks Daniel for your answer.
OK, the GC get always linked, so i'll get extra bytes in my files but, does this
mean that the GC is active (run) when i open my application or the GC is just a
simple bunch of functions that are never called?

Heinz
Dec 11 2006
parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Heinz wrote:

 Thanks Daniel for your answer.
 OK, the GC get always linked, so i'll get extra bytes in my files but, does
this
 mean that the GC is active (run) when i open my application or the GC is just a
 simple bunch of functions that are never called?
 
 Heinz


The GC is "run" in the sense that it is initialised when the application 
starts up.

However, what you have to understand is that the GC will not run a 
collection cycle UNLESS you attempt to 'new' some memory, and you've run 
out.  If you, for example, use C's malloc and free, then the GC won't 
ever be triggered.

(An exception to this is that when you quit, the GC runs a collection to 
clean up... I think.)

One other thing to keep in mind is that you can override the use of the 
GC on a per-class basis by overriding a class' 'new' member.  Lemme see 
if I can find the doc for it...

http://digitalmars.com/d/class.html#allocators

So, summary:

1. With stock DMD, the GC is always linked in.
2. The GC is always initialised on program startup.
3. The GC is used (by default) for the 'new' operator.
4. You can use a different allocator for 'new' on a per-class basis.
5. You can use any allocation scheme you like so long as you manually 
call it.
6. A collection is only run if you attempt to 'new' some memory, and 
there isn't enough free memory.

Hope that covers everything.

	-- Daniel
Dec 11 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Daniel Keep wrote:
<snip>

 The GC is "run" in the sense that it is initialised when the application 
 starts up.
 
 However, what you have to understand is that the GC will not run a 
 collection cycle UNLESS you attempt to 'new' some memory, and you've run 
 out.


There are a number of ways to trigger allocation of memory on the heap:
- using associative arrays
- setting .length of an array
- calling .dup on an array
- concatenating arrays with ~ or ~=
- maybe others....


 If you, for example, use C's malloc and free, then the GC won't 
 ever be triggered.
 
 (An exception to this is that when you quit, the GC runs a collection to 
 clean up... I think.)


It does seem to've changed since I last looked.

<snip>

 1. With stock DMD, the GC is always linked in.
 2. The GC is always initialised on program startup.
 3. The GC is used (by default) for the 'new' operator.
 4. You can use a different allocator for 'new' on a per-class basis.
 5. You can use any allocation scheme you like so long as you manually 
 call it.
 6. A collection is only run if you attempt to 'new' some memory, and 
 there isn't enough free memory.


I'd think it would make an effort to clean up so that it can reuse 
existing memory rather than claiming more and more from the OS.

Stewart.
Dec 16 2006