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