-
Bug
-
Resolution: Won't Fix
-
P3
-
6u4
This table shows the user cpu time for 6u3 and 6u4 reported by
/bin/time for running 32 bit javac on various numbers of files on a Sun Blade 2500, 2 cpus. Sol 10.
Options used are:
-J-XX:ThreadStackSize=768 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m
6u3 6u4 Per cent degradation
Server:
122 files 12.3 13.2 0.07
203 files 13.7 15.6 0.14
435 files 31.6 36.2 0.15
Client
203 files 5.3 5.4 0.02
I added the option
-XX:+PrintGCDetails
and the two log files shows that the GC time is the same for 6u3 and 6u4.
I swapped libjvm.so in 6u3 and 6u4 and the degradation followed libjvm.so.
The attached script can be used to repro this problem.
/bin/time for running 32 bit javac on various numbers of files on a Sun Blade 2500, 2 cpus. Sol 10.
Options used are:
-J-XX:ThreadStackSize=768 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m
6u3 6u4 Per cent degradation
Server:
122 files 12.3 13.2 0.07
203 files 13.7 15.6 0.14
435 files 31.6 36.2 0.15
Client
203 files 5.3 5.4 0.02
I added the option
-XX:+PrintGCDetails
and the two log files shows that the GC time is the same for 6u3 and 6u4.
I swapped libjvm.so in 6u3 and 6u4 and the degradation followed libjvm.so.
The attached script can be used to repro this problem.
- relates to
-
JDK-6463133 Deoptimization should not use code patching
- Resolved