www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Disabling GC in D

reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
Is there a way to disable GC in D?
I am aware of the  nogc qualifier but I would like to completely 
disable GC for the whole app/library.

Regards
Dibyendu
Jan 21 2016
next sibling parent Brad Anderson <eco gnuk.net> writes:
On Thursday, 21 January 2016 at 21:54:36 UTC, Dibyendu Majumdar 
wrote:

 Is there a way to disable GC in D?
 I am aware of the  nogc qualifier but I would like to 
 completely disable GC for the whole app/library.

 Regards
 Dibyendu


GC.disable();

This prevents the garbage collector from running but your program 
will still allocate using the GC's managed memory (use the 
command line switch -vgc to see all the allocation points). It 
will just never free memory.
Jan 21 2016
prev sibling next sibling parent cym13 <cpicard openmailbox.org> writes:
On Thursday, 21 January 2016 at 21:54:36 UTC, Dibyendu Majumdar 
wrote:

 Is there a way to disable GC in D?
 I am aware of the  nogc qualifier but I would like to 
 completely disable GC for the whole app/library.

 Regards
 Dibyendu


You should read the core.memory.GC section ( 

have fine grained control over the GC if needed.
Jan 21 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Thu, 21 Jan 2016 21:54:36 +0000, Dibyendu Majumdar wrote:


 Is there a way to disable GC in D?
 I am aware of the  nogc qualifier but I would like to completely disable
 GC for the whole app/library.
 
 Regards Dibyendu


In order to suppress GC collections, you can call core.memory.GC.disable. 
This doesn't prevent you from allocating GC memory. You will have a 
memory leak if you use the GC at all.

Alternatively, if you never allocate GC memory, the GC will never run.

Finally, you can use gc_setProxy() with a a GC proxy you create. Have it 
throw an exception instead of allocating. That means you will get crashes 
instead of memory leaks if something uses the GC when it shouldn't.

gc_setProxy() and struct Proxy seem not to be part of the public runtime. 
You can copy the definitions into your own project -- they're listed as 
extern(C) to make that easier. This may tie you to specific DMD revisions 
in the case that the GC interface changes.
Jan 21 2016
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 21 January 2016 at 22:15:13 UTC, Chris Wright wrote:

 Finally, you can use gc_setProxy() with a a GC proxy you 
 create. Have it throw an exception instead of allocating. That 
 means you will get crashes instead of memory leaks if something 
 uses the GC when it shouldn't.

 gc_setProxy() and struct Proxy seem not to be part of the 
 public runtime. You can copy the definitions into your own 
 project -- they're listed as extern(C) to make that easier. 
 This may tie you to specific DMD revisions in the case that the 
 GC interface changes.


Thanks - I am looking for an option where no GC memory allocation 
is possible so above looks like the solution.

Regards
Jan 21 2016
parent reply cym13 <cpicard openmailbox.org> writes:
On Thursday, 21 January 2016 at 22:20:13 UTC, Dibyendu Majumdar 
wrote:

 On Thursday, 21 January 2016 at 22:15:13 UTC, Chris Wright 
 wrote:

 Finally, you can use gc_setProxy() with a a GC proxy you 
 create. Have it throw an exception instead of allocating. That 
 means you will get crashes instead of memory leaks if 
 something uses the GC when it shouldn't.

 gc_setProxy() and struct Proxy seem not to be part of the 
 public runtime. You can copy the definitions into your own 
 project -- they're listed as extern(C) to make that easier. 
 This may tie you to specific DMD revisions in the case that 
 the GC interface changes.


 Thanks - I am looking for an option where no GC memory 
 allocation is possible so above looks like the solution.

 Regards


Out of curiosity, why would you force not being able to allocate 
memory? I understand wanting to disable automatic collection of 
memory as it may pause the threads but an allocation through the 
GC is just like any other allocation.

Besides you don't need to disable allocations not to use the GC, 
you just need not to use the GC. What I mean by that is that if 
allocation is disabled and your code needs to allocate through 
the GC, your program will crash. So you'll design your code so 
that you don't allocate through the GC. But then as your code 
doesn't use the GC it doesn't matter wether allocation is 
possible or not. If your code doesn't use the GC then the GC 
isn't used, no collection, no pause, nothing. So I don't quite 
see the point of disabling allocation.

On the other hand disabling collection makes sense, you can still 
allocate if you need to (to allocate an exception or an error for 
example, in such case it doesn't matter much if memory is 
collected as the program terminates).

Sooo.... where's the catch?
Jan 21 2016
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 21 January 2016 at 22:34:43 UTC, cym13 wrote:

 Out of curiosity, why would you force not being able to 
 allocate memory?


Hi - I want to be sure that my code is not allocating memory via 
the GC allocator; but when shipping I don't need to disable GC - 
it is mostly a development check.

I want to manage all memory allocation manually via malloc/free.

Regards
Jan 21 2016
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Thu, Jan 21, 2016 at 10:43:31PM +0000, Dibyendu Majumdar via
Digitalmars-d-learn wrote:

 On Thursday, 21 January 2016 at 22:34:43 UTC, cym13 wrote:

Out of curiosity, why would you force not being able to allocate
memory?


 
 Hi - I want to be sure that my code is not allocating memory via the
 GC allocator; but when shipping I don't need to disable GC - it is
 mostly a development check.
 
 I want to manage all memory allocation manually via malloc/free.


Just write " nogc:" at the top of every module and the compiler will
tell you if there's a GC allocation anywhere.


T

-- 
Tech-savvy: euphemism for nerdy.
Jan 21 2016
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 21 January 2016 at 22:44:14 UTC, H. S. Teoh wrote:

 Hi - I want to be sure that my code is not allocating memory 
 via the GC allocator; but when shipping I don't need to 
 disable GC - it is mostly a development check.
 
 I want to manage all memory allocation manually via 
 malloc/free.


 Just write " nogc:" at the top of every module and the compiler 
 will tell you if there's a GC allocation anywhere.


Thanks!
Jan 21 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 21 January 2016 at 23:06:55 UTC, Dibyendu Majumdar 
wrote:

 On Thursday, 21 January 2016 at 22:44:14 UTC, H. S. Teoh wrote:

 Hi - I want to be sure that my code is not allocating memory 
 via the GC allocator; but when shipping I don't need to 
 disable GC - it is mostly a development check.
 
 I want to manage all memory allocation manually via 
 malloc/free.


 Just write " nogc:" at the top of every module and the 
 compiler will tell you if there's a GC allocation anywhere.


 Thanks!


You can also compile with -vgc and it will tell you where gc 
allocations are taking place.

```
import std.stdio;
void main() {
     int[] ints = new int[](10);
     for(int i=0; i<15; ++i)
         ints ~= i;
     writeln("Here be GC");
}
```

Compiling the above produces the following messages from the 
compiler:

alloc.d(3): vgc: 'new' causes GC allocation
alloc.d(5): vgc: operator ~= may cause GC allocation
Jan 21 2016
parent Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Friday, 22 January 2016 at 05:15:13 UTC, Mike Parker wrote:

 On Thursday, 21 January 2016 at 23:06:55 UTC, Dibyendu Majumdar 
 wrote:

 On Thursday, 21 January 2016 at 22:44:14 UTC, H. S. Teoh wrote:

 Hi - I want to be sure that my code is not allocating memory 
 via the GC allocator; but when shipping I don't need to 
 disable GC - it is mostly a development check.
 
 I want to manage all memory allocation manually via 
 malloc/free.






 You can also compile with -vgc and it will tell you where gc 
 allocations are taking place.


Thanks!
Jan 22 2016