Steel Bank Common Lisp

Sebastian Tennant <sebyte@...> writes:

> Hi there commodity brokers,
>
> sbcl will only run on my low-powered VPS if a dynamic space size is
> specified when it is invoked, e.g.
>
>  $ sbcl --dynamic-space-size 128
>
> Is there a way to set this as a site-wide default?
>
> I'm new to sbcl and my understanding is that the config files
> /etc/sbclrc and ~/sbclrc can only contain lisp forms.
>
You can make a wrap around shell-script. Or you can recompile sbcl with
DEFAULT_DYNAMIC_SPACE_SIZE changed in sbcl/src/runtime/validate.h

-- 
With best regards, Stas.

Sebastian Tennant wrote:

> Is there a way to set this as a site-wide default?
>
> I'm new to sbcl and my understanding is that the config files
> /etc/sbclrc and ~/sbclrc can only contain lisp forms.

You might get away with this:

  (sb-alien:define-alien-variable
    ("dynamic_space_size" *sbcl%dynamic-space-size*)
    sb-alien:unsigned)

  (defconstant +MB+ (expt 1024 2))

  (setf *sbcl%dynamic-space-size* (* 128 +MB+))

 Leslie

-- 
http://www.linkedin.com/in/polzer

Hi Sebastian,

There's a slightly different, but very effective approach, which involves
a trampoline shell-script.

You can set up a script, either called 'sbcl' or something else (I tend to
call it 'lisp') which calls the actual sbcl runtime with the appropriate
arguments. The trick is to make sure it's the first thing that answers to
the given name in $PATH, then get everything to call that.

The starting point is `sbcl --dynamic-space-size 128` but you can add
further <a
href="http://www.sbcl.org/manual/Command-Line-Options.html">command-line
options</a> to suit, particularly --load and --eval.


Cheers,
James


> Hi there commodity brokers,
>
> sbcl will only run on my low-powered VPS if a dynamic space size is
> specified when it is invoked, e.g.
>
>  $ sbcl --dynamic-space-size 128
>
> Is there a way to set this as a site-wide default?
>
> I'm new to sbcl and my understanding is that the config files
> /etc/sbclrc and ~/sbclrc can only contain lisp forms.
>
> Regards,
>
> Sebastian
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

Quoth Stas Boukarev <stassats@...>:
> Or you can recompile sbcl with DEFAULT_DYNAMIC_SPACE_SIZE changed in
> sbcl/src/runtime/validate.h

sbcl/src/runtime/validate.h contains the following:

 #ifndef LISP_FEATURE_GENCGC
 /* FIXME: genesis/constants.h also defines this with a constant value */
 #define DYNAMIC_SPACE_START current_dynamic_space
 #endif

 #define BINDING_STACK_SIZE (1024*1024)   /* chosen at random */
 #define ALIEN_STACK_SIZE (1024*1024)     /* chosen at random */

 /* eventually choosable per-thread: */
 #define DEFAULT_CONTROL_STACK_SIZE (2*1024*1024)

 /* constants derived from the fundamental constants in passed by GENESIS */
 #ifdef LISP_FEATURE_GENCGC
 #define DEFAULT_DYNAMIC_SPACE_SIZE (DYNAMIC_SPACE_END - DYNAMIC_SPACE_START)
 #else
 #define DEFAULT_DYNAMIC_SPACE_SIZE (DYNAMIC_0_SPACE_END - DYNAMIC_0_SPACE_START)
 #endif

genesis/constants.h is not included in the source I've downloaded so presumably
LISP_FEATURE_GENCGC will not be defined at compile time, leaving me with the following
relevant line:

 #define DEFAULT_DYNAMIC_SPACE_SIZE (DYNAMIC_0_SPACE_END - DYNAMIC_0_SPACE_START)

