Reflection optimization

I think it might make sense to implement on a branch first then merge in after a chance for comments. I've read the paper, but have some questions about how the mechanism actually works (for example when the arguments to invoke aren't immediately obvious String constants) that I think would be clarified by seeing the code.

The implementation of 2 works by detecting calls to VM_Reflection.invoke and changing these to a new operator, REFLECTIVE_CALL. The first argument to REFLECTIVE_CALL is an operand that encodes the method to be called. If this operand is a constant then we can simplify the REFLECTIVE_CALL to a CALL. We aren't reliant on any of the other arguments to the REFLECTIVE_CALL being constants.

The next matter to make this work we need to get method object constants as arguments to VM_Reflection.invoke. As ultimately it is an array load in the class loader, this isn't ever going to be a constant value. To force it into being a constant making parts of the class loader pure is required.

Ultimately the scheme loses to bytecode generation as bytecode generation gets an immediate speedup from the baseline compiler, whereas the reflective call needs opt compilation with a lot of inlining to do a successful job.

I'll start pulling the world to pieces and removing the instrumentation. I can submit as either patches or to a branch.

One of the goals of this code is to remove the allocation of the reflective method call arguments array. For the simplification code, we need to check the arguments using a switch statement rather than a loop, to get around the problem that indirect accesses into the array would break simple escape analysis. The bytecode case uses helper methods to unpack all the arguments and throw exceptions, which ends up looking slightly more elegant.

Patch implementing all 4 schemes. I'd propose separating the bytecode generation scheme and only implementing that.

Implementation of reflection using bytecodes in r14866.