On 2010/01/25 12:41:36, Søren Gjesse wrote:
This is an interesting aproach to changing the code of a running function.
Well, not necessarily running, but 100% already instantiated.
1. Current activations of a function which is changed will stay the same,
and
cause a mix of code for that function. With our current code generation I
don't
think it will be possible to replace activated code. Should this be
disallowed
if the function is active?
Yes, probably. However, Java seems to implement a good compromise solution,
because changing already running function is a use case too tempting. They
reset
top activation to the entry point. If there are more problem functions on
stack,
they remove several frames and reset the top activation. I think we may
implement the same. Vitaly reminds about native frames, which may block this
scenario though.
2. What happens if the number of arguments to a function is changed? Call
sites
in other functions might be expecting the original number of arguments,
and
will
set up adaptor frames for the original number of arguments.
Probably we should not support changing number of arguments for already
instantiated functions.
3. With our current structure only function with a trivial scope can be
layily
compiled. See AllowsLazyCompilation() on FunctionLiteral. Functions which
does
not have these properties will not be suitable for this (this might
change at
some point though).
Thank you for describing this. I base my current approach around solving
this
issue.
4. How about functions outside the patch itself. As far as I can see the
position in the script is updated in their SharedFunctionInfo, but if
these
are
compiled then all the position information in the relocation information
should
also be patched.
Yes, good point. I haven't tried this yet, but it seems to be doable.
5. What about existing script break-points? Some of these might also need
to
be
moved.
Probably same with #4.
6. If any of the constraints to allow this operation is violated an error
should
be returned and no change should happen.
The current work definitely lacks good error handling/diagnostic. Probably I
will develop it later. Note, that Pavel suggests other possible strategy:
function gets stub that simply throws exception like "this is a
compilation-challenged function".
Theoretically, we can combine.
Another thing is that I am not sure whether this makes much sense if the
tool
performing the script patching is not controlling the actual source. E.g.
if
changing source in the Chrome DevTools these changes will be transient as
the
source will be reloaded from some URL with no control from DevTools.
I think supporting it in tool and in V8 are more or less separated tasks.
This
work is concentrated on V8.
As for the tool, there is Eclipse plugin, which may change actual sources
quite
naturally (there are even some contributors, who are interested in binding
our
plugin with JSDT). For Chrome we should devise some other plan. What seems
practical for me, is some special extension inside Chrome browser, that
sends
all patches directly to developer's agent, that applies them to source
files.
http://codereview.chromium.org/546125
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
