Constant folding values from TIBs produces failures

This still causes errors in r12495. Specifically the SPECjbb suites fail with;

Exception in thread "main": java.lang.NullPointerException
at java.util.HashSet.<init>(HashSet.java:138)
at java.security.CodeSource.<init>(CodeSource.java:97)
at gnu.java.net.loader.Resource.getCodeSource(Resource.java:74)
at java.net.URLClassLoader.findClass(URLClassLoader.java:580)
at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
at java.lang.ClassLoader.loadClass(ClassLoader.java:293)

A bug with TIB folding was fixed in r12849 but a number of failures still exist (including the above SPECjbb failure.

Fixed in r12887

It seems that the bug is still present. Overnight test runs produced failures such as SPECjbb200* in

http://jikesrvm.anu.edu.au/cattrack/results/rvmppclnx32.anu.edu.au/commit.471/summary
http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/commit.473/summary

It seems that only getObjTib causes this failure so that has been disabled and CF_TIB set to true

Having spent yesterday distracted thinking I had my own bug, I found I was actually looking at this bug I have a concrete example of the problem in that we simplify:

3 get_obj_tib t913sa([Ljava/lang/Object = t528psa(Ljava/util/Collection;,p), <TRUEGUARD>

into

3 ref_move t913sa([Ljava/lang/Object = tib "java.util.Collection"

However, a Collection is an interface so it's TIB won't really be the TIB we're after. What has confused the simplifier is that the register is marked as having a precise type. This should mean the value of the register was created by a new. But a collection is an interface which you can't possibly allocate or have as precise!

The bug occurs in java.security.CodeSource.<init> which inlines the Collection version of HashMaps constructor (inlining must be enabled for the bug to occur ). The culprit of incorrectly specifying the precise type on the register appears to be OPT_BranchOptimizations.

I'd suggest that we:
1) disable folding get_obj_tib on registers (constants should be ok)
2) create an IR verifier that when we check register operands of instructions, if a register operand is marked as precise it can't be an interface or abstract class
3) fix all the places this shows the precise type information has become corrupt

which is quite a bit of work, but it's better we're strict about register properties prior to re-introducing all the O3 optimization phases (that probably violate them as well). This won't stop all possible corruptions of register precise type information (corruptions from a class to another class will be possible), but hopefully we have enough test cases that we will find all our bugs.

Phase 1 is committed as r12970. Rather than use the verifier it's easier to track the bug via asserts. Adding asserts to ensure precise type information is preserved is what I'm doing currently.

Attached is the state of play on this. It seems the problem is that a checkcast is setting the type of a register operand to whatever it's checking even though the register operand is precise. This can weaken the strong type information meaning we have some specific type of collection but then following a cast it's now just a collection. The precise type information is wrong and this has the potential not just to break the simplifier but also inlining. This patch does 3 things:

1) it makes all accesses to a register operands register and type go through a getter and setter (praise be to eclipse's refactor tool)
2) it adds asserts to trap when precise information is given which is wrong (namely the precise type is abstract or an interface). So that this doesn't blow up some statements setting a precise type needed reordering.
3) it removes the java.lang.String special case from the field database (shouldn't be necessary since we have the boot image writer oracle now) and ignores the setting of the type following a checkcast if the type is already precise

It seems likely that the special case is still required for the field database Or the checkcast change is improving inlining and exposing latent bugs. In any case dacapo bloat is now failing (with an error relating to a string). It seems the string special case should be re-introduced or the checkcast modified so that it clears the precise type when weakening what we know about it. After this the get_obj_tib optimization can be tried out again.

I'm not going to get chance to play with this for a while so if someone else wants a go feel free.

This should be fixed as of r13007 (see also r13004 for the problems that were gating this fix). Not closing until we have a clean set of sanity runs, but passed pre-commit and commit tests that include the previously failing SPECjbb benchmarks.

Last nights regression results [1] don't show new opt compiler failures so I'm closing.
[1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/sanity.546/regression_report