Fiber

Fiber implements an proof-of-concept Python decorator that rewrites a function so that it can be paused and resumed (by moving stack variables to a heap frame and adding if statements to simulate jumps/gotos to specific lines of code).

Then, using a trampoline function that simulates the call stack on the heap, we can call functions that recurse arbitrarily deeply without stack overflowing (assuming we don't run out of heap memory).

cache = {}

@fiber.fiber(locals=locals())
def fib(n):
    assert n >= 0
    if n in cache:
        return cache[n]
    if n == 0:
        return 0
    if n == 1:
        return 1
    cache[n] = fib(n-1) + fib(n-2)
    return cache[n]

print(sys.getrecursionlimit())  # 1000 by default

# https://www.wolframalpha.com/input/?i=fib%281010%29+mod+10**5
print(trampoline.run(fib, [1010]) % 10 ** 5) # 74305

Please do not use this in production.

TOC

• Fiber
  • How it works
  • Performance
  • Limitations
    • Possible improvements
  • Questions
    • Why didn't you use Python generators?
    • Why did you write this?
  • Contributing
  • License
  • Disclaimer

How it works

A quick refresher on the call stack: normally, when some function A calls another function B, A is "paused" while B runs to completion. Then, once B finishes, A is resumed.

In order to move the call stack to the heap, we need to transform function A to (1) store all variables on the heap, and (2) be able to resume execution at specific lines of code within the function.

The first step is easy: we rewrite all local loads and stores to instead load and store in a frame dictionary that is passed into the function. The second is more difficult: because Python doesn't support goto statements, we have to insert if statements to skip the code prefix that we don't want to execute.

There are a variety of "special forms" that cannot be jumped into. These we must handle by rewriting them into a form that we do handle.

For example, if we recursively call a function inside a for loop, we would like to be able to resume execution on the same iteration. However, when Python executes a for loop on an non-iterator iterable it will create a new iterator every time. To handle this case, we rewrite for loops into the equivalent while loop. Similarly, we must rewrite boolean expressions that short circuit (and, or) into the equivalent if statements.

Lastly, we must replace all recursive calls and normal returns by instead returning an instruction to a trampoline to call the child function or return the value to the parent function, respectively.

To recap, here are the AST passes we currently implement:

1. Rewrite special forms:
   • for_to_while: Transforms for loops into the equivalent while loops.
   • promote_while_cond: Rewrites the while conditional to use a temporary variable that is updated every loop iteration so that we can control when it is evaluated (e.g. if the loop condition includes a recursive call).
   • bool_exps_to_if: Converts and and or expressions into the equivalent if statements.
2. promote_to_temporary: Assigns the results of recursive calls into temporary variables. This is necessary when we make multiple recursive calls in the same statement (e.g. fib(n-1) + fib(n-2)): we need to resume execution in the middle of the expression.
3. remove_trivial_temporaries: Removes temporaries that are assigned to only once and are directly assigned to some other variable, replacing subsequent usages with that other variable. This helps us detect tail calls.
4. insert_jumps: Marks the statement after yield points (currently recursive calls and normal returns) with a pc index, and inserts if statements so that re-execution of the function will resume at that program counter.
5. lift_locals_to_frame: Replaces loads and stores of local variables to loads and stores in the frame object.
6. add_trampoline_returns: Replaces places where we must yield (recursive calls and normal returns) with returns to the trampoline function.
7. fix_fn_def: Rewrites the function defintion to take a frame parameter.

See the examples directory for functions and the results after each AST pass. Also, see src/trampoline_test.py for some test cases.

Performance

A simple tail-recursive function that computes the sum of an array takes about 10-11 seconds to compute with Fiber. 1000 iterations of the equivalent for loop takes 7-8 seconds to compute. So we are slower by roughly a factor of 1000.

lst = list(range(1, 100001))

# fiber
@fiber.fiber(locals=locals())
def sum(lst, acc):
    if not lst:
        return acc
    return sum(lst[1:], acc + lst[0])

# for loop
total = 0
for i in lst:
    total += i

print(total, trampoline.run(sum, [lst, 0]))  # 5000050000, 5000050000

We could improve the performance of the code by eliminating redundant if checks in the generated code. Also, as we statically know the stack variables, we can use an array for the stack frame and integer indexes (instead of a dictionary and string hashes + lookups). This should improve the performance significantly, but there will still probably be a large amount of overhead.

Another performance improvement is to inline the stack array: instead of storing a list of frames in the trampoline, we could variables directly in the stack. Again, we can compute the frame size statically. Based on some tests in a handwritten JavaScript implementation, this has the potential to speed up the code by roughly a factor of 2-3, at the cost of a more complex implementation.

Limitations

• The transformation works on the AST level, so we don't support other decorators (for example, we cannot use functools.cache in the above Fibonacci example).

• The function can only access variables that are passed in the locals= argument. As a consequence of this, to resolve recursive function calls, we maintain a global mapping of all fiber functions by name. This means that fibers must have distinct names.

• We don't support some special forms (ternaries, comprehensions). These can easily be added as a rewrite transformation.

• We don't support exceptions. This would require us to keep track of exception handlers in the trampoline and insert returns to the trampoline to register and deregister handlers.

• We don't support generators. To add support, we would have to modify the trampoline to accept another operation type (yield) that sends a value to the function that called next(). Also, the trampoline would have to support multiple call stacks.

Possible improvements

• Improve test coverage on some of the AST transformations.
  • remove_trivial_temporaries may have a bug if the variable that it is replaced with is reassigned to another value.
• Support more special forms (comprehensions, generators).
• Support exceptions.
• Support recursive calls that don't read the return value.

Questions

Why didn't you use Python generators?

It's less interesting as the transformations are easier. Here, we are effectively implementing generators in userspace (i.e. not needing VM support); see the answer to the next question for why this is useful.

Also, people have used generators to do this; see one recent generator example.

Why did you write this?

• A+ project for CS 61A at Berkeley. During the course, we created a Scheme interpreter. The extra credit question we to replace tail calls in Python with a return to a trampoline, with the goal that tail call optimization in Python would let us evaluate tail calls to arbitrary depth in Scheme, in constant space.

  The test cases for the question checked whether interpreting tail-call recursive functions in Scheme caused a Python stack overflow. Using this Fiber implementation, (1) without tail call optimization in our trampoline, we would still be able to pass the test cases (we just wouldn't use constant space) and (2) we can now evaluate any Scheme expression to arbitrary depth, even if they are not in tail form.

• The React framework has an a bug open which explores a compiler transform to rewrite JavaScript generators to a state machine so that recursive operations (render, reconcilation) can be written more easily. This is necessary because some JavaScript engines still don't support generators.

  This project basically implements a rough version of that compiler transform as a proof of concept, just in Python. https://github.com/facebook/react/pull/18942

Contributing

See CONTRIBUTING.md for more details.

License

Apache 2.0; see LICENSE for more details.

Disclaimer

This is a personal project, not an official Google project. It is not supported by Google and Google specifically disclaims all warranties as to its quality, merchantability, or fitness for a particular purpose.