mu-client-pypy issueshttps://gitlab.anu.edu.au/mu/mu-client-pypy/-/issues2017-10-05T22:02:34+11:00https://gitlab.anu.edu.au/mu/mu-client-pypy/-/issues/10RawRefCount translation in Mu back-end2017-10-05T22:02:34+11:00John ZhangRawRefCount translation in Mu back-end## Problem Description
PyPy supports CPython extensions through linking `PyObject`s with RPython objects. This is done in the `rawrefcount` RPython library (`rpython/rlib/rawrefcount`). Calls to functions in `rawrefcount` in the RPyth...## Problem Description
PyPy supports CPython extensions through linking `PyObject`s with RPython objects. This is done in the `rawrefcount` RPython library (`rpython/rlib/rawrefcount`). Calls to functions in `rawrefcount` in the RPython source code are translated into `gc_rawrefcount_*` operations in the CFG, and are then handled by the back-end.
The Incremental Minimark GC implements these operations in `rpython/memory/gc/incminimark.py`. As part of the GC code it is written in RPython and compiled. It involves pinning the object, converting the address to an integer and stored in the header of the allocated `PyObject`.
A make-shift solution in `ll2mu` might be possible, but it will be quite messy.
A perhaps better solution would be to write a Mu GC transformer and a GC class that handles the translation of GC operations like this.
The translation of `gc_identityhash` operation can also benefit from this approach.
## Task description
- Investigate more on how the existing GC and GC transformers work, and evaluate how much work needs to be done;
- Possibly write a Mu GC and GC transformer that handles things like these;
- What other things can be benefited from having these two classes?John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-client-pypy/-/issues/4Loss of type information in JitCode2017-10-05T22:02:35+11:00John ZhangLoss of type information in JitCode# Problem Description
RPython contains a meta-interpreter that produces trace of JitCode as the interpreter runs.
JitCode is a flattened representation of the control flow graph of the source RPython program processed by the ahead-of...# Problem Description
RPython contains a meta-interpreter that produces trace of JitCode as the interpreter runs.
JitCode is a flattened representation of the control flow graph of the source RPython program processed by the ahead-of-time compiler.
Due to the C oriented design and the complexity of Python objects representating the types in RPython program,
the flattening process generally throws away type information.
In the case of `malloc`, the type is replaced by the size in bytes of the allocated object.
This poses a problem for Mu, since `NEW` instruction requires type information.
It is neccessary then, to do some 'hacking' in the flattening process to preserve some sort of type information,
with possible addition to some special JitCode instructions.
Research still needs to be done on the flattening process,
the representation of JitCode,
and the coordination with the AoT chain,
so to propose possible solutions.
# Files of interest
- `rpython/jit/codewriter/codewriter.py:31` -- `transform_graph_to_jitcode` function is a key function that compiles RTyped graph into JitCode. It is a multi-step process. The documentation in the function gives an overview of the steps.
- `rpython/jit/codewriter/jtransform.py:231` -- the operations in the RTyped graph are rewritten to prepare to be encoded to JitCode. It is at this step that the type information in malloc is lost (see `rewrite_op_malloc()` at line 940).