[
https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703452#comment-14703452
]
Ariel Weisberg commented on CASSANDRA-9738:
-------------------------------------------
In OHCKeyCache when calculating the length of strings you are calculating the
length using String.length() which returns a wrong answer if you encode using
UTF-8.
We went to some length to come up with an "optimal" no garbage string writing
function for BufferedDataOutputStream (you can see it as a static method in
UnbufferedDataOutputStream). It would be great if we could do the same thing
here and not allocate byte arrays for the encoded names. Would it be crazy for
it take a lambda that describes how to write the generated byte array to some
output? Then we could use the same code everywhere. [~benedict] what do you
think?
Since you are using a short length prefix what is your level of confidence it
will always be enough? How does it fail if it isn't?
The 2i path testing is much appreciated. The utests didn't seem to make it in
cassci.
> Migrate key-cache to be fully off-heap
> --------------------------------------
>
> Key: CASSANDRA-9738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.0 beta 2
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and
> feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure
> off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some
> benefit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
