Ramon,
Something else to think about regarding the
issue of using 3 pages per scanned code page.
We need to run code in one (modified) page, and let read/writes
operate out of another (unmodified) page.
The hash-table idea would not _directly_ let us do this.
However, here are some related ideas...
We can time stamp (RDTSC) each page with time of
last use and time of last modification. We could
based on these times, decide to return certain
pages to the available pool. For instance, if
a page is used a lot, but has not been updated
in ages, we could return the meta page to the
pool, and continue to use the 2 modified/unmodified
pages until a write occurs.
If a page has not been used or updated recently, then
we could created a compressed list of which offsets
contain INT3 and store that with the meta info. Then
return both the meta page and modified page to the
available pool. Upon next use, we could create on-demand,
the modified page, and use as above, without the meta page.
Any modification would force us to dump everything and
start from scratch.
This goes well with the paging policy; that less commonly
used/updated pages take up less resources, and
more active ones are assigned more resources dynamically.
I will restructure the prescan code a little to incorporate
extra information including time stamps, and create an
associated page pool mechanism.
-Kevin