Re: [infinispan-dev] Cost of inheritance

On 15 November 2013 08:10, Bela Ban <bban(a)redhat.com&gt; 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev