|
From: Jeremy F. <je...@go...> - 2002-11-19 05:56:01
|
On Mon, 2002-11-18 at 17:04, Julian Seward wrote:
> > > That seems unavoidable. We'd probably just recycle the current
> > > arrangement, or perhaps a simplified version of it, in this case. Bear
> > > in mind that x86 RET instructions are going to pull an original address
> > > off the stack and jump to it, so there will still me a significant
> > > minority of such lookups needed.
> >
> > It's likely that rets will be the majority of jumps with unknown
> > destinations (though very OO C++ code's use of virtual method
> > invocations will get close). I think the current mechanism is fine.
>
> Agree. The only other major source is implementation of switch statements
> with dense ranges (jump tables).
Another optimisation I'm thinking of is
> Hmm, that differs from what the internal valgrind profiler itself tells
> us ... about 30-40% of the time starting up mozilla, on memcheck, is
> translation. That also corresponds (non-quantitatively) with the speed
> variations in the lines printed by -v -v when running stuff (try it).
Is there a set of benchmarks you've been using for this kind of stuff?
It would be useful to have a set for evaluating all the proposals that
have been flying around lately. It would be nice to have something less
interactive than Mozilla, for example. I'm particularly short of nice
examples of multithreaded programs which arn't all GUI.
> Disco: Running Commodity Operating systems on scalable multiprocessors.
> Bugnion, Devine, Rosenblum (at least the last of these is a founder of VMware,
> Inc). 1997 ish. I'm sure you can scag it from the web somewhere; I'd start
> at citeseer. I only have a paper copy.
Hm, I think I've read that paper, but I don't think can I paid attention
to it. I've certainly read the Cellular Disco paper.
J
|