If you run with --print-code --code-comments you will see generated code (v8 should be build with objectprint=on disassembler=on) and you'll have to locate bailout in the code and figure out why it happens.
If it happens only once then the reason it probably that the function was optimized before it got correct type feedback. I took a very quick look through 2nd version of code that V8 generates for Arbiter.applyImpulse, without trying to understand what it does, just by looking for inefficiencies. I don't see anything obvious but there are two things: 1) V8 seems to exhaust inlining budget when trying to inline things into applyImpulse. It leaves one call in the loop not inlined, which prevents proper LICM and probably causes unnecessary boxing. If I relax inlining budget by --nolimit-inlining I get 10% boost on the benchmark. 2) There are fields mutated in the loop that contain floating point values. This currently requires boxing (and boxing requires heap allocation, heap allocation puts pressure on GC etc). I wonder if you can put typed arrays (e.g. Float64Array) to work here. -- Vyacheslav Egorov On Thu, Dec 29, 2011 at 4:18 AM, Joseph Gentle <[email protected]> wrote: > Wow, thats awesome information. That would explain why the function in > question is slow, and why inlining a couple of the function calls it makes > decreases overall speed. > > How do I read the trace I get back? I'm getting this: > > **** DEOPT: Arbiter.applyImpulse at bailout #49, address 0x0, frame size > 264 > [deoptimizing: begin 0x1b70ac6a67f1 Arbiter.applyImpulse @49] > translating Arbiter.applyImpulse => node=432, height=216 > 0x7fff6f711630: [top + 248] <- 0x3ebe7f33eb9 ; [esp + 296] > 0x3ebe7f33eb9 <JS Object> > 0x7fff6f711628: [top + 240] <- 0x2457afa6b4ad ; caller's pc > 0x7fff6f711620: [top + 232] <- 0x7fff6f7116c0 ; caller's fp > .... > > I assume address 0x0 means something the function is doing is hitting a > null object. Does bailout #49 mean anything? The function is (later) > repeatedly optimized and deoptimized again with bailout #8. How do I track > these down? > > -J > > > On Monday, 26 December 2011 23:56:31 UTC+11, Vyacheslav Egorov wrote: > >> This is a multiplication stub that is usually called from non-optimized >> code (or optimized code that could not be appropriately specialized). >> Non-optimizing compiler does not try to infer appropriate representation >> for local variable so floating point numbers always get boxed. >> >> If this stub is high on the profile then it usually means that optimizing >> compiler either failed to optimize hot function which does a lot of >> multiplications or it failed to infer an optimal representation for some >> reason. >> >> Bottom up profile should show which functions invoke the stub. Then you >> should inspect --trace-opt --trace-bailout --trace-deopt output to figure >> out what optimizer does with those function. >> >> -- >> Vyacheslav Egorov >> >> On Mon, Dec 26, 2011 at 7:00 AM, Joseph Gentle <[email protected]> wrote: >> >>> What does it mean when I see BinaryOpStub_MUL_Alloc_**HeapNumbers in my >>> profile? Does that mean the compiler is putting local number variables on >>> the heap? Why would it do that? >>> >>> -J >>> >>> -- >>> v8-users mailing list >>> [email protected] >>> http://groups.google.com/**group/v8-users<http://groups.google.com/group/v8-users> >> >> >> -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
