[Openmcl-devel] Clozure Common Lisp Version 1.2-r7902S (LinuxX8664)

Tue Feb 26 12:59:40 PST 2008

On Tue, 26 Feb 2008, Ralf Stoye wrote:

> Hi,
> just tested ccl on: Linux version 2.6.22-3-vserver-amd64 (Debian 
> 2.6.22-6.lenny1)
>
> After some hours there are no more problems  running
> "Hunchentoot 0.14.6 (Clozure Common Lisp Version 1.2-r7902S (LinuxX8664)) at 
> X.X.X.X:4242"
>
>
> Some problems though:
>
> 1.) Since this server is limited to 768 MB RAM , i had to use -R 2048000000 
> to be able to start & run without errors.
>
> Without that, i just got;
> Initial mmap: Cannot allocate memory
>
> after using -R xxxx, depending on xxxx, the errors changed:
>
> openmcl64 -R 1024000000
> exception in foreign context
> Exception occurred while executing foreign code
>
> openmcl64 -R 1224000000
> ;; seemed to be OK, but after some time, the lisp hang caused by gc
>
> openmcl64 -R 2048000000
> ;; seems to be OK
>
> Are there any rules of thumb specifying the "right" size?

What you're reserving is address space (not physical or virtual
memory); I've only ever seen the default fail on very old (e.g.,
3-4 year old) linux kernels; I've seen it fail on 2.6.9.

Does the "vserver" above indicate that this is running -in- a
virtual environment ?  Or is it hosting one ?

I have heard of people having difficulty running Ubuntu under
VMWare on a Windows (?) host; I'm also awar of people running
Fedora successfully under VMWare on a Mac host.  I don't know
how to generalize about that.

I have some 1GB machines running UBuntu 7.10 here   I don't
think that the difference between 768MB and 1GB would explain
this.

