ConCurrentLinkedHashMap

[Noble]

Do we have any datastructure that can be used as a ThreadSafe version
of LinkedHashMap? The problem with LinkedHashMap is that both get()
and put() have to be synchronized which is too expensive for
implementing an Cache which evicts LRU objects

[Jared Levy]

We don't have a class of that sort.

[kevin bourrillion]

Have you confirmed that contention for your synchronized LHM is actually a bottleneck in practice?

I'm not aware if anyone's come up with a good solution for a concurrent LRU cache.  It's certainly nonobvious how it would be done.  Can you use soft references (say, with our ReferenceMap) instead?

On Mon, Jul 28, 2008 at 11:38 AM, Noble <noble...@gmail.com> wrote:

--
Kevin Bourrillion @ Google
internal: go/javalibraries
google-collections.googlecode.com
google-guice.googlecode.com

[Noble]

We have a very heavily hit cache so this has turned out to be a huge
bottleneck in our usecase.

SoftRerence is not relevant here I guess

On Jul 29, 12:09 am, "kevin bourrillion" <kev...@google.com> wrote:
> Have you confirmed that contention for your synchronized LHM is actually a
> bottleneck in practice?
>
> I'm not aware if anyone's come up with a good solution for a concurrent LRU
> cache.  It's certainly nonobvious how it would be done.  Can you use soft
> references (say, with our ReferenceMap) instead?
>

[Noble]

I have written a ConcurrentLRUCache for our own purposes using
ConcurrentHashMap.I can contribute it here if needed

[Jared Levy]

Thanks for the offer!

We already have a caching library, which includes multiple LRU caches,
in Google's internal code base. We may open-source that library at
some point, but we don't have any plans to do so. Before accepting any
contributions, we should clean up and release our current caching
code.

Jared

[Jed Wesley-Smith]

On Aug 20, 7:56 am, "Jared Levy" <jared.l.l...@gmail.com> wrote:
> We already have a caching library, which includes multiple LRU caches,
> in Google's internal code base. We may open-source that library at
> some point, but we don't have any plans to do so. Before accepting any
> contributions, we should clean up and release our current caching
> code.

Erm, you're comments are a bit contradictory. You don't plan to
release your caching libs and you won't accept any contributions as
you already have internal versions. That is all well and good for
Google projects I guess.

Noble, I for one would be very interested in your ConcurrentLRUCache.
I have written a version of one myself, but I haven't had enough time
to write a comprehensive test suite for it - and to be honest I am not
that happy with it atm. If GCollect isn't the place for it, maybe
consider another OS project such as Commons Collections?

cheers,
jed.

[Noble]

I guess commons collections use java 1.4 mine works only on java 5

On Aug 20, 7:24 am, Jed Wesley-Smith <jed.wesleysm...@gmail.com>
wrote:

[Noble]

I guess commons collections use java 1.4 mine works only on java 5

On Aug 20, 7:24 am, Jed Wesley-Smith <jed.wesleysm...@gmail.com>
wrote:

[Jared Levy]

Jed, I understand your frustration. Google has some libraries that
would be useful to you, but we're aren't making them publicly
available.

There's a lot of stuff we'd like to open-source, if we ever find the
time. Sorry about the inconvenience.

Jared

[Jed Wesley-Smith]

Hi, Jared.

On 21/08/2008, at 6:06 AM, Jared Levy wrote:

> Jed, I understand your frustration. Google has some libraries that
> would be useful to you, but we're aren't making them publicly
> available.

Understand that, I am certainly not under the impression that Google
would or should use gcoll to open source everything you have - as
attractive as that may be for us :-)

The frustration is that something difficult that seems a good fit for
gcoll like a an LRU ConcurrentMap would not even be considered (I
haven't seen the implementation so I have no opinion on its quality).
The other frustration is I have a clear an pressing need for such a
beast right now ;-)

> There's a lot of stuff we'd like to open-source, if we ever find the
> time. Sorry about the inconvenience.

S'orright, thanks for the reply.

cheers,
jed.