GitLab

  These refer to unaligned locations that need to be written
  byte-at-a-time. This fixes the SPARC ghci failures in 
  the current head.

Part of the fix for #3171

 - add newAlignedPinnedByteArray# for allocating pinned BAs with
   arbitrary alignment

 - the old newPinnedByteArray# now aligns to 16 bytes

Foreign.alloca will use newAlignedPinnedByteArray#, and so might end
up wasting less space than before (we used to align to 8 by default).
Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte
aligned memory, which is enough to avoid problems with SSE
instructions on x86, for example.

There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes,
but would have failed if the header was not a multiple of 8
(fortunately it always was, even with profiling).  Also we
occasionally wasted some space unnecessarily due to alignment in
allocatePinned().

I haven't done anything about Foreign.malloc/mallocBytes, which will
give you the same alignment guarantees as malloc() (8 bytes on
Linux/x86 here).

In this version, I untag R1 before using it, and even enter R2 at the
end rather than simply returning it (which didn't work right when R2
was a thunk).

might fix #2925

  
Patch originally by Ivan Tomac <tomac@pacific.net.au>, amended by
Simon Marlow:

  - mkWeakFinalizer# commoned up with mkWeakFinalizerEnv#
  - GC parameters to ALLOC_PRIM fixed

This appears to be necessary on FreeBSD.  It might be necessary on
other OSs too, but I'm being cautious because using MAP_FIXED can lead
to crashes by overwriting existing mappings, and we have no (easy) way
to prevent that.

Eager blackholing can improve parallel performance by reducing the
chances that two threads perform the same computation.  However, it
has a cost: one extra memory write per thunk entry.  

To get the best results, any code which may be executed in parallel
should be compiled with eager blackholing turned on.  But since
there's a cost for sequential code, we make it optional and turn it on
for the parallel package only.  It might be a good idea to compile
applications (or modules) with parallel code in with
-feager-blackholing.

ToDo: document -feager-blackholing.

On x86_64, the RTS needs to allocate memory in the low 2Gb of the
address space.  On Linux we can do this with MAP_32BIT, but sometimes
this doesn't work (#2512) and other OSs don't support it at all
(#2063).  So to work around this:

  - Try MAP_32BIT first, if available.

  - Otherwise, try allocating memory from a fixed address (by default
    1Gb)

  - We now provide an option to configure the address to allocate
    from.  This allows a workaround on machines where the default
    breaks, and also provides a way for people to test workarounds
    that we can incorporate in future releases.

Fixes win32002(ghci)

Previously we only did this for references from object files, but we
should do it for all symbols, including those that GHCi looks up due
to FFI calls from bytecode.

Signficantly reduces the overhead for par, which means that we can
make use of paralellism at a much finer granularity.

This was causing problems because sometimes mremap() moved the memory
we had allocated from the low 2Gb to above the 2Gb boundary, causing
some linkages to fail.  There's no MAP_32BIT flag to mremap().

So now we just use mmap(MAP_ANON|MAP_32BIT) to allocated space for the
trampolines.  People without MAP_32BIT (eg. *BSD) will still have to
do something else here, such as allocating memory from a fixed
address; so I've made it slightly easier for those guys, but there's
still work to do (#2063).

One solution (that Simon PJ is advocating) is to turn on -fPIC by
default on x86-64.  This is a good solution as it removes the need for
MAP_32BIT, but doesn't work with -fvia-C, so probably this is for
later.

Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
isn't really a proper fix, but it'll help in some cases).
And I tidied up the error message for a DLL load failure, though it's
still a bit of a mess because addDLL is supposed to return a (static)
string with the error message, but this isn't possible on Windows.

RTLD_NOW apparently causes some problems, according to previous
mailing-list discussion

 http://www.haskell.org/pipermail/cvs-ghc/2007-September/038570.html