I am trying to do something that involves reading in a large amount of
data using Franz Allegro Common Lisp 8.0, and it keeps dying with the
following error: what should I tweak to make it work? Might using a
different lisp solve my problem? [Offtopic, but is there an equivalent
of Allegrocache for any of the other lisps? Allegrocache offers
serialization plus fast indexing].
An allocation request for 4112 bytes caused tenuring and a need for
62128128 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 of type storage-condition]
Thanks.
From: Pascal Bourguignon
Subject: Re: Allocation request for x bytes caused tenuring and need for y more bytes of heap
Date:
Message-ID: <87hcygn6ev.fsf@thalassa.informatimago.com>
"remixer" <········@gmail.com> writes:
> I am trying to do something that involves reading in a large amount of
> data using Franz Allegro Common Lisp 8.0, and it keeps dying with the
> following error: what should I tweak to make it work? Might using a
> different lisp solve my problem? [Offtopic, but is there an equivalent
> of Allegrocache for any of the other lisps? Allegrocache offers
> serialization plus fast indexing].
>
> An allocation request for 4112 bytes caused tenuring and a need for
>
> 62128128 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 of type storage-condition]
It doesn't seem to be the fault of Allegro CL, does it?
You'd probably have the same problem with any other implementation.
man ulimit
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Pascal Bourguignon wrote:
> "remixer" <········@gmail.com> writes:
>
> > I am trying to do something that involves reading in a large amount of
> > data using Franz Allegro Common Lisp 8.0, and it keeps dying with the
> > following error: what should I tweak to make it work? Might using a
> > different lisp solve my problem? [Offtopic, but is there an equivalent
> > of Allegrocache for any of the other lisps? Allegrocache offers
> > serialization plus fast indexing].
> >
> > An allocation request for 4112 bytes caused tenuring and a need for
> > 62128128 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 of type storage-condition]
>
> It doesn't seem to be the fault of Allegro CL, does it?
> You'd probably have the same problem with any other implementation.
>
> man ulimit
Thanks. Is it the stack size? What should I change here?
[·······@node] ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
From: Pascal Bourguignon
Subject: Re: Allocation request for x bytes caused tenuring and need for y more bytes of heap
Date:
Message-ID: <87ac48n1m0.fsf@thalassa.informatimago.com>
"remixer" <········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> "remixer" <········@gmail.com> writes:
>>
>> > I am trying to do something that involves reading in a large amount of
>> > data using Franz Allegro Common Lisp 8.0, and it keeps dying with the
>> > following error: what should I tweak to make it work? Might using a
>> > different lisp solve my problem? [Offtopic, but is there an equivalent
>> > of Allegrocache for any of the other lisps? Allegrocache offers
>> > serialization plus fast indexing].
>> >
>> > An allocation request for 4112 bytes caused tenuring and a need for
>> > 62128128 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 of type storage-condition]
>>
>> It doesn't seem to be the fault of Allegro CL, does it?
>> You'd probably have the same problem with any other implementation.
>>
>> man ulimit
>
> Thanks. Is it the stack size? What should I change here?
>
> [·······@node] ulimit -a
> core file size (blocks, -c) 0
> data seg size (kbytes, -d) unlimited
> file size (blocks, -f) unlimited
> max locked memory (kbytes, -l) unlimited
> max memory size (kbytes, -m) unlimited
> open files (-n) 1024
> pipe size (512 bytes, -p) 8
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) 7168
> virtual memory (kbytes, -v) unlimited
Well, it seems it's not the max memory size, since it's unlimited.
Then it might be what the error message says, that your OS has too
little swap allocated and cannot allocate more dynamically.
Or if you're unlucky, the third option, that some memory is mapped in
an inconvenient place.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
From: Alex Mizrahi
Subject: Re: Allocation request for x bytes caused tenuring and need for y more bytes of heap
Date:
Message-ID: <4527d04e$0$49208$14726298@news.sunsite.dk>
(message (Hello 'remixer)
(you :wrote :on '(6 Oct 2006 20:12:43 -0700))
(
r> An allocation request for 4112 bytes caused tenuring and a need for
r> 62128128 more bytes of heap. The operating system will not make the
r> space available because of a lack of swap space or some other operating
r> system imposed limit or memory mapping collision.
r> [Condition of type storage-condition]
looks like it's out of address space (if phys memory + swap is enough), for
example because of address space fragmentation. can you get 64-bit machine
with 64-bit OS and run 64-bit lisp?
if you want to use 32-bit machine/os/lisp, or don't have enough mem, i think
it's possible to optimize, but you'd better say what do you have and what
pieces do you want to allocate. for example, if you allocate large arrays
(kinda 100MB each or more), don't do that, split them into some 25 MB pieces
or so (otherwise they may fail to allocate because of fragmentation). OTOH,
if you are using lots of small objects, it would be much better if you put
them into big arrays (however, not too big).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Allocation request for x bytes caused tenuring and need for y more bytes of heap
Date:
Message-ID: <87slhznfdg.fsf@qrnik.zagroda>
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> r> An allocation request for 4112 bytes caused tenuring and a need for
> r> 62128128 more bytes of heap.
> looks like it's out of address space (if phys memory + swap is enough),
> for example because of address space fragmentation.
Each process has its own address space. It should be extermely
unlikely that the memory of a Lisp process is so fragmented that
it can't get 64MB from the OS despite free memory & swap.
Perhaps it's a free edition with an artificial heap size limit;
http://www.franz.com/downloads/ says 50MB.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Alex Mizrahi
Subject: Re: Allocation request for x bytes caused tenuring and need for y more bytes of heap
Date:
Message-ID: <45291f07$0$49197$14726298@news.sunsite.dk>
(message (Hello 'Marcin)
(you :wrote :on '(Sun, 08 Oct 2006 14:47:39 +0200))
(
MQK> Each process has its own address space. It should be extermely
MQK> unlikely that the memory of a Lisp process is so fragmented that
MQK> it can't get 64MB from the OS despite free memory & swap.
hmm, it doesn't say how much have it alredy allocated, it says "and a need
for 62128128 more bytes of heap", so i guess it means it was not able to
allocate NEXT 64 MB, or something like this.
MQK> Perhaps it's a free edition with an artificial heap size limit;
MQK> http://www.franz.com/downloads/ says 50MB.
maybe, but as i remember it explicitly says that it's free edition's
limitation in this case.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")