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

[Mariano Martinez Peck via Glass]

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

> In 3.3, instead of returning an Array of Associations, the report is
> written to the gem log ... you are using 3.2.9?
>
>
Yes, I am using 3.2.9.  But....I thought the guy that would write into the
gem log was #_vmPrintInstanceCounts:   , not #_vmInstanceCountsReport: (I
thought this one would simply answer the string)






> Dale
>
>
> On 03/07/2016 12:39 PM, Mariano Martinez Peck wrote:
>
> Also...I do not get the instance count written neither in object log
> (could be the bug I mentioned in previous email), nor in the gem file
> log...shouldn't I get that? At least I remember getting that once upon a
> time.
>
> Thanks!
>
> On Mon, Mar 7, 2016 at 5:11 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> BTW Dale.... I think the line of "System *_vmInstanceCounts:* 3"  in
>> #installAlmostOutOfMemoryStaticHandler: is wrong and instead it should
>> be (System *_vmInstanceCountsReport:* 3)  and it also will fail the
>>
>>   sort: [ :a :b | (a value at: 2) > (b value at: 2) ]
>>
>> Was this fixed somewhere after 3.2.9 ???
>>
>>
>> Cheers,
>>
>>
>>
>>
>> On Mon, Mar 7, 2016 at 4:57 PM, Mariano Martinez Peck <
>> <marianopeck at gmail.com>marianopeck at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Mar 7, 2016 at 3:18 PM, Dale Henrichs via Glass <
>>> 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
>>>
>>>
>>>> It is also possible that your temp obj cache is filling with objects
>>>> that have not yet been connected to the persistent root ...
>>>>
>>>>
>>> mmm OK  I will check this. But now I get this same error in another cron
>>> job. Both were running correctly a few weeks/months ago.
>>>
>>>
>>>> If you want to see what's happening with respect to the exceptions that
>>>> are being signaleed, you could add logging to MCPlatformSupport
>>>> class>>installAlmostOutOfMemoryStaticHandler: ...
>>>>
>>>>
>>> mmmm I am a bit lost there. Which kind of log could I add?
>>>
>>> Thanks in advance,
>>>
>>>
>>>
>>>
>>>
>>>> Dale
>>>>
>>>>
>>>>
>>>> On 03/07/2016 08:35 AM, Mariano Martinez Peck via Glass wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> I am running some code that processes a huge csv file and inserts
>>>> persistent data to gemstone. This is a GemStone 3.2.9 with 1GB of SPC,
>>>> GEM_TEMPOBJ_CACHE_SIZE of 700MB and GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE  at
>>>> 100.
>>>>
>>>> What is funny is that my code runs inside commitOnAlmost...
>>>>
>>>> I have this method:
>>>>
>>>> FAGemStoneCompatibility >> commitOnAlmostOutOfMemoryDuring: aBlock
>>>> threshold: aThreshold
>>>>   [
>>>>   MCPlatformSupport installAlmostOutOfMemoryStaticHandler: aThreshold.
>>>>   aBlock value ]
>>>>     ensure: [ MCPlatformSupport uninstallAlmostOutOfMemoryStaticHandler
>>>> ]
>>>>
>>>> And this is how I use it:
>>>>
>>>>                System commitTransaction.
>>>> FACompatibilityUtils current
>>>> commitOnAlmostOutOfMemoryDuring: [
>>>>     *WhateverClass whateverThingThatNeedsMemory.*
>>>>                         ]
>>>>                         threshold: 10.
>>>> System commitTransaction.
>>>>
>>>>
>>>> And even with a threshold of 10...  I am getting a
>>>>
>>>> *VM temporary object memory is full *
>>>> *, too many failed pom_gen scavenges*
>>>>
>>>>
>>>> Any idea what could be going on?
>>>>
>>>> Thanks in advance,
>>>>
>>>> --
>>>> Mariano
>>>> <http://marianopeck.wordpress.com>http://marianopeck.wordpress.com
>>>>
>>>>
>>>> _______________________________________________
>>>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160307/39f6f961/attachment.html>