Re: [Gc] Porting Mono's version of the garbage collector to a simple OS

[Ivan Maidanski]

hi, Michael!

Mon, 25 Oct 2010 14:21:30 -0400 MudgeMC at welchallyn.com:

> 
> I am a part of a group that is porting Mono, which includes its own modified
> version of the Boehm GC, to a micro-kernel called ThreadX. Can I get some
> suggestions on specifically what parts of code need to be changed to suit this
> OS?

Sure. (Hope you'd also prepare the patch for the unmodified BDWGC not only the mono-port)
 
> - There is poor support for signals, so we'd like to avoid using them.

Signals are used for determining threads' stack base, for suspending/resuming threads and, optionally, for supporting incremental collection (if MPROTECT_VDB defined).

> - The OS exposes the bounds of the used stack for each thread. (scan the stack)

Looks like the code that uses pthread_attr_getstack (eg. ECOS).

> - The OS can force another thread to sleep and delay signal processing. (stop
> the world)

Looks like GC_OPENBSD_THREADS (or GC_DARWIN_THREADS, or GC_WIN32_THREADS).
 
> - A fixed amount of RAM will be used and there is no MMU; just malloc. (use
> ECOS' tiny_sbrk?) 

Probably, calloc-based one is more flexible (see GET_MEM for NEXT/DOS4GW in gcconfig.h)

> Because of the above, I assume a lot of the signal code can be factored out. Am
> I right on this?

Yes.

> What is the appropriate way to do this?

Described above. (I'd suggest to first create single-threaded port based on the current BDWGC CSV snapshot.)

> Pointers to docs that
> address this specifically are appreciated too. 
> I am not subscribed to this list (at the moment), please be sure to include my
> email in the reply. 
> Thanks, 
> - Michael "Kipp" Mudge 
> Welch Allyn
> Software Engineer 
> 315-554-4057 _______________________________________________