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

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

[Boehm, Hans]

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.
> 

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

[Helge Hess]

Jeff Sturm wrote:
> I believe the java frontend always maintains base pointers to live objects, not
> sure about objc.

ObjC is much more 'free' in how you manage the object's memory. But in
practice you also always use base pointers to live objects (at least
when using the Foundation kit).

Helge
-- 
SKYRIX Software AG  http://www.skyrix.com/

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

[Helge Hess]

Jeff Sturm wrote:
> Can you say much slowdown is due to the use of thread primitives in libobjc vs.
> how much is due to memory allocation?  Using boehm-gc might even be beneficial
> to the threaded runtime... I've observed poor performance from the standard
> (thread-safe) allocator on some systems, including glibc.

No, unfortunatly I can't, I didn't make any memory timings (except with
mingw32, where the default allocator is *extremly* slow).

If this is of interest to you, one major problem with the (GNU) libobjc
is that all operations referring class objects by name are compiled to
hashtable lookups instead of static references, eg

  [NSString alloc]

ends up int
  objc_msg_send(objc_class_lookup("NSString"),@sel(alloc));

And this objc_class_lookup is protected by a mutex ...

best regards
  Helge
-- 
SKYRIX Software AG  http://www.skyrix.com/

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

[Boehm, Hans]

> I'm sure I read somewhere (in one of your papers, perhaps) 
> that some compiler
> optimizations can hide base pointers and necessitate 
> ALL_INTERIOR_POINTERS even
> if interior objects are not explicitly accessed in code.
> 
> I believe the java frontend always maintains base pointers to 
> live objects, not
> sure about objc.
> 
Short answer:
Yes, there are potential problems.  But I don't think they affect this
discussion much.

Longer answer:
The collector always considers interior pointers from the stack or the
registers to be valid, even if it's not configured with
ALL_INTERIOR_POINTERS.  The ALL_INTERIOR_POINTERS option affects only
pointers stored in the heap or static data areas.  It seems unlikely that
the compiler would introduce stores of derived pointers into either the heap
or static data areas (since this would probaly introduce thread-safety
issues if nothing else).  Thus I think it's mostly a source language/client
code issue as to whether this is needed.

This unfortunately doesn't completely solve the problem, since there are
cases in which the compiler potentially introduces a derived pointer that
doesn't point to anywhere in the original object, and yet that is logically
the only reference to the object.  The canonical example is

char *a = GC_malloc( ...);
char *x;

x = a + (i - 1000);
<a dead>
... *x ...

which may be compiled to

a -= 1000;
<GC occurs here, reclaiming a>
... *(a + i) ...
<oops!>

In this form, this can only be done by the compiler, since the "a -= 1000"
assignment is not legal C pointer arithmetic.

I know of no way to avoid this problem, no matter what kind of GC you use,
without teaching the compiler that there might be a garbage collector.  This
can be done by telling the backend that "a" is live until the dereference of
*x occurs.  There are more details in my 1996 PLDI paper, and in a paper
that David Chase and I wrote before that.

It sounds like gcc doesn't currently guard against this, no matter what the
front end.  This really needs to be fixed eventually.  On the other hand,
this problem seems to be EXTREMELY rare in real code.  (It's basically
impossible when generating debuggable unoptimized code.)

Hans

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

[Tom Tromey]

>>>>> "Jeff" == Jeff Sturm <jeff.sturm@appnet.com> writes:

Jeff> I believe the java frontend always maintains base pointers to
Jeff> live objects, not sure about objc.

We do for references on the heap.  For references on the stack we just
hope that the right thing happens.  That is, it might be the case that
you're right due to some side effect of the implementation, but we
certainly didn't plan it that way.  Really fixing this requires GC
safety support from gcc.  There's another thread about this elsewhere.
One thing to note is that even if this is a problem it is likely to be
extremely rare as it requires a peculiar set of circumstances.

Tom

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

[Jeff Sturm]

Helge Hess wrote:
> 
> "Boehm, Hans" wrote:
> > > > 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.
> 
> I think I wasn't clear. I was referring to the performance of libobjc,
> not of the gc. Libobjc gets slower if threading is enabled which is
> often the reason why people turn it off.

Can you say much slowdown is due to the use of thread primitives in libobjc vs.
how much is due to memory allocation?  Using boehm-gc might even be beneficial
to the threaded runtime... I've observed poor performance from the standard
(thread-safe) allocator on some systems, including glibc.

--
Jeff Sturm
jeff.sturm@commerceone.com

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

[Jeff Sturm]

"Boehm, Hans" wrote:
> > From: Helge Hess [ mailto:helge.hess@skyrix.com ]
> > Hm, I don't remember - all-interior-ptrs are required for
> > untyped memory
> > ? The ObjC runtime uses typed allocation, so it might not require
> > all-interior-ptrs.
>
> 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?

I'm sure I read somewhere (in one of your papers, perhaps) that some compiler
optimizations can hide base pointers and necessitate ALL_INTERIOR_POINTERS even
if interior objects are not explicitly accessed in code.

I believe the java frontend always maintains base pointers to live objects, not
sure about objc.

--
Jeff Sturm
jeff.sturm@commerceone.com

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

[Boehm, Hans]

> -----Original Message-----
> From: Helge Hess [ mailto:helge.hess@skyrix.com ]
>
> In this context: How does BoehmGC access threading ? Libobjc has it's
> own threading-backend architecture. This might be 
> reused/shared as well
> (in one or the other direction).
> 
The collector supports threads only on some of the most common platforms.
Currently these consist of

- Linuxthreads (most hardware)
- Win32 threads
- Solaris threads (both variants)
- Irix pthreads

Recent versions (more recent than the gcc tree) add support for HP/UX 11,
Windows CE, and Compaq Tru64 (Tru64 is completely untested, AFAIK).

It uses the system provided thread primitives directly.  In many cases it
also uses some flavor of hardware test and set instruction directly, in
order to get better locking performance.

For pthreads (including old-style Solaris threads), the collector needs to
intercept some pthread primitives, since it has to keep its own shadow
thread data structures to hold information about thread stack location, etc.
This is traditionally done by #define'ing functions like pthread_create in
gc.h, and making sure that gets included in files that need these
primitives.  In a GNU environment, it can also be done using the GNU linker
--wrap facility.

It looks to me like this is mostly consistent with libObjC requirements?
The only issue might be the wrapping of pthreads calls made from the libObjC
thread layer?  Do you currently build separate versions of this for the GC
case?

The collectors use of thread primitives tends to be performance critical.
Thus I would rather not move it on top of some higher thread abstraction
layer.

[Tom Tromey wrote:]
> What Hans proposed is making ALL_INTERIOR_POINTERS a runtime option
> and not a compile time option.  I think simply enabling it by default
> would entail a performance hit for Java.  I'd rather not enable it
> until the appropriate change is made.
It sounds like Objective C currently doesn't use ALL_INTERIOR_POINTERS, and
there is some controversy about whether it should?

Assuming this needs to be changed, I agree with Tom.  ALL_INTERIOR_POINTERS
doesn't actually affect the run time of the collector in any obvious way.
It affects mostly the initialization and format of some tables.  The actual
pointer validity checking is done largely by table lookup in either case.
But it does have some other performance impacts related to false pointer
scanning and large object allocation.

(Even if Objective C doesn't need the change, it would potentially be a
useful one, since C clients generally want ALL_INTERIOR_POINTERS.  But that
would lower its priority in my eyes.  I guess the other advantage of making
it runtime configurable is that the Objective C maintainers wouldn't really
have to agree ...)

Hans

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

[Tom Tromey]

>>>>> "Ovidiu" == Ovidiu Predescu <ovidiu@cup.hp.com> writes:

Ovidiu> As you pointed out, I think we should set the
Ovidiu> ALL_INTERIOR_POINTERS and enable the threading as it doesn't
Ovidiu> seem to add a substantial overhead.

What Hans proposed is making ALL_INTERIOR_POINTERS a runtime option
and not a compile time option.  I think simply enabling it by default
would entail a performance hit for Java.  I'd rather not enable it
until the appropriate change is made.

Tom

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

[Helge Hess]

"Boehm, Hans" wrote:
> > > 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.

I think I wasn't clear. I was referring to the performance of libobjc,
not of the gc. Libobjc gets slower if threading is enabled which is
often the reason why people turn it off.

In this context: How does BoehmGC access threading ? Libobjc has it's
own threading-backend architecture. This might be reused/shared as well
(in one or the other direction).

Helge

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

[Helge Hess]

Matthias Klose wrote:
> Boehm, Hans writes:
>  > 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?
> 
> Then ObjC needs it as well.

I do not agree. It is theoretically possible, but irrelevant in practice
(it plays in the same league like ORing a ptr).

It doesn't make sense to hold *only* a ptr into the inside, since if you
don't have the ptr to the block-start, you can't reach 'isa' and
therefore this object isn't an ObjC object anymore.
Not storing a block-ptr is actually also problematic with
retain-counting as used in gstep-base or libFoundation as well.

An object is kept alive by it's handle and can only be messaged by a
handle.

Helge

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

[Fergus Henderson]

On 17-Jan-2001, Ovidiu Predescu <ovidiu@cup.hp.com> wrote:
> I briefly looked in the GCC source code: is the garbage collector itself
> distributed with GCC? I couldn't find it anywhere; am I missing something?

