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