[M3commit] CVS Update: cm3

[Antony Hosking]

CVSROOT:	/usr/cvs
Changes by:	hosking at birch.	14/04/29 22:33:09

Modified files:
	cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 

Log message:
	Don't grey filler objects, especially for zeroed pages, so as to avoid race
	with allocation, as follows:
	
	On Apr 29, 2014, at 1:10 AM, Peter McKinna <peter.mckinna at gmail.com> wrote:
	
	I think there's a small problem with the M3 Collector and I thought I'd run it
	past you. I have a fix but I'm not sure if its the correct way to go. If
	you're already aware of this problem please disregard this mail.
	
	When the allocator is under heavy load from a number of threads its possible
	that several threads are blocked in LockHeap inside AllocTraced. When
	LongAlloc returns (in the single running thread) with its newly zeroed page it
	enters the finally clause to unlock the heap. At that point another thread can
	run and relock the heap before the new pointer can return and be
	initialised. The other thread will then do a collection and promote the page
	of the newly allocated pointer. The problem is that during the collection both
	GrayBetween and CleanBetween get called which loop over all objects in that
	page. Since the typecode of Fill_1_type is zero these procedures treat all
	zero words as Fill_1_type types and ignore them except to set the dirty and
	gray flags. At the end of CleanBetween the gray flag is false but the dirty
	flag is true leaving a page full of 16_200000 values.
	
	When the original thread gets control back it returns a pointer to a non zero
	bunch of memory which is then initialised to some type. This can then lead to
	a segv if its an object containing references which are then dereferenced.