[Glass] OutOfMemoryError ...

As I posted before - I often get this error if I file-in a large source
code from a Jade Workspace and I get this error message (and perhaps
this is an error message due to Dolphin  and not due to Gemstone VM ?)?

I do get this error, even if I clode my Jade main window and "Login" again.

I do NOT get this error, if I do this large file-in as a first working
step after starting Jade and Login.

Marten

 The ouput below is printing in a dark window ...

an OutOfMemoryError('Für diesen Vorgang ist nicht genügend Speicher
verfügbar. (16rE: Für diesen Vorgang ist nicht genügend Speicher
verfügbar.)')

ProcessorScheduler>>noMemory:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
SmallInteger(Object)>>doesNotUnderstand:
SmallInteger(Behavior)>>new:max:
Process class>>new
Process class>>forContext:priority:
BlockClosure>>newProcess
BlockClosure>>fork
GciSession>>withExplanation:doA:
GciSession>>withExplanation:do:
GciSession>>executeString:fromContext:
GciSession>>executeString:
[] in
JadeTranscript(JadeTextDocument)>>defineMethod:inClassNamed:inPackageNamed:inCategory:
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:


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

Hi,

Check out GEM_TEMPOBJ_CACHE_SIZE.

It is possible that you are running out of temp space.

I do not think is a Dolphin problem because the Dolphin does not process anything. All in sent to the server.

For example if you ran a SQL query which return a lot of rows (in Mbytes) and your GEM_TEMPOBJ_CACHE_SIZE is small then you will have this error.

The default value is 10000 (10 MB).

Regards,
bruno

PS: from GemStone manual:
To Tune the Temporary Object Space
You should increase GEM_TEMPOBJ_CACHE_SIZE (page 369) for applications
that create a large number of temporary objects — for example, applications that
make heavy use of the reduced conflict classes or sessions performing a bulk load.
It is important to provide sufficient temporary object space. If temporary object
memory is exhausted, the Gem can encounter an out-of-memory condition and
terminate. This is particularly likely to be a problem if there are long transactions
that modify a large number of objects.
You will probably need to experiment somewhat before you determine the
optimum size of the temporary object space for the application. The default of
10000 (10 MB) should be adequate for normal user sessions. For sessions that place
a high demand on the temporary object cache, such as upgrade, you may wish to
use 100000 (i.e., 100 MB). Any increase in GEM_TEMPOBJ_CACHE_SIZE
translates directly into increased memory usage per user.
Memory management is discussed in greater detail in Chapter 10, “Managing
Memory”, on page 295.

On 03/25/2014 03:41 AM, [hidden email] wrote:
> As I posted before - I often get this error if I file-in a large source
> code from a Jade Workspace and I get this error message (and perhaps
> this is an error message due to Dolphin  and not due to Gemstone VM ?)?
>

From the stack, it does look like it's Dolphin that's running out of
memory, not the gem. I'm afraid I don't use Dolphin or Jade (or Windows,
which explains the other two) so I can't be much help beyond that.

Regards,

-Martin

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

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

It happens both in the Development IDE and in the standalone tool.

Memory use is very low - 53 to 75 MByte RAM.  The system has 16GByte and
it's Windows 7/64.

Marten


Am 25.03.2014 19:32, schrieb James Foster: _______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Okay. I think I have some ideas.

When you do a file-in, we do some analysis on the client (in Jade) and then for each Topaz command we do at least one server round-trip. (Obviously, this isn’t very efficient, but its been working okay so far.) With each server round-trip we fork a background process to talk to the server while we manage the client UI in the foreground. Because the walkback happens in that place I investigated the possibility that lots of forks can cause a problem. It turns out that the following code can reproduce the problem pretty consistently, and uncommenting the MemoryManager lines can fix it. If you run the code and then look at the stack you can see the Dolphin stack corruption that occurs at the Process class>>#’new’ call. (The stack makes it look like an instance of SmallInteger is the receiver when Process class>>#’new’ sends a message to ‘self’.)

"MemoryManager current collectGarbage; compact."
1 to: 10000 do: [:i |
    | semaphore |
    semaphore := Semaphore new.
    [
        (Delay forMilliseconds: 1) wait.
        semaphore signal.
    ] fork.
    semaphore wait.
    "i \\ 1000 == 0 ifTrue: [MemoryManager current collectGarbage; compact]."
].

I’ve added some code to do a full GC after each thousand server calls. Version 1.037 of Jade has this change. Let me know if that improves things!

James


On Mar 25, 2014, at 12:10 PM, [hidden email] wrote:

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

Seems to be fixed ! Upload takes now longer, but that is ok.

Well done,

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