On 09 March 2005 17:13, Wolfgang Thaller wrote:
>> 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;
Ok, so the question of whether to retain CAFs is really one of GHCi vs.
standalone program, rather than static vs. dynamic linking. Of course
if you're doing anything GHCi-like (eg. hs-plugins) then the same issues
arise, but I believe hs-plugins does its own CAF-retention by making
explicit stable pointers to the entities it provides.
Our CAF-reverting machinery doesn't actually work that well, because it
only applies to compiled code (we never implemented it for interpreted
code).
I think you're right that there aren't any large CAFs in GHCi that are
used only during initialisation. So always retaining CAFs in GHCi
perhaps isn't too bad. Incedentally, if we're always retaining CAFs,
then the part of the GC that traverses the SRTs can be turned off (this
is worthwhile in GHC, which has a large SRT graph to traverse).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
