I'm running the most current kernel on an Arch x86_64 distro. I run this same setup on a variety of other machines (Raspberry Pi, Dell Inspiron 32-bit laptop, HP AMD Desktop). I've not experienced such terrible Java performance on any of these machines (even the Pi much to my dismay). The current setup is running on a virtualized machine inside of VMWare player with 1 Gig of RAM (which should be more than enough). Initially, I never experienced a performance issue when running Java applications. Over time however, something must've changed through one of the updates that affected the JVM.
Upon research I uncovered the following pages:
At one point the issue was fixed by issuing a simple:
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
I (perhaps erroneously) concluded that the defragmentation of the huge pages was creating some sort of bottleneck, but given that the problem seems to spontaneously occur despite having added "transparent_hugepage=madvise" to the kernel boot parameters in grub. I'm guessing that's not the case. When I used the "never" option, the Eclipse IDE crashed, so I'm guessing never is simply inadvisable. Running grep Huge /proc/meminfo yields the following info:
Hugepagesize: 2048 kB
Furthermore, I've noticed the problem only occurs on graphical applications using Swing, as determined by a simple use case of a "Hello World!" JLabel on a JFrame. Running it with the command line option -Dsun.java2d.trace=log showed that the application hung specifically on the following line:
sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
Which appears to be the moment RIGHT before drawing takes place and anything is dislayed on the screen (as this is subsequently followed by a series of X11FillRect calls). Console applications don't suffer from this massive startup lag.
I'm running the latest version of the openjdk, and at this point am extremely baffled. Short of asking the simplest and laziest question which is "what the eff am I doing wrong?" I'm just unsure as to what step to take next or what key piece of information I'm missing. I figure that because this is a 64-bit system, I may actually have to set up my HugePages so that there are actually some available, as opposed to the 0 that are showing. Why this strikes me as odd is that my understanding is that the JVM doesn't use HugePages unless you supply -XX:+UseLargePages in the command line. However, are the HugePages indicated by /proc/meminfo somehow different from Transparent HugePages?
Any help would be greatly appreciated.
1 Replies - 1211 Views - Last Post: 23 October 2013 - 01:37 PM
Replies To: Java Performance Issues with Transparent Huge Pages
Re: Java Performance Issues with Transparent Huge Pages
Posted 23 October 2013 - 01:37 PM
For myself the solution proved to be the same as in this thread. I had not set up my /etc/hosts file because the Arch Linux installation implied that it was no longer necessary. However, upon doing so all the Java slowdown issues have disappeared. I've also undone any changes that made available standard Huge Pages and/or JVM parameters that made use of them. Thankfully the performance of my Java applications is now as expected. Apparently, there must be some form of interaction, at some level, between the JVM and the /etc/hosts file that causes this hiccup.
This post has been edited by grimpirate: 23 October 2013 - 01:40 PM
Page 1 of 1