GitLab

Quoting design rationale by dcoutts: The event indicates that we're doing
a stop-the-world GC and all other HECs should be between their GC_START
and GC_END events at that moment. We don't want to use GC_STATS_GHC
for that, because GC_STATS_GHC is for extra GHC-specific info,
not something we have to rely on to be able to match the GC pauses
across HECs to a particular global GC.

There was a discrepancy between GC times reported in +RTS -s
and the timestamps of GC_START and GC_END events on the cap,
on which +RTS -s stats for the given GC are based.
This is fixed by posting the events with exactly the same timestamp
as generated for the stat calculation. The calls posting the events
are moved too, so that the events are emitted close to the time instant
they claim to be emitted at. The GC_STATS_GHC was moved, too, ensuring
it's emitted before the moved GC_END on all caps, which simplifies tools code.

In stat_exit we want to emit a final EVENT_HEAP_ALLOCATED for each cap
so that we get the same total allocation count as reported via +RTS -s.
To do so we need to update the per-cap total_allocated counts.

Previously we had a single calcAllocated(rtsBool) function that counted
the large allocations and optionally the nurseries for all caps. The GC
would always call it with false, and the stat_exit always with true.
The reason for these two modes is that the GC counts the nurseries via
clearNurseries() (which also updates the per-cap total_allocated
counts), so it's only the stat_exit() path that needs to count them.

We now split the calcAllocated() function into two: countLargeAllocated
and updateNurseriesStats. As the name suggests, the latter now updates
the per-cap total_allocated counts, in additon to returning a total.

Will let us do final per-cap trace events from stat_exit().
Otherwise we would end up with eventlogs with events for caps
that have already been deleted.

The EventLogFormat.h described the spark counter fields in a different
order to that which ghc emits (the GC'd and fizzled fields were
reversed). At this stage it is easier to fix the ghc-events lib and
to have ghc continue to emit them in the current order.

They cover much the same info as is available via the GHC.Stats module
or via the '+RTS -s' textual output, but via the eventlog and with a
better sampling frequency.

We have three new generic heap info events and two very GHC-specific
ones. (The hope is the general ones are usable by other implementations
that use the same eventlog system, or indeed not so sensitive to changes
in GHC itself.)

The general ones are:

 * total heap mem allocated since prog start, on a per-HEC basis
 * current size of the heap (MBlocks reserved from OS for the heap)
 * current size of live data in the heap

Currently these are all emitted by GHC at GC time (live data only at
major GC).

The GHC specific ones are:

 * an event giving various static heap paramaters:
   * number of generations (usually 2)
   * max size if any
   * nursary size
   * MBlock and block sizes
 * a event emitted on each GC containing:
   * GC generation (usually just 0,1)
   * total bytes copied
   * bytes lost to heap slop and fragmentation
   * the number of threads in the parallel GC (1 for serial)
   * the maximum number of bytes copied by any par GC thread
   * the total number of bytes copied by all par GC threads
     (these last three can be used to calculate an estimate of the
      work balance in parallel GCs)

Also rename internal variables to make the names match what they hold.
The parallel GC work balance is calculated using the total amount of
memory copied by all GC threads, and the maximum copied by any
individual thread. You have serial GC when the max is the same as
copied, and perfectly balanced GC when total/max == n_caps.

Previously we presented this as the ratio total/max and told users
that the serial value was 1 and the ideal value N, for N caps, e.g.

  Parallel GC work balance: 1.05 (4045071 / 3846774, ideal 2)

The downside of this is that the user always has to keep in mind the
number of cores being used. Our new presentation uses a normalised
scale 0--1 as a percentage. The 0% means completely serial and 100%
is perfect balance, e.g.

  Parallel GC work balance: 4.56% (serial 0%, perfect 100%)

In addition to the existing global method. For now we just do
it both ways and assert they give the same grand total. At some
stage we can simplify the global method to just take the sum of
the per-cap counters.

