ory.
OK. It sounds like it already works, just needs a large rpython_reserve.
Again, pick a large number, show it works, optimize later?
-Roger
From: Armin Rigo
To: Roger Flores
Cc: "[email protected]"
Sent: Wednesday, August 8, 2012 1:
Hi Eli, hi Roger,
Both of your solutions might work.
Roger, you overlook a problem in this pseudo-code:
> print 'MemoryError'
> print stack_trace() # of app
We can't suddenly print the stack trace of the application from inside
the GC. In order to have a regular stack t
On Tue, Aug 7, 2012 at 6:33 AM, Armin Rigo wrote:
> If you can come up with a more precise scheme, you're welcome. The
> issue is to know when it's ok to reserve from that pool and when we
> should raise an RPython MemoryError instead. A possible answer would
I'm not convinced this MemoryErr
On Tue, Aug 7, 2012 at 6:33 AM, Armin Rigo wrote:
> If you can come up with a more precise scheme, you're welcome. The
> issue is to know when it's ok to reserve from that pool and when we
> should raise an RPython MemoryError instead. A possible answer would
> look like "when allocating interna
Hi Ronny,
On Tue, Aug 7, 2012 at 1:56 PM, Ronny Pfannschmidt
wrote:
> However in some cases (like the example) the memory error is caused by
> accumulating more and more smaller objects,
> in which case the memory one would use for a Stack-trace is used up and the
> extra pool would be used.
I'm
Hi Armin, Harald,
On 08/07/2012 11:28 AM, Armin Rigo wrote:
Hi Harald,
On Tue, Aug 7, 2012 at 10:23 AM, Massa, Harald Armin wrote:
outside of programming there is the concept of having a secret backup
("nest egg"). Would'nt it be a solution to preallocate some bytes on
startup for really, rea
Hi Harald,
On Tue, Aug 7, 2012 at 10:23 AM, Massa, Harald Armin wrote:
> outside of programming there is the concept of having a secret backup
> ("nest egg"). Would'nt it be a solution to preallocate some bytes on
> startup for really, really bad times?
It might help in general, but not in this
Tuesday 07 August 2012 you wrote:
> Re-hi,
>
> I tried to debug it more precisely, and it seems that the problem is
> even more basic than I thought. It is very hard to solve in general.
> The issue is that when we are really out of memory, then *every*
> single allocation is going to fail. The
> What occurs then in PyPy is that when we are out of memory, we can
> really not allocate any single object at more.
outside of programming there is the concept of having a secret backup
("nest egg"). Would'nt it be a solution to preallocate some bytes on
startup for really, really bad times?
As
Re-hi,
I tried to debug it more precisely, and it seems that the problem is
even more basic than I thought. It is very hard to solve in general.
The issue is that when we are really out of memory, then *every*
single allocation is going to fail. The difference with CPython is
that in the same si
Hi Roger,
On Tue, Aug 7, 2012 at 7:41 AM, Roger Flores wrote:
> Can someone else at least confirm this?
Yes, I can reproduce it easily running in a 32-bit chroot on a machine
with more than 4GB of RAM.
The problem is the same, and is still not solved: we run out of memory
when doing a minor cyc
I'm still getting MemoryError exceptions in RPython, as I mentioned a few
months back. I only knew of one way to reproduce it back then, but now I'm
seeing different ways. So, inspired, I wrote a short program to quickly
exhaust memory in the hopes of reproducing the problem. It seems to work
12 matches
Mail list logo
