3

I am in the process to tune a heap heavy Java Application running in a 64 bit environment (required heap size more than 32G) and intending to increase Xmx to an appropriate number.

After 32G, OOPs (Ordinary Object Pointers) will not be compressed using -XX:+UseCompressedOops option. So need to know the exact size of OOPs in my application to compensate for the uncompressed OOPS and increasing extra memory required on top of that.

Is there a way to determine the total memory consumed by OOPs alone?

Tagir Valeev
  • 97,161
  • 19
  • 222
  • 334
Vivek
  • 1,640
  • 1
  • 17
  • 34
  • Ordinary Object Pointers – Vivek Dec 24 '15 at 07:26
  • Seems to be a duplicate of http://stackoverflow.com/questions/52353/in-java-what-is-the-best-way-to-determine-the-size-of-an-object?rq=1 Have you tried to use a Profiler? Can you share the outcome if yes? – Akshay Gehi Dec 24 '15 at 07:27
  • It isn't a duplicate, Here I am not trying to understand the size taken by OOPs alone, not the object. – Vivek Dec 24 '15 at 07:28
  • I tried using visualvm which only gives analysis on size of objects, not oops – Vivek Dec 24 '15 at 07:32
  • Every OOP is 64 bits, so times that by how many objects you have - should give you a very good indication as to how much memory you are using for OOPs alone. So four bytes for a single OOP is a reasonable metric to work with. – Ewald Dec 24 '15 at 07:33
  • That will not be a very accurate number because there will be a lot of objects with multiple references, take example of String Objects from Pool, where same object can be referenced by a lot of references. – Vivek Dec 24 '15 at 07:35
  • 1
    You might want to check out JOL - http://openjdk.java.net/projects/code-tools/jol/ – Akshay Gehi Dec 24 '15 at 07:35
  • 1
    If you are already consuming more than 32gb of data, being out by a few megabytes really won't rock the boat. – Ewald Dec 24 '15 at 07:46
  • sidenote: If you bump `ObjectAlignmentInBytes` to 16 bytes then you can extend compressed oops to 64GB. Of course that comes with its own overhead due to unused alignment padding. Whether the gain from compressed oops outstrips the alignment losses depends on your object population. – the8472 Dec 24 '15 at 19:14
  • @Ewald - Makes sense. Thanks, your advice helped – Vivek Dec 25 '15 at 17:08
  • @Vivek - I'd be interested to see those results - could you post your findings as an edit? – Ewald Dec 28 '15 at 06:56

1 Answers1

1

It's quite simple using Java Object Layout library which is available on Maven Central. Just check the org.openjdk.jol.util.VMSupport.OOP_SIZE static field:

import org.openjdk.jol.util.VMSupport;

public class Test {
    public static void main(String[] args) {
        // Prints OOP size in bytes: usually 4 or 8
        System.out.println(VMSupport.OOP_SIZE);
    }
}

Sample output:

$ java -cp jol-core-0.4.jar;bin -Xmx32G Test
8

$ java -cp jol-core-0.4.jar;bin -Xmx31G Test
4

$ java -cp jol-core-0.4.jar;bin -Xmx32G -XX:-UseCompressedOops Test
8
Tagir Valeev
  • 97,161
  • 19
  • 222
  • 334
  • This will tell me the size of one OOP, which is not something I wanted. I wanted to know the size consumed by all the OOPs in the process – Vivek Dec 25 '15 at 09:34
  • @Vivek The only way to do this is to dump all the objects in the heap and count the number of references. Why do you want to know this? Perhaps there is a better way to do this? Have you tried to use a memory profiler? – Peter Lawrey Dec 26 '15 at 16:09