te/17/2010 2:40 PM, Mehul Sanghvi wrote:
What you are asking for is something that is equivalent to doing a
printf ("size of int = %i\n", sizeof(int)) ;
in C.
I don't believe that is possible in Java for a class. I don't believe
it is possible even in pure OO language like Smalltalk.
For Java SE version 7 one API that was considered for inclusion was an
Object.sizeof(Object) method. For a primitive type like a local variable
or an object field containing a scalar, or even an array of scalars,
array of arrays of scalars, etc, it would have behaved just like the
familiar C/C++ sizeof function by simply leveraging autoboxing.
For object references there was a debate about whether the size of a
referenced object should be returned without "following" object
references contained in the object, or whether it should be a transitive
closure of all the objects referenced in the given object:: in other
words a traversal of the complete graph of objects hanging off the one
passed to sizeof.
One slightly messy detail with this is avoiding multiple counts of the
same object. For example, with. three refs to the same object the total
size would include the three references (pointers), but only one total
from sizeof applied to the singleton object alll three references
pointed to. That was easy enough to deal with. A much more worrisome
issue is the notion that the graph of objects can easily be changing, so
you can't begin to say the results are accurate and you might not even
be able to succeed with the traversal if you don't "stop the world" and
prevent the entire graph from being mutated while the traversal and size
calculation is going on. This gets real nasty real fast and leads to all
manner of terrible scenarios of program misbehavior, as well as the need
for magical locking mechanisms that don't exist in Java. It's possible
with some collectors to shut off everything and guarantee no space will
be reclaimed out from under the traversal and measurement. But I'm not
aware of a scheme that tells the JVM to hold off modifying fields,
instantiating new objects, etc one step behind or one step ahead of the
traversal thread. And apart from not producing a meaningful result, the
traversal itself could "go off into the weeds" because of race
conditions, such as when a traversal is popping back to the next field
of an object except that object is no longer referenced by the program:
the sizeof API is holding a reference and keeping it alive but the right
thing to do would be to trim that whole object and the graph below it
from the results. But how to know the program has made the object
unreferenced? Or for cases where objects that were involved with the
API's implementation got involved the choice might simply be between
getting something approximate or risking deadlocking the measurement by
trying to stop mutation (that is required to make forward progress).
Managing these cases and properly cleaning up afterward in this case is
nontrivial.
In the end it was found that a prototype implementation that did the
traversal in a straight forward manner an ignored the scary
possibilities would give good results 98% of the time and complete
garbage results the other 2% of the time. I recall it was maybe 100
lines of code relying on reflection and recursion with only a little
magic such as "fixed object overhead for this kind of object shall be 16
bytes before the field sizes are tallied." This was about as good as it
would get without driving the implementation into the JVM and putting up
with extremely obtrusive behavior for the corner cases while avoiding
sabotaging the program behavior.
Then another group declared that this was obviously a monitoring and
management API and that it should not be in java.lang or the like. That
took it out of my hands. But this minor turf skuffle was overshadowed
by fact that the usefulness of the feature simply didn't justify the
complexity and unpleasant corner cases, let alone the extra cleverness
required to make it reliable. This was Spring of 2008 and staff levels
were imploding, so it was an easy call fo the M&M folks to put this work
into limbo. But I haven't talked to them in a long time: maybe the
original "just one level" object sizing approach was taken.
Some IDEs provide memory monitoring tools that should satisfy many
curiosity issues. And these IDES often allow you to trigger measurements
at meaninful times so you can get to the bottom of the frequent
question:: I know I'm leaking memory, but how and where?
-Pete
On Thu, Jun 17, 2010 at 13:20, Shiv Shankar<mca.shivshan...@gmail.com> wrote:
In that case compiler will embed its own constructor and class Object and
its implementing interfaces variables (if any) will also inherited. So on
the basis of .class file we can not find the size. Correct me if I am wrong.
On 6/17/2010 10:27 PM, Dainis Brjuhoveckis wrote:
Have you tried to create such class and compile it and then see the size of
resulting .class file? :-)
On Thu, Jun 17, 2010 at 7:24 PM, Shiv Shankar<mca.shivshan...@gmail.com>
wrote:
Hi everyone,
This look like silly questions, but I am confused and asking this
questions. "What is size of an empty class ? ".
We know in C/C++ its one byte. In java as there is no empty class (Object
class inherited automatically), what will be the size of class if I am not
providing any code in the class definition.
--
With Regards,
Shiv Shankar
--
To post to this group, send email to
javaprogrammingwithpassion@googlegroups.com
To unsubscribe from this group, send email to
javaprogrammingwithpassion+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaprogrammingwithpassion?hl=en
--
With Regards,
Shiv Shankar
--
To post to this group, send email to
javaprogrammingwithpassion@googlegroups.com
To unsubscribe from this group, send email to
javaprogrammingwithpassion+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaprogrammingwithpassion?hl=en
--
To post to this group, send email to javaprogrammingwithpassion@googlegroups.com
To unsubscribe from this group, send email to
javaprogrammingwithpassion+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaprogrammingwithpassion?hl=en
