Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Allocation Problems

14 views
Skip to first unread message

Chris Stolpe

unread,
Oct 14, 1997, 3:00:00 AM10/14/97
to

I'm using Franz Lisp's ACL 4.3 for linux and when I try to allocate a
large
array I get the following error:

USER(3): (setf image (make-array '(3000 3000) :initial-element 0))
Error: An allocation request for 64000016 bytes caused a need for
170983424 more bytes of heap. The operating system will not make the
space available because of a lack of swap space or some other operating
system imposed limit or memory mapping collision.
[condition type: STORAGE-CONDITION]

USER(5): (setf image (make-array '(3000 3000) :initial-element 0))
Error: An allocation request for 36000016 bytes caused a need for
96534528 more bytes of heap. The operating system will not make the
space available because of a lack of swap space or some other operating
system imposed limit or memory mapping collision.
[condition type: STORAGE-CONDITION]

I only have 24M of ram and 64M of swap so I would expect it to fail if
it
tried to allocate 64M of memory. What I don't understand is why I'm
getting
different allocation request amounts for the same array or why a request
for
64000016 bytes would cause a need for 170983234 bytes of heap.
Is there a way to determine the amount of space a variable is
consuming?
How about a way to free allocated memory? After the first attempt the cl
image
grew to 64M and didn't shrink when I set image to nil.

Thanks
Chris Stolpe
cst...@acm.org

Erik Naggum

unread,
Oct 14, 1997, 3:00:00 AM10/14/97
to

* Chris Stolpe

| I only have 24M of ram and 64M of swap so I would expect it to fail if it
| tried to allocate 64M of memory. What I don't understand is why I'm
| getting different allocation request amounts for the same array or why a
| request for 64000016 bytes would cause a need for 170983234 bytes of
| heap.

Allegro CL uses a generational, copying garbage collector. this is fast
and convenient, but uses twice the memory required by new objects. here's
the output from `(room)' at startup in my somewhat tweaked Lisp image:

area address(bytes) cons symbols other bytes
8 bytes each 24 bytes each
(free:used) (free:used) (free:used)
Top #x596000
New #x52e000(425984) 180:4915 252:2 228384:97032
New #x4c6000(425984) ----- ----- -----
Old #x102f50(3944624) 813:160189 218:21817 872:2110616
Root pages: 46
4608 (#x1200) bytes used for loading foreign functions
Reserved foreign function space at #x82000:
262144 bytes allocated, 4608 bytes used (257536 bytes free)

the "new" space is occupied by objects that were allocated more recently
than the tenure-limit, which is measured in the number of gc's. the "old"
space is occupied by tenured objects. old space is not gc'ed as often as
new space. (it is called a "global gc" if old space is included.)

because the garbage collector is copying between two spaces, only one of
the newspaces is in use at any given time. this means that you can't
allocate very large objects in newspace, and it is usually a bad idea,
anyway, if you know they're going to hang around for a while. Allegro
offers the ability to communicate your intent to the allocator:

(make-array '(3000 3000) :element-type '(unsigned-byte 8)
:initial-element 0
#+allegro :allocation #+allegro :old)

the `element-type' argument can take any of a number of useful values to
request specialized array and therefore smaller allocated objects:

bit
character
fixnum
single-float
double-float
(unsigned-byte 8)
(unsigned-byte 16)
(unsigned-byte 32)
(signed-byte 8)
(signed-byte 16)
(signed-byte 32)
(complex single-float)
(complex double-float)

the above call to make-array consumes just over 9 million bytes of memory,
assuming that 8 bits per pixel is enough.

| Is there a way to determine the amount of space a variable is consuming?

er, "variable" is not quite what you think it is. a _symbol_ takes up a
constant 24 bytes, as you can see from the above output from (room), but
the _values_ of the various slots take up more space. there is no way (I
know of) to ask for the size of Lisp objects that don't have constant size,
but evaluate (room t) and learn more.

| How about a way to free allocated memory? After the first attempt the cl
| image grew to 64M and didn't shrink when I set image to nil.

this is actually covered quite well in the User Guide, Chapter 15. the
function sys:resize-areas is very good at reducing the size of the Lisp
process once you have unintentionally blown away your system memory.

#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".

see http://www.naggum.no/emacs/ for Emacs-20-related material.

Pierpaolo Bernardi

unread,
Oct 14, 1997, 3:00:00 AM10/14/97
to

Chris Stolpe (cst...@us.ibm.net) wrote:
: I'm using Franz Lisp's ACL 4.3 for linux and when I try to allocate a

: large
: array I get the following error:

: USER(3): (setf image (make-array '(3000 3000) :initial-element 0))
: Error: An allocation request for 64000016 bytes caused a need for
: 170983424 more bytes of heap. The operating system will not make the
: space available because of a lack of swap space or some other operating
: system imposed limit or memory mapping collision.
: [condition type: STORAGE-CONDITION]

[...]
: tried to allocate 64M of memory. What I don't understand is why I'm


: getting
: different allocation request amounts for the same array or why a request
: for
: 64000016 bytes would cause a need for 170983234 bytes of heap.

You are not requesting bytes, but general objects.

try:

(make-array '(3000 3000) :element-type '(mod 256) :initial-element 0)
^^^^^^^^^^^^^^^^^^^^^^^^

Pierpaolo.

: Thanks
: Chris Stolpe
: cst...@acm.org

Bruno Haible

unread,
Oct 16, 1997, 3:00:00 AM10/16/97
to

Erik Naggum <cle...@naggum.no> wrote about ACL 4.3 for Linux:

> Allegro CL uses a generational, copying garbage collector. this is fast
> and convenient, but uses twice the memory required by new objects.

A generational garbage collector which doesn't use twice the memory
required by new objects would be even more convenient. Like clisp's one.

> the function sys:resize-areas is very good at reducing the size of the Lisp
> process once you have unintentionally blown away your system memory.

Why is there a need for this function at all?

Bruno

Erik Naggum

unread,
Oct 17, 1997, 3:00:00 AM10/17/97
to

* Bruno Haible

| Why is there a need for this function at all?

because the alternative is to constantly badger the operating system about
allocating and deallocating memory.

Bruno Haible

unread,
Oct 20, 1997, 3:00:00 AM10/20/97
to

Erik Naggum <#\er...@naggum.no> wrote:

> because the alternative is to constantly badger the operating system about
> allocating and deallocating memory.

In a multitasking environment, it is the OS who grants memory to the
programs, and the programs should allocate only (roughly) as much space
as they need and give back to the OS large pieces of unused memory, so
that other programs are not unduly hampered. (I'm talking about pieces
of 4KB or 64KB. The previous poster was allocating a 64 MB array.)

And the memory management would ideally be automatic, with no need for
a programmer's intervention.

Bruno


0 new messages