From: Peter D. <pe...@re...> - 2007-04-28 23:37:37
|
On 4/29/07, Ian Rogers <ian...@ma...> wrote: > I'm a big fan of all the tidy ups! I think we've made some progress > fixing some issues unfortunately none of the bugs we have fixed have reduced the regression count as such. > the recent changes to make casts from ObjectReference to > java.lang.Objects explicit I'm in favour of, but I guess ultimately we > want to deprecate the toObject method. I suspect ObjectReference.fromObject and ObjectReference.toObject both belong in the Jikes RVM specific part of the codebase rather than in vmmagic. > I've been trying to think how we can perform more automated bug finding > in particular for GC map issues. finding them does not seem to be an issue. I have been using variations on the gcmap-sanity test-run I checked in and it is relatively easy to produce gc map bugs. The problem is isolating them. What I guess would be really useful would be a command line switch to disable compilation at particular optimization levels. i.e. I would love to run all our sanity tests with Opt2 disabled and see how many regression failures still remain. It is a lot of work trying to identify the cause of gc map errors. Usually after locating one I have to run the program disabling recompilation and forcing optimization levels until it re-appears. This is particularly painful when it appears in the bootimage grr. > I think the following would be beneficial: > > - this is a minor lower priority thing, when the traces are produced we > can check the object reference immediately to see if it looks valid (ie > non-null TIB, etc.) > - another lower priority thing is, when the GC maps are produced we can > sanity check the GC map to make sure anything that is natural is never > assigned an object > - I think what would be an immediate good thing to do would be in > OPT_Operand.meet and OPT_ClassLoaderProxy.findCommonSuperclass (in > particular this), to check that when a common superclass is found we > don't perform a meet where an unboxed type becomes a java.lang.Object. > Asserts and the like to guard against this would be great. This code is > originally called in OPT_BC2IR. also a few other checks that I have yet to implement; * checking nulls are never assigned to unboxed types. Forces user to use ObjectReference.nullReference() or equivelent * checking an unboxed type never participates in a cast, instanceof, etc A few enhancements that I really want to implement but they probably wait for a bit * generating list of VM_Entrypoints from annotations on methods/types * Add in check that classes can not be resolved after resolution phase during bootimage writing > I imagine the opt compiler asserts are going to give false failures in > code only used during boot image creation (during boot image creation an > Address and Object are meet-able). I think we should be able to code > around this or just ignore these failures for certain methods. I vaguely recall there already being code in there that excludes tests from within magic types. So you just need to make sure that this code either occurs within the unboxed type or within VM_Magic -- Cheers, Peter Donald |