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