Hi,

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

Thanks,
Denis

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
>
>

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.

"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

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

"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.

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