You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2014/01/31 19:28:11 UTC

[jira] [Commented] (CASSANDRA-6628) Cassandra crashes on Solaris sparcv9 using java 64bit

    [ https://issues.apache.org/jira/browse/CASSANDRA-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887964#comment-13887964 ] 

Benedict commented on CASSANDRA-6628:
-------------------------------------

Looking at FastByteComparisons a little closer, I think we should actually address some of these optimisations along with various other changes: currently we do an optimised comparison for big endian architectures, but for x86 we're doing a lot of unnecessary work. We can compare all endianness longs by comparing the least significant 63bits, and then modifying the result based on the most significant bit. This would simplify the algorithm and also make our most common target architecture faster.

At the same time, we're already doing a basic comparison of the last <= 8 bytes, so I suggest we modify this logic to run both ends, and include alignment. [~shohou] would you be able to test this on your hardware?

> Cassandra crashes on Solaris sparcv9 using java 64bit
> -----------------------------------------------------
>
>                 Key: CASSANDRA-6628
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6628
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: checked 1.2.x line and 2.0.x
>            Reporter: Dmitry Shohov
>            Assignee: Dmitry Shohov
>             Fix For: 2.0.5
>
>         Attachments: solaris_unsafe_fix.patch, tmp.patch
>
>
> When running cassandra 2.0.4 (and other versions) on Solaris and java 64 bit, JVM crashes. Issue is described once in CASSANDRA-4646 but closed as invalid.
> The reason for this crash is some memory allignment related problems and incorrect sun.misc.Unsafe usage. If you look into DirectByteBuffer in jdk, you will see that it checks os.arch before using getLong methods.
> I have a patch, which check for the os.arch and if it is not one of the known, it reads longs and ints byte by byte.
> Although patch fixes the problem in cassandra, it will still crash without similar fixes in the lz4 library. I already provided the patch for Unsafe usage in lz4.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)