I believe that object reference variables must be at least 32 bit, but on a 64 bit implementation, an object reference variable could be 64 bit. The implies that on a 32 bit implementation of Java, there would be a limit of two-to-the-32nd-power (about 8 billion) number of objects, yet in an implementation of Java that uses 64-bits for object reference variables, the limit of the number of active objects is the astronomical number of 2-to-the-64th-power (18,446,744,074,000,000,000) active objects.
Also, in Java, an int is a signed integer with 32 bits of precision, but on a 64-bit implementation, an int can be implemented as a 64 bit register or memory location with the upper 32-bits being unused.
So why waste the space? Why use 64-bits when the upper 32-bits can't be used. The answer is that It could be faster to use the naturual word-size of 64 bits on a 64 bit processor.
In C and C++, both the actual size and the usable range of an int could vary. In C/C++ the only guarantee was that a short was no bigger than an int, and an int was no bigger than a long.in one operation.
In Java, however, with an int., the range must be the same. From negative 2 to the 31st power to positive two to the 31st power. So, in Java, the range is always the same regardless of the number of bits that the processor can process
There is no ]sizeof operator in Java. But the useable size is always the same:
1. byte 8-bits 2. short 16-bits 3. int 32-bits 4. long 64-bits
I believe that you could serialize and object and see how much disk space it would take or how much space it would take to transfer over a network. This would be the useable size that would be the same on all Java implementations, but keep in mind that the size in RAM could be more.
In Java, there is, by design, no way to find out the size of any variable/field in memory. Why do you think you need to know this? In Java, you very, very rarely need this information. Are you an ex C/C++ programmer?!
The size of serialised data has little relation to the amount of memory used to store the same data.
You can find out, simply by reading the Language Specification, how many usable bits are included in each data type (except references). For instance, "int" has 32 usable bits. But this does not equal the number of bits actually used in memory.
If you really need to know, there are some hacky ways of estimating the memory used. But I'd first want to be convinced you really need this information.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Joined: Jun 01, 2007
Hello Peter, I do not know how to convinced you,but i am genuinely interested to know each and every thing related to java ,even if it basic thing or a so called "tricky" thing..."to be the best in any thing you should know everything " so please do me a favor and tell me how to retrieve size of object... as well as one more thing i want to ask is can we set heap size in java,i was trying to do that using command prompt as"java maxheap <size>",i have tried a lot of option like setmaxheap,heapmax and stuff.. but i was not successful. so now i hope you will definitely going to help me. thanks in advance shivangi...
[Shivangi Joshi]: I do not know how to convinced you,but i am genuinely interested to know each and every thing related to java ,even if it basic thing or a so called "tricky" thing..."to be the best in any thing you should know everything "
Yes, well, some priortization is still in order. Some things are more important than others. Did you notice that Marc posted a link to a nice long aritcle for you? If that's not enough for you, in the past I have estimated object sizes by creating a large number of identical objects in the JVM, and measuring the memory usage using Runtime.getRuntime().totalMemory() and Runtime.getRuntime().freeMemory(). To do this right, you need to run System.gc() many times before you measure the memory usage. I usually run it ten times in a row to be really sure. For fun, try measuring how much memory is freed on each pass. (This is easy using the java -verbose:gc option.) The values returned by freeMemory() and totalMemory() are approximations, but if you create thousands of identical objects, you can get a good estimate of the size of an individual object.
In the past I tried this for various types of objects, and was able to infer some rules about the sizes of objects based on their class definitions. To be honest, I don't really remember these now, because it really doesn't matter very much. And this sort of information can change from one JDK release to another anyway. If I need the info in the future, I will measure it again. Until then though, I am content to not worry about it any more.
"I'm not back." - Bill Harding, Twister
Joined: Jun 01, 2007
Jim Thanks for suggesting me a way,but i have already tried out that one.... i want to know any other fast method,which does not require to create a lots of objects and do the stuff...so can you suggest something different...... thanks in advance