>
> return (function JSIL_ArrayEnumerator() {
> return state.ctorToCall.apply(this, arguments);
> });
>
> Bailout in HGraphBuilder: @"JSIL_ArrayEnumerator": bad value context
> for arguments value
Interesting. There is a "small" detail that my slides do not mention:
.apply must be the builtin apply function and expression should be
monomorphic.
Monomorphic example that will be optimized:
function apply() { arguments[0].apply(this, arguments); }
function foo() { }
function bar() { }
apply(foo);
apply(foo);
apply(bar);
apply(bar);
// Both foo and bar have same hidden classes.
Polymorphic example that will not be:
function apply() { arguments[0].apply(this, arguments); }
function foo() { }
function bar() { }
bar.foo = "aaa"; // After this point foo and bar have different hidden classes.
apply(foo);
apply(foo);
apply(bar);
apply(bar);
// now .apply expression inside apply is not monomorphic and compiler
will say "bad value context for arguments value".
Did you patch Function.prototype.apply or add properties to your
functions? This might explain why .apply optimization gets confused.
> Bailout in HGraphBuilder: @"System_Threading_Interlocked_CompareExchange":
> bad value context for arguments value
This one might be tricky. Assumptions V8 makes during compilation are
all based on type-feedback. If argc was never equal to 4 before V8
tried to optimize System_Threading_Interlocked_CompareExchange V8 just
will not know that .apply there is a built-in Function.prototype.apply
so it will bailout. I suggest avoiding .apply on rarely executed
branches in hot functions if possible.
Of course there might be still a possiblity that .apply access is
polymorphic as described above.
> Your explanation on why the no-message deopts occur is helpful
To be precise I was referring to deoptimization that happens on
"deoptimize" instruction you quoted in your first mail.
[please do not hesitate to ask more questions!]
--
Vyacheslav Egorov
On Wed, Jul 18, 2012 at 6:06 PM, Kevin Gadd <kevin.g...@gmail.com> wrote:
> Thanks for the detailed response. Unfortunately I didn't write down
> the example I saw with arguments.length causing it - it may have been
> me misreading the output, or perhaps it was from inlining? However,
> there are certainly a bunch of uses of fn.apply(this, arguments),
> which the presentation also said would be fine, and those are bailing
> out. Here are two examples (both generated by code at runtime, so if I
> can change the generated code to fix this, I'd love to know about it
> :D)
>
> return (function JSIL_ArrayEnumerator() {
> return state.ctorToCall.apply(this, arguments);
> });
>
> Bailout in HGraphBuilder: @"JSIL_ArrayEnumerator": bad value context
> for arguments value
>
> return (function System_Threading_Interlocked_CompareExchange() {
> var argc = arguments.length;
> if (argc === 4) {
> return thisType["CompareExchange`1$559[!!0],!!0,!!0=!!0"].apply(this,
> arguments);
> }
>
> throw new Error('No overload of ' + name + ' can accept ' +
> (argc - offset) + ' argument(s).')
> });
>
> Bailout in HGraphBuilder:
> @"System_Threading_Interlocked_CompareExchange": bad value context for
> arguments value
>
> In total I see something like 30 'value context for arguments value'
> bailouts when starting this test case and almost all of them look like
> they should be okay based on that slide, so I must either have
> misinterpreted the slide or it's not correct anymore.
>
> Your explanation on why the no-message deopts occur is helpful; if I
> assume that they indicate polymorphism maybe I can use that
> information to try and zero in on locations within the function where
> polymorphism might be occurring and make some headway that way.
> Thanks.
>
> --hydrogen-filter sounds like *exactly* what I need, so thank you very
> much for mentioning that. :D
>
> -kg
>
> On Tue, Jul 17, 2012 at 11:52 PM, Vyacheslav Egorov
> <vego...@chromium.org> wrote:
>> Hi Kevin,
>>
>> To be absolutely honest all these flags historically were made by V8
>> developers for V8 developers. You usually can't interpret what they
>> print without understanding of how V8 works internally, how optimizing
>> compiler IR looks like etc. We advocate them for JS developers only
>> because there is nothing else available at the moment.
>>
>> [I was always convinced that V8 needs a more gui-sh thing that would
>> overlay events from the optimizing compiler over the source of
>> function but that is not so easy. I was playing with some prototypes
>> but at some point I gave up... It requires attaching source position
>> information to individual IR instructions (plus merging this
>> information somehow when we optimize code and remove redundant
>> instructions) and to make it worse: AST does not even have a span
>> information attached to each node... you can't say that expression a +
>> b starts a position X and ends at position Y to correctly highlight
>> the whole offending expression.]
>>
>> The deoptimization that you are mentioning in the first message
>> indicates that either the execution reached a part of the function
>> that was optimized before typefeedback for it was available [this
>> happens a lot for big functions or functions with complicated control
>> flow and rarely executed parts] or you have a polymorphic property
>> access site that had a small degree of polymorphism at the moment of
>> compilation, but now it saw some new hidden class.
>>
>>> To provide one example: I did some spelunking around with
>>> --trace-deopt and --trace-bailouts and found that in my codebase,
>>> basically any use of the 'arguments' object - even just checking
>>> 'arguments.length' - causes the entire function to be deoptimized.
>>
>> Can you provide more information about this? What kind of --trace-
>> deopt/trace-bailout output made it look like arguments.length causes
>> deoptimization?
>>
>>> Non-v8/non-chrome devs saying false things about V8
>>> performance isn't your fault
>>
>> To be precise presentation your are linking to was made by me and I am
>> V8 dev.
>>
>>> Thanks for the info about c1visualizer - I bet the memory limit was
>>> probably responsible for the flakiness and if I fiddle with JVM
>>> parameters it might work. I'll give it another try later on.
>>
>> C1Visualizer has a major problem with its memory consumption. Big IR
>> dumps usually have to be either split into separate files (I do it
>> with a small script) or minimized by applying --hydrogen-filter=foo
>> flag to block optimization of all functions that are not called foo.
>>
>> --
>> Vyacheslav Egorov
>>
>>
>>
>> On Jul 18, 12:42 am, Kevin Gadd <kevin.g...@gmail.com> wrote:
>>> Thanks for the link to that video, I'll give it a look. Based on your
>>> suggestion I'll try doing a custom build of Chromium and see if the
>>> disassembly will let me make sense of things.
>>>
>>> The reason this is a real problem for me (and why I find the lack of
>>> documentation for this stuff in chromium frustrating) is that I'm
>>> machine-translating code from other languages to JS - hand-editing it
>>> to make it faster is something I can do for code I'm writing myself,
>>> but I can't do it in a compiler. The current nature of the performance
>>> feedback from V8 makes it more or less a black box and this is
>>> worsened by the fact that a large amount of the documentation I've
>>> found out there that claims to describe V8 performance characteristics
>>> is either wrong or outdated. When you profile an application in V8 and
>>> the web inspector says you're spending 50% of your time in a simple
>>> function, your only choice is to dig deeper to try and understand why
>>> that function is slow. You could solve this by offering line-level
>>> profiling data in your profiler, but I think that's probably a ton of
>>> work, so I'm not asking for that. ;)
>>>
>>> To provide one example: I did some spelunking around with
>>> --trace-deopt and --trace-bailouts and found that in my codebase,
>>> basically any use of the 'arguments' object - even just checking
>>> 'arguments.length' - causes the entire function to be deoptimized. Of
>>> course, there isn't a ton of documentation here,
>>> buthttp://s3.mrale.ph/nodecamp.eu/#57along with other sources claim that
>>> this is not the case. So, either something creepy is happening in my
>>> test cases - more verbose feedback from V8 here, or concrete docs from
>>> the devs themselves would help - or the information being given to the
>>> public is wrong. Non-v8/non-chrome devs saying false things about V8
>>> performance isn't your fault, but it wouldn't hurt to try and prevent
>>> that by publishing good information in textual form on the web.
>>>
>>> I hope I'm not giving the impression that I think V8 is the only
>>> problem here either; JS performance in general is a labyrinth. Based
>>> on my experiences however, the best way to get info about V8
>>> performance tuning is to talk to a Chromium dev directly or hunt down
>>> YouTube videos of hour long presentations. This is pretty suboptimal
>>> for a developer who's trying to tackle a performance issue in the
>>> short term - Google is surprisingly bad at finding either of those two
>>> info sources when you dig around or search for diagnostic messages.
>>>
>>> I've personally been documenting everything concrete I learn about
>>> this stuff on my wiki, but once I stop doing this day-to-day, all that
>>> information will get outdated and mislead future developers. I think
>>> that sucks, and the only good solution is for JS runtime devs to
>>> provide concrete information on performance pitfalls and such in an
>>> easily found location and keep it somewhat up to date. I don't think
>>> you guys necessarily need to make --trace-deopt or --trace-bailout
>>> super user friendly, but if you don't, there needs to be some basic
>>> guidance out there for developers so that JS flags aren't their only
>>> option for understanding Chrome performance.
>>>
>>> Thanks for the info about c1visualizer - I bet the memory limit was
>>> probably responsible for the flakiness and if I fiddle with JVM
>>> parameters it might work. I'll give it another try later on.
>>>
>>> -kg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 17, 2012 at 3:32 PM, Jakob Kummerow <jkumme...@chromium.org>
>>> wrote:
>>> > Seems like you're finding out the hard way what a complicated beast a
>>> > modern
>>> > JS engine is ;-)
>>>
>>> > --trace-deopt is certainly usable; but it is not geared towards
>>> > ease-of-use
>>> > for JavaScript developers, that's for sure.
>>>
>>> > Helpful flags are --print-opt-code and --code-comments. Those two together
>>> > will print the disassembled code for *optimized* functions, interleaved
>>> > with
>>> > some comments, such as the IDs of the HIR instructions that generated the
>>> > code (which is what the "@36" in your example refers to), and the
>>> > deoptimization IDs ("bailout #7" in your example). And yes, there can be a
>>> > lot of disassembled code that gets printed when you feed a lot of
>>> > JavaScript
>>> > code to V8 -- redirecting output to a file and opening that with an editor
>>> > makes this easier to manage.
>>>
>>> > Since disassembly is involved, --print-opt-code only works when V8 has
>>> > been
>>> > built with disassembler support. That's the case in a debug mode build, or
>>> > in release mode when you specify GYPFLAGS="-Dv8_enable_disassembler=1"
>>> > (when
>>> > you build d8 with GYP/make, we have a convenience option for that: "make
>>> > disassembler=on ia32.release"). If you build your own Chromium anyway, you
>>> > can also change the flag's default value in src/v8/build/common.gypi, if
>>> > you
>>> > find that easier than setting an environment variable.
>>>
>>> > Due to the optimizations that the optimizing compiler does, there is no
>>> > mapping from assembly instructions (or deopt points) to line numbers. I'm
>>> > not sure if and with how much effort it'd be possible to hack up support
>>> > for
>>> > that. I agree that it would be great if Chrome's dev tools could show you
>>> > where deopts happened, and why...
>>>
>>> > c1visualizer is still state of the art to visualize what the optimizing
>>> > compiler does. Yes, it's a somewhat sorry state of things, but it can be
>>> > very helpful. Probably more helpful for debugging the compiler than for
>>> > debugging JavaScript, though. Upping the max memory helps a lot when
>>> > loading
>>> > large hydrogen.cfg dumps.
>>>
>>> > There aren't all that many reasons for deopts, and it's relatively easy to
>>> > learn which JS constructs can cause a deopt at all: mainly stuff that
>>> > hasn't
>>> > happened earlier, e.g. accessing a property of an object with a new type,
>>> > or
>>> > a double value suddenly being undefined, or code after a long-running loop
>>> > that's never been executed before, or an array access out of bounds that
>>> > was
>>> > within bounds earlier, and so on. So with some experience, and assuming
>>> > you're not running into bugs/deficiencies of V8, staring at assembly code
>>> > won't even be necessary. Also, if you find that by refactoring your
>>> > function
>>> > (e.g. splitting it into two smaller functions) you can prevent the deopt,
>>> > that's not really a problem, is it? It's kind of the solution you were
>>> > looking for in the first place, right?
>>> > [Btw, there's a pretty recent video of a talk that explains some of this,
>>> > and mentions some common pitfalls to avoid:
>>> >http://www.youtube.com/watch?v=UJPdhx5zTaw]
>>>
>>> > Ranting about flags or their output being cryptic may help you let off
>>> > some
>>> > steam, but beyond that doesn't get you anywhere. V8's command-line flags
>>> > let
>>> > you peek at V8's inner workings, and making sense of their output requires
>>> > some understanding of these internals. Nobody ever claimed anything else.
>>>
>>> > On Tue, Jul 17, 2012 at 8:34 PM, Kevin Gadd <kevin.g...@gmail.com> wrote:
>>>
>>> >> I've spent the last couple hours trying to actually get anything useful
>>> >> out of --trace-deopt. Unfortunately, I've had no success. I'm primarily
>>> >> going off the information from
>>> >>http://floitsch.blogspot.com/2012/03/optimizing-for-v8-inlining.html, as
>>> >> it's the only detailed info I've found on the internet about
>>> >> --trace-deopt.
>>>
>>> >> From what I can tell, the only way to use this feature seems to be in a
>>> >> debug build of d8, and to map the offsets (I think they're offsets?
>>> >> Unable
>>> >> to find information on this) in the deopt spew back to the generated
>>> >> assembly from the JIT, using the --print-code option. I.E.:
>>>
>>> >> **** DEOPT: MouseCursor_get_ClientBoundsWidth at bailout #7, address 0x0,
>>> >> frame size 12
>>> >> ;;; @36: deoptimize.
>>>
>>> >> In this spew I *think* @36 refers to instruction #36 in the generated IR
>>> >> from the JIT? It's unclear whether this is the high level IR or the low
>>> >> level IR (hydrogen.cfg, when you can actually get c1visualizer to load
>>> >> it,
>>> >> claims there are two kinds of IR - more on that later).
>>>
>>> >> So, right off the bat, this seems less than helpful - --print-code
>>> >> generates an absolutely titanic dump of all sorts of data and none of it
>>> >> is
>>> >> correlated - nothing in the output ASM maps it back to the source JS, and
>>> >> the IR (the IR that shows up in hydrogen.cfg) doesn't even seem to be
>>> >> there.
>>> >> It's unclear what the @36 in this case would actually point to, or how
>>> >> once
>>> >> I had located 36 I would map it back to a defect in my original source
>>> >> JavaScript or even to a particular operation in the IR. Mapping my
>>> >> JavaScript to V8's IR seems like something I can manage if necessary -
>>> >> most
>>> >> of the opcodes are KIND OF self explanatory if you spend forever
>>> >> understanding V8. But mapping the raw JIT assembly back to JS is just
>>> >> plain
>>> >> nuts - there's way too much going on there to even understand what a
>>> >> given
>>> >> deoptimization means if this is the only information I have.
>>>
>>> >> Really, all I need here is a rough mapping that tells me what part of a
>>> >> function is triggering a deoptimization. If V8 can't give me a reason
>>> >> (this
>>> >> seems to almost universally be the case), then fine, I'll just figure it
>>> >> out
>>> >> with brute force - but without knowing roughly what part of the function
>>> >> is
>>> >> responsible it's impossible to do any real debugging or optimization here
>>> >> (trying to binary search the function manually won't work, because
>>> >> changing
>>> >> the size and structure of the function will change whether it deoptimizes
>>> >> and where it deoptimizes).
>>>
>>> >>http://floitsch.blogspot.com/2012/03/optimizing-for-v8-hydrogen.html
>>> >> suggests that it's possible to get at the IR using some debug flags, and
>>> >> when I tried them out they indeed generate an enormous file named
>>> >> hydrogen.cfg. Unfortunately, the tool the post suggests using -
>>> >> c1visualizer
>>> >> - is either broken or does not support the version of the .cfg format
>>> >> Chrome
>>> >> now spits out, because it fails to load almost every meaningfully large
>>> >> .cfg
>>> >> file I've ever managed to get. When it does successfully load one, most
>>> >> of
>>> >> the
>>>
>>> ...
>>>
>>> read more ยป
>>
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>
>
>
> --
> -kg
>
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
