Question: Are you aware of JCTools? about caffeine

[ben-manes]

Hi Nitsan,

It would be nice to bounce ideas, but I think the projects have different intents. I've read your blog and more recently used JCTools comparatively to check for performance lapses in my algorithms. I may have misread your project's goals, as I took the lack of documentation and minimal test suite as indicating it is a library for experimenting and demonstrating ideas.

This project is an outgrowth of my previous caching libraries (Guava, CLHM). The broadening to include collections is generalizing algorithms that I had explored for cache internals. For example 3.5yrs ago I wrote the original version of SingleConsumerQueue when exploring ways to improve write performance and talking with @plokhotnyuk who was trying to improve Akka's mailbox implementation. I wrote the EliminationStack as a favor to @jbellis, who wanted alternative ideas for solving a Cassandra performance bug. Internally the cache uses a ring buffer with an adaption of Striped64 resizing, and I haven't decided if any of that should be made reusable.

My experience working on Guava taught me to be very API conservative. I think JCTools will have a broader bag of data structures to choose from, whereas Caffeine will focus more on maximizing the power-to-weight ratio. Caffeine will be much more narrow like how Guava originally was, perhaps not venturing very far from its caching roots.

I see our two projects as very different, but a great opportunity explore ideas together.

[nitsanw]

Q: "I'd be interested in hearing your feedback"
A: "I took the lack of documentation and minimal test suite as indicating it is a library for experimenting and demonstrating ideas."
Thanks!
The test suite is indeed minimal, but covers most of the relevant API and I'm happy to say I've had no complaints on the released version (the state of the master branch is at times experimental).
The documentation is lacking in places, but the many of the classes have a good javadoc I think. In any case, I'm always happy to fix shortcomings as they are pointed out to me, so please file issues where you see fit. The main data structure JCTools makes available at the moment is Queue and that is a well understood API.
I'm aware to date of a few big projects using JCTools(or parts thereof) in production. So... it's not a demo project, and it has some happy users. But it is young and far from perfect.
I realize your main focus is on caching, which is why I think we can assist each other on the concurrent data structures part. I would be interested to hear what it would take for you to consider using JCTools where it meets your needs and maybe contributing remaining parts for the benefit of all.

[nitsanw]

happy to take this chat off-github, Skype: nitsanw.work

[ben-manes]

Great, also feel free to email me: [email protected]. I'm in the bay area and haven't been able to sleep the last few nights (~4:30am), so I won't skype you tonight as I head to bed.

In short, I would use JCTools in an application but prefer minimizing dependencies in any library that I publish. So I'd probably borrow ideas from JCTools and embed them internally, at least for this project.