 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2006sizeof in java
Hi friends, i have one doubt. java does not have sizeof(). so how can i know the size of the objects in java. thanks Although the need to know the memory size of objects in java is never really needed, following article shows a way to find it: http://martin.nobilitas.com/java/sizeof.html Bart > Hi friends, > > i have one doubt. java does not have sizeof(). so how can i know the > size of the objects in java. > > thanks Why do you need to know? You certainly don't need to know, so that you can allocate enough storage space for them, as this is done for you by the JVM. > > Hi friends, > > > > i have one doubt. java does not have sizeof(). so how can i know the > > size of the objects in java. > > > > thanks Just add up the size of the primitive variables that make up the object. ST >>> Hi friends, >>> [quoted text clipped - 6 lines] > > ST which in no way gives the size of the object. >>>> Hi friends, >>>> [quoted text clipped - 8 lines] > > which in no way gives the size of the object. It's pretty close - just add 8 bytes for the object itself. Mark Hi Mark, >>> Just add up the size of the primitive variables that make up the object. >> >> which in no way gives the size of the object. > > It's pretty close - just add 8 bytes for the object itself. So, the size of an ArrayList is about 16 bytes (8 bytes for the reference to the array and 8 byte for the object itself plus a few bytes for some other members)? It all depends if you want to know the flat or the deep size or (most commonly) something between this (see my posting in cljh). Ciao, Ingo > Hi Mark, > [quoted text clipped - 14 lines] > Ciao, > Ingo I'm not sure what you mean by 'deep'. If the object contains anything other than primitives, then you can still calculate the size allowing 4 bytes for each reference. The size of the objects referenced is irrelevant, as they are not contained within the source object. Or am I missing something here? Mark Hi, > I'm not sure what you mean by 'deep'. ... > Or am I missing something here? Then, obviously, you are in deed missing something here...: > If the object contains anything > other than primitives, then you can still calculate the size allowing > 4 bytes for each reference. The size of the objects referenced is > irrelevant, as they are not contained within the source object. Who sais that it is irrelevant? If you are e.g. implementing a cache, then it is *very* important, how large the 'deep size' (*) of your objects are. (*) Note that in many cases, neither the flat size nor the deep size is interesting, but something in between - see my posting in cljh! Ciao, Ingo > > If the object contains anything > > other than primitives, then you can still calculate the size allowing [quoted text clipped - 4 lines] > then it is *very* important, how large the 'deep size' (*) of your > objects are. not to mention that the size of a reference is not guaranteed to be 4 bytes >> > If the object contains anything >> > other than primitives, then you can still calculate the size [quoted text clipped - 7 lines] > > not to mention that the size of a reference is not guaranteed to be 4 bytes yep - which is why this whole thread is a red herring for the op. > Hi, > [quoted text clipped - 11 lines] > then it is *very* important, how large the 'deep size' (*) of your > objects are. If that is the case, you're *not* interested in the size of the object, but the total size of a number of objects. The fact remains that the size of a particular object has nothing to do with the sizes of any objects it may reference. But I do understand now what you meant by the 'deep' size - the size of the object and the sum of the sizes of objects that it references. It was just the odd use of object size that confused me. > (*) Note that in many cases, neither the flat size nor the deep size is > interesting, but something in between - see my posting in cljh! > > Ciao, > Ingo Thanks Mark > If that is the case, you're *not* interested in the size of the object, > but the total size of a number of objects. The fact remains that the > size of a particular object has nothing to do with the sizes of any > objects it may reference. Indeed. Much of this thread has very little to do with the originally stated desire to have something like a Java version of C's sizeof operator. C's sizeof operator, or anything like it in Java, is completely inappropriate for the kinds of problems being discussed here. So the problem is that it's unclear what should or should not be included in an object's "size". The article I mentioned earlier goes into all the options in some detail.  Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Hi, > If that is the case, you're *not* interested in the size of the object, > but the total size of a number of objects. The fact remains that the > size of a particular object has nothing to do with the sizes of any > objects it may reference. Depends on the definition of "size" (see below). > But I do understand now what you meant by the > 'deep' size - the size of the object and the sum of the sizes of objects > that it references. It was just the odd use of object size that > confused me. Well, I know for a fact that there the terms "deep copy" and "flat copy / shallow copy" are well defined and quite common. Also, the terms of "deep equality" and "flat equality" are well-defined and common. So, I thought, that "deep size" and "flat size" would be also well-known and common terms. Ciao, Ingo > Well, I know for a fact that there the terms "deep copy" and "flat copy > / shallow copy" are well defined and quite common. Also, the terms of > "deep equality" and "flat equality" are well-defined and common. So, I > thought, that "deep size" and "flat size" would be also well-known and > common terms. FWIW, I found the term completely transparent. (Of course, that doesn't mean there aren't problems with the /concept/ ;-) -- chris > It's pretty close - just add 8 bytes for the object itself. Or 12 if its an array. Or more than that if you're running on a 64-bit JVM :-( And if you are attempting to understand your overall memory consumption, then remember that the GCed heap requires extra space to work (how much extra depends on the algorithm, which in turn depends on the implementation, and probably also on which generation your objects reside in). And too, the habit of the JVM of reserving address space without actually consuming real RAM -- which may give misleading numbers depending on how you monitor the memory usage). Still, the add-everything-up-then-add-8 (or 12) approach can be very useful as a starting point. You may have to adjust the details to match the JVM you are using, but that works for Sun's current 32-bit JVMs. -- chris > i have one doubt. java does not have sizeof(). so how can i know the > size of the objects in java. With Java 5 you can use java.lang.instrument.Instrumentation getObjectSize() API for that. You can also use this API to compute something else you think is an "object size". See example there: http://tinyurl.com/hfzzu Regards, piotr I was thinking of serializing the object and then checking the size of the object ,ie, thet size of the byte array , will give you deep size but i think adding 8 byte is still good option. > Hi friends, > > i have one doubt. java does not have sizeof(). so how can i know the > size of the objects in java. http://riters.com/JINX/index.cgi/Size_20of_20an_20Object Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >i have one doubt. java does not have sizeof(). so how can i know the >size of the objects in java. Objects don't have a size. Hiding the internal representation from you is part of platform independence. They have a size when you serialised them. You could estimate it with perhaps 16 bytes overhead per object 4 bytes per reference 4 bytes per int 8 bytes per long 8 bytes per double etc. see http://mindprod.com/jgloss/primitive.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Wed, 19 Apr 2006 18:16:05 GMT, Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or indirectly quoted someone who said : >>i have one doubt. java does not have sizeof(). so how can i know the >>size of the objects in java. [quoted text clipped - 10 lines] >8 bytes per double >etc. But even if you do that, it does not account for possible alignment pad bytes. The JVM is free to align internally any way it wants. You can estimate by allocating objects and watching memory use. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >i have one doubt. java does not have sizeof(). so how can i know the >size of the objects in java. see http://mindprod.com/jgloss/sizeof.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.