Hi Phil,
I don't have a reference to point you too. But from what I know I can tell
you the following:
The garbage collector itself is actually pretty stupid. It basically only
knows how to walk trees rooted at a certain point. These roots need to be
reported to the garbage collector with their physical memory address. These
reports are usually done by a jit compiler during memory layout of types
(for static members.) and by the "operating system" for the thread stacks.
(The alternative is that the GC is smart enough to enumerate all threads and
determine their stack.)
All variables on the stack and all "global" statics are considered a root.
Walking a type becomes a bit harder. In order for the GC to understand a
type it needs its layout information, which is ussually at the first DWORD
of an object. Which means that this structure there contains the runtime
type info, the memory layout of a type including all type members and their
data types and the vtable/itable for the type itself.
So the GC walks this type info and looks at the addresses and marks all
objects as visited and adds these seen objects again to a list of roots to
walk iteratively.
This so far considers all objects on the stack and all objects in a global
heap, but it does not consider the CPU registers. This one is actually
pretty easy: There's simply no type info for the registers. The problem with
registers is that you'd need to halt all threads, capture their registers
and process all objects instantly. If you let a thread continue to run you'd
work on dirty state. For that reason the registers are always considered as
roots. If the value of a register matches an address inside the object heap,
the object in that heap address is in use - there's nothing special to do
here. This found object is automatically marked as a root to iterate
further. There's no type info for registers, as the register use usually
highly fluctuates inside a method. There's certain assembly instructions,
which except their arguments in fixed registers - so you'll always end up
moving the registers around. It would simply cause too much management
overhead to keep track of that.
For the sake of moving or compacting garbage collectors, this ussually
occurs in two stages. The first one just collects the usage statistics and
the second one actually performs the collection and compacting operation. If
objects are moved around, you will freeze all threads instantly and visit
all registers and globals again. Since a garbage object can't become live
again (we don't have zombies fortunately) cleanup is easy. Movement is also
easy in most cases, as the compacting pass knows which addresses to update
from the collection phase. There's special care however for addresses which
have been updated in the meantime. And finally: A compacting allocator won't
move an object, if it is pointed to by a register - you never know if the
register is really a pointer or only an integral value, which unfortunately
matches a heap address. The last problem can be overcome however by using
specific registers only for specific purposes (again work of the native code
compiler.) Unfortunately on x86 we don't have enough registers to start with
so the last idea is virtually impossible, unless we use all CPU extensions
and move all integral data into the SSE/MMX registers.
I hope this clears up your questions.
Mike
P.S.: IMHO the compacting or moving GCs are a waste of CPU time.
_____
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Phil
Garcia
Gesendet: Mittwoch, 4. Juni 2008 17:50
An: [EMAIL PROTECTED];
sharpos-developers@lists.sourceforge.net
Betreff: [Ensemble-Dev] Garbage Collection
Does anyone have any good references for how garbage collection in an
managed environment handles walking the stack looking for active objects,
interacting multiple threads, and modifying the stack and cpu registers when
objects are moved in memory? I know the basics of GC, but not these finer
points.
Thanks,
Phil
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
