diff --git a/README.md b/README.md
index f53fdea4..5206932f 100644
--- a/README.md
+++ b/README.md
@@ -47,14 +47,14 @@ Documentation
- The [User Manual](docs/User-Manual.md) covers in detail how to use Cyclone, and provides information and API documentation on the Scheme language features implemented by Cyclone.
+- [Writing the Cyclone Scheme Compiler](docs/Writing-the-Cyclone-Scheme-Compiler-Revised-2017.md) provides high-level details on how the compiler was written and how it works.
+
- There is a [Development Guide](docs/Development.md) with instructions for common tasks when hacking on the compiler itself.
- Cyclone's [Garbage Collector](docs/Garbage-Collector.md) is documented at a high-level. This document includes details on extending Cheney on the MTA to support multiple stacks and fusing that approach with a tri-color marking collector.
- This [Benchmarks](http://ecraven.github.io/r7rs-benchmarks/benchmark.html) page by [ecraven](https://github.com/ecraven) compares the performance of Cyclone with other R7RS and R6RS Schemes using a common set of benchmarks.
-- [Writing the Cyclone Scheme Compiler](docs/Writing-the-Cyclone-Scheme-Compiler.md) provides high-level details on how the compiler was written and how it works.
-
- Finally, if you need another resource to start learning the Scheme language you may want to try a classic textbook such as [Structure and Interpretation of Computer Programs](https://mitpress.mit.edu/sicp/full-text/book/book.html).
Example Programs
diff --git a/docs/Garbage-Collector.md b/docs/Garbage-Collector.md
index 81ff0273..1b52d204 100644
--- a/docs/Garbage-Collector.md
+++ b/docs/Garbage-Collector.md
@@ -168,7 +168,7 @@ The collector swaps the values of the clear color (white) and the mark color (bl
### Mark
-The collector transitions to sync 2 and then async. At this point it marks the global variables and waits for the mutators to also transition to async:
+The collector transitions to sync 2 and then async. At this point it marks the global variables and waits for the mutators to also transition to async. When a mutator transitions it will mark its roots and use black as the allocation color to prevent any new objects from being collected during this cycle:
diff --git a/docs/Writing-the-Cyclone-Scheme-Compiler-Revised-2017.md b/docs/Writing-the-Cyclone-Scheme-Compiler-Revised-2017.md
new file mode 100644
index 00000000..2ec219af
--- /dev/null
+++ b/docs/Writing-the-Cyclone-Scheme-Compiler-Revised-2017.md
@@ -0,0 +1,474 @@
+[
](http://github.com/justinethier/cyclone)
+
+# Writing the Cyclone Scheme Compiler
+
+## Revised for 2017
+
+###### by [Justin Ethier](https://github.com/justinethier)
+
+This write-up is an attempt to provide a high level background on the various components of Cyclone and how they were written. It is a revision of the [original write-up](Writing-the-Cyclone-Scheme-Compiler.md), written over a year ago in August 2015, when the compiler was self hosting but before the new garbage collector was written. So much time has passed that I thought it would be worthwhile to provide a brain dump of sorts for everything that has happened in the last year and half.
+
+Before we get started, I want to say **Thank You** to all of the contributors to the Scheme community. Cyclone is based on the community's latest revision of the Scheme language and wherever possible existing code was reused or repurposed for this project, instead of starting from scratch. At the end of this document is a list of helpful online resources. Without high quality Scheme resources like these the Cyclone project would not have been possible.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [Source-to-Source Transformations](#source-to-source-transformations)
+ - [Just Make Many Small Passes](#just-make-many-small-passes)
+ - [Macro Expansion](#macro-expansion)
+ - [CPS Conversion](#cps-conversion)
+ - [CPS Optimizations](#cps-optimizations)
+ - [Closure Conversion](#closure-conversion)
+ - [C Code Generation](#c-code-generation)
+ - [Native Compilation](#native-compilation)
+- [Garbage Collector](#garbage-collector)
+ - [Background: Cheney on the MTA](#background-cheney-on-the-mta)
+ - [Cyclone's Hybrid Collector](#cyclones-hybrid-collector)
+ - [Major Garbage Collection Algorithm](#major-garbage-collection-algorithm)
+ - [Developing the New Collector](#developing-the-new-collector)
+ - [Heap Data Structures](#heap-data-structures)
+- [C Runtime](#c-runtime)
+ - [Data Types](#data-types)
+ - [Thread Data Parameter](#thread-data-parameter)
+ - [Call History](#call-history)
+ - [Exception Handling](#exception-handling)
+- [Scheme Libraries](#scheme-libraries)
+ - [Native Thread Support](#native-thread-support)
+ - [Reader](#reader)
+ - [Interpreter](#interpreter)
+ - [Compiler Internals](#compiler-internals)
+- [Scheme Standards](#scheme-standards)
+- [Benchmarks](#benchmarks)
+- [Future](#future)
+- [Conclusion](#conclusion)
+- [Terms](#terms)
+- [References](#references)
+
+## Overview
+
+Cyclone has a similar architecture to other modern compilers:
+
+
+
+First, an input file containing Scheme code is received on the command line and loaded into an abstract syntax tree (AST) by Cyclone's parser. From there a series of source-to-source transformations are performed on the AST to expand macros, perform optimizations, and make the code easier to compile to C. These intermediate representations (IR) can be printed out in a readable format to aid debugging. The final AST is then output as a `.c` file and the C compiler is invoked to create the final executable or object file.
+
+Programs are linked with the necessary Scheme libraries and the Cyclone runtime library to create an executable:
+
+
+
+## Source-to-Source Transformations
+
+### Overview
+
+My primary inspiration for Cyclone was Marc Feeley's [The 90 minute Scheme to C compiler](http://churchturing.org/y/90-min-scc.pdf) (also [video 1](https://www.youtube.com/watch?v=HIr9eO1kB8g), [video 2](https://www.youtube.com/watch?v=TxOM9Y5YrCs), and [code](https://github.com/justinethier/nugget/tree/master/90-min-scc)). Over the course of 90 minutes, Feeley demonstrates how to compile Scheme to C code using source-to-source transformations, including closure and continuation-passing-style (CPS) conversions.
+
+As outlined in the presentation, some of the difficulties in compiling to C are:
+
+> Scheme has, and C does not have
+>
+> - tail-calls a.k.a. tail-recursion optimization
+> - first-class continuations
+> - closures of indefinite extent
+> - automatic memory management i.e. garbage collection (GC)
+>
+> Implications
+>
+> - cannot translate (all) Scheme calls into C calls
+> - have to implement continuations
+> - have to implement closures
+> - have to organize things to allow GC
+>
+> The rest is easy!
+
+To overcome these difficulties a series of source-to-source transformations are used to remove powerful features not provided by C, add constructs required by the C code, and restructure/relabel the code in preparation for generating C. The final code may be compiled direcly to C. Cyclone also includes many other intermediate transformations, including:
+
+- Macro expansion
+- Processing of globals
+- [Alpha conversion](https://wiki.haskell.org/Alpha_conversion)
+- [CPS conversion](https://en.wikipedia.org/wiki/Continuation-passing_style)
+- [Closure conversion](http://matt.might.net/articles/closure-conversion/)
+
+The 90-minute compiler ultimately compiles the code down to a single function and uses jumps to support continuations. This is a bit too limiting for a production compiler, so that part was not used.
+
+### Just Make Many Small Passes
+
+To make Cyclone easier to maintain a separate pass is made for each transformation. This allows Cyclone's code to be as simple as possible and minimizes dependencies so there is less chance of changes to one transformation breaking the code for another.
+
+Internally Cyclone represents the code being compiled as an AST of regular Scheme objects. Since Scheme represents both code and data using [S-expressions](https://en.wikipedia.org/wiki/S-expression), our compiler does not (in general) have to use custom abstract data types to store the code as would be the case with many other languages.
+
+Most of the transformations follow a similar pattern of recursively examining an expression. Here is a short example that demonstrates the code structure:
+
+ (define (search exp)
+ (cond
+ ((const? exp) '())
+ ((prim? exp) '())
+ ((quote? exp) '())
+ ((ref? exp) (if bound-only? '() (list exp)))
+ ((lambda? exp)
+ (difference (reduce union (map search (lambda->exp exp)) '())
+ (lambda-formals->list exp)))
+ ((if-syntax? exp) (union (search (if->condition exp))
+ (union (search (if->then exp))
+ (search (if->else exp)))))
+ ((define? exp) (union (list (define->var exp))
+ (search (define->exp exp))))
+ ((define-c? exp) (list (define->var exp)))
+ ((set!? exp) (union (list (set!->var exp))
+ (search (set!->exp exp))))
+ ((app? exp) (reduce union (map search exp) '()))
+ (else (error "unknown expression: " exp))))
+
+The [Nanopass Framework](https://github.com/nanopass/nanopass-framework-scheme) was created to make it easier to write a compiler that makes many small passes over the code. Unfortunately Nanopass itself is written in R6RS and could not be used for this project.
+
+### Macro Expansion
+
+Macro expansion is one of the first transformations. Any macros the compiler knows about are loaded as functions into a macro environment, and a single pass is made over the code. When the compiler finds a macro the code is expanded by calling the macro. The compiler then inspects the resulting code again in case the macro expanded into another macro.
+
+At the lowest level, Cyclone's [explicit renaming](http://wiki.call-cc.org/explicit-renaming-macros) (ER) macros provide a simple, low-level macro system that does not require much more than `eval`. Many ER macros from [Chibi Scheme](https://github.com/ashinn/chibi-scheme) are used to implement the built-in macros in Cyclone.
+
+Cyclone also supports the high-level `syntax-rules` system from the Scheme reports. Syntax rules is implemented as [a huge ER macro](https://github.com/justinethier/cyclone/blob/v0.3.3/scheme/base.sld#L1242) ported from Chibi Scheme.
+
+As a simple example the `let` macro below:
+
+ (let ((square (lambda (x) (* x x))))
+ (write (+ (square 10) 1)))
+
+is expanded to:
+
+ (((lambda (square) (write (+ (square 10) 1)))
+ (lambda (x) (* x x))))
+
+### CPS Conversion
+
+The conversion to continuation passing style (CPS) makes continuations explicit in the compiled code. This is a critical step to make the Scheme code simple enough that it can be represented by C. As we will see later, the runtime's garbage collector also requires code in CPS form.
+
+The basic idea is that each expression will produce a value that is consumed by the continuation of the expression. Continuations will be represented using functions. All of the code must be rewritten to accept a new continuation parameter `k` that will be called with the result of the expression. For example, considering the previous `let` example:
+
+ (((lambda (square) (write (+ (square 10) 1)))
+ (lambda (x) (* x x))))
+
+the code in CPS form becomes:
+
+ ((lambda (r)
+ ((lambda (square)
+ (square
+ (lambda (r)
+ ((lambda (r) (write r))
+ (+ r 1)))
+ 10))
+ r))
+ (lambda (k x) (k (* x x))))
+
+### CPS Optimizations
+
+CPS conversion generates too much code and is inefficient for functions such as primitives that can return a result directly instead of calling into a continuation. So we need to optimize it to make the compiler practical. For example, the previous CPS code can be simplified to:
+
+ ((lambda (k x) (k (* x x)))
+ (lambda (r)
+ (write (+ r 1)))
+ 10)
+
+One of the most effective optimizations is inlining of primitives. That is, some runtime functions can be called directly, so an enclosing `lambda` is not needed to evaluate them. This can greatly reduce the amount of generated code.
+
+A contraction phase is also used to eliminate other unnecessary `lambda`'s. There are a few other miscellaneous optimizations such as constant folding, which evaluates certain primitives at compile time if the parameters are constants.
+
+To more efficiently identify optimizations Cyclone first makes a code pass to build up an hash table-based analysis database (DB) of various attributes. This is the same strategy employed by CHICKEN, although each compiler records different attributes. The DB contains a table of records with an entry for each variable (indexed by symbol) and each function (indexed by unique ID).
+
+In order to support the analysis DB a custom AST is used to represent functions during this phase, so that each one can be tagged with a unique identification number. After optimizations are complete, the lambdas are converted back into regular S-expressions.
+
+### Closure Conversion
+
+Free variables passed to a nested function must be captured in a closure so they can be referenced at runtime. The closure conversion transformation modifies lambda definitions as necessary to create new closures. It also replaces free variable references with lookups from the current closure.
+
+Cyclone uses flat closures: objects that contain a single function reference and a vector of free variables. This is a more efficient representation than an environment as only a single vector lookup is required to read any of the free variables.
+
+Mutated variables are not directly supported by flat closures and must be added to a pair (called a "cell") by a separate compilation pass prior to closure conversion.
+
+Cyclone's closure conversion is based on code from Marc Feeley's 90 minute Scheme->C compiler and Matt Might's Scheme->C compiler.
+
+### C Code Generation
+
+The compiler's code generation phase takes a single pass over the transformed Scheme code and outputs C code to the current output port (usually a `.c` file).
+
+During this phase C code is sometimes saved for later use instead of being output directly. For example, when compiling a vector literal or a series of function arguments, the code is returned as a list of strings that separates variable declarations from C code in the "body" of the generated function.
+
+The C code is carefully generated so that a Scheme library (`.sld` file) is compiled into a C module. Functions and variables exported from the library become C globals in the generated code.
+
+### Native Compilation
+
+The C compiler is invoked to generate machine code for the Scheme module, and to also create an executable if a Scheme program is being compiled.
+
+## Garbage Collector
+
+### Background: Cheney on the MTA
+A runtime based on Henry Baker's paper [CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A.](http://www.pipeline.com/~hbaker1/CheneyMTA.html) was used as it allows for fast code that meets all of the fundamental requirements for a Scheme runtime: tail calls, garbage collection, and continuations.
+
+Baker explains how it works:
+
+> We propose to compile Scheme by converting it into continuation-passing style (CPS), and then compile the resulting lambda expressions into individual C functions. Arguments are passed as normal C arguments, and function calls are normal C calls. Continuation closures and closure environments are passed as extra C arguments. Such a Scheme never executes a C return, so the stack will grow and grow ... eventually, the C "stack" will overflow the space assigned to it, and we must perform garbage collection.
+
+Cheney on the M.T.A. uses a copying garbage collector. By using static roots and the current continuation closure, the GC is able to copy objects from the stack to a pre-allocated heap without having to know the format of C stack frames. To quote Baker:
+
+> the entire C "stack" is effectively the youngest generation in a generational garbage collector!
+
+After GC is finished, the C stack pointer is reset using [`longjmp`](http://man7.org/linux/man-pages/man3/longjmp.3.html) and the GC calls its continuation.
+
+Here is a snippet demonstrating how C functions may be written using Baker's approach:
+
+ object Cyc_make_vector(object cont, object len, object fill) {
+ object v = NULL;
+ int i;
+ Cyc_check_int(len);
+
+ // Memory for vector can be allocated directly on the stack
+ v = alloca(sizeof(vector_type));
+
+ // Populate vector object
+ ((vector)v)->tag = vector_tag;
+ ...
+
+ // Check if GC is needed, then call into continuation with the new vector
+ return_closcall1(cont, v);
+ }
+
+[CHICKEN](http://www.call-cc.org/) was the first Scheme compiler to use Baker's approach.
+
+### Cyclone's Hybrid Collector
+
+Baker's technique uses a copying collector for both the minor and major generations of collection. One of the drawbacks of using a copying collector for major GC is that it relocates all the live objects during collection. This is problematic for supporting native threads because an object can be relocated at any time, invalidating any references to the object. To prevent this either all threads must be stopped while major GC is running or a read barrier must be used each time an object is accessed. Both options add a potentially significant overhead so instead Cyclone uses another type of collector for the second generation.
+
+To that end, Cyclone supports uses a tri-color tracing collector based on the Doligez-Leroy-Gonthier (DLG) algorithm for major collections. The DLG algorithm was selected in part because many state-of-the-art collectors are built on top of DLG such as Chicken, Clover, and Schism. So this may allow for further enhancements down the road.
+
+Under Cyclone's runtime each thread contains its own stack that is used for private thread allocations. Thread stacks are managed independently using Cheney on the MTA. Each object that survives one of these minor collections is copied from the stack to a newly-allocated slot on the heap.
+
+Heap objects are not relocated, making it easier for the runtime to support native threads. In addition major GC uses a collector thread that executes asynchronously so application threads can continue to run concurrently even during collections.
+
+In summary:
+
+- All objects on the stack are collected using Cheney on the MTA, and the ones that survive are placed on the heap.
+- Heap objects are collected during Major GC using the DLG algorithm.
+- Heap collection runs on a separate thread in parallel with application threads.
+
+### Major Garbage Collection Algorithm
+
+Each object is marked with a specific color (white, gray, or black) that determines how it will be handled during a major collection. Major GC transitions through the following states:
+
+#### Clear
+The collector thread swaps the values of the clear color (white) and the mark color (black). This is more efficient than modifying the color on each object in the heap. The collector then transitions to sync 1. At this point no heap objects are marked, as demonstrated below:
+
+
+
+#### Mark
+The collector thread transitions to sync 2 and then async. At this point it marks the global variables and waits for the application threads to also transition to async. When an application thread transitions it will:
+
+- Mark its roots black.
+- Gray any child objects of the roots. The collector thread traces these gray objects during the next phase.
+- Use black as the allocation color to prevent any new objects from being collected during this cycle.
+
+
+
+#### Trace
+The collector thread finds all live objects using a breadth-first search and marks them black:
+
+
+
+#### Sweep
+The collector thread scans the heap and frees memory used by all white objects:
+
+
+
+If the heap is still low on memory at this point the heap will be increased in size. Also, to ensure a complete collection, data for any terminated threads is not freed until now.
+
+More details are available in a separate [Garbage Collector](Garbage-Collector.md) document.
+
+### Developing the New Collector
+
+It took a long time to research and plan out the new GC before it could be implemented. There was a noticeable lull in Github contributions during that time:
+
+
+
+The actual development consisted of several distinct phases:
+
+- Phase 0 - Started with a runtime using a basic Cheney-style copying collector.
+- Phase 1 - Added new definitions via `gc.h` and made sure everything compiles.
+- Phase 2 - Changed how strings are allocated to clean up the code and be compatible with the new GC algorithm. This was mainly just an exercise in cleaning up cruft in the old Cyclone implementation.
+- Phase 3 - Changed major GC from using a Cheney-style copying collector to a naive mark-and-sweep algorithm. The new algorithm was based on code from Chibi Scheme so it was already debugged and would serve as a solid foundation for future work.
+- Phase 4 - Integrated code for a new tracing GC algorithm but did not cut over to it yet. Added a new thread data argument to all of the necessary runtime functions - a simple but far-reaching change that affected almost all functions in the runtime and compiled code.
+- Phase 5 - Required the pthreads library and stood Cyclone back up using the new GC algorithm for the first time.
+- Phase 6 - Added SRFI 18 to support multiple application threads.
+
+### Heap Data Structures
+
+Cyclone allocates heap data one page at a time. Each page is several megabytes in size and can store multiple Scheme objects. Cyclone will start with a small initial page size and gradually allocate larger pages using the Fibonnaci Sequence until reaching a maximum size.
+
+Each page contains a linked list of free objects that is used to find the next available slot for an allocation. An entry on the free list will be split if it is larger than necessary for an allocation; the remaining space will remain in the free list for the next allocation.
+
+Cyclone allocates smaller objects in fixed size heaps to minimize allocation time and prevent heap fragmentation. The runtime also remembers the last page of the heap that was able to allocate memory, greatly reducing allocation time on larger heaps.
+
+The heap data structures and associated algorithms are based on code from Chibi scheme.
+
+## C Runtime
+
+### Overview
+
+The C runtime provides supporting features to compiled Scheme programs including a set of primitive functions, call history, exception handling, and garbage collection.
+
+An interesting observation from R. Kent Dybvig [[11]](#references) that I have tried to keep in mind is that performance optimizations in the runtime can be just as (if not more) important that higher level CPS optimizations:
+
+> My focus was instead on low-level details, like choosing efficient representations and generating good instruction sequences, and the compiler did include a peephole optimizer. High-level optimization is important, and we did plenty of that later, but low-level details often have more leverage in the sense that they typically affect a broader class of programs, if not all programs.
+
+### Data Types
+
+#### Objects
+
+Most Scheme data types are represented as objects that are allocated in heap/stack memory. Each type of object has a corresponding C structure that defines its fields, such as the following one for pairs:
+
+ typedef struct {
+ gc_header_type hdr;
+ tag_type tag;
+ object pair_car;
+ object pair_cdr;
+ } pair_type;
+
+All objects have:
+
+- A `gc_header_type` field that contains marking information for the garbage collector.
+- A tag to identify the object type.
+- One or more additional fields containing the actual object data.
+
+#### Value Types
+
+On the other hand, some data types can be represented using 30 bits or less and are stored as value types. The great thing about value types is they do not have to be garbage collected because no extra data is allocated for them. This makes them super efficient for commonly-used data types.
+
+Value types are stored using a common technique that is described in Lisp in Small Pieces (among other places). On many machines addresses are multiples of four, leaving the two least significant bits free. [A brief explanation](http://stackoverflow.com/q/9272526/101258):
+
+> The reason why most pointers are aligned to at least 4 bytes is that most pointers are pointers to objects or basic types that themselves are aligned to at least 4 bytes. Things that have 4 byte alignment include (for most systems): int, float, bool (yes, really), any pointer type, and any basic type their size or larger.
+
+In Cyclone the two least significant bits are used to indicate the following data types:
+
+Binary Bit Pattern | Data Type
+------------------ | ---------
+00 | Pointer (an object type)
+01 | Integer
+10 | Character
+
+Booleans are potentially another good candidate for values types. But for the time being they are represented in the runtime using pointers to the constants `boolean_t` and `boolean_f`.
+
+### Thread Data Parameter
+
+At runtime Cyclone passes the current continuation, number of arguments, and a thread data parameter to each compiled C function. The continuation and arguments are used by the application code to call into its next function with a result. Thread data is a structure that contains all of the necessary information to perform collections, including:
+
+- Thread state
+- Stack boundaries
+- Cheney on the MTA jump buffer
+- List of mutated objects detected by the minor GC write barrier
+- Parameters for major GC
+- Call history buffer
+- Exception handler stack
+
+Each thread has its own instance of the thread data structure and its own stack (assigned by the C runtime/compiler).
+
+### Call History
+
+Each thread maintains a circular buffer of call history that is used to provide debug information in the event of an error. The buffer itself consists of an array of pointers-to-strings. The compiler emits calls to runtime function `Cyc_st_add` that will populate the buffer when the program is running. `Cyc_st_add` must be fast as it is called all the time! So it does the bare minimum - update the pointer at the current buffer index and increment the index.
+
+### Exception Handling
+
+A family of `Cyc_rt_raise` functions is provided to allow an exception to be raised for the current thread. These functions gather the required arguments and use `apply` to call the thread's current exception handler. The handler is part of the thread data parameter, so any functions that raise an exception must receive that parameter.
+
+A Scheme API for exception handling is provided as part of R7RS.
+
+## Scheme Libraries
+
+This section describes a few notable parts of [Cyclone's Scheme API](API.md).
+
+### Native Thread Support
+
+A multithreading API is provided based on [SRFI 18](http://justinethier.github.io/cyclone/docs/api/srfi/18). Most of the work to support multithreading is accomplished by the runtime and garbage collector.
+
+Cyclone attempts to support multithreading in an efficient way that minimizes the amount of synchronization among threads. But objects are still copied during minor GC. In order for an object to be shared among threads the application must guarantee the object is no longer on the stack. One solution is for application code to initiate a minor GC before an object is shared with other threads, to guarantee the object will henceforth not be relocated.
+
+### Reader
+
+Cyclone uses a combined lexer / parser to read S-expressions. Input is processed one character at a time and either added to the current token or discarded if it is whitespace, part of a comment, etc. Once a terminating character is read the token is inspected and converted to an appropriate Scheme object. For example, a series of numbers may be converted into an integer.
+
+The full implementation is written in Scheme and located in the `(scheme read)` library.
+
+### Interpreter
+
+The `eval` function is written in Scheme, using code from the [Metacircular Evaluator](https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-26.html#%_sec_4.1) from [SICP](https://mitpress.mit.edu/sicp/full-text/book/book.html) as a starting point.
+
+The interpreter itself is straightforward but there is nice speed up to be had by separating syntactic analysis from execution. It would be interesting see what kind of performance improvements could be obtained by compiling to VM bytecodes or even using a JIT compiler.
+
+The interpreter's full implementation is available in the `(scheme eval)` library, and the `icyc` executable is provided for convenient access to a REPL.
+
+### Compiler Internals
+
+Most of the Cyclone compiler is implemented in Scheme as [a series of libraries](API.md#cyclone-compiler-api).
+
+## Scheme Standards
+
+Cyclone targets the [R7RS-small specification](https://github.com/justinethier/cyclone/raw/master/docs/r7rs.pdf). This spec is relatively new and provides incremental improvements from the popular [R5RS spec](http://www.schemers.org/Documents/Standards/R5RS/HTML/). Library support is the most important new feature but there are also exceptions, system interfaces, and a more consistent API.
+
+## Benchmarks
+
+[ecraven](https://github.com/ecraven) has put together an excellent set of [Scheme benchmarks](http://ecraven.github.io/r7rs-benchmarks/benchmark.html) based on a R7RS suite from the Larceny project. These are the typical benchmarks that many implementations have used over the years, but the remarkable thing here is all of the major implementations are supported, allowing a rare apples-to-apples comparison among all the widely-used Schemes.
+
+Over the past year Cyclone has matured to the point where almost all of the 56 benchmarks will run:
+
+
+
+The remaining ones are:
+
+- `mbrotZ` fails because Cyclone does not support complex numbers yet.
+- `pi` does not work because Cyclone does not support bignums yet.
+- `compiler` passes but returns the wrong result. This will be fun to track down since the program is huge and takes a long time to compile...
+
+Regarding performance, from Feeley's presentation [[10]](#references):
+
+> Performance is not so bad with NO optimizations (about 6 times slower than Gambit-C with full optimization)
+
+But Cyclone has some optimizations now, doesn't it? The following is a chart of total runtime in minutes for the benchmarks that each Scheme passes successfully. This metric is problematic because not all of the Schemes can run all of the benchmarks but it gives a general idea of how well they compare to each other. Cyclone performs well against all of the interpreters but still has a long ways to go to match top-tier compilers. Then again, most of these compilers have been around for a decade or longer:
+
+
+
+## Future
+
+Some goals for the future are:
+
+- Implement more of R7RS-large; work has already started on the data structures side.
+- Implement more libraries (for example, by porting some of [industria](https://github.com/weinholt/industria) to r7rs).
+- Improve the garbage collector. Possibly by allowing more than one collector thread (Per gambit's parallel GC).
+- Perform additional optimizations, EG:
+
+ Andrew Appel used a similar runtime for [Standard ML of New Jersey](http://www.smlnj.org/) which is referenced by Baker's paper. Appel's book [Compiling with Continuations](http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X) includes a section on how to implement compiler optimizations - many of which could still be applied to Cyclone.
+
+In addition, developing [Husk Scheme](http://justinethier.github.io/husk-scheme) helped me gather much of the knowledge that would later be used to create Cyclone. In fact the primary motivation in building Cyclone was to go a step further and understand how to build a full, free-standing Scheme system. At this point Cyclone has eclipsed the speed and functionality of Husk and it is not clear if Husk will receive much more than bug fixes going forward. Perhaps if there is interest from the community some of this work can be ported back to that project.
+
+## Conclusion
+
+Thanks for reading!
+
+Want to give Cyclone a try? Install a copy using [cyclone-bootstrap](https://github.com/justinethier/cyclone-bootstrap).
+
+## Terms
+
+- Abstract Syntax Tree (AST) - A tree representation of the syntactic structor of source code written in a programming language. Sometimes S-expressions can be used as an AST and sometimes a representation that retains more information is required.
+- Free Variables - Variables that are referenced within the body of a function but that are not bound within the function.
+- Garbage Collector (GC) - A form of automatic memory management that frees memory allocated by objects that are no longer used by the program.
+- REPL - Read Eval Print Loop; basically a command prompt for interactively evaluating code.
+
+## References
+
+1. [CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A.](http://www.pipeline.com/~hbaker1/CheneyMTA.html), by Henry Baker
+2. [CHICKEN Scheme](http://www.call-cc.org/)
+3. [CHICKEN Scheme - Internals](https://wiki.call-cc.org/Internals)
+4. [Chibi Scheme](https://github.com/ashinn/chibi-scheme)
+5. [Compiling Scheme to C with closure conversion](http://matt.might.net/articles/compiling-scheme-to-c/), by Matt Might
+6. [Lisp in Small Pieces](http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/LiSP.html), by Christian Queinnec
+7. [R5RS Scheme Specification](http://www.schemers.org/Documents/Standards/R5RS/HTML/)
+8. [R7RS Scheme Specification](http://trac.sacrideo.us/wg/wiki)
+9. [Structure and Interpretation of Computer Programs](https://mitpress.mit.edu/sicp/full-text/book/book.html), by Harold Abelson and Gerald Jay Sussman
+10. [The 90 minute Scheme to C compiler](http://churchturing.org/y/90-min-scc.pdf), by Marc Feeley
+11. [The Development of Chez Scheme](https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf), by R. Kent Dybvig
+
diff --git a/docs/images/benchmark-tests-finished.png b/docs/images/benchmark-tests-finished.png
new file mode 100644
index 00000000..6ba6fb97
Binary files /dev/null and b/docs/images/benchmark-tests-finished.png differ
diff --git a/docs/images/benchmark-total-runtimes.png b/docs/images/benchmark-total-runtimes.png
new file mode 100644
index 00000000..257666db
Binary files /dev/null and b/docs/images/benchmark-total-runtimes.png differ
diff --git a/docs/images/compiler.dia b/docs/images/compiler.dia
index f3b82318..ba5c7efa 100644
Binary files a/docs/images/compiler.dia and b/docs/images/compiler.dia differ
diff --git a/docs/images/compiler.png b/docs/images/compiler.png
index 3b6bbdb2..50788d93 100644
Binary files a/docs/images/compiler.png and b/docs/images/compiler.png differ
diff --git a/docs/images/cyclone-contribs.png b/docs/images/cyclone-contribs.png
new file mode 100644
index 00000000..357ff3f1
Binary files /dev/null and b/docs/images/cyclone-contribs.png differ
diff --git a/docs/images/runtime.dia b/docs/images/runtime.dia
new file mode 100644
index 00000000..813dc36c
Binary files /dev/null and b/docs/images/runtime.dia differ
diff --git a/docs/images/runtime.png b/docs/images/runtime.png
new file mode 100644
index 00000000..e4b07487
Binary files /dev/null and b/docs/images/runtime.png differ
diff --git a/include/cyclone/ck_ht_hash.h b/include/cyclone/ck_ht_hash.h
index be4f08e6..f8cb705e 100644
--- a/include/cyclone/ck_ht_hash.h
+++ b/include/cyclone/ck_ht_hash.h
@@ -32,7 +32,6 @@
*/
#include
-#include
//-----------------------------------------------------------------------------
// MurmurHash3 was written by Austin Appleby, and is placed in the public
diff --git a/scheme/cyclone/common.sld b/scheme/cyclone/common.sld
index 450648eb..0c608de9 100644
--- a/scheme/cyclone/common.sld
+++ b/scheme/cyclone/common.sld
@@ -29,7 +29,7 @@
@@ @@ Cyclone Scheme->C compiler
,@ http://justinethier.github.io/cyclone/
'@
- .@ (c) 2014-2016 Justin Ethier
+ .@ (c) 2014-2017 Justin Ethier
@@ #@ Version " *version* "
`@@@#@@@.
#@@@@@
diff --git a/tests/debug/ack-gmon-analysis.txt b/tests/debug/ack-gmon-analysis.txt
new file mode 100644
index 00000000..5b8ded40
--- /dev/null
+++ b/tests/debug/ack-gmon-analysis.txt
@@ -0,0 +1,2519 @@
+Flat profile:
+
+Each sample counts as 0.01 seconds.
+ % cumulative self self total
+ time seconds seconds calls s/call s/call name
+ 18.82 16.76 16.76 710694909 0.00 0.00 __lambda_1
+ 9.81 25.50 8.74 8950 0.00 0.00 gc_sweep
+ 9.66 34.10 8.60 1075614 0.00 0.00 gc_minor
+ 9.26 42.35 8.25 693683336 0.00 0.00 gc_copy_obj
+ 8.32 49.77 7.42 693927121 0.00 0.00 gc_try_alloc
+ 7.03 56.03 6.26 2137195779 0.00 0.00 Cyc_num_fast_eq_op
+ 6.28 61.62 5.60 1370056701 0.00 0.00 gc_allocated_bytes
+ 4.56 65.68 4.06 693921734 0.00 0.00 gc_alloc
+ 4.48 69.67 3.99 1424380073 0.00 0.00 Cyc_fast_sub
+ 3.53 72.81 3.14 710296579 0.00 0.00 Cyc_fast_sum
+ 3.42 75.86 3.05 693849289 0.00 0.00 gc_move
+ 3.03 78.56 2.70 711654992 0.00 0.00 __lambda_0
+ 2.74 81.00 2.44 693722448 0.00 0.00 gc_fixup_moved_obj
+ 2.13 82.90 1.90 693922724 0.00 0.00 gc_thr_add_to_move_buffer
+ 2.04 84.72 1.82 1424649027 0.00 0.00 Cyc_st_add
+ 1.03 85.64 0.92 dispatch_num_eq
+ 0.73 86.29 0.65 44 0.01 0.01 cell_get
+ 0.62 86.84 0.55 1358 0.00 0.00 gc_grow_heap
+ 0.60 87.37 0.53 1054 0.00 0.00 gc_mark_globals
+ 0.33 87.66 0.29 __halt
+ 0.32 87.94 0.29 5 0.06 0.06 gc_thr_grow_move_buffer
+ 0.30 88.21 0.27 gc_print_stats
+ 0.28 88.46 0.25 2 0.13 0.13 __lambda_2
+ 0.26 88.70 0.24 29559012 0.00 0.00 gc_mark_black
+ 0.13 88.82 0.12 54145669 0.00 0.00 gc_collector_mark_gray
+ 0.09 88.90 0.08 32429287 0.00 0.00 ck_pr_md_load_int
+ 0.07 88.96 0.07 941 0.00 0.00 gc_collector_trace
+ 0.03 88.99 0.03 29134668 0.00 0.00 vpbuffer_add
+ 0.02 89.01 0.02 1894577 0.00 0.00 gc_empty_collector_stack
+ 0.02 89.03 0.02 1076173 0.00 0.00 GC
+ 0.01 89.04 0.01 1075181 0.00 0.00 gc_sum_pending_writes
+ 0.01 89.05 0.01 8 0.00 0.00 vpbuffer_realloc
+ 0.01 89.06 0.01 1 0.01 74.94 Cyc_start_trampoline
+ 0.01 89.07 0.01 ck_pr_md_load_uint
+ 0.00 89.07 0.00 2015508 0.00 0.00 gc_mark_gray
+ 0.00 89.07 0.00 1077265 0.00 0.00 clear_mutations
+ 0.00 89.07 0.00 1077084 0.00 0.00 do_dispatch
+ 0.00 89.07 0.00 1076787 0.00 0.00 gc_mut_cooperate
+ 0.00 89.07 0.00 17613 0.00 0.00 ck_pr_cas_int
+ 0.00 89.07 0.00 14863 0.00 0.00 gc_is_heap_empty
+ 0.00 89.07 0.00 9037 0.00 0.00 gc_get_heap
+ 0.00 89.07 0.00 6882 0.00 0.00 ck_pr_barrier
+ 0.00 89.07 0.00 6714 0.00 0.00 ck_pr_fence_load
+ 0.00 89.07 0.00 6379 0.00 0.00 ck_pr_md_load_ptr
+ 0.00 89.07 0.00 5153 0.00 0.00 gc_heap_free
+ 0.00 89.07 0.00 2686 0.00 0.00 gc_wait_handshake
+ 0.00 89.07 0.00 1965 0.00 0.00 gc_handshake
+ 0.00 89.07 0.00 1960 0.00 0.00 gc_zero_read_write_counts
+ 0.00 89.07 0.00 1904 0.00 0.00 gc_free_old_thread_data
+ 0.00 89.07 0.00 1861 0.00 0.00 gc_post_handshake
+ 0.00 89.07 0.00 1361 0.00 0.00 gc_heap_create
+ 0.00 89.07 0.00 1080 0.00 0.01 gc_collector
+ 0.00 89.07 0.00 856 0.00 0.00 MurmurHash64A
+ 0.00 89.07 0.00 856 0.00 0.00 hs_hash
+ 0.00 89.07 0.00 472 0.00 0.00 add_symbol
+ 0.00 89.07 0.00 472 0.00 0.00 set_insert
+ 0.00 89.07 0.00 400 0.00 0.00 Cyc_is_pair
+ 0.00 89.07 0.00 384 0.00 0.00 find_or_add_symbol
+ 0.00 89.07 0.00 384 0.00 0.00 find_symbol_by_name
+ 0.00 89.07 0.00 384 0.00 0.00 set_get
+ 0.00 89.07 0.00 343 0.00 0.00 _strdup
+ 0.00 89.07 0.00 343 0.00 0.00 add_symbol_by_name
+ 0.00 89.07 0.00 255 0.00 0.00 add_global
+ 0.00 89.07 0.00 255 0.00 0.00 malloc_make_pair
+ 0.00 89.07 0.00 255 0.00 0.00 mcvar
+ 0.00 89.07 0.00 192 0.00 0.00 Cyc_cdr
+ 0.00 89.07 0.00 128 0.00 0.00 mark_stack_or_heap_obj
+ 0.00 89.07 0.00 127 0.00 0.00 gc_is_stack_obj
+ 0.00 89.07 0.00 97 0.00 0.00 Cyc_eq
+ 0.00 89.07 0.00 82 0.00 0.00 Cyc_is_null
+ 0.00 89.07 0.00 69 0.00 0.00 Cyc_car
+ 0.00 89.07 0.00 64 0.00 0.00 equal
+ 0.00 89.07 0.00 64 0.00 0.00 gc_mut_update
+ 0.00 89.07 0.00 56 0.00 0.00 equalp
+ 0.00 89.07 0.00 40 0.00 0.00 add_mutation
+ 0.00 89.07 0.00 37 0.00 0.00 Cyc_set_car
+ 0.00 89.07 0.00 32 0.00 0.00 Cyc_is_port
+ 0.00 89.07 0.00 31 0.00 0.00 Cyc_length
+ 0.00 89.07 0.00 24 0.00 0.00 Cyc_global_set
+ 0.00 89.07 0.00 23 0.00 0.00 Cyc_is_string
+ 0.00 89.07 0.00 23 0.00 0.00 __lambda_19
+ 0.00 89.07 0.00 23 0.00 0.00 __lambda_20
+ 0.00 89.07 0.00 23 0.00 0.01 __lambda_721
+ 0.00 89.07 0.00 21 0.00 0.00 gc_mark_gray2
+ 0.00 89.07 0.00 17 0.00 0.00 Cyc_is_number
+ 0.00 89.07 0.00 17 0.00 0.00 apply
+ 0.00 89.07 0.00 16 0.00 0.00 Cyc_is_eof_object
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_12
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_14
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_250
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_251
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_252
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_253
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_254
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_44
+ 0.00 89.07 0.00 16 0.00 0.00 __lambda_45
+ 0.00 89.07 0.00 14 0.00 0.00 Cyc_display
+ 0.00 89.07 0.00 13 0.00 0.00 Cyc_io_read_char
+ 0.00 89.07 0.00 13 0.00 0.00 __lambda_282
+ 0.00 89.07 0.00 13 0.00 0.00 gc_mutator_thread_blocked
+ 0.00 89.07 0.00 13 0.00 0.00 gc_mutator_thread_runnable
+ 0.00 89.07 0.00 13 0.00 0.00 memberp
+ 0.00 89.07 0.00 12 0.00 0.00 Cyc_display_va
+ 0.00 89.07 0.00 12 0.00 0.00 Cyc_display_va_list
+ 0.00 89.07 0.00 12 0.00 0.00 Cyc_is_vector
+ 0.00 89.07 0.00 12 0.00 0.00 Cyc_vector_ref
+ 0.00 89.07 0.00 12 0.00 0.00 __lambda_0
+ 0.00 89.07 0.00 12 0.00 0.00 __lambda_1
+ 0.00 89.07 0.00 10 0.00 0.00 Cyc_apply
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_241
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_242
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_243
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_244
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_245
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_246
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_247
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_248
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_249
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_281
+ 0.00 89.07 0.00 9 0.00 0.00 __lambda_36
+ 0.00 89.07 0.00 9 0.00 0.00 _cons
+ 0.00 89.07 0.00 8 0.00 0.00 __lambda_245
+ 0.00 89.07 0.00 8 0.00 0.00 __lambda_246
+ 0.00 89.07 0.00 8 0.00 0.00 __lambda_247
+ 0.00 89.07 0.00 7 0.00 0.00 Cyc_num_fast_lt_op
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_13
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_15
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_16
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_17
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_18
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_43
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_55
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_56
+ 0.00 89.07 0.00 7 0.00 0.00 __lambda_57
+ 0.00 89.07 0.00 7 0.00 0.00 apply_va
+ 0.00 89.07 0.00 7 0.00 0.00 dispatch
+ 0.00 89.07 0.00 5 0.00 0.00 Cyc_string_append
+ 0.00 89.07 0.00 4 0.00 0.00 Cyc_check_obj
+ 0.00 89.07 0.00 4 0.00 0.00 Cyc_list2string
+ 0.00 89.07 0.00 4 0.00 0.00 Cyc_list2vector
+ 0.00 89.07 0.00 4 0.00 0.00 Cyc_string2number2_
+ 0.00 89.07 0.00 4 0.00 0.00 Cyc_string2number_
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_10
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_11
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_15
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_16
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_17
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_19
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_20
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_21
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_24
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_248
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_249
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_250
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_251
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_27
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_28
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_328
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_329
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_330
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_336
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_337
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_35
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_383
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_384
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_387
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_388
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_389
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_390
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_40
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_41
+ 0.00 89.07 0.00 4 0.00 0.00 __lambda_42
+ 0.00 89.07 0.00 4 0.00 0.03 __lambda_9
+ 0.00 89.07 0.00 4 0.00 0.00 assoc
+ 0.00 89.07 0.00 4 0.00 0.00 str2int
+ 0.00 89.07 0.00 3 0.00 0.00 Cyc_number2string2
+ 0.00 89.07 0.00 3 0.00 0.00 Cyc_set_cell
+ 0.00 89.07 0.00 3 0.00 0.00 Cyc_write_char
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_21
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_22
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_23
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_307
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_308
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_309
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_51
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_718
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_719
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_722
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_723
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_724
+ 0.00 89.07 0.00 3 0.00 0.00 __lambda_725
+ 0.00 89.07 0.00 2 0.00 0.00 Cyc_fast_div
+ 0.00 89.07 0.00 2 0.00 0.00 Cyc_io_flush_output_port
+ 0.00 89.07 0.00 2 0.00 0.00 Cyc_write
+ 0.00 89.07 0.00 2 0.00 0.00 Cyc_write_va
+ 0.00 89.07 0.00 2 0.00 0.00 Cyc_write_va_list
+ 0.00 89.07 0.00 2 0.00 0.00 _Cyc_write
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_0
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_1
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_2
+ 0.00 89.07 0.00 2 0.00 0.04 __lambda_23
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_3
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_3
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_304
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_327
+ 0.00 89.07 0.00 2 0.00 0.00 __lambda_4
+ 0.00 89.07 0.00 2 0.00 0.00 double2buffer
+ 0.00 89.07 0.00 1 0.00 0.00 Cyc_fast_mul
+ 0.00 89.07 0.00 1 0.00 0.00 Cyc_heap_init
+ 0.00 89.07 0.00 1 0.00 0.00 Cyc_stderr
+ 0.00 89.07 0.00 1 0.00 0.00 Cyc_stdin
+ 0.00 89.07 0.00 1 0.00 0.00 Cyc_stdout
+ 0.00 89.07 0.00 1 0.00 0.00 __75halt
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_0
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_10
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_11
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_12
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_13
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_14
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1544
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1545
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1546
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1547
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1548
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1549
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1550
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1551
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1552
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1553
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1554
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1555
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1556
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1557
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1558
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1559
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1560
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_1561
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_2
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_2
+ 0.00 89.07 0.00 1 0.00 0.04 __lambda_22
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_24
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_25
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_26
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_27
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_28
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_29
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_3
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_3
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_30
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_31
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_32
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_33
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_34
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_35
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_36
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_37
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_38
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_39
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_399
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_4
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_4
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_40
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_400
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_41
+ 0.00 89.07 0.00 1 0.00 0.04 __lambda_42
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_42
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_43
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_44
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_5
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_5
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_5
+ 0.00 89.07 0.00 1 0.00 0.01 __lambda_5
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_50
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_52
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_53
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_54
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_55
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_56
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_57
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_58
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_59
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_6
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_6
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_6
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_60
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_61
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_62
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_63
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_64
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_65
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_66
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_67
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_68
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_69
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_7
+ 0.00 89.07 0.00 1 0.00 0.01 __lambda_7
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_765
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_766
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_8
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_8
+ 0.00 89.07 0.00 1 0.00 0.00 __lambda_9
+ 0.00 89.07 0.00 1 0.00 0.00 c_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 c_entry_pt_first_lambda
+ 0.00 89.07 0.00 1 0.00 0.00 c_scheme_char_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 c_schemebase_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 c_schemecyclonecommon_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 c_schemeread_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 c_schemetime_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 c_schemewrite_entry_pt
+ 0.00 89.07 0.00 1 0.00 0.00 gc_add_mutator
+ 0.00 89.07 0.00 1 0.00 0.00 gc_init_heap
+ 0.00 89.07 0.00 1 0.00 0.00 gc_initialize
+ 0.00 89.07 0.00 1 0.00 0.00 gc_start_collector
+ 0.00 89.07 0.00 1 0.00 0.06 gc_thread_data_init
+ 0.00 89.07 0.00 1 0.00 0.00 set_env_variables
+
+ % the percentage of the total running time of the
+time program used by this function.
+
+cumulative a running sum of the number of seconds accounted
+ seconds for by this function and those listed above it.
+
+ self the number of seconds accounted for by this
+seconds function alone. This is the major sort for this
+ listing.
+
+calls the number of times this function was invoked, if
+ this function is profiled, else blank.
+
+ self the average number of milliseconds spent in this
+ms/call function per call, if this function is profiled,
+ else blank.
+
+ total the average number of milliseconds spent in this
+ms/call function and its descendents per call, if this
+ function is profiled, else blank.
+
+name the name of the function. This is the minor sort
+ for this listing. The index shows the location of
+ the function in the gprof listing. If the index is
+ in parenthesis it shows where it would appear in
+ the gprof listing if it were to be printed.
+
+Copyright (C) 2012-2015 Free Software Foundation, Inc.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved.
+
+ Call graph (explanation follows)
+
+
+granularity: each sample hit covers 2 byte(s) for 0.01% of 89.07 seconds
+
+index % time self children called name
+
+[1] 84.2 0.00 75.00 main [1]
+ 0.01 74.93 1/1 Cyc_start_trampoline [2]
+ 0.00 0.06 1/1 gc_thread_data_init [38]
+ 0.00 0.00 1/1 gc_initialize [49]
+ 0.00 0.00 1/1 set_env_variables [213]
+ 0.00 0.00 1/1 gc_add_mutator [210]
+ 0.00 0.00 1/1 Cyc_heap_init [198]
+-----------------------------------------------
+ 0.01 74.93 1/1 main [1]
+[2] 84.1 0.01 74.93 1 Cyc_start_trampoline [2]
+ 19.71 55.22 1077077/1077078 do_dispatch [133]
+-----------------------------------------------
+[3] 84.1 19.71 55.22 1077078+1422350722 [3]
+ 16.76 39.98 710694909+713501311 __lambda_1 [4]
+ 2.70 14.59 711654992 __lambda_0 [10]
+ 0.00 0.34 23 __lambda_721 [29]
+ 0.25 0.00 2 __lambda_2 [33]
+ 0.00 0.10 4 __lambda_9 [35]
+ 0.00 0.09 2 __lambda_23 [36]
+ 0.00 0.04 1 __lambda_42 [39]
+ 0.00 0.04 1 __lambda_22 [40]
+ 0.00 0.01 1 __lambda_7 [44]
+ 0.00 0.01 1 __lambda_5 [43]
+ 0.00 0.00 23 __lambda_19 [57]
+ 0.00 0.00 16 __lambda_253 [59]
+ 0.00 0.00 7 __lambda_17 [61]
+ 0.00 0.00 7 __lambda_15 [60]
+ 0.00 0.00 7 __lambda_57 [62]
+ 0.00 0.00 23 __lambda_20 [63]
+ 0.00 0.00 16 __lambda_254 [68]
+ 0.00 0.00 16 __lambda_14 [67]
+ 0.00 0.00 16 __lambda_12 [66]
+ 0.00 0.00 13 __lambda_282 [69]
+ 0.00 0.00 12 __lambda_1 [70]
+ 0.00 0.00 9 __lambda_36 [71]
+ 0.00 0.00 8 __lambda_247 [72]
+ 0.00 0.00 7 __lambda_13 [73]
+ 0.00 0.00 7 __lambda_18 [75]
+ 0.00 0.00 7 __lambda_16 [74]
+ 0.00 0.00 7 __lambda_43 [76]
+ 0.00 0.00 1 __lambda_1561 [77]
+ 0.00 0.00 1 __lambda_5 [80]
+ 0.00 0.00 1 __lambda_42 [79]
+ 0.00 0.00 1 __lambda_400 [78]
+ 0.00 0.00 1 __lambda_52 [82]
+ 0.00 0.00 1 __lambda_8 [84]
+ 0.00 0.00 1 __lambda_65 [83]
+ 0.00 0.00 5 Cyc_string_append [85]
+ 0.00 0.00 1 __lambda_3 [101]
+ 0.00 0.00 1 __lambda_2 [100]
+ 0.00 0.00 1 __lambda_0 [86]
+ 0.00 0.00 1 __lambda_1559 [99]
+ 0.00 0.00 1 __lambda_1557 [98]
+ 0.00 0.00 1 __lambda_1555 [97]
+ 0.00 0.00 1 __lambda_1554 [96]
+ 0.00 0.00 1 __lambda_1553 [95]
+ 0.00 0.00 1 __lambda_1552 [94]
+ 0.00 0.00 1 __lambda_1551 [93]
+ 0.00 0.00 1 __lambda_1550 [92]
+ 0.00 0.00 1 __lambda_1549 [91]
+ 0.00 0.00 1 __lambda_1548 [90]
+ 0.00 0.00 1 __lambda_1547 [89]
+ 0.00 0.00 1 __lambda_1546 [88]
+ 0.00 0.00 1 __lambda_1544 [87]
+ 0.00 0.00 1 __lambda_4 [103]
+ 0.00 0.00 1 __lambda_399 [102]
+ 0.00 0.00 1 __lambda_6 [105]
+ 0.00 0.00 4 __lambda_390 [116]
+ 0.00 0.00 4 __lambda_11 [106]
+ 0.00 0.00 4 __lambda_28 [110]
+ 0.00 0.00 4 __lambda_383 [114]
+ 0.00 0.00 4 __lambda_21 [107]
+ 0.00 0.00 4 __lambda_251 [109]
+ 0.00 0.00 4 __lambda_384 [115]
+ 0.00 0.00 4 __lambda_337 [112]
+ 0.00 0.00 4 __lambda_329 [111]
+ 0.00 0.00 4 __lambda_35 [113]
+ 0.00 0.00 4 __lambda_24 [108]
+ 0.00 0.00 3 __lambda_725 [120]
+ 0.00 0.00 3 __lambda_23 [117]
+ 0.00 0.00 3 __lambda_308 [118]
+ 0.00 0.00 3 __lambda_309 [119]
+ 0.00 0.00 1 __lambda_5 [121]
+ 0.00 0.00 1 __lambda_43 [122]
+ 0.00 0.00 2 __lambda_327 [125]
+ 0.00 0.00 2 __lambda_304 [124]
+ 0.00 0.00 2 __lambda_3 [123]
+ 0.00 0.00 1 __lambda_69 [131]
+ 0.00 0.00 1 __lambda_4 [128]
+ 0.00 0.00 1 __lambda_3 [127]
+ 0.00 0.00 1 __lambda_14 [126]
+ 0.00 0.00 1 __lambda_6 [129]
+ 0.00 0.00 1 __lambda_67 [130]
+ 0.00 0.00 1077084 do_dispatch [133]
+ 0.00 0.00 17 apply [167]
+ 0.00 0.00 16 __lambda_252 [830]
+ 0.00 0.00 16 __lambda_45 [832]
+ 0.00 0.00 16 __lambda_44 [831]
+ 0.00 0.00 16 __lambda_251 [829]
+ 0.00 0.00 16 __lambda_250 [828]
+ 0.00 0.00 13 Cyc_io_read_char [170]
+ 0.00 0.00 13 gc_mutator_thread_runnable [172]
+ 0.00 0.00 12 __lambda_0 [833]
+ 0.00 0.00 10 Cyc_apply [178]
+ 0.00 0.00 9 __lambda_249 [842]
+ 0.00 0.00 9 __lambda_248 [841]
+ 0.00 0.00 9 __lambda_247 [840]
+ 0.00 0.00 9 __lambda_246 [839]
+ 0.00 0.00 9 __lambda_245 [838]
+ 0.00 0.00 9 __lambda_244 [837]
+ 0.00 0.00 9 __lambda_243 [836]
+ 0.00 0.00 9 __lambda_242 [835]
+ 0.00 0.00 9 __lambda_241 [834]
+ 0.00 0.00 9 _cons [844]
+ 0.00 0.00 9 __lambda_281 [843]
+ 0.00 0.00 8 __lambda_245 [845]
+ 0.00 0.00 8 __lambda_246 [846]
+ 0.00 0.00 7 __lambda_56 [848]
+ 0.00 0.00 7 dispatch [181]
+ 0.00 0.00 7 apply_va [180]
+ 0.00 0.00 7 __lambda_55 [847]
+ 0.00 0.00 4 __lambda_387 [862]
+ 0.00 0.00 4 __lambda_389 [864]
+ 0.00 0.00 4 __lambda_10 [849]
+ 0.00 0.00 4 __lambda_388 [863]
+ 0.00 0.00 4 __lambda_42 [867]
+ 0.00 0.00 4 __lambda_20 [854]
+ 0.00 0.00 4 __lambda_250 [857]
+ 0.00 0.00 4 __lambda_248 [855]
+ 0.00 0.00 4 __lambda_249 [856]
+ 0.00 0.00 4 __lambda_19 [853]
+ 0.00 0.00 4 Cyc_list2vector [184]
+ 0.00 0.00 4 __lambda_17 [852]
+ 0.00 0.00 4 __lambda_15 [850]
+ 0.00 0.00 4 __lambda_16 [851]
+ 0.00 0.00 4 __lambda_27 [858]
+ 0.00 0.00 4 __lambda_328 [859]
+ 0.00 0.00 4 __lambda_336 [861]
+ 0.00 0.00 4 Cyc_list2string [183]
+ 0.00 0.00 4 __lambda_330 [860]
+ 0.00 0.00 4 Cyc_string2number2_ [185]
+ 0.00 0.00 4 Cyc_string2number_ [186]
+ 0.00 0.00 4 __lambda_41 [866]
+ 0.00 0.00 4 __lambda_40 [865]
+ 0.00 0.00 3 __lambda_719 [873]
+ 0.00 0.00 3 __lambda_724 [876]
+ 0.00 0.00 3 __lambda_718 [872]
+ 0.00 0.00 3 __lambda_723 [875]
+ 0.00 0.00 3 __lambda_722 [874]
+ 0.00 0.00 3 __lambda_22 [869]
+ 0.00 0.00 3 __lambda_21 [868]
+ 0.00 0.00 3 __lambda_51 [871]
+ 0.00 0.00 3 Cyc_number2string2 [189]
+ 0.00 0.00 3 __lambda_307 [870]
+ 0.00 0.00 2 __lambda_3 [881]
+ 0.00 0.00 2 __lambda_1 [879]
+ 0.00 0.00 2 __lambda_0 [878]
+ 0.00 0.00 2 __lambda_4 [882]
+ 0.00 0.00 2 __lambda_2 [880]
+ 0.00 0.00 1 __lambda_68 [928]
+ 0.00 0.00 1 __lambda_1 [884]
+ 0.00 0.00 1 c_schemebase_entry_pt [205]
+ 0.00 0.00 1 __lambda_1560 [892]
+ 0.00 0.00 1 __lambda_1558 [891]
+ 0.00 0.00 1 __lambda_1556 [890]
+ 0.00 0.00 1 __lambda_1545 [889]
+ 0.00 0.00 1 c_schemetime_entry_pt [208]
+ 0.00 0.00 1 c_schemewrite_entry_pt [209]
+ 0.00 0.00 1 c_scheme_char_entry_pt [204]
+ 0.00 0.00 1 c_schemeread_entry_pt [207]
+ 0.00 0.00 1 c_entry_pt_first_lambda [203]
+ 0.00 0.00 1 __lambda_50 [913]
+ 0.00 0.00 1 __lambda_54 [915]
+ 0.00 0.00 1 __lambda_53 [914]
+ 0.00 0.00 1 __lambda_44 [912]
+ 0.00 0.00 1 __lambda_55 [916]
+ 0.00 0.00 1 __lambda_766 [931]
+ 0.00 0.00 1 __lambda_64 [926]
+ 0.00 0.00 1 __lambda_765 [930]
+ 0.00 0.00 1 __lambda_63 [925]
+ 0.00 0.00 1 __lambda_41 [911]
+ 0.00 0.00 1 c_entry_pt [202]
+ 0.00 0.00 1 c_schemecyclonecommon_entry_pt [206]
+ 0.00 0.00 1 __lambda_13 [888]
+ 0.00 0.00 1 __lambda_12 [887]
+ 0.00 0.00 1 __lambda_11 [886]
+ 0.00 0.00 1 __lambda_10 [885]
+ 0.00 0.00 1 __lambda_9 [933]
+ 0.00 0.00 1 __lambda_8 [932]
+ 0.00 0.00 1 __lambda_7 [929]
+ 0.00 0.00 1 __lambda_58 [919]
+ 0.00 0.00 1 __lambda_57 [918]
+ 0.00 0.00 1 __lambda_2 [893]
+ 0.00 0.00 1 __lambda_56 [917]
+ 0.00 0.00 1 __lambda_24 [894]
+ 0.00 0.00 1 __lambda_39 [909]
+ 0.00 0.00 1 __lambda_37 [907]
+ 0.00 0.00 1 __lambda_61 [923]
+ 0.00 0.00 1 __lambda_60 [922]
+ 0.00 0.00 1 __lambda_40 [910]
+ 0.00 0.00 1 __lambda_38 [908]
+ 0.00 0.00 1 __lambda_36 [906]
+ 0.00 0.00 1 __lambda_35 [905]
+ 0.00 0.00 1 __lambda_33 [903]
+ 0.00 0.00 1 __lambda_31 [901]
+ 0.00 0.00 1 __lambda_30 [900]
+ 0.00 0.00 1 __lambda_29 [899]
+ 0.00 0.00 1 __lambda_28 [898]
+ 0.00 0.00 1 __lambda_27 [897]
+ 0.00 0.00 1 __lambda_59 [920]
+ 0.00 0.00 1 __lambda_34 [904]
+ 0.00 0.00 1 __lambda_26 [896]
+ 0.00 0.00 1 __lambda_25 [895]
+ 0.00 0.00 1 __lambda_6 [921]
+ 0.00 0.00 1 __lambda_66 [927]
+ 0.00 0.00 1 __lambda_62 [924]
+ 0.00 0.00 1 __lambda_32 [902]
+-----------------------------------------------
+ 713501311 __lambda_1 [4]
+ 2 __lambda_2 [33]
+ 826498 do_dispatch [133]
+ 709868409 __lambda_0 [10]
+[4] 63.7 16.76 39.98 710694909+713501311 __lambda_1 [4]
+ 0.01 26.74 731595/1076173 GC [5]
+ 6.26 0.00 2137195778/2137195779 Cyc_num_fast_eq_op [15]
+ 3.14 0.00 710296554/710296579 Cyc_fast_sum [19]
+ 2.00 0.00 714276442/1424380073 Cyc_fast_sub [18]
+ 1.82 0.00 1424648814/1424649027 Cyc_st_add [21]
+ 711405239 __lambda_0 [10]
+ 2 __lambda_23 [36]
+ 713501311 __lambda_1 [4]
+-----------------------------------------------
+ 0.01 12.60 344578/1076173 __lambda_0 [10]
+ 0.01 26.74 731595/1076173 __lambda_1 [4]
+[5] 44.2 0.02 39.34 1076173 GC [5]
+ 8.60 30.72 1075614/1075614 gc_minor [6]
+ 0.00 0.02 1076787/1076787 gc_mut_cooperate [42]
+-----------------------------------------------
+ 8.60 30.72 1075614/1075614 GC [5]
+[6] 44.1 8.60 30.72 1075614 gc_minor [6]
+ 3.05 27.67 693849289/693849289 gc_move [7]
+ 0.00 0.00 1077265/1077265 clear_mutations [132]
+-----------------------------------------------
+ 3.05 27.67 693849289/693849289 gc_minor [6]
+[7] 34.5 3.05 27.67 693849289 gc_move [7]
+ 4.06 19.05 693921734/693921734 gc_alloc [8]
+ 2.44 2.12 693722448/693722448 gc_fixup_moved_obj [17]
+-----------------------------------------------
+ 4.06 19.05 693921734/693921734 gc_move [7]
+[8] 25.9 4.06 19.05 693921734 gc_alloc [8]
+ 7.42 11.08 693927121/693927121 gc_try_alloc [9]
+ 0.55 0.00 1357/1358 gc_grow_heap [24]
+-----------------------------------------------
+ 7.42 11.08 693927121/693927121 gc_alloc [8]
+[9] 20.8 7.42 11.08 693927121 gc_try_alloc [9]
+ 8.25 0.00 693683336/693683336 gc_copy_obj [14]
+ 2.83 0.00 693783511/1370056701 gc_allocated_bytes [16]
+-----------------------------------------------
+ 249753 do_dispatch [133]
+ 711405239 __lambda_1 [4]
+[10] 19.4 2.70 14.59 711654992 __lambda_0 [10]
+ 0.01 12.60 344578/1076173 GC [5]
+ 1.99 0.00 710103629/1424380073 Cyc_fast_sub [18]
+ 709868409 __lambda_1 [4]
+-----------------------------------------------
+
+[11] 14.1 0.00 12.58 collector_main [11]
+ 0.00 12.58 1080/1080 gc_collector [12]
+ 0.00 0.00 1671/32429287 ck_pr_md_load_int [37]
+-----------------------------------------------
+ 0.00 12.58 1080/1080 collector_main [11]
+[12] 14.1 0.00 12.58 1080 gc_collector [12]
+ 8.74 2.76 8950/8950 gc_sweep [13]
+ 0.07 0.48 941/941 gc_collector_trace [25]
+ 0.53 0.00 1054/1054 gc_mark_globals [26]
+ 0.00 0.00 1/1358 gc_grow_heap [24]
+ 0.00 0.00 1965/1965 gc_handshake [52]
+ 0.00 0.00 752/2686 gc_wait_handshake [51]
+ 0.00 0.00 1097/32429287 ck_pr_md_load_int [37]
+ 0.00 0.00 519/1861 gc_post_handshake [53]
+ 0.00 0.00 9037/9037 gc_get_heap [136]
+ 0.00 0.00 7556/17613 ck_pr_cas_int [134]
+ 0.00 0.00 1904/1904 gc_free_old_thread_data [142]
+-----------------------------------------------
+ 8.74 2.76 8950/8950 gc_collector [12]
+[13] 12.9 8.74 2.76 8950 gc_sweep [13]
+ 2.76 0.00 676273190/1370056701 gc_allocated_bytes [16]
+ 0.00 0.00 14863/14863 gc_is_heap_empty [135]
+ 0.00 0.00 5153/5153 gc_heap_free [140]
+-----------------------------------------------
+ 8.25 0.00 693683336/693683336 gc_try_alloc [9]
+[14] 9.3 8.25 0.00 693683336 gc_copy_obj [14]
+-----------------------------------------------
+ 0.00 0.00 1/2137195779 __lambda_5 [121]
+ 6.26 0.00 2137195778/2137195779 __lambda_1 [4]
+[15] 7.0 6.26 0.00 2137195779 Cyc_num_fast_eq_op [15]
+-----------------------------------------------
+ 2.76 0.00 676273190/1370056701 gc_sweep [13]
+ 2.83 0.00 693783511/1370056701 gc_try_alloc [9]
+[16] 6.3 5.60 0.00 1370056701 gc_allocated_bytes [16]
+-----------------------------------------------
+ 2.44 2.12 693722448/693722448 gc_move [7]
+[17] 5.1 2.44 2.12 693722448 gc_fixup_moved_obj [17]
+ 1.90 0.23 693922724/693922724 gc_thr_add_to_move_buffer [20]
+ 0.00 0.00 21/21 gc_mark_gray2 [64]
+-----------------------------------------------
+ 0.00 0.00 1/1424380073 __lambda_43 [122]
+ 0.00 0.00 1/1424380073 __lambda_42 [39]
+ 1.99 0.00 710103629/1424380073 __lambda_0 [10]
+ 2.00 0.00 714276442/1424380073 __lambda_1 [4]
+[18] 4.5 3.99 0.00 1424380073 Cyc_fast_sub [18]
+-----------------------------------------------
+ 0.00 0.00 2/710296579 __lambda_23 [36]
+ 0.00 0.00 7/710296579 __lambda_57 [62]
+ 0.00 0.00 16/710296579 __lambda_253 [59]
+ 3.14 0.00 710296554/710296579 __lambda_1 [4]
+[19] 3.5 3.14 0.00 710296579 Cyc_fast_sum [19]
+-----------------------------------------------
+ 1.90 0.23 693922724/693922724 gc_fixup_moved_obj [17]
+[20] 2.4 1.90 0.23 693922724 gc_thr_add_to_move_buffer [20]
+ 0.23 0.00 4/5 gc_thr_grow_move_buffer [31]
+-----------------------------------------------
+ 0.00 0.00 1/1424649027 __lambda_69 [131]
+ 0.00 0.00 1/1424649027 __lambda_67 [130]
+ 0.00 0.00 1/1424649027 __lambda_14 [126]
+ 0.00 0.00 1/1424649027 __lambda_6 [129]
+ 0.00 0.00 1/1424649027 __lambda_1561 [77]
+ 0.00 0.00 1/1424649027 __lambda_4 [128]
+ 0.00 0.00 1/1424649027 __lambda_3 [127]
+ 0.00 0.00 1/1424649027 __lambda_5 [80]
+ 0.00 0.00 1/1424649027 __lambda_42 [79]
+ 0.00 0.00 1/1424649027 __lambda_400 [78]
+ 0.00 0.00 2/1424649027 __lambda_327 [125]
+ 0.00 0.00 2/1424649027 __lambda_304 [124]
+ 0.00 0.00 2/1424649027 __lambda_3 [123]
+ 0.00 0.00 3/1424649027 __lambda_725 [120]
+ 0.00 0.00 3/1424649027 __lambda_309 [119]
+ 0.00 0.00 3/1424649027 __lambda_308 [118]
+ 0.00 0.00 3/1424649027 __lambda_23 [117]
+ 0.00 0.00 4/1424649027 __lambda_21 [107]
+ 0.00 0.00 4/1424649027 __lambda_384 [115]
+ 0.00 0.00 4/1424649027 __lambda_383