[Mono-devel-list] RAPGO Proposal

[Paolo Molaro]

On 11/29/04 Willibald Krenn wrote:
> >We have already the code to deal with this.
> 
> Could you give me a pointer? I wasn't aware of that - must be some 
> relatively new thing..

Described in the summit notes: the code is not in cvs yet.

> >Counters are not needed and would be too slow. We can simply walk
> >the stack of the various threads and see if any is inside the method.
> >At first, there is no need to free the code, since we'll only recompile a 
> >method once or twice, so the 'leak' is bounded.
> 
> I see. So you are first patching all invocations to go to the new method 
> and will then check all threads whether they are within the 'old' method..
> When do you think stack walking will be slower than having counters?

Only in degenerate cases (many threads each many call frames into the stack,
where many is in the thousands). Using counters would be a nightmare to 
maintain.

> Well, a sampling profiler will slow down execution too, but not that 

A lot less and after the hot methods are recompiled it could be
shut down or the sampling frequency could be reduced.

> much. However, you won't get all information you need for certain 
> optimizations by using a sampling profiler AFAIK, so IMO it's still 

Sampling the call stack and not just the IP address should provide
most of the interesting info.

> beneficial to instrument methods that have been shown by sampling to be 
> 'hot'. The resulting slowdown will IMO be minimal (especially if MMX 
> registers are used, the float pipeline isn't populated by the method to 

Note that we are interested in portable solutions: using arch-specific
stuff is of course welcome, but the solution should be implementable in 
other architectures, too.

> Code that runs endlessly in a loop probably isn't a good candidate for 
> runtime replacement at all. Probably 'transfer-points' - icalls p/i 

Eh, yeah, if we could remove issues by just saying they don't exist:-)

> calls are good candidates - could be introduced that have a known 
> stack/register state, but well..

Sure, but it's a lot of complex work.

> Ok, point taken. (Although if you'd move inssel into the backend and let 
> the inssel generate the final code into the target buffer, things should 
> be faster. However, it's questionable how much.)

That would prevent a cheap but effective peephole pass, so your proposal
would actually slow down mono.

> I'm quite surprised no-one commented on my C++ proposal! So does that 
> mean if I send patches that use C++, you'll accept them?

I didn't see any reference to C++ in your mail: you talked about objects,
but we're fairly good at doing objects in C, too (see the linux kernel, 
Gtk+, etc:-)
Anyway, no C++ code in the runtime.
Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better