Dynarec multithreading

[Coreforge]

With the BOX64_DYNAREC_WAIT option giving some speedups with JIT code (I need to verify this again to make sure it wasn't something else, but iirc I got about a 5fps boost in beat saber), is there anything that would prevent the dynarec from running multithreaded?

There are a few global variables in use (the dynarec helper pointer and some static buffers), but from some testing it doesn't seem like they need to be global for the whole program. (I put current_helper in thread-local storage and for testing purposes I'm allocating static_jmps, static_next, static_table64 and static_insts on each call to FillBlock64 and freeing them after, although this is just temporary and was the easiest way I found that worked so far)
From some basic profiling, it looks like pass 0 is taking the most time, followed by pass 1 and 3. Unlocking the dyndump mutex during all of FillBlock64 results in most programs crashing rather fast with a segfault (I haven't narrowed down yet what exactly is causing this), but only unlocking during pass 0 seems to work so far, while the dynarec is being skipped less often in favour of the interpreter. (I have not tested yet if this actually speeds anything up)

Is this something that would be worth spending more time on, or are there certain things in the dynarec that make this unfeasible?

[ptitSeb]

I did some experiement in the past to make the dynarec compiler multithread. But I mostly had more unstability and not really any speed up.

The compiler itself is pretty fast, not sure having it multithreaded would help a lot.

(also, consider that program might have multiple thread waiting on the exact same dynarec block, wich complicate things a bit)

[Coreforge]

I think I'm seeing the same thing now. I got it to mostly work for a while (now it's refusing to again, seems to be some deadlocks which aren't very obvious in gdb though, or it quits with no visible errors), but the performance was slightly worse than normal box64