Building std_spec runs ouf memory on 32-bit platform

[straight-shoota]

The test_linux32 job is continuously failing because the compiler runs out of memory while building std_spec (example: https://github.com/crystal-lang/crystal/runs/3260787966).

It seems that the amount of specs for the standard library is exceeding the limitations of 32-bit address space (or available memory on the runner machine, but I suppose both are probably 4 GB). That's kind of a good sign because it means we have a lot of test cases. (On the other hand, the compiler is also very memory hungry 😢)

There had previously been issues while running the stdlib specs which have been worked around by splitting spec execution into several batches (#8065).
We should be able to apply a similar workaround when building the standard specs. We could split the top-level entries in spec/std/ into different buckets to build and run them separately.

As an alternative, we could also try to increase swap space on the CI runner. But I expect splitting stdlib specs would be more efficient. It's also generally useful for any system with memory limitations (I recently tried to compile stdlib specs on a Raspberry PI with 2GB memory 🙈).
If we could make sure there are no interferences or side effects, this could also be an efficient way to parallelize specs. Perhaps it could work with a separate cache directory for every batch. Might be an idea to investigate as a follow-up...

[straight-shoota]

Splitting std specs into separate slices (3 in this example) significantly lowers memory requirement as well as overall compile time:

Command being timed: "make std_spec"
        User time (seconds): 419.41
        System time (seconds): 69.73
        Percent of CPU this job got: 240%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 3:23.54
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 3218200
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 4194467
        Voluntary context switches: 40907
        Involuntary context switches: 6779
        Swaps: 0
        File system inputs: 3272
        File system outputs: 564328
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

Command being timed: "SPEC_SPLIT=3 .test/split.sh spec/std bin/crystal spec"
        User time (seconds): 249.13
        System time (seconds): 32.44
        Percent of CPU this job got: 158%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:57.98
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1692028
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 4309632
        Voluntary context switches: 40134
        Involuntary context switches: 3838
        Swaps: 0
        File system inputs: 1440
        File system outputs: 605328
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

[yxhuvud]

It's unfortunate that LLVM isn't more resistant to memory limits. 2GB should really be enough to compile anything reasonable, it should just be slower :(

I wonder if there is anything we could do on our side to reduce the memory use. I tried googling for it but couldn't find anything relevant :(