[
https://issues.apache.org/jira/browse/CASSANDRA-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333858#comment-14333858
]
Ariel Weisberg commented on CASSANDRA-8714:
-------------------------------------------
I suspect that the change to MemoryUtil.getByteBuffer could be slower. The JNA
implementation requires a JNI call which I suspect then uses the JNI call
newDirectByteBuffer. The Java implementation is all intrinsics and plain Java.
Conceptually does this shell code for finding the library belong in
cassandra-env.sh? Do Windows users no longer have a path running with jemalloc
(or did the ever)?
My bash is terrible so reviewing the shell script is tough. I tested it
manually and it worked with and without jemalloc installed on Ubuntu 14.04 and
CentOS 6.5. Conceptually I get it and it looks as reasonable a way as any to
find where jemalloc is hiding.
I am +1 conditional on:
* A micro benchmark for the change to getByteBuffer.
* If cassandra-env.sh is where this code should go then move, it's not clear to
me what belongs in cassandra vs cassandra-env.sh
* Do Windows users lose the ability to use jemalloc via JNA with this change?
Is that acceptable?
> row-cache: use preloaded jemalloc w/ Unsafe
> -------------------------------------------
>
> Key: CASSANDRA-8714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8714
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.0
>
> Attachments: 8714-2.txt, 8714-3.txt, 8714.txt
>
>
> Using jemalloc via Java's {{Unsafe}} is a better alternative on Linux than
> using jemalloc via JNA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
