cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<the_drow>
I do have some questions that weren't answered in the blog post
<mattip>
the_drow: thanks
<mattip>
the_drow: it's IRC, just ask
<the_drow>
Couldn't we provide a macro redefinition of Py_INCREF and Py_DECREF that simply ignores reference counting and interacts with our GC directly?
<the_drow>
Extensions shouldn't use it by default but can if they don't rely on the refcounting behaviour to release resources
<the_drow>
This can be especially helpful for Cython extensions which can generate such code
<mattip>
the_drow: what would "interact directly" mean? It would just push the problem elsewhere
<mattip>
since the concept of "scope" does not exist in C
<the_drow>
I mean, it will not use refcounting at all which is one of the problems we have with cpyext as far as I recall
Zaab1t has quit [Ping timeout: 252 seconds]
<mattip>
so what would it use instead?
<the_drow>
Because we have a GC that can allocate objects much faster
<the_drow>
I suggest that Py_INCREF will simply add the object to the nursury if it's not already there
<the_drow>
and Py_DECREF will be a noop since the GC already tracks what objects needs to be released
<mattip>
but how does the GC track things that are managed opaquely in C, it cannot know when it is safe to release.
<the_drow>
Well, if an object is only managed in C than we have a problem
<mattip>
yes, that is the problem exactly. It is managed via C and then passed into the interpreter
<mattip>
We don't want to always get involved for each malloc/free since sometimes the code doesn't reach the interpreter at all
<the_drow>
Because we create the bridge view object lazily right?
<mattip>
yup, only when calling a c-api that forces rpython interaction
<mattip>
so the idea to make it fast is to minimize those crossing points in either direction
<mattip>
if possible, what is written in C should stay in C
<the_drow>
Another question I had is why don't we trace the execution of instructions, write the appropriate bytecodes for them in our VM and interact with the C code only when it does not invoke cpyext
<the_drow>
Essentially turning a cpyext extension to CFFI
<the_drow>
I'm aware that what I'm suggesting isn't easy
<the_drow>
But hey, you guys haven't done easy in quite a while :P
Zaab1t has joined #pypy
<mattip>
not sure I follow - "trace the execution of instructions" - of compiled C code?
<mattip>
we have toyed with the thought of changing cython to do something along those lines, but not at the C level, at the python level
oberstet has quit [Remote host closed the connection]