[#RVM-517] Reflection optimization

RVM

Reflection optimization

Created: 27/May/08 10:20 AM Updated: 10/Aug/08 11:13 AM

Component/s:

Runtime

Affects Version/s:

None

Fix Version/s:

3.0.1

Time Tracking:

Not Specified

File Attachments:

RVM-517.patch (159 kB)

Issue Links:

Related

This issue relates to:

~~RVM-443~~ Avoid back references in java.lang.reflect VMXXX classes

Description

« Hide

In "Approaches to Reflective Method Invocation" to be presented at ICOOOLPS 2008, we show 4 ways to implement method reflection:

1) out-of-line machine code - what we currently have
2) opt compiler simplification of out-of-line - simplifying a out-of-line call to a regular call when the method argument is constant
3) bytecode generation upon initial reflect method/constructor object creation - create bytecode to perform the reflective method call when a reflective wrapper is created
4) deferred bytecode generation - as with 3, but create bytecode upon 1st reflective method invocation

Of the approaches 3 gives the greatest time saving, as it speeds eclipse up considerably. The best average performance is given by 4.

Schemes 3 and 4 require an extra class to work, putting pressure on the JTOC. However, they are able to speed both baseline and opt compiled code.

We should implement scheme 4 in the current trunk.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

David Grove added a comment - 27/May/08 12:24 PM

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.

[ Permalink | « Hide ]

Ian Rogers added a comment - 28/May/08 03:00 AM

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.

[ Permalink | « Hide ]

Ian Rogers added a comment - 28/May/08 03:05 AM

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.

[ Permalink | « Hide ]

Ian Rogers added a comment - 28/May/08 06:16 PM

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

[ Permalink | « Hide ]

Ian Rogers added a comment - 10/Aug/08 11:13 AM

Implementation of reflection using bytecodes in r14866.