However, I can't see where DYNAMIC_0_SPACE_START (and DYNAMIC_0_SPACE_END) are defined:

 # cd ~/lisp/cl/sbcl-1.0.28/
 # grep -r DYNAMIC_0_SPACE_START *
 src/runtime/sunos-os.c:       in_range_p(addr, DYNAMIC_0_SPACE_START, dynamic_space_size) ||
 src/runtime/coreparse.c:            if ((addr != (os_vm_address_t)DYNAMIC_0_SPACE_START) &&
 src/runtime/coreparse.c:                        (long)DYNAMIC_0_SPACE_START,
 src/runtime/hpux-os.c:        || (DYNAMIC_0_SPACE_START <= ad && ad < DYNAMIC_0_SPACE_END)
 src/runtime/linux-os.c:        || (DYNAMIC_0_SPACE_START <= ad && ad < DYNAMIC_0_SPACE_END)
 src/runtime/validate.h:#define DEFAULT_DYNAMIC_SPACE_SIZE (DYNAMIC_0_SPACE_END - DYNAMIC_0_SPACE_START)
 src/runtime/cheneygc.c:    if (current_dynamic_space == (lispobj *) DYNAMIC_0_SPACE_START)
 src/runtime/cheneygc.c:        new_space = (lispobj *) DYNAMIC_0_SPACE_START;
 src/runtime/cheneygc.c:       to set current_dynamic_space to DYNAMIC_0_SPACE_START here,
 src/runtime/validate.c:    ensure_space( (lispobj *)DYNAMIC_0_SPACE_START, dynamic_space_size);

Regards,

Sebastian

2009/6/3 Sebastian Tennant <sebyte@...>:

>> Or you can recompile sbcl with DEFAULT_DYNAMIC_SPACE_SIZE changed in
>> sbcl/src/runtime/validate.h

That was slightly misleading advice, sorry for not catching it in the
first place. Those constants are defined in Lisp, and the appropriate
C headers are generated during the build. The canonical place to touch
is src/compiler/<arch>/parms.lisp.

Assuming you are on x86/Linux, you would change this
src/compiler/x86/parms.lisp. Look for

#!+linux
(progn
  (def!constant read-only-space-start     #x01000000)
  (def!constant read-only-space-end       #x010ff000)

  (def!constant static-space-start        #x01100000)
  (def!constant static-space-end          #x011ff000)

  (def!constant dynamic-space-start       #x09000000)
  (def!constant dynamic-space-end         #x29000000)

  (def!constant linkage-table-space-start #x01200000)
  (def!constant linkage-table-space-end   #x012ff000))

-- or the corresponding section for your OS, and lower the
DYNAMIC-SPACE-END closer to DYNAMIC-SPACE-START.

...and yes, there should be an easier way to do this. I've added a bug
about this:

  https://bugs.launchpad.net/sbcl/+bug/383222

Cheers,

 -- Nikodemus

Quoth Nikodemus Siivola <nikodemus@...>:
> That was slightly misleading advice, sorry for not catching it in the
> first place. Those constants are defined in Lisp, and the appropriate
> C headers are generated during the build. The canonical place to touch
> is src/compiler/<arch>/parms.lisp.

Thanks Nikodemus.

I lowered the value of dynamic-space-end in src/compiler/x86/parms.lisp to #x11000000 and
ran make.sh like so:

 # sh make.sh "sbcl --dynamic-space-size 128" 2>&1 | tee ../sbcl-compile.log

About 10 mins and 78466 lines of output later the compile was complete.

However, I received the following final warning:

 WARNING! Some of the contrib modules did not build successfully or pass
 their self-tests. Failed contribs:"
   asdf-install
   sb-bsd-sockets
   sb-posix
   sb-simple-streams

and upon inspection, noticed that each of these modules encoutered compilation errors of
the form:

 unhandled SIMPLE-ERROR: couldn't fork child process: Cannot allocate memory
 [...]
 ; compilation unit aborted
 ;   caught 1 fatal ERROR condition

As it is *child* processes that are failing I assume the problem is not the restricted
dynamic space size of the cross compilation host, rather the low specs of my VPS.

I will free up more resources (at some ungodly hour) and try again.

> ...and yes, there should be an easier way to do this. I've added a bug about this:
>
>   https://bugs.launchpad.net/sbcl/+bug/383222

I agree this could/should be easier.

Thanks again,

Sebastian

2009/6/4 Sebastian Tennant <sebyte@...>:

> and upon inspection, noticed that each of these modules encoutered compilation errors of
> the form:
>
>  unhandled SIMPLE-ERROR: couldn't fork child process: Cannot allocate memory
>  [...]
>  ; compilation unit aborted
>  ;   caught 1 fatal ERROR condition
>
> As it is *child* processes that are failing I assume the problem is not the restricted
> dynamic space size of the cross compilation host, rather the low specs of my VPS.

That sounds probable. You might be able to squeeze the contrib build
thru by adding --dynamic-space-size 64 to make-target-contrib.sh, as
well.

Cheers,

 -- Nikodemus