[M3devel] gc/barriers?

[Jay K]

 > Feel free to ask if you have questions.

 

On a different matter.... can you, um, explain garbage collection?
Specifically barriers?

And the five states? Are they just older/younger?

 

 

I understand "the generational hypothesis".

"Most objects die young".

 (Most objects could be stack allocated. :) )

 

And then there is a need to divide objects, at runtime, into older and younger.

 

And then, there is some need to notice pointers that cross generations?

That is, "old" usually includes no garbage, unless it has been changed since

the last check, and then needs a new check?

 

That is, a write barrier is a sort of copy-on-write, or notice-writes mechanism?

A write into a generation means the gc needs to check it?

 

That is, if you look at the Win32 GetWriteWatch API, that's what we are simulating sort of?

(or vice versa)?

 

I'm really guessing.

And this doesn't explain what, if anything, a read barrier is.

 

But then is meant by gray/impure/etc.?

 

Maybe checkin RTCollector.readme?

 

(note that read/write barriers are other things too -- ways to enforce

(relative) order of executation).

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091105/7250d260/attachment-0001.html>