Global functions should be initialized as JSFunctions in byte code
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2
3         Global functions should be initialized as JSFunctions in byte code
4         https://bugs.webkit.org/show_bug.cgi?id=144178
5
6         Reviewed by Geoffrey Garen.
7
8         This patch makes the initialization of global functions more explicit by
9         moving initialization into bytecode. It also prepares JSC for having ES6
10         style lexical scoping because initializing global functions in bytecode
11         easily allows global functions to be initialized with the proper scope that
12         will have access to global lexical variables. Global lexical variables
13         should be visible to global functions but don't live on the global object.
14
15         * bytecode/UnlinkedCodeBlock.cpp:
16         (JSC::UnlinkedProgramCodeBlock::visitChildren):
17         * bytecode/UnlinkedCodeBlock.h:
18         * bytecompiler/BytecodeGenerator.cpp:
19         (JSC::BytecodeGenerator::generate):
20         (JSC::BytecodeGenerator::BytecodeGenerator):
21         * bytecompiler/BytecodeGenerator.h:
22         * runtime/Executable.cpp:
23         (JSC::ProgramExecutable::initializeGlobalProperties):
24         * runtime/JSGlobalObject.cpp:
25         (JSC::JSGlobalObject::addGlobalVar):
26         (JSC::JSGlobalObject::addFunction):
27         * runtime/JSGlobalObject.h:
28
29 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
30
31         Large array shouldn't be slow
32         https://bugs.webkit.org/show_bug.cgi?id=144617
33
34         Reviewed by Geoffrey Garen.
35         
36         Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
37         you're already using ArrayStorage mode, from the minimul array length required to use
38         ArrayStorage in a new Array(length) allocation.
39         
40         Lift the array allocation length threshold to something very high. If this works, we'll
41         probably remove that threshold entirely.
42         
43         This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
44         JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
45         for now.
46
47         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
48         * dfg/DFGSpeculativeJIT32_64.cpp:
49         (JSC::DFG::SpeculativeJIT::compile):
50         * dfg/DFGSpeculativeJIT64.cpp:
51         (JSC::DFG::SpeculativeJIT::compile):
52         * ftl/FTLLowerDFGToLLVM.cpp:
53         (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
54         * runtime/ArrayConventions.h:
55         * runtime/JSArray.h:
56         (JSC::JSArray::create):
57         * runtime/JSGlobalObject.h:
58         (JSC::constructEmptyArray):
59         * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
60
61 2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
62
63         Add backed intrinsics to private functions exposed with private symbols in global object
64         https://bugs.webkit.org/show_bug.cgi?id=144545
65
66         Reviewed by Darin Adler.
67
68         Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
69         This patch adds intrinsic to private functions exposed with private symbols in global object,
70         @floor and @abs.
71
72         * runtime/JSGlobalObject.cpp:
73         (JSC::JSGlobalObject::init):
74         * runtime/JSGlobalObjectFunctions.cpp:
75         (JSC::globalPrivateFuncAbs): Deleted.
76         (JSC::globalPrivateFuncFloor): Deleted.
77         * runtime/MathObject.cpp:
78         * runtime/MathObject.h:
79         * tests/stress/array-from-abs-and-floor.js: Added.
80         (target1):
81         (target2):
82         (target3):
83
84 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
85
86         [cmake] ARM related build system cleanup
87         https://bugs.webkit.org/show_bug.cgi?id=144566
88
89         Reviewed by Darin Adler.
90
91         * CMakeLists.txt:
92
93 2015-05-04  Andreas Kling  <akling@apple.com>
94
95         Optimize WeakBlock's "reap" and "visit" operations.
96         <https://webkit.org/b/144585>
97
98         Reviewed by Geoffrey Garen.
99
100         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
101         That function was really written with conservative roots marking in mind, and will do a bunch
102         of sanity and bounds checks.
103
104         For weaks, we know that the pointer will have been a valid cell pointer into a block
105         of appropriate cell size, so we can skip a lot of the checks.
106
107         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
108         MarkedBlock::blockFor() for every single cell when iterating.
109
110         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
111         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
112         be pointing to any live cells, and the only operation that will run on the block is sweep().
113
114         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
115         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
116         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
117
118         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
119         what looks like a 1% speedup locally.
120
121         * heap/MarkedBlock.cpp:
122         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
123
124         * heap/MarkedBlock.h:
125         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
126         block's state is known to be either Marked or Retired.
127
128         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
129         would report that all cells are live anyway.
130
131         * heap/WeakBlock.cpp:
132         (JSC::WeakBlock::create):
133         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
134
135         (JSC::WeakBlock::visit):
136         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
137
138         * heap/WeakBlock.h:
139         (JSC::WeakBlock::disconnectMarkedBlock): Added.
140         * heap/WeakSet.cpp:
141         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
142         ownership to Heap until it can die peacefully.
143
144         (JSC::WeakSet::addAllocator):
145         * heap/WeakSet.h:
146         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
147
148 2015-05-04  Basile Clement  <basile_clement@apple.com>
149
150         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
151         https://bugs.webkit.org/show_bug.cgi?id=144587
152
153         Rubber stamped by Filip Pizlo.
154
155         When sinking object allocations, we ensure in
156         determineMaterializationPoints that whenever an allocation is
157         materialized on a path to a block, it is materialized in all such
158         paths. Thus when running the SSA calculator to place Phis in
159         placeMaterializationPoints, we can't encounter a situation where some
160         Upsilons are referring to a materialization while others are referring
161         to the phantom object.
162
163         This replaces the code that was adding a materialization late in
164         placeMaterializationPoints to handle that case by an assertion that it
165         does not happen, which will make
166         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
167
168         * dfg/DFGObjectAllocationSinkingPhase.cpp:
169         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
170
171 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
172
173         Extending undefined in class syntax should throw a TypeError
174         https://bugs.webkit.org/show_bug.cgi?id=144284
175
176         Reviewed by Darin Adler.
177
178         The bug was caused by op_eq_null evaluating to true when compared to undefined.
179         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
180
181         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
182
183         * bytecompiler/NodesCodegen.cpp:
184         (JSC::ClassExprNode::emitBytecode):
185
186 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
187
188         new super should be a syntax error
189         https://bugs.webkit.org/show_bug.cgi?id=144282
190
191         Reviewed by Joseph Pecoraro.
192
193         Disallow "new super" as ES6 spec doesn't allow this.
194
195         * parser/Parser.cpp:
196         (JSC::Parser<LexerType>::parseMemberExpression):
197
198 2015-05-04  Saam Barati  <saambarati1@gmail.com>
199
200         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
201         https://bugs.webkit.org/show_bug.cgi?id=144265
202
203         Reviewed by Geoffrey Garen.
204
205         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
206         for a static function if the parent has that property slot. JSCallbackObject::put 
207         did not maintain this symmetry of also calling ::put on the parent if the parent 
208         has the property. We should ensure that this symmetry exists.
209
210         * API/JSCallbackObjectFunctions.h:
211         (JSC::JSCallbackObject<Parent>::put):
212         * API/tests/testapi.c:
213         * API/tests/testapi.js:
214         (globalStaticFunction2):
215         (this.globalStaticFunction2):
216         (iAmNotAStaticFunction):
217         (this.iAmNotAStaticFunction):
218
219 2015-05-04  Andreas Kling  <akling@apple.com>
220
221         Make ExecState::vm() branchless in release builds.
222         <https://webkit.org/b/144586>
223
224         Reviewed by Geoffrey Garen.
225
226         Avoid null checking the ExecState's callee() before getting the
227         VM from it. The code was already dereferencing it anyway, since we
228         know it's not gonna be null.
229
230         * runtime/JSCellInlines.h:
231         (JSC::ExecState::vm):
232
233 2015-05-04  Basile Clement  <basile_clement@apple.com>
234
235         Object allocation not sinking properly through CheckStructure
236         https://bugs.webkit.org/show_bug.cgi?id=144465
237
238         Reviewed by Filip Pizlo.
239
240         Currently, sinking an allocation through a CheckStructure will
241         completely ignore all structure checking, which is obviously wrong.
242
243         A CheckStructureImmediate node type was present for that purpose, but
244         the CheckStructures were not properly replaced.  This ensures that
245         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
246         sunk through, and that structure checking happens correctly.
247
248         * dfg/DFGNode.h:
249         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
250         (JSC::DFG::Node::hasStructureSet):
251         * dfg/DFGObjectAllocationSinkingPhase.cpp:
252         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
253         * ftl/FTLLowerDFGToLLVM.cpp:
254         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
255         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
256         (JSC::FTL::LowerDFGToLLVM::checkStructure):
257         * tests/stress/sink_checkstructure.js: Added.
258         (foo):
259
260 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
261
262         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
263         https://bugs.webkit.org/show_bug.cgi?id=144476
264
265         Reviewed by Sam Weinig.
266
267         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
268
269         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
270         to my knowledge, the topic of how to optimize it is not covered in any
271         literature about sorting.
272
273         On the slowest jQuery sorting test -- prevAll -- our new
274         Array.prototype.sort, compared to its predecessor, performed 12% fewer
275         comparisons and requireed 10X less overhead per comparison. Yet, it was
276         slower.
277
278         It was slower because it inadvertantly increased the average cost of the
279         comparison function by 2X. jQuery uses compareDocumentPosition to compare
280         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
281         required to traverse backwards from b to a. In prevAll, we encounter the
282         worst case for merge sort of compareDocumentPosition: A long list of DOM
283         nodes in mostly reverse order. In this case, merge sort will sequentially
284         compareDocumentPosition(a, b), where a is not reachable backwards from
285         b, and therefore compareDocumentPosition will traverse the whole sibling
286         list.
287
288         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
289
290         This is a pretty silly thing to do, but it is harmless, and jQuery is
291         popular, so let's do it.
292
293         We do not risk suffering the same problem in reverse when sorting a long
294         list of DOM nodes in forward order. (We still have a 37% speedup on the
295         nextAll benchmark.) The reason is that merge sort performs 2X fewer
296         comparisons when the list is already sorted, so we can worry less about
297         the cost of each comparison.
298
299         A fully principled soultion to this problem would probably do something
300         like Python's timsort, which special-cases ordered ranges to perform
301         only O(n) comparisons. But that would contradict our original
302         goal of just having something simple that works.
303
304         Another option is for elements to keep a compareDocumentPosition cache,
305         like a node list cache, which allows you to determine the absolute
306         position of a node using a hash lookup. I will leave this as an exercise
307         for kling.
308
309         * builtins/Array.prototype.js:
310         (sort.merge): Compare in an order that is favorable to a comparator
311         that calls compareDocumentPosition.
312
313 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
314
315         [cmake] Fix generate-js-builtins related incremental build issue
316         https://bugs.webkit.org/show_bug.cgi?id=144094
317
318         Reviewed by Michael Saboff.
319
320         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
321         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
322         * DerivedSources.make:
323         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
324         * generate-js-builtins: Accept input files and input directory too.
325
326 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
327
328         Make some static data const
329         https://bugs.webkit.org/show_bug.cgi?id=144552
330
331         Reviewed by Andreas Kling.
332         
333         Turn characterSetInfo into const data.
334
335         * yarr/YarrCanonicalizeUCS2.cpp:
336         * yarr/YarrCanonicalizeUCS2.h:
337
338 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
339
340         TypeOf should be fast
341         https://bugs.webkit.org/show_bug.cgi?id=144396
342
343         Reviewed by Geoffrey Garen.
344         
345         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
346         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
347         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
348         
349         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
350         rely heavily on C++ calls to fulfill their function.
351         
352         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
353         
354         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
355         This means that if the TypeOf is dominated by any type checks, we will automatically prune
356         out cases that are redundant.
357         
358         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
359         code generation is designed to be reusable.
360         
361         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
362         the exotic call trap hook. That hook is now in a deeper slow path than before.
363
364         * CMakeLists.txt:
365         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
366         * JavaScriptCore.xcodeproj/project.pbxproj:
367         * dfg/DFGClobberize.h:
368         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
369         * dfg/DFGFixupPhase.cpp:
370         (JSC::DFG::FixupPhase::fixupNode):
371         * dfg/DFGHeapLocation.cpp:
372         (WTF::printInternal):
373         * dfg/DFGHeapLocation.h:
374         * dfg/DFGOperations.cpp:
375         * dfg/DFGOperations.h:
376         * dfg/DFGSpeculativeJIT.cpp:
377         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
378         (JSC::DFG::SpeculativeJIT::compileIsFunction):
379         (JSC::DFG::SpeculativeJIT::compileTypeOf):
380         * dfg/DFGSpeculativeJIT.h:
381         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
382         (JSC::DFG::SpeculativeJIT::callOperation):
383         * dfg/DFGSpeculativeJIT32_64.cpp:
384         (JSC::DFG::SpeculativeJIT::compile):
385         * dfg/DFGSpeculativeJIT64.cpp:
386         (JSC::DFG::SpeculativeJIT::compile):
387         * ftl/FTLCapabilities.cpp:
388         (JSC::FTL::canCompile):
389         * ftl/FTLIntrinsicRepository.h:
390         * ftl/FTLLowerDFGToLLVM.cpp:
391         (JSC::FTL::LowerDFGToLLVM::compileNode):
392         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
393         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
394         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
395         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
396         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
397         * ftl/FTLSwitchCase.h:
398         (JSC::FTL::SwitchCase::SwitchCase):
399         * jit/AssemblyHelpers.h:
400         (JSC::AssemblyHelpers::branchIfNotEqual):
401         (JSC::AssemblyHelpers::branchIfEqual):
402         (JSC::AssemblyHelpers::branchIfNumber):
403         (JSC::AssemblyHelpers::branchIfNotNumber):
404         (JSC::AssemblyHelpers::branchIfBoolean):
405         (JSC::AssemblyHelpers::branchIfNotBoolean):
406         (JSC::AssemblyHelpers::boxBooleanPayload):
407         (JSC::AssemblyHelpers::boxBoolean):
408         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
409         * jit/JITOperations.h:
410         * runtime/SmallStrings.h:
411         (JSC::SmallStrings::typeString):
412         * runtime/TypeofType.cpp: Added.
413         (WTF::printInternal):
414         * runtime/TypeofType.h: Added.
415         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
416
417 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
418
419         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
420
421         * dfg/DFGLICMPhase.cpp:
422         (JSC::DFG::LICMPhase::attemptHoist):
423
424 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
425
426         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
427         https://bugs.webkit.org/show_bug.cgi?id=144525.
428
429         * dfg/DFGLICMPhase.cpp:
430         (JSC::DFG::LICMPhase::attemptHoist):
431         * dfg/DFGPhantomInsertionPhase.cpp:
432
433 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
434
435         Static property hashtable should only lookup with non-symbol key
436         https://bugs.webkit.org/show_bug.cgi?id=144438
437
438         Reviewed by Darin Adler.
439
440         Static property hashtable compares the Identifier's uid
441         with the normal C string without interning it.
442         So this comparison is performed in their contents.
443         As the result, in this comparison, symbol-ness is not considered.
444
445         So if accidentally the hash collision occur with the symbol and the string
446         and they have the same contents, the hash table entry is looked up incorrectly.
447
448         * runtime/Lookup.h:
449         (JSC::HashTable::entry):
450
451 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
452
453         Class syntax should allow string and numeric identifiers for method names
454         https://bugs.webkit.org/show_bug.cgi?id=144254
455
456         Reviewed by Darin Adler.
457
458         Added the support for string and numeric identifiers in class syntax.
459
460         * parser/Parser.cpp:
461         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
462         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
463         outside a class constructor as it should be.
464         (JSC::Parser<LexerType>::parseFunctionDeclaration):
465         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
466         element to allow numeric and string method names. For both of those method names, parse it here instead
467         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
468         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
469         this function is never used to parse a class method.
470         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
471         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
472         * parser/Parser.h:
473         * parser/SyntaxChecker.h:
474         (JSC::SyntaxChecker::createProperty):
475
476 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
477
478         FTL should use AI more
479         https://bugs.webkit.org/show_bug.cgi?id=144500
480
481         Reviewed by Oliver Hunt.
482         
483         This makes our type check folding even more comprehensive by ensuring that even if the FTL
484         decides to emit some checks, it will still do another query to the abstract interpreter to
485         see if the check is necessary. This helps with cases where we decided early on to speculate
486         one way, but later proved a more specific type of the value in question, and the constant
487         folder didn't catch it.
488         
489         This also makes it more natural to query the abstract interpreter. For example, if you just
490         want the proven type, you can now say provenType(node) or provenType(edge).
491
492         * dfg/DFGArrayMode.cpp:
493         (JSC::DFG::ArrayMode::alreadyChecked):
494         * dfg/DFGArrayMode.h:
495         * ftl/FTLLowerDFGToLLVM.cpp:
496         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
497         (JSC::FTL::LowerDFGToLLVM::compileToThis):
498         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
499         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
500         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
501         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
502         (JSC::FTL::LowerDFGToLLVM::compileGetById):
503         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
504         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
505         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
506         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
507         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
508         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
509         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
510         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
511         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
512         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
513         (JSC::FTL::LowerDFGToLLVM::compileIsString):
514         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
515         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
516         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
517         (JSC::FTL::LowerDFGToLLVM::baseIndex):
518         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
519         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
520         (JSC::FTL::LowerDFGToLLVM::boolify):
521         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
522         (JSC::FTL::LowerDFGToLLVM::lowInt32):
523         (JSC::FTL::LowerDFGToLLVM::lowInt52):
524         (JSC::FTL::LowerDFGToLLVM::lowCell):
525         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
526         (JSC::FTL::LowerDFGToLLVM::lowDouble):
527         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
528         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
529         (JSC::FTL::LowerDFGToLLVM::isNumber):
530         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
531         (JSC::FTL::LowerDFGToLLVM::isNotCell):
532         (JSC::FTL::LowerDFGToLLVM::isCell):
533         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
534         (JSC::FTL::LowerDFGToLLVM::isMisc):
535         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
536         (JSC::FTL::LowerDFGToLLVM::isBoolean):
537         (JSC::FTL::LowerDFGToLLVM::isNotOther):
538         (JSC::FTL::LowerDFGToLLVM::isOther):
539         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
540         (JSC::FTL::LowerDFGToLLVM::isObject):
541         (JSC::FTL::LowerDFGToLLVM::isNotObject):
542         (JSC::FTL::LowerDFGToLLVM::isNotString):
543         (JSC::FTL::LowerDFGToLLVM::isString):
544         (JSC::FTL::LowerDFGToLLVM::isFunction):
545         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
546         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
547         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
548         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
549         (JSC::FTL::LowerDFGToLLVM::abstractValue):
550         (JSC::FTL::LowerDFGToLLVM::provenType):
551         (JSC::FTL::LowerDFGToLLVM::provenValue):
552         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
553
554 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
555
556         USE(...) macro should expect unprefixed variables
557         https://bugs.webkit.org/show_bug.cgi?id=144454
558
559         Reviewed by Daniel Bates.
560
561         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
562
563 2015-05-01  Jordan Harband  <ljharb@gmail.com>
564
565         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
566         https://bugs.webkit.org/show_bug.cgi?id=144314
567
568         Reviewed by Darin Adler.
569
570         Fixing handling of Infinity position args, per
571         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
572         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
573         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
574
575         * runtime/StringPrototype.cpp:
576         (JSC::clampInt32):
577         (JSC::stringProtoFuncStartsWith):
578         (JSC::stringProtoFuncEndsWith):
579         (JSC::stringProtoFuncIncludes):
580
581 2015-05-01  Basile Clement  <basile_clement@apple.com>
582
583         Math.abs() returns negative
584         https://bugs.webkit.org/show_bug.cgi?id=137827
585
586         Reviewed by Michael Saboff.
587
588         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
589         identity function.
590
591         * dfg/DFGAbstractInterpreterInlines.h:
592         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
593         * tests/stress/math-abs-positive.js: Added, was previously failing.
594         (foo):
595
596 2015-05-01  Basile Clement  <basile_clement@apple.com>
597
598         Function allocation sinking shouldn't be performed on singleton functions
599         https://bugs.webkit.org/show_bug.cgi?id=144166
600
601         Reviewed by Geoffrey Garen.
602
603         Function allocations usually are free of any other side effects, but
604         this is not the case for allocations performed while the underlying
605         FunctionExecutable is still a singleton (as this allogation will fire
606         watchpoints invalidating code that depends on it being a singleton).
607         As the object allocation sinking phase assumes object allocation is
608         free of side-effects, sinking these allocations is not correct.
609
610         This also means that when materializing a function allocation on OSR
611         exit, that function's executable will never be a singleton, and we don't have
612         to worry about its watchpoint, allowing us to use
613         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
614         JSFunction::create.
615
616         * dfg/DFGObjectAllocationSinkingPhase.cpp:
617         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
618         * ftl/FTLOperations.cpp:
619         (JSC::FTL::operationMaterializeObjectInOSR):
620
621 2015-04-30  Jon Davis  <jond@apple.com>
622
623         Web Inspector: console should show an icon for console.info() messages
624         https://bugs.webkit.org/show_bug.cgi?id=18530
625
626         Reviewed by Timothy Hatcher.
627
628         * inspector/ConsoleMessage.cpp:
629         (Inspector::messageLevelValue):
630         * inspector/protocol/Console.json:
631         * runtime/ConsoleClient.cpp:
632         (JSC::appendMessagePrefix):
633         * runtime/ConsolePrototype.cpp:
634         (JSC::ConsolePrototype::finishCreation):
635         (JSC::consoleProtoFuncInfo):
636         * runtime/ConsoleTypes.h:
637
638 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
639
640         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
641         https://bugs.webkit.org/show_bug.cgi?id=144462
642
643         Reviewed by Geoffrey Garen and Mark Lam.
644         
645         At some point we started adding representation-agnostic helpers for doing common type tests.
646         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
647         they had overlapping powers, though SpeculativeJIT was a bit better.
648         
649         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
650         better because now all of these helpers can be used in all of the assembly-based JITs, not
651         just the DFG. It also settles on what I find to be a slightly better naming convention.
652         For example where we previously would have said branchIsString, now we say
653         branchIfString. Similarly, branchNotString becomes branchIfNotString.
654
655         * dfg/DFGSpeculativeJIT.cpp:
656         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
657         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
658         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
659         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
660         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
661         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
662         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
663         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
664         (JSC::DFG::SpeculativeJIT::speculateObject):
665         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
666         (JSC::DFG::SpeculativeJIT::speculateString):
667         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
668         (JSC::DFG::SpeculativeJIT::speculateNotCell):
669         (JSC::DFG::SpeculativeJIT::speculateOther):
670         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
671         (JSC::DFG::SpeculativeJIT::emitSwitchString):
672         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
673         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
674         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
675         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
676         * dfg/DFGSpeculativeJIT.h:
677         * dfg/DFGSpeculativeJIT32_64.cpp:
678         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
679         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
680         (JSC::DFG::SpeculativeJIT::emitCall):
681         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
682         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
683         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
684         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
685         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
686         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
687         (JSC::DFG::SpeculativeJIT::compile):
688         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
689         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
690         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
691         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
692         * dfg/DFGSpeculativeJIT64.cpp:
693         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
694         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
695         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
696         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
697         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
698         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
699         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
700         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
701         (JSC::DFG::SpeculativeJIT::compile):
702         (JSC::DFG::SpeculativeJIT::writeBarrier):
703         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
704         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
705         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
706         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
707         * jit/AssemblyHelpers.h:
708         (JSC::AssemblyHelpers::branchIfCell):
709         (JSC::AssemblyHelpers::branchIfOther):
710         (JSC::AssemblyHelpers::branchIfNotOther):
711         (JSC::AssemblyHelpers::branchIfObject):
712         (JSC::AssemblyHelpers::branchIfNotObject):
713         (JSC::AssemblyHelpers::branchIfType):
714         (JSC::AssemblyHelpers::branchIfNotType):
715         (JSC::AssemblyHelpers::branchIfString):
716         (JSC::AssemblyHelpers::branchIfNotString):
717         (JSC::AssemblyHelpers::branchIfSymbol):
718         (JSC::AssemblyHelpers::branchIfNotSymbol):
719         (JSC::AssemblyHelpers::branchIfFunction):
720         (JSC::AssemblyHelpers::branchIfNotFunction):
721         (JSC::AssemblyHelpers::branchIfEmpty):
722         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
723         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
724         * jit/JITPropertyAccess.cpp:
725         (JSC::JIT::emitScopedArgumentsGetByVal):
726
727 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
728
729         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
730         https://bugs.webkit.org/show_bug.cgi?id=144463
731
732         Reviewed by Benjamin Poulain.
733         
734         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
735         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
736         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
737         converting the boolean into an integer. But as part of doing that, it would try to
738         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
739         and it would try to figure out if the addition might overflow. Part of that logic
740         involved checking if the immediate is either a boolean or a sufficiently small integer.
741         But: it would check if it's a sufficiently small integer before checking if it was a
742         boolean, so it would try to call asNumber() on the boolean.
743         
744         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
745         case was previously never hit until I wrote these tests, and so we never knew that
746         calling asNumber() on a boolean was wrong.
747         
748         The fix is super simple: the expression should just check for boolean first.
749         
750         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
751         garbage, and that's OK, since we'd take the boolean case anyway.
752
753         * dfg/DFGGraph.h:
754         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
755
756 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
757
758         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
759
760         * jit/JITOperations.cpp:
761
762 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
763
764         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
765         particular that they cannot change their minds and may be called from compiler threads.
766
767         Rubber stamped by Geoffrey Garen.
768
769         * runtime/JSCell.h:
770
771 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
772
773         DFG Is<Blah> versions of TypeOf should fold based on proven input type
774         https://bugs.webkit.org/show_bug.cgi?id=144409
775
776         Reviewed by Geoffrey Garen.
777         
778         We were missing some obvious folding opportunities here. I don't know how this affects real
779         code, but in general, we like to ensure that our constant folding is comprehensive. So this
780         is more about placating my static analysis OCD than anything else.
781         
782         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
783
784         * dfg/DFGAbstractInterpreterInlines.h:
785         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
786
787 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
788
789         Use the default hash value for Symbolized StringImpl
790         https://bugs.webkit.org/show_bug.cgi?id=144347
791
792         Reviewed by Darin Adler.
793
794         Before this patch, symbolized StringImpl* has a special hash value
795         to avoid the hash collision with the other normal StringImpl*.
796         I guess that it is introduced when private symbols are introduced.
797         However, it prevents using symbolized StringImpl* in the other place
798         For example, using it as WTFString cause a problem because of its special hash value.
799
800         When only using private symbols, they are not exposed to the outside of JSC,
801         so we can handle it carefully. But now, it's extended to symbols.
802         So I think storing a special hash value in StringImpl* causes an error.
803
804         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
805         And to provide significantly different hash value when using it as symbol,
806         store the additional hash value in symbolized StringImpl*. It is used when
807         the hash value is required by IdentifierRepHash.
808
809         * runtime/Identifier.h:
810         (JSC::IdentifierRepHash::hash):
811         * runtime/Lookup.h:
812         (JSC::HashTable::entry):
813         * runtime/PropertyMapHashTable.h:
814         (JSC::PropertyTable::find):
815         (JSC::PropertyTable::get):
816         * runtime/Structure.cpp:
817         (JSC::PropertyTable::checkConsistency):
818
819 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
820
821         [JSC] Remove RageConvert array conversion
822         https://bugs.webkit.org/show_bug.cgi?id=144433
823
824         Reviewed by Filip Pizlo.
825
826         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
827         pretty hard:
828         -The indexing types shows that the array access varies between Int32 and DoubleArray.
829         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
830          An Arrayify node would convert the Int32 to that type.
831         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
832          node would use RageConvert instead of Convert.
833         -The Arrayify for that GetByVal with RageConvert would not convert the array to
834          Contiguous.
835         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
836          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
837          fail systematically and we never get to run the later code.
838
839         Getting rid of RageConvert fixes the problem and does not seems to have any
840         negative side effect on other benchmarks.
841
842         The improvments on Kraken are:
843             -stanford-crypto-aes: definitely 1.0915x faster.
844             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
845             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
846
847         * dfg/DFGAbstractInterpreterInlines.h:
848         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
849         * dfg/DFGArrayMode.cpp:
850         (JSC::DFG::ArrayMode::refine):
851         (JSC::DFG::arrayConversionToString):
852         * dfg/DFGArrayMode.h:
853         * dfg/DFGArrayifySlowPathGenerator.h:
854         * dfg/DFGFixupPhase.cpp:
855         (JSC::DFG::FixupPhase::fixupNode):
856         * dfg/DFGOperations.cpp:
857         * dfg/DFGOperations.h:
858         * dfg/DFGPredictionPropagationPhase.cpp:
859         (JSC::DFG::PredictionPropagationPhase::propagate):
860         * dfg/DFGTypeCheckHoistingPhase.cpp:
861         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
862         * ftl/FTLLowerDFGToLLVM.cpp:
863         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
864         * runtime/JSObject.cpp:
865         (JSC::JSObject::convertDoubleToContiguous):
866         (JSC::JSObject::ensureContiguousSlow):
867         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
868         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
869         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
870         * runtime/JSObject.h:
871         (JSC::JSObject::rageEnsureContiguous): Deleted.
872
873 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
874
875         Gracefully handle missing auto pause key on remote inspector setup
876         https://bugs.webkit.org/show_bug.cgi?id=144411
877
878         Reviewed by Timothy Hatcher.
879
880         * inspector/remote/RemoteInspector.mm:
881         (Inspector::RemoteInspector::receivedSetupMessage):
882
883 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
884
885         NodeList has issues with Symbol and empty string
886         https://bugs.webkit.org/show_bug.cgi?id=144310
887
888         Reviewed by Darin Adler.
889
890         * runtime/PropertyName.h:
891         (JSC::PropertyName::isSymbol):
892         Helper to check if the PropertyName is a string or symbol property.
893
894 2015-04-29  Alex Christensen  <achristensen@webkit.org>
895
896         Fix non-cygwin incremental builds on Windows.
897         https://bugs.webkit.org/show_bug.cgi?id=143264
898
899         Reviewed by Brent Fulgham.
900
901         * generate-js-builtins:
902         Remove stale headers before calling os.rename to replace them.
903
904 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
905
906         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
907         https://bugs.webkit.org/show_bug.cgi?id=144397
908
909         Reviewed by Andreas Kling.
910         
911         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
912         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
913         making a getCallData() call if it isn't necessary.
914
915         * API/JSCallbackObject.h:
916         * runtime/InternalFunction.h:
917         * runtime/JSTypeInfo.h:
918         (JSC::TypeInfo::typeOfShouldCallGetCallData):
919         * runtime/Operations.cpp:
920         (JSC::jsTypeStringForValue):
921         * tests/stress/type-of-functions-and-objects.js: Added.
922         (foo):
923         (bar):
924         (baz):
925         (fuzz):
926         (expect):
927         (test):
928
929 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
930
931         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
932         https://bugs.webkit.org/show_bug.cgi?id=144013
933
934         Reviewed by Mark Lam.
935
936         This patch implements Array.prototype.sort in JavaScript, removing the
937         C++ implementations. It is simpler and less error-prone to express our
938         operations in JavaScript, which provides memory safety, exception safety,
939         and recursion safety.
940
941         The performance result is mixed, but net positive in my opinion. It's
942         difficult to enumerate all the results, since we used to have so many
943         different sorting modes, and there are lots of different data patterns
944         across which you might want to measure sorting. Suffice it to say:
945
946             (*) The benchmarks we track are faster or unchanged.
947
948             (*) Sorting random input using a comparator -- which we think is
949             common -- is 3X faster.
950
951             (*) Sorting random input in a non-array object -- which jQuery does
952             -- is 4X faster.
953
954             (*) Sorting random input in a compact array of integers using a
955             trivial pattern-matchable comparator is 2X *slower*.
956
957         * builtins/Array.prototype.js:
958         (sort.min):
959         (sort.stringComparator):
960         (sort.compactSparse): Special case compaction for sparse arrays because
961         we don't want to hang when sorting new Array(BIG).
962
963         (sort.compact):
964         (sort.merge):
965         (sort.mergeSort): Use merge sort because it's a reasonably efficient
966         stable sort. We have evidence that some sites depend on stable sort,
967         even though the ES6 spec does not mandate it. (See
968         <http://trac.webkit.org/changeset/33967>.)
969
970         This is a textbook implementation of merge sort with three optimizations:
971
972             (1) Use iteration instead of recursion;
973
974             (2) Use array subscripting instead of array copying in order to
975             create logical sub-lists without creating physical sub-lists;
976
977             (3) Swap src and dst at each iteration instead of copying src into
978             dst, and only copy src into the subject array at the end if src is
979             not the subject array.
980
981         (sort.inflate):
982         (sort.comparatorSort):
983         (sort): Sort in JavaScript for the win.
984
985         * builtins/BuiltinExecutables.cpp:
986         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
987         names so we can use helper functions.
988
989         * bytecode/CodeBlock.h:
990         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
991         * bytecode/UnlinkedCodeBlock.cpp:
992         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
993         * bytecode/UnlinkedCodeBlock.h:
994         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
995         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
996         * bytecompiler/BytecodeGenerator.cpp:
997         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
998         * bytecompiler/BytecodeGenerator.h:
999         * bytecompiler/NodesCodegen.cpp:
1000         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
1001         on pattern matching anymore. This was mainly an optimization to avoid 
1002         the overhead of calling from C++ to JS, which we now avoid by
1003         sorting in JS.
1004
1005         * heap/Heap.cpp:
1006         (JSC::Heap::markRoots):
1007         (JSC::Heap::pushTempSortVector): Deleted.
1008         (JSC::Heap::popTempSortVector): Deleted.
1009         (JSC::Heap::visitTempSortVectors): Deleted.
1010         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
1011         in JavaScript using a normal JavaScript array for our temporary storage.
1012
1013         * parser/Parser.cpp:
1014         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
1015         helper functions.
1016
1017         * runtime/ArrayPrototype.cpp:
1018         (JSC::isNumericCompareFunction): Deleted.
1019         (JSC::attemptFastSort): Deleted.
1020         (JSC::performSlowSort): Deleted.
1021         (JSC::arrayProtoFuncSort): Deleted.
1022
1023         * runtime/CommonIdentifiers.h: New strings used by sort.
1024
1025         * runtime/JSArray.cpp:
1026         (JSC::compareNumbersForQSortWithInt32): Deleted.
1027         (JSC::compareNumbersForQSortWithDouble): Deleted.
1028         (JSC::compareNumbersForQSort): Deleted.
1029         (JSC::compareByStringPairForQSort): Deleted.
1030         (JSC::JSArray::sortNumericVector): Deleted.
1031         (JSC::JSArray::sortNumeric): Deleted.
1032         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
1033         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
1034         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
1035         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
1036         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
1037         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
1038         (JSC::JSArray::sortCompactedVector): Deleted.
1039         (JSC::JSArray::sort): Deleted.
1040         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
1041         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
1042         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
1043         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
1044         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
1045         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
1046         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
1047         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
1048         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
1049         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
1050         (JSC::JSArray::sortVector): Deleted.
1051         (JSC::JSArray::compactForSorting): Deleted.
1052         * runtime/JSArray.h:
1053
1054         * runtime/JSGlobalObject.cpp:
1055         (JSC::JSGlobalObject::init):
1056         * runtime/ObjectConstructor.cpp:
1057         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
1058         by sort.
1059
1060 2015-04-29  Mark Lam  <mark.lam@apple.com>
1061
1062         Safari WebKit crash when loading Google Spreadsheet.
1063         https://bugs.webkit.org/show_bug.cgi?id=144020
1064
1065         Reviewed by Filip Pizlo.
1066
1067         The bug is that the object allocation sinking phase did not account for a case
1068         where a property of a sunken object is only initialized on one path and not
1069         another.  As a result, on the path where the property is not initialized, we'll
1070         encounter an Upsilon with a BottomValue (which is not allowed by definition).
1071
1072         The fix is to use a JSConstant(undefined) as the bottom value instead (of
1073         BottomValue).  If the property is uninitialized, it should still be accessible
1074         and have the value undefined.
1075
1076         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1077         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1078         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
1079         (foo):
1080         (foo2):
1081
1082 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
1083
1084         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1085         https://bugs.webkit.org/show_bug.cgi?id=144257
1086
1087         Reviewed by Darin Adler.
1088
1089         SHA1 is used to calculate CodeBlockHash.
1090         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
1091         However, the source code can contain null character.
1092         So when performing `strlen` on the source code's CString, it returns the incorrect length.
1093         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
1094
1095         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
1096         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
1097
1098         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
1099         is not correct. Because
1100
1101         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
1102         2. If CString can contain a null character, this assertion becomes incorrect.
1103
1104         So this patch just drops the assertion.
1105
1106         In the current implementation, we once convert the entire source code to the newly allocated
1107         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
1108         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
1109         We'll implement it in the separate patch[2].
1110
1111         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
1112         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
1113
1114         * tests/stress/eval-script-contains-null-character.js: Added.
1115         (shouldBe):
1116         (test):
1117         * tests/stress/template-literal-line-terminators.js:
1118         * tests/stress/template-literal-syntax.js:
1119         * tests/stress/template-literal.js:
1120
1121 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
1122
1123         Evict IsEnvironmentRecord from inline type flags
1124         https://bugs.webkit.org/show_bug.cgi?id=144398
1125
1126         Reviewed by Mark Lam and Michael Saboff.
1127         
1128         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
1129         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
1130         and evicts it into the out-of-line type flags. This change has no performance implications
1131         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
1132         where we access it at all is in String.prototype.repeat, and there we already load the
1133         structure anyway.
1134
1135         * runtime/JSTypeInfo.h:
1136         (JSC::TypeInfo::implementsHasInstance):
1137         (JSC::TypeInfo::structureIsImmortal):
1138         (JSC::TypeInfo::isEnvironmentRecord):
1139
1140 2015-04-29  Darin Adler  <darin@apple.com>
1141
1142         [ES6] Implement Unicode code point escapes
1143         https://bugs.webkit.org/show_bug.cgi?id=144377
1144
1145         Reviewed by Antti Koivisto.
1146
1147         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
1148         the header. Made it a non-member class so it doesn't need to be part
1149         of a template. Made it use UChar32 instead of int for the value to
1150         make it clearer what goes into this class.
1151         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
1152         old type() function.
1153         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
1154         parseFourDigitUnicodeHex and added support for code point escapes.
1155         (JSC::isLatin1): Added an overload for UChar32.
1156         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
1157         to call it with a UChar, so no need to overload for that type for now.
1158         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
1159         Also added FIXME about a subtle ES6 change that we might want to make later.
1160         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
1161         to call it with a UChar, so no need to overload for that type for now.
1162         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
1163         don't need to repeat the code twice. Added code to handle code point escapes.
1164         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
1165         code in line.
1166         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
1167         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
1168         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
1169         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
1170         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
1171         the code that handles the escapes, since the code point escape code now
1172         consumes characters while parsing rather than peeking ahead. Test case
1173         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
1174         giving a syntax error.
1175
1176         * parser/Lexer.h: Updated for above changes.
1177
1178         * runtime/StringConstructor.cpp:
1179         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
1180         out 0x10FFFF; clearer this way.
1181
1182 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
1183
1184         [CMake] [GTK] Organize and clean up unused CMake variables
1185         https://bugs.webkit.org/show_bug.cgi?id=144364
1186
1187         Reviewed by Gyuyoung Kim.
1188
1189         * PlatformGTK.cmake: Add variables specific to this project.
1190
1191 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1192
1193         TypeOf should return SpecStringIdent and the DFG should know this
1194         https://bugs.webkit.org/show_bug.cgi?id=144376
1195
1196         Reviewed by Andreas Kling.
1197         
1198         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
1199         
1200         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
1201         bad.
1202
1203         * dfg/DFGAbstractInterpreterInlines.h:
1204         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1205         * dfg/DFGAbstractValue.cpp:
1206         (JSC::DFG::AbstractValue::setType):
1207         * dfg/DFGAbstractValue.h:
1208         (JSC::DFG::AbstractValue::setType):
1209         * dfg/DFGInPlaceAbstractState.cpp:
1210         (JSC::DFG::InPlaceAbstractState::initialize):
1211         * dfg/DFGPredictionPropagationPhase.cpp:
1212         (JSC::DFG::PredictionPropagationPhase::propagate):
1213         * runtime/SmallStrings.cpp:
1214         (JSC::SmallStrings::initialize):
1215         * tests/stress/switch-typeof-indirect.js: Added.
1216         (bar):
1217         (foo):
1218         (test):
1219         * tests/stress/switch-typeof-slightly-indirect.js: Added.
1220         (foo):
1221         (test):
1222         * tests/stress/switch-typeof.js: Added.
1223         (foo):
1224         (test):
1225
1226 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1227
1228         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
1229         https://bugs.webkit.org/show_bug.cgi?id=144373
1230
1231         Reviewed by Darin Adler.
1232
1233         Revert r181868 as it caused a failure on live.com. We can try
1234         re-enabling this exception after we make idl attributes configurable,
1235         which may have prevented this particular failure.
1236
1237         * runtime/ObjectPrototype.cpp:
1238         (JSC::objectProtoFuncDefineGetter):
1239         (JSC::objectProtoFuncDefineSetter):
1240
1241 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1242
1243         Deadlock on applications using JSContext on non-main thread
1244         https://bugs.webkit.org/show_bug.cgi?id=144370
1245
1246         Reviewed by Timothy Hatcher.
1247
1248         * inspector/remote/RemoteInspector.mm:
1249         (Inspector::RemoteInspector::singleton):
1250         Prevent a possible deadlock by assuming we can synchronously
1251         run something on the main queue at this time.
1252
1253 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1254
1255         FTL should fully support Switch (it currently lacks the SwitchString variant)
1256         https://bugs.webkit.org/show_bug.cgi?id=144348
1257
1258         Reviewed by Benjamin Poulain.
1259         
1260         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
1261         in LayoutTests/js/regress.
1262
1263         * dfg/DFGCommon.cpp:
1264         (JSC::DFG::stringLessThan):
1265         * dfg/DFGCommon.h:
1266         * dfg/DFGOperations.cpp:
1267         * dfg/DFGOperations.h:
1268         * dfg/DFGSpeculativeJIT.cpp:
1269         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
1270         * dfg/DFGSpeculativeJIT.h:
1271         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
1272         * ftl/FTLCapabilities.cpp:
1273         (JSC::FTL::canCompile):
1274         * ftl/FTLIntrinsicRepository.h:
1275         * ftl/FTLLowerDFGToLLVM.cpp:
1276         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
1277         (JSC::FTL::LowerDFGToLLVM::switchString):
1278         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
1279         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
1280         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
1281         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
1282         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
1283         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
1284         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1285         * ftl/FTLOutput.cpp:
1286         (JSC::FTL::Output::check):
1287         * ftl/FTLOutput.h:
1288         * ftl/FTLWeight.h:
1289         (JSC::FTL::Weight::inverse):
1290         * jit/JITOperations.h:
1291
1292 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1293
1294         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1295         https://bugs.webkit.org/show_bug.cgi?id=144304
1296
1297         Reviewed by Geoffrey Garen.
1298
1299         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1300         ENABLE_LLINT_C_LOOP, disabled by default.
1301         * llint/LLIntSlowPaths.cpp:
1302         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1303
1304 2015-04-28  Commit Queue  <commit-queue@webkit.org>
1305
1306         Unreviewed, rolling out r183514.
1307         https://bugs.webkit.org/show_bug.cgi?id=144359
1308
1309         It broke cloop test bots (Requested by mcatanzaro on #webkit).
1310
1311         Reverted changeset:
1312
1313         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
1314         https://bugs.webkit.org/show_bug.cgi?id=144304
1315         http://trac.webkit.org/changeset/183514
1316
1317 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1318
1319         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1320         https://bugs.webkit.org/show_bug.cgi?id=144304
1321
1322         Reviewed by Geoffrey Garen.
1323
1324         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1325         ENABLE_LLINT_C_LOOP, disabled by default.
1326         * llint/LLIntSlowPaths.cpp:
1327         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1328
1329 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1330
1331         Fix common typo "targetting" => "targeting"
1332         https://bugs.webkit.org/show_bug.cgi?id=144349
1333
1334         Reviewed by Daniel Bates.
1335
1336         * bytecode/ExecutionCounter.h:
1337
1338 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
1339
1340         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
1341         https://bugs.webkit.org/show_bug.cgi?id=144328
1342
1343         Reviewed by Andreas Kling.
1344
1345         Update the status of ES6 features.
1346
1347         * features.json:
1348
1349 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1350
1351         DFG should not use or preserve Phantoms during transformations
1352         https://bugs.webkit.org/show_bug.cgi?id=143736
1353
1354         Reviewed by Geoffrey Garen.
1355         
1356         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
1357         no longer necessary to preserve Phantoms during transformations. They are still useful just
1358         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
1359         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
1360         block, we can be sure that so long as the IR pinpoints the place where the value becomes
1361         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
1362         other block would need the value (either for OSR or for DFG execution), then we don't need any
1363         liveness markers.
1364         
1365         So, this removes any places where we inserted Phantoms just for liveness during transformation
1366         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
1367         Check node only keeps its children so long as those children have checks.
1368         
1369         The fact that we no longer convertToPhantom() means that we have to be more careful when
1370         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
1371         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
1372         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
1373         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
1374         GetLocals.
1375         
1376         The only Phantom-like cruft left over after this patch is:
1377         
1378         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
1379           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
1380           the users of the original local's live range in bytecode. This is essential for supporting our
1381           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
1382         
1383         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
1384           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
1385           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
1386           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
1387           treat GetLocal/SetLocal conservatively, this should all be sound.
1388         
1389         This change should be perf-neutral although it does reduce the total work that the compiler
1390         does.
1391
1392         * CMakeLists.txt:
1393         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1394         * JavaScriptCore.xcodeproj/project.pbxproj:
1395         * dfg/DFGAdjacencyList.h:
1396         (JSC::DFG::AdjacencyList::justChecks):
1397         * dfg/DFGArgumentsEliminationPhase.cpp:
1398         * dfg/DFGBasicBlock.cpp:
1399         (JSC::DFG::BasicBlock::replaceTerminal):
1400         * dfg/DFGBasicBlock.h:
1401         (JSC::DFG::BasicBlock::findTerminal):
1402         * dfg/DFGCFGSimplificationPhase.cpp:
1403         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
1404         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1405         * dfg/DFGCPSRethreadingPhase.cpp:
1406         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
1407         (JSC::DFG::CPSRethreadingPhase::clearVariables):
1408         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
1409         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1410         * dfg/DFGCSEPhase.cpp:
1411         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
1412         (JSC::DFG::CleanUpPhase::CleanUpPhase):
1413         (JSC::DFG::CleanUpPhase::run):
1414         (JSC::DFG::performCleanUp):
1415         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
1416         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
1417         (JSC::DFG::performPhantomRemoval): Deleted.
1418         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
1419         * dfg/DFGConstantFoldingPhase.cpp:
1420         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1421         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
1422         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
1423         * dfg/DFGDCEPhase.cpp:
1424         (JSC::DFG::DCEPhase::run):
1425         (JSC::DFG::DCEPhase::fixupBlock):
1426         (JSC::DFG::DCEPhase::cleanVariables):
1427         * dfg/DFGFixupPhase.cpp:
1428         (JSC::DFG::FixupPhase::fixupBlock):
1429         (JSC::DFG::FixupPhase::fixupNode):
1430         (JSC::DFG::FixupPhase::convertStringAddUse):
1431         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1432         (JSC::DFG::FixupPhase::checkArray):
1433         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1434         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
1435         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
1436         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1437         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1438         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1439         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
1440         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
1441         * dfg/DFGGraph.cpp:
1442         (JSC::DFG::Graph::convertToConstant):
1443         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
1444         * dfg/DFGGraph.h:
1445         * dfg/DFGInsertionSet.h:
1446         (JSC::DFG::InsertionSet::insertCheck):
1447         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1448         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1449         * dfg/DFGLICMPhase.cpp:
1450         (JSC::DFG::LICMPhase::attemptHoist):
1451         * dfg/DFGNode.cpp:
1452         (JSC::DFG::Node::remove):
1453         * dfg/DFGNode.h:
1454         (JSC::DFG::Node::replaceWith):
1455         (JSC::DFG::Node::convertToPhantom): Deleted.
1456         (JSC::DFG::Node::convertToCheck): Deleted.
1457         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
1458         * dfg/DFGNodeFlags.h:
1459         * dfg/DFGNodeType.h:
1460         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1461         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1462         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1463         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
1464         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
1465         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
1466         * dfg/DFGPhantomRemovalPhase.h: Removed.
1467         * dfg/DFGPlan.cpp:
1468         (JSC::DFG::Plan::compileInThreadImpl):
1469         * dfg/DFGPutStackSinkingPhase.cpp:
1470         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
1471         * dfg/DFGResurrectionForValidationPhase.h: Removed.
1472         * dfg/DFGSSAConversionPhase.cpp:
1473         (JSC::DFG::SSAConversionPhase::run):
1474         * dfg/DFGSpeculativeJIT64.cpp:
1475         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1476         * dfg/DFGStoreBarrierElisionPhase.cpp:
1477         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
1478         * dfg/DFGStrengthReductionPhase.cpp:
1479         (JSC::DFG::StrengthReductionPhase::handleNode):
1480         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
1481         * dfg/DFGValidate.cpp:
1482         (JSC::DFG::Validate::validate):
1483         (JSC::DFG::Validate::validateCPS):
1484         (JSC::DFG::Validate::validateSSA):
1485         * dfg/DFGVarargsForwardingPhase.cpp:
1486         * ftl/FTLLink.cpp:
1487         (JSC::FTL::link):
1488         * ftl/FTLLowerDFGToLLVM.cpp:
1489         (JSC::FTL::LowerDFGToLLVM::compileNode):
1490         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
1491         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
1492
1493 2015-04-28  Andreas Kling  <akling@apple.com>
1494
1495         DFG+FTL should generate efficient code for branching on a string's boolean value.
1496         <https://webkit.org/b/144317>
1497
1498         Reviewed by Geoff Garen & Filip Pizlo
1499
1500         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
1501         instead of dropping out to C++ whenever we branch on a string.
1502
1503         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
1504         the DFG JIT gets some new codegen logic in this patch.
1505
1506         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
1507
1508         * dfg/DFGFixupPhase.cpp:
1509         (JSC::DFG::FixupPhase::fixupNode):
1510         * dfg/DFGSpeculativeJIT.cpp:
1511         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1512         * dfg/DFGSpeculativeJIT.h:
1513         * dfg/DFGSpeculativeJIT32_64.cpp:
1514         (JSC::DFG::SpeculativeJIT::emitBranch):
1515         * dfg/DFGSpeculativeJIT64.cpp:
1516         (JSC::DFG::SpeculativeJIT::emitBranch):
1517
1518 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1519
1520         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
1521         https://bugs.webkit.org/show_bug.cgi?id=144340
1522
1523         Reviewed by Michael Saboff and Mark Lam.
1524         
1525         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
1526         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
1527         Basically, we'd keep it alive until the end of the block. This maximized the chances of
1528         there being an interfering operation, which would prevent elimination.
1529         
1530         The fix is to only consider MovHints that have the arguments candidate as a child. We only
1531         care to track the liveness of those bytecode locals that would need an arguments object
1532         recovery on OSR exit.
1533         
1534         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
1535         introduced in http://trac.webkit.org/changeset/183406.
1536
1537         * dfg/DFGVarargsForwardingPhase.cpp:
1538
1539 2015-04-28  Csaba Osztrogonác  <ossy@webkit.org>
1540
1541         Remove WinCE cruft from cmake build system
1542         https://bugs.webkit.org/show_bug.cgi?id=144325
1543
1544         Reviewed by Gyuyoung Kim.
1545
1546         * CMakeLists.txt:
1547         * create_jit_stubs: Removed.
1548
1549 2015-04-27  Andreas Kling  <akling@apple.com>
1550
1551         RegExp matches arrays should use contiguous indexing.
1552         <https://webkit.org/b/144286>
1553
1554         Reviewed by Geoffrey Garen.
1555
1556         We had a custom Structure being used for RegExp matches arrays that would
1557         put the arrays into SlowPutArrayStorageShape mode. This was just left
1558         from when matches arrays were custom, lazily initialized objects.
1559
1560         This change removes that Structure and switches the matches arrays to
1561         using the default ContiguousShape Structure. This allows the FTL JIT
1562         to compile the inner loop of the Octane/regexp benchmark.
1563
1564         Also made a version of initializeIndex() [inline] that takes the indexing
1565         type in an argument, allowing createRegExpMatchesArray() to initialize
1566         the entire array without branching on the indexing type for each entry.
1567
1568         ~3% progression on Octane/regexp.
1569
1570         * runtime/JSGlobalObject.cpp:
1571         (JSC::JSGlobalObject::init):
1572         (JSC::JSGlobalObject::visitChildren):
1573         * runtime/JSGlobalObject.h:
1574         (JSC::JSGlobalObject::mapStructure):
1575         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1576         * runtime/JSObject.h:
1577         (JSC::JSObject::initializeIndex):
1578         * runtime/RegExpMatchesArray.cpp:
1579         (JSC::createRegExpMatchesArray):
1580
1581 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1582
1583         FTL failed to initialize arguments.callee on the slow path as well as the fast path
1584         https://bugs.webkit.org/show_bug.cgi?id=144293
1585
1586         Reviewed by Mark Lam.
1587         
1588         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
1589         to initialize the callee on the common path after the fast and slow path.
1590
1591         * ftl/FTLLowerDFGToLLVM.cpp:
1592         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
1593         * tests/stress/arguments-callee-uninitialized.js: Added.
1594         (foo):
1595
1596 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
1597
1598         [JSC] Add support for typed arrays to the Array profiling
1599         https://bugs.webkit.org/show_bug.cgi?id=143913
1600
1601         Reviewed by Filip Pizlo.
1602
1603         This patch adds ArrayModes for every typed arrays. Having that information
1604         let us generate better GetByVal and PutByVal when the type speculation
1605         are not good enough.
1606
1607         A typical case where this is useful is any basic block for which the type
1608         of the object is always more restrictive than the speculation (for example, 
1609         a basic block gated by a branch only taken for on type).
1610
1611         * bytecode/ArrayProfile.cpp:
1612         (JSC::dumpArrayModes):
1613         * bytecode/ArrayProfile.h:
1614         (JSC::arrayModeFromStructure):
1615         * dfg/DFGArrayMode.cpp:
1616         (JSC::DFG::ArrayMode::fromObserved):
1617         (JSC::DFG::ArrayMode::refine):
1618         Maintain the refine() semantic. We do not support OutOfBounds access
1619         for GetByVal on typed array.
1620
1621         * runtime/IndexingType.h:
1622         * tests/stress/typed-array-get-by-val-profiling.js: Added.
1623         (testArray.testCode):
1624         (testArray):
1625         * tests/stress/typed-array-put-by-val-profiling.js: Added.
1626         (testArray.testCode):
1627         (testArray):
1628
1629 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1630
1631         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
1632         causes many debug test failures.
1633
1634         * runtime/JSGlobalObject.cpp:
1635         (JSC::JSGlobalObject::init):
1636         (JSC::JSGlobalObject::visitChildren):
1637         * runtime/JSGlobalObject.h:
1638         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1639         * runtime/JSObject.h:
1640         (JSC::JSObject::initializeIndex):
1641         * runtime/RegExpMatchesArray.cpp:
1642         (JSC::createRegExpMatchesArray):
1643
1644 2015-04-27  Andreas Kling  <akling@apple.com>
1645
1646         RegExp matches arrays should use contiguous indexing.
1647         <https://webkit.org/b/144286>
1648
1649         Reviewed by Geoffrey Garen.
1650
1651         We had a custom Structure being used for RegExp matches arrays that would
1652         put the arrays into SlowPutArrayStorageShape mode. This was just left
1653         from when matches arrays were custom, lazily initialized objects.
1654
1655         This change removes that Structure and switches the matches arrays to
1656         using the default ContiguousShape Structure. This allows the FTL JIT
1657         to compile the inner loop of the Octane/regexp benchmark.
1658
1659         Also made a version of initializeIndex() [inline] that takes the indexing
1660         type in an argument, allowing createRegExpMatchesArray() to initialize
1661         the entire array without branching on the indexing type for each entry.
1662
1663         ~3% progression on Octane/regexp.
1664
1665         * runtime/JSGlobalObject.cpp:
1666         (JSC::JSGlobalObject::init):
1667         (JSC::JSGlobalObject::visitChildren):
1668         * runtime/JSGlobalObject.h:
1669         (JSC::JSGlobalObject::mapStructure):
1670         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1671         * runtime/JSObject.h:
1672         (JSC::JSObject::initializeIndex):
1673         * runtime/RegExpMatchesArray.cpp:
1674         (JSC::createRegExpMatchesArray):
1675
1676 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
1677
1678         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1679         https://bugs.webkit.org/show_bug.cgi?id=144257
1680
1681         Temporarily disable skip these tests.
1682
1683         * tests/stress/template-literal-line-terminators.js:
1684         * tests/stress/template-literal-syntax.js:
1685         * tests/stress/template-literal.js:
1686
1687 2015-04-27  Basile Clement  <basile_clement@apple.com>
1688
1689         Function allocations shouldn't sink through Put operations
1690         https://bugs.webkit.org/show_bug.cgi?id=144176
1691
1692         Reviewed by Filip Pizlo.
1693
1694         By design, we don't support function allocation sinking through any
1695         related operation ; however object allocation can sink through PutByOffset et
1696         al.
1697
1698         Currently, the checks to prevent function allocation to sink through
1699         these are misguided and do not prevent anything ; function allocation sinking
1700         through these operations is prevented as a side effect of requiring an
1701         AllocatePropertyStorage through which the function allocation is seen as
1702         escaping.
1703
1704         This changes it so that ObjectAllocationSinkingPhase::handleNode()
1705         checks properly that only object allocations sink through related write
1706         operations.
1707
1708         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1709         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1710         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1711
1712 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
1713
1714         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
1715         https://bugs.webkit.org/show_bug.cgi?id=143843
1716
1717         Reviewed by Geoffrey Garen.
1718         
1719         It will soon come to pass that Phantom isn't available at the time that
1720         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
1721         a value dies for OSR.
1722         
1723         This is simplified by two things:
1724         
1725         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
1726            before by polishing the API.
1727         
1728         2) This phase already operates on one node at a time and allows itself to do a full search
1729            of the enclosing basic block for that node. This is fine because CreateDirectArguments
1730            and friends is a rarely occurring node. The fact that it operates on one node at a time
1731            makes it even easier to reason about OSR liveness - we just track the list of locals in
1732            which it is live.
1733         
1734         This change has no effect right now but it is a necessary prerequisite to implementing
1735         https://bugs.webkit.org/show_bug.cgi?id=143736.
1736
1737         * dfg/DFGBasicBlock.h:
1738         (JSC::DFG::BasicBlock::tryAt):
1739         * dfg/DFGForAllKills.h:
1740         (JSC::DFG::forAllKilledOperands):
1741         * dfg/DFGPhantomInsertionPhase.cpp:
1742         * dfg/DFGVarargsForwardingPhase.cpp:
1743
1744 2015-04-27  Jordan Harband  <ljharb@gmail.com>
1745
1746         Map#entries and Map#keys error for non-Maps is swapped
1747         https://bugs.webkit.org/show_bug.cgi?id=144253
1748
1749         Reviewed by Simon Fraser.
1750
1751         Correcting error messages on Set/Map methods when called on
1752         incompatible objects.
1753
1754         * runtime/MapPrototype.cpp:
1755         (JSC::mapProtoFuncEntries):
1756         (JSC::mapProtoFuncKeys):
1757         * runtime/SetPrototype.cpp:
1758         (JSC::setProtoFuncEntries):
1759
1760 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1761
1762         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
1763         https://bugs.webkit.org/show_bug.cgi?id=144186
1764
1765         Reviewed by Geoffrey Garen.
1766         
1767         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
1768         Int32. We may later perform code simplifications based on the proof that this is Int32, and
1769         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
1770         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
1771         except that we still need the overflow check!
1772
1773         Previously we mishandled this:
1774
1775         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
1776           to keep it alive. That's dirty and it's just indicative of a deeper issue.
1777
1778         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
1779           powerless. This was sort of hiding the bug.
1780
1781         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
1782           something that you are relying on for subsequent simplifications.
1783         
1784         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
1785         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
1786         we no longer need the weird MustGenerate node.
1787
1788         * dfg/DFGAbstractInterpreterInlines.h:
1789         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1790         * dfg/DFGArgumentsEliminationPhase.cpp:
1791         * dfg/DFGClobberize.h:
1792         (JSC::DFG::clobberize):
1793         * dfg/DFGDCEPhase.cpp:
1794         (JSC::DFG::DCEPhase::run):
1795         * dfg/DFGDoesGC.cpp:
1796         (JSC::DFG::doesGC):
1797         * dfg/DFGFixupPhase.cpp:
1798         (JSC::DFG::FixupPhase::fixupNode):
1799         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1800         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1801         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1802         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
1803         * dfg/DFGMayExit.cpp:
1804         (JSC::DFG::mayExit):
1805         * dfg/DFGNode.h:
1806         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1807         * dfg/DFGNodeType.h:
1808         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1809         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1810         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1811         (JSC::DFG::PhantomCanonicalizationPhase::run):
1812         * dfg/DFGPhantomRemovalPhase.cpp:
1813         (JSC::DFG::PhantomRemovalPhase::run):
1814         * dfg/DFGPlan.cpp:
1815         (JSC::DFG::Plan::compileInThreadImpl):
1816         * dfg/DFGPredictionPropagationPhase.cpp:
1817         (JSC::DFG::PredictionPropagationPhase::propagate):
1818         * dfg/DFGSafeToExecute.h:
1819         (JSC::DFG::safeToExecute):
1820         * dfg/DFGSpeculativeJIT32_64.cpp:
1821         (JSC::DFG::SpeculativeJIT::compile):
1822         * dfg/DFGSpeculativeJIT64.cpp:
1823         (JSC::DFG::SpeculativeJIT::compile):
1824         * dfg/DFGTypeCheckHoistingPhase.cpp:
1825         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1826         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1827         * dfg/DFGVarargsForwardingPhase.cpp:
1828         * ftl/FTLCapabilities.cpp:
1829         (JSC::FTL::canCompile):
1830         * ftl/FTLLowerDFGToLLVM.cpp:
1831         (JSC::FTL::LowerDFGToLLVM::compileNode):
1832         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
1833         (foo):
1834         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
1835         (foo):
1836         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
1837         (foo):
1838         * tests/stress/fold-based-on-int32-proof.js: Added.
1839         (foo):
1840
1841 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1842
1843         Class body ending with a semicolon throws a SyntaxError
1844         https://bugs.webkit.org/show_bug.cgi?id=144244
1845
1846         Reviewed by Darin Adler.
1847
1848         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
1849         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
1850         it by continue'ing when it encounters a semicolon.
1851
1852         * parser/Parser.cpp:
1853         (JSC::Parser<LexerType>::parseClass):
1854
1855 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1856
1857         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
1858         https://bugs.webkit.org/show_bug.cgi?id=144243
1859
1860         Reviewed by Darin Adler.
1861
1862         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
1863
1864         * parser/Parser.cpp:
1865         (JSC::Parser<LexerType>::parseGetterSetter):
1866
1867 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1868
1869         Map#forEach does not pass "map" argument to callback.
1870         https://bugs.webkit.org/show_bug.cgi?id=144187
1871
1872         Reviewed by Darin Adler.
1873
1874         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
1875         step 7.a.i., the callback should be called with three arguments.
1876
1877         * runtime/MapPrototype.cpp:
1878         (JSC::mapProtoFuncForEach):
1879
1880 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1881
1882         [ES6] Implement ES6 template literals
1883         https://bugs.webkit.org/show_bug.cgi?id=142691
1884
1885         Reviewed by Darin Adler.
1886
1887         This patch implements TemplateLiteral.
1888         Since TaggedTemplate requires some global states and
1889         primitive operations like GetTemplateObject,
1890         we separate the patch. It will be implemented in a subsequent patch.
1891
1892         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
1893         By disabling it, we can disable Template Literal support.
1894
1895         To implement template literals, in this patch,
1896         we newly introduces bytecode op_to_string.
1897         In template literals, we alternately evaluate the expression and
1898         perform ToString onto the result of evaluation.
1899         For example,
1900
1901         `${f1()} ${f2()}`
1902
1903         In this template literal, execution order is the following,
1904         1. calling f1()
1905         2. ToString(the result of f1())
1906         3. calling f2()
1907         4. ToString(the result of f2())
1908
1909         op_strcat also performs ToString. However, performing ToString
1910         onto expressions are batched in op_strcat, it's not the same to the
1911         template literal spec. In the above example,
1912         ToString(f1()) should be called before calling f2().
1913
1914         * Configurations/FeatureDefines.xcconfig:
1915         * bytecode/BytecodeList.json:
1916         * bytecode/BytecodeUseDef.h:
1917         (JSC::computeUsesForBytecodeOffset):
1918         (JSC::computeDefsForBytecodeOffset):
1919         * bytecode/CodeBlock.cpp:
1920         (JSC::CodeBlock::dumpBytecode):
1921         * bytecompiler/BytecodeGenerator.h:
1922         (JSC::BytecodeGenerator::emitToString):
1923         (JSC::BytecodeGenerator::emitToNumber): Deleted.
1924         * bytecompiler/NodesCodegen.cpp:
1925         (JSC::TemplateStringNode::emitBytecode):
1926         (JSC::TemplateLiteralNode::emitBytecode):
1927         * dfg/DFGByteCodeParser.cpp:
1928         (JSC::DFG::ByteCodeParser::parseBlock):
1929         * dfg/DFGCapabilities.cpp:
1930         (JSC::DFG::capabilityLevel):
1931         * jit/JIT.cpp:
1932         (JSC::JIT::privateCompileMainPass):
1933         (JSC::JIT::privateCompileSlowCases):
1934         * jit/JIT.h:
1935         * jit/JITOpcodes.cpp:
1936         (JSC::JIT::emit_op_to_string):
1937         (JSC::JIT::emitSlow_op_to_string):
1938         * jit/JITOpcodes32_64.cpp:
1939         (JSC::JIT::emit_op_to_string):
1940         (JSC::JIT::emitSlow_op_to_string):
1941         * llint/LowLevelInterpreter32_64.asm:
1942         * llint/LowLevelInterpreter64.asm:
1943         * parser/ASTBuilder.h:
1944         (JSC::ASTBuilder::createTemplateString):
1945         (JSC::ASTBuilder::createTemplateStringList):
1946         (JSC::ASTBuilder::createTemplateExpressionList):
1947         (JSC::ASTBuilder::createTemplateLiteral):
1948         * parser/Lexer.cpp:
1949         (JSC::Lexer<T>::Lexer):
1950         (JSC::Lexer<T>::parseIdentifierSlowCase):
1951         (JSC::Lexer<T>::parseString):
1952         (JSC::LineNumberAdder::LineNumberAdder):
1953         (JSC::LineNumberAdder::clear):
1954         (JSC::LineNumberAdder::add):
1955         (JSC::Lexer<T>::parseTemplateLiteral):
1956         (JSC::Lexer<T>::lex):
1957         (JSC::Lexer<T>::scanRegExp):
1958         (JSC::Lexer<T>::scanTrailingTemplateString):
1959         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
1960         * parser/Lexer.h:
1961         * parser/NodeConstructors.h:
1962         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
1963         (JSC::TemplateStringNode::TemplateStringNode):
1964         (JSC::TemplateStringListNode::TemplateStringListNode):
1965         (JSC::TemplateLiteralNode::TemplateLiteralNode):
1966         * parser/Nodes.h:
1967         (JSC::TemplateExpressionListNode::value):
1968         (JSC::TemplateExpressionListNode::next):
1969         (JSC::TemplateStringNode::cooked):
1970         (JSC::TemplateStringNode::raw):
1971         (JSC::TemplateStringListNode::value):
1972         (JSC::TemplateStringListNode::next):
1973         * parser/Parser.cpp:
1974         (JSC::Parser<LexerType>::parseTemplateString):
1975         (JSC::Parser<LexerType>::parseTemplateLiteral):
1976         (JSC::Parser<LexerType>::parsePrimaryExpression):
1977         * parser/Parser.h:
1978         * parser/ParserTokens.h:
1979         * parser/SyntaxChecker.h:
1980         (JSC::SyntaxChecker::createTemplateString):
1981         (JSC::SyntaxChecker::createTemplateStringList):
1982         (JSC::SyntaxChecker::createTemplateExpressionList):
1983         (JSC::SyntaxChecker::createTemplateLiteral):
1984         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
1985         * runtime/CommonSlowPaths.cpp:
1986         (JSC::SLOW_PATH_DECL):
1987         * runtime/CommonSlowPaths.h:
1988         * tests/stress/template-literal-line-terminators.js: Added.
1989         (test):
1990         (testEval):
1991         (testEvalLineNumber):
1992         * tests/stress/template-literal-syntax.js: Added.
1993         (testSyntax):
1994         (testSyntaxError):
1995         * tests/stress/template-literal.js: Added.
1996         (test):
1997         (testEval):
1998         (testEmbedded):
1999
2000 2015-04-26  Jordan Harband  <ljharb@gmail.com>
2001
2002         Set#forEach does not pass "key" or "set" arguments to callback.
2003         https://bugs.webkit.org/show_bug.cgi?id=144188
2004
2005         Reviewed by Darin Adler.
2006
2007         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
2008         Set#forEach should pass 3 arguments to the callback.
2009
2010         * runtime/SetPrototype.cpp:
2011         (JSC::setProtoFuncForEach):
2012
2013 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
2014
2015         [JSC] Implement Math.clz32(), remove Number.clz()
2016         https://bugs.webkit.org/show_bug.cgi?id=144205
2017
2018         Reviewed by Michael Saboff.
2019
2020         This patch adds the ES6 function Math.clz32(), and remove the non-standard
2021         Number.clz(). Number.clz() probably came from an older draft.
2022
2023         The new function has a corresponding instrinsic: Clz32Intrinsic,
2024         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
2025
2026         * assembler/MacroAssemblerX86Common.h:
2027         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
2028         * assembler/X86Assembler.h:
2029         (JSC::X86Assembler::bsr_rr):
2030         The x86 assembler did not have countLeadingZeros32() because there is
2031         no native CLZ instruction on that architecture.
2032
2033         I have added the version with bsr + branches for the case of zero.
2034         An other popular version uses cmov to handle the case of zero. I kept
2035         it simple since the Assembler has no support for cmov.
2036
2037         It is unlikely to matter much. If the code is hot enough, LLVM picks
2038         something good based on the surrounding code.
2039
2040         * dfg/DFGAbstractInterpreterInlines.h:
2041         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2042         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
2043
2044         * dfg/DFGBackwardsPropagationPhase.cpp:
2045         (JSC::DFG::BackwardsPropagationPhase::propagate):
2046         Thanks to the definition of toUint32(), we can ignore plenty of details
2047         from doubles.
2048
2049         * dfg/DFGByteCodeParser.cpp:
2050         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2051         * dfg/DFGClobberize.h:
2052         (JSC::DFG::clobberize):
2053         * dfg/DFGDoesGC.cpp:
2054         (JSC::DFG::doesGC):
2055         * dfg/DFGFixupPhase.cpp:
2056         (JSC::DFG::FixupPhase::fixupNode):
2057         * dfg/DFGNodeType.h:
2058         * dfg/DFGPredictionPropagationPhase.cpp:
2059         (JSC::DFG::PredictionPropagationPhase::propagate):
2060         * dfg/DFGSafeToExecute.h:
2061         (JSC::DFG::safeToExecute):
2062         * dfg/DFGSpeculativeJIT.cpp:
2063         (JSC::DFG::SpeculativeJIT::compileArithClz32):
2064         * dfg/DFGSpeculativeJIT.h:
2065         * dfg/DFGSpeculativeJIT32_64.cpp:
2066         (JSC::DFG::SpeculativeJIT::compile):
2067         * dfg/DFGSpeculativeJIT64.cpp:
2068         (JSC::DFG::SpeculativeJIT::compile):
2069         * ftl/FTLCapabilities.cpp:
2070         (JSC::FTL::canCompile):
2071         * ftl/FTLIntrinsicRepository.h:
2072         * ftl/FTLLowerDFGToLLVM.cpp:
2073         (JSC::FTL::LowerDFGToLLVM::compileNode):
2074         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
2075         * ftl/FTLOutput.h:
2076         (JSC::FTL::Output::ctlz32):
2077         * jit/ThunkGenerators.cpp:
2078         (JSC::clz32ThunkGenerator):
2079         * jit/ThunkGenerators.h:
2080         * runtime/Intrinsic.h:
2081         * runtime/MathCommon.h:
2082         (JSC::clz32):
2083         Fun fact: InstCombine does not recognize this pattern to eliminate
2084         the branch which makes our FTL version better than the C version.
2085
2086         * runtime/MathObject.cpp:
2087         (JSC::MathObject::finishCreation):
2088         (JSC::mathProtoFuncClz32):
2089         * runtime/NumberPrototype.cpp:
2090         (JSC::clz): Deleted.
2091         (JSC::numberProtoFuncClz): Deleted.
2092         * runtime/VM.cpp:
2093         (JSC::thunkGeneratorForIntrinsic):
2094         * tests/stress/math-clz32-basics.js: Added.
2095         (mathClz32OnInteger):
2096         (testMathClz32OnIntegers):
2097         (verifyMathClz32OnIntegerWithOtherTypes):
2098         (mathClz32OnDouble):
2099         (testMathClz32OnDoubles):
2100         (verifyMathClz32OnDoublesWithOtherTypes):
2101         (mathClz32NoArguments):
2102         (mathClz32TooManyArguments):
2103         (testMathClz32OnConstants):
2104         (mathClz32StructTransition):
2105         (Math.clz32):
2106
2107 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
2108
2109         [ES6] Array.from need to accept iterables
2110         https://bugs.webkit.org/show_bug.cgi?id=141055
2111
2112         Reviewed by Darin Adler.
2113
2114         ES6 spec requires that Array.from accepts iterable objects.
2115         This patch introduces this functionality, Array.from accepting iterable objects.
2116
2117         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
2118         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
2119         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
2120         This will be fixed in the subsequent patch[1].
2121
2122         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
2123
2124         * builtins/ArrayConstructor.js:
2125         (from):
2126         * parser/Parser.cpp:
2127         (JSC::Parser<LexerType>::parseInner):
2128         * runtime/CommonIdentifiers.h:
2129         * runtime/JSGlobalObject.cpp:
2130         (JSC::JSGlobalObject::init):
2131         * tests/stress/array-from-with-iterable.js: Added.
2132         (shouldBe):
2133         (.set for):
2134         (.set var):
2135         (.get var):
2136         (argumentsGenerators):
2137         (.set shouldBe):
2138         (.set new):
2139         * tests/stress/array-from-with-iterator.js: Added.
2140         (shouldBe):
2141         (shouldThrow):
2142         (createIterator.iterator.return):
2143         (createIterator):
2144         (.):
2145
2146 2015-04-25  Jordan Harband  <ljharb@gmail.com>
2147
2148         Set#keys !== Set#values
2149         https://bugs.webkit.org/show_bug.cgi?id=144190
2150
2151         Reviewed by Darin Adler.
2152
2153         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
2154         Set#keys should === Set#values
2155
2156         * runtime/SetPrototype.cpp:
2157         (JSC::SetPrototype::finishCreation):
2158         (JSC::setProtoFuncValues):
2159         (JSC::setProtoFuncEntries):
2160         (JSC::setProtoFuncKeys): Deleted.
2161
2162 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
2163
2164         Allow for pausing a JSContext when opening a Web Inspector
2165         <rdar://problem/20564788>
2166
2167         Reviewed by Timothy Hatcher.
2168
2169         * inspector/remote/RemoteInspector.mm:
2170         (Inspector::RemoteInspector::receivedSetupMessage):
2171         * inspector/remote/RemoteInspectorConstants.h:
2172         * inspector/remote/RemoteInspectorDebuggable.h:
2173         * inspector/remote/RemoteInspectorDebuggableConnection.h:
2174         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
2175         (Inspector::RemoteInspectorDebuggableConnection::setup):
2176         On any incoming setup message, we may want to automatically
2177         pause the debuggable. If requested, pause the debuggable
2178         after we have setup the frontend connection.
2179
2180         * runtime/JSGlobalObjectDebuggable.h:
2181         * runtime/JSGlobalObjectDebuggable.cpp:
2182         (JSC::JSGlobalObjectDebuggable::pause):
2183         Pass through to the inspector controller.
2184
2185         * inspector/JSGlobalObjectInspectorController.h:
2186         * inspector/JSGlobalObjectInspectorController.cpp:
2187         (Inspector::JSGlobalObjectInspectorController::pause):
2188         Enable pause on next statement.
2189
2190 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
2191
2192         class methods should be non-enumerable
2193         https://bugs.webkit.org/show_bug.cgi?id=143181
2194
2195         Reviewed by Darin Adler.
2196
2197         Fixed the bug by using Object.defineProperty to define methods.
2198
2199         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
2200         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
2201
2202         * bytecode/CodeBlock.cpp: 
2203         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
2204         index of zero.
2205         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
2206         exactly one entry for Object.defineProperty.
2207         * bytecode/UnlinkedCodeBlock.h:
2208         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
2209         constant register for the link time constant we're adding.
2210         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
2211         * bytecompiler/BytecodeGenerator.cpp:
2212         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
2213         register for the specified link time constant and notify UnlinkedCodeBlock about it.
2214         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
2215         Object.defineProperty with it.
2216         * bytecompiler/BytecodeGenerator.h:
2217         * bytecompiler/NodesCodegen.cpp:
2218         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
2219         non-enumerable by using emitCallDefineProperty to define them.
2220         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
2221         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
2222         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
2223         * runtime/CommonIdentifiers.h:
2224         * runtime/JSGlobalObject.cpp:
2225         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
2226         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
2227         * runtime/JSGlobalObject.h:
2228         (JSC::JSGlobalObject::definePropertyFunction): Added.
2229         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
2230         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
2231         returns a JSCell; e.g. Object.defineProperty.
2232         * runtime/ObjectConstructor.cpp:
2233         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
2234         * runtime/ObjectConstructor.h:
2235
2236 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
2237
2238         [ES6] Implement String.fromCodePoint
2239         https://bugs.webkit.org/show_bug.cgi?id=144160
2240
2241         Reviewed by Darin Adler.
2242
2243         This patch implements String.fromCodePoint.
2244         It accepts multiple code points and generates a string that consists of given code points.
2245         The range [0x0000 - 0x10FFFF] is valid for code points.
2246         If the given value is out of range, throw a range error.
2247
2248         When a 0xFFFF <= valid code point is given,
2249         String.fromCodePoint generates a string that contains surrogate pairs.
2250
2251         * runtime/StringConstructor.cpp:
2252         (JSC::stringFromCodePoint):
2253         (JSC::constructWithStringConstructor):
2254         * tests/stress/string-from-code-point.js: Added.
2255         (shouldBe):
2256         (shouldThrow):
2257         (toCodePoints):
2258         (passThrough):
2259
2260 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
2261
2262         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
2263         https://bugs.webkit.org/show_bug.cgi?id=144182
2264
2265         Reviewed by Simon Fraser.
2266
2267         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
2268
2269 2015-04-25  Mark Lam  <mark.lam@apple.com>
2270
2271         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
2272         https://bugs.webkit.org/show_bug.cgi?id=144152
2273
2274         Reviewed by Filip Pizlo.
2275
2276         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
2277         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
2278         OSR exits.  This was overlooked in the original code.
2279
2280         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
2281         the Branch node, the other 3 may also trigger the same bug for other nodes.
2282         To prevent this bug from manifesting with other nodes (and future ones that
2283         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
2284         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
2285
2286         Also added a test to exercise a code path that will trigger this bug with
2287         the Branch node before the fix is applied.
2288
2289         * dfg/DFGMayExit.cpp:
2290         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
2291         (inlinedFunction):
2292         (foo):
2293
2294 2015-04-24  Commit Queue  <commit-queue@webkit.org>
2295
2296         Unreviewed, rolling out r183288.
2297         https://bugs.webkit.org/show_bug.cgi?id=144189
2298
2299         Made js/sort-with-side-effecting-comparisons.html time out in
2300         debug builds (Requested by ap on #webkit).
2301
2302         Reverted changeset:
2303
2304         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
2305         array."
2306         https://bugs.webkit.org/show_bug.cgi?id=144013
2307         http://trac.webkit.org/changeset/183288
2308
2309 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
2310
2311         CRASH in operationCreateDirectArgumentsDuringExit()
2312         https://bugs.webkit.org/show_bug.cgi?id=143962
2313
2314         Reviewed by Geoffrey Garen.
2315         
2316         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
2317         recoverable so long as they are live. Therefore, OSR exit should track liveness of
2318         constants instead of assuming that they are always live.
2319
2320         * dfg/DFGGenerationInfo.h:
2321         (JSC::DFG::GenerationInfo::noticeOSRBirth):
2322         (JSC::DFG::GenerationInfo::appendBirth):
2323         * dfg/DFGSpeculativeJIT.cpp:
2324         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2325         * dfg/DFGVariableEvent.cpp:
2326         (JSC::DFG::VariableEvent::dump):
2327         * dfg/DFGVariableEvent.h:
2328         (JSC::DFG::VariableEvent::birth):
2329         (JSC::DFG::VariableEvent::id):
2330         (JSC::DFG::VariableEvent::dataFormat):
2331         * dfg/DFGVariableEventStream.cpp:
2332         (JSC::DFG::VariableEventStream::reconstruct):
2333         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
2334         (foo):
2335         (bar):
2336         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
2337         (foo):
2338         (bar):
2339
2340 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
2341
2342         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
2343         https://bugs.webkit.org/show_bug.cgi?id=144169
2344
2345         Reviewed by Geoffrey Garen.
2346
2347         * runtime/JSObject.cpp:
2348         (JSC::JSObject::convertInt32ForValue):
2349         DoubleArray do not store NaN, they are used for holes.
2350         What happened was:
2351         1) We fail to insert the NaN in the Int32 array because it is a double.
2352         2) We were converting the array to DoubleArray.
2353         3) We were trying to insert the value again. We would fail again because
2354            DoubleArray does not store NaN.
2355         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
2356            to boxed values.
2357
2358         * tests/stress/int32array-transition-on-nan.js: Added.
2359         The behavior is not really observable. This only test nothing crashes in those
2360         cases.
2361
2362         (insertNaNWhileFilling):
2363         (testInsertNaNWhileFilling):
2364         (insertNaNAfterFilling):
2365         (testInsertNaNAfterFilling):
2366         (pushNaNWhileFilling):
2367         (testPushNaNWhileFilling):
2368
2369 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
2370
2371         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
2372         https://bugs.webkit.org/show_bug.cgi?id=144013
2373
2374         Reviewed by Mark Lam.
2375
2376         This patch implements Array.prototype.sort in JavaScript, removing the
2377         C++ implementations. It is simpler and less error-prone to express our
2378         operations in JavaScript, which provides memory safety, exception safety,
2379         and recursion safety.
2380
2381         The performance result is mixed, but net positive in my opinion. It's
2382         difficult to enumerate all the results, since we used to have so many
2383         different sorting modes, and there are lots of different data patterns
2384         across which you might want to measure sorting. Suffice it to say:
2385
2386             (*) The benchmarks we track are faster or unchanged.
2387
2388             (*) Sorting random input using a comparator -- which we think is
2389             common -- is 3X faster.
2390
2391             (*) Sorting random input in a non-array object -- which jQuery does
2392             -- is 4X faster.
2393
2394             (*) Sorting random input in a compact array of integers using a
2395             trivial pattern-matchable comparator is 2X *slower*.
2396
2397         * builtins/Array.prototype.js:
2398         (sort.min):
2399         (sort.stringComparator):
2400         (sort.compactSparse): Special case compaction for sparse arrays because
2401         we don't want to hang when sorting new Array(BIG).
2402
2403         (sort.compact):
2404         (sort.merge):
2405         (sort.mergeSort): Use merge sort because it's a reasonably efficient
2406         stable sort. We have evidence that some sites depend on stable sort,
2407         even though the ES6 spec does not mandate it. (See
2408         <http://trac.webkit.org/changeset/33967>.)
2409
2410         This is a textbook implementation of merge sort with three optimizations:
2411
2412             (1) Use iteration instead of recursion;
2413
2414             (2) Use array subscripting instead of array copying in order to
2415             create logical sub-lists without creating physical sub-lists;
2416
2417             (3) Swap src and dst at each iteration instead of copying src into
2418             dst, and only copy src into the subject array at the end if src is
2419             not the subject array.
2420
2421         (sort.inflate):
2422         (sort.comparatorSort):
2423         (sort): Sort in JavaScript for the win.
2424
2425         * builtins/BuiltinExecutables.cpp:
2426         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
2427         names so we can use helper functions.
2428
2429         * bytecode/CodeBlock.h:
2430         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
2431         * bytecode/UnlinkedCodeBlock.cpp:
2432         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2433         * bytecode/UnlinkedCodeBlock.h:
2434         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2435         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2436         * bytecompiler/BytecodeGenerator.cpp:
2437         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2438         * bytecompiler/BytecodeGenerator.h:
2439         * bytecompiler/NodesCodegen.cpp:
2440         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2441         on pattern matching anymore. This was mainly an optimization to avoid 
2442         the overhead of calling from C++ to JS, which we now avoid by
2443         sorting in JS.
2444
2445         * heap/Heap.cpp:
2446         (JSC::Heap::markRoots):
2447         (JSC::Heap::pushTempSortVector): Deleted.
2448         (JSC::Heap::popTempSortVector): Deleted.
2449         (JSC::Heap::visitTempSortVectors): Deleted.
2450         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
2451         in JavaScript using a normal JavaScript array for our temporary storage.
2452
2453         * parser/Parser.cpp:
2454         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
2455         helper functions.
2456
2457         * runtime/ArrayPrototype.cpp:
2458         (JSC::isNumericCompareFunction): Deleted.
2459         (JSC::attemptFastSort): Deleted.
2460         (JSC::performSlowSort): Deleted.
2461         (JSC::arrayProtoFuncSort): Deleted.
2462
2463         * runtime/CommonIdentifiers.h: New strings used by sort.
2464
2465         * runtime/JSArray.cpp:
2466         (JSC::compareNumbersForQSortWithInt32): Deleted.
2467         (JSC::compareNumbersForQSortWithDouble): Deleted.
2468         (JSC::compareNumbersForQSort): Deleted.
2469         (JSC::compareByStringPairForQSort): Deleted.
2470         (JSC::JSArray::sortNumericVector): Deleted.
2471         (JSC::JSArray::sortNumeric): Deleted.
2472         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
2473         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
2474         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
2475         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
2476         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
2477         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
2478         (JSC::JSArray::sortCompactedVector): Deleted.
2479         (JSC::JSArray::sort): Deleted.
2480         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
2481         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
2482         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
2483         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
2484         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
2485         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
2486         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
2487         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
2488         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
2489         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
2490         (JSC::JSArray::sortVector): Deleted.
2491         (JSC::JSArray::compactForSorting): Deleted.
2492         * runtime/JSArray.h:
2493
2494         * runtime/JSGlobalObject.cpp:
2495         (JSC::JSGlobalObject::init):
2496         * runtime/ObjectConstructor.cpp:
2497         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
2498         by sort.
2499
2500 2015-04-24  Matthew Mirman  <mmirman@apple.com>
2501
2502         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
2503         https://bugs.webkit.org/show_bug.cgi?id=141865
2504         rdar://problem/19927273
2505
2506         Reviewed by Filip Pizlo.
2507
2508         * runtime/JSGlobalObjectFunctions.cpp:
2509         (JSC::globalFuncProtoGetter):
2510         (JSC::globalFuncProtoSetter):
2511
2512 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
2513
2514         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
2515         https://bugs.webkit.org/show_bug.cgi?id=144118
2516
2517         Reviewed by Geoffrey Garen.
2518
2519         * dfg/DFGGraph.h:
2520         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
2521         Both block do the same thing.
2522
2523 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2524
2525         Web Inspector: Speculative fix for non-main thread auto-attach failures
2526         https://bugs.webkit.org/show_bug.cgi?id=144134
2527
2528         Reviewed by Timothy Hatcher.
2529
2530         * inspector/remote/RemoteInspector.mm:
2531         (Inspector::RemoteInspector::singleton):
2532
2533 2015-04-23  Basile Clement  <basile_clement@apple.com>
2534
2535         Allow function allocation sinking
2536         https://bugs.webkit.org/show_bug.cgi?id=144016
2537
2538         Reviewed by Filip Pizlo.
2539
2540         This adds the ability to sink function allocations in the
2541         DFGObjectAllocationSinkingPhase.
2542
2543         In order to enable this, we add a new PhantomNewFunction node that is
2544         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
2545         a sunk NewFunction and keep track of the allocations that have to be performed
2546         in case of OSR exit after the sunk allocation but before the real one.
2547         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
2548         are stored onto the PhantomNewFunction through PutHints in order for them
2549         to be recovered on OSR exit.
2550
2551         Contrary to sunk object allocations, sunk function allocations do not
2552         support any kind of operations (e.g. storing into a field) ; any such operation
2553         will mark the function allocation as escaping and trigger materialization. As
2554         such, function allocations can only be sunk to places where it would have been
2555         correct to syntactically move them, and we don't need a special
2556         MaterializeNewFunction node to recover possible operations on the function. A
2557         sunk NewFunction node will simply create new NewFunction nodes, then replace
2558         itself with a PhantomNewFunction node.
2559
2560         In itself, this change is not expected to have a significant impact on
2561         performances other than in degenerate cases (see e.g.
2562         JSRegress/sink-function), but it is a step towards being able to sink recursive
2563         closures onces we support CreateActivation sinking as well as allocation cycles
2564         sinking.
2565
2566         * dfg/DFGAbstractInterpreterInlines.h:
2567         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2568         * dfg/DFGClobberize.h:
2569         (JSC::DFG::clobberize):
2570         * dfg/DFGDoesGC.cpp:
2571         (JSC::DFG::doesGC):
2572         * dfg/DFGFixupPhase.cpp:
2573         (JSC::DFG::FixupPhase::fixupNode):
2574         * dfg/DFGNode.h:
2575         (JSC::DFG::Node::convertToPhantomNewFunction):
2576         (JSC::DFG::Node::isPhantomAllocation):
2577         * dfg/DFGNodeType.h:
2578         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2579         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2580         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2581         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2582         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2583         * dfg/DFGPredictionPropagationPhase.cpp:
2584         (JSC::DFG::PredictionPropagationPhase::propagate):
2585         * dfg/DFGPromotedHeapLocation.cpp:
2586         (WTF::printInternal):
2587         * dfg/DFGPromotedHeapLocation.h:
2588         * dfg/DFGSafeToExecute.h:
2589         (JSC::DFG::safeToExecute):
2590         * dfg/DFGSpeculativeJIT32_64.cpp:
2591         (JSC::DFG::SpeculativeJIT::compile):
2592         * dfg/DFGSpeculativeJIT64.cpp:
2593         (JSC::DFG::SpeculativeJIT::compile):
2594         * dfg/DFGValidate.cpp:
2595         (JSC::DFG::Validate::validateCPS):
2596         * ftl/FTLCapabilities.cpp:
2597         (JSC::FTL::canCompile):
2598         * ftl/FTLLowerDFGToLLVM.cpp:
2599         (JSC::FTL::LowerDFGToLLVM::compileNode):
2600         * ftl/FTLOperations.cpp:
2601         (JSC::FTL::operationMaterializeObjectInOSR):
2602         * tests/stress/function-sinking-no-double-allocate.js: Added.
2603         (call):
2604         (.f):
2605         (sink):
2606         * tests/stress/function-sinking-osrexit.js: Added.
2607         (.g):
2608         (sink):
2609         * tests/stress/function-sinking-put.js: Added.
2610         (.g):
2611         (sink):
2612
2613 2015-04-23  Basile Clement  <basile_clement@apple.com>
2614
2615         Make FunctionRareData allocation thread-safe
2616         https://bugs.webkit.org/show_bug.cgi?id=144001
2617
2618         Reviewed by Mark Lam.
2619
2620         The two things we want to prevent are:
2621
2622          1. A thread seeing a pointer to a not-yet-fully-created rare data from
2623             a JSFunction
2624          2. A thread seeing a pointer to a not-yet-fully-created Structure from
2625             an ObjectAllocationProfile
2626
2627         For 1., only the JS thread can be creating the rare data (in
2628         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
2629         worry about concurrent writes, and we don't need any fences when *reading* the
2630         rare data from the JS thread. Thus we only need a storeStoreFence between the
2631         rare data creation and assignment to m_rareData in
2632         JSFunction::createAndInitializeRareData() to ensure that when the store to
2633         m_rareData is issued, the rare data has been properly created.
2634
2635         For the DFG compilation threads, the only place they can access the
2636         rare data is through JSFunction::rareData(), and so we only need a
2637         loadLoadFence there to ensure that when we see a non-null pointer in
2638         m_rareData, the pointed object will be seen as a fully created
2639         FunctionRareData.
2640
2641
2642         For 2., the structure is created in
2643         ObjectAllocationProfile::initialize() (which appears to be called only by the
2644         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
2645         which always happen in the JS thread), and read through
2646         ObjectAllocationProfile::structure() and
2647         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
2648         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
2649         loadLoadFence in ObjectAllocationProfile::structure() (and change
2650         ObjectAllocationProfile::inlineCapacity() to go through
2651         ObjectAllocationProfile::structure()).
2652
2653         We don't need a fence in ObjectAllocationProfile::clear() because
2654         clearing the structure is already as atomic as it gets.
2655
2656         Finally, notice that we don't care about the ObjectAllocationProfile's
2657         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
2658         ObjectAllocationProfile::clear() that are always run in the JS thread.
2659         ObjectAllocationProfile::isNull() could cause some trouble, but it is
2660         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
2661         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
2662         thread anyway.
2663
2664         * bytecode/ObjectAllocationProfile.h:
2665         (JSC::ObjectAllocationProfile::initialize):
2666         (JSC::ObjectAllocationProfile::structure):
2667         (JSC::ObjectAllocationProfile::inlineCapacity):
2668         * runtime/JSFunction.cpp:
2669         (JSC::JSFunction::allocateAndInitializeRareData):
2670         * runtime/JSFunction.h:
2671         (JSC::JSFunction::rareData):
2672         (JSC::JSFunction::allocationStructure): Deleted.
2673         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2674
2675 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2676
2677         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
2678         https://bugs.webkit.org/show_bug.cgi?id=143735
2679
2680         Reviewed by Geoffrey Garen.
2681         
2682         We've always had bugs arising from the fact that we would MovHint something into a local,
2683         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
2684         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
2685         sophistication of the transformations we are doing today, this approach is just not sound
2686         anymore.
2687         
2688         This comprehensively fixes these bugs by having the DFG backend automatically insert
2689         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
2690         makes it much faster to query bytecode liveness.
2691         
2692         It's about as perf-neutral as it gets for a change that increases compiler work without
2693         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
2694         which should then speed us up. I can't really report concrete slow-down numbers because
2695         they are low enough to basically be in the noise. For example, a 20-iteration run of
2696         SunSpider yields "maybe 0.8% slower", whatever that means.
2697
2698         * CMakeLists.txt:
2699         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2700         * JavaScriptCore.xcodeproj/project.pbxproj:
2701         * bytecode/BytecodeLivenessAnalysis.cpp:
2702         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
2703         * bytecode/FullBytecodeLiveness.h:
2704         (JSC::FullBytecodeLiveness::getLiveness):
2705         * bytecode/VirtualRegister.h:
2706         (JSC::VirtualRegister::operator+):
2707         (JSC::VirtualRegister::operator-):
2708         * dfg/DFGForAllKills.h:
2709         (JSC::DFG::forAllLiveNodesAtTail):
2710         (JSC::DFG::forAllKilledOperands):
2711         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2712         * dfg/DFGGraph.cpp:
2713         (JSC::DFG::Graph::isLiveInBytecode):
2714         (JSC::DFG::Graph::localsLiveInBytecode):
2715         * dfg/DFGGraph.h:
2716         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2717         (JSC::DFG::Graph::forAllLiveInBytecode):
2718         * dfg/DFGMayExit.cpp:
2719         (JSC::DFG::mayExit):
2720         * dfg/DFGMovHintRemovalPhase.cpp:
2721         * dfg/DFGNodeType.h:
2722         * dfg/DFGPhantomInsertionPhase.cpp: Added.
2723         (JSC::DFG::performPhantomInsertion):
2724         * dfg/DFGPhantomInsertionPhase.h: Added.
2725         * dfg/DFGPlan.cpp:
2726         (JSC::DFG::Plan::compileInThreadImpl):
2727         * dfg/DFGScoreBoard.h:
2728         (JSC::DFG::ScoreBoard::sortFree):
2729         (JSC::DFG::ScoreBoard::assertClear):
2730         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2731         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2732         * ftl/FTLLowerDFGToLLVM.cpp:
2733         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2734         * tests/stress/phantom-inadequacy.js: Added.
2735         (bar):
2736         (baz):
2737         (foo):
2738
2739 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
2740
2741         Rename HardPhantom to MustGenerate.
2742
2743         Rubber stamped by Geoffrey Garen.
2744         
2745         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
2746         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
2747         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
2748         node should just be called MustGenerate.
2749
2750         * dfg/DFGAbstractInterpreterInlines.h:
2751         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2752         * dfg/DFGArgumentsEliminationPhase.cpp:
2753         * dfg/DFGClobberize.h:
2754         (JSC::DFG::clobberize):
2755         * dfg/DFGDCEPhase.cpp:
2756         (JSC::DFG::DCEPhase::run):
2757         * dfg/DFGDoesGC.cpp:
2758         (JSC::DFG::doesGC):
2759         * dfg/DFGFixupPhase.cpp:
2760         (JSC::DFG::FixupPhase::fixupNode):
2761         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
2762         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2763         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
2764         * dfg/DFGMayExit.cpp:
2765         (JSC::DFG::mayExit):
2766         * dfg/DFGNode.h:
2767         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2768         * dfg/DFGNodeType.h:
2769         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2770         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2771         * dfg/DFGPhantomCanonicalizationPhase.cpp:
2772         (JSC::DFG::PhantomCanonicalizationPhase::run):
2773         * dfg/DFGPhantomRemovalPhase.cpp:
2774         (JSC::DFG::PhantomRemovalPhase::run):
2775         * dfg/DFGPredictionPropagationPhase.cpp:
2776         (JSC::DFG::PredictionPropagationPhase::propagate):
2777         * dfg/DFGSafeToExecute.h:
2778         (JSC::DFG::safeToExecute):
2779         * dfg/DFGSpeculativeJIT32_64.cpp:
2780         (JSC::DFG::SpeculativeJIT::compile):
2781         * dfg/DFGSpeculativeJIT64.cpp:
2782         (JSC::DFG::SpeculativeJIT::compile):
2783         * dfg/DFGTypeCheckHoistingPhase.cpp:
2784         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2785         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2786         * dfg/DFGVarargsForwardingPhase.cpp:
2787         * ftl/FTLCapabilities.cpp:
2788         (JSC::FTL::canCompile):
2789         * ftl/FTLLowerDFGToLLVM.cpp:
2790         (JSC::FTL::LowerDFGToLLVM::compileNode):
2791
2792 2015-04-23  Jordan Harband  <ljharb@gmail.com>
2793
2794         Implement `Object.assign`
2795         https://bugs.webkit.org/show_bug.cgi?id=143980
2796
2797         Reviewed by Filip Pizlo.
2798
2799         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
2800
2801         * builtins/ObjectConstructor.js: Added.
2802         (assign):
2803         * runtime/CommonIdentifiers.h:
2804         * runtime/JSGlobalObject.cpp:
2805         (JSC::JSGlobalObject::init):
2806         * runtime/ObjectConstructor.cpp:
2807         * runtime/ObjectConstructor.h:
2808
2809 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2810
2811         Unreviewed, fix debug build.
2812
2813         * dfg/DFGGraph.h:
2814         (JSC::DFG::Graph::performSubstitutionForEdge):
2815
2816 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2817
2818         Nodes should have an optional epoch field
2819         https://bugs.webkit.org/show_bug.cgi?id=144084
2820
2821         Reviewed by Ryosuke Niwa and Mark Lam.
2822         
2823         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
2824         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
2825         used.
2826
2827         * dfg/DFGCPSRethreadingPhase.cpp:
2828         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2829         * dfg/DFGCSEPhase.cpp:
2830         * dfg/DFGEpoch.h:
2831         (JSC::DFG::Epoch::fromUnsigned):
2832         (JSC::DFG::Epoch::toUnsigned):
2833         * dfg/DFGGraph.cpp:
2834         (JSC::DFG::Graph::clearReplacements):
2835         (JSC::DFG::Graph::clearEpochs):
2836         * dfg/DFGGraph.h:
2837         (JSC::DFG::Graph::performSubstitutionForEdge):
2838         * dfg/DFGNode.h:
2839         (JSC::DFG::Node::Node):
2840         (JSC::DFG::Node::replaceWith):
2841         (JSC::DFG::Node::replacement):
2842         (JSC::DFG::Node::setReplacement):
2843         (JSC::DFG::Node::epoch):
2844         (JSC::DFG::Node::setEpoch):
2845         * dfg/DFGSSAConversionPhase.cpp:
2846         (JSC::DFG::SSAConversionPhase::run):
2847
2848 2015-04-22  Mark Lam  <mark.lam@apple.com>
2849
2850         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
2851         https://bugs.webkit.org/show_bug.cgi?id=143898
2852
2853         Reviewed by Filip Pizlo.
2854
2855         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
2856         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
2857         compilation threads because StringImpls are not thread safe. As a result, we get
2858         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
2859         build.
2860
2861         This patch fixes the issue by only collecting the CodeBlock (and associated info)
2862         into a DeferredSourceDump record while compiling, and stashing it away in a
2863         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
2864         later.
2865
2866         When compilation is done, the callback object will be notified that
2867         compilationDidComplete().  We will dump the SourceCode strings from there. 
2868         Since compilationDidComplete() is guaranteed to only be called on the thread
2869         doing JS execution, it is safe to access the SourceCode strings there and ref
2870         their underlying StringImpls as needed.        
2871
2872         * CMakeLists.txt:
2873         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2874         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2875         * JavaScriptCore.xcodeproj/project.pbxproj:
2876         * bytecode/DeferredCompilationCallback.cpp:
2877         (JSC::DeferredCompilationCallback::compilationDidComplete):
2878         (JSC::DeferredCompilationCallback::sourceDumpInfo):
2879         (JSC::DeferredCompilationCallback::dumpCompiledSources):
2880         * bytecode/DeferredCompilationCallback.h:
2881         * bytecode/DeferredSourceDump.cpp: Added.
2882         (JSC::DeferredSourceDump::DeferredSourceDump):
2883         (JSC::DeferredSourceDump::dump):
2884         * bytecode/DeferredSourceDump.h: Added.
2885         * dfg/DFGByteCodeParser.cpp:
2886         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2887         * dfg/DFGDriver.cpp:
2888         (JSC::DFG::compileImpl):
2889
2890 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
2891
2892         Implement String.codePointAt()
2893         https://bugs.webkit.org/show_bug.cgi?id=143934
2894
2895         Reviewed by Darin Adler.
2896
2897         This patch adds String.codePointAt() as defined by ES6.
2898         I opted for a C++ implementation for now.
2899
2900         * runtime/StringPrototype.cpp:
2901         (JSC::StringPrototype::finishCreation):
2902         (JSC::codePointAt):
2903         (JSC::stringProtoFuncCodePointAt):
2904
2905 2015-04-22  Mark Lam  <mark.lam@apple.com>
2906
2907         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
2908         https://bugs.webkit.org/show_bug.cgi?id=144067
2909
2910         Reviewed by Michael Saboff.
2911
2912         Currently, there are a few places where the JSObject that owns the
2913         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
2914         write barrier.  This is a bug and can result in the GC collecting the
2915         SparseArrayEntry even though it is being referenced by the
2916         SparseArrayValueMap.  This patch fixes the bug.
2917
2918         * runtime/JSObject.cpp:
2919         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
2920         (JSC::JSObject::putIndexedDescriptor):
2921         * tests/stress/sparse-array-entry-update-144067.js: Added.
2922         (useMemoryToTriggerGCs):
2923         (foo):
2924
2925 2015-04-22  Mark Lam  <mark.lam@apple.com>
2926
2927         Give the heap object iterators the ability to return early.
2928         https://bugs.webkit.org/show_bug.cgi?id=144011
2929
2930         Reviewed by Michael Saboff.
2931
2932         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
2933         candidate cell pointers, and, when in use, is called a lot more often than
2934         the normal way those iterators are used.  As a result, I see my instrumented
2935         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
2936         callback functor the ability to tell the iterators to return early when the
2937         functor no longer needs to continue iterating.  With this, my instrumented
2938         VM is useful again for debugging.
2939
2940         Since heap iteration is not something that we do in a typical fast path,
2941         I don't expect this to have any noticeable impact on performance.
2942
2943         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
2944         it checks JSCell addresses, not just JSObjects.
2945
2946         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2947         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2948         * JavaScriptCore.xcodeproj/project.pbxproj:
2949         * debugger/Debugger.cpp:
2950         * heap/GCLogging.cpp:
2951         (JSC::LoggingFunctor::operator()):
2952         * heap/Heap.cpp:
2953         (JSC::Zombify::visit):
2954         (JSC::Zombify::operator()):
2955         * heap/HeapStatistics.cpp:
2956         (JSC::StorageStatistics::visit):
2957         (JSC::StorageStatistics::operator()):
2958         * heap/HeapVerifier.cpp:
2959         (JSC::GatherLiveObjFunctor::visit):
2960         (JSC::GatherLiveObjFunctor::operator()):
2961         * heap/MarkedBlock.cpp:
2962         (JSC::SetNewlyAllocatedFunctor::operator()):
2963         * heap/MarkedBlock.h:
2964         (JSC::MarkedBlock::forEachCell):
2965         (JSC::MarkedBlock::forEachLiveCell):
2966         (JSC::MarkedBlock::forEachDeadCell):
2967         * heap/MarkedSpace.h:
2968         (JSC::MarkedSpace::forEachLiveCell):
2969         (JSC::MarkedSpace::forEachDeadCell):
2970         * inspector/agents/InspectorRuntimeAgent.cpp:
2971         (Inspector::TypeRecompiler::visit):
2972         (Inspector::TypeRecompiler::operator()):
2973         * runtime/IterationStatus.h: Added.
2974         * runtime/JSGlobalObject.cpp:
2975         * runtime/VM.cpp:
2976         (JSC::StackPreservingRecompiler::visit):
2977         (JSC::StackPreservingRecompiler::operator()):
2978         * tools/JSDollarVMPrototype.cpp:
2979         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2980         (JSC::CellAddressCheckFunctor::operator()):
2981         (JSC::JSDollarVMPrototype::isValidCell):
2982         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
2983         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
2984
2985 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
2986
2987         [[Set]] should be properly executed in JS builtins
2988         https://bugs.webkit.org/show_bug.cgi?id=143996
2989
2990         Reviewed by Geoffrey Garen.
2991
2992         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
2993         However,
2994
2995         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
2996         2. It's different from the default JS behavior.
2997
2998         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
2999         And dropping the current hack for builtins.
3000
3001         * builtins/Array.prototype.js:
3002         (filter):
3003         (map):
3004         (find):
3005         * bytecompiler/BytecodeGenerator.cpp:
3006         (JSC::BytecodeGenerator::emitPutByVal):
3007         * tests/stress/array-fill-put-by-val.js: Added.
3008         (shouldThrow):
3009         (.set get array):
3010         * tests/stress/array-filter-put-by-val-direct.js: Added.
3011         (shouldBe):
3012         (.set get var):
3013         * tests/stress/array-find-does-not-lookup-twice.js: Added.
3014         (shouldBe):
3015         (shouldThrow):
3016         (.get shouldBe):
3017         * tests/stress/array-from-put-by-val-direct.js: Added.
3018         (shouldBe):
3019         (.set get var):
3020         * tests/stress/array-from-set-length.js: Added.
3021         (shouldBe):
3022         (ArrayLike):
3023         (ArrayLike.prototype.set length):
3024         (ArrayLike.prototype.get length):
3025         * tests/stress/array-map-put-by-val-direct.js: Added.
3026         (shouldBe):
3027         (.set get var):
3028
3029 2015-04-22  Basile Clement  <basile_clement@apple.com>
3030  
3031         Don't de-allocate FunctionRareData
3032         https://bugs.webkit.org/show_bug.cgi?id=144000
3033
3034         Reviewed by Michael Saboff.
3035
3036         A function rare data (containing most notably its allocation profile) is currently
3037         freed and re-allocated each time the function's prototype is cleared.
3038         This is not optimal as it means we are invalidating the watchpoint and recompiling the
3039         scope each time the prototype is cleared.
3040
3041         This makes it so that a single rare data is reused, clearing the underlying
3042         ObjectAllocationProfile instead of throwing away the whole rare data on
3043         .prototype updates.
3044
3045         * runtime/FunctionRareData.cpp:
3046         (JSC::FunctionRareData::create):
3047         (JSC::FunctionRareData::finishCreation):
3048         * runtime/FunctionRareData.h:
3049         * runtime/JSFunction.cpp:
3050         (JSC::JSFunction::allocateAndInitializeRareData):
3051         (JSC::JSFunction::initializeRareData):
3052
3053 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3054
3055         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
3056
3057         * dfg/DFGSpeculativeJIT32_64.cpp:
3058         (JSC::DFG::SpeculativeJIT::compile):
3059
3060 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3061
3062         DFG should allow Phantoms after terminals
3063         https://bugs.webkit.org/show_bug.cgi?id=126778
3064
3065         Reviewed by Mark Lam.
3066         
3067         It's important for us to be able to place liveness-marking nodes after nodes that do
3068         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
3069         terminals. That made things awkward, especially for Switch and Branch, which may do
3070         things that necessitate liveness markers (for example they might want to use a converted
3071         version of a value rather than the value that was MovHinted). We previously made this
3072         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
3073         thing.
3074         
3075         This changes our IR to allow for the terminal to not be the last node in a block. Asking
3076         for the terminal involves a search. DFG::validate() checks that the nodes after the
3077         terminal are liveness markers that have no effects or checks.
3078         
3079         This is perf-neutral but will allow more optimizations in the future. It will also make
3080         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
3081
3082         * dfg/DFGBasicBlock.cpp:
3083         (JSC::DFG::BasicBlock::replaceTerminal):
3084         * dfg/DFGBasicBlock.h:
3085         (JSC::DFG::BasicBlock::findTerminal):
3086         (JSC::DFG::BasicBlock::terminal):
3087         (JSC::DFG::BasicBlock::insertBeforeTerminal):
3088         (JSC::DFG::BasicBlock::numSuccessors):
3089         (JSC::DFG::BasicBlock::successor):
3090         (JSC::DFG::BasicBlock::successorForCondition):
3091         (JSC::DFG::BasicBlock::successors):
3092         (JSC::DFG::BasicBlock::last): Deleted.
3093         (JSC::DFG::BasicBlock::takeLast): Deleted.
3094         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
3095         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
3096         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
3097         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
3098         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
3099         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
3100         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
3101         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
3102         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
3103         * dfg/DFGBasicBlockInlines.h:
3104         (JSC::DFG::BasicBlock::appendNonTerminal):
3105         (JSC::DFG::BasicBlock::replaceTerminal):
3106         * dfg/DFGByteCodeParser.cpp:
3107         (JSC::DFG::ByteCodeParser::addToGraph):
3108         (JSC::DFG::ByteCodeParser::inlineCall):
3109         (JSC::DFG::ByteCodeParser::handleInlining):
3110         (JSC::DFG::ByteCodeParser::parseBlock):
3111         (JSC::DFG::ByteCodeParser::linkBlock):
3112         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3113         * dfg/DFGCFGSimplificationPhase.cpp:
3114         (JSC::DFG::CFGSimplificationPhase::run):
3115         (JSC::DFG::CFGSimplificationPhase::convertToJump):
3116         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
3117         * dfg/DFGCPSRethreadingPhase.cpp:
3118         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3119         * dfg/DFGCommon.h:
3120         (JSC::DFG::NodeAndIndex::NodeAndIndex):
3121         (JSC::DFG::NodeAndIndex::operator!):
3122         * dfg/DFGFixupPhase.cpp:
3123         (JSC::DFG::FixupPhase::fixupBlock):
3124         (JSC::DFG::FixupPhase::fixupNode):
3125         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
3126         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
3127         * dfg/DFGForAllKills.h:
3128         (JSC::DFG::forAllLiveNodesAtTail):
3129         * dfg/DFGGraph.cpp:
3130         (JSC::DFG::Graph::terminalsAreValid):
3131         (JSC::DFG::Graph::dumpBlockHeader):
3132         * dfg/DFGGraph.h:
3133         * dfg/DFGInPlaceAbstractState.cpp:
3134         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
3135         * dfg/DFGLICMPhase.cpp:
3136         (JSC::DFG::LICMPhase::run):
3137         (JSC::DFG::LICMPhase::attemptHoist):
3138         * dfg/DFGMovHintRemovalPhase.cpp:
3139         * dfg/DFGNode.h:
3140         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
3141         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
3142         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
3143         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
3144         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
3145         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
3146         (JSC::DFG::Node::SuccessorsIterable::begin):
3147         (JSC::DFG::Node::SuccessorsIterable::end):
3148         (JSC::DFG::Node::successors):
3149         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3150         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
3151         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
3152         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
3153         * dfg/DFGPhantomRemovalPhase.cpp:
3154         (JSC::DFG::PhantomRemovalPhase::run):
3155         * dfg/DFGPutStackSinkingPhase.cpp:
3156         * dfg/DFGSSAConversionPhase.cpp:
3157         (JSC::DFG::SSAConversionPhase::run):
3158         * dfg/DFGSpeculativeJIT.h:
3159         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
3160         * dfg/DFGSpeculativeJIT32_64.cpp:
3161         (JSC::DFG::SpeculativeJIT::compile):
3162         * dfg/DFGSpeculativeJIT64.cpp:
3163         (JSC::DFG::SpeculativeJIT::compile):
3164         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
3165         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
3166         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3167         (JSC::DFG::TierUpCheckInjectionPhase::run):
3168         * dfg/DFGValidate.cpp:
3169         (JSC::DFG::Validate::validate):
3170         * ftl/FTLLowerDFGToLLVM.cpp:
3171         (JSC::FTL::LowerDFGToLLVM::compileNode):
3172         * tests/stress/closure-call-exit.js: Added.
3173         (foo):
3174
3175 2015-04-21  Basile Clement  <basile_clement@apple.com>
3176
3177         PhantomNewObject should be marked NodeMustGenerate
3178         https://bugs.webkit.org/show_bug.cgi?id=143974
3179
3180         Reviewed by Filip Pizlo.
3181
3182         * dfg/DFGNode.h:
3183         (JSC::DFG::Node::convertToPhantomNewObject):
3184         Was not properly marking NodeMustGenerate when converting.
3185
3186 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3187
3188         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
3189         https://bugs.webkit.org/show_bug.cgi?id=144007
3190
3191         Reviewed by Mark Lam.
3192         
3193         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
3194         if isForwardVarargs.
3195
3196         * dfg/DFGSpeculativeJIT32_64.cpp:
3197         (JSC::DFG::SpeculativeJIT::emitCall):
3198         * dfg/DFGSpeculativeJIT64.cpp:
3199         (JSC::DFG::SpeculativeJIT::emitCall):
3200         * tests/stress/varargs-then-slow-call.js: Added.
3201         (foo):
3202         (bar):
3203         (fuzz):
3204         (baz):
3205
3206 2015-04-21  Basile Clement  <basile_clement@apple.com>
3207
3208         Remove AllocationProfileWatchpoint node
3209         https://bugs.webkit.org/show_bug.cgi?id=143999
3210
3211         Reviewed by Filip Pizlo.
3212
3213         * dfg/DFGAbstractInterpreterInlines.h:
3214         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3215         * dfg/DFGByteCodeParser.cpp:
3216         (JSC::DFG::ByteCodeParser::parseBlock):
3217         * dfg/DFGClobberize.h:
3218         (JSC::DFG::clobberize):
3219         * dfg/DFGDoesGC.cpp:
3220         (JSC::DFG::doesGC):
3221         * dfg/DFGFixupPhase.cpp:
3222         (JSC::DFG::FixupPhase::fixupNode):
3223         * dfg/DFGHeapLocation.cpp:
3224         (WTF::printInternal):
3225         * dfg/DFGHeapLocation.h:
3226         * dfg/DFGNode.h:
3227         (JSC::DFG::Node::hasCellOperand):
3228         * dfg/DFGNodeType.h:
3229         * dfg/DFGPredictionPropagationPhase.cpp:
3230         (JSC::DFG::PredictionPropagationPhase::propagate):
3231         * dfg/DFGSafeToExecute.h:
3232         (JSC::DFG::safeToExecute):
3233         * dfg/DFGSpeculativeJIT32_64.cpp:
3234         (JSC::DFG::SpeculativeJIT::compile):
3235         * dfg/DFGSpeculativeJIT64.cpp:
3236         (JSC::DFG::SpeculativeJIT::compile):
3237         * dfg/DFGWatchpointCollectionPhase.cpp:
3238         (JSC::DFG::WatchpointCollectionPhase::handle):
3239         * ftl/FTLCapabilities.cpp:
3240         (JSC::FTL::canCompile):
3241         * ftl/FTLLowerDFGToLLVM.cpp:
3242         (JSC::FTL::LowerDFGToLLVM::compileNode):
3243         * runtime/JSFunction.h:
3244         (JSC::JSFunction::rareData):
3245         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
3246
3247 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
3248
3249         MovHint should be a strong use
3250         https://bugs.webkit.org/show_bug.cgi?id=143734
3251
3252         Reviewed by Geoffrey Garen.
3253         
3254         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
3255         so is a major step towards allowing more fancy DFG transformations and also probably fixing
3256         some bugs.
3257         
3258         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
3259         introducing a MovHint removal phase that runs in FTL.
3260         
3261         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
3262
3263         * CMakeLists.txt:
3264         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3265         * JavaScriptCore.xcodeproj/project.pbxproj:
3266         * bytecode/CodeOrigin.cpp:
3267         (JSC::InlineCallFrame::dumpInContext):
3268         * dfg/DFGDCEPhase.cpp:
3269         (JSC::DFG::DCEPhase::fixupBlock):
3270         * dfg/DFGDisassembler.cpp:
3271         (JSC::DFG::Disassembler::createDumpList):
3272         * dfg/DFGEpoch.cpp: Added.
3273         (JSC::DFG::Epoch::dump):
3274         * dfg/DFGEpoch.h: Added.
3275         (JSC::DFG::Epoch::Epoch):
3276         (JSC::DFG::Epoch::first):
3277         (JSC::DFG::Epoch::operator!):
3278         (JSC::DFG::Epoch::next):
3279         (JSC::DFG::Epoch::bump):
3280         (JSC::DFG::Epoch::operator==):
3281         (JSC::DFG::Epoch::operator!=):
3282         * dfg/DFGMayExit.cpp:
3283         (JSC::DFG::mayExit):
3284         * dfg/DFGMovHintRemovalPhase.cpp: Added.
3285         (JSC::DFG::performMovHintRemoval):
3286         * dfg/DFGMovHintRemovalPhase.h: Added.
3287         * dfg/DFGNodeType.h:
3288         * dfg/DFGPlan.cpp:
3289         (JSC::DFG::Plan::compileInThreadImpl):
3290         * dfg/DFGSpeculativeJIT.cpp:
3291         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3292         * dfg/DFGSpeculativeJIT64.cpp:
3293         (JSC::DFG::SpeculativeJIT::compile):
3294         * runtime/Options.h:
3295
3296 2015-04-21  Basile Clement  <basile_clement@apple.com>
3297
3298         REGRESSION (r182899): icloud.com crashes
3299         https://bugs.webkit.org/show_bug.cgi?id=143960
3300
3301         Reviewed by Filip Pizlo.
3302
3303         * runtime/JSFunction.h:
3304         (JSC::JSFunction::allocationStructure):
3305         * tests/stress/dfg-rare-data.js: Added.
3306         (F): Regression test
3307
3308 2015-04-21  Michael Saboff  <msaboff@apple.com>
3309
3310         Crash in JSC::Interpreter::execute
3311         https://bugs.webkit.org/show_bug.cgi?id=142625
3312
3313         Reviewed by Filip Pizlo.
3314
3315         We need to keep the FunctionExecutables in the code block for the eval flavor of 
3316         Interpreter::execute() in order to create the scope used to eval.
3317
3318         * bytecode/CodeBlock.cpp:
3319         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
3320         * bytecode/CodeBlock.h:
3321         * dfg/DFGGraph.cpp:
3322         (JSC::DFG::Graph::registerFrozenValues):
3323
3324 2015-04-21  Chris Dumez  <cdumez@apple.com>
3325
3326         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
3327         https://bugs.webkit.org/show_bug.cgi?id=143970
3328
3329         Reviewed by Darin Adler.
3330
3331         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
3332         constructor explicit as it copies the vector and it is easy to call it
3333         by mistake.
3334
3335         * bytecode/UnlinkedInstructionStream.cpp:
3336         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
3337         * bytecode/UnlinkedInstructionStream.h:
3338         * ftl/FTLLowerDFGToLLVM.cpp:
3339         (JSC::FTL::LowerDFGToLLVM::lower):
3340
3341 2015-04-20  Basile Clement  <basile_clement@apple.com>
3342
3343         PhantomNewObject should be marked NodeMustGenerate
3344         https://bugs.webkit.org/show_bug.cgi?id=143974
3345
3346         Reviewed by Filip Pizlo.
3347
3348         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
3349
3350 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3351
3352         Cleanup some StringBuilder use
3353         https://bugs.webkit.org/show_bug.cgi?id=143550
3354
3355         Reviewed by Darin Adler.
3356
3357         * runtime/Symbol.cpp:
3358         (JSC::Symbol::descriptiveString):
3359         * runtime/TypeProfiler.cpp:
3360         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
3361         * runtime/TypeSet.cpp:
3362         (JSC::TypeSet::toJSONString):
3363         (JSC::StructureShape::propertyHash):
3364         (JSC::StructureShape::stringRepresentation):
3365         (JSC::StructureShape::toJSONString):
3366
3367 2015-04-20  Mark Lam  <mark.lam@apple.com>
3368
3369         Add debugging tools to test if a given pointer is a valid object and in the heap.
3370         https://bugs.webkit.org/show_bug.cgi?id=143910
3371
3372         Reviewed by Geoffrey Garen.
3373
3374         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
3375         purported JSObject is really a valid object in the heap or not.  We can add the
3376         following utility functions to help:
3377             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
3378             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
3379             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
3380             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
3381
3382         Also moved lldb callable debug utility function prototypes from
3383         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
3384         JSDollarVMPrototype class.  This is so that we can conveniently #include that
3385         file to get the prototypes when we need to call them programmatically from
3386         instrumentation that we add while debugging an issue.
3387
3388         * heap/Heap.h:
3389         (JSC::Heap::storageSpace):
3390         * tools/JSDollarVMPrototype.cpp:
3391         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
3392         (JSC::ensureCurrentThreadOwnsJSLock):
3393         (JSC::JSDollarVMPrototype::gc):
3394         (JSC::functionGC):
3395         (JSC::JSDollarVMPrototype::edenGC):
3396         (JSC::functionEdenGC):
3397         (JSC::JSDollarVMPrototype::isInHeap):
3398         (JSC::JSDollarVMPrototype::isInObjectSpace):
3399         (JSC::JSDollarVMPrototype::isInStorageSpace):
3400         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
3401         (JSC::ObjectAddressCheckFunctor::operator()):
3402         (JSC::JSDollarVMPrototype::isValidCell):
3403         (JSC::JSDollarVMPrototype::isValidCodeBlock):
3404         (JSC::JSDollarVMPrototype::codeBlockForFrame):
3405         (JSC::functionCodeBlockForFrame):
3406         (JSC::codeBlockFromArg):
3407         (JSC::JSDollarVMPrototype::printCallFrame):
3408         (JSC::JSDollarVMPrototype::printStack):
3409         (JSC::JSDollarVMPrototype::printValue):
3410         (JSC::currentThreadOwnsJSLock): Deleted.
3411         (JSC::gc): Deleted.
3412         (JSC::edenGC): Deleted.
3413         (JSC::isValidCodeBlock): Deleted.
3414         (JSC::codeBlockForFrame): Deleted.
3415         (JSC::printCallFrame): Deleted.
3416         (JSC::printStack): Deleted.
3417         (JSC::printValue): Deleted.
3418         * tools/JSDollarVMPrototype.h:
3419
3420 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3421
3422         Web Inspector: Improve Support for WeakSet in Console
3423         https://bugs.webkit.org/show_bug.cgi?id=143951
3424
3425         Reviewed by Darin Adler.
3426
3427         * inspector/InjectedScriptSource.js:
3428         * inspector/JSInjectedScriptHost.cpp:
3429         (Inspector::JSInjectedScriptHost::subtype):
3430         (Inspector::JSInjectedScriptHost::weakSetSize):
3431         (Inspector::JSInjectedScriptHost::weakSetEntries):
3432         * inspector/JSInjectedScriptHost.h:
3433         * inspector/JSInjectedScriptHostPrototype.cpp:
3434         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3435         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
3436         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
3437         Treat WeakSets like special sets.
3438
3439         * inspector/protocol/Runtime.json:
3440         Add a new object subtype, "weakset".
3441
3442 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
3443
3444         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
3445         https://bugs.webkit.org/show_bug.cgi?id=143947
3446
3447         Reviewed by Darin Adler.
3448
3449         Type profiler has map between PropertyKey (StringImpl*) and offset.
3450         StringImpl* is also used for Symbol PropertyKey.
3451         So equality of hash tables is considered by interned StringImpl*'s pointer value.
3452         To do so, use IdentifierRepHash instead of StringHash.
3453
3454         * runtime/SymbolTable.h:
3455
3456 2015-04-20  Jordan Harband  <ljharb@gmail.com>
3457
3458         Implement `Object.is`
3459         https://bugs.webkit.org/show_bug.cgi?id=143865
3460
3461         Reviewed by Darin Adler.
3462
3463         Expose sameValue to JS, via Object.is
3464         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
3465
3466         * runtime/ObjectConstructor.cpp:
3467         (JSC::objectConstructorIs):
3468         * runtime/PropertyDescriptor.cpp:
3469         (JSC::sameValue):
3470
3471 2015-04-19  Darin Adler  <darin@apple.com>
3472
3473         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
3474         https://bugs.webkit.org/show_bug.cgi?id=143941
3475
3476         Reviewed by Gyuyoung Kim.
3477
3478         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
3479         * API/JSCallbackObjectFunctions.h: Ditto.
3480
3481         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
3482         create function and the constructor and for m_impl.
3483         * API/ObjCCallbackFunction.mm:
3484         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
3485         class by using RetainPtr<Class>.
3486         (ArgumentTypeDelegate::typeInteger): Use make_unique.
3487         (ArgumentTypeDelegate::typeDouble): Ditto.
3488         (ArgumentTypeDelegate::typeBool): Ditto.
3489         (ArgumentTypeDelegate::typeVoid): Ditto.
3490         (ArgumentTypeDelegate::typeId): Ditto.
3491         (ArgumentTypeDelegate::typeOfClass): Ditto.
3492         (ArgumentTypeDelegate::typeBlock): Ditto.
3493         (ArgumentTypeDelegate::typeStruct): Ditto.
3494         (ResultTypeDelegate::typeInteger): Ditto.
3495         (ResultTypeDelegate::typeDouble): Ditto.
3496         (ResultTypeDelegate::typeBool): Ditto.
3497         (ResultTypeDelegate::typeVoid): Ditto.
3498         (ResultTypeDelegate::typeId): Ditto.
3499         (ResultTypeDelegate::typeOfClass): Ditto.
3500         (ResultTypeDelegate::typeBlock): Ditto.
3501         (ResultTypeDelegate::typeStruct): Ditto.
3502         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
3503         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
3504         Use RetainPtr<Class> for m_instanceClass.
3505         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
3506         for non-Objective-C object pointer null.
3507         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
3508         the arguments to the constructor and for m_impl.
3509         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
3510         (skipNumber): Mark this static since it's local to this source file.
3511         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
3512         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
3513         nullptr instead of nil for JSObjectRef values.
3514         (objCCallbackFunctionForMethod): Tweaked comment.
3515         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
3516
3517         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
3518
3519         * heap/GCThread.cpp:
3520         (JSC::GCThread::GCThread): Use unique_ptr.
3521         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
3522         m_slotVisitor and m_copyVisitor.
3523         * heap/GCThreadSharedData.cpp:
3524         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
3525
3526         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
3527
3528 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
3529
3530         Improve the feature.json files
3531
3532         * features.json:
3533
3534 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3535
3536         Introduce bytecode intrinsics
3537         https://bugs.webkit.org/show_bug.cgi?id=143926
3538
3539         Reviewed by Filip Pizlo.
3540
3541         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
3542         When implementing functions in builtins/*.js,
3543         sometimes we require lower level functionality.
3544
3545         For example, in the current Array.from, we use `result[k] = value`.
3546         The spec requires `[[DefineOwnProperty]]` operation here.
3547         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
3548         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
3549
3550         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
3551         However, there's no syntax to generate it directly.
3552
3553         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
3554         Like @call, @apply, we introduce a new node, Intrinsic.
3555         These are generated when calling appropriate private symbols in privileged code.
3556         AST parser detects them and generates Intrinsic nodes and
3557         BytecodeCompiler detects them and generate required bytecodes.
3558
3559         Currently, Array.from implementation works fine without this patch.
3560         This is because when the target code is builtin JS,
3561         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
3562         This solves the above issue. However, instead of solving this issue,
3563         it raises another issue; There's no way to emit `[[Set]]` operation.
3564         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
3565         So to implement it precisely, introducing bytecode level intrinsics is necessary.
3566
3567         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
3568         for `result[k] = value` under builtin JS environment. Instead of that special handling,
3569         use bytecode intrinsics instead. It solves problems and it is more intuitive
3570         because written JS code in builtin works as the same to the usual JS code.
3571
3572         * CMakeLists.txt:
3573         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3574         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3575         * JavaScriptCore.xcodeproj/project.pbxproj:
3576         * builtins/ArrayConstructor.js:
3577         (from):
3578         * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
3579         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3580         (JSC::BytecodeIntrinsicRegistry::lookup):
3581         * bytecode/BytecodeIntrinsicRegistry.h: Added.
3582         * bytecompiler/NodesCodegen.cpp:
3583         (JSC::BytecodeIntrinsicNode::emitBytecode):
3584         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
3585         * parser/ASTBuilder.h:
3586         (JSC::ASTBuilder::makeFunctionCallNode):
3587         * parser/NodeConstructors.h:
3588         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
3589         * parser/Nodes.h:
3590         (JSC::BytecodeIntrinsicNode::identifier):
3591         * runtime/CommonIdentifiers.cpp:
3592         (JSC::CommonIdentifiers::CommonIdentifiers):
3593         * runtime/CommonIdentifiers.h:
3594         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
3595         * tests/stress/array-from-with-accessors.js: Added.
3596         (shouldBe):
3597
3598 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3599
3600         Make Builtin functions non constructible
3601         https://bugs.webkit.org/show_bug.cgi?id=143923
3602
3603         Reviewed by Darin Adler.
3604
3605         Builtin functions defined by builtins/*.js accidentally have [[Construct]].
3606         According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
3607         This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
3608
3609         Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
3610         However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
3611         In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
3612         So in this patch, we check `isBuiltinFunction()` in those places.
3613
3614         * dfg/DFGByteCodeParser.cpp:
3615         (JSC::DFG::ByteCodeParser::inliningCost):
3616         * jit/JITOperations.cpp:
3617         * llint/LLIntSlowPaths.cpp:
3618         (JSC::LLInt::setUpCall):
3619         * runtime/JSFunction.cpp:
3620         (JSC::JSFunction::getConstructData):
3621         * tests/stress/builtin-function-is-construct-type-none.js: Added.
3622         (shouldThrow):
3623
3624 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3625
3626         [ES6] Implement WeakSet
3627         https://bugs.webkit.org/show_bug.cgi?id=142408
3628
3629         Reviewed by Darin Adler.
3630
3631         This patch implements ES6 WeakSet.
3632         Current implementation simply leverages WeakMapData with undefined value.
3633         This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
3634
3635         And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
3636         Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
3637         methods return false (or undefined for WeakMap.prototype.get)
3638         when a key is not Object instead of throwing a type error.
3639
3640         [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
3641
3642         * CMakeLists.txt:
3643         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3644         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3645         * JavaScriptCore.xcodeproj/project.pbxproj:
3646         * runtime/CommonIdentifiers.h:
3647         * runtime/JSGlobalObject.cpp:
3648         * runtime/JSGlobalObject.h:
3649         * runtime/JSWeakSet.cpp: Added.
3650         (JSC::JSWeakSet::finishCreation):
3651         (JSC::JSWeakSet::visitChildren):
3652         * runtime/JSWeakSet.h: Added.
3653         (JSC::JSWeakSet::createStructure):
3654         (JSC::JSWeakSet::create):
3655         (JSC::JSWeakSet::weakMapData):
3656         (JSC::JSWeakSet::JSWeakSet):
3657         * runtime/WeakMapPrototype.cpp:
3658         (JSC::getWeakMapData):
3659         (JSC::protoFuncWeakMapDelete):
3660         (JSC::protoFuncWeakMapGet):
3661         (JSC::protoFuncWeakMapHas):
3662         * runtime/WeakSetConstructor.cpp: Added.
3663         (JSC::WeakSetConstructor::finishCreation):
3664         (JSC::callWeakSet):
3665         (JSC::constructWeakSet):
3666         (JSC::WeakSetConstructor::getConstructData):
3667         (JSC::WeakSetConstructor::getCallData):
3668         * runtime/WeakSetConstructor.h: Added.
3669         (JSC::WeakSetConstructor::create):
3670         (JSC::WeakSetConstructor::createStructure):
3671         (JSC::WeakSetConstructor::WeakSetConstructor):
3672         * runtime/WeakSetPrototype.cpp: Added.
3673         (JSC::WeakSetPrototype::finishCreation):
3674         (JSC::getWeakMapData):
3675         (JSC::protoFuncWeakSetDelete):
3676         (JSC::protoFuncWeakSetHas):
3677         (JSC::protoFuncWeakSetAdd):
3678         * runtime/WeakSetPrototype.h: Added.
3679         (JSC::WeakSetPrototype::create):
3680         (JSC::WeakSetPrototype::createStructure):
3681         (JSC::WeakSetPrototype::WeakSetPrototype):
3682         * tests/stress/weak-set-constructor-adder.js: Added.
3683         (WeakSet.prototype.add):
3684         * tests/stress/weak-set-constructor.js: Added.
3685
3686 2015-04-17  Alexey Proskuryakov  <ap@apple.com>
3687
3688         Remove unused BoundsCheckedPointer
3689         https://bugs.webkit.org/show_bug.cgi?id=143896
3690
3691         Reviewed by Geoffrey Garen.
3692
3693         * bytecode/SpeculatedType.cpp: The header was included here.
3694
3695 2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3696
3697         [ES6] Fix name enumeration of static functions for Symbol constructor
3698         https://bugs.webkit.org/show_bug.cgi?id=143891
3699
3700         Reviewed by Geoffrey Garen.
3701
3702         Fix missing symbolPrototypeTable registration to the js class object.
3703         This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
3704
3705         * runtime/SymbolConstructor.cpp:
3706
3707 2015-04-17  Basile Clement  <basile_clement@apple.com>
3708
3709         Inline JSFunction allocation in DFG
3710         https://bugs.webkit.org/show_bug.cgi?id=143858
3711
3712         Reviewed by Filip Pizlo.
3713
3714         Followup to my previous patch which inlines JSFunction allocation when
3715         using FTL, now also enabled in DFG.
3716
3717         * dfg/DFGSpeculativeJIT.cpp:
3718         (JSC::DFG::SpeculativeJIT::compileNewFunction):
3719
3720 2015-04-16  Jordan Harband  <ljharb@gmail.com>
3721
3722         Number.parseInt is not === global parseInt in nightly r182673
3723         https://bugs.webkit.org/show_bug.cgi?id=143799
3724
3725         Reviewed by Darin Adler.
3726
3727         Ensuring parseInt === Number.parseInt, per spec
3728         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
3729
3730         * runtime/CommonIdentifiers.h:
3731         * runtime/JSGlobalObject.cpp:
3732         (JSC::JSGlobalObject::init):
3733         * runtime/JSGlobalObject.h:
3734         (JSC::JSGlobalObject::parseIntFunction):
3735         * runtime/NumberConstructor.cpp:
3736         (JSC::NumberConstructor::finishCreation):
3737
3738 2015-04-16  Mark Lam  <mark.lam@apple.com>
3739
3740         Gardening: fix CLOOP build after r182927.
3741
3742         Not reviewed.
3743
3744         * interpreter/StackVisitor.cpp:
3745         (JSC::StackVisitor::Frame::print):
3746
3747 2015-04-16  Basile Clement  <basile_clement@apple.com>
3748
3749         Inline JSFunction allocation in FTL
3750         https://bugs.webkit.org/show_bug.cgi?id=143851
3751
3752         Reviewed by Filip Pizlo.
3753
3754         JSFunction allocation is a simple operation that should be inlined when possible.
3755
3756         * ftl/FTLAbstractHeapRepository.h:
3757         * ftl/FTLLowerDFGToLLVM.cpp:
3758         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
3759         * runtime/JSFunction.h:
3760         (JSC::JSFunction::allocationSize):
3761
3762 2015-04-16  Mark Lam  <mark.lam@apple.com>
3763
3764         Add $vm debugging tool.
3765         https://bugs.webkit.org/show_bug.cgi?id=143809
3766
3767         Reviewed by Geoffrey Garen.
3768
3769         For debugging VM bugs, it would be useful to be able to dump VM data structures
3770         from JS code that we instrument.  To this end, let's introduce a
3771         JS_enableDollarVM option that, if true, installs an $vm property into each JS
3772         global object at creation time.  The $vm property refers to an object that
3773         provides a collection of useful utility functions.  For this initial
3774         implementation, $vm will have the following:
3775
3776             crash() - trigger an intentional crash.
3777
3778             dfgTrue() - returns true if the current function is DFG compiled, else returns false.
3779             jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
3780             llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
3781
3782             gc() - runs a full GC.
3783             edenGC() - runs an eden GC.
3784
3785             codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
3786             printSourceFor(codeBlock) - prints the source code for the codeBlock.
3787             printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
3788
3789             print(str) - prints a string to dataLog output.
3790             printCallFrame() - prints the current CallFrame.
3791             printStack() - prints the JS stack.
3792             printInternal(value) - prints the JSC internal info for the specified value.
3793
3794         With JS_enableDollarVM=true, JS code can use the above functions like so:
3795
3796             $vm.print("Using $vm features\n");
3797
3798         * CMakeLists.txt:
3799         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3800         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3801         * JavaScriptCore.xcodeproj/project.pbxproj:
3802         * bytecode/CodeBlock.cpp:
3803         (JSC::CodeBlock::printCallOp):
3804         - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
3805           Hence, we skip this step if we're dumping an FTL codeBlock.
3806
3807         * heap/Heap.cpp:
3808         (JSC::Heap::collectAndSweep):
3809         (JSC::Heap::collectAllGarbage): Deleted.
3810         * heap/Heap.h:
3811         (JSC::Heap::collectAllGarbage):
3812         - Add ability to do an Eden collection and sweep.
3813
3814         * interpreter/StackVisitor.cpp:
3815         (JSC::printIndents):
3816         (JSC::log):
3817         (JSC::logF):
3818         (JSC::StackVisitor::Frame::print):
3819         (JSC::jitTypeName): Deleted.
3820         (JSC::printif): Deleted.
3821         - Modernize the implementation of StackVisitor::Frame::print(), and remove some
3822           now redundant code.
3823         - Also fix it so that it downgrades gracefully when encountering inlined DFG
3824           and compiled FTL functions.
3825
3826         (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
3827         (DebugPrintFrameFunctor::operator()): Deleted.
3828         (debugPrintCallFrame): Deleted.
3829         (debugPrintStack): Deleted.
3830         - these have been moved into JSDollarVMPrototype.cpp. 
3831
3832         * interpreter/StackVisitor.h:
3833         - StackVisitor::Frame::print() is now enabled for release builds as well so that
3834           we can call it from $vm.
3835
3836         * runtime/JSGlobalObject.cpp:
3837         (JSC::JSGlobalObject::init):
3838         (JSC::JSGlobalObject::visitChildren):
3839         * runtime/JSGlobalObject.h:
3840         - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
3841           option.
3842
3843         * runtime/Options.h:
3844         - Added the JSC_enableDollarVM option.
3845
3846         * tools/JSDollarVM.cpp: Added.
3847         * tools/JSDollarVM.h: Added.
3848         (JSC::JSDollarVM::createStructure):
3849         (JSC::JSDollarVM::create):
3850         (JSC::JSDollarVM::JSDollarVM):
3851
3852         * tools/JSDollarVMPrototype.cpp: Added.
3853         - This file contains 2 sets of functions:
3854
3855           a. a C++ implementation of debugging utility functions that are callable when
3856              doing debugging from lldb.  To the extent possible, these functions try to
3857              be cautious and not cause unintended crashes should the user call them with
3858              the wrong info.  Hence, they are designed to be robust rather than speedy.
3859
3860           b. the native implementations of JS functions in the $vm object.  Where there
3861              is overlapping functionality, these are built on top of the C++ functions
3862              above to do the work.
3863
3864           Note: it does not make sense for all of the $vm functions to have a C++
3865           counterpart for lldb debugging.  For example, the $vm.dfgTrue() function is
3866           only useful for JS code, and works via the DFG intrinsics mechanism.
3867           When doing debugging via lldb, the optimization level of the currently
3868           executing JS function can be gotten by dumping the current CallFrame instead.
3869
3870         (JSC::currentThreadOwnsJSLock):
3871         (JSC::ensureCurrentThreadOwnsJSLock):
3872         (JSC::JSDollarVMPrototype::addFunction):
3873         (JSC::functionCrash): - $vm.crash()
3874         (JSC::functionDFGTrue): - $vm.dfgTrue()
3875         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
3876         (JSC::CallerFrameJITTypeFunctor::operator()):