Re[4]: [Gc] boehm port to Native Client

Ivan Maidanski ivmai at mail.ru
Wed Feb 9 13:04:36 PST 2011


Hi Elijah,

I've ported libatomic_ops to NaCl.
The patch attached.

NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP

ChangeLog entries:
2011-02-09  Ivan Maidanski  <ivmai at mail.ru>

	* src/atomic_ops.c (AO_USE_NO_SIGNALS, AO_USE_NANOSLEEP): New
	macros.
	* src/atomic_ops.c (AO_USE_WIN32_PTHREADS): Imply
	AO_USE_NO_SIGNALS.
	* src/atomic_ops.c: Don't include signal.h if AO_USE_NO_SIGNALS.
	* src/atomic_ops.c: Include time.h if AO_USE_NANOSLEEP.
	* src/atomic_ops.c (AO_locks, AO_pause): Reformat the code.
	* src/atomic_ops.c (AO_pause): Use nanosleep() if
	AO_USE_NANOSLEEP.
	* src/atomic_ops.c (all_sigs, initialized,
	AO_compare_and_swap_emulation,
	AO_compare_double_and_swap_double_emulation): Use
	AO_USE_NO_SIGNALS instead of AO_USE_WIN32_PTHREADS.

Regards.

> > >
> > > Fri, 14 Jan 2011 15:36:34 -0800 письмо от Elijah Taylor <
> > > elijahtaylor at google.com (sentmsg?compose&To=elijahtaylor at 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
> > > (sentmsg?compose&To=ivmai at 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
> > > (sentmsg?compose&To=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/ (
> > 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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 3805 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20110210/17aa4709/attachment.obj


More information about the Gc mailing list