On Wed, Sep 3, 2014 at 10:32 AM, enormouspenguin <[email protected]> wrote: > Looks like I have just wandered myself far off into some pretty low level C++ > stuff that I have little to no knowledge about. Sorry but I couldn't > understand over half of your reply (only the "stack top" function explanation > part that I think I do understand, the rest is some kind of mystery). A lot > of naive questions pop up in my head: > > _ Where should I insert that code snippet? Why the 42 check? Is 42 some kind > of magic number? > _ Why pass x to printST() while it's main purpose is just simply print out > stack length that needs no argument? If x is necessary then what is the value > of x should I pass? Where should I call the new printST(x)?
42 is only a magic number insofar that it acts as a marker. Calling printST() recursively once ensures that there are two printST stack frames when the stack is captured. Because of a bug, V8 skips the first one but then picks up the second one. > _ What is self-optimizing JS code, isn't V8 responsible for optimization > process of JS run-time? Should I do self-optimizing a lot? Self-optimizing means that the generated native code for a JS function keeps track of when it can be optimized. For context, V8 consists of two compilers: the baseline and the optimizing compiler. The baseline compiler generates slow code fast, the optimizing compiler generates fast code slowly (to a first approximation.) Code generated by the baseline compiler contains heuristics like "how often has this function been called?". It's those heuristics that decide when to call the optimizing compiler. See [0] for a more detailed explanation. [0] http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-compilers > _ Where is raw_frame located in C++ source files? How can an exit frame > generated where I couldn't see any line of code I wrote that call a Node.js > native C++ addon? They're inserted into the generated code with the mechanism from the previous paragraph. It's an implementation detail that you normally wouldn't have to worry about. All the relevant code is in deps/v8/src if you're curious. > _ Is the call stack behavior different and unpredictable in live-optimized > and interpreted languages like JS compare to pre-optimized and then compiled > languages like C? If an exit frame wipe out entire current stack then how > could Node.js profiling be accurate? The exit frame (maybe "transition frame" is a better name but exit frame is what V8 calls it) doesn't wipe out the stack but it puts it in a configuration that V8 code elsewhere isn't quite able to cope with. By the way, the profiler (the --prof switch) is quite different from the optimizer. It's a sampling profiler, it doesn't instrument native code; it just collects samples of the program state at a fixed interval. > You are welcome to just ignore me because that is a lot of questions and I am > in a totally different and extremely lower level than you (I have no > experience in C/C++, although I did learn some in my university). I feel > embarrassed to even ask the question in the first place. But still I want to > learn more (university seem never enough) . So any direction pointing would > be much appreciated. Thank you for your time. No problem, happy to help. Let me know if things are still unclear. V8 is pretty large and complex, there's a lot to take in. -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAHQurc_kT0Kpq3bQHxzKkWWsEt8YkzZvdHH-Pg9yGJTuhWQy5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
