Memory footprint of a subclass

Discussion in 'Java' started by Adam Warner, Feb 27, 2006.

  1. Adam Warner

    Adam Warner Guest

    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
     
    Adam Warner, Feb 27, 2006
    #1
    1. Advertising

  2. Adam Warner

    Chris Uppal Guest

    Adam Warner wrote:

    > 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
     
    Chris Uppal, Feb 27, 2006
    #2
    1. Advertising

  3. Adam Warner

    Adam Warner Guest

    On Mon, 27 Feb 2006 08:53:07 +0000, Chris Uppal wrote:
    > Adam Warner wrote:
    >
    >> 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.)


    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, Feb 27, 2006
    #3
  4. Adam Warner

    Adam Warner Guest

    On Mon, 27 Feb 2006 22:19:20 +1300, Adam Warner wrote:
    > On Mon, 27 Feb 2006 08:53:07 +0000, Chris Uppal wrote:
    >> Adam Warner wrote:
    >>
    >>> 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.)

    >
    > 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
     
    Adam Warner, Feb 27, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jstorta
    Replies:
    3
    Views:
    447
    jstorta
    Feb 20, 2006
  2. nick
    Replies:
    58
    Views:
    1,931
    Bart van Ingen Schenau
    Mar 16, 2009
  3. S.Volkov
    Replies:
    2
    Views:
    222
    S.Volkov
    Mar 12, 2006
  4. Trans
    Replies:
    8
    Views:
    324
    Robert Klemme
    Oct 23, 2008
  5. Fab

    Subclass of subclass

    Fab, Aug 9, 2012, in forum: C++
    Replies:
    0
    Views:
    397
Loading...

Share This Page