On Wed, Feb 10, 2016 at 2:38 PM, D T <[email protected]> wrote:
> Thanks Jakob, for your answer and sorry for the late response.
>
> Another thing that came to my mind: Considering I do not execute the JS
> code with d8 and the print-opt-code flag but directly within my chrome
> browser:
> Is the produced code the same? Meaning, does it matter, if I execute the
> JS code with d8 or directly in chrome? To my understanding it shouldn't,
> since they both use the same interpreters/JIT compilers...
>
Correct, the generated code should be the same.
> However, a final question to this topic: When v8 produces the optimized
> code, it generates the AST based on the fully generated code, then letting
> the runtime profiler mark hot regions to optimize (I know this is a very
> high level and non-technical view ;) ).
> Does this mean, when I execute JS code within my chrome browser, the fully
> generated code is loaded into memory, before it is optimized and executed?
>
I don't know what you mean by "fully generated code".
The usual sequence for hot code is:
(1) The parser parses the JavaScript source and builds the AST.
(2) The non-optimizing compiler (we call it "full-codegen") generates
non-optimized machine code from the AST. The AST is then discarded (because
it's pretty big), and the generated non-optimized code is executed.
(3) V8 notices that the code is executed a lot and decides to optimize it.
This decision is made on a per-function basis.
(4) The parser (again!) parses the JavaScript source and builds the AST.
This is relatively fast, so throwing it away in the meantime was worth it
to save memory.
(5) The optimizing compiler (we call it "crankshaft") generates optimized
code from the AST, consuming type feedback collected by the unoptimized
code.
Everything (JavaScript source, AST, unoptimized code, optimized code) is in
memory -- where else would it be?
For non-hot code, steps (3) to (5) don't happen.
Side note: we're working on a new architecture ("Ignition" + "Turbofan")
that will change the way the system works.
> Please let me know, if I managed to confuse you :D
>
>
> Am Montag, 21. Dezember 2015 18:07:32 UTC+1 schrieb Jakob Kummerow:
>>
>> On Mon, Dec 21, 2015 at 5:38 PM, D T <[email protected]> wrote:
>>
>>> To my understanding, this is the ASM code, V8 produces for my Javascript
>>> input file?
>>>
>>
>> Yes. More specifically, it's the optimized code that was generated for
>> your "rnd" function.
>>
>>
>>> So if I execute my JS file with Chrome (using V8), I should find the
>>> exact same code in memory, or don't I?
>>>
>>
>> Yes.
>>
>>
>>> Furthermore: How do I reliably find the code-
>>>
>>
>> Right where it says:
>> 0x2020e060 0 55 push ebp
>> ^^^^^^^^^ This is the address of the "push ebp" instruction.
>>
>>
>>> is there a specific region where V8/Chrome normally writes to?
>>>
>>
>> No.
>>
>> What exactly do you mean when you say you want to "find the code"?
>> From a debugger? Use the address you see in the --print-opt-code output.
>> From JavaScript? Raw object addresses are not exposed to JavaScript, so
>> this should be impossible. (If you do find a way, then you've probably
>> found a security bug, which we'd love to hear about!)
>>
> --
> --
> v8-users mailing list
> [email protected]
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
v8-users mailing list
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
