Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Memory footprint of a subclass

Reply
Thread Tools

Memory footprint of a subclass

 
 
Adam Warner
Guest
Posts: n/a
 
      02-27-2006
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
 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      02-27-2006
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


 
Reply With Quote
 
 
 
 
Adam Warner
Guest
Posts: n/a
 
      02-27-2006
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
 
Reply With Quote
 
Adam Warner
Guest
Posts: n/a
 
      02-27-2006
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Subclass of subclass Fab C++ 0 08-09-2012 09:54 AM
Using virtual memory and/or disk to save reduce memory footprint nick C++ 58 03-16-2009 01:08 PM
subclass a class in the namespace of the that subclass Trans Ruby 8 10-23-2008 07:24 AM
String subclass method returns subclass - bug or feature? S.Volkov Ruby 2 03-12-2006 06:46 PM
subclass has a variable that is subclass of same superclass jstorta Java 3 02-20-2006 08:42 PM



Advertisments