This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

> -----Original Message-----
> From: Tom Tromey []
> ...
> 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 ...)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]