Our project uses BDB JE 5.0.48 and 4.0.103.
We are discussing the implications of [JVM defect 7063674|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7063674] on our project. Whilst we have not encountered a defect that we can attribute to this bug, another team here (not using BDB JE) has been affected by this JVM issue, and this has caused us to sweep through our code and our dependencies. This sweep has prompted this question.
We notice that BDB JE makes use of Integer.bitCount and BitSet.cardinality. Do you currently suggest use of the -XX:-UsePopCountInstruction at suggested by 7063674 on platforms affected by this issue?
Kind regards, Keith Wall.
From some of your previous postings, it looks like you are using JE/HA, correct?
Also, I assume you are able to reproduce the bug on your own machines (I can't reproduce it on mine). Are you able to reproduce it with an int instead of a long?
Edited by: Charles Lamb on Jun 7, 2012 7:35 PM
We use BDB JE for both non-HA and HA use-cases.
* Our non-HA use of BDB is well established: we have a large number of production users on a variety of platforms. BDB versions 4.0.103 through 5.0.48 are in use.
* Our HA use case is new (we are yet to have production users). BDB version 5.0.48.
Yes, I can reproduce the bug on my machine using the PopCount program attached in the Sun DB.
I'm on Linux 2.6.18-128.7.1.el5 (Red Hat Enterprise Linux Server release 5.3 (Tikanga)) hardware Intel(R) Xeon(R) CPU E5620 @ 2.40GHz. I see defect with Sun JVMs jdk1.6.0_18 and beyond (earlier versions of 1.6 did not show the defect). I notice that the [release notes|http://www.oracle.com/technetwork/java/javase/6u18-142093.html] 1.6.0_18 state "Bit set processing on 64-bit Linux".
I also noted that if I change the PopCount program to test Integer.bitCount() rather than Long.bitCount() (changing the type of mask from long to int), I reproduce the same problem.
Kind regards, Keith Wall.
Edited by: keithwall on Jun 8, 2012 12:49 AM
Edited by: keithwall on Jun 8, 2012 12:54 AM
The general gist is that we use Integer.bitCount and BitSet.cardinality, which are affected by this JVM bug, in JE, but our use is minimal. Keith Wall can invoke the JVM bug on his machine, using a standalone, non-JE test, but that same test does not fail in any of our environments. Neither of us have seen any JE failures that can be attributed to this JVM bug.
So we're basically working together to look at our code to see what effect this could have. Since we can't provoke the JVM bug, Keith is helping us by running some tests.
Our use of the bitCount() method is minimal and extremely unlikely to trigger this bug. That said, if it does trigger this problem, it will cause an IllegalArgumentException to be thrown during recovery of a replicated environment. If that occurs, then just rerun the recovery. If it still occurs, then the user would use the -XX:-UsePopCountInstruction argument to the JVM.
Here is Ismael's post to the hotspot-compiler-dev mailing list:
and the official review for the bug: