Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

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

 
Ranch Hand
Posts: 422
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

According to this video YouTube video on Java Memory Mgt from IBM the statement 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
 
Sheriff
Posts: 26951
83
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author & internet detective
Posts: 40913
840
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
lowercase baba
Posts: 13018
66
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...)
 
Ranch Hand
Posts: 106
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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




 
Saloon Keeper
Posts: 24825
172
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 422
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

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?


Is this any better or worse?


Thanks
Siegfried
 
Marshal
Posts: 74654
335
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic