cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
Date Thu, 24 Jul 2014 08:09:39 GMT


Robert Stupp commented on CASSANDRA-7438:

bq. no tools that aren't available through unsafe/NativeAllocator

It's "plain old" {{malloc}}/{{free}}.

But regardless whether JVM's native allocator or malloc is used - it needs to be thoroughly
tested to ensure that there are no memory leaks.
I'm not sure if it is possible with JNI code: we should also check different C malloc implementations
- there are differences.
Altogether IMO this (lruc) one is a good start to prevent GC - we can fully optimize it later.
Maybe it's possible to create a "pure Java off heap" solution without the annoying JNI-savepoint.

Ah - and we should check lruc against both Java7 and Java8 - I think there are optimizations
in Java8 regarding JNI (or at least there were some discussions - did not follow that).

> Serializing Row cache alternative (Fully off heap)
> --------------------------------------------------
>                 Key: CASSANDRA-7438
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: Linux
>            Reporter: Vijay
>            Assignee: Vijay
>              Labels: performance
>             Fix For: 3.0
>         Attachments: 0001-CASSANDRA-7438.patch
> Currently SerializingCache is partially off heap, keys are still stored in JVM heap as
> * There is a higher GC costs for a reasonably big cache.
> * Some users have used the row cache efficiently in production for better results, but
this requires careful tunning.
> * Overhead in Memory for the cache entries are relatively high.
> So the proposal for this ticket is to move the LRU cache logic completely off heap and
use JNI to interact with cache. We might want to ensure that the new implementation match
the existing API's (ICache), and the implementation needs to have safe memory access, low
overhead in memory and less memcpy's (As much as possible).
> We might also want to make this cache configurable.

This message was sent by Atlassian JIRA

View raw message