Man, Red-black trees are awesomely cool. But damn, they sure do make you work for it. So yeah, I’m currently ripping out the old POS code lookup stuff for a red black tree implementation to get better lookup times, insertion times, etc. Now if you’re thinking “but that’ll fragment the memory!” you’re one the same page as me, to solve that I’m backing all it’s node allocation with a memory pool to reduce fragmentation (and if done correctly, to zero).
There’s a bunch of other things that are being worked on(thought about)/completed, including:
- Assigning custom allocators – You can tell dynarec what to use when allocating/deallocating memory. It defaults to malloc and free but you can have it use your own memory stuff.
- Memory usage tracking – You can track how much memory can be allocated and how much is currently allocated (for control structures, exec memory is something else). This can be compiled out as it adds a little extra to each allocation to store the size of memory being pointed to.
- Code segment size tracking – pulls the same trick as memory alloc tracking. This will allow invalidated segments to be reused more easily and safely (not having to worry about overwriting part of another segment).
- Limitation of execution memory allocation – Once the limit is hit dynarec will start hacking away at not so regularly executed code segments (this will require some lightweight profiling).
- Profiling of code segments – This can either be done externally (in the emulator itself) or internally. Either way dynarec will need to know what’s up with code segments so it can invalidate the least used sections of code when it needs to spit out new code. (this is still pretty much up in the air as to how it’ll be done).
So yeah, that’s the skinny. the RB code lookup is getting most of my attention right now, improving code segment handling is coming in at second place.