[ci skip]

Fix new_spec.rb typo.

CallFrame _invariants_ must be preserved under the following states:

1. calling / returning from _managed methods_;
2. calling / returning from _native methods_;
3. calling / returning from _native functions_;
4. calling / returning from _JIT functions_;
5. running a Fiber;
6. unwinding the stack due to C++ exception handling;
7. unwinding the stack by longjmp();
8. before any managed code runs in a Thread; and
9. after all managed code has run in a Thread.

CallFrame _invariants_ are:

Assume a vector of references to CallFrame instances exists
(VM::call_frames_), where n=VM::call_frames_index_ is the total number of
CallFrame instances and VM::call_frame_ refers to VM::call_frames_[n-1], and
VM::call_frame->previous refers to VM::call_frames_[n-2], etc.

1. VM::call_frames_[0] is the oldest managed frame in a Thread;
2. For all i=0...VM::call_frames_index_, VM::call_frams_[i] has 0+ live
   references to objects.
3. VM::call_frames_[VM::call_frames_index_-1] is the newest managed frame;
4. For all i=0...VM::call_frames_index_, VM::call_frames_[i+1] _follows_
   VM::call_frames_[i], also stated as lifetime(VM::call_frames_[i]) _bounds_
   lifetime(VM::call_frames_[i+1]) where lifetime(cf) returns a tuple (start,
   end) of times during which cf has live references, and for cf[i] "start_i"
   < "start_i+1" and "end_i" > "end_i+1".

The issue here is that Thread instances may be retained by other objects (eg
Enumerator) and when the Thread instance itself is finalized, the order of
finalization is non-deterministic (ie there is no Ruby API to impose an
ordering on finalization), so a Thread instance may have had its memory for
VM* cleaned up, and the other object referring to it may call methods on it
when that other object is being finalized.

So, we avoid operating on *really* dead Threads, where a Thread's lifetime
looks something like this:

1. Memory for the Thread allocated, but the Thread is not running as a
separate thread of execution.
2. The Thread is running.
3. The Thread's separate thread of execution has exited, so it is put in a
"zombie" state, but all the memory for the Thread (except it's execution
stack) is retained.
4. The Thread itself is still allocated (ie because the Thread is in a
finalization list so its managed memory hasn't been recycled, or it's just
been finalized) but the Thread isn't reachable by any live objects.
5. The Thread has been finalized, so it's VM* memory is deallocated, but the
managed memory for the Thread itself hasn't been reclaimed.
6. The Thread's managed memory is no longer allocated and any reference to the
Thread would be an "access after free" memory violation (but not necessarily
one that would trigger a memory fault in the CPU because the region of memory
it inhabited may still be allocated to the running program).

There is no guarantee that executing some Ruby code will only create one
new Symbol instance. Since we lazily load code with the CodeDB, we could
be executing code at any time in any thread, for instance.