[
https://issues.apache.org/jira/browse/CASSANDRA-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109159#comment-14109159
]
Benedict commented on CASSANDRA-7039:
-------------------------------------
Great, thanks. Scanned the patch and it looks good (although I would have liked
a public method for operating over a direct address, but it looks like this
would have been difficult to both honour the public Java API, keep the
implementation clean and support 32bit pointers on 32bit VMs).
Since we're not in a rush, let's give jpountz plenty of time to review and
integrate it before we consider forking.
> DirectByteBuffer compatible LZ4 methods
> ---------------------------------------
>
> Key: CASSANDRA-7039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7039
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Branimir Lambov
> Priority: Minor
> Labels: performance
> Fix For: 3.0
>
>
> As we move more things off-heap, it's becoming more and more essential to be
> able to use DirectByteBuffer (or native pointers) in various places.
> Unfortunately LZ4 doesn't currently support this operation, despite being JNI
> based - this means we both have to perform unnecessary copies to de/compress
> data from DBB, but also we can stall GC as any JNI method operating over a
> java array using the GetPrimitiveArrayCritical enters a critical section that
> prevents GC for its duration. This means STWs will be at least as long any
> running compression/decompression (and no GC will happen until they complete,
> so it's additive).
> We should temporarily fork (and then resubmit upstream) jpountz-lz4 to
> support operating over a native pointer, so that we can pass a DBB or a raw
> pointer we have allocated ourselves. This will help improve performance when
> flushing the new offheap memtables, as well as enable us to implement
> CASSANDRA-6726 and finish CASSANDRA-4338.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
