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