|
From: Nicholas N. <nj...@ca...> - 2003-05-26 12:06:53
|
On Mon, 26 May 2003, Josef Weidendorfer wrote: > Sidenote (perhaps there's a misunderstanding): I thought about 2 threads > running on 2 processors in parallel. There does not have any thread switching > for races to occur, as without locking, interleaved memory accesses from the > two threads/processors can happen in any order. Oh, good point. That's even more difficult. > As memory is a shared resource, we must use locking (atomic access to shadow > and real memory). How fine should locking be done? One lock for all memory > accesses kills performance. Perhaps one lock for each allocated area / or > every 64 bytes of memory? This would need very fast user mode mutexes (e.g. > Futexes from Linux 2.5). > But all this is about problems in some specific skin. I currently wonder more > about problems with the generic valgrind core (binary translation engine and > runtime environment). Well, programs typically spend something like 80%+ of their time running generated code. So I think you could be quite crude with locking in the core and not suffer too much. But I could be wrong about that. Hmm... I guess you'd want one copy of VG_(innerloop) per thread on a multi-processor machine or performance would suck. Ach, this is getting a bit complex for me... > What are the most problematic Linux-centric things to get rid of? Threads, syscalls, signals, in particular the interactions of all of them. > I thought a bigger problem would be to support other processor architectures. > This seems an interesting goal to me as for skins, the architecture is > already hidden by using the RISC-like UCodes. Firstly, UCode looks platform independent but it's really tied quite closely to x86 -- consider the handling of condition codes, the fact that it's two-address, the way FPU/MMX/SSE instructions are handled, etc. Nonetheless, X-arch translation is a definite possibility. It's been done before by others so the basic ideas are fairly well worked out. Julian has had some thoughts about this, the difficult part is allowing arbitrary instrumentation in a way that is independent of the architecture; most instructions are fine (adds, movs, things like that) but every architecture has its own weirdo instructions; these are the difficult parts to handle. N |