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>, "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 16:21:50 -0800
- Cc: "'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
> From: Helge Hess [mailto:firstname.lastname@example.org]
> "Boehm, Hans" wrote:
> > 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.
> Hm, I don't remember - all-interior-ptrs are required for
> untyped memory
> ? The ObjC runtime uses typed allocation, so it might not require
The question is really whether the last pointer to an object can point to
the inside of the object. If you can get and save a pointer to a field in
object A, save it inside object B, and then drop the pointer to A, you need
ALL_INTERIOR_POINTERS. Thus C/C++ more or less need it, while Java doesn't.
If you can embed C structs inside Objective C objects, I suspect Objective C
also needs it?
> > 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.