Re: [Gc] boehm port to Native Client

Ivan Maidanski ivmai at
Fri Jan 14 14:50:42 PST 2011

Hi Elijah,

Some things (and questions) I could point you (and others) to at this moment:
- the patch in  naclports repository contains a typo in a macro definition (MAC_TYPE -> MACH_TYPE);
- the patch in  naclports repository looks more suitable for gc v72 than that for mono/libgc;
- gc_pthread_redirects.h (which is a public one) should not test NACL macro (or, at least, while less desirable, it should be prefixed with GC_);
- it's not clear why you need to explicitly undef STACK_GRAN, USE_M[UN]MAP, etc. in gcconfig.h;
- is MPROTECT_VDB supported or not?;
- if you you want to port gc72 please use the recent CVS snapshot (it would be easier to me to review and commit it);
- not sure that HEURISTIC1 really works reliably there (in short, HEURISTIC1 means you treat stack pointer at GC_init call as stack bottom - is it guaranteed that GC_init call is always done at higher stack addresses than any other GC call);
- is the GC port compilable (and working) on other (non-Linux) platforms (eg., Cygwin);
- for non-static GC-internal symbols use GC_ prefix (eg. for nacl_thread_parked);
- define SIG_SUSPEND to -1 (instead of 0) as it is returned by GC_get_suspend_signal;
- GC functions called from NaCl it self (eg, nacl_pre_syscall_hook) shoud be tagged with some attribute (like public GC functions are) both for code readability and to prevent that symbols stripping when compiled as a shared lib with -DGC_DLL);
- libatomic_ops does not use signals API (except for CAS emulation which is not used for x86/x64).

PS. Let me not do the benefits analysis (probably someone else can do this).


Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <elijahtaylor at>:

> Hi GC folks,

> I saw a little chatter in the archives related to porting libgc to Native Client, so I joined this list to share some details. I'm the engineer at Google who ported of libgc to Native Client for Mono. I've also included a patch for vanilla gc6.8 in our naclports repository: This version will be available to users that want to use libgc as part of their Native Client projects. 

> Before porting gc6.8 I had attempted to port one of the newer versions, gc7.2alpha4, but ran into snags. The largest snag right now I think is that gc 7+ includes libatomic_ops which will require some non-trivial effort in order to work under Native Client. Most notably we don't support signals; that was the biggest effort in porting libgc in the first place for NaCl, and I assume that will require the most work in porting libatomic_ops too. 

> Can someone give me the high level details of what kind of things we might be missing if we only support gc6.8 instead of the latest version? Because of our thread stopping implementation, we may not even benefit from some of the newer features. I just wanted to get a sense of what the benefits are of getting a newer version available for users. 

> -Elijah

More information about the Gc mailing list