[pypy-dev] Specialization for app level types

[Armin Rigo]

Hi Timothy,

On 21 March 2015 at 01:43, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> I'd like to add some optimization to app level types in Pixie. What I'm
> thinking of is something like this (in app level PyPy code):

There was some experiment in the PyPy branch
'type-specialized-instances' (in 2011-2013).  The idea there was to
use tagged pointers: every item in the array is either a regular
reference to a W_Root object, or a 31/63-bit integer stored with the
lowest bit set.  This must be specially supported by the GC, but
support is mostly there, and JIT support was in the branch
'int-tag-untag-as-operations'.

Nowadays, a better alternative is to store data in single array (say,
declared as array of integers), and have some items in there be GC
references while others are not.  A custom tracing hook needs to be
written.  This is similar to what we use for JITFRAME objects.  See
jitframe_trace() in rpython.jit.backend.llsupport.jitframe, which
enumerates items in the inlined jf_frame array based on
meta-information from the jf_gcmap field.

Note that although JITFRAME is obviously there for the JIT, it is
unclear how well the JIT itself supports RPython code doing this kind
of thing.  If you only access this kind of object from
@jit.dont_look_inside functions, then no problem, but this can't be
the case if you plan to use it for core language features.  The main
problem is that some operations that seem to be atomic in RPython
might not be any more while JITting.  We'd need to test exactly in
which order you need to update the information and the
meta-information, knowing that the GC may be randomly invoked in the
middle when tracing; and we'd need to check that instruction
reordering as done by the JIT optimizer don't create issues (they
probably do, e.g. if the update to the meta-information field is
delayed past a malloc).


A bientôt,

Armin.