FULL PRODUCT VERSION :
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b24)
Java HotSpot(TM) Client VM (build 12.0-b01, mixed mode, sharing)


FULL OS VERSION :
 customer  Windows [Version 6.0.6000]
(Vista x64)

A DESCRIPTION OF THE PROBLEM :
Unfortunately, I cannot send the simple test illustrating a bug. Obviously, the bug arises only in a complex code, for example, in our application.

Below is the link to 1MB jar-file, containing our libraries and tests:
http://algart.net/java/AlgART/BugInJava.1.7.0-ea-b24-32bit-Compiler/algorithm-lib-plus-demo.jar

Please download this jar and run the following test (maybe, with another path to java.exe):

"C:\Program Files (x86)\Java\jdk1.7.0\jre\bin\java" -ea -server -cp algorithm-lib-plus-demo.jar -Xmx200m -Dnet.algart.arrays.globalMemoryModel=BUFFER net.algart.arrays.demo.MainOperationsTest boolean 1000 1000 1 1 5

This test checks our complex algorithmic procedures, containing intensive manipulations with bits, packed into LongBuffer (1000 bits packed into 16 LongBuffer elements, 1000 passes). The sequence of operations is random, but the initial randseed is set via the 5th argument of this test (1), so every call leads to the same results.

When called by 32-bit java 1.7.0-ea-b24, this test prints an error message:

...
(5)  Testing "buffer().map" method, changing + forcing...
java.lang.AssertionError: The bug in setData found in test #455: destPos = 21, count = 887, error found at 928
        at net.algart.arrays.demo.MainOperationsTest.testBufferMapping(Unknown Source)
        at net.algart.arrays.demo.MainOperationsTest.testElementType(Unknown Source)
        at net.algart.arrays.demo.MainOperationsTest.testAll(Unknown Source)
        at net.algart.arrays.demo.MainOperationsTest.main(Unknown Source)
...
(This message should inform about a bug in our setData method.)

However, if we call this test without "-server" key or with "-Xint" key, or under 64-bit version of java 1.7.0-ea-b24, or under java 1.6.0_02, the test works normally and do not find any errors.

But: 32-bit java 1.6.0_04 (with -server key) also cannot perform this test!

I detected analogous bugs with bit manipulations under previous releases of Java 1.7.0-ea, on Windows XP SP2. The thorough investigations shew that sometimes 1 bit in a long bit array (packed into a direct LongBuffer) is processed incorrectly. It is probably a new bug, appeared in JVM while your latest optimizations.

If you need, we may send you the source files, but they are large and complex enough.


THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Please download our JAR and run the test listed above.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: identical behaviour (excepting the speed) under all versions of JVM and regardless of "-server" or "-Xint" keys
Actual: under 32-bit versions of java 1.7.0-ea-b24 and java 1.6.0_04-b12, with -server key, this test "detects a bug" in my algorithms, really, I think - in the HotSpot optimizer.
REPRODUCIBILITY :
This bug can be reproduced always.
Posted Date : 2008-02-09 02:05:39.0

Reducing the register pressure in your code might help.  From looking at the code in the other bug you filed you might consider recoding your loop for packing values.  It might seem like not using a loop for the packing would make the code run better but it's such a big chunk of code with so many unique constants it might be making it worse.  I recoded the pack routine as a pair of loops and it performs maybe 15% better plus to doesn't trigger our bug.

            int low = 0;
            int bit = 1;
            for (int i = 0; i < 32; i++) {
                if (src[srcPos + i]) low |= bit;
                bit <<= 1;
            }
            int high = 0;
            bit = 1;
            for (int i = 32; i < 64; i++) {
                if (src[srcPos + i]) high |= bit;
                bit <<= 1;
            }
            srcPos += 64;

Handling the high and low halves separately is reasonable since operations on longs aren't the best in 32 bit jvms.

In general there isn't a good workaround for this bug but modifying your source may make it go away.

This is a bug in post allocation copy removal for constants introduced by the change for 5032515.  There's some confusion between the value we found and the node which defined that value that results in us skipping over a def during elimination.  This causes us to have the wrong register state so we think a register is live when it's not.  It's a somewhat unusual case to have a rematerializable constant spilled instead of being rematerialized.  I think it occurs because of the high register pressure in the unrolled body of the loop.
Posted Date : 2008-02-14 02:00:16.0

Thank you. When, approximately, we can hope this bug will be resolved? It's obvious that is is a critical issue. In can lead to bugs in our commercial image processing software. - Daniel Alievsky

Unfortunately, this bug is still reproduced in JDK 1.6.0_05 and 1.7.0-ea-b25 (32-bit versions).

Please also check the following calls:
"C:\Program Files\Java\jdk1.6.0_05\jre\bin\java" -ea -server -cp algorithm-lib-plus-demo.jar -Xmx200m -Dnet.algart.arrays.globalMemoryModel=BUFFER net.algart.arrays.demo.MainOperationsTest -funcOnly ALL 1000 1000 1 1

and the same parameters for Java 1.7.0 (b25). These calls, vice versa, work normally under 32-bit versions of JRE, but fail (detect a bug while testing "Arrays.asShifted" for boolean type) under 64-bit versions.