Ilya Minkov wrote:

> std::auto_ptr??? Bwaaahahahaa! You're in the wrong newsgroup!

Well, I could have suggested boost::shared_ptr <g>

> I suggest you read: http://www.digitalmars.com/d/garbage.html http://www.digitalmars.com/d/memory.html

Thanks, I think that's what I was looking for.

> Gargbage collection engine is automatically started with the application. Then, you just allocate objects as usual, and need not take care of their deallocation, which may happen whenever the runtime decides so. The distructors are called whenever actual deallocation takes place. You can also deallocate objects by hand if you like, and you can temporily disable garbage collection.

> It has nothing to do with RAII at all, since RAII is conserned with allocation, not deallocation.

I disagree, RAII is useless if the resource acquisition in the constructor is not matched by resource release in the destructor.  The symmetry is what makes the idiom work, and avoids introducing all that nasty manual exception handling with try/finally.

RAII matters especially when you are dealing with resources other than memory, which are often more limitted such as file handles, mutex locks etc.  In these cases you really do want destruction to occur at the specified time and not when the garbage collector gets to it.  Given D supports RAII, it is important that garbage collection can be turned off for these reasons.

OTOH, garbage collection can be very useful in its own right, and certainly makes memory management with cyclic dependencies much easier (something traditionally quite problematic in C++)  Not that it is easy to write a garbage collector that collects cycles, but once written client code need never see the problem again <g>

I'm still not sure about mixing GC with non-GC languages, as it makes code-reading much more labour intensive.  If everything is GC, no problems, ignore those resources that aren't really leaking.  If there is no GC, then chase down everything that looks like a leak.  With a mix, you need to be alert for leaks all the time, and all that GC code will be sending alarm bells to the human parser as they read the code and continually reassure themself that a given 'leak' will in fact be collected.

OTOH, it might be really neat to simply pull the right tool out the toolbox to handle a given problem <g>

Until we have more experienced of mixed-mode environments on large scale projects, I'm trying to keep an open mind.

-- 
AlisdairM

> I disagree, RAII is useless if the resource acquisition in the constructor is not matched by resource release in the destructor.  The symmetry is what makes the idiom work, and avoids introducing all that nasty manual exception handling with try/finally.

There are normal classes and auto classes in D. Normal classes are always allocated on the heap, and auto classes always on the stack (with proper exact lifetime semantics). You can do RAII using them.

-fg

Walter wrote:
> 
> "Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EF69401.F1EC2F81@chello.at...
> > GC gives up knowledge about the memory blocks needed or unneeded. To regain this knowledge has a cost. That's my theoretical basis why I think that GC will always (statistically) be slower than good tradition memory management.
> 
> Many programs rarely ever need to free memory, gc can be a big win for them. Also, there is overhead involved in keeping track of who owns each chunk of memory.

I know this, but the majority of software needs freeing memory. It makes little sense to talk about special cases.

I don't want to be misunderstood:
   "GC has a cost"
doesn't mean
   "I don't want GC"
it means:
   "don't tell me that GC is free".

I don't think that current GC in D is good enough. If you think it is, I'll start benchmarking it.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

Georg Wrede wrote:
> If the impact of GC were 10% in speed, and if the choice of programmer meant a 20% difference in speed, shouldn't we choose and educate our staff better, instead of splitting hairs over GC/no GC.

People are so used to the GC/no GC conflict, that any argument is immediately seen as a pro or con argument.

My "GC has a cost" meant only what it says.

I agree with you. If we have a GC that has an average cost of 10% and a worst case cost of 30%, then I would be happy. I don't think that Java GC comes near, I know that D GC doesn't come near. There's a lot to do in GC development.

In this situation I just hate to hear "GC is free" and
even "GC may even be better".

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

