59

I have heard mixed opinions over the amount of memory that a byte takes up in a java program.

I am aware you can store no more than +127 in a java byte, and the documentation says that a byte is only 8 bits but here I am told that it actually takes up the same amount of memory as an int, and therefore is just a Type that helps in code comprehension and not efficiency.

Can anyone clear this up, and would this be an implementation specific issue?

MPelletier
  • 16,256
  • 15
  • 86
  • 137
Ben Page
  • 3,011
  • 4
  • 35
  • 37
  • a single byte takes 4/8 bytes depending on the cpu architecture, a byte in byte[] takes exactly one byte + object header (+trailing align) – bestsss Feb 05 '11 at 09:58
  • 2
    "*I am aware you can store no more than +127 in a java byte*" -- Not true, in a sense. You can store 256 different values in a byte, therefore you **can** store way more than 127 in it: up to 255 if you start from 0. It all depends on how you handle those 8 bits. Just for the sake of pedantry :P – Unai Vivi Aug 08 '12 at 14:05

13 Answers13

68

Okay, there's been a lot of discussion and not a lot of code :)

Here's a quick benchmark. It's got the normal caveats when it comes to this kind of thing - testing memory has oddities due to JITting etc, but with suitably large numbers it's useful anyway. It has two types, each with 80 members - LotsOfBytes has 80 bytes, LotsOfInts has 80 ints. We build lots of them, make sure they're not GC'd, and check memory usage:

class LotsOfBytes
{
    byte a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af;
    byte b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf;
    byte c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf;
    byte d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df;
    byte e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef;
}

class LotsOfInts
{
    int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af;
    int b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf;
    int c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf;
    int d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df;
    int e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef;
}


public class Test
{
    private static final int SIZE = 1000000;

    public static void main(String[] args) throws Exception
    {        
        LotsOfBytes[] first = new LotsOfBytes[SIZE];
        LotsOfInts[] second = new LotsOfInts[SIZE];

        System.gc();
        long startMem = getMemory();

        for (int i=0; i < SIZE; i++)
        {
            first[i] = new LotsOfBytes();
        }

        System.gc();
        long endMem = getMemory();

        System.out.println ("Size for LotsOfBytes: " + (endMem-startMem));
        System.out.println ("Average size: " + ((endMem-startMem) / ((double)SIZE)));

        System.gc();
        startMem = getMemory();
        for (int i=0; i < SIZE; i++)
        {
            second[i] = new LotsOfInts();
        }
        System.gc();
        endMem = getMemory();

        System.out.println ("Size for LotsOfInts: " + (endMem-startMem));
        System.out.println ("Average size: " + ((endMem-startMem) / ((double)SIZE)));

        // Make sure nothing gets collected
        long total = 0;
        for (int i=0; i < SIZE; i++)
        {
            total += first[i].a0 + second[i].a0;
        }
        System.out.println(total);
    }

    private static long getMemory()
    {
        Runtime runtime = Runtime.getRuntime();
        return runtime.totalMemory() - runtime.freeMemory();
    }
}

Output on my box:

Size for LotsOfBytes: 88811688
Average size: 88.811688
Size for LotsOfInts: 327076360
Average size: 327.07636
0

So obviously there's some overhead - 8 bytes by the looks of it, although somehow only 7 for LotsOfInts (? like I said, there are oddities here) - but the point is that the byte fields appear to be packed in for LotsOfBytes such that it takes (after overhead removal) only a quarter as much memory as LotsOfInts.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
20

Yes, a byte variable in Java is in fact 4 bytes in memory. However this doesn't hold true for arrays. The storage of a byte array of 20 bytes is in fact only 20 bytes in memory.

That is because the Java Bytecode Language only knows two integer number types: ints and longs. So it must handle all numbers internally as either type and these types are 4 and 8 bytes in memory.

However, Java knows arrays with every integer number format. So the storage of short arrays is in fact two bytes per entry and one byte per entry for byte arrays.

The reason why I keep saying "the storage of" is that an array is also an object in Java and every object requires multiple bytes of storage on its own, regardless of the storage that instance variables or the array storage in case of arrays require.

Mecki
  • 125,244
  • 33
  • 244
  • 253
  • oh yeah, I forgot that not-so-little detail! – Steve McLeod Oct 23 '08 at 14:39
  • 1
    Don't forget that a byte array also has the normal overheads of being an object, and the length. Oh, and your variable is then a reference (4 or 8 bytes). So to actually have 20 bytes available and useful will require 36 bytes, assuming no aliasing. I'd stick to 20 byte fields :) – Jon Skeet Oct 23 '08 at 15:10
  • @Jon @Mecki Can you give more or less exact formula to compute the size of `int[]` array? Will it be `4[=length] + 4[=int_size]*length(array) + 8_byte_align`? – dma_k Mar 08 '10 at 10:53
  • @dma_k: There is no formula because it solely depends on the virtual machine. An array is more or less an object in Java. An object might have 20 internal variables, necessary for VM management only, or it might have none of these. There is more than just Sun's VM on this planet (a lot more). An int[] array will for sure be at least "4 * length(array)" and has some static overhead. Overhead can be anything, from 4 byte to xxx byte; overhead does not depend on array size (int[1] has the same static overhead as int[10000000]); thus overhead is insignificant for big arrays. – Mecki Mar 08 '10 at 11:36
  • 1
    @Mecki I found this link in yet another thread; it satisfied my curiosity: http://kohlerm.blogspot.com/2008/12/how-much-memory-is-used-by-my-java.html – dma_k Mar 08 '10 at 17:12
  • @dma_k: Please note: Those are only valid for SUNs JVM, as the blog entry also states (and SUN is now Oracle, BTW; and the Sun JVM exists only for Windows, Linux and Solaris); Not necessarily for any other JVM that exists. Further SUN may feel to change that with every new release (e.g. Java 1.7/1.8 might have totally different values). If you want to know for sure, test yourself (create lots of arrays, measure memory consumption of JVM) - if the JVM exists in source, look at the source and you'll have absolute correct values. – Mecki Mar 09 '10 at 00:22
  • That means you say "test".getBytes() occupies only 4 bytes? – JavaTechnical Mar 26 '19 at 13:33
  • @JavaTechnical No. First of all it depends on the charset how many bytes a character occupies. If the charset is UTF-16, you will have 2 bytes per characters, so in case of "test" that would 8 bytes of character data. And then an array is an object in Java and an object itself requires several bytes of storage (depends on the JVM how many). I only said that within an array, a byte is a byte and a short is two bytes of storage. But ivars or stack variables in Java are always at least 4 bytes, because they can only be int or long, even if you declare them as byte or short. – Mecki Mar 26 '19 at 16:34
7

Java is never implementation or platform specific (at least as far as primitive type sizes are concerned). They primitive types are always guaranteed to stay the same no matter what platform you're on. This differs from (and was considered an improvement on) C and C++, where some of the primitive types were platform specific.

Since it's faster for the underlying operating system to address four (or eight, in a 64-bit system) bytes at a time, the JVM may allocate more bytes to store a primitive byte, but you can still only store values from -128 to 127 in it.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
  • 1
    Even if it uses 4 bytes to store a byte, an array of bytes would probably be packed. I would be surprised if a byte[4] used 16 bytes instead of 4 bytes. – Kip Oct 23 '08 at 14:32
  • 1
    Probably. That *would* be implementation specific. I honestly don't know which method would be faster. – Bill the Lizard Oct 23 '08 at 14:36
  • 1
    the article is correct, but the comment is wrong. a single byte variable consumes 1 byte +aligment. 8 Byte variabels on a Sun JVM for example cost 8 bytes – kohlerm Oct 27 '08 at 20:40
5

I did a test using http://code.google.com/p/memory-measurer/ Note that I am using 64-bit Oracle/Sun Java 6, without any compression of references etc.

