[use_latest_valgrind] Use valgrind-3.10.0
Pypa vs Python parser tests

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>
Merge pull request #210 from vinzenz/pypa-ast-test

AST Compare tests libpypa vs cpython
Don't need copyright assignment here
Change link strategy: set rpath instead of linking some libs statically

Hopefully this doesn't break things for people trying non-default
toolchains, but it might.

We were previously using -static-libstdc++ to make sure that we would
find the right libstdc++.  I noticed that we weren't getting the right
version of libgcc_s (using the system one instead of the freshly-built
one), so use rpath for now.
Add 'runtime ics' to improve C++ runtime speed

An experimental way of making the runtime faster.  Previously, the C++
runtime was much slower than pure-Python code, since the Python code
can use the JIT to improve performance (through inline caches and type
speculation).  This commit adds "runtime ics", which are out-of-band
patchpoints that we can allocate from C++.  We insert them into the
same patchpoint system that gets used by the main JIT pipeline, so
they get rewritten like any other patchpoint, but the lifetime and use
gets controlled by the C++ code.

The trickiest part is getting the newly-allocated instruction regions
to work with our exception handling; to make this work we have to emit
.eh_frame sections.  (A custom libunwind-based exception unwinder
might not have this requirement.)

Otherwise it feels like a decent approach.  Right now just using it to
implement class slots and then only using them in the pyElements
iterator; it's probably not the most direct or efficient way of
implementing that particular feature, but it has the benefit of being
general and being useful for things such as binops which are not
directly expressible in terms of class slots.

This commit adds the support without turning the feature on (next
commit will turn it on), since there are a number of other changes
needed.
Enable runtime ics
Updated codespeed instructions
Fix a GC bug

We were scanning the wrong number of bytes for conservative objects;
we were using the allocated size instead of the user size, but
starting the scan at the beginning of the user section.

Finally ran into a case where a conservative object was the very
last object in the heap and it segfaulted.
Merge pull request #212 from lyh-kernel/use_latest_valgrind

[use_latest_valgrind] Use valgrind-3.10.0
Refactor: move BoxedClass from core/ to runtime/
Refactor: abstract this functionality more
wip