Thank you for your answer!

The runtime profiler is the one that decides if a function is hot, right?
I wanted to have a general understanding of how the IC works. How the 
profiler runs, detects hot functions, or small functions, to optimize, and 
tries to optimize them.
Basically, the Full compiler compiles the full code (except functions, for 
them the compiler generates stubs), after that, the runtime profiler starts 
running, and choosing which functions are hot, based on how many times are 
the functions placed in the stack, or if the function are small, or if 
there's enough type information about the function. And for this functions, 
there are attempts to optimize them with Crankshaft, and save the optimized 
code in IC stubs. If the assumptions about the type expected are right, 
then there's some time gaining due to the optimized code (cached in the IC 
stub), but if there the assumptions are wrong (i.e. there's a new type 
other than the expected) then deoptimization happens, the optimized code is 
thrown away, and the function is re-compiled with the Full compiler.
Would that be an accurate description of how the IC works?

I've read online in a Google V8 presentation that there are the following 
states regarding IC:
Uninitialized -> Pre-monomorphic -> Monomorphic -> Polymorphic/Megamorphic 
-> Generic
How should I build an example, or which flag should I use to see the 
transitions between these states?

Thank you for your help! I'm new with the v8, and the replies are really 
helpful.



On Monday, September 21, 2015 at 5:43:07 PM UTC+2, Jakob Kummerow wrote:
>
> On Mon, Sep 21, 2015 at 4:53 PM, Ignacio Queralt <[email protected] 
> <javascript:>> wrote:
>
>> [snip]
>>
>> My questions would be:
>> 1) Where are the transitions between Uninitialized, and Monomorphic of 
>> the newadd function, for instance? I read that there are some Uninitialized 
>> -> Smi, but I can't see the relation in the output to my function newadd().
>>
> We don't use the term "monomorphic" for binary ops, only for loads and 
> stores, so the BinaryOpIC transitions you're seeing in "newadd" are exactly 
> what's expected to happen.
>
>> 2) How does the IC technique works here? I've seen in the code, in 
>> runtime-profiler.cc that here's where the OptimizeNow() function is called, 
>> but I don't understand how many times or why is it called. Does anyone here 
>> knows how it works?
>>
> The runtime profiler has nothing to do with ICs. (Well, almost nothing, it 
> uses some hints from the IC system to make its decisions, but is not 
> required for the IC system to work.) An IC misses when it sees a new type, 
> then the code in src/ic/ic.cc patches it to fit the new types.
>
>> 3) What does LoadIC, StoreIC, CompareIC and BinaryOpcIC mean?
>>
> A LoadIC handles loads, e.g. "foo.bar". A StoreIC handles stores, e.g. 
> "foo.bar = 1". A Compare IC handles comparisons, e.g. "foo == bar". 
> Finally, a BinaryOpIC handles binary ops (hard to guess, eh?), e.g. "foo + 
> bar". 
>
>

-- 
-- 
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.

Reply via email to