2

I'm trying to find a simple and accurate reference for the cost in bytes of Java 64 bit Objects. I've not been able to find this. The primitives are clearly specified but there are all these edge cases and exceptions that I am trying to figure out like padding for an Object and cost vrs. space they actually take up on the heap, etc. From the gist of what I'm reading here: http://btoddb-java-sizing.blogspot.com/ that can actually be different?? :-/

trincot
  • 317,000
  • 35
  • 244
  • 286
user447607
  • 5,149
  • 13
  • 33
  • 55
  • 1
    possible duplicate of [In Java, what is the best way to determine the size of an object?](http://stackoverflow.com/questions/52353/in-java-what-is-the-best-way-to-determine-the-size-of-an-object) – David Conrad Jul 18 '14 at 21:01
  • The example above is fine if you are not at the whiteboard for an interview. On the other hand if you are... My main issue here was that we were supposed to know enough of this off the top of our heads to be useful when calculating the memory efficiency of an algorithm. Also not terribly accurate according to answers to that question. I'm aware of the String table for example but in the case of data we can assume most, if not all, Strings are not the same. – user447607 Jul 18 '14 at 21:24
  • When you're worried about the memory efficiency of an algorithm you're usually worried about array sizes. Arrays take a fixed overhead plus the size of the actual data -- byte, char, int, double, whatever multiplied times the number of elements. – Hot Licks Jul 18 '14 at 23:14
  • A thoroughly pointless interview question with no single correct answer. Possibly they may have been expecting an answer about measuring methodology. Or else they were just wrong, showing off, etc. – user207421 Jul 19 '14 at 00:54

2 Answers2

3

If you turn off the TLAB, you will get accurate accounting and you can see exactly how much memory each object allocation uses.

The best way to see where your memory is being used, is via a memory profiler. Worry about bytes here and there is most likely a waste of time. When you have hundreds of MB, then it makes a difference and the best way to see that is in a profiler.

BTW Most systems use 32-bit references, even in 64-bit JVMs. There is no such thing as a 64-bit Object. Apart from the header, the object will uses the same space whether it is a 32-bit JVM or using 32-bit references in a 64-bit JVM.

user207421
  • 305,947
  • 44
  • 307
  • 483
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
1

You are essentially asking for a simple way to get an accurate prediction of object sizes in Java.

Unfortunately ... there isn't one!

The blog posting you found mentions a number of complicating factors. Another one is that the object sizing calculation can potentially change from one Java release to the next, or between different Java implementation vendors.

In practice, you options are:

  • Estimate the sizes based on what you know, and accept that your estimates may be wrong. (If you take account of enough factors, you should be able to get reasonable ballpark estimates, at least for a particular platform. But accurate predictions are inherently hard work.)

  • Write micro benchmarks using the TLAB technique to measure the size of the objects.

The other point is that in most cases it doesn't matter if your object size predictions are not entirely accurate. The recommended approach is to implement, measure and then optimize. This does not require accurate size information until you get to the optimization stage, and at that point you can measure the sizes ... if you need the information.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216