JDK-6761298 : Broken methods (inlining)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u10
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2008-10-20
  • Updated: 2011-01-25
  • Resolved: 2008-10-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
hs11Resolved
Related Reports
Duplicate :  
JDK-6732194 - Data corruption dependent on -server/-client/-Xbatch
Description
It looks like these methods does not work correctly (maybe if inlined):
private boolean toBoolean(long r) {
    return r == 0 ? false : true;
}

private long toLong(boolean b) {
    return b ? 1 : 0;
}

see comments for details
Comments
EVALUATION Based on the debugging I did I'm certain this is the same bug. I tested this workaround by modifying the bytecodes in the jar file directly and it does work for me. I was having a problem where netbeans was somehow getting the old version of the class file even though the jar file contained the fixed version. I blew away my .netbeans/dev/var/cache directory and it started picking up the modified version. Are you sure it was actually picking up the modified jar file? The pattern below should work as well but is more extreme. private static long one = 1; private static long zero = 0; private long toLong(boolean b) { return b ? one : zero; } The important part of this one is that it hides the fact that the values are constants. 6732194 is going to be fixed in u11 and I'm building the test bits today. I'll point you at a jvm that you can try to confirm the fix as well.
30-10-2008
EVALUATION I've confirmed that this is a duplicate of 6732194 and the problematic code pattern does come from toLong. Basically we're rematerializing constants for use by the ?: pattern and that exposes us to the bug. If you can change the definition of toLong to something like: private long toLong(boolean b) { return (long)(b ? 1 : 0); } you could avoid the problem and get more efficient code to boot. C2 is smart enough to know that a boolean is really just an int with the value of either 1 or 0 so it converts (b ? 1 : 0) into (int)b. The cast to long then just sign extends that. We don't have a similar optimization for longs so we end up emitting the a full cmove expression. Anyway, I know that code is ugly but I thought I would mention it. I believe we're trying to fix this for 6u11.
28-10-2008
EVALUATION I believe this is a duplicate of 6732194. I can reproduce this problem with the version of hotspot before this was fixed and the problem goes away with the build containing the fix for 6732194. I'm going to confirm this in the debugger but we might want to consider including this in u11.
20-10-2008