I am currently designing a data structure in which I'm trying to keep memory consumption to a minimum. I have a few instance variables that may be null depending on the placement of the Node in the Trie. I started going down the path of creating separate classes (one that has the instance variable and one that doesn't) so that I won't waste tons of space with null references... but then I started to wonder how the jvm works. Does it still eat up the full 8 bytes (assuming x64 arch) if the object reference is null or does it have a more optimal way to store a null reference?
Asked
Active
Viewed 716 times
3
-
I would think the object reference is still allocated (8 bytes) but no memory allocated for the object itself. I don't know though, so I'm really interested in the answer. – Sheriff Apr 13 '12 at 18:29
4 Answers
2
I'm almost sure JVMs will use as much space for a null reference as for any other one. If you have an object with say 3 reference fields, and you null out the one in the middle, I don't think any virtual machine would be able to move the 3rd one and save the 4 or 8 bytes (and then when you changed the null to something else, it would have to move stuff around again). If if this was technically feasible, it would not be worth it - the extra computational cost and code complexity would kill any potential gains. Also, partly due to C heritage, on most machines a pointer equal bit-wise to 0 works as a NULL at a very low level, so the null reference has a rather obvious representation.
On Oracle/Sun JDK you can use -XX:+UseCompressedOops command line argument to make references 4 bytes instead of 8 on 64-bit if your heap is smaller than 16 GB (regardless of whether the reference is null or not).
Michał Kosmulski
- 9,855
- 1
- 32
- 51
1
The answer is yes It still use necessary bytes. In Java, null is just a value that a reference can have. It means that the reference refers to nothing. In this case you still consume the space for the reference. This is 4 bytes on 32-bit systems or 8 bytes on 64-bit systems.
-
This is just one possible way of implementing null references. What's to stop the JVM from doing it differently? – templatetypedef Apr 13 '12 at 18:35
0
Classes and superclasses use some bytes too.
If you really want to avoid most memory use, I suggest using the FlyWeight pattern
(Ideas : reuse the same immutable objects ; have a factory creating and caching them).
Your code becomes a bit more complex, which is bad. But you can save a lot on memory.
Another choice is to work on simpler types (not objects). It is less practical though, you have to do everything externally on your data ... So I prefer the FlyWeight.
KLE
- 23,689
- 4
- 56
- 62
0
We can appy simple math: assume you have an object with a field of type int, that's 4 bytes on any architecture, which can be undefined (it depends on the use case what value the field must take that you could understand it is undefined). Now, if it is defined, you use 4 bytes. If it is not defined, you waste 4 bytes.
Assume you wrap it into the object. Now, if the field is defined, it uses 4 or 8 bytes (depending on the JVM bitness and the pointer compression turned on or off with -XX:+UseCompressedOops) for the pointer. The object with single 4 byte field will consume 16 bytes regardless of bitness (object will occupy 16 bytes both on 32 and 64 bit Java runtime, as it contains 8 or 12 bytes of object header and 4 bytes of value and used memory is aligned up closest 8 bytes).
To sum it up, if you stick to the primitive you'll use 4 bytes. If you will wrap single int into an object you will use 20 or 24 bytes if the field has value; and 4 or 8 bytes if the value is null.
Vladimir Šor
- 119
- 6