Each object occupies some space, plus JVM needs to know address of that object, and "address" itself is 8 bytes.

With primitives, looks like primitives are casted to 64-bit for better performance (of course!):

byte: 16 bytes,
 int: 16 bytes,
long: 24 bytes.

With Arrays:

byte[1]: 24 bytes
 int[1]: 24 bytes
long[1]: 24 bytes

byte[2]: 24 bytes
 int[2]: 24 bytes
long[2]: 32 bytes

byte[4]: 24 bytes
 int[4]: 32 bytes
long[4]: 48 bytes

byte[8]: 24 bytes => 8 bytes, "start" address, "end" address => 8 + 8 + 8 bytes
 int[8]: 48 bytes => 8 integers (4 bytes each), "start" address, "end" address => 8*4 + 8 + 8 bytes
long[8]: 80 bytes => 8 longs (8 bytes each), "start" address, "end" address => 8x8 + 8 + 8 bytes

And now guess what...

    byte[8]: 24 bytes
 byte[1][8]: 48 bytes
   byte[64]: 80 bytes
 byte[8][8]: 240 bytes

P.S. Oracle Java 6, latest and greatest, 64-bit, 1.6.0_37, MacOS X

Fuad Efendi
  • 147
  • 2
  • 2
5

A revealing exercise is to run javap on some code that does simple things with bytes and ints. You'll see bytecodes that expect int parameters operating on bytes, and bytecodes being inserted to co-erce from one to another.

Note though that arrays of bytes are not stored as arrays of 4-byte values, so a 1024-length byte array will use 1k of memory (Ignoring any overheads).

izb
  • 50,101
  • 39
  • 117
  • 168
3

It depends on how the JVM applies padding etc. An array of bytes will (in any sane system) be packed into 1-byte-per-element, but a class with four byte fields could either be tightly packed or padded onto word boundaries - it's implementation dependent.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Does this mean that using a byte alone will not save memory, but if i were to use more than one byte variable (or an array of bytes) i could save significant memory. (I.e. A byte[10][10] could/should take less memory than a int[10][10]) – Ben Page Oct 23 '08 at 14:28
  • Potentially :) (Certainly I'd expect a byte array to take up less space than an int array - but four byte variables vs four int variables? Don't know.) – Jon Skeet Oct 23 '08 at 14:36
  • (See my other answer for evidence that at least some JVMs do packing.) – Jon Skeet Oct 23 '08 at 15:03
2

What you've been told is exactly right. The Java byte code specification only has 4-byte types and 8-byte types.

byte, char, int, short, boolean, float are all stored in 4 bytes each.

double and long are stored in 8 bytes.

However byte code is only half the story. There's also the JVM, which is implementation-specific. There's enough info in Java byte code to determine that a variable was declared as a byte. A JVM implementor may decide to use only a byte, although I think that is highly unlikely.

Steve McLeod
  • 51,737
  • 47
  • 128
  • 184
  • Hmm... that seems to go against http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#31446 : "The values of the integral types of the Java virtual machine are the same as those for the integral types of the Java programming language (§2.4.1)" (Looking for bytecode stuff now...) – Jon Skeet Oct 23 '08 at 14:24
  • Got something: http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#7565 - bipush, baload and bastore appear to work on the byte type... *arithmetic* is only done on ints/longs, but that's a different matter. – Jon Skeet Oct 23 '08 at 14:26
  • Jon, I described the byte code spec. That's different to the JVM spec. – Steve McLeod Oct 23 '08 at 14:27
  • Does the byte code spec not include bastore/baload/bipush then? – Jon Skeet Oct 23 '08 at 14:30
  • 1
    Actually it also has arrays and byte arrays are in fact byte arrays and there every byte really is a byte – Mecki Oct 23 '08 at 14:33
  • 1
    Yes it does. But the Java stack is defined as a series of 4-byte slots. Pushing onto the stack always uses one (for 4-byte types) or two (for 8-byte types) elements. bipush will use one slot. – Steve McLeod Oct 23 '08 at 14:35
  • 1
    And the JVM certainly knows when a field is a byte field rather than an int field, doesn't it? It may choose not to pack them tightly, but surely that's an implementation decision. – Jon Skeet Oct 23 '08 at 14:35
  • And the JVM is a stack-based VM. But I'm guessing you knew that! – Steve McLeod Oct 23 '08 at 14:36
  • I learnt this stuff in detail when I wrote a java decompiler. Illuminating stuff as to what really goes on in Java byte code. – Steve McLeod Oct 23 '08 at 14:38
  • 3
    Even if the Java *stack* is int-based, that doesn't mean its object layout has to be. I'm working up a benchmark... – Jon Skeet Oct 23 '08 at 14:48
  • Hi, Jon, what did the benchmark show? By the way, I heard another reason why stack based jvm deal with int/long only - performance: it's not fast to address bytes with other types within single stack line: shifting operations, some logic etc - will slow down the execution. – yetanothercoder Oct 02 '12 at 14:30
