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.

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.

Conflicts:
	src/codegen/unwinding.cpp

make a couple more places successfully rewrite

- if we try guarding after a mutation
- if we use all of our scratch space

Now, just set a "failed" flag internally and which prevents committing.

The motivation for the first part is trying to get rewrite calls to tp_getattro;
if the rewrite is from getattr then it will succeed, but if it comes from
callattr then we will want to do some more guards after the tp_getattro.  We
could try to pass that state around, but for now just use the 'failed' approach.

We don't usually call callattr with null_on_nonexistent,
but we do for __hasattr__ checking.  We can rewrite those
to just do the guards and then return NULL.

kind of hacky but I think it's ok for now.

We could also add more general rewriting, but
- these new special cases catch something like
  95% of the cases that we weren't rewriting
- these special cases are faster than doing the generic
  nonzerno mechanism (looking up the attribute, etc)

It'd be nice if we could get to the point that the generic
rewrites we'd create would be as good as the hand-crafted ones,
but that would require knowing that we don't need to guard on
constant classes, and then inlining within rewrites.

Some more perf hunting

ie one of the common entrypoints to capi code.

ie when it's on a builtin method.  We assumed at some point
that we wouldn't need to look at the function object, but now
that we can rewrite method_cls calls, that's not true.

Playing with stattimers

ie roll up all the time into the most "avoidable" reason that we were doing it.
For example, if we are doing something like calling slot_tp_getttro on a builtin
type (very avoidable), roll up all the subsequent time (runtimeCall, etc) into
the slot_tp_getattro timer.  But if we call runtimeCall where we couldn't avoid it
(ex from the interpreter), log that separately.

Not sure how helpful it will be but for this specific investigation it seems to
somewhat work.  The idea of the "avoidability" is definitely pretty specific to
the type of work that you are thinking of doing; the numbers I put in are for
investigating slowpaths.

Also, remove all the timers that we have on specific runtime functions (ex: listMul).
I think we'll need another strategy for those.