RE: Bug with Current KJC Compiler

[Brent Fulgham]

> Under the new KJC (from their website), it works a bit better:
> 
> Administrator@BFULGHAM1 ~/java
> $ javac PlusPlusTest.java
> assertion "!INTS_DISABLED()" failed: file "exception.c", line 386
> Aborted (core dumped)
> 
> I'm not sure which is worse -- however the second case 
> indicates an issue with the JVM so might be of more interest 
> to us as time passes.
> 

Actually, it seems to be related to time.  If I run in verbose mode,
everything builds just fine...

Administrator@BFULGHAM1 ~/java
$ javac OldTest.java
assertion "!INTS_DISABLED()" failed: file "exception.c", line 386
Aborted (core dumped)

Administrator@BFULGHAM1 ~/java
$ javac -v OldTest.java
[ start compilation in verbose mode ]
[ parsed OldTest.java in 344 ms ]
[ checked interfaces in 273 ms ]
[ checked body of OldTest.java in 188 ms ]
[ optimized and generated OldTest in 187 ms ]
[ compilation ended ]

-Brent

Bug with Current KJC Compiler

[Brent Fulgham]

The version of KJC that ships in Kaffe right now has a bug with the ++ operator when 
used with instance variables.  Here's a sample program that highlights the problem (at 
least under a Cygwin build):

public class PlusPlusTest
{
private int count = 0;

public PlusPlusTest() {
for (int i = 1; i < 5; ++i) {
//count++;  // This works
++count;// This fails
}
}

public static void main(String[] argv) {
PlusPlusTest ppt = new PlusPlusTest();
System.out.println("Test Key: " + new Integer(ppt.count).toString());
}
}

An attempt to compile results in:

-1 / -2
10: N/A putfield
0:  1   aload_0
1:  0   invokespecial
2:  1   aload_0
3:  0   invokespecial
4:  1   iconst_1
5:  0   istore_1
6:  0   goto
7:  1   aload_0
8:  2   iconst_1
9:  1   iadd
10: N/A putfield
11: N/A iinc
12: 1   iload_1
13: 2   iconst_5
14: 0   if_icmplt
15: N/A return
0:  1   aload_0
1:  0   invokespecial
2:  1   aload_0
3:  0   invokespecial
4:  1   iconst_1
5:  0   istore_1
6:  0   goto
7:  1   aload_0
8:  2   iconst_1
9:  1   iadd
10: N/A putfield
11: N/A iinc
12: 1   iload_1
13: 2   iconst_5
14: 0   if_icmplt
15: N/A return
0:  1   aload_0
1:  0   invokespecial
2:  1   aload_0
3:  0   invokespecial
4:  1   iconst_1
5:  0   istore_1
6:  0   goto
7:  1   aload_0
8:  2   iconst_1
9:  1   iadd
10: N/A putfield
11: N/A iinc
12: 1   iload_1
13: 2   iconst_5
14: 0   if_icmplt
15: N/A return
GenCode failure in source class: PlusPlusTest
at.dms.classfile.ClassFileFormatException: stack underflow
at 
at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:122)
at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95)
at at.dms.classfile.JumpInstruction.check(JumpInstruction.java:147)
at 
at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:133)
at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95)
at at.dms.classfile.JumpInstruction.check(JumpInstruction.java:147)
at 
at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:133)
at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95)
at at.dms.classfile.CodeEnv.checkExecutionPaths(CodeEnv.java:73)
at at.dms.classfile.CodeEnv.check(CodeEnv.java:47)
at at.dms.classfile.CodeInfo.resolveConstants(CodeInfo.java:289)
at at.dms.classfile.AttributeList.resolveConstants(AttributeList.java:237)
at at.dms.classfile.MethodInfo.resolveConstants(MethodInfo.java:221)
at at.dms.classfile.ClassInfo.resolveConstants(ClassInfo.java:467)
at at.dms.classfile.ClassInfo.write(ClassInfo.java:360)
at at.dms.classfile.ClassInfo.write(ClassInfo.java:436)
at at.dms.kjc.CSourceClass.genCode(CSourceClass.java:235)
at at.dms.kjc.Main.genCode(Main.java:222)
at at.dms.kjc.Main.run(Main.java:174)
at at.dms.kjc.Main.compile(Main.java:68)
at at.dms.kjc.Main.main(Main.java:59)
error:stack underflow

This happens under both Kaffe and the Sun JVM, so seems to indicate a bug in the 
actual KJC compiler code.

Under the new KJC (from their website), it works a bit better:

Administrator@BFULGHAM1 ~/java
$ javac PlusPlusTest.java
assertion "!INTS_DISABLED()" failed: file "exception.c", line 386
Aborted (core dumped)

I'm not sure which is worse -- however the second case indicates an issue with the JVM 
so might be of more interest to us as time passes.

Thanks,

-Brent

RE: JRE file layout for 1.0.7?

[Brent Fulgham]

> Is anybody opposed to this?  It is breaking with tradition 
> somewhat, and it's for the upcoming release, so I figured
> it would be best to ask.  It'll also impact the Debian and
> RPM packages.
> 

Go for it -- this will also allow side-by-side testing with other
JRE implementations by resetting the JAVA_HOME variable when
so desired.

-Brent