I'd like to know about how AddSimulate() and FinishExitWithDeoptimize() work together?

[Amy]

From a google v8 video, I heard that the simulate instruction is for the de-optimization. I went through the code and found out there is AddSimulate() appearing in the BasicBlock, GraphBuilder, and CodeStubGraphBuilder, etc., while FinishExitWithDeoptimize() in the OptimizedGraphBuilder. 

My feeling is that maybe AddSimulate() is like a setLongJump(); while FinishExitWithDeoptimize() will do a longJump(). Is this feeling correct? 

How the de-optimization stuff work? 

What about IC related to de-optimization? 

Thanks very much.

[Jakob Kummerow]

There's no direct relationship between AddSimulate() and FinishExitWithDeoptimization(). Both are helper methods to add certain HInstructions to the Hydrogen instruction graph.

Simulates are "safe points" or "snapshots" of the compiler's "environment", which reflects the execution state of the program, live values on the stack and such. Simulates have associated program counter addresses in both optimized and unoptimized code that can be translated to each other. When a deoptimization happens, execution resumes at the address in unoptimized code that corresponds to the last simulate (or basic block entry) before the deopt point. That's why there must generally be a simulate after each instruction with observable side effects, i.e. after anything that can't just be skipped or re-executed.

FinishExitWithDeoptimization() is just one of many ways of creating potential deoptimization points. Its purpose is situations like "insert an instruction to compare the hidden class of this object; if it's class A jump to block X which will handle that, if it's B jump to block Y; otherwise insert an unconditional Deopt instruction and then finish the current block".

"The deoptimization stuff" is tricky business involving replacing the current stack of the optimized code with what the unoptimized code expects. If you're interested in the details, you should look at the source code.

ICs are not related to deoptimization.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Yue Xing]

Jakob, Thanks very much! It helps a lot. 

One more question related to your answer, my understanding about de-optimization is that it happens during execution time when some guard is compromised, then the de-opt instruction(s) are invoked. In the compilation/optimization time, the de-opt instruction(s) are inserted at potential points.  Is this correct?

I read through the hydrogen.cc and I saw some checkXXX instructions. Are those also used for the potential de-opt points? 

Sincerely,

Amy

You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/gE7UZAw8AMs/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.

[Jakob Kummerow]

On Sun, Apr 14, 2013 at 11:09 PM, Yue Xing <amyue...@gmail.com> wrote:

Jakob, Thanks very much! It helps a lot. 

One more question related to your answer, my understanding about de-optimization is that it happens during execution time when some guard is compromised, then the de-opt instruction(s) are invoked. In the compilation/optimization time, the de-opt instruction(s) are inserted at potential points.  Is this correct?

Yes.

 

I read through the hydrogen.cc and I saw some checkXXX instructions. Are those also used for the potential de-opt points? 

Yes.

But you won't see all possible deoptimizations explicitly on the Hydrogen level. Look for uses of DeoptimizeIf() in src/$ARCH/lithium-codegen-$ARCH.cc for more. 

[Yue Xing]

Sure, I will. You are very helpful, really.

A very silly question, I am a newbie to v8, so my ways to try to understand v8 is:

1) build and run benchmark (with flags), which gives me some feeling about v8;

2) read blogs and see video, which gives me basic ideas;

3) refer to the code, however, the code is too much for me, and I want to quickly grab how all the parts work together (for example, I see there are hydrogen, ic, lithium, even build graph and build optimized graph, however, I still now how all the things work together);

4) refer to "git log" to see the changes, still very hard;

Could you give me some suggestions that I can see how the parts work together? All I can think (maybe my next step) is to use gdb to step through function calls, which is tooo inefficient as to huge v8.

Sincerely,

Amy

[Dmitry Lomov]

I do not think we have too much learning material on v8 available (frankly, not even internally :) ).

If you haven't seen them already, Andy Wingo's articles are helpful to many people: http://wingolog.org/tags/v8

You mentioned that you are using it already,  but just in case you haven't seen it, various debug printing options on v8 are very useful (--print-code --code-comments, print-opt-code and many others).

One useful way to approach this might be to write some examples that you think should cause certain behaviors (e.g. deoptimizations), run them with appropriate --trace-* commands (e.g --trace-deopt) and then set breakpoints in in places in code where traces are generated.

 

There are some debugging intrinsics as well, such as %OptimizeFunctionOnNextCall. E.g. if you want to see what an optimized (hydrogenized) code for the function will look like, the following is useful:

function f(x, y) {

  return x+y;

}

f(1,2);

f(3,4);

%OptimizeFunctionOnNextCall(f);

f(5,6);

and run this with --allow-natives-syntax --print-opt-code --code-comments. This will show you the hydrogen code for function f.

In case you do not know it, CodeSearch on cs.chromium.org contains (as part of chromium project) a cross-referenced browser-navigable source code for v8, see for example:

https://code.google.com/p/chromium/codesearch#chromium/src/v8/include/v8.h&q=v8&sq=package:chromium&l=1 
I personally find it very useful. 

Hope this helps and best of luck!

Dmitry

[Yue Xing]

"run them with appropriate --trace-* commands (e.g --trace-deopt) and then set breakpoints in in places in code where traces are generated", 

when you are saying "set breakpoints", is that in javascript code or v8 code ?

 If for v8, how can I know where traces are generated? My way is to search the output string,  set breakpoint, run and view backtrace dumped from gdb. Any better way?

For javascript, I only know how to set breakpoint in Chrome with developer tools, but with "d8" commend line, I am still wondering where and how to do that?

where can I find more stuff like "OptimizeFunctionOnNextCall", their prototypes and documents. 

Thanks very much