[Gc] boehm port to Native Client

Elijah Taylor elijahtaylor at google.com
Mon Apr 18 11:30:55 PDT 2011


Hi Ivan,

If I can add a couple of functions to our pthread implementation
(pthread_getattr_np and pthread_getattr_getstack) then we should be able to
just use the GC_LINUX_THREADS version and take off the "!defined(NACL)".
 I'll let you know of my progress when I have something to report.

-Elijah

On Sat, Apr 16, 2011 at 1:48 AM, Ivan Maidanski <ivmai at mail.ru> wrote:

> Hi Elijah,
>
> Could you also provide GC_get_stack_base() implementation for NaCl? (just
> for the completeness of the port)
>
> Thanks.
>
> Sat, 22 Jan 2011 16:23:32 -0800 Elijah Taylor <elijahtaylor at google.com>:
>
> Hi Ivan,
>
> Sorry I haven't gotten back to you yet, I've been busy with other things
> this last week.  I'm planning on addressing the feedback you've given me so
> far in the next week, and I can send you a more detailed response to your
> other questions at that time.  Thanks for the help so far.
>
> -Elijah
>
>
> On Sat, Jan 22, 2011 at 9:09 AM, Ivan Maidanski <ivmai at mail.ru<http://sentmsg?compose&To=ivmai@mail.ru>
> > wrote:
>
>> Hi Elijah,
>>
>> Any progress or comments?
>>
>> Sat, 15 Jan 2011 15:36:47 +0300 Ivan Maidanski <ivmai at mail.ru<http://sentmsg?compose&To=ivmai@mail.ru>
>> >:
>>
>> > Hello Elijah,
>> >
>> > Fri, 14 Jan 2011 15:36:34 -0800 письмо от Elijah Taylor <
>> > elijahtaylor at google.com<http://sentmsg?compose&To=elijahtaylor@google.com>(sentmsg?compose&To=
>> elijahtaylor at google.com<http://sentmsg?compose&To=elijahtaylor@google.com>)
>> >:
>> >
>> > > 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<http://sentmsg?compose&To=ivmai@mail.ru>
>> > (sentmsg?compose&To=ivmai at mail.ru<http://sentmsg?compose&To=ivmai@mail.ru>)
>> > wrote:
>> > >
>> > > - the patch in  naclports repository contains a typo in a macro
>> definition
>> > > > (MAC_TYPE -> MACH_TYPE);
>> > >
>> > > Oops, will fix.
>> >
>> > Why not to leave MACH_TYPE as-is (e.g. "I386", etc.)? NaCl is a kind of
>> OS not
>> > a kind of machine hardware.
>> > Is eg. I386 defined for x86?
>> >
>> > Also, please add a mapping comment in gcconfig.h (around "Feel free to
>> add
>> > more clauses here").
>> >
>> > >
>> > > > - 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.
>> >
>> > Yes, I only meant the vanilla gc6.8 patch contains some more code (eg,
>> for
>> > PARALLEL_MARK) not present in 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_);
>> > > >
>> > >
>> > > 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.
>> >
>> > There should none "undef" (no other target undefining them).
>> >
>> > If mmap is supported by NaCl then it might be possible to support
>> > USE_M[UN]MAP.
>> >
>> > > > - 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.
>> >
>> > Ok, so MPROTECT_VDB (i.e., incremental/generation collection) is not
>> > supported.
>> >
>> > > > - 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/
>> > (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
>> > > me.
>> >
>> > http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/
>> > (For convenience, I have a recent snapshot as a tarball which I use for
>> my
>> > project -
>> > http://www.ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110107.tar.bz2)
>> >
>> > > - 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,as
>> > > 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.
>> >
>> > No, HEURISTIC2 won't work without signals, but there are other
>> alternatives:
>> > - if threads-support is on then is it possible to use
>> > USE_GET_STACKBASE_FOR_MAIN?;
>> > - is it possible to LINUX_STACKBOTTOM (if we are on real Linux)?
>> > - for NaCl on Cygwin, it might be possible to use
>> GC_get_[main_]stack_base
>> > based on __asm__ ("%fs:4").
>> >
>> > > > - 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.
>> >
>> > So, eg. DARWIN, GC_DARWIN_THREADS,  WIN32, CYGWIN, GC_WIN32_THREADS
>> won't ever
>> > be defined when building NaCl, right?
>> > Is GC_LINUX_THREADS defined when building NaCl with multi-threaded
>> support?
>> >
>> > I have very little knowledge of NaCl - could you briefly explain what
>> does
>> > stand for NaCl portability - is it possible to call Win32 API if I'm
>> compiling
>> > on Cygwin or should I use the NaCl API (and, thus, the compiled binary
>> code
>> > will run on any x86 target)?
>> >
>> > If NaCl is some kind of OS then LINUX, DARWIN, WIN32, etc shouldn't be
>> defined
>> > (even if __linux__ defined) if NACL.
>> > Same for GC_xxx_THREADS - I think GC_NACL_THREADS could be defined
>> instead of
>> > GC_LINUX_THREADS, etc.
>> >
>> > I also think that I386 and X86_64 should stay defined for respectively
>> the
>> > corresponding CPU type (I guess it is already for NaCl but i haven't
>> checked
>> > yet)
>> > I think there should be 2 ifdef NACL define OS_TYPE "NACL" ... sections
>> (one
>> > for every supported CPU).
>> >
>> > > > - 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)
>> >
>> > Ok. But what is eg. nacl_pre_syscall_hook() - a callback from the NaCl
>> > subsystem? (I guess this should be treated as GC public API)
>> >
>> > Of course, use STATIC or static where possible (all STATIC symbols start
>> with
>> > GC_, while static typically not).
>> > More tips: use GC_INNER and GC_EXTERN for internal global variables; use
>> > GC_INNER for internal 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.
>> >
>> > Most probably, it work w/o any porting afforts but it would be good to
>> port
>> > atomic_ops.c (similar to what I did for Win32-pthreads targets - see
>> > AO_USE_WIN32_PTHREADS, I guess you should add AO_USE_NACL macro testing
>> in
>> > that file (looks easy to add). I think it's worth doing first (and
>> submit me a
>> > separate patch for libatomics_op when done).
>> >
>> > What's about GC_HAVE_BUILTIN_BACKTRACE and GC_CAN_SAVE_CALL_STACKS? At
>> least,
>> > gc.h should be consistent with the GC implementation (I mean eg. if
>> > GC_HAVE_BUILTIN_BACKTRACE not supported then it shouldn't be defined in
>> gc.h
>> > regardless of __linux__, _MSC_VER, etc. provided  __native_client__).
>> Same for
>> > GC_ADD_CALLER, GC_RETURN_ADDR.
>> >
>> > Regards.
>> >
>> > > > 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<http://sentmsg?compose&To=elijahtaylor@google.com>
>> > (sentmsg?compose&To=elijahtaylor at google.com<http://sentmsg?compose&To=elijahtaylor@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/ (
>> 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...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20110418/61b55ceb/attachment-0001.htm


More information about the Gc mailing list