We ported our Java Swing application from Windows2000 to Windows7.
We are using JRE 1.5. We tried porting the application to JRE 1.6 and JRE 1.7 without success due to Swing problems and we are not keen to undergo a major rewrite of our application in order to fix the Swing problems. Hence we are sticking with JRE 1.5 for now.
Application users are claiming that after several hours of continued use on Windows7 the application becomes slow.
We had no such complaints when the application was running on Windows2000.
We have checked the garbage collection and the heap and have found no significant differences between Windows2000 and Windows7.
Although there is no apparent memory leak, the amount of memory allocated to the java process grows with time until there is around 50Mb of free memory available as shown by the Windows Task Manager on a machine with 2Gb of RAM.
The application uses JNI to interact with the printer device. Each workstation running the application has a local printer attached.
The application also interacts with an IBM mainframe that houses a central database which is accessed by all the workstations. Communication between the workstation and the mainframe is via IBM's MQ software.
I would like to get suggestions on how to locate the cause of this slowdown in our application.
Avi Abrami wrote:Although there is no apparent memory leak, the amount of memory allocated to the java process grows with time until there is around 50Mb of free memory available as shown by the Windows Task Manager on a machine with 2Gb of RAM.
Ok. So there is a "not easy to find" memory leak. Can you take a dump of the memory used by the process when it is hogging memory and see what the biggest uses are?
Using jvisualvm and jstat it appears that
permgen used space remains more or less constant over time
number of loaded classes remains constant over time
However the Resource Monitor (resmon) utility of Windows 7 shows that the total memory that the java process is using increases over time while the user interacts with it. In fact we narrowed it down to interaction with a particular JInternalFrame within the application. If I continually open and close this particular internal frame, the memory used by the java process increases. However if I leave the application running but do not interact with it at all then after a while the amount of memory used decreases.
From my research, it appears that the size of the code-cache part of the non-heap memory is the cause of the increasing memory used by the java process.
So my question now is:
What things cause the code-cache to increase?
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Help Locate Cause of Application Slowdown