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