Instance size of Java object are different in different JVM

Question

Here I found a problem that instance size of same class are not same in different version of JVM (it's 40 in 1.6.0_21 and 24 in 1.6.0_31). even though, the code are same. Do you anyone encounter similar problem before? Or do you have any suggestions?

JDK 1.6.0_21

# java -version 
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)

# java obj.ObjectSize &

# jps | grep ObjectSize
27251 ObjectSize

# jmap -histo 27251 | grep US_ASCII
 145:             1             40  sun.nio.cs.US_ASCII

JDK 1.6.0_31

# java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

# java obj.ObjectSize &

# jps | grep ObjectSize
26645 ObjectSize

# jmap -histo 26645 | grep US_ASCII
161:             1             24  sun.nio.cs.US_ASCII

ObjectSize.java

package obj;
import java.util.concurrent.TimeUnit;
import sun.nio.cs.US_ASCII;

public class ObjectSize {

    public static void main(String[] args) {
        US_ASCII as = new US_ASCII();
        System.out.println(as);

        try {
            TimeUnit.MINUTES.sleep(5);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

If I use jre 1.6.0_21, the total memory usage will be larger than that using 1.6.0_31. — Jason Hu
– Jason Hu, Commented Jan 8, 2013 at 9:00

fgysin · Accepted Answer · 2013-01-08 09:12:26Z

5

I think what you are encountering is just a fact originating in how compiled programming languages work, especially if they run inside a VM.

Changes in the implementation of the virtual machines are allowed to behave differently, e.g. producing Java byte code of different sizes -- as long as they keep to the same Java API.

Is the difference in memory usages really that big? If the increase in memory size is actually a problem I would dare to suggest that you already had a memory problem in the first place.

If you were working at 50% capacity with one VM and are now hitting the cap with the other I guess you need to undertake some deeper changes in your code. Or throw more hardware at the problem. ;)

answered Jan 8, 2013 at 9:12

fgysin

12k15 gold badges69 silver badges99 bronze badges

Sign up to request clarification or add additional context in comments.

Comments

Peter Lawrey · Accepted Answer · 2013-01-08 09:23:01Z

2

Early versions of Java 6 supported -XX:+UseCompressedOops but it was off by default. (The first versions of Java 6 didn't support this at all) This means that references in a 64-bit JVM were 64-bit. In newer JVMs, a 32-bit reference is used if the heap is < 32 GB. It can do this as obejcts are 8-byte aligned so you can address 2^32 * 8 bytes with a 32-bit reference.

Note: US_ASCII inherits three fields from Charset

private final String name;          // tickles a bug in oldjavac
private final String[] aliases;     // tickles a bug in oldjavac
private Set<String> aliasSet = null;

These references are 4-bytes smaller saving 12 bytes, however objects are 8 byte aligned so the total saving is 16 bytes.

Using compressed oops reduces the amount of memory used.

Compressed oops in the Hotspot JVM

BTW: You wouldn't use this class directly, instead you would use StandardCharset.US_ASCII

answered Jan 8, 2013 at 9:23

Peter Lawrey

535k83 gold badges770 silver badges1.2k bronze badges

3 Comments

Mark Rotteveel Over a year ago

StandardCharsets was added in Java 7, so it isn't available when you use Java 6

Peter Lawrey Over a year ago

If you can't use StandardCharsets, you can use Charset.forName("US-ASCII") which is what this class does in reality.

Jason Hu Over a year ago

Thanks Peter Lawrey, I also find below link that talking about -XX:+UseCompressedOops. link.

Stephen C · Accepted Answer · 2013-01-08 09:38:22Z

1

Do you have any suggestions?

If the usage of memory is that important to you, don't use the 64-bit version of 1.6.0_21. Switch to the 32-bit version, or a more recent patch level. Or better yet, Java 7. After all 1.6.0_21 is VERY out of date.

Alternatively, run the JVM with the option to explicitly enable compressed oops as described here:

"For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature."

(But beware that this might tickle bugs in what was ... at that time ... still an experimental JVM feature.)

answered Jan 8, 2013 at 9:38

Stephen C

723k95 gold badges849 silver badges1.3k bronze badges

Collectives™ on Stack Overflow

Instance size of Java object are different in different JVM

3 Answers 3

Comments

3 Comments

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

Comments

3 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Related