I see. But what about sampling? It shouldn't slow down the program nearly as much as these "instrumentation" like mechanisms. And as I'm going to count them anyways, missing the most unused ones won't be such a problem. That combined with complete capture for a small run (like a test or block) would be enough for our needs. On Tue, Sep 24, 2013 at 4:19 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Sep 24, 2013, at 9:09 AM, Alejandro Pulver <alepulver@gmail.com> wrote:
Thanks for the reply, but the links mentioned in the forum are down. Also, I would a solution that works in Pharo 2.
Wrapping every method in the system doesn't look like an efficient solution. I know about Bifrost but it's implemented in 1.0 and not likely to be ported to 3 soon (according to a discussion I found recently).
Do you know a reason why the profiler of changing perform won't work?
perform: is not called when doing a message send. Reason: it would be too slow to explicitly call a method to do a message send. Everything is in the VM.
We are working (slowly) on a new version of Reflectivity (Partial Behavioral Reflection) that is the basis of bifrost. But even then, if you replace every message send by multiple ones, the result will be a *very* slow system.
This is in the end the real problem of behavioral reflection: it is not only difficult to find a good model and implement it in a way that it works for real even in strange cases (e.g. kernel classes that are used by the reflective layer itself).
The real challenge is to make it fast. And that is not easy: just replacing the message send byte code by o multiple reflective sends will slow things down quite a lot, regardless how clever you are.
Marcus