<arigato>
you could do obscure stuff like decompress the executable in memory when it loads, but lazily, not all at once
<arigato>
well you could do that already---I don't think userfaultfd gives you more than the old signal handler hack, but it's cleaner
<antocuni>
or zero-initialize memory lazily
<arigato>
well, you can do that more efficiently by calling mmap()
<arigato>
but let's imagine that you need a large piece of memory lazily initialized to contain 0xFF :-)
<arigato>
ah no, with userfaultfd you can do more crazy things because the file descriptor can be read from a different process
<arigato>
maybe lazily decompress and run a *different* non-cooperating program?
<arigato>
or more generally play at being a MMU for other programs
<antocuni>
I wonder whether we could use it for some GC things. E.g., maybe it is possible to setup things in such a way that it records all the pages which are accessed from one major collection to the other, but then I'm not sure how to use this info to speed up things
<arigato>
it would replace the write barrier. the question is what the overhead would be, both in terms of the read() stuff and in terms of loosing quite a bit of precision in the write barrier
<antocuni>
right
<arigato>
I would even say a LOT of precision is lost, because it would record at granularity "an object somewhere in this page", and also trigger when we write int fields, or nulls
<arigato>
given that we need to read the write barriers every minor collections, it's unclear if the overhead is reasonable
dmalcolm_ has joined #pypy
dmalcolm has quit [Ping timeout: 248 seconds]
jcea has joined #pypy
Dejan has joined #pypy
joshszep_ has joined #pypy
joshszep has quit [Ping timeout: 248 seconds]
lehmrob has quit [Quit: Konversation terminated!]
joshszep_ has quit [Read error: Connection reset by peer]
Dejan has quit [Read error: Connection reset by peer]
joshszep has joined #pypy
lritter has quit [Ping timeout: 246 seconds]
<vext01>
sorry, me again :)
<vext01>
when i run build_cffi_imports.py it makes a lib/pypy3.9 directory
<vext01>
is that right?
<vext01>
so we now have three library dirs: lib-python, lib_pypy and lib/pypy3.9
<vext01>
do i ignore the latter? I can delete it?
Guest12 has joined #pypy
Guest12 has quit [Client Quit]
otisolsen70 has quit [Quit: Leaving]
mattip_ has joined #pypy
<mattip_>
vext01: there is a lot of historical baggage around the directory structure
<mattip_>
the best way to deal with all that is via the pypy/tool/release/package.py script
<mattip_>
which builds the cffi extensions and creates a tarball with the correct directory structure
<mattip_>
it expects the pypy3.*-c and libpypy*.so in pypy/goal