Closed GoogleCodeExporter closed 9 years ago
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
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
Original issue reported on code.google.com by
chris.bu...@gmail.com
on 26 Oct 2011 at 4:28