Updates:
Status: Accepted
Comment #1 on issue 1840 by [email protected]: High num of deopts for
attached production code from game engine
http://code.google.com/p/v8/issues/detail?id=1840
I've had a look at the deopts, and they break down into several categories:
* The deopts in String.replace, mandreel_webAudio_PreloadAssets,
_ZN11CFileSystem5fseekEli, Mandreel_Audio_Init_, __v_printf, uint and most
of the ones in _ZN15chanka_test_pvr15PVRTCDecompressEPKviiiPh are caused by
missing type feedback. This means, v8 compiles them to optimized code, but
does not have type information for code which hasn't been run yet.
Subsequent compilations will have gathered more information, so this
improves over time. This is simply how v8 works, and there is nothing wrong
with it.
* Malloc checks for 'heap == 0', and assigns an ArrayBuffer to heap in
that case. The next time Malloc is called, it expects heap to be an
integral number, so it deopts. This could be avoided by using e.g.
undefined as the special value and testing with 'heap === undefined'. In
general, mixing types is not a good idea when it comes to performance in v8.
*Under some conditions,_ZN15chanka_test_pvr15PVRTCDecompressEPKviiiPh
deopts at the division "r2 = (r2 /r3)&-1". The reason for this is that both
r2 and r3 are known to be integral values, so v8 chooses to do integral
division, but deopts when the remainder is not zero. This is a more tricky
one, because JavaScript has no way to express an integer divide directly.
Perhaps we can do something more clever in v8 here, because it is obvious
that only the integral quotient will be used, anyway. What currently
happens is that the function gets recompiled and uses floating point
division, which will work without deopts, but this is obviously non-optimal.
Another reason for the latter deopt could be division by zero, a result of
-0, or an integral overflow, but I guess that this is not the case, but it
would be good if this could be checked.
In a nutshell: We should reconsider how and when we use div-i
internally... :-/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
