OK, I've tried out the latest commit. The changes to the MV implementation
seem fine to me, though I haven't tested or analyzed them other than to
confirm that our code isn't affected. I like that the generated code
is simpler, and I agree with your choice to not support passthrough
unless/until we can find a correct implementation that isn't too
complicated. In the absence of that, the latest version seems like a
good compromise and an improvement over what we had before. It's a
reasonable place to stop.
That being said, there's one point that's still bugging me because I
don't see it yet:
>> Other exit points from a function are throws and control reaching the
>> end of the function. So both are going to have to get instrumented.
I sketched an argument why extra instrumentation isn't needed in these
two cases. If that argument is wrong (which it may well be) then we
should be able to give examples where the pure global-variable (GV)
design fails in the absence of such implementation. That is:
(1) An example where an uninstrumented throw causes the GV
implementation to be wrong; and
(2) An example where an uninstrumented function exit causes the
GV implementation to be wrong.
I don't think any of the examples in the thread satisfy (1) or (2),
nor have I come up with any. Can you? I'd like to see them.
Daniel
On Thu, Sep 13, 2012 at 12:00 AM, Vladimir Sedach
<vsedach@gmail.com> wrote:
Ok, I just pushed the promised change that removes mv passthrough and
replaces the function object property setting with a global variable.
I'm very happy with this approach - the generated code is now much
cleaner than it used to be.
Please try the changes out. If there aren't any issues, this is going
in to the next release, which I'd like to make by the end of the
month.
Happy hacking,