From: Guillaume Le Vaillant <glv@posteo.net>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: help-guix@gnu.org
Subject: Re: Heap space when building SBCL packages
Date: Mon, 23 Mar 2020 18:06:30 +0100 [thread overview]
Message-ID: <87sghzf1bd.fsf@yamatai> (raw)
In-Reply-To: <87sghz86cj.fsf@ambrevar.xyz>
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?
next prev parent reply other threads:[~2020-03-23 17:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sghzf1bd.fsf@yamatai \
--to=glv@posteo.net \
--cc=help-guix@gnu.org \
--cc=mail@ambrevar.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).