On 4 February 2012 14:57, Manik Surtani <ma...@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. Precision is more important when allocating buffers for network & co, so if we enrich the Externalizer API to provide such information it would be handy to know as well if it's going to be an estimate or a precise size of serialized form, considering as well that serialized size isn't necessarily going to match the runtime memory cost. > > The tricky part will be to get this to work with Vladimir's LIRS container > which works on number of entries. :) Vladimir? > > Cheers > Manik > > On 3 Feb 2012, at 18:14, Sanne Grinovero wrote: > >> New idea: what about implementing a memory-size based eviction policy >> which only works on values of type byte[] ? >> >> The limitation might be strong, but actually applies quite well to >> some use cases: >> - Hot Rod >> - Lucene >> >> I think this could serve well more use cases, and specifically for >> Lucene it would rock, as besides from some small metadata, the bulk of >> stuff is big arrays of bytes. >> >> -- Sanne >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > ma...@jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev