How do I estimate a class's total permgen memory consumption?

Question

Recently, I was writing a class in which I discovered that I could reduce memory consumption of instances by ~10 bytes/element, but only at the cost of making the code much more complex. This increased the size of the compiled .class file by ~10KB.

I assume that the JVM has to load the .class file into memory, so these changes wouldn't pay for themselves unless there were at least 1000 elements or so. But that arithmetic doesn't work out unless the extra 10KB in the class file is the only cost of the increased code complexity.

This Oracle blog suggests that there's a fair amount of extra memory getting consumed by the class in the permgen that isn't just based on the .class file -- for example, I suspect that more complex code might require more memory for optimization metadata.

So, this question has two parts:

• How can I measure the actual permgen memory consumption of a particular class? Either at runtime with some instrumentation, or with profiling tools?
• Is there a way to estimate the permgen memory consumption of the class as I'm writing it? (With some background knowledge , you can estimate the memory consumption of class instances as you're writing them; I'm wondering if we can estimate the permgen memory consumption of the class itself.)

Similar details for the Dalvik VM would be appreciated, but I'm mostly focused on OpenJDK and the other "mainstream" JVMs.

Answer 1

How can I measure the actual permgen memory consumption of a particular class? Either at runtime with some instrumentation, or with profiling tools?

One approach could be to load the class to measure in a different classloader and use jmap -permstat as presented in this blog entry .

For each class loader object, the following details are printed:

1. The address of the class loader object – at the snapshot when the utility was run.
2. The number of classes loaded (defined by this loader with the method(java.lang.ClassLoader.defineClass).
3. The approximate number of bytes consumed by meta-data for all classes loaded by this class loader.
4. The address of the parent class loader (if any).
5. A “live” or “dead” indication – indicates whether the loader object will be garbage collected in the future.
6. The class name of this class loader.

Answer 2

This is an answer to your second point; I'm not sure how useful this would be, but I've found the slides in the presentation Building Memory-efficient Java Applications: Practices and Challenges to be pretty helpful in estimating the size and health of various Java objects. He goes into a lot of detail when estimating sizes for objects in 32-bit and 64-bit JVM's, and also provides pointers to make your object more memory-efficient.