In this test case (from jakarta-commons-collections) we expect to see an
OutOfMemoryError thrown. This doesn't always happen as it should, but only
when compiling from bytecode. And only with ecj...
public class OutOfMemoryError
{
private static void fail(String msg)
{
System.err.println(msg);
System.exit(1);
}
private static void gc() {
try {
// trigger GC
byte[][] tooLarge = new byte[1000000000][1000000000];
fail("you have too much RAM");
} catch (java.lang.OutOfMemoryError ex) {
System.gc(); // ignore
}
}
public static void main(String[] argv)
{
gc();
}
}
It depends on exactly how the bytecode compiler generates code.
This one fails:
Method name:"gc" private static Signature: ()void
Attribute "Code", length:70, max_stack:2, max_locals:0, code_length:22
0: ldc <Integer 1000000000>
2: ldc <Integer 1000000000>
4: multianewarray <Class [[B> 2
8: pop
This one doesn't fail:
Method name:"gc" private static Signature: ()void
Attribute "Code", length:66, max_stack:2, max_locals:1, code_length:22
0: ldc <Integer 1000000000>
2: ldc <Integer 1000000000>
4: multianewarray <Class [[B> 2
8: astore_0
It seems that the pop instruction in the first version causes the
multianewarray never to be invoked. The "oh so clever" ecj notices that
tooLarge is never used, so doesn't generate a slot for it.
--
Summary: multianewarray not always evaluated when compiling from
bytecode
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28423
