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

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

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

On Sat, 11 Jul 1998 02:04:53 -0600, Jeffrey A Law wrote:

>   In message <>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/ -- 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
> void
> __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 <> 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.


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