This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
RE: ObjC configured --with-objc-gc needs external Boehm gc
- To: "'Matthias Klose'" <doko at cs dot tu-berlin dot de>, "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: ObjC configured --with-objc-gc needs external Boehm gc
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Tue, 16 Jan 2001 15:51:49 -0800
- Cc: gcc at gcc dot gnu dot org, java-discuss at sources dot redhat dot com, ovidiu at cup dot hp dot com
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.
>