On Aug 24, 1:50 pm, molesky...@yahoo.com wrote:

That is never the way to get object's in-memory size. What if the
class declares all the fields as transient?

The output you pasted indicates that one or more of the attributes in
the class that you serialized are non-serializable (do not implement
java.io.Serializable).

-cheers,
Manish

dump the stream to a file and have a look at it with a hex editor. A
Serialized stream has quite a bit of overhead for the first object,
namely the fully qualified names of all the types of all the fields
used and the field names. Try dumping several objects and compare the
streams. You will see the incremental size is quite reasonable.
Further, you normally GZIP these streams. They compact nicely.  See
http://mindprod.com/applet/fileio.html
for sample code.

Further objects pointed to and their descriptors go in the stream too.
Often much more crud that you imagine gets dragged along.  Check it
out with a hex editor to make sure you have not inadvertently dragged
along the kitchen sink.

Correct.

Try something like:

public class SizeOf2 {
    private final static int N = 1000000;
    public static long mem() {
        System.gc();
        Runtime rt = Runtime.getRuntime();
        return rt.totalMemory() - rt.freeMemory();
    }
    public static void main(String[] args) {
        long m1 = mem();
        int[] ia = new int[N];
        long m2 = mem();
        System.out.println("sizeof int = " + (m2 - m1)*1.0/N);
    ia = null;
        long m3 = mem();
        double[] xa = new double[N];
        long m4 = mem();
        System.out.println("sizeof double = " + (m4 - m3)*1.0/N);
    xa = null;
    }
}

Arne

On Aug 25, 1:50 am, molesky...@yahoo.com wrote:

First of all, what is meant by Object's size? This is not C/ C++. In
C, C++ the object size is calculated by summing up the member
variables. But, in java, it depends on implementation. For example,
the java language specification just says that the boolean should take
either 'true' or 'false'. But, it doesnt force any constraints on the
implementation like, the boolean size should be 1 or 10 bytes. Some
implementation might represent a boolean variable in 1 single byte.
Some other implementation may represent the boolean varibale in 2
bytes or more. So, size is all about implementation specific.

One more thing, the 'Object Construction' is also implementation
specific. Assume, you declare 5 integers in a serialized class. So,
you think that the object instance size for the class will be (5 * 4)
20 bytes. But, that cant be the case always. Because, jvm might add
some internal fields to represent the 'serialized' feature. Or it
might do some trick over constructing the particular instance. So, no
guarantee that your measured 'size' will be accurate.

I would suggest not to talk about *size* in java. Talk about memory.

--
Manivannan Palanichamy (@) Oracle.com
http://mani.gw.googlepages.com/index.html

On Aug 24, 4:50 pm, molesky...@yahoo.com wrote:

This has all kinds of problems.

First, objects may be larger in memory than serialized, due to
transient fields. As others noted, measuring size in memory is best
done by something like

Runtime rt = Runtime.getRuntime();
System.gc();
int usage = rt.totalMemory() - rt.freeMemory();
MyObject myObject = new MyObject(args);
System.gc();
int size = rt.totalMemory() - rt.freeMemory() - usage;

This still will vary from VM to VM, and may not work perfectly
(System.gc() doesn't guarantee the gc runs, so it can err high if
transient objects are made and discarded by the MyObject constructor
and the second System.gc() does nothing, and it can err low if the
first System.gc() does nothing and the second does and collects some
garbage).

Measuring the size of serialized objects can be done more reliably,
since for an identical object it will be identical on all platforms
given the same version of the object's class. It may vary from
instance to instance depending on what objects it references or
contains via its member variables though. Still it will give you an
idea of how much disk space or bandwidth serialized instances will
consume in bulk.

But serialized output contains overhead; this will be most of your 637
bytes. I'd serialize an N-element array of MyObjects and an N+1-
element array of MyObjects, both with every array cell containing a
MyObject (rather than null), and look at the difference in their file
sizes. I'd make the fields that would tend to reference shared objects
reference a single instance from all these MyObjects so that their
referents "don't count" in the final calculation, and the fields that
would tend to reference "owned" objects or "contained" ones reference
separate ones for each instance so that their referents do count. This
will give the best idea of scaling behavior when a large number of
MyObjects are serialized on a single stream. Your original figure of
637 bytes is, on the other hand, unfortunately exactly what you can
expect if each one is serialized on a separate stream.

Note that the suggested method of measurement should end up summing
the MyObject size as the size of its fields, with fields of reference
type being the size of a pointer or some equivalent, plus the size of
the objects an instance references with such fields and actually
"owns".

see http://mindprod.com/jgloss/sizeof.html