Re: pkg/41893: Should devel/boehm-gc be built with thread support by default?

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR pkg/41893; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/41893: Should devel/boehm-gc be built with thread support
 by default?
Date: Sat, 5 Nov 2011 17:14:57 -0400

 On Sat,  5 Nov 2011 13:55:02 +0000 (UTC)
 David Holland <dholland-pbugs%netbsd.org@localhost> wrote:
 
 >   >  It would also be possible to tell ECL to build and embed its own
 >   >  boehm-gc, which is part of the tree, although this duplicates things a
 >   >  little in RAM.  Is it a valid concern?
 >  
 >  The primary concern is that if a vulnerability appears in the package,
 >  someone has to remember where the extra private copies are and mark
 >  those packages vulnerable too... and then someone has to apply the
 >  fixes. This is usually a bad idea, so we like to not use included
 >  private copies of things.
 
 True, I agree that dynamic linking has an advantage here.
 
 >   >  Yet we since force pthread support for everything that uses dlopen(3),
 >   >  so why not also enable the current thread option by default on
 >   >  netbsd-5+ and Linux? (boehm-gc doesn't use DLFCN(3), though).
 >  
 >  Well, the concern I'd have is that thread support may add a lot of
 >  overhead. Threaded garbage collection is painful enough in general
 >  that people go to substantial lengths to avoid it on purpose; I don't
 >  know to what extent this applies to boehm-gc's thread support.
 >  
 >  If there's not a significant problem, then we should enable it by
 >  default, as non-threaded/single-core environments are not the future
 >  or even at this point the present.
 >  
 >  If there is a problem, a separate package is probably the way to go;
 >  however, I'd go so far as to say the default package should be
 >  threaded and the other package should be "boehm-gc-unthreaded".
 >  
 >  As to whether there's a problem... that's the sort of thing we have
 >  package maintainers to know about. I have no idea. If you'd be willing
 >  to look into it, which hopefully by now should require only digging
 >  around and not actually benchmarking things, we can probably move
 >  forward on this...
 
 I've not checked the code, but according to the tech docs:
 
 According to http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html,
 it uses a stop-world mark-and-sweep algorithm, with some support or
 incremental and generational modes for some operating systems (I'm not
 sure if that's true for BSD yet, but no BSD is listed in the OS
 enumeration.
 
 It also supports an experimental parallel-mark, but by default,
 according to http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html:
 
     It causes the garbage collector to stop all other threads when it
     needs to see a consistent memory state. It causes the collector to
     acquire a lock around essentially all allocation and garbage
     collection activity. Since a single lock is used for all
     allocation-related activity, only one thread can be allocating or
     collecting at one point. This inherently limits performance of
     multi-threaded applications on multiprocessors.
 
 Personally, I currently am using a boehm-gc built with threads support,
 as I use ECL built with threads support as well.  I can't say that it's
 a problem on my slowest system (a 2793.16 MHz cache-crippled Celeron).
 However, boehm-gc is only used by ECL, w3m and Inkscape on my own
 systems.  I'm not sure that a boehm-gc-unthreaded would even be
 necessary, but who knows...
 
 Thanks,
 -- 
 Matt