Re: GC-optional mode: does anyone care?

[David Chisnall]

n 27 May 2011, at 19:58, Eric Wasylishen wrote:

> Hi David,
> 
> First, I wanted to say your work on GC sounds great!

Thanks.

> 
> In my mind, the ideal developer/user experience for GC is being able to 
> install GNUstep from your OS's package manager, compile an app written for 
> GC, and have it work. Or, even better, be able to install apps from the OS's 
> package manager which were written for GC along with ones written using 
> retain/release.

Yes, I'd agree.

> As I understand it, in order to support these use cases, we would either need 
> OS's to ship GC-only builds of GNUstep base/gui/back, or else ship Optional 
> GC builds. If the OS's shipped GC-only builds, it would force everyone to use 
> GC (maybe not a problem, but there may be reasons to not want GC.) Does that 
> sound accurate?

Not quite.  There are basically two options:

Packagers ship two flavours of GNUstep libraries (including third-party ones, 
such as frameworks from GAP or Étoilé), one compiled with GC and without.  They 
can coexist, as long as they give them different library names (e.g. 
libgnustep-base-gc.so, libgnustep-base.so - either -make can automate this or 
packagers can pick their own naming scheme).  This has the advantage that 
people don't have any overhead from the version that they don't use, but has 
the down side that packagers need to create two versions of each library.  For 
end users, it's not such an issue.  You install FooNeedsGC.app, and your 
package manager automatically installs the GC versions of any dependencies, or 
you install BarNeedsRetainRelease.app and your package manager automatically 
installs the non-GC versions of any dependencies.

The other solution is for us to support GC-optional mode.  In this mode, the 
programmer inserts retain and release calls and the compiler inserts read and 
write barriers.  The framework will work in either mode.  This will need some 
special logic in -base to select the correct mode at run time (although this 
should be confined to NSGarbageCollector, NSZone, and NSObject), rather than at 
compile time.  The advantage of this approach is that distributions can ship 
just one version of libraries.  The down sides are that someone (probably me) 
has to implement the required logic in -base, and the code will be slower.  In 
pure GC mode, clang will remove all -retain / -release / -autorelease message 
sends[1], so you just get the write barriers for heap assignments.  In non-GC 
mode, it won't insert the write barriers, so you just get the retain / release 
/ autorelease message sends.  In hybrid mode, you get both, even though in any 
given process one will be a no-op.  This bloats the binary size too.

There's possibly a third option, which is to do a hybrid of the two, and for 
the build system to support building both GC and non-GC versions of libraries 
automatically, and sticking them in the same framework bundle.  Users would 
only need to install one bundle, and applications could link to either version.

OS X needs the hybrid mode, because it's fairly common for people to have 
frameworks without the source.  It's much less important for us, because we 
generally have two sorts of users:

- Free Software systems, which build their own packages from source
- Proprietary software users who ship a specific version of GNUstep, tested 
with their apps

So, the question is really aimed at people in these groups.  Sebastian is 
probably the packager who has worked most closely with GNUstep, so I'd like to 
hear his opinion...

David

[1] It doesn't do this on OS X, just for us because we are special.