Operating System: Linux
Platform: PC

So the cache is used to support a 'replay' history thing. A cache is the wrong data structure to support this use case, as its performance decreases with elements retained. The time-based eviction policy incurs heavy penalty when retention time is exceeded.

What you really want is a fixed-depth ArrayBlockingQueue. Make the depth configurable. Then to store a new packet do:

ArrayBlockingQueue q;
Object msg;

if (!q.offer(msg)) {
q.poll();
q.offer(msg);
}

which will give you a guaranteed replay buffer, with excellent O(1) performance. Given the high number of switches we want to support I would suggest to wrap the message in a SoftReference so we automatically throw debug data out before runnig out of memory.

Note that the ArrayBlockingQueue uses a preallocated backing array, so be careful to use reasonable numbers.

If you need time-based eviction, you can wrap the message into:

class MessageTime {
Object msg;
long time = System.nanoTime();
}

before inserting into the queue. Then have a background thread run the following periodically:

long cutoff = System.nanoTime() - RETENTION_TIME;
while (true) { // Not really, place an upper bound on items processed!
MessageTime m = q.peek();
if (m == null || m.time >= cutoff)

q.remove(m); // Because an enqueue thread may have removed it already
}

https://git.opendaylight.org/gerrit/#/c/6994/

removing bulk transaction cache
https://git.opendaylight.org/gerrit/#/c/7024/

cbench is showing speed improvements (up to 5%), memory consumption is lower (200MB)