axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] How to allocate more space for Axiom on Windows


From: Gregory Vanuxem
Subject: Re: [Axiom-developer] How to allocate more space for Axiom on Windows
Date: Sat, 03 Feb 2007 22:39:05 +0100

Le samedi 03 février 2007 à 16:02 -0500, William Sit a écrit : 
> On Sat, 03 Feb 2007 15:41:57 -0500
>   William Sit <address@hidden> wrote:
> >    >> System error:
> >    The storage for CONS is exhausted.
> >Currently, 82689 pages are allocated.
> >Use ALLOCATE to expand the space.
> >
> >Can any one tell me how to increase the space? Exactly 
> >how
> >big is one page?

4096 bytes (1 << 12) 

)lis (room) will tell you the number of page availables. This is fixed
at compile time so if you have compiled with the default options you'll
be limited to 512Mo (and I don't know exactly the memory organisation,
Camm could tell you, but you'll not be able I think to allocate all the
space for cons since there are contiguous pages, relocatable pages ...).

You can use the function allocate:

-- Function: ALLOCATE (type number &optional (really-allocate nil))
     Package:LISP

     GCL specific: Sets the maximum number of pages for the type class
     of the GCL implementation type TYPE to NUMBER.  If REALLY-ALLOCATE
     is given a non-NIL value, then the specified number of pages will
     be allocated immediately.

>(room)

   434/434    47.5%         CONS BIGNUM RATIO COMPLEX STRUCTURE
     7/45     76.9%         FIXNUM SHORT-FLOAT LONG-FLOAT CHARACTER
RANDOM-STATE READTABLE SPICE
   154/736    85.6%         SYMBOL STREAM PATHNAME CCLOSURE CLOSURE
     1/2      23.9%         PACKAGE
     2/59     21.2%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
    21/33     97.9%         CFUN CFDATA
    45/59     99.1%         SFUN STRING GFUN VFUN AFUN

   805/2215                 contiguous (125 blocks)
       26214                hole
       10485   0.0%         relocatable

       664 pages for cells
     38168 total pages
    202532 pages available
     21444 pages in heap but not gc'd + pages needed for gc marking
    262144 maximum pages

