Heap space when building SBCL packages

Heap space when building SBCL packages

[Konrad Hinsen]

Hi Guix,

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.

 2. Building binaries with SBCL takes more heap space than merely
    loading a system from source via ASDF.

 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?

Cheers,
  Konrad.

Re: Heap space when building SBCL packages

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Heap space when building SBCL packages

[Guillaume Le Vaillant]

Pierre Neidhardt <mail@ambrevar.xyz> 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?

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Hi Pierre,

>>  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.

Worth testing, if only to have a non-Guix way to illustrate the issue
for reporting upstream if necessary.

Is there a way to get the exact ASD file plus command line that is used
by the build system?

>>  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?

Building sbcl-numcl works fine with 1.5 and 2.0. It's only with 2.0.2
that there is this heap issue.

> Maybe report this issue to the SBCL issue tracker, they will probably
> know what's going on.

If it's not a Guix issue, then yes, that's the way to proceed.

Cheers,
  Konrad.

Re: Heap space when building SBCL packages

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

You could also try playing with the
`--dynamic-space-size` command line flag, e.g.

  sbcl --dynamic-space-size 2048 ...

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> You could also try playing with the
> `--dynamic-space-size` command line flag, e.g.
>
>   sbcl --dynamic-space-size 2048 ...

That was a good idea. It turns out that 1024 is just a bit too low to do
program-op, though load-system works. With 1280 I can do program-op on
numcl.

So it looks like SBCL 2.0.2 just needs a bit of extra memory compared to
older versions. Guillaume's suggestion of increasing the limit should
thus be sufficient.

Cheers,
  Konrad.

Re: Heap space when building SBCL packages

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

Thanks for investigating this!
Can you send a patch?  Or maybe Guillaume?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Thanks for investigating this!
> Can you send a patch?  Or maybe Guillaume?

Not me, sorry. I haven't figured out yet how the asdf-build-system
works. Nor build systems in general.

Cheers,
  Konrad

Re: Heap space when building SBCL packages

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]


Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Thanks for investigating this!
>> Can you send a patch?  Or maybe Guillaume?
>
> Not me, sorry. I haven't figured out yet how the asdf-build-system
> works. Nor build systems in general.
>
> Cheers,
>   Konrad

I pushed the fix as 47a2306415cf19270cb398590be3d95a92a0e73b.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Heap space when building SBCL packages

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 57 bytes --]

Thanks!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Guillaume Le Vaillant <glv@posteo.net> writes:

> I pushed the fix as 47a2306415cf19270cb398590be3d95a92a0e73b.

Thanks a lot - this works just fine!

Cheers,
  Konrad.