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