Why not. Only doubt I'd have is that other usages of the CHM are - I guess - services registry and similar configuration tools, for which write performance is irrelevant: your test measured puts, are there drawbacks on gets or memory usage?
Recently you changed all (most?) CHM creations to use a consistent factory, maybe we could improve on that by actually using a couple of factories which differentiate on the intended usage of the CHM: for example some maps who change very infrequently - mostly during boot or reconfiguration, maybe even topology change - could be better served by a non concurrent structure using copy-on-wrtite. Sanne On 19 Apr 2013 08:48, "Dan Berindei" <[email protected]> wrote: > +1 to make CHMv8 the default on JDK6 and JDK7 > > But I'm not convinced we should make it the default for JDK8 - even though > we don't know exactly what we're getting with the JDK's implementation. > > > On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd <[email protected]>wrote: > >> On 04/18/2013 09:35 PM, Manik Surtani wrote: >> > Guys, >> > >> > Based on some recent micro benchmarks I've been doing, I've seen: >> > >> > MapStressTest configuration: capacity 100000, test running time 60 >> seconds >> > Testing mixed read/write performance with capacity 100,000, keys >> 300,000, concurrency level 32, threads 12, read:write ratio 0:1 >> > Container CHM Ops/s 21,165,771.67 Gets/s 0.00 Puts/s >> 21,165,771.67 HitRatio 100.00 Size 262,682 stdDev 77,540.73 >> > Container CHMV8 Ops/s 33,513,807.09 Gets/s 0.00 Puts/s >> 33,513,807.09 HitRatio 100.00 Size 262,682 stdDev 77,540.73 >> > >> > So under high concurrency (12 threads, on my workstation with 12 >> hardware threads - so all threads are always working), we see that >> Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM >> implementation when doing puts. >> > >> > We use a fair number of CHMs all over Infinispan's codebase. By >> default, these are all JDK-provided CHMs. But we have the option to switch >> to our CHMv8 implementation by passing in >> -Dinfinispan.unsafe.allow_jdk8_chm=true. >> > >> > The question is, should this be the default? Thoughts, opinions? >> >> The JDK's concurrency code - especially CHM - changes all the time. >> You'd be very well-served, in my opinion, to go with something like >> CHMv8 just because you could be so much more sure that you'll have more >> consistent (and possibly better, but definitely more consistent) >> performance across all JVMs, instead of being at the mercy of whatever >> particular implementation happens to run on whatever JVM. >> >> >> -- >> - DML >> _______________________________________________ >> 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 >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
