[Mono-dev] Monoco update

Paolo Molaro lupus at ximian.com
Thu May 3 11:47:57 EDT 2007


On 05/02/07 Tomi Valkeinen wrote:
> I updated Monoco (http://www.bat.org/~tomba/monoco.html) to work with svn 
> head of Mono. Behaviour of GC had changed a bit and it broke the 
> continuations (GC didn't follow an IntPtr in a managed object). I 

Yes, we are more strict now even with the conservative GC.

> While fixing the bug I started to think about how the continuations would 
> work with the new precice GC. I've understood that in the first phase the 
> new GC will scan stack conservatively. Is precise stack scanning something 
> that may happen in the distant future, or something that will 
> definitely come?

It will definitely come, though it won't be fully precise for a while.
At the beginning stack locations will be identified as:
1) precise reference (reference local vars allocated on the stack)
2) definitely non-references (non-reference local vars, ABI-specific
stack locations that can't contain managed references etc)
3) unknown (will be considered containing potentially pinning pointers,
this will include registers, spilling locations etc)

With time we'll reduce the amount of unknown locations further
(especially by tracking register contents).

> The same information that the GC uses to do a precise stack scan could 
> possibly be used to serialize continuations. Also currently the whole area 

Proper serialization needs a lot more data than that. Serialization as
"save the stack data and keep the GC happy" would work. I made you use
mono_gc_alloc_fixed() so that your code would work also on the moving GC
unchanged. Tracking the precise info will allow better GC behaviour with
the moving GC, but it will also be somewhat slower at saving coroutine
state.

> reserved for continuation's stack is scanned, even if it is known that 
> only part of the area contains real data. This is also something that I 
> hope I will get fixed with the new GC.

Yeah, for a while I wanted to add a GC description that keeps track also
of a pointer to a length, so at GC time the length of the memory area
is read from the pointer and only that area is scanned.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better



More information about the Mono-devel-list mailing list