This is the mail archive of the
mailing list for the Java project.
RE: ObjC configured --with-objc-gc needs external Boehm gc
- To: "'tromey at redhat dot com'" <tromey at redhat dot com>, Matthias Klose <doko at cs dot tu-berlin dot de>
- 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:02:38 -0800
- Cc: gcc at gcc dot gnu dot org, java-discuss at sources dot redhat dot com, ovidiu at cup dot hp dot com
> -----Original Message-----
> From: Tom Tromey [mailto:email@example.com]
> For instance, we define these options:
That one's pretty standard.
That one, too.
That's already run-time configurable. The macro is a backward compatibility
hack. It only determines the initial value of GC_java_finalization.
Shouldn't hurt. You just get a bit of extra code.
The problematic one is ALL_INTERIOR_POINTERS, which gcj doesn't define, but
most other clients do.
> When cross-compiling we also assume that we're targeting a smaller
> or embedded system and enable these options:
I don't recognize either of these off the top of my head. I don't think
they're source language specific.
You want to define those for small embedded apps, whether ObjC or Java. You
don't want to define them for anything else.
> I'm not against having other uses for the boehm-gc. However, ideally
> these other uses wouldn't result in performance loss for Java
> programs. The GC is a critical component for us; we've gotten
> significant performance improvements by tweaking it. Untweaking would
> be bad for us.
The effect of making ALL_INTERIOR_POINTERS a runtime option isn't obvious to
me. It may involve a slight performance loss, or it may not.
(I have some more important performance fixes for the GC in my work area.
In particular, the current thread support is way overzealous in clearing
stacks, especially on X86. I measured 6% for that on GCBench, with another
3 or 4% from inlining GC_allocobj. The latter change unfortunately has some
aesthetic problems ...)