Re: [Gc] Porting Mono's version of the garbage collector to a simple OS
ivmai at mail.ru
Mon Oct 25 12:05:41 PDT 2010
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
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?
> 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.
> - Michael "Kipp" Mudge
> Welch Allyn
> Software Engineer
> 315-554-4057 _______________________________________________
More information about the Gc