.Net Framework Inheritance memory managment, Plz Help ?

Question

An interviewer asked me this question and still i am not sure what's the proper answer of this...

Scenario :

We have Inheritance in which there is a "Base" Class and its "Child" class, Now if we instantiate Child class, its Parent/Base class is also is instantiate.

Now interviewer Asked me these questions...

interviewer : how .net framework manage Memory is this case, Does Heap contain One object or two ?

My Reply : One Object..

interviewer : if one then what space is the space it occupy ?

My Reply : Base + Child = Size of Memory.

interviewer : so if we instantiate a child class having 100 Parents in hierarchy, then Memory contain a object equal to 101 classes ...its pretty heavy..?

My Reply: Confused ! :(

Answer 1

System.IO.File is a static class. You can't instantiate it.

Answer 2

It goes only one way: System.IO.File will allocate base class of file + size of File itself, but not other descendants of the base class. So its not pretty heavy and your answer is correct.

Also, initializing a class is only done once per class, while instantiating a class will take up space per instance. So the size per initialization does not matter that much (within bounds).

Answer 3

You clearly meant the base members + derived members = total size. The interviewer sounds like he just wanted to confuse you.

That said, in a managed language things get hairy, because the implementation can do whatever it wants as long as semantics hold, and as you've noticed the semantics avoid direct pointers. If you must say something, the closest short answer is probably:

Object size =

• Type system/GC overhead (say 4-8 bytes fixed for a heap allocated object regardless of what type it is)
• +All instance fields of that type and its bases. Fields with reference types are machine-int aligned (int on 32-bit, long on 64). Structs are generally externally machine-int aligned, internal layout can vary. Not sure how it packs bool, char, and short members.

If 99 of the 100 base types of the object mentioned have no new instance fields declared, then their per-object allocation overhead is zero. You still have the fixed overhead for a type, but like I said, it's fixed.

There is some small runtime overhead for declaring a new type. Each type will require space for a type descriptor (plus a few extra things), but this doesn't affect the size of an instance of that type, and doesn't grow or shrink as you create and free objects (the GC doing the freeing here).