Re: Heap space when building SBCL packages

[Guillaume Le Vaillant]

Pierre Neidhardt <address@hidden> skribis:

> Hi Konrad,
>
>> I am trying to figure out why sbcl-numcl fails to build since the update
>> to SBCL 2.0.2. See here for a typical build log:
>>
>>    http://ci.guix.gnu.org/build/2339924/details
>>
>> What happens is that SBCL runs out of heap space and stops. However, I
>> can load numcl into SBCL 2.0.2 perfectly well when I load it via ASDF
>> under my own user account.
>>
>> Therefore I suspect one of the following three possible causes:
>>
>>  1. The build daemon runs with memory restrictions that are too severe
>>     for building binaries for numcl.
>
> Hmmm, my intuition is that it would be surprising considering we build
> very heavy packages.
>
>>  2. Building binaries with SBCL takes more heap space than merely
>>     loading a system from source via ASDF.
>
> I think probably not.  However there are different ASDF operation.  In the
> Guix build system we use "program-op" which does not behave like the
> default operation when loading a package.  This could be a factor here.
>
>>  3. Guix' build systems does something that either limits heap space
>>     or causes SBCL to require more of it.
>>
>> Does anyone have an idea on how to proceed to fix the problem?
>
> Can you reproduce with SBCL 2.0 or SBCL 1.5?
> Maybe report this issue to the SBCL issue tracker, they will probably
> know what's going on.
>
> Cheers!

In case the problem is that newer SBCL versions really need more memory
during compilation, we could pass "--dynamic-space-size" to "make.sh"
when building SBCL to increase the maximum heap size (1 Gb by default).

I tried rebuilding SBCL with "--dynamic-space-size=2Gb" and I was able
to compile sbcl-numcl.

IIRC, compiling the clml and mgl libraries requires a 4Gb max heap. So
if one day we want to package them in Guix we will need to use a bigger
default max heap size.

Do you see a case where a bigger default value could be a problem?