Now that we can adjust the number of capabilities on the fly, we need
this reflected in the eventlog. Previously the eventlog had a single
startup event that declared a static number of capabilities. Obviously
that's no good anymore.

For compatability we're keeping the EVENT_STARTUP but adding new
EVENT_CAP_CREATE/DELETE. The EVENT_CAP_DELETE is actually just the old
EVENT_SHUTDOWN but renamed and extended (using the existing mechanism
to extend eventlog events in a compatible way). So we now emit both
EVENT_STARTUP and EVENT_CAP_CREATE. One day we will drop EVENT_STARTUP.

Since reducing the number of capabilities at runtime does not really
delete them, it just disables them, then we also have new events for
disable/enable.

The old EVENT_SHUTDOWN was in the scheduler class of events. The new
EVENT_CAP_* events are in the unconditional class, along with the
EVENT_CAPSET_* ones. Knowing when capabilities are created and deleted
is crucial to making sense of eventlogs, you always want those events.
In any case, they're extremely low volume.

Fixes Trac #5957, which pointed out that
  Int -> Ord a => a -> a
is not Haskell 98

Signed-off-by: Paolo Capriotti <p.capriotti@gmail.com>

We now always have base4, and don't need a workaround for GHC 6.4.2.

Signed-off-by: Paolo Capriotti <p.capriotti@gmail.com>

This is motivated by the fact that before this change marking e.g.
GHC.List.filter as INLINABLE caused the compiler to diverge when
you tried to make use of the function.

The response is to say that a RULE on an imported function introduces
a dependency edge between the FVs of its LHS and RHS for the purposes
of computing loop breakers. This will not perfectly prevent all those
potential inlinings that could cause the compiler to non-terminate,
but it works well enough for the particular case we are interested in.

We might be in the "knot" of a type declaration: see Trac #5968.

variables work in Template Haskell

Triggered by fixing Trac #5968.

Fixes Trac #5951

Add support for ELF objects on ARM to the runtime linker. While the list of
relocation types in the "ELF for the ARM Architecture" specification spans four
pages, we thankfully only see a handful of these in the wild. Thus, at the
moment we only support the following .rel relocation types,

 * R_ARM_ABS32
 * R_ARM_TARGET1
 * R_ARM_REL32
 * R_ARM_CALL
 * R_ARM_JUMP24
 * R_ARM_MOVT_ABS
 * R_ARM_MOVW_ABS_NC
 * R_ARM_THM_CALL
 * R_ARM_THM_JUMP24
 * R_ARM_THM_MOVT_ABS
 * R_ARM_THM_MOVW_ABS_NC
 * R_ARM_THM_JUMP8
 * R_ARM_THM_JUMP11
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>

If the old stack is only half full, then the next chunk we allocate
will be twice as large, to accommodate large requests for stack.  In
that case, make sure that the chunk we allocate is at least as large
as the usual chunk size - there's no point allocating a 2k chunk
(double the default initial chunk size of 1k) if in the normal case we
would allocate a 32k chunk.

If we overflow the current stack chunk and copy its entire contents
into the next stack chunk, we could end up with two UNDERFLOW_FRAMEs.
We had a special case to catch this in the case when the old stack
chunk was the last one (ending in STOP_FRAME), but it went wrong for
other chunks.

I found this bug while poking around in the core dump attached to
options and running the nofib suite: imaginary/wheel_sieve2 crashed
with +RTS -kc600 -kb300.

I don't know if this is the cause of all the symptoms reported in

This allows us to give a sensible error message when a Template Haskell
splice generates an occurrence without a binding site.

Fixes Trac #5959 and #5971

The absence of this was causing a loop when typechecking an interface
where the superclass context mentioned an associated type
   class C (T a) => D a where
     data T a

Fixes Trac #5970

No reason user should turn them off, just want for ghc developer
debugging uses.

A Forest is just a list, and we have a Show instance for
lists already.  We don't need a special Show instance for
Forests.  If we change our minds we can add a newtype,
but I don't think it's worth it.

Fixes Trac #5960