Jump to content
Excelsior Forums
Dirv

Garbage Collection and Out Of Memory

Recommended Posts

Application Context: JET 4.0 MP2

There seems to be a rather large difference in how garbage collection is done with the standard Sun JDK/JRE and Excelsior JET. I have an image processing application that I run that constantly processes image data. This is an application that is supposed to run 24/7 for possible weeks/months at a time. Utilizing the Sun JVM, I have run the application for large periods of time (>5 days) and never seen memory usage issues or growth. I've logged out the memory usage over that time period, so I have an extensive amount of usage data collected. When I compile the same code base with JET and run the application, before too long (~2 days) I get an "Out of Memory" error. I have experiemented extensively with the garbage collection parameters, etc. in JET, and setting the GC ratio to maximum (40%) seems to give the best performance. However the usage still seems to escalate with a code base that does not have the same behaviors when run with Sun JVM.

Would someone please explain to me the garbage collection algorithm used? How does it compare to the algorithms in the Sun JVM? Are other algorithms available as options/plugins?

-D

Share this post


Link to post
Share on other sites

Hello,

To understand what is the reason of the OutOfMemoryError, please, enable the properties

"jet.gc.verbose.out.of.memory" and "jet.gc.fatal.out.of.memory".

To do that, write a simple .bat file like:

-------------- run.bat

SET JETVMPROP=-Djet.gc.fatal.out.of.memory -Djet.gc.verbose.out.of.memory

YourApplication.exe

---------------

Then run it, and send its output to Excelsior Support at

java@excelsior-usa.com.

By the way, how many threads are created in your application? The OutOfMemoryError can be caused by creating the excessive number of threads and/or too large thread stack size.

Also, it would be helpful if you could send us the JET project file (.prj) you use for compilation.

Regards,

--ZZ Top

Share this post


Link to post
Share on other sites

ZZ Top,

In response to your message, the number of threads created is not excessive. At any given time 25-27 threads are active, and some of those are due to JMX monitoring and the VM. I believe I only create maybe 10-15 actual threads, and most of those Timers for GUI functions. Either way, it is not a stack problem; it is a heap problem.

It seems that there is an issue with Jet allocating large buffers. Most of the memory issues are periodic; when I'm processing a large image product. If the image is on the order of 80+ MB (RGBA,20MPix/ch), then after the initial processing, it seems to retain memory. The Sun JVM is running in parallel the same code base and doesn't exhibit the behavior. It seems to be associated with a BufferedImage constructor....

The same processing code occurs on smaller images with no problem.

-D

Share this post


Link to post
Share on other sites

Hello,

We have no ideas why it occurs.

So the only thing we can offer is to try to reproduce it and to debug it by ourselves.

We can do that locally or via remote access.

So we can propose you two options:

1. Provide us with the application bytecode, input data and scenario on which the problem can be reproduced. We may sign a non-disclosure agreement on request. We do not need the full application and real data. If the problem can be reproduced on a scaled down version of the application and/or on some "fake" data, that would be sufficient.

2. Set up remote access so that we could run the application under the debugger right on the client's system. We may sign a non-disclosure agreement on request.

Regards,

Pavel

Share this post


Link to post
Share on other sites

Hi, Pavlov, thank you for your response. It is appreciated.

First off, though, it is not possible for us to either give you the bytecode, nor remote access to the system. There are various export control and security restrictions involved with this software that limit me from doing that. If Excelsior was based in the US, that might be different, but Russia is a hard sell.

Also, just a gut feeling on what the issue might be: I personally think it has to do with the Garbage Collector and possible memory fragmentation for large objects. I obviously don't know the internal workings of your garbage collector, but all my data seems to lead me to that conclusion. However, I only see it when repeatedly allocating 80+ MB objects (20MPixel BufferedImage of RGBA type) , and multiple instances in a relatively short amount of time. These objects are really only manipulated slightly and then converted using ImageIO to some standard format (PNG). THe memory usage looks a little higher than expecting on the allocating of the RGBA product after converting from Grayscale colorspace of the product data, and never seems to be fully released or go back down to an expected level some 45 minutes after the large products are done. Obviously a BufferedImage.flush() and setting the object to null is performed, so the garbage collector should be able to deal correctly with that. Smaller products do not seem to be adversely affected, and if you average out the amount of data over time, the small products produce significantly more data than the larger products. But that is really all I can tell you at this time.

I really appreciate your feedback on this issue.

-D

Share this post


Link to post
Share on other sites
There are various export control and security restrictions involved with this software that limit me from doing that. If Excelsior was based in the US, that might be different, but Russia is a hard sell.

I see. But that did not prevent Sun Microsystems from licensing the Java technology to Excelsior.

http://java.sun.com/j2se/licensees/index.html

B)

--------------

As for your problem, could you enable the jet.gc.* properties as described in a previous post and send us the app output?

It should help prove or disprove your assumptions.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×