>(allocate 'cons 512)

T

>(room)

   434/512    48.8%         CONS BIGNUM RATIO COMPLEX STRUCTURE
     7/45     81.7%         FIXNUM SHORT-FLOAT LONG-FLOAT CHARACTER
RANDOM-STATE READTABLE SPICE
   154/736    85.6%         SYMBOL STREAM PATHNAME CCLOSURE CLOSURE
     1/2      23.9%         PACKAGE
     2/59     21.2%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
    21/33     97.9%         CFUN CFDATA
    45/59     99.4%         SFUN STRING GFUN VFUN AFUN

   805/2215                 contiguous (120 blocks)
       26214                hole
       10485   0.0%         relocatable

       664 pages for cells
     38168 total pages
    202532 pages available
     21444 pages in heap but not gc'd + pages needed for gc marking
    262144 maximum pages


Greg

----------------------------------------------------------------------
Random documentation (under LGPL I think):


-- Variable: *IGNORE-MAXIMUM-PAGES*
     Package:SI GCL specific: Tells the GCL memory manager whether
     (non-NIL) or not (NIL) it should expand memory whenever the
     maximum allocatable pages have been used up.


-- Variable: *OPTIMIZE-MAXIMUM-PAGES*
     Package:SI

     GCL specific: Tells the GCL memory manager whether to attempt to
     adjust the maximum allowable pages for each type to approximately
     optimize the garbage collection load in the current process.
     Defaults to T.  Set to NIL if you care more about memory usage
     than runtime.

-- Function: GBC (x)
     Package:LISP

     GCL specific: Invokes the garbage collector (GC) with the
     collection level specified by X.  NIL as the argument causes GC to
     collect cells only.  T as the argument causes GC to collect
     everything.

-- Function: MAXIMUM-CONTIGUOUS-PAGES ()
     Package:SI

     GCL specific: Returns the current maximum number of pages for
     contiguous blocks.


-- Function: GET-HOLE-SIZE ()
     Package:SI

     GCL specific: Returns as a fixnum the size of the memory hole (in
     pages).

-- Function: ALLOCATE-CONTIGUOUS-PAGES (number &optional
          (really-allocate nil))
     Package:SI

     GCL specific: Sets the maximum number of pages for contiguous
     blocks to NUMBER.  If REALLY-ALLOCATE is non-NIL, then the
     specified number of pages will be allocated immediately.

-- Function: MAXIMUM-ALLOCATABLE-PAGES (type)
     Package:SI

     GCL specific: Returns the current maximum number of pages for the
     type class of the GCL implementation type TYPE.

-- Function: ALLOCATED-RELOCATABLE-PAGES ()
     Package:SI

     GCL specific: Returns the number of pages currently allocated for
     relocatable blocks.

-- Function: MAXIMUM-CONTIGUOUS-PAGES ()
     Package:SI

     GCL specific: Returns the current maximum number of pages for
     contiguous blocks.


-- Function: GET-HOLE-SIZE ()
     Package:SI

     GCL specific: Returns as a fixnum the size of the memory hole (in
     pages).

-- Function: SET-HOLE-SIZE (fixnum)
     Package:SI

     GCL specific: Sets the size of the memory hole (in pages).

-- Funcition: ALLOCATED (type)
     Package:SI

     Returns 6 values:
    nfree
          number free

    npages
          number of pages

    maxpage
          number of pages to grow to

    nppage
          number per page

    gbccount
          number of gc's due to running out of items of this size

    nused
          number of items used

     Note that all items of the same size are stored on similar pages.
     Thus for example on a 486 under linux the following basic types are
     all the same size and so will share the same allocated information:
     CONS BIGNUM RATIO COMPLEX STRUCTURE.

-- Variable: *LISP-MAXPAGES*
     Package:SI GCL specific: Holds the maximum number of pages (1 page
     = 2048 bytes) for the GCL process.  The result of changing the
     value of SI:*LISP-MAXPAGES* is unpredictable.

-- Variable: *MULTIPLY-STACKS*
     Package:SI

     If this variable is set to a positive fixnum, then the next time
     through the TOP-LEVEL loop, the loop will be exited.  The size of
     the stacks will be multiplied by the value of *multiply-stacks*,
     and the TOP-LEVEL will be called again.  Thus to double the size
     of the stacks:

     >(setq si::*multiply-stacks* 2) [exits top level and reinvokes it,
     with the new stacks in place] >

     We must exit TOP-LEVEL, because it and any other lisp functions
     maintain many pointers into the stacks, which would be incorrect
     when the stacks have been moved.    Interrupting the process of
     growing the stacks, can leave you in an inconsistent state.


-- Function: ALLOCATE-GROWTH (type min max percent percent-free)
     Package:SI

     The next time after a garbage collection for TYPE, if PERCENT-FREE
     of the objects of this TYPE are not actually free, and if the
     maximum number of pages for this type has already been allocated,
     then the maximum number will be increased by PERCENT of the old
     maximum, subject to the condition that this increment be at least
     MIN pages and at most MAX pages.  A list of the previous values
     for min, max, percent, and percent-free for the type TYPE is
     returned.   A value of 0 means use the system default,  and if an
     argument is out of range then the current values are returned with
     no change made.

     Examples: (si::allocate-growth 'cons 1 10 50 10) would insist that
     after a garbage collection for cons, there be at least 10% cons's
     free.   If not the number of cons pages would be grown by 50% or
     10 pages which ever was smaller.   This might be reasonable if you
     were trying to build an image which was `full', ie had few free
     objects of this type.

     (si::allocate-growth 'fixnum 0 10000 30 40) would grow space till
     there were normally 40% free fixnums, usually growing by 30% per
     time.

     (si::allocate-growth 'cons 0 0 0 40) would require 40% free conses
     after garbage collection for conses, and would use system defaults
     for the the rate to grow towards this goal.

     (si::allocate-growth 'cons -1 0 0 0) would return the current
     values, but not make any changes.


> I have 2GB RAM. Is it possible to 
> >allocate
> >the max to Axiom (under Windows XP)?
> >
> Let me add that on my system, the XP OS normally used 
> about under 800 MB with multiple programs open. When Axiom 
> started the CPU monitor shows 770MB and when the command 
> psolve(amat) started, the memory usage rose all the way to 
> about 1.20 GB and then quit. So there is plenty of 
> physical RAM left (not to mention virtual RAM). I repeated 
> this and Axiom aborted with:
> 
>     >> System error:
>     The storage for CONS is exhausted.
> Currently, 97956 pages are allocated.
> Use ALLOCATE to expand the space.
> 
> protected-symbol-warn called with (NIL)
> 
> William
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 






reply via email to

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