To enhance messaging in a cluster, it’s important to know at runtime about how big a message is (should I prefer processing local or remote).
I could just find frameworks about estimating the object memory size based on java instrumentation. I’ve tested classmexer, which didn’t come close to the serialization size and sourceforge SizeOf.
In a small testcase, SizeOf was around 10% wrong and 10x faster than serialization. (Still transient breaks the estimation completely and since e.g. ArrayList is transient but is serialized as an Array, it’s not easy to patch SizeOf. But I could live with that)
On the other hand, 10x faster with 10% error doesn’t seem very good. Any ideas how I could do better?
Update: I also tested ObjectSize (http://sourceforge.net/projects/objectsize-java). Results seem just good for non-inheritating objects 🙁
The size a class takes at runtime doesn’t necessarily have any bearing on it’s size in memory. The example you’ve mentioned is transient fields. Other examples include when objects implement Externalizable and handle serialization themselves.
If an object implements Externalizable or provides
readObject()/writeObject()then your best bet is to serialize the object to a memory buffer to find out the size. It’s not going to be fast, but it will be accurate.If an object is using the default serialization, then you could amend SizeOf to take into account transient fields.
After serializing many of the same types of objects, you may be able to build up a “serialization profile” for that type that correlates serialized size with runtime size from SizeOf. This will allow you then to estimate the serialized size quickly (using SizeOf) and then correlate this to runtime size, to arrive at a more accurate result than that provided by SizeOf.