Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Does Unicorn still keep and use the cache after ending execution of uc_emu_start ? #1043

Closed
pent0 opened this issue Nov 13, 2018 · 1 comment

Comments

@pent0
Copy link

pent0 commented Nov 13, 2018

Context:

  • I'm emulating a type of OS and have to stop each 20000 ticks to reschedule emulated threads. It's something of this:
     while (!shutdown) {
         uc_emu_start(engine, pc, 1ULL << 63, 0, 20000);
         do_kernel_reschedule();
     }
  • If I try to run this without instructions limit, and do reschedule in code hook, it's super fast. But if I do like above, the performance drops are noticeable, especially when the emulated system enters a big loop.

  • It's not my reschedule that's slow, because there is another JIT backend I use, that although slower than Unicorn in general, but it keeps the cache and suprass Unicorn in loop situation.

  • So does Unicorn still keep cache after uc_emu_start done?

TLDR: Unicorn is slow when restarting continously. I want to ask if Unicorn stills keep cache after uc_emu_start done.

I'm happy to provide more information. Thanks.

Note: The build I'm using is release build on the web, but this question still relevant to master branch on github.

@pent0
Copy link
Author

pent0 commented Nov 13, 2018

I think I found the evil line:

unicorn/qemu/cpu-exec.c

Lines 279 to 282 in 19ffa83

// Unicorn: flush JIT cache to because emulation might stop in
// the middle of translation, thus generate incomplete code.
// TODO: optimize this for better performance
tb_flush(env);

Waiting for an optimization :)

@pent0 pent0 closed this as completed Nov 14, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant