Seeing the advantage of using Hugemem and Hugepages with JDK1.5, Good bye JDK1.4
By gaurav.verma on Apr 28, 2007
PrefaceWell, J2SE1.5 has been out for a long time now. Along with the new version, we now have capability to use some really exciting features like HugePages. Using this feature has been covered in great detail in an earlier article Using +LargePages feature with JDK1.5 on Linux hugemem kernel on 11.5.10.
Performance BenchmarkIn this article, we'll see performance benchmarks done for preloading different configurator models. The models were loosely grouped into ~20 groups having different number of models. This was done to keep the results objective and reduce skew.
The experiments were done on Oracle Applications 11i Configurator environment. The dedicated configurator 4 CPU (dual-core) machines were running linux RHAS3 (32-bit architechture).
For JDK1.5, the linux Hugemem Kernal was used so that the Virtual process size coule be as high as 3.5g. Please read through Redhat Linux Kernels and process space limits.. Some eye-openers for having a better idea on process address limits in different linux kernels. Common Incorrect beliefs about process address limits on 32bit platforms is also a good article that you can go through to clear memory address basics.
However, in these experiments, an address space of 1.5g was used for JDK1.5 JVM heapsize. In case its not clear at this point, +LargePages feature allows you to 'lock' JVM heap in real memory and not let it to be swapped out.
The comparision graph of preloading models across Groups using JDK1.5 without hugemem and Largepages Vs JDK1.4 for 1g heap
Now, it was seen that JDK1.4 actually performed better for executing Oracle configurator code while doing the preloading against the same database.
The comparision graph of preloading models across Groups using JDK1.5 WITH hugemem and Largepages (1.5g heap) Vs JDK1.4 (1g) heap
As can be seen, JDK1.5 behaves more if the LargePage feature is used.