cvs commit: fptools/ghc/includes Storage.h fptools/ghc/rts GC.c Linker.c Storage.c

[Wolfgang Thaller]

> I've merged this, but I think a better solution might be for -fPIC to
> generate code that calls a different version of newCaf (i.e. 
> newDynCaf).

Well, we've got three different ways to treat a CAF now:

A) garbage collect them as usual - what newCAF used to do, and what it 
still does most of the time
B) retain them - what newCAF does now when we are in dynamically-linked 
ghci
C) retain them and maybe revert them later - what newDymCAF does.

Most of the time, CAFs from dynamic libraries should get treatment A, 
only in GHCi they should get treatment B. C is really reserved for .o 
files, we probably don't want to "revert" unsafePerformIO cafs in GHCi 
or the libraries.
So even if we made -fPIC call a different new*CAF, we'd still need the 
same checks for GHCi. It's not making things simpler, it only helps us 
to avoid retaining CAFs in the main program.

Also, it's still possible on Mac OS X to link -fPIC code statically, 
and on PowerPC64 Linux, all code is position independent, so you don't 
need -fPIC. I'm reluctant to add more GHC-specific code generation 
differences that would prevent that.

How bad is it to retain CAFs in GHCi? I think it shouldn't cause a 
problem in an interactive program like GHCi, where most things are 
meant to stick aroud anyway. I don't think there are any big CAFs used 
in GHCi during initialisation that can be collected when initialisation 
is done?
Iff we decide it's bad, then we'll want to do something about it - so 
far I can think of two things:
a) generate different calls for -fPIC. Ugly because it makes -fPIC more 
special than it is on some platforms.
b) check the CAF's address. Ugly in principle, but not as bad as the 
address space checks we used to have before GHC 6. I think it can even 
be done portably (based only on the assumption that no dynamic 
libraries are loaded _between_ the executable's code and data 
sections), because we are in a very controlled situation here. The CAF 
is in the data section and contains a pointer to the text section of 
the same executable/dylib. That way we wouldn't even need to get access 
to etext and friends again:

// returns true if caf is in the main executable
if(caf->info < caf)	// if text comes before data
	return caf > &someTextObjectInExecutable && caf->info < 
&someDataObjectInExecutable;
else					// else data comes before text
	return caf < &someTextObjectInExecutable && caf->info > 
&someDataObjectInExecutable;


Cheers,

Wolfgang