Yes, it is in the `boehm-gc' directory.
But only in recent snapshots, not in e.g. 2.95.*, I think.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

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

[Ovidiu Predescu]

As you pointed out, I think we should set the ALL_INTERIOR_POINTERS and enable
the threading as it doesn't seem to add a substantial overhead.

I briefly looked in the GCC source code: is the garbage collector itself
distributed with GCC? I couldn't find it anywhere; am I missing something?

Thanks,
Ovidiu

On Tue, 16 Jan 2001 16:21:50 -0800, "Boehm, Hans" <hans_boehm@hp.com> wrote:

> > From: Helge Hess [ mailto:helge.hess@skyrix.com ]
> > "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
> > all-interior-ptrs.
> 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.
> 
> Hans
> 

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

[Matthias Klose]

Boehm, Hans writes:
 > 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?

Then ObjC needs it as well.

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

[Boehm, Hans]

> From: Helge Hess [ mailto:helge.hess@skyrix.com ]
> "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
> all-interior-ptrs.
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.

Hans

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

[Helge Hess]

"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
all-interior-ptrs.

> 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.

Personally I would really like to see a reuse of the gcc libgc, so that
no external lib is required.

Helge

> There are probably also other issues with the build process.  Tom Tromey can
> probably comment on those.
> 
> Hans
> 
> > -----Original Message-----
> > From: Matthias Klose [ mailto:doko@cs.tu-berlin.de ]
> > Sent: Tuesday, January 16, 2001 2:07 PM
> > To: gcc@gcc.gnu.org
> > Cc: java-discuss@sources.redhat.com; ovidiu@cup.hp.com
> > Subject: ObjC configured --with-objc-gc needs external Boehm gc
> >
> >
> > The Objective C runtime library enabled with garbage collection needs
> > an external Boehm gc collector beeing installed at compile time. Is it
> > possible to build the libobjcgc library with the Boehm gc that is
> > already used for gcj?
> >

-- 
SKYRIX Software AG  http://www.skyrix.com/
Join the team:      http://www.skyrix.com/de/jobs/index.html

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

[Matthias Klose]

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.

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

[Boehm, Hans]

> -----Original Message-----
> From: Tom Tromey [ mailto:tromey@redhat.com ]
> ...
> For instance, we define these options:
> 
>     AC_DEFINE(SILENT)
That one's pretty standard.
>     AC_DEFINE(NO_SIGNALS)
That one, too.
>     AC_DEFINE(JAVA_FINALIZATION)
That's already run-time configurable.  The macro is a backward compatibility
hack.  It only determines the initial value of GC_java_finalization.
>     AC_DEFINE(GC_GCJ_SUPPORT)
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:
> 
>     AC_DEFINE(NO_SIGSET)
>     AC_DEFINE(NO_CLOCK)
I don't recognize either of these off the top of my head.  I don't think
they're source language specific.
>     AC_DEFINE(SMALL_CONFIG)
>     AC_DEFINE(NO_DEBUGGING)
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 ...)

Hans

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

[Boehm, Hans]

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? 

There are probably also other issues with the build process.  Tom Tromey can
probably comment on those.

Hans

> -----Original Message-----
> From: Matthias Klose [ mailto:doko@cs.tu-berlin.de ]
> Sent: Tuesday, January 16, 2001 2:07 PM
> To: gcc@gcc.gnu.org
> Cc: java-discuss@sources.redhat.com; ovidiu@cup.hp.com
> Subject: ObjC configured --with-objc-gc needs external Boehm gc
> 
> 
> The Objective C runtime library enabled with garbage collection needs
> an external Boehm gc collector beeing installed at compile time. Is it
> possible to build the libobjcgc library with the Boehm gc that is
> already used for gcj?
> 

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

[Tom Tromey]

>>>>> "Matthias" == Matthias Klose <doko@cs.tu-berlin.de> writes:

Matthias> The Objective C runtime library enabled with garbage
Matthias> collection needs an external Boehm gc collector beeing
Matthias> installed at compile time. Is it possible to build the
Matthias> libobjcgc library with the Boehm gc that is already used for
Matthias> gcj?

The boehm-gc in the gcc tree is a mildly modified version of the
standard Boehm collector.  Basically we modified it to use autoconf
and automake so that it would fit into the existing gcc build system.

However, the Boehm GC is designed so that many of its options can only
be set at build time, and not at runtime.  So we've set things up to
configure the GC to be appropriate for our runtime environment.  It
might or might not work in other environments.

For instance, we define these options:

    AC_DEFINE(SILENT)
    AC_DEFINE(NO_SIGNALS)
    AC_DEFINE(JAVA_FINALIZATION)
    AC_DEFINE(GC_GCJ_SUPPORT)

When cross-compiling we also assume that we're targeting a smaller
or embedded system and enable these options:

    AC_DEFINE(NO_SIGSET)
    AC_DEFINE(NO_CLOCK)
    AC_DEFINE(SMALL_CONFIG)
    AC_DEFINE(NO_DEBUGGING)


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.

One idea would be to work with Hans Boehm to see if some of these
configuration options can be made runtime configurable without
(significant) performance impact.

Tom

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

[Ovidiu Predescu]

On Tue, 16 Jan 2001 23:06:34 +0100 (MET), Matthias Klose <doko@cs.tu-berlin.de>
 wrote:

> The Objective C runtime library enabled with garbage collection needs
> an external Boehm gc collector beeing installed at compile time. Is it
> possible to build the libobjcgc library with the Boehm gc that is
> already used for gcj?

I'm not familiar with the version of Boehm gc used by gcj, can you provide more
details?

Thanks,
Ovidiu

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

[Matthias Klose]

The Objective C runtime library enabled with garbage collection needs
an external Boehm gc collector beeing installed at compile time. Is it
possible to build the libobjcgc library with the Boehm gc that is
already used for gcj?