[Gc] boehm port to Native Client

Elijah Taylor elijahtaylor at google.com
Fri Jan 14 15:36:34 PST 2011

Hi Ivan,

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

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
https://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
> 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);

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
> this).
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 :)

> Regards.
> 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:
> https://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...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20110114/2d252d84/attachment.htm

More information about the Gc mailing list