>
>
>
> 2.) There's a problem with ccl:run-program. It just hangs, waiting for some 
> semaphore:
> ? (run-program "/bin/ls" nil)
>> Break: interrupt signal
>> While executing: CCL::%PROCESS-WAIT-ON-SEMAPHORE-PTR, in process 
>> listener(1).
>> Type :GO to continue, :POP to abort, :R for a list of available restarts.
>> If continued: Return from BREAK.
>> Type :? for other options.
> 1 > :B
> (2AAAAACBB910) : 0 (%PROCESS-WAIT-ON-SEMAPHORE-PTR #<A Foreign Pointer 
> [gcable] #x64A2E0> 16777215 0 [...]) 461
> (2AAAAACBB9B8) : 1 (WAIT-ON-SEMAPHORE #<SEMAPHORE  #x300040DFFCBD> [...]) 205
> (2AAAAACBB9F0) : 2 (RUN-PROGRAM "/bin/ls" '("/bin/ls") [...]) 2221
> (2AAAAACBBB58) : 3 (CALL-CHECK-REGS 'RUN-PROGRAM [...]) 229
> (2AAAAACBBB90) : 4 (TOPLEVEL-EVAL '(RUN-PROGRAM "/bin/ls" NIL) [...]) 349
> (2AAAAACBBBE0) : 5 (READ-LOOP [...]) 1773
> (2AAAAACBBDE8) : 6 (TOPLEVEL-LOOP) 125
> (2AAAAACBBE18) : 7 (FUNCALL #'#<Anonymous Function #x3000404605CF>) 109
> (2AAAAACBBE30) : 8 (FUNCALL #'#<Anonymous Function #x30004059BEAF>) 597
> (2AAAAACBBEB8) : 9 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1) 
> [Active] #x300040DD6AAD> '(#)) 717
> (2AAAAACBBF48) : 10 (FUNCALL #'#<Anonymous Function #x30004047994F> 
> #<TTY-LISTENER listener(1) [Active] #x300040DD6AAD> '(#)) 365
> (2AAAAACBBF98) : 11 (FUNCALL #'#<Anonymous Function #x300040452C0F>) 301
> 1 >
>
> Is there any solution / workaround?
>
>
>
> 3) Since the used ccl is dated (ccl-071213) i tried to update it.
> After checking out current code, i did the following:

Did you check out from CVS or SVN ?

If SVN, there's a 1.1 branch that should match CVS; the SVN trunk
is all 1.2-not-quite-ready-yet code.

>
> v03-s154:/usr/local/src/ccl-head# ./lx86cl64 -n -R 2048000000
> Welcome to Clozure Common Lisp Version 1.2-r7902S  (LinuxX8664)!
> ? (setf *WARN-IF-REDEFINE-KERNEL* nil)
> NIL
> ? (load #p"ccl:lib;misc.lisp")
> ;Compiler warnings :
> ;   Undefined function TIMEVAL->MICROSECONDS (2 references), in REPORT-TIME.
> #P"/usr/local/src/ccl-head/lib/misc.lisp"
> ? (xload-level-0 :force)
> Can't find #P"ccl:xdump;xx8664-fasload.lx64fsl.newest" so requiring 
> "ccl:xdump;xx8664-fasload.lisp" instead
> Can't find #P"ccl:xdump;xfasload.lx64fsl.newest" so requiring 
> "ccl:xdump;xfasload.lisp" instead
> Can't find #P"ccl:xdump;heap-image.lx64fsl.newest" so requiring 
> "ccl:xdump;heap-image.lisp" instead
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-aprims.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-array.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-bignum32.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-bignum64.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-cfm-support.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-complex.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-def.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-error.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-float.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-hash.lisp"...
> ;Compiler warnings for "/usr/local/src/ccl-head/level-0/l0-hash.lisp" :
> ;   Undefined function %STRING-HASH, in %%EQUALHASH.
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-init.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-int.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-io.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-misc.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-numbers.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-pred.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-symbol.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/l0-utils.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/nfasload.lisp"...
> ;Compiler warnings for "/usr/local/src/ccl-head/level-0/nfasload.lisp" :
> ;   Undefined function SETF::|CCL::CODE-NOTE-PARENT-NOTE|, in 
> REGISTER-CODE-COVERED-FUNCTIONS.
> ;   Undefined function CODE-NOTE-PARENT-NOTE, in 
> REGISTER-CODE-COVERED-FUNCTIONS.
> ;   Undefined function CODE-NOTE-P, in REGISTER-CODE-COVERED-FUNCTIONS.
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/X8664/x8664-bignum.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-array.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-clos.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-def.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-float.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-hash.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-io.lisp"...
> ;Compiling "/usr/local/src/ccl-head/level-0/X86/x86-misc.lisp"...
>> Error: Unbound variable: X8664::XCF.PREV-XFRAME signaled during 
>> assembly-time evaluation of form X8664::XCF.PREV-XFRAME
>> While executing: PARSE-X86-LAP-EXPRESSION, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 >
>
> i am stuck here ...
>
>
> i know that the code isn't announced/released yet (Gary Byers, 11. Februar 
> 2008 00:34:32 MEZ),
> but i hope to be able to use it in a production environment soon, is there 
> any chance to do so?
>
>
>
> Greetings
> Ralf Stoye
>
>

I'm trying to put a release together, and have been saying "real soon
now" for several weeks.  (Er, months.)

Anyone who is (a) adventurous, the documentation's still a mess and
there aren't even any release notes) (b) able to use svn can do:

shell> svn co http://svn.clozure.com/publicsvn/openmcl/trunk/PLATFORM/ccl

where PLATFORM is one of "linuxx8664", "darwinx8664", "freebsdx8664",
"darwinppc", or "linuxppc"

That'll check out binaries/interfaces for the platform as well as
sources.  Subsequent "svn updates" might pull updated binaries (which
should make it easier to bootstrap things.)

I'm probably most suspicious of:

1) the possibility that virtualization is an issue
2) the possibility that machines with less that 1GB of memory
    have different notions of what "address space" means than
    other machines do.
3) changes in the lisp itself [*[

in roughly that order.

I just tried a fresh install of the 070722 linuxx8664 binary
on that 1GB system running Ubuntu 7.10, and didn't see any
problems.  (I think that Ubuntu 7.10 decided that /bin/arch
was redundant, and the "openmcl64" shell script tries to use
"/bin/arch" to determine the machine architecture, so I should
say "other than that".)

-----
[*] 2.6.23 kernels introduced changes that affected the shared-library
initialization code in CCL; fixes/workarounds for that are in CVS.