Re: Boehm's garbage collector support for Objective-C

[Jeffrey A Law <law at cygnus dot com>]

  In message <3559F85C.E33EB514@aracnet.com>you write:
  > Some time ago I added support for the Boehm's garbage collector into the
  > GNU Objective-C runtime. For those of you who know about this collector,
  > I used the typed memory allocation so that the collector runs faster.
  > There is yet another advantage of using typed memory allocation, it
  > helps implementing weak pointers, pointer instance variables hidden from
  > the collector. This is a very useful facility when keeping references to
  > global objects, yet still allowing them to be collected when no longer
  > needed.
Some comments on the code itself:

In objc/Makefile.in -- it looks like you tack on different suffixes
to the .o files depending on how they're compiled.

Seems to me it would be easier and cleaner to make a subdirectory
for the Boehm-aware .o files and build them into that subdirectory.
Similar to how we handle building multiple versions of libgcc.a for
the main compiler. 


In the code you add -- each new function should have a short description
of the function, its args and return value.  See other parts of gcc
for examples.

gc.c seems to be a target file, so why is it referencing HOST_BITS_PER_INT.  
I'm a little worried that there may be other cases where we are not
clearly distinguishing between the host, build and target.  I'm not
familiar enough with our objc code to even hazard what other problems
of this nature might be lurking.

You have many functions declared like this:

void __objc_generate_gc_type_description (Class class)

That should be

void
__objc_generate_gc_type_description (Class class)


I'm concerned about adding this code for the egcs-1.1 release for a
few reasons:

	1. I don't understand it :-)  This is not your fault; I just
	   have no experience at all in the objc front end or the
	   language itself and it's unlikely I'll have the opportunity
	   to learn this stuff.

	2. Nobody else has reviewed the code.  It would be nice if
	   we could get someone else that knows something about objc
	   to look at the code (maybe Scott Christley could take a look)

	3. Nobody else is using/testing the code.  Then again, I don't
	   think we've got many objc users to start with.

	4. Copyright assignment issues.


I can live with #1 and #3 if we can get a second opinion on the code
from someone that knows the language and our implementation of the
language.  Again, Scott Christley comes to mind.  maybe you could send
your code to Scott asking for comments?  I believe his address is in
the ChangeLogs somewhere.

We must resolve #4 before we can do anything at all with this contribution.

I also think that if we can resolve #4 in time, we can go forward with
your testsuite contribution for egcs-1.1, even if we don't install the
new language feature immediately.

--


Longer term, we desparately need someone to maintain objc for egcs.
Right now you and Scott are the only candidates I can think of.
Would this be something you might be interested in doing?  It would
basically mean you'd have a free hand to "do the right thing" for
the objc front end and runtime libraries.

If you're interested I can bring it up with the egcs steering committe
and see if they think it's a good idea.




jeff