cvs commit: fptools/ghc/includes Storage.h fptools/ghc/rts GC.c
wolfgang.thaller at gmx.net
Wed Mar 9 12:12:42 EST 2005
> 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.
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
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
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 <
else // else data comes before text
return caf < &someTextObjectInExecutable && caf->info >
More information about the Cvs-ghc