Terracotta Discussion Forums

I'm using ehcache 2.5 and limiting my cache by max bytes on the local heap. When looking at the size of my objects as calculated by ehcache, it was much larger than expected so I dug in a bit. It appears that the vast majority of the size was coming from a java.lang.Class instance. I see that there is some built-in logic for excluding the size of "flyweight" type objects of which Class is one. However, this seems to just exclude the size of the Class object itself, not its members. The entire object graph rooted by the Class instance was still crawled resulting in over 100k bytes for a single Class instance. It happens to be the case that this Class instance is a field on an Enum instance, which is another type considered to be "flyweight" by ehcache. Now I know I can configure ehcache to just ignore this field when calculating size, but I just thought I'd check to make sure this is the intended behavior.

Please let me know if there is any other info I can provide.

Can you provide some code sample (and maybe even a reproducible test case) ?
That would help a lot to pin point the issue... and eventually fix it, if need be.

I'm attaching a junit test that reproduces this issue. It's not to the same extent that I see in my running application, but it is still significant. The test defines a CacheKey object that has an Enum field and that Enum holds a reference to the Class instance. In my app this is the class for a domain object so I've created a stand-in for this in the unit test with the approximate number and types of fields as my actual domain object.

The key factor in reproducing the behavior is to reflectively traverse the fields of the object before calculating the size. This populates some internal caches on the Class instance which is what I believe leads to the inflated size calculation.

On my machine I get the following results:

Size without enum: 120
Size with enum before reflection: 192
Size with enum after reflection: 25240

I just ran this and get :

Size without enum: 120
Size with enum before reflection: 120
Size with enum after reflection: 120

Now, what version of Ehcache (and VM) are you running exactly. Also, and more importantly, what SizeOfEngine is your VM using ?
My test used INFO: using Agent sizeof engine, but I get consistent results with all 3 implementations. That was using the current head of trunk though...

I wonder whether you're not hitting a variant of http://jira.terracotta.org/jira/browse/EHC-909

Did you try using 2.5.2 ?

Oh, that's my fault - I was running 2.5.0. Updating to 2.5.2 does fix the issue - I get the same output you are reporting now. Sorry for the confusion and thanks for the fast response.

NP! Happy to hear the bug is already fixed ;-)