[pypy-dev] Optimizing Append Only structures

[Armin Rigo]

Hi,

On Tue, Nov 29, 2011 at 21:28, Romain Guillebert <romain.py at gmail.com> wrote:
> Probably because he (as a clojure developer) likes immutability of data
> structures.

No, it's really needed for the way it is written: by creating a new
dict, the old purefunction results no longer apply.  But we are
(indeed) using a slightly different approach in PyPy by not copying
the dict, but instead creating a new empty 'signature' object that we
pass to the purefunction too.

We don't have anything exactly similar in PyPy, I think.  I would go
for something along the lines of:

class Cell(object):
    _immutable_fields_ = ['content?']   # quasi-immutable
    content = None
_all_cells = {}

@elidable      # same as @purefunction
def get_cell(key):
     return _all_cells.setdefault(key, Cell())

or, depending on the usage, maybe @elidable_promote, if the key should
always be a jit-constant.  In this way the user gets a Cell
corresponding to the key he asked for, and then he can read the
'content' field, which is initially None but may be set to something
else.  Because it is a quasi-immutable field, this is all done with no
machine code produced.  If later the same Cell has its 'content' field
modified, then the old machine code is discarded and new code is
produced.  Note the indirection: the JIT should not see the @elidable
code, but just call it at tracing time; but the JIT must see the read
of the 'content' field, to be able to use the fact that it's a
quasi-immutable.


A bientôt,

Armin.