
THIS IS JUST AN UNORDERED LIST OF NOTES AND TODOS AND HINTS


Let only one implementation (linked / tables) survive, test on NUMA machine.

Add burn test.

Cleanup (or better: combination of entry size and trigger/target) may expose a bug. Definitely worth keeping an eye on it.
It will just "do nothing" if there's not enough off-heap memory could be allocated.
But if too many threads allocate new entries and the machine is near-to-full, the whole machine may fail (due to OOM).


// Marker item (RowCacheSentinel) added to row cache before actual load of row.
--
Honestly I cannot recall. I think it's simply to avoid duplicated work, but I think both end up performing the read.
It would make sense if one simply waited on the result of the other, but I don't tihnk that's what happens.
--
It's nice - but we should not do more than adding a "marker" to the cache and regularly poll if it has been processed.
But it will degrade performance for rows that are bigger than "maxEntrySize".
--> use CacheLoader since OHC 0.3



jemalloc + Unsafe allocation on Linux + Windows regarding fragmentation on long running systems.


Currently LRU is built in - but I'm not really sold on LRU as is. Alternatives could be
    timestamp (not sold on this either - basically the same as LRU)
    LIRS (https://en.wikipedia.org/wiki/LIRS_caching_algorithm), big overhead (space)
    2Q (counts accesses, divides counter regularly)
    LRU+random (50/50) (may give the same result than LIRS, but without LIRS' overhead)
But replacement of LRU with something else is out of scope of this ticket and should be done with real workloads in C* -
although the last one is "just" a additional config parameter.

IMO we should add a per-table option that configures whether the row cache receives data on reads+writes or just on reads.
Might prevent garbage in the cache caused by write heavy tables.
