GitLab

Solaris's sed apparently doesn't understand [:space:]

Solaris's sh gives
    /bin/sh: syntax error at line 1: `;' unexpected
when faced with something like
    for x in ; do ...; done
Patch from Christian Maeder.

(the image doesn't work, but at least db2latex doesn't fall over)

-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.

ALL_RTS_LIBS is (ab)used for linking ghc when BootingFromHc=Yes,
which needs libHSrtsmain.a before libHSrts.a.

It was off-by-one

We used to just get
    ghc: panic! (the 'impossible' happened)
      (GHC version 6.13.20091128 for x86_64-unknown-linux):
        too few bytes. Failed reading at byte position 32753
with no indication of what was being parsed.

Also corrected a couple of line 0's to line 1

So ghc-pkg register/update takes input in UTF-8, and ghc-pkg dump
outputs in UTF-8.  Textual package config files in the package DB are
assumed to be in UTF-8.

And make the code simpler in the process!

Caution: Largely untested

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.