This is the mail archive of the
mailing list for the Java project.
Re: ObjC configured --with-objc-gc needs external Boehm gc
- To: Helge Hess <helge dot hess at skyrix dot com>
- Subject: Re: ObjC configured --with-objc-gc needs external Boehm gc
- From: Jeff Sturm <jeff dot sturm at appnet dot com>
- Date: Wed, 17 Jan 2001 13:48:26 -0500
- CC: "Boehm, Hans" <hans_boehm at hp dot com>, "'Matthias Klose'" <doko at cs dot tu-berlin dot de>, gcc at gcc dot gnu dot org, java-discuss at sources dot redhat dot com, ovidiu at cup dot hp dot com
- Organization: Commerce One
- References: <140D21516EC2D3119EE700902787664401E3A83E@hplex1.hpl.hp.com> <3A657F24.B14B6641@skyrix.com>
- Reply-To: jeff dot sturm at commerceone dot com
Helge Hess wrote:
> "Boehm, Hans" wrote:
> > > > Does Objective C normally use the collector with thread support?
> > >
> > > I think that this is 50/50. The problem is that threading currently
> > > slows down the runtime to some degree and therefore is often
> > > turned off
> > > if threading is not required.
> > Aside from a tuning problem in current collector versions, it should
> > currently cost basically one test-and-set (probably 5-30 cycles depending on
> > the processor) on entry, and a store on exit of each malloc call. The
> > uniprocessor cost with thread-local allocation (as in GC6.0) is probably
> > about the same, though it scales much better on multiprocessors.
> I think I wasn't clear. I was referring to the performance of libobjc,
> not of the gc. Libobjc gets slower if threading is enabled which is
> often the reason why people turn it off.
Can you say much slowdown is due to the use of thread primitives in libobjc vs.
how much is due to memory allocation? Using boehm-gc might even be beneficial
to the threaded runtime... I've observed poor performance from the standard
(thread-safe) allocator on some systems, including glibc.