[Glass] Explanation to "too many failed pom_gen scavenges" in this context??

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Mon Mar 7 14:07:37 PST 2016

On 03/07/2016 11:57 AM, Mariano Martinez Peck wrote:
> On Mon, Mar 7, 2016 at 3:18 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>     Mariano,
>     The handler for AlmostOutOfMemory relies on being able to resume
>     after a successful commit, but a GemStone vm will sometimes cross
>     the threshol in the middle of a "random C code" called by a
>     primitive ... in these cases we have to defer the signalling of
>     AlmostOutOfMemory until we reach a point where we can safely
>     resume .... The implication is that depending upon the details of
>     your call it is possible to physically run out of memory before
>     the deferred signaling can take place ...
>     If you lower the threshold, you should be able to find a limit
>     that gives you room to finish the memory hungry primitive call and
>     get the deferred AlmostOfOfMemory exception signalled.
> Yes,*but I am already running the threshold with 10% with a 700MB temp 
> space*... how less than that should it be? mmmm

This implies that you are doing something that consumes quite a bit of 
memory while in  a primitive .... a stack trace would be helpful ... but 
it is likely that the only way to get a stack trace in this situation is 
to set the env vars as suggested by Richard ...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160307/04f18852/attachment.html>

More information about the Glass mailing list