Warp wrote:
>   Oh, you have discovered a method to completely avoid memory
> fragmentation? :-o Is it efficient?

Yes, and yes.

>   I think that the world would be very interested in hearing that
> method.

Go look up "compacting generational garbage collection" and get back to 
me. That you think this is something new tells me there's not much point 
in me discussing it with you.

>   Instead your non-fragmenting memory allocation engine knows by magic
> all the objects which are not used anymore and those which are,
> with no reference counts, with no going through allocated objects
> to see if anything points to them, with nothing?

No. Go read up on how garbage collection works. GIYF.

>   Ok, it doesn't work and it's slow.

Right.

>>>  Btw, how does the GC engine know that the object is not used anymore?

>>There are a number of ways, from simplistic to convoluted. Generally, GC 
>>engines assume they can find the live pointers.

>   Can't you give me even some idea?

So, the fact that I said "GC engines assume they can find the live 
pointers" doesn't give you an idea? I just told you how a GC engine 
knows an object isn't used any more - they base it on the fact that they 
can find the live pointers.

When a full GC is needed, they scan the tree of pointers starting at the 
root. This is called "mark and sweep". Primitive and slow, but functional.

Generational GC is an oldish technique. It's pretty efficient, based on 
normal programming usage. That is, it can be slow, but usually isn't, 
just like virtual memory can be slow for programs with no locality of 
reference, but usually isn't. It works by having several generations of 
collections. The newest generation is allocated as "unsaved." Whenever a 
pointer to something in generation 0 is assigned into an object in a 
higher generation, that gen-0 object is marked as "maybe live". (Note 
that that particular test is a trivial address comparison.) When 
generation 0 fills up, you walk all the objects that have that bit set 
(or which are in the linked list, or whatever), promote them to 
generation 1, and throw away everything you didn't promote. When that 
memory starts getting tight, you do the same with generation 1, from 
generation 2. Etc. This is complicated, of course, by finalization.

If you're actually interested in how (for example) Microsoft's GC works,
http://msdn.microsoft.com/msdnmag/issues/1100/gci/

Now, that wasn't hard to find, was it?

How about this one?
http://citeseer.ist.psu.edu/bacon03realtime.html
A realtime garbage collector with Low Overhead and Consistent 
Utilization for Java.  Good thing Java-style GC is so unpredictable, 
huh? So unpredictable you can plug in a real-time GC engine.

Now, since this hasn't anything to do with POV, let's take it to 
off-topic if you actually want to discuss it. But I have the feeling 
from your words here that you're more interested in arguing than 
actually learning anything. Maybe that's just a cultural thing, tho.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message