Skip to content
  • Aaron Patterson's avatar
    cdf33ed5
    Optimized forwarding callers and callees · cdf33ed5
    Aaron Patterson authored
    This patch optimizes forwarding callers and callees. It only optimizes methods that only take `...` as their parameter, and then pass `...` to other calls.
    
    Calls it optimizes look like this:
    
    ```ruby
    def bar(a) = a
    def foo(...) = bar(...) # optimized
    foo(123)
    ```
    
    ```ruby
    def bar(a) = a
    def foo(...) = bar(1, 2, ...) # optimized
    foo(123)
    ```
    
    ```ruby
    def bar(*a) = a
    
    def foo(...)
      list = [1, 2]
      bar(*list, ...) # optimized
    end
    foo(123)
    ```
    
    All variants of the above but using `super` are also optimized, including a bare super like this:
    
    ```ruby
    def foo(...)
      super
    end
    ```
    
    This patch eliminates intermediate allocations made when calling methods that accept `...`.
    We can observe allocation elimination like this:
    
    ```ruby
    def m
      x = GC.stat(:total_allocated_objects)
      yield
      GC.stat(:total_allocated_objects) - x
    end
    
    def bar(a) = a
    def foo(...) = bar(...)
    
    def test
      m { foo(123) }
    end
    
    test
    p test # allocates 1 object on master, but 0 objects with this patch
    ```
    
    ```ruby
    def bar(a, b:) = a + b
    def foo(...) = bar(...)
    
    def test
      m { foo(1, b: 2) }
    end
    
    test
    p test # allocates 2 objects on master, but 0 objects with this patch
    ```
    
    How does it work?
    -----------------
    
    This patch works by using a dynamic stack size when passing forwarded parameters to callees.
    The caller's info object (known as the "CI") contains the stack size of the
    parameters, so we pass the CI object itself as a parameter to the callee.
    When forwarding parameters, the forwarding ISeq uses the caller's CI to determine how much stack to copy, then copies the caller's stack before calling the callee.
    The CI at the forwarded call site is adjusted using information from the caller's CI.
    
    I think this description is kind of confusing, so let's walk through an example with code.
    
    ```ruby
    def delegatee(a, b) = a + b
    
    def delegator(...)
      delegatee(...)  # CI2 (FORWARDING)
    end
    
    def caller
      delegator(1, 2) # CI1 (argc: 2)
    end
    ```
    
    Before we call the delegator method, the stack looks like this:
    
    ```
    Executing Line | Code                                  | Stack
    ---------------+---------------------------------------+--------
                  1| def delegatee(a, b) = a + b           | self
                  2|                                       | 1
                  3| def delegator(...)                    | 2
                  4|   #                                   |
                  5|   delegatee(...)  # CI2 (FORWARDING)  |
                  6| end                                   |
                  7|                                       |
                  8| def caller                            |
              ->  9|   delegator(1, 2) # CI1 (argc: 2)     |
                 10| end                                   |
    ```
    
    The ISeq for `delegator` is tagged as "forwardable", so when `caller` calls in
    to `delegator`, it writes `CI1` on to the stack as a local variable for the
    `delegator` method.  The `delegator` method has a special local called `...`
    that holds the caller's CI object.
    
    Here is the ISeq disasm fo `delegator`:
    
    ```
    == disasm: #<ISeq:delegator@-e:1 (1,0)-(1,39)>
    local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
    [ 1] "..."@0
    0000 putself                                                          (   1)[LiCa]
    0001 getlocal_WC_0                          "..."@0
    0003 send                                   <calldata!mid:delegatee, argc:0, FCALL|FORWARDING>, nil
    0006 leave                                  [Re]
    ```
    
    The local called `...` will contain the caller's CI: CI1.
    
    Here is the stack when we enter `delegator`:
    
    ```
    Executing Line | Code                                  | Stack
    ---------------+---------------------------------------+--------
                  1| def delegatee(a, b) = a + b           | self
                  2|                                       | 1
                  3| def delegator(...)                    | 2
               -> 4|   #                                   | CI1 (argc: 2)
                  5|   delegatee(...)  # CI2 (FORWARDING)  | cref_or_me
                  6| end                                   | specval
                  7|                                       | type
                  8| def caller                            |
                  9|   delegator(1, 2) # CI1 (argc: 2)     |
                 10| end                                   |
    ```
    
    The CI at `delegatee` on line 5 is tagged as "FORWARDING", so it knows to
    memcopy the caller's stack before calling `delegatee`.  In this case, it will
    memcopy self, 1, and 2 to the stack before calling `delegatee`.  It knows how much
    memory to copy from the caller because `CI1` contains stack size information
    (argc: 2).
    
    Before executing the `send` instruction, we push `...` on the stack.  The
    `send` instruction pops `...`, and because it is tagged with `FORWARDING`, it
    knows to memcopy (using the information in the CI it just popped):
    
    ```
    == disasm: #<ISeq:delegator@-e:1 (1,0)-(1,39)>
    local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
    [ 1] "..."@0
    0000 putself                                                          (   1)[LiCa]
    0001 getlocal_WC_0                          "..."@0
    0003 send                                   <calldata!mid:delegatee, argc:0, FCALL|FORWARDING>, nil
    0006 leave                                  [Re]
    ```
    
    Instruction 001 puts the caller's CI on the stack.  `send` is tagged with
    FORWARDING, so it reads the CI and _copies_ the callers stack to this stack:
    
    ```
    Executing Line | Code                                  | Stack
    ---------------+---------------------------------------+--------
                  1| def delegatee(a, b) = a + b           | self
                  2|                                       | 1
                  3| def delegator(...)                    | 2
                  4|   #                                   | CI1 (argc: 2)
               -> 5|   delegatee(...)  # CI2 (FORWARDING)  | cref_or_me
                  6| end                                   | specval
                  7|                                       | type
                  8| def caller                            | self
                  9|   delegator(1, 2) # CI1 (argc: 2)     | 1
                 10| end                                   | 2
    ```
    
    The "FORWARDING" call site combines information from CI1 with CI2 in order
    to support passing other values in addition to the `...` value, as well as
    perfectly forward splat args, kwargs, etc.
    
    Since we're able to copy the stack from `caller` in to `delegator`'s stack, we
    can avoid allocating objects.
    
    I want to do this to eliminate object allocations for delegate methods.
    My long term goal is to implement `Class#new` in Ruby and it uses `...`.
    
    I was able to implement `Class#new` in Ruby
    [here](https://github.com/ruby/ruby/pull/9289
    
    ).
    If we adopt the technique in this patch, then we can optimize allocating
    objects that take keyword parameters for `initialize`.
    
    For example, this code will allocate 2 objects: one for `SomeObject`, and one
    for the kwargs:
    
    ```ruby
    SomeObject.new(foo: 1)
    ```
    
    If we combine this technique, plus implement `Class#new` in Ruby, then we can
    reduce allocations for this common operation.
    
    Co-Authored-By: default avatarJohn Hawthorn <john@hawthorn.email>
    Co-Authored-By: default avatarAlan Wu <XrXr@users.noreply.github.com>
    cdf33ed5
    Optimized forwarding callers and callees
    Aaron Patterson authored
    This patch optimizes forwarding callers and callees. It only optimizes methods that only take `...` as their parameter, and then pass `...` to other calls.
    
    Calls it optimizes look like this:
    
    ```ruby
    def bar(a) = a
    def foo(...) = bar(...) # optimized
    foo(123)
    ```
    
    ```ruby
    def bar(a) = a
    def foo(...) = bar(1, 2, ...) # optimized
    foo(123)
    ```
    
    ```ruby
    def bar(*a) = a
    
    def foo(...)
      list = [1, 2]
      bar(*list, ...) # optimized
    end
    foo(123)
    ```
    
    All variants of the above but using `super` are also optimized, including a bare super like this:
    
    ```ruby
    def foo(...)
      super
    end
    ```
    
    This patch eliminates intermediate allocations made when calling methods that accept `...`.
    We can observe allocation elimination like this:
    
    ```ruby
    def m
      x = GC.stat(:total_allocated_objects)
      yield
      GC.stat(:total_allocated_objects) - x
    end
    
    def bar(a) = a
    def foo(...) = bar(...)
    
    def test
      m { foo(123) }
    end
    
    test
    p test # allocates 1 object on master, but 0 objects with this patch
    ```
    
    ```ruby
    def bar(a, b:) = a + b
    def foo(...) = bar(...)
    
    def test
      m { foo(1, b: 2) }
    end
    
    test
    p test # allocates 2 objects on master, but 0 objects with this patch
    ```
    
    How does it work?
    -----------------
    
    This patch works by using a dynamic stack size when passing forwarded parameters to callees.
    The caller's info object (known as the "CI") contains the stack size of the
    parameters, so we pass the CI object itself as a parameter to the callee.
    When forwarding parameters, the forwarding ISeq uses the caller's CI to determine how much stack to copy, then copies the caller's stack before calling the callee.
    The CI at the forwarded call site is adjusted using information from the caller's CI.
    
    I think this description is kind of confusing, so let's walk through an example with code.
    
    ```ruby
    def delegatee(a, b) = a + b
    
    def delegator(...)
      delegatee(...)  # CI2 (FORWARDING)
    end
    
    def caller
      delegator(1, 2) # CI1 (argc: 2)
    end
    ```
    
    Before we call the delegator method, the stack looks like this:
    
    ```
    Executing Line | Code                                  | Stack
    ---------------+---------------------------------------+--------
                  1| def delegatee(a, b) = a + b           | self
                  2|                                       | 1
                  3| def delegator(...)                    | 2
                  4|   #                                   |
                  5|   delegatee(...)  # CI2 (FORWARDING)  |
                  6| end                                   |
                  7|                                       |
                  8| def caller                            |
              ->  9|   delegator(1, 2) # CI1 (argc: 2)     |
                 10| end                                   |
    ```
    
    The ISeq for `delegator` is tagged as "forwardable", so when `caller` calls in
    to `delegator`, it writes `CI1` on to the stack as a local variable for the
    `delegator` method.  The `delegator` method has a special local called `...`
    that holds the caller's CI object.
    
    Here is the ISeq disasm fo `delegator`:
    
    ```
    == disasm: #<ISeq:delegator@-e:1 (1,0)-(1,39)>
    local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
    [ 1] "..."@0
    0000 putself                                                          (   1)[LiCa]
    0001 getlocal_WC_0                          "..."@0
    0003 send                                   <calldata!mid:delegatee, argc:0, FCALL|FORWARDING>, nil
    0006 leave                                  [Re]
    ```
    
    The local called `...` will contain the caller's CI: CI1.
    
    Here is the stack when we enter `delegator`:
    
    ```
    Executing Line | Code                                  | Stack
    ---------------+---------------------------------------+--------
                  1| def delegatee(a, b) = a + b           | self
                  2|                                       | 1
                  3| def delegator(...)                    | 2
               -> 4|   #                                   | CI1 (argc: 2)
                  5|   delegatee(...)  # CI2 (FORWARDING)  | cref_or_me
                  6| end                                   | specval
                  7|                                       | type
                  8| def caller                            |
                  9|   delegator(1, 2) # CI1 (argc: 2)     |
                 10| end                                   |
    ```
    
    The CI at `delegatee` on line 5 is tagged as "FORWARDING", so it knows to
    memcopy the caller's stack before calling `delegatee`.  In this case, it will
    memcopy self, 1, and 2 to the stack before calling `delegatee`.  It knows how much
    memory to copy from the caller because `CI1` contains stack size information
    (argc: 2).
    
    Before executing the `send` instruction, we push `...` on the stack.  The
    `send` instruction pops `...`, and because it is tagged with `FORWARDING`, it
    knows to memcopy (using the information in the CI it just popped):
    
    ```
    == disasm: #<ISeq:delegator@-e:1 (1,0)-(1,39)>
    local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
    [ 1] "..."@0
    0000 putself                                                          (   1)[LiCa]
    0001 getlocal_WC_0                          "..."@0
    0003 send                                   <calldata!mid:delegatee, argc:0, FCALL|FORWARDING>, nil
    0006 leave                                  [Re]
    ```
    
    Instruction 001 puts the caller's CI on the stack.  `send` is tagged with
    FORWARDING, so it reads the CI and _copies_ the callers stack to this stack:
    
    ```
    Executing Line | Code                                  | Stack
    ---------------+---------------------------------------+--------
                  1| def delegatee(a, b) = a + b           | self
                  2|                                       | 1
                  3| def delegator(...)                    | 2
                  4|   #                                   | CI1 (argc: 2)
               -> 5|   delegatee(...)  # CI2 (FORWARDING)  | cref_or_me
                  6| end                                   | specval
                  7|                                       | type
                  8| def caller                            | self
                  9|   delegator(1, 2) # CI1 (argc: 2)     | 1
                 10| end                                   | 2
    ```
    
    The "FORWARDING" call site combines information from CI1 with CI2 in order
    to support passing other values in addition to the `...` value, as well as
    perfectly forward splat args, kwargs, etc.
    
    Since we're able to copy the stack from `caller` in to `delegator`'s stack, we
    can avoid allocating objects.
    
    I want to do this to eliminate object allocations for delegate methods.
    My long term goal is to implement `Class#new` in Ruby and it uses `...`.
    
    I was able to implement `Class#new` in Ruby
    [here](https://github.com/ruby/ruby/pull/9289
    
    ).
    If we adopt the technique in this patch, then we can optimize allocating
    objects that take keyword parameters for `initialize`.
    
    For example, this code will allocate 2 objects: one for `SomeObject`, and one
    for the kwargs:
    
    ```ruby
    SomeObject.new(foo: 1)
    ```
    
    If we combine this technique, plus implement `Class#new` in Ruby, then we can
    reduce allocations for this common operation.
    
    Co-Authored-By: default avatarJohn Hawthorn <john@hawthorn.email>
    Co-Authored-By: default avatarAlan Wu <XrXr@users.noreply.github.com>
Loading