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

[Dale Henrichs via Glass]

Well,

In 2.4.x, this primitive returned an Array of Associations ... class and 
instance count .. somewhere along the line this obviously changed ---- 
the danger of using _ methods ... I assume that this also means that the 
condition that was being tested for has never been hit either :)

I haven't worked my way up the GemStone version chain to find out when 
the behavior actually changed, but #_* methods are not documented by 
definition and also cannot be depended upon to even exist from version 
to version ... but sometimes the #_ method is the only way to get a bit 
of interesting information:)

I've submitted an issue for this and I will check into what might have 
happened ... getting back objects was the intent and happens to be quite 
useful so I want to find out if that capability is still present in a 
different form.

Dale

[1] https://github.com/GsDevKit/GsDevKit/issues/90


On 03/07/2016 12:11 PM, Mariano Martinez Peck 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 <mailto:marianopeck at gmail.com>> 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
>
>         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
>>
>>
>>         _______________________________________________
>>         Glass mailing list
>>         Glass at lists.gemtalksystems.com
>>         <mailto:Glass at lists.gemtalksystems.com>
>>         http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>         _______________________________________________
>         Glass mailing list
>         Glass at lists.gemtalksystems.com
>         <mailto:Glass at lists.gemtalksystems.com>
>         http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
>     -- 
>     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/16c69247/attachment.html>