weights as long

[GoogleCodeExporter]

Currently weights are ints instead of longs.  This causes problems if objects 
have large weights (such as in bytes).  A simple work around is to divide the 
byte-weight by some constant, but that breaks down for small values.  Is there 
an advantage to weights being ints?

Original issue reported on code.google.com by chris.bu...@gmail.com on 26 Oct 2011 at 4:28

[GoogleCodeExporter]

There were a few reasons...

A long takes more memory per entry (64-bit), which wouldn't be preferred in the 
common cases. In a singleton weigher cache (entry = 1), the weight field is 
still retained so the memory could appear to be wasted. It can't be magically 
removed by different entry classes in CLHM, because the implementation encodes 
the entry's status into the weight to avoid locking. This is not the case in 
the Guava port which may make different trade-offs.

Originally I expected that the common case would be weighing of collections and 
memory usage would be rare. This resulted in an API mistake of not including 
the key parameter to the weigher (fixed in the Guava port). Therefore the trick 
of changing from bytes to kilobytes seemed reasonable, and probably still is 
okay in most cases. 

At the time I wasn't sure how it would play with Map.size() which restricts all 
maps to an Integer.MAX_VALUE size. If a singleton weigher was chosen and the 
maximum weighted size > MAX_VALUE, the characteristics of the underlying 
hashmap might be unknown if reached. If it silently discarded entries then it 
could create a bug in the decorator. So it appeared better to be safe than 
sorry.

I'm hesitant to say that longs are correct, but it has come up a few times. As 
this project is fed into Guava as enhancements, such issues are discussed and 
decided by a larger group. When weights are finalized in Guava then better 
answer can be provided for why we decided one way or another. That is then a 
feeder into a JSR-166 implementation which is still in early discussion phase, 
but would be discussed openly on the concurrency-interest group.

In short, I don't expect to make the change in CLHM but it might appear in ones 
of its decedents.

Original comment by Ben.Manes@gmail.com on 27 Oct 2011 at 2:57

[GoogleCodeExporter]

Fixed in v1.3. I plan on releasing this tonight.

Also introduced EntryWeigher<K, V> to allow key/value weighing. We fixed this 
oversight in Guava's CacheBuilder from the get-go.

The weight of an entry are still an integer, but the maximum weight of the 
cache is now a long. Let me know if this isn't acceptable. A max of 2GB per 
entry, if in bytes, seems acceptable.

Original comment by Ben.Manes@gmail.com on 8 May 2012 at 9:41

• Changed state: Fixed