[infinispan-dev] Cost of inheritance

[Bela Ban]

Excellent idea of moving fields between parent/sub classes !
Which tool did you use to dump the layout of a class ? Following Shane's 
ref, "Java Object Layout" has been moved...

I'd like to take a look at some JGroups classes and see if I can reorder 
fields (although I don't use a lot of inheritance)

On 11/14/13 10:18 PM, Sanne Grinovero wrote:
> In a particular benchmark I'm running, the bottleneck of my system
> seems to be the object allocation rate.
>
> More specifically, in just some minutes I've got about 55GB allocated
> just of instances of SingleKeyNonTxInvocationContext
> (yes I literally mean GigaBytes)
>
> and 45GB of org.infinispan.commands.read.GetKeyValueCommand.
>
> To be clear: these high amounts are caused only by the "shallow" class
> instance of these two types, not counting key nor value sizes being
> actually moved into/out Infinispan.
> Of course it means we're talking about many of these instances, but
> also the size of each of them matters, so I've been taking a look at
> their definitions.
>
> Running 64-bit HotSpot VM.
> Using compressed references with 3-bit shift.
> Objects are 8 bytes aligned.
>
> # org.infinispan.context.SingleKeyNonTxInvocationContext
>
>   offset  size          type description
>        0    12            (assumed to be the object header + first
> field alignment)
>       12     1            byte AbstractInvocationContext.contextFlags
>       13     3            (alignment/padding gap)
>       16     4            Address AbstractInvocationContext.origin
>       20     4            WeakReference AbstractInvocationContext.classLoader
>       24     1            boolean SingleKeyNonTxInvocationContext.isOriginLocal
>       25     1            boolean SingleKeyNonTxInvocationContext.isLocked
>       26     2            (alignment/padding gap)
>       28     4            Object SingleKeyNonTxInvocationContext.key
>       32     4            CacheEntry SingleKeyNonTxInvocationContext.cacheEntry
>       36     4            (loss due to the next object alignment)
>       40            (object boundary, size estimate)
>
> I notice two things in here:
>   a) we could refactor maybe some code to have less fields in such a
> hot allocated type
>   b) Lots of space is being wasted in padding!
>
> If you count the bytes lost because of the various alignment rules: 9
> That's almost 25%, about 13GB of used memory!
>
> Why are there two separate object alignment gaps? That's because the
> fields of the parent class need to be grouped, then the child class's
> fields are aligned after it.
> In other words, if I move the fields from the parent class to the
> bottom class I get:
>
> org.infinispan.context.SingleKeyNonTxInvocationContext
>   offset  size        type description
>        0    12            (assumed to be the object header + first
> field alignment)
>       12     1            byte SingleKeyNonTxInvocationContext.contextFlags
>       13     1            boolean SingleKeyNonTxInvocationContext.isOriginLocal
>       14     1            boolean SingleKeyNonTxInvocationContext.isLocked
>       15     1            (alignment/padding gap)
>       16     4            Address SingleKeyNonTxInvocationContext.origin
>       20     4            ClassLoader SingleKeyNonTxInvocationContext.classLoader
>       24     4            Object SingleKeyNonTxInvocationContext.key
>       28     4            CacheEntry SingleKeyNonTxInvocationContext.cacheEntry
>       32               (object boundary, size estimate)
>
> which recovers 20% ..
>
> Looking forward to see simpler class hierarchies in the code ;-)
>
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)