This is the mail archive of the
mailing list for the GCC project.
Re: Boehm's garbage collector support for Objective-C
- To: law at cygnus dot com
- Subject: Re: Boehm's garbage collector support for Objective-C
- From: Ovidiu Predescu <ovidiu at aracnet dot com>
- Date: Sat, 11 Jul 1998 02:12:10 -0700
- Cc: egcs-patches at cygnus dot com, gcc-patches at gnu dot org
On Sat, 11 Jul 1998 02:04:53 -0600, Jeffrey A Law wrote:
> 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.
OK, I'll take a look and do it like there.
> 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.
Yes, my fault, I used the host macro instead of the target one. As far as I
remember, there are no other target dependencies besides this, but I'll check
the code again. Sorry about that!
> You have many functions declared like this:
> void __objc_generate_gc_type_description (Class class)
> That should be
> __objc_generate_gc_type_description (Class class)
Sorry, I'll correct it.
> 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.
The code is used by two higher-level libraries in which I added support for
Boehm's GC. These two libraries are used by Helge Hess <email@example.com> into a
commercial application that's currently being developed and used by his
company. The ObjC code was actually the result of my work to integrate the
Boehm's GC in the higher-level libraries I co-wrote.
I used to work in Scott Christley's company (NET Community) until very recently
when I started the process of moving to Hewlett Packard. In the past I
contributed with some other major improvements and bug fixes in the ObjC
front-end (oops, no assignments for the improvements either?!), so this would
not be my first contribution to the ObjC compiler and runtime. I am also an
active developer in the GNUstep project, a GNU project that's heavily relying
on the GNU ObjC compiler.
> We must resolve #4 before we can do anything at all with this contribution.
BTW, I signed a copyright assignment for the GNUstep project while I was
working for NET-Community, though it maybe did not include the GCC work.
Anyway, this weekend I'll print out the GCC assignment and send it over to FSF.
> 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.
The testsuite is actually testing a functionality added by the patch ;-), it
will fail if that's not installed.
> 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.
Yes, I think I can do this for the long term as I am quite familiar with the
ObjC frontend and the runtime library. There are some other nice things I would
love to do in the ObjC front-end and runtime library and this would be a great
opportunity to work directly with the rest of the compiler team.
Please let me know your decisions.