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

          Activity

          Ian Rogers made changes -
          Field Original Value New Value
          Link This issue relates to RVM-443 [ RVM-443 ]
          Hide
          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
          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
          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
          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.
          Ian Rogers made changes -
          Attachment RVM-517.patch [ 34833 ]
          David Grove made changes -
          Fix Version/s 3.0 [ 13530 ]
          Fix Version/s 2.9.4 [ 14162 ]
          David Grove made changes -
          Fix Version/s 3.1 [ 14379 ]
          Fix Version/s 3.0 [ 13530 ]
          Hide
          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.
          Ian Rogers made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 3.0.1 [ 14378 ]
          Fix Version/s 3.1 [ 14379 ]
          Resolution Fixed [ 1 ]
          Ian Rogers made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Ian Rogers
              Reporter:
              Ian Rogers
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: