Re: GC-optional mode: does anyone care?

[Sebastian Reitenbach]

Hi,

On Saturday, May 28, 2011 01:04 CEST, David Chisnall <theraven@sucs.org> wrote:

> 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...

So if I get it right, I'd need to create two versions for each 
library/framework, one without, and one with gc, so that apps, which would use 
one or the other method can both work.
Speaking for OpenBSD packages, I think I'd favor the third option you proposed, 
if both could be created with one compile run. Then I could just install both 
versions, and I'm done. The apps would pick then one or the other, whatever 
they need.
Also with this method, I could create SUB_PACKAGES, having one default package, 
i.e. the non-gc version, and another SUBPACKAGE, with the gc version, making 
the apps depending on one or the other.
Creating so-called FLAVORS of the packages, when at configure time it is chosen 
to compile with or without gc, would make things complicated, since different 
FLAVORS of the same packages can't be installed at the same time. You can only 
install one or the other, to get both installed, I'd need to create so-called 
PSEUDO_FLAVORS, which is a mixture of SUBPACKAGE and FLAVOR, but this would add 
a lot complexity to the ports makefile. This is also the reason why I have only 
the cairo backend as package for OpenBSD. Before I took over maintainership of 
the gnustep ports on OpenBSD, there have been FLAVORS of the gnustep-back 
package, but they were kind of useless, since only one could be installed at 
the same time.I could have made a port for gnustep-back with the 
PSEUDO_FLAVORS, to allow the user to install all in parallel, and to choose 
which backend he wants for each application, but because of the complexity, I 
decided against it, since everything I ported, was tested with and works well 
with the cairo based backend, I just sticked to that.
Hope that answer helps you.

cheers,
Sebastian

>
> David
>
> [1] It doesn't do this on OS X, just for us because we are special.
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep