The check compress large chunk test makes up a 4GB string, compresses it, then decompresses and checks that it's the same string. While a useful test, it makes the test suite occupy at least 8 GB of RAM as witnessed by excerpt from +RTS -s from executing the test suite below:
14,212,450,144 bytes allocated in the heap
406,598,392 bytes copied during GC
8,283,161,336 bytes maximum residency (7 sample(s))
487,513,352 bytes maximum slop
8974 MiB total memory in use (97 MiB lost due to fragmentation)
By modern standards that's not too much but it becomes questionable on laptops with 8 GB of RAM. It's causing troubles in distributions like NixOS that run tests after building package by default. While tests are run in this fashion there's typically other processes in the RAM (on NixOS it may be particularly memory-hungry package manager nix process that wants its own number of gigabytes of RAM) so even presence of swap may not be enough or may lead no "infinite" swapping.
This issue is to reconsider the test or make it only execute if system has, say, at least 16 GB of RAM, etc.
Maybe another option is to make test lazier: i.e. generate lazy bytestrings on the fly and never retain them so that multi-gigabyte objects never stay on the heap?
The
check compress large chunktest makes up a 4GB string, compresses it, then decompresses and checks that it's the same string. While a useful test, it makes the test suite occupy at least 8 GB of RAM as witnessed by excerpt from+RTS -sfrom executing the test suite below:By modern standards that's not too much but it becomes questionable on laptops with 8 GB of RAM. It's causing troubles in distributions like NixOS that run tests after building package by default. While tests are run in this fashion there's typically other processes in the RAM (on NixOS it may be particularly memory-hungry package manager
nixprocess that wants its own number of gigabytes of RAM) so even presence of swap may not be enough or may lead no "infinite" swapping.This issue is to reconsider the test or make it only execute if system has, say, at least 16 GB of RAM, etc.
Maybe another option is to make test lazier: i.e. generate lazy bytestrings on the fly and never retain them so that multi-gigabyte objects never stay on the heap?