The DFG is capable of four levels of get_by_id optimization: Fastest: CheckStructure to check if the object still has the right structure, and then WeakJSConstant for the result, if the structure specializes that field. Fast: CheckStructure to check if the object still has the right structure, and then a GetByOffset. Slow: GetById, which gets patched and is slightly speculated in favor of the access not causing arbitrary side-effects, in that it doesn't pre flush registers and thus requires getters to go through the slow path Slowest: GetByIdFlush, which flushes all registers first and allows for any arbitrarily crazy access to happen using the fastest possible dynamically generated stub When parsing code, the DFG sees two distinct kinds of get_by_id's: those that are preceded by method_check and those that aren't. Currently for those that have method_check, the DFG first tries to generate the Fastest code, but if that fails (say due to slow path profiling indicating that it's a bad idea) then it reverts to Slow or Slowest. The Fast mode is thus only available to get_by_id's that don't have a method_check. This is an unusual and unnecessary restriction that is largely caused by the intelligence necessary to emit the Fast form only being present in the 'case op_get_by_id' part of the parser. The code should be refactored so that the op_method_check case can gracefully fall through to op_get_by_id and be able to emit all of the optimizations that op_get_by_id would do.
Created attachment 145462 [details] the patch
Comment on attachment 145462 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=145462&action=review r=me > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:97 > + // Handle get_by_id. I don't think this comment adds anything.
(In reply to comment #2) > (From update of attachment 145462 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=145462&action=review > > r=me > > > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:97 > > + // Handle get_by_id. > > I don't think this comment adds anything. Nope, it sure doesn't. Removed! Thanks!
Landed in http://trac.webkit.org/changeset/119343