* Heap space when building SBCL packages
@ 2020-03-23 14:40 Konrad Hinsen
2020-03-23 14:59 ` Pierre Neidhardt
0 siblings, 1 reply; 11+ messages in thread
From: Konrad Hinsen @ 2020-03-23 14:40 UTC (permalink / raw)
To: help-guix
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Heap space when building SBCL packages
2020-03-23 14:40 Heap space when building SBCL packages Konrad Hinsen
@ 2020-03-23 14:59 ` Pierre Neidhardt
2020-03-23 17:06 ` Guillaume Le Vaillant
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Pierre Neidhardt @ 2020-03-23 14:59 UTC (permalink / raw)
To: Konrad Hinsen, help-guix; +Cc: Guillaume Le Vaillant
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Heap space when building SBCL packages
2020-03-23 14:59 ` Pierre Neidhardt
@ 2020-03-23 17:06 ` Guillaume Le Vaillant
2020-03-23 17:17 ` Konrad Hinsen
2020-03-23 17:55 ` Pierre Neidhardt
2 siblings, 0 replies; 11+ messages in thread
From: Guillaume Le Vaillant @ 2020-03-23 17:06 UTC (permalink / raw)
To: Pierre Neidhardt; +Cc: help-guix
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Heap space when building SBCL packages
2020-03-23 14:59 ` Pierre Neidhardt
2020-03-23 17:06 ` Guillaume Le Vaillant
@ 2020-03-23 17:17 ` Konrad Hinsen
2020-03-23 17:55 ` Pierre Neidhardt
2 siblings, 0 replies; 11+ messages in thread
From: Konrad Hinsen @ 2020-03-23 17:17 UTC (permalink / raw)
To: Pierre Neidhardt, help-guix
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Heap space when building SBCL packages
2020-03-23 14:59 ` Pierre Neidhardt
2020-03-23 17:06 ` Guillaume Le Vaillant
2020-03-23 17:17 ` Konrad Hinsen
@ 2020-03-23 17:55 ` Pierre Neidhardt
2020-03-23 19:45 ` Konrad Hinsen
2 siblings, 1 reply; 11+ messages in thread
From: Pierre Neidhardt @ 2020-03-23 17:55 UTC (permalink / raw)
To: Konrad Hinsen, help-guix
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Heap space when building SBCL packages
2020-03-23 17:55 ` Pierre Neidhardt
@ 2020-03-23 19:45 ` Konrad Hinsen
2020-03-23 20:30 ` Pierre Neidhardt
0 siblings, 1 reply; 11+ messages in thread
From: Konrad Hinsen @ 2020-03-23 19:45 UTC (permalink / raw)
To: Pierre Neidhardt, help-guix
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-03-24 10:43 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-23 14:40 Heap space when building SBCL packages Konrad Hinsen
2020-03-23 14:59 ` Pierre Neidhardt
2020-03-23 17:06 ` Guillaume Le Vaillant
2020-03-23 17:17 ` Konrad Hinsen
2020-03-23 17:55 ` Pierre Neidhardt
2020-03-23 19:45 ` Konrad Hinsen
2020-03-23 20:30 ` Pierre Neidhardt
2020-03-24 7:40 ` Konrad Hinsen
2020-03-24 8:40 ` Guillaume Le Vaillant
2020-03-24 9:40 ` Pierre Neidhardt
2020-03-24 10:43 ` Konrad Hinsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).