Jump to content
Excelsior Forums

Dirv

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Everything posted by Dirv

  1. Hello all. I'm interesting in utilizing the jmxremote features that are part of J2SE 5.0, so I may use the JConsole application to monitor performance from another host. I've attempted to set the correct system properties to activate it as I had when testing with the Sun JRE, but I keep getting a connection refused message. Is that not available from Excelsior JET? If it is, would someone please point me in the correct direction? Note: I'm using Excelsior Jet 4.0 MP2, and have successfully tested the jmxremote stuff using the Sun JRE for J2SE 5.0. Any help would be most appreciated. -D
  2. 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
  3. Garbage Collection and Out Of Memory

    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
  4. Garbage Collection and Out Of Memory

    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
  5. Garbage Collection and Out Of Memory

    Are there any more "jet.gc" properties that aren't listed in the User's Guide that can be used in debugging? -D
×