On Mar 20, 2013, at 10:49 AM, Sanne Grinovero <[email protected]> wrote:
> Great stuff. Another benefit to keep in mind is that this can make it > easy to use equality defined as identity of objects (the "=="): > something I'm looking forward for, as with all use cases I'm familiar > with (Lucene Directory + Hibernate OGM) we should be able to maintain > uniqueness of instances per key. ^ That'd be dead easy to do. Just create an implementation of Comparing, i.e. ComparingByIdentity or something like, and pass it to as key/value Comparing function, depending at which level you wanna do the identitiy comparison, whether key or value only, or both. > You could take this a step further (maybe as a second step in future) > and break out of the ConcurrentMap contract.. we don't strictly need > that; as from previous brainstorming we can optimise certain > operations - although I don't remember if any is left as Manik already > applied some great improvements - so just to remind it doesn't have to > strictly guarantee the ConcurrentMap contract. Good point. We're certainly not obliged to keep a "ConcurrentMap" per se internally. What optimisations did you brainstorm? Would you mind creating a JIRA about this last part and assigning it to me? Cheers, > > Sanne > > > On 19 March 2013 19:56, Mircea Markus <[email protected]> wrote: >> >> On 18 Mar 2013, at 12:21, Galder Zamarreño wrote: >> >>> Hi all, >>> >>> A heads up on what is going on with >>> https://issues.jboss.org/browse/ISPN-2281 >>> >>> While discussing this, Tristan and I came to the conclusion that we could >>> avoid the need to create some wrappers required to fulfill requirements in >>> this JIRA, and as a side effect, reduce the memory consumption of >>> Infinispan servers, if we could have internal data containers based on >>> concurrent hash maps that took a custom function for equals/hashCode…etc. >>> By doing that, you could effectively have **byte[] keys and values for >>> maps**. >>> >>> By doing that, you avoid creating wrappers (yippee!) for keys (bye bye >>> ByteArrayKey), and combined with a better way to pass metadata into >>> Infinispan Caches (i.e. version) that is stored within the internal cache >>> entries, you avoid wrapper values too! (bye bye CacheValue). >> Do you plan to use Versioned*CacheValue for storing values? if so you'd >> still create a version object to be aggregated in Versioned*CacheValue. >>> >>> Doing the latter was relatively simple (I have this stashed), but having a >>> CHM that could take a byte[] as key wasn't that easy, since we can't change >>> JDK CHM. >> why's that? copyright? >>> >>> This is why, I've created a new CHM, based on the CHMv8, called >>> ComparingConcurrentHashMapv8 (thx Tristan for the name!). The work for this >>> can be seen in: >>> https://github.com/galderz/infinispan/commit/351e29d327d163ca8e941edf873f6d46b43cfae1 >> this relies on sun.misc.Unsafe, so won't work with a non-oracle JVM. >> This class would be aggregated in the DataContainer in the case we use >> infinispan in server mode, right? >>> >>> I'm sending it here so that I can get feedback early on. I've added some >>> tests as well that verify that ComparingConcurrentHashMapv8, with byte[] >>> keys and values, works as expected, and checks that the expectations are >>> opposite with JDK CHM. It also tests new function-based methods. >>> >>> To make it easier to track changes as original CHMv8 evolves, I've marked >>> all changes with a marker comment that should make it easy to apply same >>> changes in new CHMv8 versions. Plus, with the tests I've added, it can >>> easily be seen if it works as expected or not. >>> >>> Two important TODOs, which will be most likely separated into separate >>> JIRAs: >>> >>> 1. Note that TreeBin has not been modified to use custom equals/hashCode >>> functions. That is cos I need to implement a way to compare byte arrays, >>> i.e. provide equivalent logic for Comparable.compare(). >>> >>> 2. Compare memory consumption of a CHMv8 with wrapper classes for byte >>> arrays versus ComparingConcurrentHashMapv8<byte[], byte[]>. I'll do that >>> once it's closer to CR stages. Right now fulfilling requirements in >>> ISPN-2281 is more priority. >>> >>> Finally, I need to do the same thing with out BoundedConcurrentHashMap, >>> iow, provide a way to do comparison based on custom equals/hashCode. That's >>> gonna be my next task, before I get to transform Infinispan Servers to take >>> a type directly, and avoid relying on ByteArrayKey or CacheValue wrappers. >>> >>> IOW, you'll be able to say: create an Infinsipan Server that has String as >>> key and value of type X, where X is the actual data type, no metadata!! The >>> metadata (version, encoding, whatever is requried to fulfill the >>> compatibility reqs in ISPN-2281) will be passed as part of the >>> put/replace…etc (I will email this around when in place). >>> >>> Cheers, >>> -- >>> Galder Zamarreño >>> [email protected] >>> twitter.com/galderz >>> >>> Project Lead, Escalante >>> http://escalante.io >>> >>> Engineer, Infinispan >>> http://infinispan.org >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
