[Gc] boehm port to Native Client
elijahtaylor at google.com
Fri Jan 14 15:36:34 PST 2011
Thanks for taking a look, I'm pleasantly surprised by the level of detail
here. Specific replies inline:
On Fri, Jan 14, 2011 at 2:50 PM, Ivan Maidanski <ivmai at mail.ru> wrote:
- the patch in naclports repository contains a typo in a macro definition
> (MAC_TYPE -> MACH_TYPE);
Oops, will fix.
> - the patch in naclports repository looks more suitable for gc v72 than
> that for mono/libgc;
This patch is meant to be applied to vanilla gc6.8. The mono/libgc port is
already patched directly into mono's code repository.
> - 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_);
Ok, makes sense, I think I didn't realize this was a public header. Though
that explains why I had to add a test for __native_client__ (which is
defined in our toolchain). I'll fix this.
> - it's not clear why you need to explicitly undef STACK_GRAN, USE_M[UN]MAP,
> etc. in gcconfig.h;
I'll do some investigation, but IIRC these were needed at one point for me.
There's a good chance these may be unnecessary and vestigial.
> - is MPROTECT_VDB supported or not?;
Is MPROTECT_VDB equivalent to catching protection violations in the GC code?
If so, then no, we don't support anything like that right now. Protection
violation in NaCl == instant death.
> - if you you want to port gc72 please use the recent CVS snapshot (it would
> be easier to me to review and commit it);
I've been grabbing source from
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/ ... can you point me
to where I should be getting the latest? It's not immediately obvious to
- 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);
HEURISTIC2 will definitely not work for us as it wants to use a segfault to
detect running over the stack. I've set STACK_GRAN to 64K, so as long as
the stack doesn't grow beyond that size before GC_init, we should be ok,
right? The stack for the main thread right now in NaCl lives at a fixed
address usually, but that isn't guaranteed for all future time, so I'd
prefer not to hard code magic numbers here.
> - is the GC port compilable (and working) on other (non-Linux) platforms
> (eg., Cygwin);
Native Client is meant to be portable, so it should run on any x86 or x86-64
machine once it's built. In terms of building, I haven't built this gc port
personally on Mac or Windows, but I just checked our build bot logs and they
seem to be building ok on Mac and in Cygwin.
> - for non-static GC-internal symbols use GC_ prefix (eg. for
> - define SIG_SUSPEND to -1 (instead of 0) as it is returned by
> - 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);
I'll address these issues. (note that NaCl currently doesn't support shared
libs yet so your dll example won't happen, but I agree that these should be
treated like other public GC functions)
> - libatomic_ops does not use signals API (except for CAS emulation which is
> not used for x86/x64).
I think I saw sigprocmask and related functions and assumed the worst, but I
see now that's windows code. Looking at the x86 variants it looks like a
NaCl port of libatomic_ops is probably not going to be too bad. I'll look
into this eventually.
> PS. Let me not do the benefits analysis (probably someone else can do
Well, if the gc7.2 port is as easy as it's looking now, I think it's
probably worth doing it. I would still love to hear anyone chime in on the
benefits of gc7.2 vs 6.8 though :)
> Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <elijahtaylor at google.com>:
> > 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:
> http://code.google.com/p/naclports/. 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc