Java JRE致命错误:乘法太多

Question

我试图测试Math.pow（）的速度，反对“手动”乘法，并偶然发现了这个错误：

Java 运行时环境检测到致命错误：

EXCEPTION_ACCESS_VIOLATION （0xc0000005） 在 pc=0x000000005ac46888， pid=1508， tid=6016

JRE版本：Java（TM）SE运行时环境（8.0_25-b18）（构建1.8.0-25-B16）
Java VM:Java热点（TM）64位服务器VM（25.25-b02混合模式windows-amd64压缩oops）
问题帧：
V[jvm.dll 0x496888]

无法写入核心转储。默认情况下，在客户端版本的Windows上不启用小型转储

生成它的代码:

long t = System.nanoTime();
for (int i = 0; i < 10000000; i++) {
    double val = i*i*i*i*i /* 256 times *i */ *i*i*i;
    sum ^= Double.doubleToLongBits(val);
}
System.out.println((System.nanoTime() - t) / 10000000);

我知道这确实是一个极端情况，但这仍然是有效的代码，可能发生的最糟糕的事情应该是在值中包含Inf，而不是JRE崩溃。这真的是甲骨文描述的标准行为吗？还是只是一个没人想修复的bug，因为如果你看到了它，你真的是个坏人。

对于记录运行 NetBeans 8.0.2

更新1

看来问题在于乘数的大小。

long t = System.nanoTime();
for(int j = 0; j < 10000000; j++) {
    int i = j % 50;
    double val = i*i*i*i*i /* 256 times *i */ *i*i*i;
    sum ^= Double.doubleToLongBits(val);
}
System.out.println((System.nanoTime() - t) / 10000000);

会没事的。

更新2

尝试从控制台运行它

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

并顺利通过，所以我认为这一定是这个特定的JRE或NetBeans的问题。

Answer 1

尝试使用BigInteger。

import java.math.BigInteger;

public class hackerrank {
    public static void main (String args[]){
        BigInteger x = new BigInteger("10000000");
        BigInteger sum = BigInteger.ZERO;
        long t = System.nanoTime();
        for (BigInteger i = BigInteger.ONE; i.compareTo(x) == -1; i = i.add(BigInteger.ONE)) {
            BigInteger j = i.remainder(new BigInteger("50"));
            BigInteger val = j.pow(256);
            sum = sum.xor(val);
        }
        System.out.println((System.nanoTime() - t) / 10000000);
    }
}

输出：4083

Answer 2

这对我来说很好。您的问题发生在哪里？通过减少乘法或循环数来隔离问题。它适用于50乘法吗？

long sum=0;
long t = System.nanoTime();
for (int i = 1; i < 10000000; i++) {
    double val = i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i
                    *i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i
                    *i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i; 
            // set of 10 *i*i*i*i*i*i*i*i*i*i
    sum ^= Double.doubleToLongBits(val);
}
System.out.println(sum);
System.out.println((System.nanoTime() - t) / 10000000);

jre1.8.0_51

输出：

    -32067153335156736
    614

即使再乘以10次迭代也可以，但真的很慢。时间6020

Answer 3

在我看来，这绝对像是一个JVM错误。这比SO上的问题更适合作为bug报告。参见http://bugreport.java.com/