[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14224734#comment-14224734
]
graham sanderson commented on CASSANDRA-8325:
---------------------------------------------
Well that was a good guess ;-)
So {{unsafe.getByte(null, address)}} and {{unsafe.getByte(address)}} are not
documented to be the same, but do seem to be on most platforms
However from getInt() docs:
{code}
* This method refers to a variable by means of two parameters, and so
* it provides (in effect) a <em>double-register</em> addressing mode
* for Java variables. When the object reference is null, this method
* uses its offset as an absolute address. This is similar in operation
* to methods such as {@link #getInt(long)}, which provide (in effect) a
* <em>single-register</em> addressing mode for non-Java variables.
* However, because Java variables may have a different layout in memory
* from non-Java variables, programmers should not assume that these
* two addressing modes are ever equivalent. Also, programmers should
* remember that offsets from the double-register addressing mode cannot
* be portably confused with longs used in the single-register addressing
* mode.
{code}
The why? Well you could look on FreeBSD OpenJDK mailing lists, or dig up the
source - changes to {{hotspot/src/share/vm/opto/library_call.cpp}} may help.
However this may not be a JVM bug, it might just be a consequence of address
space layout on FreeBSD. Things like -XX:+UseCompressedOps and heap size <= or
>= 32gig may have an effect.
Anyway, you might consider this a C* bug... sort of fuzzy there. If you're
building C* yourself, I'd start by changing (though it isn't necessarily the
only effected method)
In FastByteOperations.UnsafeOperations, I'd change
{code}
public static void copy(Object src, long srcOffset, byte[] trg, int
trgPosition, int length)
{
if (length <= MIN_COPY_THRESHOLD)
{
for (int i = 0 ; i < length ; i++)
trg[trgPosition + i] = theUnsafe.getByte(src, srcOffset +
i);
}
else
{
copy(src, srcOffset, trg, BYTE_ARRAY_BASE_OFFSET + trgPosition,
length);
}
}
{code}
to
{code}
public static void copy(Object src, long srcOffset, byte[] trg, int
trgPosition, int length)
{
if (length <= MIN_COPY_THRESHOLD)
{
if (src == null)
{
for (int i = 0 ; i < length ; i++)
trg[trgPosition + i] = theUnsafe.getByte(srcOffset + i);
}
else
{
for (int i = 0 ; i < length ; i++)
trg[trgPosition + i] = theUnsafe.getByte(src, srcOffset
+ i);
}
}
else
{
copy(src, srcOffset, trg, BYTE_ARRAY_BASE_OFFSET + trgPosition,
length);
}
}
{code}
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -----------------------------------------------------
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
> Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
