----- Original Message -----
From: "Sanne Grinovero" <sanne(a)infinispan.org>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Monday, February 6, 2012 2:56:58 PM
Subject: Re: [infinispan-dev] JBoss Libra
On 6 February 2012 14:44, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Sanne Grinovero" <sanne(a)infinispan.org>
>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
>> Sent: Saturday, February 4, 2012 10:08:16 PM
>> Subject: Re: [infinispan-dev] JBoss Libra
>>
>> On 4 February 2012 14:57, Manik Surtani <manik(a)jboss.org> wrote:
>> > This is very similar to storeAsBinary. If this is set to true,
>> > then keys and values are serialized and stored as a
>> > MarshalledValue which contains the resulting byte[]. So rather
>> > than restrict to just byte[] types, we could restrict to:
>> >
>> > * byte[] or any other primitive, primitive array or String
>> > * OR, if storeAsBinary is set to true.
>>
>> +1, the family of known sizes can be extended. We could even do a
>> recursive calculation and ask the registered Externalizer for the
>> specific type; it's unlikely we can have this information returned
>> by
>> all externalizers but many could be able to handle a fairly
>> accurate
>> estimate.
> I'm not sure I get the "family of known sizes" bit. If you have
> storeAsBinary set to true you know exactly the size the size that
> given object has in memory. Or are you refering at the situation
> whre storeAsBinary is set to false?
Yes, with storeAsBinary=false. I didn't think about the details, just
suggesting that there are many more cases in which the size can be
well known even if it's not a byte[].
For example, the Externalizer interface could provide this
information
in many cases. Maybe we could even use JBoss Libra at build time to
"weight" all internal and some other common types and fold this
information in the provided externalizers, so to take advantage of
its
capabilities but not require the annotation processor to be used by
Infinispan users.
this would work indeed at the cost of some effort from user's
side to extend and manintain the externilizers. Might cause some issues though: if the
users don't get the externalizer.size() right the memory estimate can go very wrong.
Geting the in-memory size for an object is not an simple thing to do, as per the
memory-usage presentation sent by Manik last week. On top of that an object added to the
cache might be refered by another object added to the cache, so the user must be aware of
that. IMO this approach is tricky from a support perspective.