JDK-6733531 : Hang occurs in javac(jdk1.4.2_18 for IA64)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_18,1.4.2_21-rev
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,linux_redhat_3.0
  • CPU: generic,itanium
  • Submitted: 2008-08-05
  • Updated: 2010-12-03
  • Resolved: 2009-11-02
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
1.4-poolResolved
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
A customer has found out a hang.
The behavior seems hang, but actually this seems infinite loop in javac in jdk1.4.2 for ia64.

CONFIGURATION:

-bash-2.05b$ more /proc/cpuinfo
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 0
revision   : 7
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 900.000000
itc MHz    : 900.000000
BogoMIPS   : 1346.37

-bash-2.05b$ more /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon)

-bash-2.05b$ uname -a
Linux llllll 2.4.21-4.EL #1 SMP Fri Oct 3 17:29:39 EDT 2003 ia64 ia64 ia64 GNU/Linux

JDK : 1.4.2_18


REPRODUCE:
1) unfold the attached .tar file
2) Go to javac_infloop/j2se
3) Edit j2se_build_javac.sh
 3-1) Set Java home path to JAVA_H

  ex.
  #JAVA_H=/opt/j2se/1.4.2_18
  JAVA_H=/export/home/guest4us/java/jdk1.4.2_18

 3-2)Set option

   OPT="-J-XX:MaxInlineSize=60"
  
   Note:
     In jdk1.4.2_10 and earlier, this problem occurs easier
     even if without the above option.

4) Invoke ./j2se_build_javac.sh

  This script tries to execute javac.
  This is repeated 1000 times in while loop.
  Usually, this problem occurs within 5-10 iterations in the loop.


==== Messages and Thread Dump ======>
-bash-2.05b$ ./j2se_build_javac.sh

......

2 /export/home/guest4us/java/jdk1.4.2_18/bin/javac -J-XX:MaxInlineSize=60
src/share/classes/java/io/ObjectStreamClass.java:896: warning: non-varargs call of varargs method with inexact argument type for last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
                return cons.newInstance(null);
                                        ^
src/share/classes/java/io/ObjectStreamClass.java:976: warning: non-varargs call of varargs method with inexact argument type for last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
                readObjectNoDataMethod.invoke(obj, null);
                                                   ^
src/share/classes/java/io/ObjectStreamClass.java:1004: warning: non-varargs call of varargs method with inexact argument type for last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
                return writeReplaceMethod.invoke(obj, null);
                                                      ^
src/share/classes/java/io/ObjectStreamClass.java:1033: warning: non-varargs call of varargs method with inexact argument type for last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
                return readResolveMethod.invoke(obj, null);
                                                     ^

[ Here, "kill -QUIT <process#>" was invoked ]



Full thread dump Java HotSpot(TM) 64-Bit Server VM (1.4.2_18-b06 mixed mode):

"Signal Dispatcher" daemon prio=1 tid=0x6000000000097bb0 nid=0x1f9c waiting on
condition [0x0000000000000000..0x0000000000000000]

"Finalizer" daemon prio=1 tid=0x6000000000091e40 nid=0x1f9a in Object.wait() [0x2000000013cde000..0x2000000013cdebe0]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x200000000a7906b8> (a java.lang.ref.ReferenceQueue$Lock)        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x200000000a7906b8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x60000000000916f0 nid=0x1f99 in Object.wait() [0x2000000013bde000..0x2000000013bdebe0]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x200000000a790760> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:429)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
        - locked <0x200000000a790760> (a java.lang.ref.Reference$Lock)

"main" prio=1 tid=0x600000000001a400 nid=0x1f97 runnable [0x60000fffffff1000..0x60000fffffff3378]
        at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:98)
        at com.sun.tools.javac.comp.Flow.visitTry(Flow.java:1009)
        at com.sun.tools.javac.tree.Tree$Try.accept(Tree.java:674)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:34)
        at com.sun.tools.javac.comp.Flow.scanStat(Flow.java:484)
        at com.sun.tools.javac.comp.Flow.scanStats(Flow.java:492)
        at com.sun.tools.javac.comp.Flow.visitBlock(Flow.java:732)
        at com.sun.tools.javac.tree.Tree$Block.accept(Tree.java:540)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:34)
        at com.sun.tools.javac.comp.Flow.scanStat(Flow.java:484)
        at com.sun.tools.javac.comp.Flow.visitMethodDef(Flow.java:684)
        at com.sun.tools.javac.tree.Tree$MethodDef.accept(Tree.java:482)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:34)
        at com.sun.tools.javac.comp.Flow.visitClassDef(Flow.java:624)
        at com.sun.tools.javac.tree.Tree$ClassDef.accept(Tree.java:438)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:34)
        at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:1229)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:418)        
        at com.sun.tools.javac.main.Main.compile(Main.java:592)
        at com.sun.tools.javac.main.Main.compile(Main.java:544)
        at com.sun.tools.javac.Main.compile(Main.java:58)
        at com.sun.tools.javac.Main.main(Main.java:48)

"VM Thread" prio=1 tid=0x60000000000905a0 nid=0x1f98 runnable

"VM Periodic Task Thread" prio=1 tid=0x600000000009d960 nid=0x1fa0 waiting on condition
"Suspend Checker Thread" prio=1 tid=0x6000000000096fd0 nid=0x1f9b runnable

==== Messages and Thread Dump End ======>



NOTE:
 1) This problem did not occur with -XX:-OptoScheduling
 2) When the following statement was specified in .hotspot_compiler,
    This problem did not occur.

     exclude com/sun/tools/javac/comp/Flow visitTry

 3) There is a similar issue, BugID 5068762. The bug file provides a workaround
    -J-XX:MaxInlineSize=0. This option is set in Makefile of JavaSE for jdk5. 
    This option is not specified in the provided reproducing environment easier reproduction.

 4) This problem occurs easier in jdk1.4.2_10 and earlier.
   (Please see "comment" section. More details comment for source code change is attached.)

Comments
EVALUATION close as duplicate of 6560907, all the fix will be under 6560907.
02-11-2009

EVALUATION Backed out from 1.4.2_24-rev-b06 (with 6560907)
30-10-2009

EVALUATION Made changes according to tom's evaluatino of 6560907 fix the priliminary test showed OKay. After 6560907 fix integrated, this bug should be closed as a dup.
11-09-2009

EVALUATION This is likely the same bug as 6560907 which was probably the cause of 5068762. http://javaweb.sfbay.sun.com/~never/webrev/6560907 is a copy of the fix we're going to apply for 6560907. The webrev is against a recent hotspot so it might not apply cleanly to 1.4.2.
05-08-2008