[
https://issues.apache.org/jira/browse/CASSANDRA-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-6628:
--------------------------------
Attachment: tmp.patch
I've attached a patch with some minor changes:
Instead of the proliferation of "os.arch" tests checking "sparcv9" and "64"
around the place, I've moved them into
DatabaseDescriptor.hasLargeAddressSpace(). This now first checks for the
sun.arch.data.model before falling back to os.arch if that isn't present, or is
not 32 or 64.
Also, there didn't seem to be a great deal of point to adding the complication
to the UnsafeComparator in FastByteComparisons. The native comparer seems like
it would do just as well. Unless you have benchmarks demonstrating the
performance benefit, of course.
All this said, it looks to me like it might be worth investigating what
alignment would be necessary to ensure unsafe.getLong() works safely. If it's a
simply that is has to not have the lowest 3 address bits set (likely given that
this is the requirement for JVM packing of long positions inside regular
objects), we could probably write a special aligned comparator, that does byte
comparisons for the first and last <=7 bytes. For Memory we could pad out the
first few bytes when we know the offset we'll be putting/reading longs.
This is probably a better solution, but for now the attached patch should be
sufficient.
> 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)
