gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] GCL exists while running smoe benchmarks


From: Camm Maguire
Subject: Re: [Gcl-devel] GCL exists while running smoe benchmarks
Date: Sun, 11 Nov 2018 13:14:47 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Greetings!

GCL can now make use of all system memory available.  On certain
machines (e.g. amd64) code is compiled in the 'medium memory' model for
efficiency (and reliability), which means that all code must be loaded
within the same 2Gb.  If your heap exceeds this before load, and your
existing code space is full, you get this message.

To reserve more space for code, do

(progn (setq si::*code-block-reserve* (make-array 50000000 :element-type
                               'character :static t) nil))

Alternatively, you can limit your heap growth with environment variables
as explained on this list -- search for GCL_MEM_MULTIPLE.

Please let me know if problems persist.  Thanks for checking this out!

Take care,

Jeronimo Pellegrini <address@hidden> writes:

> Now -- could that be loop unrolling that exceeded the max size that PROGN 
> takes in GCL?
>
> J.
>
> On November 9, 2018 5:23:05 PM GMT-02:00, Jeronimo Pellegrini 
> <address@hidden> wrote:
>
>  Hello,
>
> So -- I had used GCL in the past with Spartns 
> (https://gitlab.com/jpellegrini/spartns)
> and it worked fine. However, currently this is what happens:
>
> - the released version (Debian package, 2.6.12-80) fails
>   several Spartns unit tests. This is finem because:
>
> - the git checkout does pass all tests! However, when running 
>   the benchmarks, it exits abnormally:
>
> $ GCL_ANSI=1 gcl
> GCL (GNU Common Lisp)  2.7.0 ANSI    Nov  6 2018 23:26:25
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/user/1000/
>
>  (si::use-fast-links nil) 
>
> NIL
>
>  (load "do-benchmarks.lisp")
>
> ...
> ... ;; lots of normal output here, from other functions being compiled
> ...
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, 
> (Debug quality ignored)
> ;; Finished compiling /tmp/user/1000/gazonk_12854_0.o.
> ;; Loading #P"/tmp/user/1000/gazonk_12854_0.o"
>
> Error: 
> Signalled by PROGN.
> Condition in PROGN [or a callee]: INTERNAL-SIMPLE-ERROR: The assertion v && 
> (unsigned long)(v+sz)<MAX_CODE_ADDRESS
>  on line 1035 of alloc.c in function alloc_code_space
>  failed: Success
>
> Broken at SYSTEM::BREAK-LEVEL.  Type :H for Help.
>     1  Return to top level. 
> SPARTNS>> :bt
>
> #0   INVOKE-DEBUGGER {loc0=#<conditions::internal-simple-error.0>} [ihs=21]
> #1   LOAD-FASL {loc0=#P"/tmp/user/1000/gazonk_12854_0.o",loc1=nil} [ihs=18]
> #2   LOAD-PATHNAME 
> {loc0=#P"/tmp/user/1000/gazonk_12854_0.o",loc1=nil,loc2=:error,loc3=nil,loc4=nil...}
>  [ihs=17]
> #3   LOAD {loc0=#P"/tmp/user/1000/gazonk_12854_0.o"} [ihs=16]
> #4   COMPILE {loc0=run-cvector-get,loc1=(nil),loc2=nil} [ihs=15]
> #5   LOAD-STREAM {} [ihs=11]
> #6   LOAD-PATHNAME 
> {loc0=#P"benchmark.lisp",loc1=nil,loc2=:error,loc3=nil,loc4=nil,loc5=#<input 
> str...} [ihs=10]
> #7   LOAD {loc0="benchmark.lisp"} [ihs=9]
> #8   LOAD-STREAM {} [ihs=7]
> #9   LOAD-PATHNAME 
> {loc0=#P"do-benchmarks.lisp",loc1=nil,loc2=:error,loc3=nil,loc4=nil,loc5=#<input...}
>  [ihs=6]
> #10   LOAD {loc0="do-benchmarks.lisp"} [ihs=5]
>
> The benchmarks were written in a very lazy state of mind, so I have
> a big macro that generates lots of functions. But I wasn't expecting this,
> since the generated functions are actually simple (nested loops for accessing
> vectors and hashtables, mostly)...
>
> What does the error mean?
> It's funny that the error happens not during the execution of the benchmark,
> but when the function (which is quite simple actually) is being compiled!
>
> That something called "MAX_CODE_ADDRESS" has been exceeded makes me worried! 
> :-)
>
> What could I possibly be doing to trigger that?
>
> (Anyway -- ECL, SBCL, Clisp, ccl seem to compile and run the benchmarks with 
> no
>  problem)
>
> The easy way to reproduce:
>
> $ git clone https://gitlab.com/jpellegrini/spartns.git
> $ cd spartns
> $ GCL_ANSI=1 gcl
>
>  (si::use-fast-links nil)
>
>  (load "do-benchmarks.lisp")
>
> Thanks,
> J.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Gcl-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]