RVM

Reflection optimization

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0.1
  • Component/s: Runtime
  • Labels:
    None
  • Number of attachments :
    1

Description

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.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. RVM-443 Avoid back references in java.lang.reflect VMXXX classes

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Grove added a comment -

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.

Show
David Grove added a comment - 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.
Hide
Permalink
Ian Rogers added a comment -

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.

Show
Ian Rogers added a comment - 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.
Hide
Permalink
Ian Rogers added a comment -

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.

Show
Ian Rogers added a comment - 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.
Hide
Permalink
Ian Rogers added a comment -

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

Show
Ian Rogers added a comment - Patch implementing all 4 schemes. I'd propose separating the bytecode generation scheme and only implementing that.
Hide
Permalink
Ian Rogers added a comment -

Implementation of reflection using bytecodes in r14866.

Show
Ian Rogers added a comment - Implementation of reflection using bytecodes in r14866.

People

  • Assignee:
    Ian Rogers
    Reporter:
    Ian Rogers
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: