full-laziness optimization makes program run out of memory
The full laziness optimization pass seems to produce an executable that runs Out Of Memory. Without this optimization the executable runs without the OOM problem.
Please see the attachment for a full test case tc1.zip. Go into package.yaml and comment / uncomment the -fno-full-laziness flag.
Command used to build and run the program:
reset && stack clean && stack build && rm -rf data_bench && echo "Running .." && /usr/bin/time stack exec -- tc1
Setting -O0 and -ffull-laziness does NOT trigger the problem. -O1 must be set for the problem to become visible. As much as possible other optimization flags have been disabled to minimize the code transformation in the core-to-core pipeline (handy for when comparing with VS without full laziness).
GenerateCommand 2 1 11046 1 187960 to
GenerateCommand 1 1 11046 1 187960 in the source code also gets rid of the problem. This information might help to pinpoint the problem.
LTS 16.4 for ghc-8.8.3 was used as package set and compiler. 64 bits ubuntu 20.04
One of the following conclusions may be derived:
- My code was poorly written thus triggering the problem with full laziness optimization.
- This is normal that it happens sometimes, as stated in the documentation
Full laziness increases sharing, which can lead to increased memory residency.
- Even if the code is poor and the optimization doesn't always work that well ("increased memory residency"), the OOM problem is still severe and normally should not happen, thus might be an indication of a bug in the full laziness optimization pass.