2

You could always use longs and pack the data in yourself to increase efficiency. Then you can always gaurentee you'll be using all 4 bytes.

Christopher Lightfoot
  • 1,147
  • 1
  • 11
  • 27
  • or even all 8 bytes, in a long :) – JeeBee Oct 23 '08 at 14:34
  • 1
    if you're actually considering this type of memory management, I think you should probably be using C++ or some other language that lets you do the memory management yourself. You'll lose far more in the overhead of the JVM than you'll save through tricks like this in Java. – rmeador Oct 23 '08 at 14:35
  • Ah. In C/C++ on 32bit systems int and long are both 32bit or 4 bytes; I forget that long is actually a long on other systems - always made me laugh when they added "longlong" to indicate an 8byte long... ah well. – Christopher Lightfoot Oct 24 '08 at 09:02
  • you can gain performance because you can with ints you can handle 4 bytes at once, not because you save memory (at lost usually) You don't need to pack byte[]'s. you need to avoid single byte fields in objects because alignment will increase the memory overhead – kohlerm Oct 27 '08 at 20:45
2

byte = 8bit = one byte defined by the Java Spec.

how much memory an byte array needs is not defined by the Spec, nor is defined how much a complex objects needs.

For the Sun JVM I documented the rules: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5163

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
kohlerm
  • 2,596
  • 1
  • 17
  • 22
0

Just wanted to point out that the statement

you can store no more than +127 in a java byte

is not truly correct.

You can always store 256 different values in a byte, therefore you can easily have your 0..255 range as if it were an "unsigned" byte.

It all depends on how you handle those 8 bits.

Example:

byte B=(byte)200;//B contains 200
System.out.println((B+256)%256);//Prints 200
System.out.println(B&0xFF);//Prints 200
Unai Vivi
  • 3,073
  • 3
  • 30
  • 46
0

See my MonitoringTools at my site (www.csd.uoc.gr/~andreou)

class X {
   byte b1, b2, b3...;
}

long memoryUsed = MemoryMeasurer.measure(new X());

(It can be used for more complex objects/object graphs too)

In Sun's 1.6 JDK, it seems that a byte indeed takes a single byte (in older versions, int ~ byte in terms of memory). But note that even in older versions, byte[] were also packed to one byte per entry.

Anyway, the point is that there is no need for complex tests like Jon Skeet's above, that only give estimations. We can directly measure the size of an object!

0

Reading through the above comments, it seems that my conclusion will come as a surprise to many (it is also a surprise to me), so it worths repeating:

  • The old size(int) == size(byte) for variables holds no more, at least in Sun's Java 6.

Instead, size(byte) == 1 byte (!!)

-3

It appears that the answer is likely to depend on your JVM version and probably also the CPU architecture you're running on. The Intel line of CPUs do byte manipulation efficiently (due to its 8-bit CPU history). Some RISC chips require word (4 byte) alignment for many operations. And memory allocation can be different for variables on the stack, fields in a class, and in an array.

Jeff Grigg
  • 1,004
  • 8
  • 7