We are encountering some strange JVM performance issues.
We have a large and somewhat opaque GUI component (Actuate Formula 1 spreadsheet).
If we initialize all of it from the Event Dispatch Thread (as you should), we find that the code runs considerably more slowly (dragging the mouse to select cells, there's a noticeable lag).
If we initialize it the first time in the main launcher thread, and only then start using it in the EDT, it runs much more quickly.
When I look at why it is performing slowly using a profiler, the method calls that are taking all of the time are:
- java.lang.Object.getClass()
- java.lang.reflect.Array.newInstance(Class, int)
- java.lang.Class.getComponentType()
- java.lang.Thread.currentThread()
We are using the 64-bit Sun Hotspot JVM on Windows 7 (the one that comes with the JDK).
Does anyone know of any reason why the above methods might perform drastically slower that usual?
I am thinking that maybe it has something to do with the order in which the classes are loaded.... is that a reasonable theory? Does anyone know of any other ways in which I can diagnose why these method calls might be taking a long time?
I've attached two screenshots from the profiler. In both, all I did was drag the mouse around the spreadsheet cells while the profiler was running. So it's just updating the GUI component and not doing very much else.
The first one is spending a lot of time in a method called "releaseLock()". For some reason, this is taking a long time because "getComponentType()" is taking a much longer time than usual.
The second one is after I did a "hack" to remove the cost of "releaseLock()" - but now it just spends lots of time in "getLock()" due to getClass() and currentThread() taking much longer than normal: