[infinispan-dev] JBoss Libra

[Mircea Markus]

----- Original Message -----
> From: "Sanne Grinovero" <sanne at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at 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 at redhat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Sanne Grinovero" <sanne at infinispan.org>
> >> To: "infinispan -Dev List" <infinispan-dev at 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 at 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.