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

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