Skip to main content

GameDemo stop running after receive two OutOfMemoryError exceptions.

10 replies [Last post]
sherikekele
Offline
Joined: 2010-05-06

Hi All,

Recently, I encounter a problem when running the GameDemo in persoanl basis profile. The program stop running after receive two continious OutOfMemoryError exceptions. Seems the first exception handling hasn't been finished yet, then recerive another OutOfMemoryError exception.

Can anybody help me about this issue? Thanks in advance.

Following is the log I get using DFB to implement the AWT. This problem also exists in QT.
-----------my debug-----------------
66666666666666666666
Java_java_awt_DFBGraphics_pCloneGraphPSD psd = 0, ========thread id = 0x9ad770
-----------my debug-----------------
66666666666666666666
-----------my debug-----------------
java.lang.OutOfMemoryError: Graphic Descriptors Pool exhausted
at java.awt.DFBGraphics.pCloneGraphPSD(IZ)I(Native Method)
at java.awt.DFBGraphics.(Ljava/awt/Window;)V(DFBGraphics.java:164)
at java.awt.DFBToolkit.getGraphics(Ljava/awt/Window;)Ljava/awt/Graphics;(DFBToolkit.java:51)
at java.awt.Component.getGraphics()Ljava/awt/Graphics;(Component.java:1415)
at basis.demos.GameDemo$Enemy.move()V(Compiled Method)(GameDemo.java:893)
at basis.demos.GameDemo$Animator.run()V(GameDemo.java:670)
at java.lang.Thread.startup(Z)V(Thread.java:785)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hi Davy & Hinkmond,
>
> I have referred to thread http://forums.java.net/jive/thread.jspa?messageID=319016. And made a comparison with my problem, concluded that my issue is a garbage collector issue. The test case metioned in the thread is no more available now. I don't have a test case yet.
>
> I changed the GC heap size from 2M to 512K, the dispose() function is called before the outofmemory exception was thrown out. At this condition the program works very well.
>
> I defined an array to store the graphics context in DFBGraphics.cpp, which is used when callling the getGraphics() fucntion. When this array is all used out, and calling getGraphics() again, the outofmemory execption will be thrown out. When the GC thread is trying to free all the occupied memories, another thread called getGraphics(), and throw an outofmemory exception again, which cause the program die.
>
> I want to know if there is a way for the GC to work around before outofmemroy execption is thrown out.
> Davy, you mentioned to use DeleteGlobalRef() when calling PPCGraphics.dispose(). Is this can help about my GC issue, or just to prevent memory leak?
>

Hi Sheri,

Glad to hear that Davy's suggestion from the cited thread helped!
(Thanks, Davy) Another thing to try when you want the old Graphics to
be disposed by a GC is to first make sure you have no remaining
references (object pointers) hanging on to the old Graphics objects,
then call System.gc() to request a GC by the VM. However, this is no
guarantee, it is only a suggestion to the VM to make its best effort to
reclaim some memory.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

sherikekele
Offline
Joined: 2010-05-06

Hi Hinkmond,

I called System.gc() when I found out the array is going to be exsauted, now the GameDemo won't die. But new problem came out, the "stop-the-world" time is too long, which makes the game un-continious.
Any suggestion about this issue?

Sheri

Hinkmond Wong

> I called System.gc() when I found out the array is going to be exsauted, now the GameDemo won't die. But new problem came out, the "stop-the-world" time is too long, which makes the game un-continious.
> Any suggestion about this issue?
>

Hi Sheri,

I'm thinking you are saying that the garbage collection seems to be
solving your problem now, but each time the GC happens it makes your
game pause. Is that correct?

If that's true, I would suggest that instead of creating new graphics
objects every time, try reusing one graphics object each time you need
to change the data.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

sherikekele
Offline
Joined: 2010-05-06

Hi Hinkmond,

Thanks for you suggestion. It's really not a good way to call getGraphics() in a for loop. Maybe I also could try to tune the CVM performance to shorten the "stop-the-wold" time.

Sheri

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Thanks for you suggestion. It's really not a good way to call getGraphics() in a for loop. Maybe I also could try to tune the CVM performance to shorten the "stop-the-world" time.
>

Hi Sheri,

Usually it's better to try to rewrite your app to avoid a lot of
temporary object creations that won't last the entire duration of your
app lifespan, rather than trying to tune the CVM's GC.

Chris might have some other suggestions for the CVM GC pause time you
are seeing, but I would suggest to first try minimizing your calls to
getGraphics() to be called only once or at most a couple times using a
variable or variables to cache the Graphics object(s).

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

sherikekele
Offline
Joined: 2010-05-06

Hi Hinkmond,

I got it. I will focus on my application.
Thank you very much.

Sheri

Hinkmond Wong

Hi sherikekele,

Do you have a small testcase that can reproduce this exact error
message, but without having to run the entire GameDemo? Just the stack
trace alone doesn't describe enough what is going on, but a smaller code
example of a testcase that can cause the same effect should be enough to
try to help.

It appears though, that the DFBGraphics.java file at line 164 is keeping
track of the Graphic Descriptors Pool and for some reason your testcase
(GameDemo) is calling java.awt.Component.getGraphics() too many times or
on maybe has has too many graphics objects. It will help if you can
post a small testcase still.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

davyp
Offline
Joined: 2007-01-03

This reminds of a memory leak I had a while ago with the PocketPC port. It turned out that the
native WinCE peers were allocating memory with each getGraphics() call and were not
releasing this memory. If I cached the result of getGraphics() and used that handle later on
in the loop that was causing the exception, the error went away.

Have a look at this thread:
http://forums.java.net/jive/thread.jspa?messageID=319016

There is a pointer to a simple test application that may help you identify what is going
wrong.

Davy

sherikekele
Offline
Joined: 2010-05-06

Hi Davy & Hinkmond,

I have referred to thread http://forums.java.net/jive/thread.jspa?messageID=319016. And made a comparison with my problem, concluded that my issue is a garbage collector issue. The test case metioned in the thread is no more available now. I don't have a test case yet.

I changed the GC heap size from 2M to 512K, the dispose() function is called before the outofmemory exception was thrown out. At this condition the program works very well.

I defined an array to store the graphics context in DFBGraphics.cpp, which is used when callling the getGraphics() fucntion. When this array is all used out, and calling getGraphics() again, the outofmemory execption will be thrown out. When the GC thread is trying to free all the occupied memories, another thread called getGraphics(), and throw an outofmemory exception again, which cause the program die.

I want to know if there is a way for the GC to work around before outofmemroy execption is thrown out.
Davy, you mentioned to use DeleteGlobalRef() when calling PPCGraphics.dispose(). Is this can help about my GC issue, or just to prevent memory leak?
Thanks.

Sheri

sherikekele
Offline
Joined: 2010-05-06

BTW, I'm using the personal basis profile. I checked the souce code, seems PBP & PP awt implementation differs a lot.