[Glass] Error: VM temporary object memory is full

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 <[hidden email]> 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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Thu, Nov 27, 2014 at 12:20 PM, Dario Trussardi via Glass <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Thu, Nov 27, 2014 at 1:23 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> wrote:

On Thu, Nov 27, 2014 at 12:20 PM, Dario Trussardi via Glass <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

Mariano,

There's a persistent root for writing as well. See Object>>sixxOn:persistentRoot: (same idea)...

Dale

On Thu, Nov 27, 2014 at 10:20 AM, Mariano Martinez Peck <[hidden email]> wrote:

On Thu, Nov 27, 2014 at 1:23 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> wrote:

On Thu, Nov 27, 2014 at 12:20 PM, Dario Trussardi via Glass <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com