How much memory is required for "new Integer(10)" ?

[Siegfried Heintze]

According to this video YouTube video on Java Memory Mgt from IBM the statement

Integer x = new Integer(10)

consumes 128 bits (assuming you are running 32 bit java) or 224 bits for 64 bit java.

Is this really true? Are there not some additional data structures required so the garbage collector can find all these bits of memory and de-fragment them? So what does x actually contain? Does it contain a pointer to the Integer object and that pointer needs to change after the garbage collector de-fragments the heap? If so, how does the garbage collector know where the variable x is? X must be on a linked list of active variables so the garbage collector can update "x" to the new location of the Integer object after the heap has been de-fragmented ... correct?

If that is true, then storing an integer object in java is much worse than 128 bits or 224 bits for 64 bit java. How bad is it?

Alternatively, the JVM could implement x as an integer index into a large fixed array of pointers. That array cell would contain the address of the actual integer object containing 10. If so, then the garbage collector would just update this large fixed array (which requires more memory too!). In either case, we need more memory. How much more?

Does anyone know how the Oracle (and other popular JVMs) implement this?

Thanks
Siegfried

[Paul Clapham]

An answer to part of that post:

Yes. A variable always contains a pointer to an object (unless it contains a null reference, that is). (And unless it's a variable of primitive type.) So your line of code contains two things:

1. Integer x is a variable which can refer to an Integer object.

2. new Integer(10) is an object of type Integer.

As far as I know all variables, regardless of their type, require the same amount of memory. Obviously that's not the case for objects. I haven't watched that video but since it's from IBM one would hope that it starts out by mentioning this fact and then continues by describing how variables and objects are implemented. Although, when you're working with "memory management" you're normally only considering the space occupied by objects.

[Jeanne Boyarsky]

Also keep in mind, that you don't need to write new Integer(10). If you use a static/factory method, you'll get the cached version back and there is only one Integer object with value 10 in the system.

[fred rosenberger]

are you really worried about this?  i mean, even if it's not 224 bits but is instead 1000 bits, the computer i'm typing this on has 8 GB...so one Integer uses 0.0000015625% of my computer's memory (if my math is correct, which is often not the case...)

[Gary W. Lucas]

Actually, 16 bytes per Integer instance sounds reasonable to me.  While I haven't made a deep study of this topic, I have had to learn a bit about it.  I have a project that deals with terrain data which processes large data sets and requires the creation of multiple millions of objects at a time. The objects themselves are small, so the memory overhead is quite a substantial factor.   To deal with that successfully, I had to do some testing and investigation  (including using the "Unsafe" API to inspect the bytes of objects, and watching the system process size to evaluate how large the JVM memory use grows during test runs).  Here's what I've found:

In the HotSpot JVM for Windows, Java uses "compressed" object references which require only 4 bytes provided when running with a heap size of smaller than 32 gigabytes (some other JVM's require 16).  For various reasons, all objects must be stored at memory addresses that are a multiple of 8 bytes (there's a long history of this going back to C/C++ structures). So when the JVM is running with a maximum memory space of fewer that 2^35 bytes, it simply divides the addresses by 8 before storing them and multiplies them by 8 before using them.  So only 32 bits (4 bytes) are required for object references.

So,  the JVM  uses the following per object
8 bytes management (including object-synchronization overhead)
4 bytes reference to object's class
x bytes as required for member elements and to "pad" the object size out to a multiple of 8  

In the case of Integer, that 'x' value would be 4 bytes to represent the integer value.  Bringing the total up to 16.  I strongly suspect that there's additional overhead for garbage collection and management, but I've looked at the process size for the JVM in my experiments and I think it's relatively small.

Okay, one other comment.  One of the other posters asked you why you would care about this.  While he has a point, I can think of a couple of circumstances where you might care very much.  For example, if you're doing any kind of image processing  you routinely deal with mega-pixel images.  A Java int would be a fine representation for your pixel data in this case, but an Integer would be disastrous both in terms of memory and performance.   Similar principles would apply for any scientific application that deals with raster data or other large fields of regularly spaced samples.   On the other hand, if you're implementing a user interface and using a ComboBoxModel model based on Integers, the size of the individual objects is trivial compared to everything else that's going on.

So I guess that, in most cases, if your application uses an appropriate data representation for the problem you are dealing with, Java will do a pretty good job of taking care of the memory considerations for you.

Gary

P.S. If you're interested, you can see the project where I've dealt with this stuff at Tinfour

[Tim Holloway]

I gave up on expecting to be able to calculate absolute byte occupancy for Java or database objects a long time ago. Modern-day JVMs and DBMS's can do too many evil tricks to optimize memory occupancy including changing the rules on the fly.

The actual reason why object addresses might be aligned on specific boundaries may have more to do with processor efficiency than memory efficiency. Ever since at least the IBM System/360, the RAM and data bus was a fixed width - generally something between 2 and bytes, depending on the machine model, and any multi-byte object that spanned bus chunks would therefore require more memory-fetch/store cycles than objects that fit neatly within the chunks.

These days we have L1 and L2 cache for stuff like that, but the concept remains the same, if not more so.

[Siegfried Heintze]

Gary W. Lucas wrote:
So,  the JVM  uses the following per object
8 bytes management (including object-synchronization overhead)

Wow! 8 bytes seems like a lot to me -- especially when it is rarely used. I often see this

class Counter{
   Object lock = new Object();
   int c = 0;
   void inc(){
      synchronized(lock){
        c++;
      }
   }
}

So java programmers often create a separate object just for locking. So why does this synchronization feature require 64 bits? Can anyone elaborate on the memory layout of these 64 bits (assuming 32 bit java).
Why must all descendants of Object consume this extra 64 bits of memory when it is so common to create a dedicated lock object (as in my example)? This seems extremely inefficient to require all objects to have this locking capability.
There is probably something I don't understand about locking... Perhaps someone can help me.


So could we save memory with this code?

class Counter{
   int c = 0;
   void inc(){
      synchronized(c){
        c++;
      }
   }
}

Is this any better or worse?

class Counter{
   int c = 0;
   void inc(){
      synchronized(this){
        c++;
      }
   }
}

Thanks
Siegfried

[Campbell Ritchie]

Siegfried Heintze wrote:. . . Wow! 8 bytes seems like a lot to me . . .

There are all sorts of things to fit into those eight bytes. Your object will require creation time (used to prioritise garbage collection), original memory location (used for identity hash code/Object#hashCode), location of its pointer in memory (used if object has to be moved in memory during garbage collection), etc. Come to think of it, those three things alone will occupy sixteen bytes on a 32‑bit machine.

Remember that memory is cheap nowadays. I don't know what fits into those eight bytes, but you might use anything between one bit and one byte to determine whether the object's lock is on or off.