discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GC-optional mode: does anyone care?


From: Austin Clow
Subject: Re: GC-optional mode: does anyone care?
Date: Fri, 27 May 2011 13:08:41 -0500

My opinion is that all three modes should be supported. 

- Austin

Sent from my iPad

On May 27, 2011, at 7:11 AM, David Chisnall <theraven@sucs.org> wrote:

> Hi Everyone,
> 
> On OS X, you can compile in one of three modes with respect to garbage 
> collection:
> 
> 1 No GC, normal retain/release semantics.
> 2GC-only, no retain/release stuff is used anywhere.
> 3 Optional GC, uses GC mode if everything that is linked supports GC, 
> otherwise uses normal retain/release semantics.
> 
> GNUstep has supported the first mode forever.  I now have the second mode 
> working quite nicely - still needs more testing, but Gorm and all of the 
> Étoilé code that I've tried seems to work.
> 
> So, my question is whether it's worth supporting the GC-optional mode.  Code 
> compiled in this mode will still send retain / release messages, but they'll 
> be ignored if you're in GC mode.  The compiler will always insert the read 
> and write barriers, but the runtime will ignore them if you're not in GC 
> mode.  
> 
> This will require some tweaking in GNUstep code (things that are currently 
> compile-time options will have to be modified to be switched at run time, for 
> example we need both versions of the autorelease pool code.  On OS X, the 
> main advantage is that you can ship binary-only frameworks that work in both 
> modes (albeit with some performance overhead).  I'm not really sure that this 
> is interesting to us, so before I waste time on a feature that no one will 
> use, I thought I'd ask if anyone cares.  
> 
> David
> 
> -- Sent from my PDP-11
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



reply via email to

[Prev in Thread] Current Thread [Next in Thread]