Stupid books says this but stupid me says that...

[K.I.L.E.R]

The book (Java in 2 semesters, which I need for my course) is saying that there should be no need to use anything below int(Byte) and anything below Double(Float).

I believe that using 'Byte' and 'Float' where it can be used will give out a performance benefit over just using double/int everywhere.

So who is right?

There should be benefits AFAICS.

[princec]

It's not correct, there are times and places to use everything. What you need to understand is why and when, and a book making a blanket statement like that won't help you.

Cas

[blahblahblahh]

The book (Java in 2 semesters, which I need for my course) is saying that there should be no need to use anything below int(Byte) and anything below Double(Float).

(assuming you meant to use all lower case, and are talking about the primitives only: )

It's probably referring to the fact that the bytecode encodes both versions using the same number of bits; so a java byte, char, and short ALL take the same amount of memory as an int. long and double use twice as much as int and float. Everything else uses the same as int (including boolean, IIRC?)

Cas, what situations are there (other than JIT/Hotspot, JNI comms, and IO, perhaps?) where there's a difference under-the-cover?

NB java bytecode does *preserve* the difference (different bytecodes for whether the 32-bit number is an int or a short), so  Hotspot/JIT/etc could take advantage of this when compiling to native code. I'm not defending the book's statement, just trying to explain it. It may have been true if the book were written long enough ago to predate advanced VM's, but was always a dumb thing to put in a *book*, which tends to hand around a long time!

Games published by our own members! Check 'em out!

[swpalmer]

It's probably referring to the fact that the bytecode encodes both versions using the same number of bits; so a java byte, char, and short ALL take the same amount of memory as an int.

Huh?  Surely this isn't really the case.  Specially for arrays of primitives.  I mean maybe when they are pushed on the stack they are all pushed as multiples of the machine word size, but as they exist inside Objects I expect the sizes are respected in terms of allocated space, baring any alignment optimizations.

[Mark Thornton]

baring any alignment optimizations.

Java should have less of this than C/C++ as it doesn't have to respect the order of field declarations. So we can order our fields in a logical manner and not distort our source code merely to ensure nice packing.

[blahblahblahh]

Huh?  Surely this isn't really the case.  Specially for arrays of primitives.  I mean maybe when they are pushed on the stack they are all pushed as multiples of the machine word size, but as they exist inside Objects I expect the sizes are respected in terms of allocated space, baring any alignment optimizations.

I was only referring to basic bytecode/stack manipulation (I never played with objects-in-bytecode), and I can't remember any further details . This is what I remember from when I played around with bytecodes years ago...as I said, just trying to "invent" an explanation for what the book was claiming .

[Raghar]

It's true that memory is cheap, 4 GB is too small. I recently tried to install windoze on system with 4 MB. and it wasn't mobile phone.
Java in two semesters? How is it different from Java in two weeks, that is avilable somewhere in the Internet?
Teachers are hendayo.
There are few things that could help you in the test.



Java_g_adtest proc something:dword, somethingelse:dword, SomeInt:DWORD, SomeByte1:BYTE, SomeByte2:BYTE
     xor ebx,ebx
     mov eax,SomeInt
     mov bl,SomeByte
     add eax,ebx
     mov bl,SomeByte2
     add eax,ebx

this is JNI

Hey great success, I managed to call ASM without proxy library.

And this would check how much is necessary to store one byte. That's it, after you write that few other lines of code that are necessary to test it.

class ByteObje1{
byte byte1=0;
}

class ByteObje2{
byte byte1=0;
byte byte2=0;
}

[Jeff]

It used to be that int and long were both stored in a long, for convenience reasons, in Hotspot.  NO general book on Java should be stating this though because its a VM specific thing.

I believe bytes were really bytes, but im not 100% sure.  This is also old information (as of when I did the performance book) and may have changed...

[K.I.L.E.R]

Jeff, the book said it was for convenience reasons. It didn't mention anything about hotspots.

So in general I should use Byte over int when I can to reduce memory footprint. The book does mention that long/double take up more space in memory over int/float.

Funny book eh? It asks the reader to do the wrong thing(use int/double over byte/float) for convenience but it ends up mentioning that you are going to consume more memory by doing so.

Sometimes I wander what point the book is trying to make?

[Jeff]

The author may not have known himself what he was trying to say... it happens :/

I'd say this:  Use the most appropriate data-type to the kind of data youa re storing and then the VM will do the best it can with it.

This is a specific on a more general performacne tip. Don't look for ways to "trick" the VM.  People who do this end up just hurting themselves 99 times out of 10.  (Yes that was on purpose.)

Give the VM the best information you can about what you are trying to accomplish and then let it do its job.