[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query on stacktrace management logic
From: |
Chris Gray |
Subject: |
Re: Query on stacktrace management logic |
Date: |
Tue, 2 Mar 2004 10:52:17 +0100 |
On Monday 01 March 2004 23:38, David Holmes wrote:
> Chris Gray wrote:
> > I found one gotcha with using a pre-allocated OutOfMemoryError :
> > if several threads throw OOME at the same time, the stack traces
> > can get mixed up.
>
> This is one of our issues too. With no stacktrace you can share an OOME
> instance with no problem and require no runtime allocation. With a
> stacktrace you need at least a per-thread OOME and pre-allocated stacktrace
> space. As it stands our OOME does have a stacktrace but its created at
> system startup when running out of memory is not an issue - but of course
> the stacktrace is meaningless for any actual circumstance where the OOME is
> thrown.
>
> We encounter OOME much more often than others might because we are dealing
> with RTSJ scoped memory areas - which introduces some added twists to
> things. :)
On the bright side, it does make it more likely that the OOM problem will be
confined to one thread.
One OOME per thread, allocated at thread creation time, should be safe.
Ensuring that one can always find memory "somewhere" to store a stack trace
is left as an exercise for the reader (and the answer is likely to be
VM-specific).
Chris
--
Chris Gray /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi http://www.kiffer.be/k/
address@hidden +32 3 216 0369