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.
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. 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
