[#RVM-597] Array index out of bounds in BC2IR generation context

RVM

Array index out of bounds in BC2IR generation context

Created: 23/Jul/08 06:14 AM Updated: 01/Aug/08 03:26 PM

Component/s:

Compiler: Optimizing

Affects Version/s:

None

Fix Version/s:

3.0

Time Tracking:

Not Specified

Issue Links:

Related

This issue relates to:

~~RVM-288~~ Assertion failure in inline oracle

Description

« Hide

An example of the bug is here:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4483/production/default/perf-jbb2000/jbb2000GC/1/Output.txt

there appears to be a mismatch between the number of operands returned by the Call instruction and those expected by the method.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Ian Rogers added a comment - 27/Jul/08 04:09 AM

This is still occurring:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4531/production/default/perf-jbb2000/jbb2000/1/Output.txt

[ Permlink | « Hide ]

Ian Rogers added a comment - 27/Jul/08 06:11 PM

This is becoming a fairly dependable failure that we should aim to close by 3.0. Another example here:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4544/production/default/perf-jbb2000/jbb2000GC/1/Output.txt

I've tried repeating the error with the OTH and failed. spec/jbb/TransactionManager.go is a long method making it difficult to pinpoint the inlining problem. Related bug statements added in r14769, r14807 and r14808.

[ Permlink | « Hide ]

Ian Rogers added a comment - 28/Jul/08 06:53 AM

An example of the error:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4550/production/default/perf-jbb2000/jbb2000GC/1/Output.txt

what appears to be happening is a call from spec.jbb.TransactionManager.go is getting the wrong targets. Ie in the bytecode:

665: invokevirtual #105; //Method spec/jbb/NewOrderTransaction.process)Z
668: pop
669: aload 32
671: invokevirtual #117; //Method spec/jbb/NewOrderTransaction.secondDisplay)V
674: invokestatic #65; //Method java/lang/System.currentTimeMillis)J
677: lstore 9
679: lload 9
681: lload 7
683: lsub
684: lstore 11
686: aload_0
687: getfield #61; //Field company:Lspec/jbb/Company;
690: getfield #97; //Field spec/jbb/Company.mode:B
693: iconst_2
694: if_icmpne 706
697: aload 24
699: iload 13
701: lload 11
703: invokevirtual #124; //Method spec/jbb/TimerData.updateTimerData:(IJ)V

the call to process() at PC=665 is returning the methods from updateTimerData at PC=703. There are similar sequence elsewhere in the very large go method but always the distance between the bytecodes appears to be 38.

I believe the cause of the bug may be OSR, this is what makes it hard to reproduce. I think OSR may have inserted extra bytecodes into go (probably 38 of them) and by a fluke this means that when we ask for targets of process we get them for a method that is 38bytes later.

[ Permlink | « Hide ]

Ian Rogers added a comment - 28/Jul/08 08:27 AM

There is a bug that the callHelper in BC2IR doesn't take into account the bciAdjustment of OSR, we can therefore currently get the wrong targets for a method called during OSR from the adaptive systems weighted call graph (which quite logically doesn't know anything about OSR bytecode adjustments). We know SPECjbb2000 is likely to be hitting this problem because of the array index out of bounds exception, bloat could be getting this problem too, but perversely the called method and the wrong target methods may have the same or a greater number of arguments.

[ Permlink | « Hide ]

Ian Rogers added a comment - 28/Jul/08 09:19 AM

Fix committed in r14811. Will close after some regression tests go by.