JIT: reuse trampolines when possible

[hthh]

In tests, this showed hundreds of cache hits. A huge number of hits were, to my surprise, write trampolines with the same PC. I'm inferring from this that JIT code may be repeatedly invalidated and re-generated.

It seems this could easily lead to a trampoline-memory-leak causing the "Trampoline cache full" issue: https://code.google.com/p/dolphin-emu/issues/detail?id=7661

However, I was unable to reproduce that issue, so I'm not sure if this fixes it or not.

[phire]

@dolphin-emu-bot rebuild

[hthh]

Oops. I just noticed Jit64::ClearCache calls trampolines.ClearCodeSpace(), which would probably break this quite dangerously...

[hthh]

I fixed up those problems, and investigated the cause of the excessive back-patching:
https://docs.google.com/document/d/1mJgMcmefJIW8Bx139BcaigmhU89S1vtPPgk1sfzUIi4/edit?usp=sharing

I think this PR is still a good idea (and should fix the trampoline cache full error). Other changes to the JIT should probably be made to address the underlying problem.

edit: wrong link >_>

[skidau]

Thanks for the investigation, @hthh. Since you have found out that it is not a leak would you please also double the trampoline cache size? This will account for the addition of fastmem-writes on top of fastmem-reads. We can merge this PR after that is done. I do find it a bit strange that the issue does not occur on Windows and that it took over a year for it to be reported, considering that SSBB is one of the most popular games on the Wii.

[skidau]

@dolphin-emu-bot rebuild

[FioraAeterna]

I can't read the document you linked; could you make it public?

[FioraAeterna]

Could there be a nicer solution to that FIFO problem -- maybe tracking when an instruction fastmem-faults so that when the block is recompiled, we just disable fastmem for that particular load or store?

[hthh]

@skidau You're absolutely right, it's a very strange problem, and I don't have any explanation for the Windows/Linux/OS X mysteries. The only thing I'm sure about is that the quadratic rate of trampoline generation is wrong. It's probably worth checking that other people find that this fixes it for them.

It might be worth noting that trampolines have grown in size over time (the PC argument was added, which would make each trampoline a bit larger), which might explain why it only started getting noticed recently.

Anyway, I've doubled the trampoline cache size and hopefully fixed the Windows build warnings.

@FioraAeterna That sounds like a good approach, and would remove the back-patching overhead (in my tests, there are still 20000 redundant segfaults). I'm not sure that would be a complete fix: the bigger a block (of FIFO writes) is, the more times it will be recompiled, which could still cause problems (quadratic compilation time and quadratic code allocations come to mind).

I'd like to keep this code because I think it will, generally speaking, prevent redundant trampoline generation. It's definitely not the most complete or most elegant fix.

[FioraAeterna]

I'm going to write up a patch for this and see how well it works

[FioraAeterna]

#1222

[PatrickFerry]

@hthh that's a very big problem you've discovered.