Discussion:
Re[4]: [Gc] boehm port to Native Client
(too old to reply)
Ivan Maidanski
2011-02-09 21:04:36 UTC
Permalink
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 <***@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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
- 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 <
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
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
Elijah Taylor
2011-02-09 21:20:47 UTC
Permalink
Oops, I replied to this message and attached a patch that put me over the
message size limit. Can someone who moderates this list push my message
through?
Post by Ivan Maidanski
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
* 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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
- 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 <
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
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
Ivan Maidanski
2011-02-09 21:23:46 UTC
Permalink
Hi,

Yes, config.sub is auto-generated (by autoreconf -vif), so please modify configure.ac, etc.

It is ok if you're going to produce a patch against that "floating" bdwgc snapshot (2011-01-07).
You don't need to hold off - just post a patch for the audience when ready.

I'll produce another snapshot in several days (collecting this and some other patches in).

PS If you hit the limit of this mailing list (around 30 KiB) - please cut it into 2 (or more) parts (don't wait for the moderator - even I have this limit).

Regards.
Hi Ivan,
Great, that looks very similar to my porting effort.
I also have a patch against the tarball that's been floating around on this
list (attached). I've been holding off on it until now waiting for
sourceforge access to come back online. I'm modifying some config.sub and
other config files which are distributed with a snapshot but I suspect when
they're built from source in the tree they're system files that can't be
modified, so we may have to change configure.in to compensate.
I've tested this patched libgc in Native Client and it seems to work well.
-Elijah
Post by Ivan Maidanski
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
* 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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
- 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 <
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
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
Elijah Taylor
2011-02-09 21:26:48 UTC
Permalink
Ok, I'll work on getting my config changes to the checked in configure
scripts and I'll post a patch then. In the meantime, at least you have the
patch I sent (not sure if anyone else on the list cares right now) so I
won't bother re-sending.
Post by Ivan Maidanski
Hi,
Yes, config.sub is auto-generated (by autoreconf -vif), so please modify configure.ac, etc.
It is ok if you're going to produce a patch against that "floating" bdwgc
snapshot (2011-01-07).
You don't need to hold off - just post a patch for the audience when ready.
I'll produce another snapshot in several days (collecting this and some other patches in).
PS If you hit the limit of this mailing list (around 30 KiB) - please cut
it into 2 (or more) parts (don't wait for the moderator - even I have this
limit).
Regards.
Hi Ivan,
Great, that looks very similar to my porting effort.
I also have a patch against the tarball that's been floating around on
this
list (attached). I've been holding off on it until now waiting for
sourceforge access to come back online. I'm modifying some config.sub
and
other config files which are distributed with a snapshot but I suspect
when
they're built from source in the tree they're system files that can't be
modified, so we may have to change configure.in to compensate.
I've tested this patched libgc in Native Client and it seems to work
well.
-Elijah
Post by Ivan Maidanski
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
* 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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level
of
Post by Ivan Maidanski
detail
On Fri, Jan 14, 2011 at 2:50 PM, Ivan Maidanski <
- 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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
to
add
more clauses here").
- the patch in naclports repository looks more suitable for
gc
Post by Ivan Maidanski
v72
than
that for mono/libgc;
This patch is meant to be applied to vanilla gc6.8. The
mono/libgc
Post by Ivan Maidanski
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
Post by Ivan Maidanski
NACL
macro
(or, at least, while less desirable, it should be prefixed
with
Post by Ivan Maidanski
GC_);
Ok, makes sense, I think I didn't realize this was a public
header.
Post by Ivan Maidanski
Though
that explains why I had to add a test for __native_client__
(which
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
supported.
- if you you want to port gc72 please use the recent CVS
snapshot
Post by Ivan Maidanski
(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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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,
Post by Ivan Maidanski
HEURISTIC1
means you treat stack pointer at GC_init call as stack bottom
-
Post by Ivan Maidanski
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
Post by Ivan Maidanski
long
as
the stack doesn't grow beyond that size before GC_init, we
should
Post by Ivan Maidanski
be
ok,as
right? The stack for the main thread right now in NaCl lives
at a
Post by Ivan Maidanski
fixed
address usually, but that isn't guaranteed for all future time,
so
Post by Ivan Maidanski
I'd
prefer not to hard code magic numbers here.
No, HEURISTIC2 won't work without signals, but there are other
- 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)
Post by Ivan Maidanski
platforms
(eg., Cygwin);
Native Client is meant to be portable, so it should run on any
x86
Post by Ivan Maidanski
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
Post by Ivan Maidanski
and
they
seem to be building ok on Mac and in Cygwin.
So, eg. DARWIN, GC_DARWIN_THREADS, WIN32, CYGWIN,
GC_WIN32_THREADS
Post by Ivan Maidanski
won't
ever
be defined when building NaCl, right?
Is GC_LINUX_THREADS defined when building NaCl with
multi-threaded
Post by Ivan Maidanski
support?
I have very little knowledge of NaCl - could you briefly explain
what
Post by Ivan Maidanski
does
stand for NaCl portability - is it possible to call Win32 API if
I'm
Post by Ivan Maidanski
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
Post by Ivan Maidanski
be
defined
(even if __linux__ defined) if NACL.
Same for GC_xxx_THREADS - I think GC_NACL_THREADS could be
defined
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
for
code
readability and to prevent that symbols stripping when
compiled
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
start
with
GC_, while static typically not).
More tips: use GC_INNER and GC_EXTERN for internal global
variables;
Post by Ivan Maidanski
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
to
port
atomic_ops.c (similar to what I did for Win32-pthreads targets -
see
Post by Ivan Maidanski
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
Post by Ivan Maidanski
submit
me a
separate patch for libatomics_op when done).
What's about GC_HAVE_BUILTIN_BACKTRACE and
GC_CAN_SAVE_CALL_STACKS?
Post by Ivan Maidanski
At
least,
gc.h should be consistent with the GC implementation (I mean eg.
if
Post by Ivan Maidanski
GC_HAVE_BUILTIN_BACKTRACE not supported then it shouldn't be
defined
Post by Ivan Maidanski
in
gc.h
regardless of __linux__, _MSC_VER, etc. provided
__native_client__).
Post by Ivan Maidanski
Same for
GC_ADD_CALLER, GC_RETURN_ADDR.
Regards.
PS. Let me not do the benefits analysis (probably someone
else
Post by Ivan Maidanski
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
Post by Ivan Maidanski
in on
the
benefits of gc7.2 vs 6.8 though
Regards.
Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <
Hi GC folks,
I saw a little chatter in the archives related to porting
libgc
Post by Ivan Maidanski
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
Post by Ivan Maidanski
included a
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
Post by Ivan Maidanski
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
Post by Ivan Maidanski
effort in
order to work under Native Client. Most notably we don't
support
Post by Ivan Maidanski
signals;
that was the biggest effort in porting libgc in the first
place
Post by Ivan Maidanski
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
Post by Ivan Maidanski
version?
Because of our thread stopping implementation, we may not
even
Post by Ivan Maidanski
benefit
from
some of the newer features. I just wanted to get a sense of
what
Post by Ivan Maidanski
the
benefits are of getting a newer version available for users.
-Elijah
Ivan Maidanski
2011-02-17 07:28:14 UTC
Permalink
Hi Elijah,

configure.ac should be modified to define AO_USE_NO_SIGNALS and AO_USE_NANOSLEEP for NaCl.

But, in fact, atomic_ops.c is not used by BDWGC since all is handled in *.h of libatomic_ops.

Regards.
Hi Ivan,
This patch has one problem, AO_USE_NANOSLEEP isn't defined for Native
Client. When I conditionally define it based on __native_client__ in
atomic_ops.c it works. Where is the best place to define something like
that, is atomic_ops.c ok?
-Elijah
Post by Ivan Maidanski
Hi Elijah,
Please test the attached patch (against the latest CVS [Feb 13]).
Note: the patch has been created with -b option for easier reading.
I have no time to check it today.
Regards.
Post by Elijah Taylor
Ok, I'll work on getting my config changes to the checked in configure
scripts and I'll post a patch then. In the meantime, at least you have
the
Post by Elijah Taylor
patch I sent (not sure if anyone else on the list cares right now) so I
won't bother re-sending.
Post by Ivan Maidanski
Hi,
Yes, config.sub is auto-generated (by autoreconf -vif), so please
modify
Post by Elijah Taylor
Post by Ivan Maidanski
configure.ac, etc.
It is ok if you're going to produce a patch against that "floating"
bdwgc
Post by Elijah Taylor
Post by Ivan Maidanski
snapshot (2011-01-07).
You don't need to hold off - just post a patch for the audience when
ready.
Post by Elijah Taylor
Post by Ivan Maidanski
I'll produce another snapshot in several days (collecting this and some
other patches in).
PS If you hit the limit of this mailing list (around 30 KiB) - please
cut
Post by Elijah Taylor
Post by Ivan Maidanski
it into 2 (or more) parts (don't wait for the moderator - even I have
this
Post by Elijah Taylor
Post by Ivan Maidanski
limit).
Regards.
Hi Ivan,
Great, that looks very similar to my porting effort.
I also have a patch against the tarball that's been floating around
on
Post by Elijah Taylor
Post by Ivan Maidanski
this
list (attached). I've been holding off on it until now waiting for
sourceforge access to come back online. I'm modifying some
config.sub
Post by Elijah Taylor
Post by Ivan Maidanski
and
other config files which are distributed with a snapshot but I
suspect
Post by Elijah Taylor
Post by Ivan Maidanski
when
they're built from source in the tree they're system files that can't
be
Post by Elijah Taylor
Post by Ivan Maidanski
modified, so we may have to change configure.in to compensate.
I've tested this patched libgc in Native Client and it seems to work
well.
-Elijah
Post by Ivan Maidanski
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
New
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
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.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
* 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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the
level
Post by Elijah Taylor
Post by Ivan Maidanski
of
Post by Ivan Maidanski
detail
On Fri, Jan 14, 2011 at 2:50 PM, Ivan Maidanski <
- the patch in naclports repository contains a typo in a
macro
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
definition
(MAC_TYPE -> MACH_TYPE);
Oops, will fix.
Why not to leave MACH_TYPE as-is (e.g. "I386", etc.)? NaCl is
a
Post by Elijah Taylor
Post by Ivan Maidanski
kind
Post by Ivan Maidanski
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
Post by Elijah Taylor
Post by Ivan Maidanski
free
Post by Ivan Maidanski
to
add
more clauses here").
- the patch in naclports repository looks more suitable
for
Post by Elijah Taylor
Post by Ivan Maidanski
gc
Post by Ivan Maidanski
v72
than
that for mono/libgc;
This patch is meant to be applied to vanilla gc6.8. The
mono/libgc
Post by Ivan Maidanski
port is
already patched directly into mono's code repository.
Yes, I only meant the vanilla gc6.8 patch contains some more
code
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
(eg,
for
PARALLEL_MARK) not present in mono/libgc.
- gc_pthread_redirects.h (which is a public one) should
not
Post by Elijah Taylor
Post by Ivan Maidanski
test
Post by Ivan Maidanski
NACL
macro
(or, at least, while less desirable, it should be
prefixed
Post by Elijah Taylor
Post by Ivan Maidanski
with
Post by Ivan Maidanski
GC_);
Ok, makes sense, I think I didn't realize this was a public
header.
Post by Ivan Maidanski
Though
that explains why I had to add a test for __native_client__
(which
Post by Ivan Maidanski
is
defined in our toolchain). I'll fix this.
- it's not clear why you need to explicitly undef
STACK_GRAN,
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
USE_M[UN]MAP,
etc. in gcconfig.h;
I'll do some investigation, but IIRC these were needed at
one
Post by Elijah Taylor
Post by Ivan Maidanski
point
Post by Ivan Maidanski
for
me.
There's a good chance these may be unnecessary and
vestigial.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
There should none "undef" (no other target undefining them).
If mmap is supported by NaCl then it might be possible to
support
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
USE_M[UN]MAP.
- is MPROTECT_VDB supported or not?;
Is MPROTECT_VDB equivalent to catching protection
violations in
Post by Elijah Taylor
Post by Ivan Maidanski
the
Post by Ivan Maidanski
GC
code?
If so, then no, we don't support anything like that right
now.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
Protection
violation in NaCl == instant death.
Ok, so MPROTECT_VDB (i.e., incremental/generation collection)
is
Post by Elijah Taylor
Post by Ivan Maidanski
not
Post by Ivan Maidanski
supported.
- if you you want to port gc72 please use the recent CVS
snapshot
Post by Ivan Maidanski
(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/)
...
Post by Elijah Taylor
Post by Ivan Maidanski
can
Post by Ivan Maidanski
you
point
me
to where I should be getting the latest? It's not
immediately
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
obvious
to
me.
http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/
(For convenience, I have a recent snapshot as a tarball which
I
Post by Elijah Taylor
Post by Ivan Maidanski
use
Post by Ivan Maidanski
for
my
project -
http://www.ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110107.tar.bz2)
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
- not sure that HEURISTIC1 really works reliably there (in
short,
Post by Ivan Maidanski
HEURISTIC1
means you treat stack pointer at GC_init call as stack
bottom
Post by Elijah Taylor
Post by Ivan Maidanski
-
Post by Ivan Maidanski
is it
guaranteed that GC_init call is always done at higher
stack
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
addresses
than
any other GC call);
HEURISTIC2 will definitely not work for us as it wants to
use a
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
segfault to
detect running over the stack. I've set STACK_GRAN to 64K,
so
Post by Elijah Taylor
Post by Ivan Maidanski
as
Post by Ivan Maidanski
long
as
the stack doesn't grow beyond that size before GC_init, we
should
Post by Ivan Maidanski
be
ok,as
right? The stack for the main thread right now in NaCl
lives
Post by Elijah Taylor
Post by Ivan Maidanski
at a
Post by Ivan Maidanski
fixed
address usually, but that isn't guaranteed for all future
time,
Post by Elijah Taylor
Post by Ivan Maidanski
so
Post by Ivan Maidanski
I'd
prefer not to hard code magic numbers here.
No, HEURISTIC2 won't work without signals, but there are
other
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
- 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)?
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
- 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)
Post by Ivan Maidanski
platforms
(eg., Cygwin);
Native Client is meant to be portable, so it should run on
any
Post by Elijah Taylor
Post by Ivan Maidanski
x86
Post by Ivan Maidanski
or
x86-64
machine once it's built. In terms of building, I haven't
built
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
this gc
port
personally on Mac or Windows, but I just checked our build
bot
Post by Elijah Taylor
Post by Ivan Maidanski
logs
Post by Ivan Maidanski
and
they
seem to be building ok on Mac and in Cygwin.
So, eg. DARWIN, GC_DARWIN_THREADS, WIN32, CYGWIN,
GC_WIN32_THREADS
Post by Ivan Maidanski
won't
ever
be defined when building NaCl, right?
Is GC_LINUX_THREADS defined when building NaCl with
multi-threaded
Post by Ivan Maidanski
support?
I have very little knowledge of NaCl - could you briefly
explain
Post by Elijah Taylor
Post by Ivan Maidanski
what
Post by Ivan Maidanski
does
stand for NaCl portability - is it possible to call Win32 API
if
Post by Elijah Taylor
Post by Ivan Maidanski
I'm
Post by Ivan Maidanski
compiling
on Cygwin or should I use the NaCl API (and, thus, the
compiled
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
binary
code
will run on any x86 target)?
If NaCl is some kind of OS then LINUX, DARWIN, WIN32, etc
shouldn't
Post by Ivan Maidanski
be
defined
(even if __linux__ defined) if NACL.
Same for GC_xxx_THREADS - I think GC_NACL_THREADS could be
defined
Post by Ivan Maidanski
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
Post by Ivan Maidanski
checked
yet)
I think there should be 2 ifdef NACL define OS_TYPE "NACL"
...
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
sections
(one
for every supported CPU).
- for non-static GC-internal symbols use GC_ prefix (eg.
for
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
nacl_thread_parked);
- define SIG_SUSPEND to -1 (instead of 0) as it is
returned
Post by Elijah Taylor
Post by Ivan Maidanski
by
Post by Ivan Maidanski
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)
Post by Elijah Taylor
Post by Ivan Maidanski
both
Post by Ivan Maidanski
for
code
readability and to prevent that symbols stripping when
compiled
Post by Ivan Maidanski
as a
shared
lib with -DGC_DLL);
I'll address these issues. (note that NaCl currently
doesn't
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
support
shared
libs yet so your dll example won't happen, but I agree that
these
Post by Ivan Maidanski
should be
treated like other public GC functions)
Ok. But what is eg. nacl_pre_syscall_hook() - a callback from
the
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
NaCl
subsystem? (I guess this should be treated as GC public API)
Of course, use STATIC or static where possible (all STATIC
symbols
Post by Ivan Maidanski
start
with
GC_, while static typically not).
More tips: use GC_INNER and GC_EXTERN for internal global
variables;
Post by Ivan Maidanski
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
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
worst,
but I
see now that's windows code. Looking at the x86 variants
it
Post by Elijah Taylor
Post by Ivan Maidanski
looks
Post by Ivan Maidanski
like
a
NaCl port of libatomic_ops is probably not going to be too
bad.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
I'll
look
into this eventually.
Most probably, it work w/o any porting afforts but it would
be
Post by Elijah Taylor
Post by Ivan Maidanski
good
Post by Ivan Maidanski
to
port
atomic_ops.c (similar to what I did for Win32-pthreads
targets -
Post by Elijah Taylor
Post by Ivan Maidanski
see
Post by Ivan Maidanski
AO_USE_WIN32_PTHREADS, I guess you should add AO_USE_NACL
macro
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
testing
in
that file (looks easy to add). I think it's worth doing first
(and
Post by Ivan Maidanski
submit
me a
separate patch for libatomics_op when done).
What's about GC_HAVE_BUILTIN_BACKTRACE and
GC_CAN_SAVE_CALL_STACKS?
Post by Ivan Maidanski
At
least,
gc.h should be consistent with the GC implementation (I mean
eg.
Post by Elijah Taylor
Post by Ivan Maidanski
if
Post by Ivan Maidanski
GC_HAVE_BUILTIN_BACKTRACE not supported then it shouldn't be
defined
Post by Ivan Maidanski
in
gc.h
regardless of __linux__, _MSC_VER, etc. provided
__native_client__).
Post by Ivan Maidanski
Same for
GC_ADD_CALLER, GC_RETURN_ADDR.
Regards.
PS. Let me not do the benefits analysis (probably someone
else
Post by Ivan Maidanski
can do
this).
Well, if the gc7.2 port is as easy as it's looking now, I
think
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
it's
probably worth doing it. I would still love to hear anyone
chime
Post by Ivan Maidanski
in on
the
benefits of gc7.2 vs 6.8 though
Regards.
Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <
Hi GC folks,
I saw a little chatter in the archives related to
porting
Post by Elijah Taylor
Post by Ivan Maidanski
libgc
Post by Ivan Maidanski
to
Native
Client, so I joined this list to share some details. I'm
the
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
engineer
at
Google who ported of libgc to Native Client for Mono.
I've
Post by Elijah Taylor
Post by Ivan Maidanski
also
Post by Ivan Maidanski
included a
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
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
projects.
Before porting gc6.8 I had attempted to port one of the
newer
Post by Ivan Maidanski
versions,
gc7.2alpha4, but ran into snags. The largest snag right
now I
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
think
is
that
gc 7+ includes libatomic_ops which will require some
non-trivial
Post by Ivan Maidanski
effort in
order to work under Native Client. Most notably we don't
support
Post by Ivan Maidanski
signals;
that was the biggest effort in porting libgc in the first
place
Post by Ivan Maidanski
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
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
things
we
might be missing if we only support gc6.8 instead of the
latest
Post by Ivan Maidanski
version?
Because of our thread stopping implementation, we may not
even
Post by Ivan Maidanski
benefit
from
some of the newer features. I just wanted to get a sense
of
Post by Elijah Taylor
Post by Ivan Maidanski
what
Post by Ivan Maidanski
the
benefits are of getting a newer version available for
users.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
-Elijah
Elijah Taylor
2011-02-09 21:14:56 UTC
Permalink
Hi Ivan,

Great, that looks very similar to my porting effort.

I also have a patch against the tarball that's been floating around on this
list (attached). I've been holding off on it until now waiting for
sourceforge access to come back online. I'm modifying some config.sub and
other config files which are distributed with a snapshot but I suspect when
they're built from source in the tree they're system files that can't be
modified, so we may have to change configure.in to compensate.

I've tested this patched libgc in Native Client and it seems to work well.

-Elijah
Post by Ivan Maidanski
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
* 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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
- 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 <
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
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
Ivan Maidanski
2011-02-20 13:21:24 UTC
Permalink
Hi Elijah,

I've finally finished with NaCl port. I've committed the patch (with some minor modifications). Please test it.

I found a number of bugs in the recent NaCl SDK (native_client_sdk_0_1_721_0 for Win32) - for most of them workaround is possible via -D option:
1. -m64 should be always specified with nacl64-gcc (and should not be specified with nacl-gcc) - typically -m32/m64 selects the compilation target but in NaCl SDK it only influences some predefined macros;
2. pthread.h: pthread_create lacks const for attr argument (to workaround use -DGC_PTHREAD_CONST= );
3. pthread.h: pthread_exit lacks __noreturn__ attribute (to workaround use -DGC_PTHREAD_EXIT_ATTRIBUTE= );
4. sys/features.h: _POSIX_TIMERS is not defined for NaCl (to workaround use -D_POSIX_TIMERS);
5. 64-bit GCC (nacl64-gcc (GCC) 4.4.3 20110124 (Native Client r4216)) produces incorrect code for "xaddq %0, %1" in AO_fetch_and_add_full in gcc/x86_64.h - it substitutes %0 with %eax instead of %rax (AO_fetch_and_add is used eg. in mallocx.c if PARALLEL_MARK).
Post by Ivan Maidanski
Hi Elijah,
configure.ac should be modified to define AO_USE_NO_SIGNALS and
AO_USE_NANOSLEEP for NaCl.
But, in fact, atomic_ops.c is not used by BDWGC since all is handled in *.h of
libatomic_ops.
Regards.
Hi Ivan,
This patch has one problem, AO_USE_NANOSLEEP isn't defined for Native
Client. When I conditionally define it based on __native_client__ in
atomic_ops.c it works. Where is the best place to define something like
that, is atomic_ops.c ok?
-Elijah
Post by Ivan Maidanski
Hi Elijah,
Please test the attached patch (against the latest CVS [Feb 13]).
Note: the patch has been created with -b option for easier reading.
I have no time to check it today.
Regards.
Post by Elijah Taylor
Ok, I'll work on getting my config changes to the checked in configure
scripts and I'll post a patch then. In the meantime, at least you have
the
Post by Elijah Taylor
patch I sent (not sure if anyone else on the list cares right now) so I
won't bother re-sending.
Post by Ivan Maidanski
Hi,
Yes, config.sub is auto-generated (by autoreconf -vif), so please
modify
Post by Elijah Taylor
Post by Ivan Maidanski
configure.ac, etc.
It is ok if you're going to produce a patch against that "floating"
bdwgc
Post by Elijah Taylor
Post by Ivan Maidanski
snapshot (2011-01-07).
You don't need to hold off - just post a patch for the audience when
ready.
Post by Elijah Taylor
Post by Ivan Maidanski
I'll produce another snapshot in several days (collecting this and
some
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
other patches in).
PS If you hit the limit of this mailing list (around 30 KiB) - please
cut
Post by Elijah Taylor
Post by Ivan Maidanski
it into 2 (or more) parts (don't wait for the moderator - even I have
this
Post by Elijah Taylor
Post by Ivan Maidanski
limit).
Regards.
Hi Ivan,
Great, that looks very similar to my porting effort.
I also have a patch against the tarball that's been floating around
on
Post by Elijah Taylor
Post by Ivan Maidanski
this
list (attached). I've been holding off on it until now waiting for
sourceforge access to come back online. I'm modifying some
config.sub
Post by Elijah Taylor
Post by Ivan Maidanski
and
other config files which are distributed with a snapshot but I
suspect
Post by Elijah Taylor
Post by Ivan Maidanski
when
they're built from source in the tree they're system files that
can't
Post by Ivan Maidanski
be
Post by Elijah Taylor
Post by Ivan Maidanski
modified, so we may have to change configure.in to compensate.
I've tested this patched libgc in Native Client and it seems to work
well.
-Elijah
Post by Ivan Maidanski
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
New
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
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.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
* 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 <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the
level
Post by Elijah Taylor
Post by Ivan Maidanski
of
Post by Ivan Maidanski
detail
On Fri, Jan 14, 2011 at 2:50 PM, Ivan Maidanski <
- the patch in naclports repository contains a typo in a
macro
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
definition
(MAC_TYPE -> MACH_TYPE);
Oops, will fix.
Why not to leave MACH_TYPE as-is (e.g. "I386", etc.)? NaCl
is
Post by Ivan Maidanski
a
Post by Elijah Taylor
Post by Ivan Maidanski
kind
Post by Ivan Maidanski
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
Post by Elijah Taylor
Post by Ivan Maidanski
free
Post by Ivan Maidanski
to
add
more clauses here").
- the patch in naclports repository looks more suitable
for
Post by Elijah Taylor
Post by Ivan Maidanski
gc
Post by Ivan Maidanski
v72
than
that for mono/libgc;
This patch is meant to be applied to vanilla gc6.8. The
mono/libgc
Post by Ivan Maidanski
port is
already patched directly into mono's code repository.
Yes, I only meant the vanilla gc6.8 patch contains some more
code
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
(eg,
for
PARALLEL_MARK) not present in mono/libgc.
- gc_pthread_redirects.h (which is a public one) should
not
Post by Elijah Taylor
Post by Ivan Maidanski
test
Post by Ivan Maidanski
NACL
macro
(or, at least, while less desirable, it should be
prefixed
Post by Elijah Taylor
Post by Ivan Maidanski
with
Post by Ivan Maidanski
GC_);
Ok, makes sense, I think I didn't realize this was a
public
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
header.
Post by Ivan Maidanski
Though
that explains why I had to add a test for
__native_client__
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
(which
Post by Ivan Maidanski
is
defined in our toolchain). I'll fix this.
- it's not clear why you need to explicitly undef
STACK_GRAN,
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
USE_M[UN]MAP,
etc. in gcconfig.h;
I'll do some investigation, but IIRC these were needed at
one
Post by Elijah Taylor
Post by Ivan Maidanski
point
Post by Ivan Maidanski
for
me.
There's a good chance these may be unnecessary and
vestigial.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
There should none "undef" (no other target undefining them).
If mmap is supported by NaCl then it might be possible to
support
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
USE_M[UN]MAP.
- is MPROTECT_VDB supported or not?;
Is MPROTECT_VDB equivalent to catching protection
violations in
Post by Elijah Taylor
Post by Ivan Maidanski
the
Post by Ivan Maidanski
GC
code?
If so, then no, we don't support anything like that right
now.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
Protection
violation in NaCl == instant death.
Ok, so MPROTECT_VDB (i.e., incremental/generation
collection)
Post by Ivan Maidanski
is
Post by Elijah Taylor
Post by Ivan Maidanski
not
Post by Ivan Maidanski
supported.
- if you you want to port gc72 please use the recent CVS
snapshot
Post by Ivan Maidanski
(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/)
...
Post by Elijah Taylor
Post by Ivan Maidanski
can
Post by Ivan Maidanski
you
point
me
to where I should be getting the latest? It's not
immediately
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
obvious
to
me.
http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/
(For convenience, I have a recent snapshot as a tarball
which
Post by Ivan Maidanski
I
Post by Elijah Taylor
Post by Ivan Maidanski
use
Post by Ivan Maidanski
for
my
project -
http://www.ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110107.tar.bz2)
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
- not sure that HEURISTIC1 really works reliably there (in
short,
Post by Ivan Maidanski
HEURISTIC1
means you treat stack pointer at GC_init call as stack
bottom
Post by Elijah Taylor
Post by Ivan Maidanski
-
Post by Ivan Maidanski
is it
guaranteed that GC_init call is always done at higher
stack
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
addresses
than
any other GC call);
HEURISTIC2 will definitely not work for us as it wants to
use a
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
segfault to
detect running over the stack. I've set STACK_GRAN to
64K,
Post by Ivan Maidanski
so
Post by Elijah Taylor
Post by Ivan Maidanski
as
Post by Ivan Maidanski
long
as
the stack doesn't grow beyond that size before GC_init, we
should
Post by Ivan Maidanski
be
ok,as
right? The stack for the main thread right now in NaCl
lives
Post by Elijah Taylor
Post by Ivan Maidanski
at a
Post by Ivan Maidanski
fixed
address usually, but that isn't guaranteed for all future
time,
Post by Elijah Taylor
Post by Ivan Maidanski
so
Post by Ivan Maidanski
I'd
prefer not to hard code magic numbers here.
No, HEURISTIC2 won't work without signals, but there are
other
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
- 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)?
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
- 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)
Post by Ivan Maidanski
platforms
(eg., Cygwin);
Native Client is meant to be portable, so it should run on
any
Post by Elijah Taylor
Post by Ivan Maidanski
x86
Post by Ivan Maidanski
or
x86-64
machine once it's built. In terms of building, I haven't
built
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
this gc
port
personally on Mac or Windows, but I just checked our build
bot
Post by Elijah Taylor
Post by Ivan Maidanski
logs
Post by Ivan Maidanski
and
they
seem to be building ok on Mac and in Cygwin.
So, eg. DARWIN, GC_DARWIN_THREADS, WIN32, CYGWIN,
GC_WIN32_THREADS
Post by Ivan Maidanski
won't
ever
be defined when building NaCl, right?
Is GC_LINUX_THREADS defined when building NaCl with
multi-threaded
Post by Ivan Maidanski
support?
I have very little knowledge of NaCl - could you briefly
explain
Post by Elijah Taylor
Post by Ivan Maidanski
what
Post by Ivan Maidanski
does
stand for NaCl portability - is it possible to call Win32
API
Post by Ivan Maidanski
if
Post by Elijah Taylor
Post by Ivan Maidanski
I'm
Post by Ivan Maidanski
compiling
on Cygwin or should I use the NaCl API (and, thus, the
compiled
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
binary
code
will run on any x86 target)?
If NaCl is some kind of OS then LINUX, DARWIN, WIN32, etc
shouldn't
Post by Ivan Maidanski
be
defined
(even if __linux__ defined) if NACL.
Same for GC_xxx_THREADS - I think GC_NACL_THREADS could be
defined
Post by Ivan Maidanski
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
Post by Ivan Maidanski
checked
yet)
I think there should be 2 ifdef NACL define OS_TYPE "NACL"
...
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
sections
(one
for every supported CPU).
- for non-static GC-internal symbols use GC_ prefix (eg.
for
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
nacl_thread_parked);
- define SIG_SUSPEND to -1 (instead of 0) as it is
returned
Post by Elijah Taylor
Post by Ivan Maidanski
by
Post by Ivan Maidanski
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)
Post by Elijah Taylor
Post by Ivan Maidanski
both
Post by Ivan Maidanski
for
code
readability and to prevent that symbols stripping when
compiled
Post by Ivan Maidanski
as a
shared
lib with -DGC_DLL);
I'll address these issues. (note that NaCl currently
doesn't
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
support
shared
libs yet so your dll example won't happen, but I agree
that
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
these
Post by Ivan Maidanski
should be
treated like other public GC functions)
Ok. But what is eg. nacl_pre_syscall_hook() - a callback
from
Post by Ivan Maidanski
the
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
NaCl
subsystem? (I guess this should be treated as GC public API)
Of course, use STATIC or static where possible (all STATIC
symbols
Post by Ivan Maidanski
start
with
GC_, while static typically not).
More tips: use GC_INNER and GC_EXTERN for internal global
variables;
Post by Ivan Maidanski
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
Post by Ivan Maidanski
the
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
worst,
but I
see now that's windows code. Looking at the x86 variants
it
Post by Elijah Taylor
Post by Ivan Maidanski
looks
Post by Ivan Maidanski
like
a
NaCl port of libatomic_ops is probably not going to be too
bad.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
I'll
look
into this eventually.
Most probably, it work w/o any porting afforts but it would
be
Post by Elijah Taylor
Post by Ivan Maidanski
good
Post by Ivan Maidanski
to
port
atomic_ops.c (similar to what I did for Win32-pthreads
targets -
Post by Elijah Taylor
Post by Ivan Maidanski
see
Post by Ivan Maidanski
AO_USE_WIN32_PTHREADS, I guess you should add AO_USE_NACL
macro
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
testing
in
that file (looks easy to add). I think it's worth doing
first
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
(and
Post by Ivan Maidanski
submit
me a
separate patch for libatomics_op when done).
What's about GC_HAVE_BUILTIN_BACKTRACE and
GC_CAN_SAVE_CALL_STACKS?
Post by Ivan Maidanski
At
least,
gc.h should be consistent with the GC implementation (I mean
eg.
Post by Elijah Taylor
Post by Ivan Maidanski
if
Post by Ivan Maidanski
GC_HAVE_BUILTIN_BACKTRACE not supported then it shouldn't be
defined
Post by Ivan Maidanski
in
gc.h
regardless of __linux__, _MSC_VER, etc. provided
__native_client__).
Post by Ivan Maidanski
Same for
GC_ADD_CALLER, GC_RETURN_ADDR.
Regards.
PS. Let me not do the benefits analysis (probably
someone
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
else
Post by Ivan Maidanski
can do
this).
Well, if the gc7.2 port is as easy as it's looking now, I
think
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
it's
probably worth doing it. I would still love to hear
anyone
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
chime
Post by Ivan Maidanski
in on
the
benefits of gc7.2 vs 6.8 though
Regards.
Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <
Hi GC folks,
I saw a little chatter in the archives related to
porting
Post by Elijah Taylor
Post by Ivan Maidanski
libgc
Post by Ivan Maidanski
to
Native
Client, so I joined this list to share some details. I'm
the
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
engineer
at
Google who ported of libgc to Native Client for Mono.
I've
Post by Elijah Taylor
Post by Ivan Maidanski
also
Post by Ivan Maidanski
included a
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
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
projects.
Before porting gc6.8 I had attempted to port one of
the
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
newer
Post by Ivan Maidanski
versions,
gc7.2alpha4, but ran into snags. The largest snag right
now I
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
think
is
that
gc 7+ includes libatomic_ops which will require some
non-trivial
Post by Ivan Maidanski
effort in
order to work under Native Client. Most notably we don't
support
Post by Ivan Maidanski
signals;
that was the biggest effort in porting libgc in the
first
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
place
Post by Ivan Maidanski
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
Post by Ivan Maidanski
of
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
things
we
might be missing if we only support gc6.8 instead of the
latest
Post by Ivan Maidanski
version?
Because of our thread stopping implementation, we may
not
Post by Ivan Maidanski
Post by Elijah Taylor
Post by Ivan Maidanski
even
Post by Ivan Maidanski
benefit
from
some of the newer features. I just wanted to get a sense
of
Post by Elijah Taylor
Post by Ivan Maidanski
what
Post by Ivan Maidanski
the
benefits are of getting a newer version available for
users.
Post by Elijah Taylor
Post by Ivan Maidanski
Post by Ivan Maidanski
-Elijah
Ivan Maidanski
2011-04-16 08:48:45 UTC
Permalink
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 <***@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 <***@mail.ru> wrote:
Hi Elijah,

Any progress or comments?
Hello Elijah,
Fri, 14 Jan 2011 15:36:34 -0800 пОсьЌП Пт Elijah Taylor <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of detail
- 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.
- 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.
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
 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
Elijah Taylor
2011-04-18 18:30:55 UTC
Permalink
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
Post by Ivan Maidanski
Hi Elijah,
Could you also provide GC_get_stack_base() implementation for NaCl? (just
for the completeness of the port)
Thanks.
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
Post by Ivan Maidanski
Hi Elijah,
Any progress or comments?
Hello Elijah,
Fri, 14 Jan 2011 15:36:34 -0800 ÐÉÓØÍÏ ÏÔ Elijah Taylor <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
- 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 <
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
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
Ivan Maidanski
2012-03-05 15:01:59 UTC
Permalink
Hi Elijah,

I've cherry-picked your latest commit regarding NaCl from mono/libgc to BDWGC master branch (with minor modifications):
https://github.com/ivmai/bdwgc/commit/14f2760d584c18fc8a1f305f5ed0a6d13ff5918a

I wonder where is nacl_register_gc_hooks defined?

Thanks.
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
Post by Ivan Maidanski
Hi Elijah,
Could you also provide GC_get_stack_base() implementation for NaCl? (just
for the completeness of the port)
Thanks.
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
Post by Ivan Maidanski
Hi Elijah,
Any progress or comments?
Hello Elijah,
Fri, 14 Jan 2011 15:36:34 -0800 письмо от Elijah Taylor <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
- 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 <
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
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
Elijah Taylor
2012-03-05 19:08:28 UTC
Permalink
Hi Ivan,

nacl_register_gc_hooks is defined in libnacl.a. Unfortunately, that
library is really only meaningful with our newlib toolchain. Thanks for
reminding me, I've filed a bug:
http://code.google.com/p/nativeclient/issues/detail?id=2635

You may want to consider taking a couple more changes to that file (and
other parts of libgc that we changed) in order to get something that will
Ivan Maidanski
2012-03-06 08:11:14 UTC
Permalink
Hi Elijah,

Thank you for your reply.
In future, please also CC to this ML on committing to mono/libgc.
Unfortunately, i don't have time to check it on NaCl target.

PS. I don't see anything else in mono master relevant to GC and NaCl in 2011.
(for convenience, we have a branch "mono_libgc" which is a copy of mono/master - https://github.com/ivmai/bdwgc/tree/mono_libgc )
Hi Ivan,
nacl_register_gc_hooks is defined in libnacl.a. Unfortunately, that
library is really only meaningful with our newlib toolchain. Thanks for
http://code.google.com/p/nativeclient/issues/detail?id=2635
You may want to consider taking a couple more changes to that file (and
other parts of libgc that we changed) in order to get something that will
build and run with our glibc toolchain.
Elijah Taylor
2012-03-06 15:51:09 UTC
Permalink
That's correct that mono master doesn't have these changes. I'm working to
get these changes in upstream mono so I can retire my fork.

I'll let you know of further changes in the future but I would call it
pretty stable at this point and don't expect it to change for some time.
Post by Ivan Maidanski
Hi Elijah,
Thank you for your reply.
In future, please also CC to this ML on committing to mono/libgc.
Unfortunately, i don't have time to check it on NaCl target.
PS. I don't see anything else in mono master relevant to GC and NaCl in 2011.
(for convenience, we have a branch "mono_libgc" which is a copy of
mono/master - https://github.com/ivmai/bdwgc/tree/mono_libgc )
Hi Ivan,
nacl_register_gc_hooks is defined in libnacl.a. Unfortunately, that
library is really only meaningful with our newlib toolchain. Thanks for
http://code.google.com/p/nativeclient/issues/detail?id=2635
You may want to consider taking a couple more changes to that file (and
other parts of libgc that we changed) in order to get something that will
Ivan Maidanski
2013-09-15 14:56:42 UTC
Permalink
Hi Elijah,

I found several commits from you to mono repository this year (8 months ago) including ARM support:
* https://github.com/ivmai/bdwgc/commit/204bcc6ede64402ca3ff2b165fc47a63374c68b1
* https://github.com/ivmai/bdwgc/commit/b328e8824e6ffa7cbd38c83e26433bee24bd3bb1
* https://github.com/ivmai/bdwgc/commit/21f0df75f5bac02619fb6fa4bcf5b49b169aeb1a

Anything to upstream?
Thank you.
That's correct that mono master doesn't have these changes. I'm working to get these changes in upstream mono so I can retire my fork.
I'll let you know of further changes in the future but I would call it pretty stable at this point and don't expect it to change for some time.
Post by Ivan Maidanski
Hi Elijah,
Thank you for your reply.
In future, please also CC to this ML on committing to mono/libgc.
Unfortunately, i don't have time to check it on NaCl target.
PS. I don't see anything else in mono master relevant to GC and NaCl in 2011.
(for convenience, we have a branch "mono_libgc" which is a copy of mono/master - https://github.com/ivmai/bdwgc/tree/mono_libgc )
Hi Ivan,
nacl_register_gc_hooks is defined in libnacl.a.  Unfortunately, that
library is really only meaningful with our newlib toolchain.  Thanks for
http://code.google.com/p/nativeclient/issues/detail?id=2635
You may want to consider taking a couple more changes to that file (and
other parts of libgc that we changed) in order to get something that will
build and run with our glibc toolchain.  From September through January, a
lot of changes went into Mono to make things work cleanly with our glibc,
and a decent amount was getting libgc working in the different environment.
 In fact, I've pretty much dropped support for using this with our newlib
version.
-Elijah
Post by Ivan Maidanski
Hi Elijah,
I've cherry-picked your latest commit regarding NaCl from mono/libgc to
https://github.com/ivmai/bdwgc/commit/14f2760d584c18fc8a1f305f5ed0a6d13ff5918a
I wonder where is nacl_register_gc_hooks defined?
Thanks.
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
Post by Ivan Maidanski
Hi Elijah,
Could you also provide GC_get_stack_base() implementation for NaCl?
(just
Post by Ivan Maidanski
for the completeness of the port)
Thanks.
Hi Ivan,
Sorry I haven't gotten back to you yet, I've been busy with other
things
Post by Ivan Maidanski
this last week.  I'm planning on addressing the feedback you've given
me so
Post by Ivan Maidanski
far in the next week, and I can send you a more detailed response to
your
Post by Ivan Maidanski
other questions at that time.  Thanks for the help so far.
-Elijah
Post by Ivan Maidanski
Hi Elijah,
Any progress or comments?
Hello Elijah,
Fri, 14 Jan 2011 15:36:34 -0800 пОсьЌП Пт Elijah Taylor <
Hi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
detail
- 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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
add
more clauses here").
- the patch in  naclports repository looks more suitable for gc
v72
Post by Ivan Maidanski
Post by Ivan Maidanski
than
that for mono/libgc;
This patch is meant to be applied to vanilla gc6.8.  The
mono/libgc
Post by Ivan Maidanski
Post by Ivan Maidanski
port is
already patched directly into mono's code repository.
Yes, I only meant the vanilla gc6.8 patch contains some more code
(eg,
Post by Ivan Maidanski
Post by Ivan Maidanski
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.
Post by Ivan Maidanski
Post by Ivan Maidanski
 Though
that explains why I had to add a test for __native_client__
 (which is
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
(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
Post by Ivan Maidanski
Post by Ivan Maidanski
point
me
to where I should be getting the latest?  It's not immediately
obvious
Post by Ivan Maidanski
Post by Ivan Maidanski
to
me.
http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/
(For convenience, I have a recent snapshot as a tarball which I use
for
Post by Ivan Maidanski
Post by Ivan Maidanski
my
project -
http://www.ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110107.tar.bz2 )
Post by Ivan Maidanski
Post by Ivan Maidanski
- not sure that HEURISTIC1 really works reliably there (in short,
HEURISTIC1
means you treat stack pointer at GC_init call as stack bottom -
is
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
as
the stack doesn't grow beyond that size before GC_init, we should
be
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
prefer not to hard code magic numbers here.
No, HEURISTIC2 won't work without signals, but there are other
- 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
Post by Ivan Maidanski
Post by Ivan Maidanski
x86-64
machine once it's built.  In terms of building, I haven't built
this
Post by Ivan Maidanski
Post by Ivan Maidanski
gc port
personally on Mac or Windows, but I just checked our build bot
logs
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
code
will run on any x86 target)?
If NaCl is some kind of OS then LINUX, DARWIN, WIN32, etc shouldn't
be
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
(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)
Post by Ivan Maidanski
Post by Ivan Maidanski
shoud
be tagged with some attribute (like public GC functions are)
both
Post by Ivan Maidanski
Post by Ivan Maidanski
for code
readability and to prevent that symbols stripping when compiled
as a
Post by Ivan Maidanski
Post by Ivan Maidanski
shared
lib with -DGC_DLL);
I'll address these issues.  (note that NaCl currently doesn't
support
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
subsystem? (I guess this should be treated as GC public API)
Of course, use STATIC or static where possible (all STATIC symbols
start
Post by Ivan Maidanski
Post by Ivan Maidanski
with
GC_, while static typically not).
More tips: use GC_INNER and GC_EXTERN for internal global
variables; use
Post by Ivan Maidanski
Post by Ivan Maidanski
GC_INNER for internal functions.
- libatomic_ops does not use signals API (except for CAS
emulation
Post by Ivan Maidanski
Post by Ivan Maidanski
which
is
not used for x86/x64).
I think I saw sigprocmask and related functions and assumed the
worst,
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
look
into this eventually.
Most probably, it work w/o any porting afforts but it would be good
to
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
gc.h
regardless of __linux__, _MSC_VER, etc. provided
 __native_client__).
Post by Ivan Maidanski
Post by Ivan Maidanski
Same for
GC_ADD_CALLER, GC_RETURN_ADDR.
Regards.
PS. Let me not do the benefits analysis (probably someone else
can
Post by Ivan Maidanski
Post by Ivan Maidanski
do
this).
Well, if the gc7.2 port is as easy as it's looking now, I think
it's
Post by Ivan Maidanski
Post by Ivan Maidanski
probably worth doing it.  I would still love to hear anyone chime
in
Post by Ivan Maidanski
Post by Ivan Maidanski
on the
benefits of gc7.2 vs 6.8 though
Regards.
Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <
Hi GC folks,
I saw a little chatter in the archives related to porting
libgc to
Post by Ivan Maidanski
Post by Ivan Maidanski
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
  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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
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
Post by Ivan Maidanski
Post by Ivan Maidanski
benefits are of getting a newer version available for users.
-Elijah
--
ИваМ МайЎаМскОй
Elijah Taylor
2013-10-16 21:26:07 UTC
Permalink
Hi Ivan,

We haven't landed all of the NaCl ARM changes into mono upstream yet, but
will be working on it. Here is where the ARM work currently lives:
https://github.com/igotti-google/mono/tree/arm_nacl

You can see changes made to libgc/ if you want to merge these in:
https://github.com/igotti-google/mono/commits/arm_nacl/libgc

Specifically, it looks like maybe you don't have changes from this:
https://github.com/igotti-google/mono/commit/8fada1863f201e29516a5442f91000bfefc39417

-Elijah
Post by Ivan Maidanski
Hi Elijah,
I found several commits from you to mono repository this year (8 months
*
https://github.com/ivmai/bdwgc/commit/204bcc6ede64402ca3ff2b165fc47a63374c68b1
*
https://github.com/ivmai/bdwgc/commit/b328e8824e6ffa7cbd38c83e26433bee24bd3bb1
*
https://github.com/ivmai/bdwgc/commit/21f0df75f5bac02619fb6fa4bcf5b49b169aeb1a
Anything to upstream?
Thank you.
That's correct that mono master doesn't have these changes. I'm working
to get these changes in upstream mono so I can retire my fork.
I'll let you know of further changes in the future but I would call it
pretty stable at this point and don't expect it to change for some time.
Hi Elijah,
Thank you for your reply.
In future, please also CC to this ML on committing to mono/libgc.
Unfortunately, i don't have time to check it on NaCl target.
PS. I don't see anything else in mono master relevant to GC and NaCl in 2011.
(for convenience, we have a branch "mono_libgc" which is a copy of
mono/master - https://github.com/ivmai/bdwgc/tree/mono_libgc )
Hi Ivan,
nacl_register_gc_hooks is defined in libnacl.a. Unfortunately, that
library is really only meaningful with our newlib toolchain. Thanks for
http://code.google.com/p/nativeclient/issues/detail?id=2635
You may want to consider taking a couple more changes to that file (and
other parts of libgc that we changed) in order to get something that will
Loading...