Hi Timothy, On 21 March 2015 at 01:43, Timothy Baldridge <tbaldri...@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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
