May want to add `--ghc-options="+RTS -M500M -RTS"`

[lspitzner]

This may of course cause heap overflow, but in my (limited) experience it is rather likely that your build times out due to thrashing anyways if the usage goes above that limit.

Of course if you run your own travis instances or pay for extra memory then this will be no good.

[phadej]

We could put that to ~/.cabal/config, @hvr opinions?

FWIW: https://docs.travis-ci.com/user/reference/overview/ says there are at least 4GB, and as we have single GHC job, we can use at least -M2G. Does @lspitzner have a package which OOMs travis consistently without a bound?

[hvr]

@phadej I think -M500M would be indeed too conservative; on matrix.hho I use something around -M1700M (matrix' builders have only 2GiB of ram; and there's only very few packages which still OOM due to INLINE+-O2-abuse mostly) and those run at -j1; adding it to ghc-options: however will affect the nix-build hash (we should really fix that). Also, new-build luckily doesn't use ghc's -j option, so we'd have only to consider the process-level parallelism of ghc when doing cabal new-build -j2; TLDR: I'd suggest something like -M1700M (which should work with -j2 most of the time) and allowing this to be user-configurable via the script generator CLI.

[lspitzner]

@phadej when setting up the travis for brittany, i had consistent problems with a single module, see Instances.hs. As you can see, I went so far and 1) split the instances in a separate module 2) disabled certain optimizations. And I am mildly certain that this was on -j1. At several points I messed up the travis.yml so I don't entirely trust that observation, but -M500M seemed to have a pretty clear effect.

Travis has different sets of containers, right? Perhaps I just run on the wrong ones? I am not sure what else to make of these conflicting observations. Feel free to fork and test that repo.

[hvr]

random idea: write a test-suite which allocates various amounts of memory, and see at which point it gets killed by Travis CI to figure this out a bit more empirically :-)

[lspitzner]

It didn't get OOM killed though, ghc just never completed compiling that one module. You'd need to test timings for random memory accesses in a working set of specified size, or (haskell) major gc pause times with large amounts of memory allocated or something in those directions.

[hvr]

@lspitzner which GHC version did you observe that with? I noticed that some older versions like GHC 7.6 IIRC suffered from simply blocking (with 0% cpu usage) for certain packages.

[lspitzner]

mostly 8.0.2 i think. perhaps 8.2.1, but certainly nothing 7.* (brittany started on 8.0 ghc api)