Question: Feasibility of Hot‑Path Runtime Profiling in Box64 Dynarec?

[TOMYUE]

Hi @ptitSeb and the Box64 team—thanks for all the fantastic work on this project!

I’ve been experimenting with Box64 for benchmarks and wanted to check whether a hot‑path runtime‑profiling mechanism is on your roadmap (or, if not, why it might not fit)?

I read the source code and found out Box64’s dynarec currently relies on static “bigblock” extending mechanism to create a block as big as possible, which could improve Box64's performance on certain workloads. But this strategy can’t always zero in on the hottest execution paths, so some performance potential may be left untapped.

So I wonder if a simple runtime profiling mechanism will be considered? Using counters to record each generated block's execution frequency, and when that counter exceeds a threshold (like 50, which in other DBI/DBO tools like DynamoRIO is treated as a good choice), the dynarec could treat the cross-block sequence as a hot path and combine these blocks into a bigblock. And let the counter decay over time, so new hot paths can surface.

I’m curious whether you’ve explored a runtime‑profiling scheme for Box64, and—if it hasn’t been pursued—would you mind sharing what factors led to that decision? Thanks very much!

[ptitSeb]

it's technically possible to embed a counter on each dynablock to check the number of time it's used, by creating some kind of prolog at start of block.

But

There still need a mecanism to check this counter value... And then do what? For now, Box64 Dynarec doesn't have an optimisation level. It's not based on an IR and Compiler logic. It's more like an Assembler.

So, yeah, hotpath could be implemented, but what to do with this info is not clear for now.