GitLab

This helps when the thread holding the lock has been descheduled,
which is the main cause of the "last-core slowdown" problem.  With
this patch, I get much better results with -N8 on an 8-core box,
although some benchmarks are still worse than with 7 cores.

I also added a yieldThread() into the any_work() loop of the parallel
GC when it has no work to do. Oddly, this seems to improve performance
on the parallel GC benchmarks even when all the cores are busy.
Perhaps it is due to reducing contention on the memory bus.

The card table is an array of bytes, placed directly following the
actual array data.  This means that array reading is unaffected, but
array writing needs to read the array size from the header in order to
find the card table.

We use a bytemap rather than a bitmap, because updating the card table
must be multi-thread safe.  Each byte refers to 128 entries of the
array, but this is tunable by changing the constant
MUT_ARR_PTRS_CARD_BITS in includes/Constants.h.

- Defines a DTrace provider, called 'HaskellEvent', that provides a probe
  for every event of the eventlog framework.
- In contrast to the original eventlog, the DTrace probes are available in
  all flavours of the runtime system (DTrace probes have virtually no
  overhead if not enabled); when -DTRACING is defined both the regular
  event log as well as DTrace probes can be used.
- Currently, Mac OS X only.  User-space DTrace probes are implemented
  differently on Mac OS X than in the original DTrace implementation.
  Nevertheless, it shouldn't be too hard to enable these probes on other
  platforms, too.
- Documentation is at http://hackage.haskell.org/trac/ghc/wiki/DTrace

The GC had a two-level structure, G generations each of T steps.
Steps are for aging within a generation, mostly to avoid premature
promotion.  

Measurements show that more than 2 steps is almost never worthwhile,
and 1 step is usually worse than 2.  In theory fractional steps are
possible, so the ideal number of steps is somewhere between 1 and 3.
GHC's default has always been 2.

We can implement 2 steps quite straightforwardly by having each block
point to the generation to which objects in that block should be
promoted, so blocks in the nursery point to generation 0, and blocks
in gen 0 point to gen 1, and so on.

This commit removes the explicit step structures, merging generations
with steps, thus simplifying a lot of code.  Performance is
unaffected.  The tunable number of steps is now gone, although it may
be replaced in the future by a way to tune the aging in generation 0.

This is a batch of refactoring to remove some of the GC's global
state, as we move towards CPU-local GC.  

  - allocateLocal() now allocates large objects into the local
    nursery, rather than taking a global lock and allocating
    then in gen 0 step 0.

  - allocatePinned() was still allocating from global storage and
    taking a lock each time, now it uses local storage. 
    (mallocForeignPtrBytes should be faster with -threaded).
    
  - We had a gen 0 step 0, distinct from the nurseries, which are
    stored in a separate nurseries[] array.  This is slightly strange.
    I removed the g0s0 global that pointed to gen 0 step 0, and
    removed all uses of it.  I think now we don't use gen 0 step 0 at
    all, except possibly when there is only one generation.  Possibly
    more tidying up is needed here.

  - I removed the global allocate() function, and renamed
    allocateLocal() to allocate().

  - the alloc_blocks global is gone.  MAYBE_GC() and
    doYouWantToGC() now check the local nursery only.

-H alone causes the RTS to use a larger nursery, but without exceeding
the amount of memory that the application is already using.  It trades
off GC time against locality: the default setting is to use a
fixed-size 512k nursery, but this is sometimes worse than using a very
large nursery despite the worse locality.

Not all programs get faster, but some programs that use large heaps do
much better with -H.  e.g. this helps a lot with #3061 (binary-trees),
though not as much as specifying -H<large>.  Typically using -H<large>
is better than plain -H, because the runtime doesn't know ahead of
time how much memory you want to use.

Should -H be on by default?  I'm not sure, it makes some programs go
slower, but others go faster.

At the moment, this just saves a memory reference in the GC inner loop
(worth a percent or two of GC time).  Later, it will hopefully let me
experiment with partial steps, and simplifying the generation/step
infrastructure.

In a stack overflow situation, stack squeezing may reduce the stack
size, but we don't know whether it has been reduced enough for the
stack check to succeed if we try again.  Fortunately stack squeezing
is idempotent, so all we need to do is record whether *any* squeezing
happened.  If we are at the stack's absolute -K limit, and stack
squeezing happened, then we try running the thread again.

We also want to avoid enlarging the stack if squeezing has already
released some of it.  However, we don't want to get into a
pathalogical situation where a thread has a nearly full stack (near
its current limit, but not near the absolute -K limit), keeps
allocating a little bit, squeezing removes a little bit, and then it
runs again.  So to avoid this, if we squeezed *and* there is still
less than BLOCK_SIZE_W words free, then we enlarge the stack anyway.

The log file format was still using 32 bits, this just updates the
header file to match; there should be no functional changes.

Patch 1/2: second part of the patch is to libraries/base

This time without dynamic linker hacks, instead I've expanded the
existing rts/Globals.c to cache more CAFs, specifically those in
GHC.Conc.  We were already using this trick for signal handlers, I
should have realised before.

It's still quite unsavoury, but we can do away with rts/Globals.c in
the future when we switch to a dynamically-linked GHCi.

This helps on a hyperthreaded CPU by yielding to the other thread in a
spinlock loop.

added:

 primop  TraceEventOp "traceEvent#" GenPrimOp
   Addr# -> State# s -> State# s
   { Emits an event via the RTS tracing framework.  The contents
     of the event is the zero-terminated byte string passed as the first
     argument.  The event will be emitted either to the .eventlog file,
     or to stderr, depending on the runtime RTS flags. }

and added the required RTS functionality to support it.  Also a bit of
refactoring in the RTS tracing code.

This makes events smaller and tracing quicker, and speeds up reading
and sorting the trace file.

HEADS UP: this changes the format of event log files.  Corresponding
changes to the ghc-events package are required (and will be pushed
soon).  Normally we would make backwards-compatible changes, but this
changes the format of every event (to remove the capability) so I'm
breaking the rules this time.  This will be the only time we can do
this, since the format becomes public in 6.12.1.

These indicate the size and time span of a sequence of events in the
event log, to make it easier to sort and navigate a large event log.

Flags (from +RTS -?):

  -qg[<n>]  Use parallel GC only for generations >= <n>
            (default: 0, -qg alone turns off parallel GC)
  -qb[<n>]  Use load-balancing in the parallel GC only for generations >= <n>
            (default: 1, -qb alone turns off load-balancing)

these are good defaults for most parallel programs.  Single-threaded
programs that want to make use of parallel GC will probably want +RTS
-qg1 (this is documented).

I've also updated the docs.

  - tracing facilities are now enabled with -DTRACING, and -DDEBUG
    additionally enables debug-tracing.  -DEVENTLOG has been
    removed.

  - -debug now implies -eventlog

  - events can be printed to stderr instead of being sent to the
    binary .eventlog file by adding +RTS -v (which is implied by the
    +RTS -Dx options).

  - -Dx debug messages can be sent to the binary .eventlog file
    by adding +RTS -l.  This should help debugging by reducing
    the impact of debug tracing on execution time.

  - Various debug messages that duplicated the information in events
    have been removed.

This has no effect with static libraries, but when the RTS is in a
shared library it does two things:

 - it prevents the function from being exposed by the shared library

 - internal calls to the function can use the faster non-PLT calls,
   because the function cannot be overriden at link time.

I've updated the wiki page about the RTS headers
  http://hackage.haskell.org/trac/ghc/wiki/Commentary/SourceTree/Includes
to reflect the new layout and explain some of the rationale.  All the
header files now point to this page.

Somehow this got lost, probably in the recent RTS tidy-up.  
Fixes segfaults in unregisterised compilation.

There were two bugs, and had it not been for the first one we would
not have noticed the second one, so this is quite fortunate.

The first bug is in stg_unblockAsyncExceptionszh_ret, when we found a
pending exception to raise, but don't end up raising it, there was a
missing adjustment to the stack pointer.  

The second bug was that this case was actually happening at all: it
ought to be incredibly rare, because the pending exception thread
would have to be killed between us finding it and attempting to raise
the exception.  This made me suspicious.  It turned out that there was
a race condition on the tso->flags field; multiple threads were
updating this bitmask field non-atomically (one of the bits is the
dirty-bit for the generational GC).  The fix is to move the dirty bit
into its own field of the TSO, making the TSO one word larger (sadly).

The first phase of this tidyup is focussed on the header files, and in
particular making sure we are exposinng publicly exactly what we need
to, and no more.

 - Rts.h now includes everything that the RTS exposes publicly,
   rather than a random subset of it.

 - Most of the public header files have moved into subdirectories, and
   many of them have been renamed.  But clients should not need to
   include any of the other headers directly, just #include the main
   public headers: Rts.h, HsFFI.h, RtsAPI.h.

 - All the headers needed for via-C compilation have moved into the
   stg subdirectory, which is self-contained.  Most of the headers for
   the rest of the RTS APIs have moved into the rts subdirectory.

 - I left MachDeps.h where it is, because it is so widely used in
   Haskell code.
 
 - I left a deprecated stub for RtsFlags.h in place.  The flag
   structures are now exposed by Rts.h.

 - Various internal APIs are no longer exposed by public header files.

 - Various bits of dead code and declarations have been removed

 - More gcc warnings are turned on, and the RTS code is more
   warning-clean.

 - More source files #include "PosixSource.h", and hence only use
   standard POSIX (1003.1c-1995) interfaces.

There is a lot more tidying up still to do, this is just the first
pass.  I also intend to standardise the names for external RTS APIs
(e.g use the rts_ prefix consistently), and declare the internal APIs
as hidden for shared libraries.