ObjC configured --with-objc-gc needs external Boehm gc

Tue Jan 16 15:52:00 GMT 2001

I expect the Java library will almost always be built with thread support.
This currently implies a small to moderate performance hit if you don't use
it, and you currently have to link against libpthread. Once the parallel GC
is imported, it does have the advantage that performance on a multiprocessor
may even be slightly better than for the thread-unsafe version, since the
collector itself uses more than one processor.
Hans
> -----Original Message-----
> From: Matthias Klose [ mailto:doko@cs.tu-berlin.de ]
> Sent: Tuesday, January 16, 2001 3:20 PM
> To: Boehm, Hans
> Cc: gcc@gcc.gnu.org; java-discuss@sources.redhat.com; 
> ovidiu@cup.hp.com
> Subject: RE: ObjC configured --with-objc-gc needs external Boehm gc
>>> Boehm, Hans writes:
> > I can't think of any fundamental problems. I suspect 
> Objective C normally
> > wants the collector built to recognize all interior 
> pointers, where gcj
> > builds it without that option, so that interior pointers 
> are recognized only
> > if they're on a stack. This is currently a build time 
> option, but that
> > probably doesn't save very much anymore over making it a 
> runtime option.
> > 
> > Does Objective C normally use the collector with thread support? 
>> The ObjC runtime can be built with thread support. I am not aware of
> applications needing thread and gc support. The gnustep core libraries
> (www.gnustep.org) are built with thread support only. The
> gnustep-extensions defines support for garbage collected objects.
>