www.digitalmars.com         C & C++   DMDScript  

D - GC deactivation

reply "zorro" <z z.com> writes:
Hi,

Is there a way to program without in D without the GC?

Thanks,
Denis
Nov 11 2002
next sibling parent "zorro" <z z.com> writes:
heu, I mean, in D without the GC....
Tired already :-(

"zorro" <z z.com> wrote in message news:aqq8ii$2crd$1 digitaldaemon.com...

 Hi,

 Is there a way to program without in D without the GC?

 Thanks,
 Denis
Nov 11 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
zorro wrote:


 Is there a way to program without in D without the GC?


You could avoid allocating anything or import the malloc/realloc/free 
symbols.  Or you can keep the GC from collecting using:

     import gc;

     gc.disable (); // Turn collecting off.
     gc.enable (); // Turn it on.

However, here's a dirty secret: it's ignored by the current collector. 
It doesn't matter much anyway, as the only time it runs the collector 
manually appears to be when it's out of memory, which will occur at the 
end of a long virtual memory swap.
Nov 12 2002
next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:aqqq3h$2v7r$1 digitaldaemon.com...

 zorro wrote:


 Is there a way to program without in D without the GC?


 You could avoid allocating anything or import the malloc/realloc/free
 symbols.  Or you can keep the GC from collecting using:

      import gc;

      gc.disable (); // Turn collecting off.
      gc.enable (); // Turn it on.

 However, here's a dirty secret: it's ignored by the current collector.
 It doesn't matter much anyway, as the only time it runs the collector
 manually appears to be when it's out of memory, which will occur at the
 end of a long virtual memory swap.


Which is a sad thing.

My problem with any non-ref-count GC implementation is that it assumes that
you have all the phisical/logical memory to spend. Which is not ethical
behaviour in a multitasking enviroment.
A D-compiled executable may hold a large chunk of garbage memory, disabling
other application to use the same memory for running more smoothly. Any real
GC should be somehow connected to the OS, and be notified, when other
processes need the garbage memory. IMHO, this is something current OS-s
don't support. So I am stuck with ref counting, or explicit deallocation.

Yours,
Sandor
Nov 13 2002
parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Sandor Hojtsy wrote:

You could avoid allocating anything or import the malloc/realloc/free
symbols.  Or you can keep the GC from collecting using:

     import gc;

     gc.disable (); // Turn collecting off.
     gc.enable (); // Turn it on.

However, here's a dirty secret: it's ignored by the current collector.
It doesn't matter much anyway, as the only time it runs the collector
manually appears to be when it's out of memory, which will occur at the
end of a long virtual memory swap.


 
 
 Which is a sad thing.
 
 My problem with any non-ref-count GC implementation is that it assumes that
 you have all the phisical/logical memory to spend. Which is not ethical
 behaviour in a multitasking enviroment.
 A D-compiled executable may hold a large chunk of garbage memory, disabling
 other application to use the same memory for running more smoothly. Any real
 GC should be somehow connected to the OS, and be notified, when other
 processes need the garbage memory. IMHO, this is something current OS-s
 don't support. So I am stuck with ref counting, or explicit deallocation.


OS level garbage collection is the ideal, but working, good kernel level 
  garbage collection has been a long time coming (dicounting LispOS), 
and I don't think that we will be able to count on it anytime soon. 
What is really needed, at this point, is more *real* control over the 
collector.  We should be able to specifty min and max heap sizes, 
collection intervals, collection increments, nursery size, etc.  The 
beltway system, which I mentioned in a previous post[1], presents a nice 
way of generalizing the frameworks of older collectors into a framework 
that can be switched about using run time variables.  It isn't a perfect 
system, by any means, since it's possible to form a leaky collector with 
it, but given good default values, the beginner would be able to avoid 
messing with it, and the advanced user would be able to read the docs 
well enough to avoid any major errors.  Maybe I'm just an obsessive 
performance freak, but I think that when large, critical pieces of 
software start getting written in D, it'll be that much easier if 
everyone doesn't have to rewrite the GC to get acceptable performance 
out of the app in the worst case.

Evan


1) http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/beltway-pldi-2002.pdf
Nov 13 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:aqqq3h$2v7r$1 digitaldaemon.com...

 It doesn't matter much anyway, as the only time it runs the collector
 manually appears to be when it's out of memory, which will occur at the
 end of a long virtual memory swap.


The collector will run in preference to getting more memory from the OS.
Only when it's wedged will it ask for more memory.
Nov 18 2002
parent sam41180 yahoo.com writes:
i think i differ from your thought about GC ,, it can becme active at any time i
have tried in one of my programs
i dont find any way of disabling gc
i user GC>KeepAlive(object)
to prevent GC from collecting required params passed to unmanaged code
Oct 25 2004