From: "John R. Hogerhuis" <jhoger@pobox.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Storing code caching
Date: Thu, 08 Jul 2004 10:05:49 -0700 [thread overview]
Message-ID: <1089306349.12383.1723.camel@aragorn> (raw)
In-Reply-To: <F85D0A87-D0D9-11D8-B4E3-000A95B1EB4C@mac.com>
On Thu, 2004-07-08 at 05:26, Martin Williams wrote:
> Has anyone thought about trying to store the code caching on disk?
Are you talking about "save machine state" essentially "suspend/resume?"
That is certainly possible and I believe it has been discussed on the
list.
The other possibility, that you wish to permanently associate
untranslated code with translated code by having a big cache available
on disk is in the general case "the halting problem" and there can be no
algorithm for that. So you've been warned: There Be Dragons Here...
However this is real life so there are probably some things you can do.
Some things to understand:
1. Basic blocks of code in the cache are found by their addresses in
memory, not their content. You can imagine that from one run to the next
code would load in different spots in memory. I suppose you could come
up with a set of heuristics for recognizing a basic block:
a) the location is not permanent but it might be a good clue. Perhaps
though with virtual address space programs always locate to the same
place in a virtual map though they will be different spots in physical
map?
b) the length of the block never changes. That could be a good heuristic
c) A checksum of the code with consideration for absolute addresses that
have been "fixed up" in the code. These addresses may be different from
run-to-run. Remember though adding in a checksum is an efficiency
tradeoff. It may not be worth it.
d) self modifying code, self modifying code, self modifying code...
In coming up with heuristics for recognizing already translated code
available in the cache, remember you are trading off against just
retranslating. Depending on the complexity/resource intensivity of
computations for your heuristic it may not be worth it to do the
computations.
If you think hard about it there are probably some things you could do
efficiently to reuse basic blocks from previous runs. "User mode" QEMU
is probably an easier case than the general one of running an entire OS
image. And maybe you would want to look at load time... When given a
program to run you check your on disk cache to see if you have loaded
this program before. Checksum it once to see if you have already saved a
cache image for this program. If so, load it up. Encountering
dynamically translated (invalidated cache) portions of the code will
result in "dead areas" which should never be cached.
Anyway an interesting problem for a grad student, I'd say... you have
some prototyping/analysis to do in order to come up with some heuristics
for matching up real code with cached code.
-- John.
next prev parent reply other threads:[~2004-07-08 17:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-08 12:26 [Qemu-devel] Storing code caching Martin Williams
2004-07-08 17:05 ` John R. Hogerhuis [this message]
2004-07-08 17:25 ` Antony T Curtis
2004-07-08 18:42 ` [spam score 1/10 -pobox] " John R. Hogerhuis
2004-07-08 19:42 ` Re[2]: " Igor Shmukler
2004-07-08 17:57 ` Martin Williams
2004-07-08 18:28 ` John R. Hogerhuis
2004-07-08 19:11 ` Julian Seward
2004-07-08 19:45 ` John R. Hogerhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1089306349.12383.1723.camel@aragorn \
--to=jhoger@pobox.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).