Hi Armin, Thank you for the reply.
Luckily, I found the bug. It was a bug in my write barrier card marking implementation. I misunderstood what AArch64 MVN instruction meant when I was porting the code. After fixing it, I can pass these two test cases (test_zipfile64 and test_tokenize). Now, I am looking into test_json. Earlier, I thought it was an XFAIL because the -O2 build was failing too. But after adding `@settings(suppress_health_check=[HealthCheck.too_slow])` to `test_json.test_roundtrip`, I could run it in reasonable time. However, it was extremely slow when I ran the same test with the `-Ojit` build. According to `PYPYLOG=jit:log.txt`, the JIT compiler kept building the same (or similar) bridge. Statistics showed that the RISC-V JIT compiled more than 3000 bridges (when Ctrl-C interrupted) whereas the X86 JIT build compiled only 900 bridges (when completed). I will try to figure out the failing guard op first. Regards, Logan On Mon, Feb 19, 2024 at 10:05 PM Armin Rigo <armin.r...@gmail.com> wrote: > Hi Logan, > > On Tue, 20 Feb 2024 at 05:08, Logan Chien <tzuhsiang.ch...@gmail.com> > wrote: > > > This should just be #defined to do nothing with Boehm, maybe in > rpython/translator/c/src/mem.h > > > > With this change and a few RISC-V backend fixes (related to > self.cpu.vtable_offset), I can build and run a JIT+BoehmGC PyPy. > > Cool! I also got a pull request merged into the main branch with this > change, and it does indeed fix boehm builds. > > > This configuration (JIT+BoehmGC) can pass test_tokenize and > test_zipfile64 (from lib_python_tests.py). > > > > Thus, my next step will focus on the differences between JIT+BoehmGC and > JIT+IncminimarkGC. > > A problem that came up a lot in other backends is a specific input > instruction that the backend emits with specific registers. When you > run into the bad case, the emitted code reuses a register *before* > reading the same register assuming that it still contains its old > value. It's entirely dependent on register allocation, and if you run > it with boehm then the sequence of instruction is slightly different > and that might be the reason that the bug doesn't show up then. If > you get two failures with incminimark and none with boehm, then it > sounds more likely that the case involves one of the incminimark-only > constructions---but it's also possible the bug is somewhere unrelated > and it's purely bad luck... > > > Armin >
_______________________________________________ pypy-dev mailing list -- pypy-dev@python.org To unsubscribe send an email to pypy-dev-le...@python.org https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: arch...@mail-archive.com
