cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Manes <ben.ma...@gmail.com>
Subject Re: Non-blocking DataRowStore - need help to test
Date Fri, 24 Feb 2012 07:50:45 GMT
>
> Very interesting. Will you be bringing the LIRS features across to
> CacheBuilder as well?


Eventually, yes. Bringing it to CacheBuilder is actually easier than CLHM,
since the segments avoid a race condition with weighted entries. There was
a recent thread on Guava about this [1]. However there isn't a rush since
we view it as a performance optimization, so users shouldn't need to be
aware of the change. When implemented, it should offer a 5-10% higher hit
rate but consume 2 extra references per entry.

[1]
http://groups.google.com/group/guava-discuss/browse_thread/thread/f92569495def1194

Also, would it be hard to limit the size of the cache in bytes rather than
> number of entries?


Sure, you can use a Weigher to do this. However as mentioned I naively
thought this wouldn't be commonly used, since no other Java caching library
offered weights. CLHM will only weigh the value, but CacheBuilder will
weigh the key and value pair.

Isn't JSR166 already finished?


Yes, but no. :-)

This JSR spans multiple JDK releases, with 166e being the current
iteration. [2]

[2] http://g.oswego.edu/dl/concurrency-interest/

On Thu, Feb 23, 2012 at 11:38 PM, Aristedes Maniatis <ari@maniatis.org>wrote:

> On 24/02/12 8:05 AM, Benjamin Manes wrote:
>
>> Hi,
>> I'm the author of CLHM, brought to you by a friendly Google alert. :)
>>
>
> Hi Ben
>
>
>  If Cayenne is currently using Guava, then there won't be a dependency
>> increase. I helped rearchitect MapMaker and design its replacement,
>> CacheBuilder, which are based on CLHM's algorithms. This is a more
>> feature-rich implementation with the support of a team at Google (whereas
>> CLHM is my weekend project). We also fixed my mistake of only weighing by
>> value, since I hadn't realized how popular memory-based weighing would be
>> (I was trying to avoid unbounded collections as values).
>>
>
> Very interesting. Will you be bringing the LIRS features across to
> CacheBuilder as well?
>
> Also, would it be hard to limit the size of the cache in bytes rather than
> number of entries?
>
>
>  Technically CLHM provides more concurrency than CacheBuilder by not
>> relying on segment locks and later using a lock-free ring buffer. These
>> will be an advantage when it is backed by JDK8's new CHM (see
>> ConcurrentHashMapV8) or Cliff Click's NBHM. A JSR-166 implementation will
>> be a marriage of CHMv8, CLHM, and CacheBuilder.
>>
>
> Isn't JSR166 already finished?
>
>
>
>  CLHM is back-ported to JDK5 on every release, so you'll find the JDK5
>> source under /tags. I do development on /trunk assuming JDK6.
>>
>> Feel free to file issues against CLHM (or Guava) if you'd like
>> enhancements to either. Both are used in large production environments.
>>
>
> Andrus, I notice that CacheBuilder can be set to concurrency=1 which means
> that write operations are sequential even though read operations are still
> concurrent. Would that help at all with the testing concern you have?
>
>
> Ari
>
>
>
>> Cheers,
>> Ben
>>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message