[Glass] Error: VM temporary object memory is full

Thu Nov 27 10:20:20 PST 2014

On Thu, Nov 27, 2014 at 1:23 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Dario,
>
> Have you tried:
>
>   | obj |
>   MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     UserGlobals at: #'MY_SIXX_ROOT_ARRAY' put: Array new).
>     System commitTransaction.
>     obj := Object readSixxFrom: xmlStringOrStream
>       context: SixxContext forRead
>       persistentRoot: (UserGlobals at: #'MY_SIXX_ROOT_ARRAY')
>   ].
>
> I had thought that this was fairly common knowledge, but when I poked
> around in Google, I couldn't find any announcement of this technique (I did
> find references to it several years back, but I expected an announcement)
> ...
>
> If this doesn't work we should get a GemStone stack and try to improve the
> persistent root usage...
>
> I will update the README for the SIXX project if this works for you...
>
>
Thanks Dale. Very nice idea. The other day I think my gems were crashing
when I was exporting sixx...and I already have 1.9 gb as temp space
there...so if I can reproduce that, I will try idea. Thanks.

> Dale
>
> On Thu, Nov 27, 2014 at 8:54 AM, Mariano Martinez Peck via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>>
>>
>> On Thu, Nov 27, 2014 at 12:20 PM, Dario Trussardi via Glass <
>> glass at lists.gemtalksystems.com> wrote:
>>
>>> Ciao,
>>>
>>>
>>> You must increase your temp object space. My recommendation is to do
>>> that only for the gemtools or revert after import. But don't let a huge
>>> temp space.
>>> I did have the same problems with SIXX. In fact, for sixx import I use
>>> 1.9GB temp space (SPC is 2GB).
>>>
>>> i need to update   system.conf    ?
>>>
>>>
>> Yes. Or..For the seaside gems it would be in the conf file passes to
>> seaside gems.
>>
>>
>>> with what parameters?
>>>
>>> # SHR_PAGE_CACHE_SIZE_KB should always be > GEM_TEMPOBJ_CACHE_SIZE
>>> SHR_PAGE_CACHE_SIZE_KB = 500000;
>>> GEM_TEMPOBJ_CACHE_SIZE = 50000;
>>>
>>
>> I always put the max as I can.
>>
>>
>>> SHR_PAGE_CACHE_SIZE_KB = 2000000;
>>> GEM_TEMPOBJ_CACHE_SIZE = 1900000;
>>>
>>
>> Be aware that if you also set those values in the gem.conf and this is
>> read, it might take those instead...
>>
>>
>>
>>
>>
>>>
>>> Thanks,
>>>
>>> Dario
>>>
>>> And...if you crash with 1.9GB...then you must look another alternative.
>>> Probably the xml pull parser may help here. But as far as I know there is
>>> not SIXX + xml pull parser working out of the box.
>>>
>>>
>>> On Thu, Nov 27, 2014 at 10:45 AM, James Foster via Glass <
>>> glass at lists.gemtalksystems.com> wrote:
>>>
>>>>
>>>> https://www.google.com/search?q=VM+temporary+object+memory+is+full+gemstone
>>>>
>>>> > On Nov 27, 2014, at 6:32 AM, Dario Trussardi via Glass <
>>>> glass at lists.gemtalksystems.com> wrote:
>>>> >
>>>> > Ciao,
>>>> >
>>>> >       i need to load data from sixx file  ( is size is 3MB ).
>>>> >
>>>> >       when i do the command   readSixxFrom:    the system erase the
>>>> error:
>>>> >
>>>> > Error: VM temporary object memory is full
>>>> >
>>>> > GsProcess>>openDebugger:
>>>> > GsRuntimeError>>defaultAction
>>>> > UndefinedObject>>handleSignal:
>>>> > GsRuntimeError(Exception)>>pass
>>>> > [] in PasteUpMorph>>becomeActiveDuring:
>>>> > BlockClosure>>valueWithPossibleArgs:
>>>> > [] in MethodContext(ContextPart)>>handleSignal:
>>>> > BlockClosure>>ensure:
>>>> > MethodContext(ContextPart)>>handleSignal:
>>>> > MethodContext(ContextPart)>>handleSignal:
>>>> > GsRuntimeError(Exception)>>signal
>>>> > GciSession>>getNbResult
>>>> > GciSession>>getNbResultAsOop
>>>> > [] in GciSession>>receiverNB:perform:withArguments:
>>>> > BlockClosure>>ensure:
>>>> > Cursor>>showWhile:
>>>> > GciSession>>receiverNB:perform:withArguments:
>>>> > GciSession>>receiver:perform:withArguments:
>>>> > GsJadeServer(GsObject)>>gsPerform:withArguments:
>>>> > [] in GsOBTextMorphEditorWithShout>>performOnServer:
>>>> >
>>>> >
>>>> >       How i can solve this problem ?
>>>> >
>>>> >       Thanks,
>>>> >
>>>> >               Dario
>>>> > _______________________________________________
>>>> > Glass mailing list
>>>> > Glass at lists.gemtalksystems.com
>>>> > http://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
>>>
>>>
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141127/1d396ff9/attachment-0001.html>