Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Odd byte vs int  RSS feed

 
Pete Letkeman
Ranch Foreman
Posts: 654
17
Android Chrome IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is generally accepted the variables of type byte are smaller then variables of type int. I think that it would then stand to reason that if you create a program that uses byte instead of int that the program would be smaller, wouldn't it? So I created a very simple program to test this out and in the end the compiled class version of the code which used byte was larger then the one that used int.

Here is the code that I used for the byte version:

When I compiled that code it was 449 bytes for MyTest.class according to Windows 10.

Here is the code I used for the int version:

When I compiled that code it was 447 bytes for MyTest.class according to Windows 10.

I would have suspected that the byte version would be smaller. Which leads me to the following questions:
  • Am I missing something?
  • If someone else runs the same test do they get the same results?

  • I realize that we are talking about only two bytes right now, but depending on your program/project this could end up to be many more bytes and most embedded systems are limited to how much storage space and memory that they can use.
     
    fred rosenberger
    lowercase baba
    Bartender
    Posts: 12542
    48
    Chrome Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If i remember correctly, there is nothing that says how big an int or a byte must be...it simply defines what range of numbers it must be able to store. So when the JVM is written, they can do whatever they want in terms of memory.

    there also may be something with that literal 100...I think literals are ints by default, so there may need to be some extra stuff needed to compare an int with a byte.
     
    Campbell Ritchie
    Marshal
    Posts: 55747
    163
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Pete Letkeman wrote:It is generally accepted the variables of type byte are smaller then variables of type int.
    Never mind whether it is generally accepted or not, the only thing that matters is what the Java® Language Specification (=JLS) says.
    The JLS wrote:The integral types are byte, short, int, and long, whose values are 8-bit, 16-bit, 32-bit and 64-bit signed two's-complement integers, respectively . . .
    . . . and the Java® Virtual Machine Specification; both those links tell you how many bits each primitive integral type occupies. As Fred says, it doesn't actually say that an int occupies four bytes in primary memory.
    I think that it would then stand to reason . . .
    Unfortunately many things which stand to reason turn out to be false. Fortunately there is a straightforward way to inspect a little program like yours. But first I shall see if I can guess some of the things going on. Start by considering that arithmetic is by default done on ints. Your line 3 makes me suspicious:-
  • 1: The compiler must verify that the int literal 0 is a compile-time constant and that it will fit into the confines of a byte and then probably applies an implicit cast to it.
  • 2: The less than operator requires the byte undergo widening conversion to an int first.
  • 3: The post-increment operator probably requires both widening to an int and, later, implicit narrowing (like a cast) back to a byte.
  • Since System.out.println() implicitly calls String#valueOf(), I don't think that line will have any differences in.
    Watch this space
     
    Campbell Ritchie
    Marshal
    Posts: 55747
    163
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Maybe the remainder operator produces more bytecode, too, but let's stop guessing.

    Use the javap program to inspect the bytecode:-The first code block was with a byte and the second with an int.
    And we can see my guesses were wrong; the compiler perceived that you were using the byte for arithmetic, etc., and converted it to an int on spec. The one difference is that the i++; statement is one line (22) using an int and (?)five lines (22‑26) using a byte. Line 25 is obviously an implicit cast. If you use a hex editor on the two versions of the .class files you can see more. Note that one version one has two lines more than the other (30 as against 28) and that is your two‑byte difference.

    It all goes to show you how you can guess what the compiler does and be miles out.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!