Memory footprint of a subclass

[Adam Warner]

Hi all,

I have a situation where I need another "colour" of a class in order to
type distinguish it from a base class. I am considering subclassing the
base class without extending its implementation. In the Sun HotSpot VM
will this result in an additional two machine word overhead compared to
the base class? Every Java object in the Sun HotSpot VM has a pointer
sized type information block and a pointer sized status field:
<www.elis.ugent.be/~kvenster/papers/cgo2006/VenstermansK_SelectiveTypedVirtualAddressing.pdf>

class BaseClass {
[fields]
public BaseClass() {}
[final methods]
}

final class SubClass extends BaseClass {
public SubClass() {}
}

The base class instantiates a fixed amount of data. In pseudocode, will
sizeof(SubClass)==sizeof(BaseClass); or
sizeof(SubClass)==sizeof(BaseClass)+8 on 32-bit platforms; or
sizeof(SubClass)==sizeof(BaseClass)+16 on 64-bit platforms?

Thanks,
Adam

 

[Chris Uppal]

I am considering subclassing the
base class without extending its implementation. In the Sun HotSpot VM
will this result in an additional two machine word overhead compared to
the base class?

No. Or rather, it's implementation dependent, but there is no sane reason why
there should be any additional overhead per object. (The extra class itself
will require a little more space, of course, but that's a fixed overhead, not
per-object.)

-- chris

 

[Adam Warner]

No. Or rather, it's implementation dependent, but there is no sane
reason why there should be any additional overhead per object. (The
extra class itself will require a little more space, of course, but
that's a fixed overhead, not per-object.)

Hi Chris! That's great news. When you say there's no sane reason I was
imagining this object layout (where superclass fields are accessed via a
pointer to the superclass):

instantiates
[subclass]------>[superclass]
points to

You're indicating that the implementation will likely lay out every
inherited field within the subclass itself. This explains why the type
information block points to the class structure instead of a superclass
instance.

Many thanks for the clarification.

Regards,
Adam

 

[Adam Warner]

No. Or rather, it's implementation dependent, but there is no sane
reason why there should be any additional overhead per object. (The
extra class itself will require a little more space, of course, but
that's a fixed overhead, not per-object.)

Hi Chris! That's great news. When you say there's no sane reason I was
imagining this object layout (where superclass fields are accessed via a
pointer to the superclass):

instantiates
[subclass]------>[superclass]
points to

You're indicating that the implementation will likely lay out every
inherited field within the subclass itself. This explains why the type
information block points to the class structure instead of a superclass
instance.

Many thanks for the clarification.

I've just come across a post from 1998 that discusses this point:
<http://groups.google.co.nz/group/comp.lang.java.programmer/msg/dddbc0fcd489ebe4?dmode=source>

An instance of class2 **IS** an instance of class1. Although not
explicitly required by the Java specs, I don't know of any Java VM that
doesn't create every object as a single chunk of memory, where that
chunk of memory is sufficiently large to hold all the data members of
all superclasses as well as the immediately declared class.

...

I think understanding how objects are laid out--as a unit rather than
as individual pieces from the various classes in the inheritance
tree--makes it easier to understand what Java is REALLY doing.

Indeed!

Regards,
Adam