In article <bd7aji$16q4$1@digitaldaemon.com>, Fabian Giesen says...
>
>> Still, I wouldn't feel comfortable writing the Linux kernel in D. Or a real-time system. But I sure wish I'll see the day when something convinces me I can do either or both in D with peace of mind.
>
>"Non-Compacting Memory Allocation and Real-Time Garbage Collection" Mark S. Johnstone, University of Texas, 1996 http://citeseer.nj.nec.com/255424.html
>
>May atleast convince you of the possibility (and gritty details :)
>of real-time garbage collection.

Yes! Thanks a lot! It did convince me of the possibility!

And, reading the paper, it did not seem much harder to write such an RT-GC than a regular GC. Most of the idea was about doing the Right Thing, and not doing something hairily elaborate.

This should be required reading for a lot of people.

Having this kind of GC in D would kick some butt when folks start seriously comparing languages for important projects.

I'd also be pretty sure that the folks at NASA would then use D for the Mars rovers and stuff, instead of OO-plain-C.

And rumor of this would be enough to crash Walter's D site. :-)

Helmut Leitner wrote:

> I know this, but the majority of software needs freeing memory. It makes little sense to talk about special cases.

The interesting cases are those that need to free unused memory (eg running 24/7) but maybe not right away.

> I don't want to be misunderstood:
>    "GC has a cost"
> doesn't mean
>    "I don't want GC"
> it means:
>    "don't tell me that GC is free".

Scheduled memory bookkeeping for a time the computer is less busy does not make GC free (overall) but it is effectively 'free-at-point-of-use', or actually better-than-free as there is less bookkeeping <g>

I agree that GC is not free, it is simply a matter of deferring the cost to when you can afford to pay it.  GC comes on credit <g>

-- 
AlisdairM
Team Thai Kingdom

> I don't want to be misunderstood:
>    "GC has a cost"
> doesn't mean
>    "I don't want GC"
> it means:
>    "don't tell me that GC is free".

As said, so does manual heap-based memory management :) (And a considerable one at that, some papers on allocator performance show that data-structure intensitive programs such as compilers tend to spend >20% of their overall runtime allocating and deallocating memory).

> I don't think that current GC in D is good enough.

I agree with that, and I also think the bad image of GC is partly due to the fact of most garbage collectors actually used in practice are far from state of the art. But then, Walter has already mentioned several times that his focus is currently on the compiler and not the runtime support.

-fg

"Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bd9rqm$1mde$1@digitaldaemon.com...
> > I don't think that current GC in D is good enough.
> I agree with that, and I also think the bad image of GC is partly due to the fact of most garbage collectors actually used in practice are far from state of the art. But then, Walter has already mentioned several times that his focus is currently on the compiler and not the runtime support.

You don't really need to wait for me, write a better gc! The one that's in there now aimed to simply work correctly and get D off the ground.

Walter wrote:
> 
> "Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bd9rqm$1mde$1@digitaldaemon.com...
> > > I don't think that current GC in D is good enough.
> > I agree with that, and I also think the bad image of GC is partly due to the fact of most garbage collectors actually used in practice are far from state of the art. But then, Walter has already mentioned several times that his focus is currently on the compiler and not the runtime support.
> 
> You don't really need to wait for me, write a better gc! The one that's in there now aimed to simply work correctly and get D off the ground.

Is it possible to replace or extend the current GC module?

If yes, what are the interfaces to the current system?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

> There are normal classes and auto classes in D. Normal classes are always allocated on the heap, and auto classes always on the stack (with proper exact lifetime semantics). You can do RAII using them.
> 
> -fg
> 

Auto classes are *not always* allocated on the stack. At least the spec doesn't say so.

<quote>
When an auto class reference goes out of scope, the destructor (if any) for
it is automatically called. This holds true even if the scope was exited via
a thrown exception.
<quote/>

In fact, current DMD always allocates auto classes on the gc-heap. The destructor is called when the reference goes out of scope, but the memory of auto classes is not freed immediately, instead it is released during normal garbage collection.



Farmer.