cheetah's tests do a PATH search for the "cheetah" executable,
and since we were appending the test-cheetah's location to PATH,
it would find the system cheetah preferentially to the test cheetah.

This is fine since on most systems there isn't a system cheetah, but
somehow mine has one.  The system cheetah will invoke the system python,
which will end up passing more of the tests.

We could prepend PATH instead of append to it, but it looks like the
the tests don't need anything else, so for now don't pass in anything else
in PATH.

Include total-tests-run in our test-suite-results checking

I'm seeing fewer failures locally than specified in the file, and
I'm guessing it's because I'm somehow skipping some tests, but I'm
not sure.

Add debug symbols to release mode.

_U_dyn_register: Use binary search to find insert location

change timers back to ticks

This reverts commit 89df764f.

Specify /bin/bash for the Makefile, as some distros may have other shells as /bin/sh

Specify /bin/bash for the Makefile, as some distros may have other shells (eg, ubuntu image for docker has /bin/dash)

Revert to using gettimeofday to have measurements in us instead of ticks.

Some capi/descr code cleanup

I think it now contains the same types that CPython's
descrobject.c handles.

more rewriting

It needs to reserve some special key values that the caller
has to promise to never insert into the map.  For integers that's
-1 and -2... which we were using and then got some random data back.

don't mmap such small regions

don't mmap such small regions - linux clusters page faults so the larger the regions we mmap the better, and larger regions don't cost us anything

ie in cases that we couldn't rewrite all of the argument conversion,
emit a rewrite that's just a call directly to callFunc, so we can skip
the earlier parts of the dispatching.

I think there is more we can do here though; there are also more places
that this kind of approach would be applicable.

Also removing logic in Stats::dump that counts the total number of ticks
in timers. It relies on specific timer naming conventions that aren't
currently being followed. If, at a later time, we are interested in
having the sum of timer ticks, we should refactor the code to have a
separate class for counters that log time.

fix two minor bugs

In CPython, PyString_GET_SIZE and PyUnicode_GET_SIZE happen to have
the same implementation, so it is ok for callers to be wrong about
which one they call.

For us, previous to this commit, PyString_GET_SIZE would call PyString_Size,
which has different behavior than PyString_GET_SIZE for non-strings.
For unicode objects it means that we would return the size of the encoded
representation of the string rather than the number of unicode characters.
It also means that PyString_GET_SIZE can fail for us and return -1,
which it never can for CPython, so callers get away with not
checking the return value.

Doesn't usually matter, but if we crank up the collection frequency
then it's possible to get a collection between the allocation
and the registration.

rewrite wrapperdescriptors

We would check that they're in the right place as part of
restoreArgs (ie putting them in the right place), but then we
would do some other work (loading the value to check, loading
the constant) which could potentially spill registers.

So add an additional check right before we emit the actual
jump instruction.  I'm surprised this never failed.

I think the issue though was that I had tried to optimize the
heuristic for "can this be a patchpoint" to be too aggressive and
we were getting false negatives on the release build (but not the
debug build).

and rename them to make it more clear that it's GC-related.

Maybe the GC should zero-initialize everything, but it doesn't,
so we would get garbage values in that field.

Involves a couple changes:
- have the rewriter treat certain callsites as non-mutations
- add special cases for wrapperdescr objects

I renamed all the "about to enter jitted code" and "about to enter the interpreter"
stats to "in_jitted_code" and "in_interpreter", respectively; I don't think the
exact entry point ends up mattering that much.

A lot of stuff is showing up as "in_jitted_code"; I tried to find some of it using
the new itimer helper, and put some separate timers on those.

Seeing some corrupted-pyc-file issues on travis-ci,
that I can't reproduce locally.  Add some more debugging output
for when it happens again.

If you define INVESTIGATE_STAT_TIMER to the name of the timer you want
to investigate, we will set an itimer that raises a SIGTRAP if you are
in that particular timer, but ignores the signal otherwise.  There's no
tooling on top of it, but just running that inside gdb is already helpful.