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