[infinispan-dev] Cost of inheritance

[Sanne Grinovero]

For those looking to use java-object-layout:

it's not longer on GitHub but contributed to OpenJDK:
  http://openjdk.java.net/projects/code-tools/jol/

The author, Aleksey Shipilev, was so nice to get in touch with me to
let us know that the version in OpenJDK has many bugs fixed so better
used that.

Sanne


On 15 November 2013 12:16, Sanne Grinovero <sanne at infinispan.org> wrote:
> On 15 November 2013 08:10, Bela Ban <bban at redhat.com> wrote:
>> 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...
>
> Seems I was lucky to read that same post a long time ago, and forking
> the repository for the tool:
> https://github.com/Sanne/java-object-layout
>
>
>> 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)
>
> nice!
>
> Sanne
>
>>
>> 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)
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev