This patch optimizes forwarding callers and callees. It only optimizes methods that only take ... as their parameter, and then pass ... to other calls.
All variants of the above but using super are also optimized, including a bare super like this:
deffoo(...)superend
This patch eliminates intermediate allocations made when calling methods that accept ....
We can observe allocation elimination like this:
defmx=GC.stat(:total_allocated_objects)yieldGC.stat(:total_allocated_objects)-xenddefbar(a)=adeffoo(...)=bar(...)deftestm{foo(123)}endtestptest# allocates 1 object on master, but 0 objects with this patch
defbar(a,b:)=a+bdeffoo(...)=bar(...)deftestm{foo(1,b: 2)}endtestptest# allocates 2 objects on master, but 0 objects with this patch
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.
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.
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):
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.
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:
SomeObject.new(foo: 1)
If we combine this technique, plus implement Class#new in Ruby, then we can
reduce allocations for this common operation.
Optimized forwarding callers and callees
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:
All variants of the above but using
superare also optimized, including a bare super like this:This patch eliminates intermediate allocations made when calling methods that accept
....We can observe allocation elimination like this:
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.
Before we call the delegator method, the stack looks like this:
The ISeq for
delegatoris tagged as "forwardable", so whencallercalls into
delegator, it writesCI1on to the stack as a local variable for thedelegatormethod. Thedelegatormethod has a special local called...that holds the caller's CI object.
Here is the ISeq disasm fo
delegator:The local called
...will contain the caller's CI: CI1.Here is the stack when we enter
delegator:The CI at
delegateeon line 5 is tagged as "FORWARDING", so it knows tomemcopy the caller's stack before calling
delegatee. In this case, it willmemcopy self, 1, and 2 to the stack before calling
delegatee. It knows how muchmemory to copy from the caller because
CI1contains stack size information(argc: 2).
Before executing the
sendinstruction, we push...on the stack. Thesendinstruction pops..., and because it is tagged withFORWARDING, itknows to memcopy (using the information in the CI it just popped):
Instruction 001 puts the caller's CI on the stack.
sendis tagged withFORWARDING, so it reads the CI and copies the callers stack to this stack:
The "FORWARDING" call site combines information from CI1 with CI2 in order
to support passing other values in addition to the
...value, as well asperfectly forward splat args, kwargs, etc.
Since we're able to copy the stack from
callerin todelegator's stack, wecan avoid allocating objects.
I want to do this to eliminate object allocations for delegate methods.
My long term goal is to implement
Class#newin Ruby and it uses....I was able to implement
Class#newin Rubyhere.
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 onefor the kwargs:
If we combine this technique, plus implement
Class#newin Ruby, then we canreduce allocations for this common operation.
Co-Authored-By: John Hawthorn [email protected]
Co-Authored-By: Alan Wu [email protected]