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

[Mariano Martinez Peck via Glass]

Hi guys,

First of all, thanks to Richard for the suggestion. Adding the env var did
write the useful info in the gem log.

Problem is that even if I tried to fix it (in my code), I still failed :(
 I attach the whole log in case someone wants to take a look.

However, I think there is something strange in
#installAlmostOutOfMemoryStaticHandler:. I added some logging to this
method to see what was going on (in bold the important parts):


*installAlmostOutOfMemoryStaticHandler: initialCommitThreshold*
*  | handler commitThreshold used |*
*  commitThreshold := initialCommitThreshold.*
*  handler := AlmostOutOfMemory*
*    addDefaultHandler: [ :ex | *
*      "Exception caught, do a commit."*
*      Transcript*
*        show: 'exception handled: ' , ex printString;*
*        cr.*
*      System commitTransaction*
*        ifFalse: [ *
*          Transcript*
*            show: 'AutoCommit failed';*
*            cr.*
*          nil error: 'AutoCommit failed' ].*
*      System _vmMarkSweep.*
*      Transcript*
*        show: 'commit threshold value: ' , commitThreshold printString;*
*        cr.*
*      used := System _tempObjSpacePercentUsedLastMark.*
*      Transcript*
*        show: 'percent used ' , used printString;*
*        cr.*
*      used < commitThreshold*
*        ifTrue: [ *
*          "We dropped below the threshold, reenable the signal"*
*          Transcript*
*            show: 're-enable the signal ';*
*            cr.*
*          System enableAlmostOutOfMemoryError ]*
*        ifFalse: [ *
*          "commit and mark sweep did drop us below threshold. cut
threshold in half *
*           and try again. Record an entry in the object log "*
*          commitThreshold := (100 - commitThreshold) // 2 +
commitThreshold.*
*          Transcript*
*            show: 'commit threshold value: ' , commitThreshold
printString;*
*            cr.*
*          commitThreshold < 98*
*            ifTrue: [ *
*              Transcript*
*                show: 'signalAlmostOutOfMemoryThreshold: ';*
*                cr.*
*              System signalAlmostOutOfMemoryThreshold: commitThreshold ]*
*            ifFalse: [ *
*              "we're with 10% of out of memory, commit instance counts
structure *
*               into objectlog for posterity."*
*              Transcript*
*                show: '10% out of memory... record in the object log ';*
*                cr.*
*              (ObjectLogEntry*
*                trace: 'almost out of memory: ' , commitThreshold
printString*
*                object: (System _vmInstanceCountsReport: 3)) addToLog.*
*              System commitTransaction*
*                ifFalse: [ *
*                  Transcript*
*                    show: 'Last AutoCommit failed ';*
*                    cr.*
*                  nil error: 'AutoCommit failed' ] ] ].*
*      ex resume ].*
*  SessionTemps current*
*    at: #'CommitOnAlmostOutOfMemoryStaticException'*
*    put: handler.*
*  System signalAlmostOutOfMemoryThreshold: commitThreshold*



Now...if I check the gem log, I get this:

*--transcript--'exception handled: a AlmostOutOfMemory occurred
(notification 6013), Session''s temporary object memory is almost full'*
*--transcript--'commit threshold value: 10'*
*--transcript--'percent used 0'*
*--transcript--'re-enable the signal '*

And that 4 lines repeated several times, until it starts with the:


************ Fatal error 4067 OutOfMemory ******

*Printing Smalltalk stack because of OutOfMemory:*
*Smalltalk stack: printing to topaz .out file at [03/08/2016 12:36:11.827
EST]*



And this is what I don't understand...from the transcript, it seems
that "*System
_tempObjSpacePercentUsedLastMark" *always answered 0, hence we are below
threshold (no problem!). But then I get the OutOfMemory anyway...  so...
how can I run out of memory if #_tempObjSpacePercentUsedLastMark answered 0
each time?


Thanks in advance,



On Mon, Mar 7, 2016 at 7:07 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> 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>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 ...
>
> Dale
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160308/d1f0c98f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outOfMemory.log
Type: application/octet-stream
Size: 131833 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160308/d1f0c98f/attachment-0001.obj>