JDK 1.7 is showing ~19%-52% drop in performance for Memory footprint in 11gr1PS5 WLS benchmarks

We are certifying JDK 7 for 11gR1PS5 for fusion middleware components. When we tested WLS startup/footprint with JDK7 b147 and compared to JDK6u27, we are seeing a regression.

JDK 1.7 is showing ~19%-52% drop in performance for Memory footprint benchmarks in live object measurement.

JDK 1.7 is showing ~12%-47% drop in performance for Memory footprint benchmarks in MaxHeap measurement.

From the memory analysis we find the following instance counts.

JDK 7 java.lang.String = 75601
JDK 6 java.lang.String = 67891

JDK 7 char[] = 69773
JDK 6 char [] = 62432

JDK 7 java.util.concurrent.ConcurrentHaspMap$HashEntry=20949
JDK 6 java.util.concurrent.ConcurrentHaspMap$HashEntry=4944

JDK 7 java.lang.Object = 17918
JDK 7 java.lang.Object = -


Observations:

· Seeing more instances of java.util.concurrent.ConcurrentHaspMap$HashEntry getting loaded in JDK1.7

· Under sun.misc.Launcher$AppClassLoader Objects, seeing multiple NEW references of java.util.concurrent.ConcurrentHaspMap internally referring to java.util.concurrent.ConcurrentHaspMap$Segment static final class objects.

o java.util.concurrent.ConcurrentHaspMap$Segment static classes are using java.util.concurrent.ConcurrentHaspMap$HashEntry data structures.

o Most of these ConcurrentHashMap referencs are ending up referring to Security related Objects(like java.security.provider,javax.annotation.security,etc)

· Seeing entirely sun.misc.Launcher$ExtClassLoader NEW Objects getting loaded at the Server startup, which are having references of java.util.concurrent.ConcurrentHaspMap$Segment (consuming around 0.7 MB)

· Java.net.URLClassLoader NEW objects are getting loaded in JDK1.7(consuming around 97KB)

· Overall we think, JDK1.7 is using java.util.concurrent.ConcurrentHaspMap$HashEntry Objects extensively which is consuming Lot of memory. It looks like some implementation has been changed, where they are using java.util.concurrent.ConcurrentHaspMap as data structure.

· The main reason why ConcurrentHashmap is consuming more Memory is that, it has to maintain Lock Objects in Memory if our understanding is correct about this. But performance wise ConcurrentHashMap is far more better than legacy Hashtable.

· From the profiles it looks like, they were using Hashtable datastructures in JDK1.6 and these Hashtable were got replaced by ConcurrentHashMap in JDK1.7.


We have the GC logs and heap dumps,please let me know in case if we need them.
I verified with the QA team that we can close the bug (but they don't have access to bugster, so I am doing it).

The ultimate resolution of the issue is that most of the difference is memory (interned strings) moved from permgen to the regular heap (which may require some resizing), and there is a small amount of additional overhead from the new parallel classloading feature, which is a design choice (trading memory for throughput).