d5c75a518b7cb9e29f43261503af516f960b8187
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-06-13  Mark Lam  <mark.lam@apple.com>
2
3         Add a mechanism for collecting LLINT stats.
4         https://bugs.webkit.org/show_bug.cgi?id=158668
5
6         Reviewed by Filip Pizlo.
7
8         This patch will add a mechanism for collecting the stats on LLINT opcode
9         execution counts.  The changes made to enable this are:
10
11         1. Refactored how Options availability work so that we can add a new category:
12            Configurable (in addition to the pre-existing Normal and Restricted
13            availability).
14                Normal options - always available.
15                Restricted options - only available on debug builds.
16                Configurable options - depends on #define flag options.
17
18            This change is necessary so that:
19            a. we won't have to rebuild the world when we want to enable that #define flag
20               to make that Configurable option available.
21            b. when the #define flag is disabled, the option will be invisible to the user.
22
23            With this, we add our first configurable option, JSC_reportLLIntStats, which
24            is dependent on the ENABLE_LLINT_STATS flag.  See next.
25
26         2. Added the ENABLE_LLINT_STATS flag in LLIntCommon.h.  To enable LLINT stats
27            collection, we'll need to set this flag to a non-zero value, and rebuilding
28            the project.  By design, this will only require a minimal set of files to
29            be rebuilt.
30
31            ENABLE_LLINT_STATS is 0 (i.e. disabled) by default.
32
33         3. Added a slow path callback to the LLINT's traceExecution() macro, to call
34            _llint_count_opcode(), which in turns counts the opcode.  This callback will
35            only be built into the LLINT if ENABLE_LLINT_STATS is non-zero.
36
37         4. Added s_opcodeStatsArray to LLInt::Data.  This is where the stats are
38            recorded and stored.
39
40         5. Added calls to LLInt::Data::dumpStats() in jsc.cpp and DumpRenderTree.mm
41            to dump the LLINT stats if enabled.  If enabled, the LLINT stats will be
42            sorted and dumped (via dataLog) before the programs terminate.
43
44         * interpreter/Interpreter.h:
45         * jsc.cpp:
46         (main):
47         * llint/LLIntCommon.h:
48         * llint/LLIntData.cpp:
49         (JSC::LLInt::initialize):
50         (JSC::LLInt::Data::dumpStats):
51         * llint/LLIntData.h:
52         (JSC::LLInt::Data::opcodeStats):
53         * llint/LLIntOfflineAsmConfig.h:
54         * llint/LLIntSlowPaths.cpp:
55         (JSC::LLInt::llint_crash):
56         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
57         * llint/LLIntSlowPaths.h:
58         * llint/LowLevelInterpreter.asm:
59         * runtime/Options.cpp:
60         (JSC::parse):
61         (JSC::Options::isAvailable):
62         (JSC::overrideOptionWithHeuristic):
63         (JSC::scaleJITPolicy):
64         (JSC::Options::initialize):
65         (JSC::Options::setOptionWithoutAlias):
66         (JSC::Options::dumpAllOptions):
67         (JSC::Options::dumpOption):
68         * runtime/Options.h:
69         (JSC::Option::Option):
70         (JSC::Option::operator!=):
71         (JSC::Option::id):
72
73 2016-06-11  Mark Lam  <mark.lam@apple.com>
74
75         Minimize the amount of memcpy done for allocating Error stacks.
76         https://bugs.webkit.org/show_bug.cgi?id=158664
77
78         Reviewed by Darin Adler.
79
80         Currently, Vector<StackFrame> are being copied around multiple times in the
81         process of creating Error stacks.
82
83         This patch avoids this unnecessary copying by:
84         1. Sizing the StackFrame vector correctly to begin with, and skipping
85            undesirable top frames before filling in the vector.
86         2. Using perfect forwarding or passing by reference to pass the vector data around
87            instead of copying the vectors.
88         3. Changing the Exception object to take a Vector<StackFrame> instead of a
89            RefCountedArray<StackFrame>.
90
91         This patch has passed the JSC and layout tests.  Benchmarks show that perf is
92         neutral.
93
94         * API/tests/testapi.mm:
95         (testObjectiveCAPI):
96         * inspector/ScriptCallStackFactory.cpp:
97         (Inspector::createScriptCallStackFromException):
98         * interpreter/Interpreter.cpp:
99         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
100         (JSC::GetStackTraceFunctor::operator()):
101         (JSC::Interpreter::getStackTrace):
102         (JSC::Interpreter::stackTraceAsString):
103         (JSC::findExceptionHandler):
104         * interpreter/Interpreter.h:
105         * runtime/Error.cpp:
106         (JSC::addErrorInfoAndGetBytecodeOffset):
107         * runtime/Exception.cpp:
108         (JSC::Exception::finishCreation):
109         * runtime/Exception.h:
110         (JSC::Exception::valueOffset):
111         (JSC::Exception::value):
112         (JSC::Exception::stack):
113         (JSC::Exception::didNotifyInspectorOfThrow):
114         (JSC::Exception::setDidNotifyInspectorOfThrow):
115
116 2016-06-11  Mark Lam  <mark.lam@apple.com>
117
118         Tests that overflows the stack should not be run with the sampling profiler.
119         https://bugs.webkit.org/show_bug.cgi?id=158663
120
121         Reviewed by Saam Barati.
122
123         The sampling profiler will be sampling the whole stack, and the amount of memory
124         churn will make this tests time out, especially with debug builds.  Hence,
125         let's not run the test with the sampling profiler configuration.
126
127         * tests/stress/mutual-tail-call-no-stack-overflow.js:
128         (shouldThrow):
129
130 2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>
131
132         Unreviewed, attempt to fix r201964 failure on Apple ports
133         https://bugs.webkit.org/show_bug.cgi?id=158619
134
135         Reviewed by Mark Lam.
136
137         Add Private attributes to MathCommon.h.
138
139         * JavaScriptCore.xcodeproj/project.pbxproj:
140
141 2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>
142
143         [JSC] Inline JSC::toInt32 to improve kraken
144         https://bugs.webkit.org/show_bug.cgi?id=158619
145
146         Reviewed by Mark Lam.
147
148         Several kraken benchmarks show that JSC::toInt32 is frequently called.
149         For example, stanford-crypto-pbkdf2 reports that the hottest runtime function is JSC::toInt32.
150
151         The data is below (taken by Linux perf tools).
152         5.50%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC7toInt32Ed
153         3.96%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC20arrayProtoFuncConcatEPNS_9ExecStateE
154         2.48%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC19arrayProtoFuncSliceEPNS_9ExecStateE
155         1.69%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZNK3JSC9Structure27holesMustForwardToPrototypeERNS_2VME
156
157         This is because of CommonSlowPaths' bit operations's JSValue::toInt32.
158         Due to the slow path, in `value | 0`, `value` may be a double number value. In that case, JSC::toInt32 is called.
159
160         While JSC::toIn32 is hot, the function itself is very small. It's worth inlining.
161
162         This change offers the following kraken improvements.
163
164                                                          baseline                  patched
165         Kraken:
166            audio-beat-detection                       47.492+-1.701             46.657+-1.232           might be 1.0179x faster
167            stanford-crypto-aes                        43.669+-0.210      ^      42.862+-0.115         ^ definitely 1.0188x faster
168            stanford-crypto-ccm                        45.213+-1.424             44.490+-1.290           might be 1.0162x faster
169            stanford-crypto-pbkdf2                    107.665+-0.581      ^     106.229+-0.807         ^ definitely 1.0135x faster
170
171         This patch only focused on the call to toInt32 from the runtime functions.
172         So JSC::toInt32 calls from the baseline / DFG remain.
173         We ensure that JIT code uses operationToInt32 instead of JSC::toInt32 since JSC::toInt32 is now marked as ALWAYS_INLINE.
174         Linux perf profiler also finds that this `operationToInt32` is frequently called in the above benchmarks.
175         It may be good to introduce asm emit for that instead of calling JSC::toInt32 operation in the separated patch.
176
177         * dfg/DFGSpeculativeJIT.cpp:
178         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
179         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
180         * ftl/FTLLowerDFGToB3.cpp:
181         (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
182         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
183         * runtime/JSCJSValue.cpp:
184         (JSC::toInt32): Deleted.
185         * runtime/JSCJSValueInlines.h:
186         * runtime/MathCommon.cpp:
187         (JSC::operationToInt32):
188         * runtime/MathCommon.h:
189         (JSC::toInt32):
190
191 2016-06-10  Filip Pizlo  <fpizlo@apple.com>
192
193         The backend should be happy to compile Unreachable even if AI didn't prove it to be unreachable
194         https://bugs.webkit.org/show_bug.cgi?id=158631
195
196         Reviewed by Keith Miller.
197         
198         We've been slowly making the DFG Unreachable opcode behave like a grown-up. When we first
199         added it, it was a hack for Throw, and we could always rely on AI proving that Unreachable
200         was not reachable. But then we started using Unreachable as a proper Unreachable opcode,
201         like Oops in B3 for example, which has a more nuanced meaning: you use it whenever you
202         emit code that *you* know will not return, and you need some way of terminating the basic
203         block. The DFG is not a proof-carrying compiler, and it never will be. So, when you have
204         proved that something is not reachable, you should be able to use Unreachable even if
205         there is no guarantee that the compiler will later be able to replicate your proof. This
206         means that the backend may find itself compiling Unreachable because AI did not prove that
207         it was unreachable.
208         
209         Prior to this change, we would crash compiling Unreachable because we would rely on AI
210         preventing us from reaching Unreachable in the backend. But that's silly! We don't want
211         users of Unreachable to have to also convince AI that their Unreachable is really
212         Unreachable.
213         
214         This fixes crashes on real websites. I couldn't work out how to turn them into a reduced
215         test.
216
217         * assembler/AbortReason.h:
218         * dfg/DFGSpeculativeJIT.cpp:
219         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
220         (JSC::DFG::SpeculativeJIT::unreachable):
221         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
222         * dfg/DFGSpeculativeJIT.h:
223         * dfg/DFGSpeculativeJIT32_64.cpp:
224         (JSC::DFG::SpeculativeJIT::compile):
225         * dfg/DFGSpeculativeJIT64.cpp:
226         (JSC::DFG::SpeculativeJIT::compile):
227         * ftl/FTLLowerDFGToB3.cpp:
228         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
229         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
230         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable):
231         (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
232
233 2016-06-09  Alex Christensen  <achristensen@webkit.org>
234
235         Clean up JavaScriptCore.vcxproj directory after switching to CMake.
236
237         * JavaScriptCore.vcxproj/LLInt: Removed.
238         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly: Removed.
239         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: Removed.
240         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Removed.
241         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Removed.
242         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets: Removed.
243         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
244         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed.
245         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Removed.
246         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor: Removed.
247         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed.
248         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed.
249         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed.
250         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Removed.
251         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed.
252         * JavaScriptCore.vcxproj/jsc: Removed.
253         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Removed.
254         * JavaScriptCore.vcxproj/jsc/DLLLauncherWinCairo.props: Removed.
255         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Removed.
256         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Removed.
257         * JavaScriptCore.vcxproj/jsc/jscCommon.props: Removed.
258         * JavaScriptCore.vcxproj/jsc/jscDebug.props: Removed.
259         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj: Removed.
260         * JavaScriptCore.vcxproj/jsc/jscLauncherPostBuild.cmd: Removed.
261         * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd: Removed.
262         * JavaScriptCore.vcxproj/jsc/jscLauncherPreLink.cmd: Removed.
263         * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Removed.
264         * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Removed.
265         * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Removed.
266         * JavaScriptCore.vcxproj/jsc/jscProduction.props: Removed.
267         * JavaScriptCore.vcxproj/jsc/jscRelease.props: Removed.
268         * JavaScriptCore.vcxproj/testRegExp: Removed.
269         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Removed.
270         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Removed.
271         * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Removed.
272         * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Removed.
273         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj: Removed.
274         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPostBuild.cmd: Removed.
275         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd: Removed.
276         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreLink.cmd: Removed.
277         * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Removed.
278         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Removed.
279         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Removed.
280         * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Removed.
281         * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Removed.
282         * JavaScriptCore.vcxproj/testapi: Removed.
283         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Removed.
284         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Removed.
285         * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Removed.
286         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Removed.
287         * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Removed.
288         * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Removed.
289         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj: Removed.
290         * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd: Removed.
291         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd: Removed.
292         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreLink.cmd: Removed.
293         * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Removed.
294         * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Removed.
295         * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Removed.
296         * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Removed.
297         * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Removed.
298         * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Removed.
299         * shell/DLLLauncherMain.cpp: Copied from JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp.
300         * shell/PlatformWin.cmake:
301
302 2016-06-09  Filip Pizlo  <fpizlo@apple.com>
303
304         Rare failure in stress/v8-deltablue-strict.js.ftl-eager
305         https://bugs.webkit.org/show_bug.cgi?id=158591
306
307         Reviewed by Saam Barati.
308         
309         This is a simple and sensible fix to an amazing compiler bug that previously only
310         manifested rarely in the v8-deltablue-strict test. It required on average 1000 runs while
311         the system was under load for the bug to manifest. Fortunately, the bug is 100% repro with
312         concurrent JIT disabled in the new "constant-fold-multi-get-by-offset-to-get-by-offset-on-
313         prototype-and-sink-allocation.js" test.
314         
315         The problem here is that we were allowing ourselves to be super sloppy with the meaning of
316         the two children of GetByOffset, and to a lesser extent, PutByOffset. The first two
317         children of these nodes have these meanings:
318         
319         child1: the storage from which to load (or to which to store)
320         child2: the logical object base
321         
322         Normally, child1 == child2, but child1 may point to a node that vends the storage pointer
323         in case we are using multiple indirections to get to the property. That's fairly common.
324         
325         Where this gets nutty is that we don't validate the behavior of child1. Previously, the
326         DFG::Validate phase would accept code that had child1 point to one object and child2 point
327         to another object. That's bad because then, analyses will assume that we're loading from
328         one object while we are actually loading from another. One of the fixes is to make
329         Validate smarter about this, so that future problems with this get caught sooner.
330         
331         The actual bug was in ConstantFoldingPhase. When we first wrote ConstantFoldingPhase's
332         logic for converting GetByIds and MultiGetByOffsets to GetByOffset, we assumed that this
333         was only for non-prototype loads. This was becuase the logic was originally written based
334         on a static GetByIdStatus analysis, which does not handle prototypes. So, as a shortcut,
335         we would convert the GetById (or MultiGetByOffset) to a GetByOffset by doing this
336         shuffling of children:
337         
338         child1 got the storage pointer, which might be a new GetButterfly node that we created.
339         child2 got the old value of child1.
340         
341         The bug was introduced when I later made it possible for a monomorphic prototype
342         MultiGetByOffset to be converted to a GetByOffset. Then this algorithm would mean that:
343         
344         child1 got either a pointer to the prototype or a storage pointer derived from the
345             prototype.
346         child2 got the old value of child1, which was a pointer to the base object (i.e. not the
347             prototype).
348         
349         This happens super rarely because most prototype loads that we can statically reason about
350         also happen to load constants, so we don't convert to GetByOffset at all. You need the
351         strange combination of a MultiGetByOffset (not GetById or GetByOffset) on some prototypes
352         and some static reasoning about the base so that we can convert it to a GetByOffset, but
353         not enough static reasoning that we can convert it to a constant.
354         
355         Even if the bad thing happened, then this is not enough for it to cause symptons. If we
356         did nothing else - like none of the other optimizations succeeded - then this would
357         be OK because the backend will emit code based on child1, which is right. But disaster
358         strikes when the code otherwise looks sane enough for ObjectAllocationSinkingPhase to kick
359         in. This phase operates on child2, as any good phase should: child1 is only interesting
360         for knowing *how* to load, not *what* we are loading. The phase is right to ignore child1.
361
362         So the phase would assume that we are loading the prototype property ("f" in the new test
363         or "addToGraph" in deltablue) from the sunken base object allocation in the inlined
364         constructor. The base object has no such property, but the phase conservatively assumes
365         that it does indeed have such a property. That's just how the phase does things: it is
366         very abstract and general, so it assumes that the set of properties on an allocation is
367         the set of properties that accesses to the allocation speak of. Clearly, this GetByOffset
368         was speaking of the property as being on the allocation. When sinking completed, it would
369         convert the GetByOffset to the sunken (a.k.a. promoted) property. But nobody stored to
370         this property on the allocation, so we'd get the bottom value, which is 1927. Why 1927? I
371         don't remember anymore, but apparently I chose it. It helped here - when I started seeing
372         that value come up, it took a quick grep to realize that this was the object allocation
373         sinking phase's bottom value.
374         
375         The real fix to the bug is to make Node::convertToGetByOffset() take an explicit new base
376         since its clients will use it to potentially create a load on a different object than the
377         base of the original operation, as in the relatively new
378         MultiGetByOffset(prototype)->GetByOffset optimization. As far as I know, the PutByOffset
379         code did not have the same bug because we don't have any optimizations that turn a PutById
380         or MultiPutByOffset into a PutByOffset on anything but the base object. But the logical
381         bug is definitely there: there's code in ConstantFoldingPhase that claims to be able to
382         convert any node to a PutByOffset on any base, but it actually silently reuses the
383         original node's child1 as the logical base (i.e. child2). This patch makes all of this
384         stuff explicit. You can't make this mistake anymore.
385
386         * dfg/DFGConstantFoldingPhase.cpp:
387         (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
388         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
389         * dfg/DFGNode.h:
390         (JSC::DFG::Node::convertToGetStack):
391         (JSC::DFG::Node::convertToGetByOffset):
392         (JSC::DFG::Node::convertToMultiGetByOffset):
393         (JSC::DFG::Node::convertToPutByOffset):
394         * dfg/DFGValidate.cpp:
395         * tests/stress/constant-fold-multi-get-by-offset-to-get-by-offset-on-prototype-and-sink-allocation.js: Added.
396         (ThingA):
397         (ThingB):
398         (foo):
399         (bar):
400         * tests/stress/sink-to-impossible-multi-get-by-offset-on-prototypes.js: Added.
401         (ThingA):
402         (ThingB):
403         (ThingC):
404         (bar):
405         (foo):
406
407 2016-06-09  Mark Lam  <mark.lam@apple.com>
408
409         Make some methods const.
410         https://bugs.webkit.org/show_bug.cgi?id=158594
411
412         Reviewed by Benjamin Poulain.
413
414         * bytecode/CodeBlock.cpp:
415         (JSC::CodeBlock::columnNumberForBytecodeOffset):
416         (JSC::CodeBlock::expressionRangeForBytecodeOffset):
417         * bytecode/CodeBlock.h:
418         * bytecode/ExpressionRangeInfo.h:
419         (JSC::ExpressionRangeInfo::encodeFatColumnMode):
420         (JSC::ExpressionRangeInfo::decodeFatLineMode):
421         (JSC::ExpressionRangeInfo::decodeFatColumnMode):
422         * bytecode/UnlinkedCodeBlock.cpp:
423         (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
424         (JSC::UnlinkedCodeBlock::getLineAndColumn):
425         (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
426         * bytecode/UnlinkedCodeBlock.h:
427         (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
428         * interpreter/Interpreter.cpp:
429         (JSC::Interpreter::isOpcode):
430         (JSC::StackFrame::computeLineAndColumn):
431         (JSC::StackFrame::toString):
432         * interpreter/Interpreter.h:
433         (JSC::StackFrame::isNative):
434
435 2016-06-09  Michael Saboff  <msaboff@apple.com>
436
437         ES6: Reusing function name as a parameter name shouldn't throw Syntax Error
438         https://bugs.webkit.org/show_bug.cgi?id=158575
439
440         Reviewed by Benjamin Poulain.
441
442         The check for a parameter with a duplicate name doesn't take into account the
443         type of the prior variable.  Added a check that the duplicate is also a
444         parameter.
445
446         See the relevant spec section at:
447         http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors
448
449         * parser/Parser.h:
450         (JSC::Scope::declareParameter):
451
452 2016-06-09  Chris Dumez  <cdumez@apple.com>
453
454         Unreviewed, rolling out r201836, r201845, and r201848.
455
456         Looks like a 1-2% PLT regression on iOS
457
458         Reverted changesets:
459
460         "[JSC] Change some parameters based on a random search"
461         https://bugs.webkit.org/show_bug.cgi?id=158514
462         http://trac.webkit.org/changeset/201836
463
464         "Tempory fix for the debug bots"
465         http://trac.webkit.org/changeset/201845
466
467         "Change thresholdForOptimizeSoon to match
468         thresholdForOptimizeAfterWarmUp"
469         http://trac.webkit.org/changeset/201848
470
471 2016-06-09  Commit Queue  <commit-queue@webkit.org>
472
473         Unreviewed, rolling out r201810.
474         https://bugs.webkit.org/show_bug.cgi?id=158563
475
476         breaks build without ENABLE_WEB_ANIMATION (Requested by
477         mcatanzaro on #webkit).
478
479         Reverted changeset:
480
481         "[web-animations] Add Animatable, AnimationEffect,
482         KeyframeEffect and Animation interface"
483         https://bugs.webkit.org/show_bug.cgi?id=156096
484         http://trac.webkit.org/changeset/201810
485
486 2016-06-08  Gavin & Ellie Barraclough  <barraclough@apple.com>
487
488         JSObject::reifyAllStaticProperties cleanup
489         https://bugs.webkit.org/show_bug.cgi?id=158543
490
491         Reviewed by Mark Lam.
492
493         - JSObject & Structure contain fields labeled 'staticFunctionsReified', however reification now
494           affects all properties, not just functions. Rename to 'staticPropertiesReified'.
495         - reifyAllStaticProperties relies on a 'hasStaticProperties' method on ClassInfo that walks the
496           ClassInfo inheritance chain looking for static property tables. We can now more efficiently
497           get this information from TypeInfo.
498         - reifyAllStaticProperties triggers a 'toUncacheableDictionaryTransition'; this is overzealous,
499           cacheable dictionary is sufficient - this is what we do in the case of DOM prototype property
500           reification (see 'reifyStaticProperties' in Lookup.h). (Changing this with an eye on switching
501           DOM prototype property reification to use JSObject:: reifyAllStaticProperties, rather than
502           having its own special purpose code path.)
503
504         * runtime/ClassInfo.h:
505         (JSC::ClassInfo::hasStaticProperties): Deleted.
506             - deprecated by TypeInfo::hasStaticPropertyTable.
507         * runtime/JSObject.cpp:
508         (JSC::JSObject::putInlineSlow):
509         (JSC::JSObject::deleteProperty):
510         (JSC::JSObject::getOwnNonIndexPropertyNames):
511             - staticFunctionsReified -> staticPropertiesReified
512         (JSC::JSObject::reifyAllStaticProperties):
513             - hasStaticProperties -> TypeInfo::hasStaticPropertyTable
514             - toUncacheableDictionaryTransition -> toCacheableDictionaryTransition
515             - staticFunctionsReified -> staticPropertiesReified
516         * runtime/JSObject.h:
517         (JSC::JSObject::staticPropertiesReified):
518         (JSC::JSObject::staticFunctionsReified): Deleted.
519         * runtime/Lookup.cpp:
520         (JSC::setUpStaticFunctionSlot):
521         * runtime/Lookup.h:
522         (JSC::getStaticPropertySlotFromTable):
523         (JSC::replaceStaticPropertySlot):
524         * runtime/Structure.cpp:
525         (JSC::Structure::Structure):
526         * runtime/Structure.h:
527             - staticFunctionsReified -> staticPropertiesReified
528
529 2016-06-08  Benjamin Poulain  <bpoulain@apple.com>
530
531         Change thresholdForOptimizeSoon to match thresholdForOptimizeAfterWarmUp
532
533         Unreviewed.
534
535         This adds back the assertion removed in r201845.
536         Making those threshold equal is completely perf neutral
537         (on Haswell rMBP with 20 runs).
538
539         * runtime/Options.cpp:
540         (JSC::Options::initialize):
541         * runtime/Options.h:
542
543 2016-06-08  Benjamin Poulain  <bpoulain@apple.com>
544
545         Tempory fix for the debug bots
546
547         Unreviewed.
548
549         * runtime/Options.cpp:
550         (JSC::Options::initialize):
551         Weaken an assertion while I test values for thresholdForOptimizeSoon.
552
553 2016-06-08  Benjamin Poulain  <bpoulain@apple.com>
554
555         [JSC] Change some parameters based on a random search
556         https://bugs.webkit.org/show_bug.cgi?id=158514
557
558         Reviewed by Filip Pizlo.
559
560         Over the weekend, I left an iMac running the JSC benchmarks
561         while changing a bunch of parameters.
562
563         The parameters were changed randomly, with a random deviation
564         from the original value.
565         To converge toward good values, the range was subject
566         to exponential annealing over time.
567
568         The values in this patch is the best outcome my iMac could
569         find over the weekend. It is about 1% better on the Haswell
570         machines I tested.
571
572         * bytecode/CodeBlock.cpp:
573         (JSC::CodeBlock::optimizationThresholdScalingFactor):
574         * runtime/Options.h:
575
576 2016-06-08  Gavin Barraclough  <barraclough@apple.com>
577
578         Remove removeDirect
579         https://bugs.webkit.org/show_bug.cgi?id=158516
580
581         Reviewed by Ryosuke Niwa.
582
583         removeDirect is typically used as a subroutine of deleteProperty, but is also available to
584         call directly. Having this functionality factored out to a separate routine is a bad idea
585         on a couple of fronts:
586
587         - for the main use within deleteProperty there is redundancy (presence of the property
588           was being checked twice) and inconsistency (the two functions returned different results
589           in the case of a nonexistent property; the result from removeDirect was never observed).
590
591         - all uses of removeDirect are in practical terms incorrect. removeDirect had the
592           advantage of ignoring the configurable (DontDelete) attributes, but this is achievable
593           using the DeletePropertyMode setting - and the disadvantage of failing delete static
594           table properties. Last uses were one that was removed in bug #158295 (where failure to
595           delete static properties was a problem), and as addressed in this patch removeDirect is
596           being used to implement runtime enabled features. This only works because we currently
597           force reification of all properties on the DOM prototype objects, so in effect there are
598           no static properties. In order to make the code robust such that runtime enabled
599           features would still work even if we were not reifying static properties (a change we
600           may want to make) we should be calling deleteProperty in this case too.
601
602         * runtime/JSObject.cpp:
603         (JSC::JSObject::deleteProperty):
604             - incorporated removeDirect functionality, added comments & ASSERT.
605         (JSC::JSObject::removeDirect): Deleted.
606             - removed.
607         * runtime/JSObject.h:
608             - removed removeDirect.
609
610 2016-06-08  Mark Lam  <mark.lam@apple.com>
611
612         Simplify Interpreter::StackFrame.
613         https://bugs.webkit.org/show_bug.cgi?id=158498
614
615         Reviewed by Saam Barati.
616
617         Previously, Interpreter::StackFrame (which is used to capture info for
618         Error.stack) eagerly extracts info out of CodeBlock and duplicates the work that
619         CodeBlock does to compute line and column numbers (amongst other things).
620
621         This patch does away with the eager extraction and only stashes the CodeBlock
622         pointer in the Interpreter::StackFrame.  Instead, Interpreter::StackFrame will
623         provide methods for computing the desired values on request later.
624
625         One difference in implementation: the old StackFrame offers a sourceURL and a
626         friendlySourceURL().  The only difference between the 2 is that for native
627         functions, sourceURL returns an empty string, and friendlySourceURL() returns
628         "[native code]".  This is how it affects the clients of StackFrame:
629
630             - In the old code, the Error object's addErrorInfoAndGetBytecodeOffset() and
631               the inspector's createScriptCallStackFromException() would check if
632               sourceURL is empty.  If so, they will use this as an indicator to use
633               alternate source info in the Error object e.g. url and line numbers from
634               the parser that produced a SyntaxError.
635
636             - In the new implementation, StackFrame only has a sourceURL() function that
637               behaves like the old friendlySourceURL().  The client code which were
638               relying on sourceURL being empty, will now explicitly check if the
639               StackFrame is for native code using a new isNative() query in addition to
640               the sourceURL being empty.  This achieve functional parity with the old
641               behavior.
642
643         Also fix Error.cpp's addErrorInfoAndGetBytecodeOffset() to take a bytecodeOffset
644         pointer instead of a reference.  The bytecodeOffset arg is supposed to be
645         optional, but was implemented in a unclear way.  This change clarifies it.
646
647         * inspector/ScriptCallStackFactory.cpp:
648         (Inspector::createScriptCallStackFromException):
649         * interpreter/Interpreter.cpp:
650         (JSC::StackFrame::sourceID):
651         (JSC::StackFrame::sourceURL):
652         (JSC::StackFrame::functionName):
653         (JSC::eval):
654         (JSC::Interpreter::isOpcode):
655         (JSC::StackFrame::computeLineAndColumn):
656         (JSC::StackFrame::toString):
657         (JSC::GetStackTraceFunctor::operator()):
658         (JSC::StackFrame::friendlySourceURL): Deleted.
659         (JSC::StackFrame::friendlyFunctionName): Deleted.
660         (JSC::getStackFrameCodeType): Deleted.
661         (JSC::StackFrame::expressionInfo): Deleted.
662         * interpreter/Interpreter.h:
663         (JSC::StackFrame::isNative):
664         * runtime/Error.cpp:
665         (JSC::addErrorInfoAndGetBytecodeOffset):
666         (JSC::addErrorInfo):
667         * runtime/Error.h:
668         * runtime/ErrorInstance.cpp:
669         (JSC::ErrorInstance::finishCreation):
670
671 2016-06-08  Keith Miller  <keith_miller@apple.com>
672
673         We should be able to lookup symbols by identifier in builtins
674         https://bugs.webkit.org/show_bug.cgi?id=158530
675
676         Reviewed by Mark Lam.
677
678         This patch allows us to lookup the value of a symbol property on a
679         object by identifier in builtins. Before, it was only possible to
680         do so if we were directly emitting the bytecodes, such as in a
681         for-of loop looking for Symbol.iterator. As we tier up we convert
682         the builtin's get_by_val symbol lookups into get_by_id
683         lookups. However, there is still a significant performance
684         difference between get_by_id and get_by_val in the LLInt, where
685         this transformation does not take place.
686
687         In order to make this work we hijack BuiltinNames'
688         m_publicToPrivateMap so that it points the @<symbol>Symbol to the
689         appropriate vm symbol. This way when we lex the identifier it will
690         become the appropriate symbol's identifier.  Currently, if the
691         symbol is used to name a property in an object literal we will not
692         keep a cache of the Symbol objects we have already seen. We could
693         add a map for symbols but since we can only load symbols by
694         identifier in builtins its likely not worth it. Additionally, even
695         in builtins it is extremely rare to use Symbols in object
696         literals.
697
698         * builtins/ArrayConstructor.js:
699         (from):
700         * builtins/ArrayPrototype.js:
701         (filter):
702         (map):
703         * builtins/BuiltinNames.h:
704         (JSC::BuiltinNames::BuiltinNames):
705         * builtins/BuiltinUtils.h:
706         * builtins/GlobalObject.js:
707         (speciesConstructor):
708         * builtins/StringPrototype.js:
709         (match):
710         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
711         (search):
712         (split):
713         * builtins/TypedArrayConstructor.js:
714         (from):
715         * builtins/TypedArrayPrototype.js:
716         (map):
717         (filter):
718         * bytecode/BytecodeIntrinsicRegistry.cpp:
719         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted.
720         * bytecode/BytecodeIntrinsicRegistry.h:
721         * bytecompiler/BytecodeGenerator.cpp:
722         (JSC::BytecodeGenerator::emitLoad):
723         * parser/Parser.cpp:
724         (JSC::Parser<LexerType>::parseInner):
725
726 2016-06-08  Rawinder Singh  <rawinder.singh-webkit@cisra.canon.com.au>
727
728         [web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface
729         https://bugs.webkit.org/show_bug.cgi?id=156096
730
731         Reviewed by Dean Jackson.
732
733         Adds:
734         - Animatable interface and implementation of getAnimations in Element
735         - Interface and implementation for Document getAnimations method.
736         - AnimationEffect interface and class stub.
737         - KeyframeEffect interface and constructor implementation.
738         - 'Animation' interface, constructor and query methods for effect and timeline.
739         - Remove runtime condition on Web animation interfaces (compile time flag is specified).
740
741         * runtime/CommonIdentifiers.h:
742
743 2016-06-08  Chris Dumez  <cdumez@apple.com>
744
745         self.hasOwnProperty() does not work inside Web workers
746         https://bugs.webkit.org/show_bug.cgi?id=158446
747         <rdar://problem/26638397>
748
749         Reviewed by Geoffrey Garen.
750
751         Add a factory function to JSProxy to create a JSProxy without a target.
752         Also make the setTarget() method public so that the target can now be
753         set after creation. This is needed so that we can create a proxy for
754         JSWorkerGlobalScope, then create the JSWorkerGlobalScope object,
755         passing it the proxy and finally set the target on the proxy.
756
757         * runtime/JSProxy.h:
758         (JSC::JSProxy::create):
759
760 2016-06-07  Filip Pizlo  <fpizlo@apple.com>
761
762         Add result validation to JSAir
763         https://bugs.webkit.org/show_bug.cgi?id=158493
764
765         Reviewed by Saam Barati.
766         
767         Add a ::jsHash() method to some things, to compute a hash code that is suitable for
768         comparing a C++ Code to a JSAir Code. This is different from existing hashing functionality
769         because it errs on the side of easy reproducibility from JS rather than speed.
770
771         * b3/air/AirArg.cpp:
772         (JSC::B3::Air::Arg::isCompatibleType):
773         (JSC::B3::Air::Arg::jsHash):
774         (JSC::B3::Air::Arg::dump):
775         * b3/air/AirArg.h:
776         (JSC::B3::Air::Arg::asDoubleCondition):
777         (JSC::B3::Air::Arg::isInvertible):
778         (JSC::B3::Air::Arg::isUnsignedCond):
779         (JSC::B3::Air::Arg::Arg):
780         * b3/air/AirCode.cpp:
781         (JSC::B3::Air::Code::addFastTmp):
782         (JSC::B3::Air::Code::jsHash):
783         * b3/air/AirCode.h:
784         (JSC::B3::Air::Code::lastPhaseName):
785         * b3/air/AirDumpAsJS.cpp:
786         (JSC::B3::Air::dumpAsJS):
787         * b3/air/AirGenerate.cpp:
788         (JSC::B3::Air::prepareForGeneration):
789         * b3/air/AirInst.cpp:
790         (JSC::B3::Air::Inst::hasArgEffects):
791         (JSC::B3::Air::Inst::jsHash):
792         (JSC::B3::Air::Inst::dump):
793         * b3/air/AirInst.h:
794         * b3/air/AirStackSlot.cpp:
795         (JSC::B3::Air::StackSlot::setOffsetFromFP):
796         (JSC::B3::Air::StackSlot::jsHash):
797         (JSC::B3::Air::StackSlot::dump):
798         * b3/air/AirStackSlot.h:
799         * b3/air/opcode_generator.rb:
800
801 2016-06-07  Mark Lam  <mark.lam@apple.com>
802
803         Need an exception check after constructEmptyArray().
804         https://bugs.webkit.org/show_bug.cgi?id=158411
805
806         Reviewed by Saam Barati.
807
808         Added an exception check after each call to constructEmptyArray().
809
810         * inspector/JSInjectedScriptHost.cpp:
811         (Inspector::JSInjectedScriptHost::getInternalProperties):
812         (Inspector::JSInjectedScriptHost::weakMapEntries):
813         (Inspector::JSInjectedScriptHost::weakSetEntries):
814         (Inspector::JSInjectedScriptHost::iteratorEntries):
815         * interpreter/ShadowChicken.cpp:
816         (JSC::ShadowChicken::functionsOnStack):
817         * profiler/ProfilerBytecodeSequence.cpp:
818         (JSC::Profiler::BytecodeSequence::addSequenceProperties):
819         * profiler/ProfilerCompilation.cpp:
820         (JSC::Profiler::Compilation::toJS):
821         * profiler/ProfilerDatabase.cpp:
822         (JSC::Profiler::Database::toJS):
823         * profiler/ProfilerOSRExitSite.cpp:
824         (JSC::Profiler::OSRExitSite::toJS):
825         * profiler/ProfilerOriginStack.cpp:
826         (JSC::Profiler::OriginStack::toJS):
827         * runtime/ArrayPrototype.cpp:
828         (JSC::arrayProtoFuncConcat):
829         (JSC::arrayProtoFuncSlice):
830         (JSC::arrayProtoFuncSplice):
831         * runtime/LiteralParser.cpp:
832         (JSC::LiteralParser<CharType>::parse):
833         * runtime/ModuleLoaderObject.cpp:
834         (JSC::moduleLoaderObjectRequestedModules):
835         * runtime/ObjectConstructor.cpp:
836         (JSC::ownPropertyKeys):
837         * runtime/RegExpObject.cpp:
838         (JSC::collectMatches):
839         * runtime/RegExpPrototype.cpp:
840         (JSC::regExpProtoFuncSplitFast):
841         * runtime/StringPrototype.cpp:
842         (JSC::stringProtoFuncSplitFast):
843         * runtime/TemplateRegistry.cpp:
844         (JSC::TemplateRegistry::getTemplateObject):
845
846         * tests/stress/regress-158411.js: Added.
847
848 2016-06-07  Filip Pizlo  <fpizlo@apple.com>
849
850         Implement Air::allocateStack() in ES6 to see how much of a bad idea that is
851         https://bugs.webkit.org/show_bug.cgi?id=158318
852
853         Reviewed by Saam Barati.
854         
855         Most of these changes are to support dumpAsJS(). But I also found some duplicate and dead
856         code while rewriting it to JS.
857
858         * CMakeLists.txt:
859         * JavaScriptCore.xcodeproj/project.pbxproj:
860         * b3/air/AirAllocateStack.cpp:
861         * b3/air/AirArg.h:
862         (JSC::B3::Air::Arg::isSomeImm):
863         (JSC::B3::Air::Arg::isAddr):
864         (JSC::B3::Air::Arg::tmpIndex):
865         (JSC::B3::Air::Arg::isValidImmForm):
866         (JSC::B3::Air::Arg::withOffset): Deleted. This was dead code.
867         * b3/air/AirArgInlines.h: It turns out that Inst has a ForEach thing that duplicated some of the logic of ArgThingHelper, so I just made ArgThingHelper more powerful.
868         (JSC::B3::Air::ArgThingHelper<Arg>::forEach):
869         (JSC::B3::Air::ArgThingHelper<Reg>::is):
870         (JSC::B3::Air::ArgThingHelper<Reg>::as):
871         (JSC::B3::Air::ArgThingHelper<Reg>::forEachFast):
872         (JSC::B3::Air::ArgThingHelper<Reg>::forEach):
873         (JSC::B3::Air::Arg::is):
874         * b3/air/AirDumpAsJS.cpp: Added.
875         (JSC::B3::Air::dumpAsJS):
876         * b3/air/AirDumpAsJS.h: Added.
877         * b3/air/AirFixObviousSpills.cpp:
878         * b3/air/AirGenerate.cpp:
879         (JSC::B3::Air::prepareForGeneration):
880         * b3/air/AirInstInlines.h:
881         (JSC::B3::Air::Inst::forEach):
882         (JSC::B3::Air::Inst::extraClobberedRegs):
883         (JSC::B3::Air::ForEach<Tmp>::forEach): Deleted. This was doing what ArgThingHelper would have done but not as well.
884         (JSC::B3::Air::ForEach<Arg>::forEach): Deleted.
885         (JSC::B3::Air::ForEach<Reg>::forEach): Deleted.
886         * b3/air/AirLogRegisterPressure.cpp:
887         * b3/air/AirReportUsedRegisters.cpp:
888         * b3/air/AirSpillEverything.cpp:
889         * b3/air/opcode_generator.rb: Make this dump opcode.js, which is like what it dumps for C++.
890         * jit/Reg.cpp:
891         (JSC::Reg::debugName):
892         (JSC::Reg::dump):
893         * jit/Reg.h:
894         (JSC::Reg::hash):
895         * jsc.cpp: Fix jsc so that it reports the filename and line number of parser errors.
896         (dumpException):
897         * parser/ParserError.h: Make it easier to debug this code.
898         (WTF::printInternal):
899         * runtime/Options.h:
900
901 2016-06-07  Keith Rollin  <krollin@apple.com>
902
903         Remove all uses of PassRefPtr in WTF
904         https://bugs.webkit.org/show_bug.cgi?id=157596
905         <rdar://problem/26234391>
906
907         Reviewed by Chris Dumez.
908
909         Update calls to interfaces that no longer take or return PassRefPtrs.
910
911         * runtime/JSString.cpp:
912         (JSC::JSRopeString::resolveRope):
913         * runtime/JSString.h:
914         (JSC::JSString::JSString):
915         (JSC::jsSubstring):
916         * runtime/PrivateName.h:
917         (JSC::PrivateName::PrivateName):
918         * runtime/SmallStrings.cpp:
919         (JSC::SmallStringsStorage::SmallStringsStorage):
920         * runtime/StringConstructor.cpp:
921         (JSC::stringFromCharCodeSlowCase):
922         * runtime/StringPrototype.cpp:
923         (JSC::jsSpliceSubstrings):
924         (JSC::jsSpliceSubstringsWithSeparators):
925         (JSC::replaceUsingStringSearch):
926         (JSC::repeatCharacter):
927         (JSC::stringProtoFuncFontsize):
928         (JSC::stringProtoFuncLink):
929         (JSC::normalize):
930
931 2016-06-07  Saam barati  <sbarati@apple.com>
932
933         InvalidationPointInjectionPhase creates bogus InvalidationPoints that may even be inserted when it's not OK to exit
934         https://bugs.webkit.org/show_bug.cgi?id=158499
935         <rdar://problem/26647473>
936
937         Reviewed by Mark Lam and Benjamin Poulain.
938
939         InvalidationPointInjectionPhase forgot to clear m_originThatHadFire 
940         before analyzing the current block it's analyzing. This meant that
941         the phase allowed a residual m_originThatHadFire that was set from the
942         previous block to effect a completely unrelated block. This is usually
943         harmless, but sometimes we would insert an InvalidationPoint at a point
944         in the graph when exiting is invalid. This would cause a crash.
945
946         * dfg/DFGInvalidationPointInjectionPhase.cpp:
947         (JSC::DFG::InvalidationPointInjectionPhase::run):
948         * tests/stress/dont-crash-on-bad-invalidation-point.js: Added.
949         (dontCrash):
950
951 2016-06-07  Saam Barati  <sbarati@apple.com>
952
953         operationProcessTypeProfilerLogDFG doesn't update topCallFrame
954         https://bugs.webkit.org/show_bug.cgi?id=158428
955         <rdar://problem/26571493>
956
957         Reviewed by Mark Lam.
958
959         * dfg/DFGOperations.cpp:
960
961 2016-06-07  Mark Lam  <mark.lam@apple.com>
962
963         calculatedDisplayName() and friends actually need a VM& and not a ExecState/CallFrame.
964         https://bugs.webkit.org/show_bug.cgi?id=158488
965
966         Reviewed by Geoffrey Garen.
967
968         calculatedDisplayName() (and some of its friends) actually just need a VM&.
969         Their work has nothing to do with an ExecState at all.  This patch will make that
970         clear by changing these functions to take a VM& arg instead of an ExecState* or
971         CallFrame*.
972
973         Also removed the JS_EXPORT_PRIVATE attribute from Interpreter::StackFrame::toString().
974         The JS_EXPORT_PRIVATE attribute was a holdover from the days when WebInspector
975         was entirely in WebCore.  It is no longer needed.
976
977         * debugger/DebuggerCallFrame.cpp:
978         (JSC::DebuggerCallFrame::functionName):
979         * inspector/JSInjectedScriptHost.cpp:
980         (Inspector::JSInjectedScriptHost::functionDetails):
981         * inspector/ScriptCallStackFactory.cpp:
982         (Inspector::createScriptCallStackFromException):
983         * interpreter/CallFrame.cpp:
984         (JSC::CallFrame::friendlyFunctionName):
985         * interpreter/Interpreter.cpp:
986         (JSC::StackFrame::friendlySourceURL):
987         (JSC::StackFrame::friendlyFunctionName):
988         (JSC::StackFrame::expressionInfo):
989         (JSC::StackFrame::toString):
990         (JSC::Interpreter::stackTraceAsString):
991         * interpreter/Interpreter.h:
992         * interpreter/StackVisitor.cpp:
993         (JSC::StackVisitor::Frame::functionName):
994         * runtime/InternalFunction.cpp:
995         (JSC::InternalFunction::name):
996         (JSC::InternalFunction::displayName):
997         (JSC::InternalFunction::getCallData):
998         (JSC::InternalFunction::calculatedDisplayName):
999         * runtime/InternalFunction.h:
1000         (JSC::InternalFunction::createStructure):
1001         * runtime/JSFunction.cpp:
1002         (JSC::JSFunction::name):
1003         (JSC::JSFunction::displayName):
1004         (JSC::JSFunction::calculatedDisplayName):
1005         (JSC::JSFunction::getConstructData):
1006         (JSC::getCalculatedDisplayName):
1007         * runtime/JSFunction.h:
1008         (JSC::JSFunction::executable):
1009         * runtime/JSObject.cpp:
1010         (JSC::JSObject::calculatedClassName):
1011
1012 2016-06-07  Yusuke Suzuki  <utatane.tea@gmail.com>
1013
1014         [JSC] Do not allocate unnecessary UTF-8 string for encodeXXX functions
1015         https://bugs.webkit.org/show_bug.cgi?id=158416
1016
1017         Reviewed by Darin Adler and Geoffrey Garen.
1018
1019         Previously, encodeXXX functions first allocate new UTF-8 string, and generate (& allocate) the results from this UTF-8 string.
1020         It is costly since this UTF-8 string is always wasted. In this patch, we generate the results without this UTF-8 string.
1021         We precisely implement ECMA262's Encode abstract operation[1].
1022
1023         This optimized encodeXXX functions provide great improvement in kraken stanford-crypto-sha256-iterative since it frequently calls
1024         these functions. We can see 6 - 7% improvements.
1025
1026                                                       baseline                  patched
1027
1028         stanford-crypto-sha256-iterative           37.952+-0.155      ^      35.484+-0.265         ^ definitely 1.0695x faster
1029
1030
1031         [1]: https://tc39.github.io/ecma262/#sec-encode
1032
1033         * runtime/JSGlobalObjectFunctions.cpp:
1034         (JSC::toSafeView):
1035         Use this helper function to retrieve JSString::SafeView.
1036
1037         (JSC::makeCharacterBitmap):
1038         (JSC::encode):
1039         In encode, we reserve N length buffer at first. This is important when the length of the given string is long enough,
1040         preventing frequent unnecessary buffer reallocations. This reserving contributes to 1% kraken stanford-crypto-sha256-iterative progression.
1041
1042         (JSC::decode):
1043         Previously, Bitmap accidentally includes \0. And instead of removing this \0, we checked character != 0.
1044         This patch fixes it for the Bitmap not to include \0.
1045
1046         (JSC::globalFuncParseInt):
1047         (JSC::globalFuncEscape):
1048         (JSC::globalFuncUnescape):
1049         * tests/stress/encode-decode-ascii.js: Added.
1050         (shouldBe):
1051         * tests/stress/encode-decode-unicode.js: Added.
1052         (shouldBe):
1053         (isLowSurrogate):
1054         (isHighSurrogate):
1055         (isSurrogate):
1056         * tests/stress/encode-decode-uri-component-surrogates.js: Added.
1057         (shouldBe):
1058         (toHighSurrogate):
1059         (toLowSurrogate):
1060         * tests/stress/encode-decode-uri-surrogates.js: Added.
1061         (shouldBe):
1062         (toHighSurrogate):
1063         (toLowSurrogate):
1064         * tests/stress/encode-decode-zero.js: Added.
1065         (shouldBe):
1066         * tests/stress/escape-unescape-surrogates.js: Added.
1067         (shouldBe):
1068         (toHighSurrogate):
1069         (toLowSurrogate):
1070
1071 2016-06-07  Ting-Wei Lan  <lantw44@gmail.com>
1072
1073         [GTK] Include locale.h before using LC_ALL
1074         https://bugs.webkit.org/show_bug.cgi?id=158470
1075
1076         Reviewed by Darin Adler.
1077
1078         * jsc.cpp:
1079
1080 2016-06-07  Joseph Pecoraro  <pecoraro@apple.com>
1081
1082         Unskip generator related stress tests
1083         https://bugs.webkit.org/show_bug.cgi?id=158461
1084
1085         Reviewed by Darin Adler.
1086
1087         * tests/stress/generator-methods.js:
1088         * tests/stress/generator-syntax.js:
1089         * tests/stress/yield-and-line-terminator.js:
1090         * tests/stress/yield-label-generator.js:
1091         * tests/stress/yield-named-accessors-generator.js:
1092         * tests/stress/yield-named-variable-generator.js:
1093         * tests/stress/yield-out-of-generator.js:
1094
1095 2016-06-06  Joseph Pecoraro  <pecoraro@apple.com>
1096
1097         Fix typo in test name trailing-comma-in-function-paramters.js
1098         https://bugs.webkit.org/show_bug.cgi?id=158462
1099
1100         Reviewed by Mark Lam.
1101
1102         * tests/stress/trailing-comma-in-function-parameters.js: Renamed from Source/JavaScriptCore/tests/stress/trailing-comma-in-function-paramters.js.
1103
1104 2016-06-06  Andreas Kling  <akling@apple.com>
1105
1106         REGRESSION(r197595): 2% JSBench regression on iPhone 5.
1107         <https://webkit.org/b/158459>
1108
1109         Unreviewed rollout.
1110
1111         * runtime/VM.cpp:
1112         (JSC::VM::deleteAllRegExpCode): Deleted.
1113         * runtime/VM.h:
1114
1115 2016-06-06  Michael Saboff  <msaboff@apple.com>
1116
1117         octal and binary parsing is wrong for some programs
1118         https://bugs.webkit.org/show_bug.cgi?id=158437
1119
1120         Reviewed by Saam Barati.
1121
1122         When there is an error parsing an binary or octal literal, we need to clear the returnValue
1123         of any residual value.  This is because the processing of returnValue happens before the
1124         syntax check for the extra character.  Without clearing returnValue, we end trying to
1125         categorize the value as an INTEGER or DOUBLE token.  If the value happens to be an
1126         impure NaN, we ASSERT.
1127
1128         * parser/Lexer.cpp:
1129         (JSC::Lexer<T>::parseBinary):
1130         (JSC::Lexer<T>::parseOctal):
1131         * tests/stress/regress-158437.js: New test.
1132
1133 2016-06-06  Mark Lam  <mark.lam@apple.com>
1134
1135         32-bit JSC stress test failing: stress/recursive-try-catch.js.ftl-no-cjit-validate-sampling-profiler
1136         https://bugs.webkit.org/show_bug.cgi?id=158362
1137
1138         Reviewed by Michael Saboff.
1139
1140         The test does infinite recursion until it overflows the stack.  That means the
1141         sampling profiler will have to capture excessively large samples, which in turn
1142         makes it run very slowly.  This is what causes the test time out.
1143
1144         The fix is to not run the test with the sampling profiler.
1145
1146         * tests/stress/recursive-try-catch.js:
1147
1148 2016-06-06  Andreas Kling  <akling@apple.com>
1149
1150         Don't reportAbandonedObjectGraph() after throwing out linked code or RegExps.
1151         <https://webkit.org/b/158444>
1152
1153         Unreviewed.
1154
1155         This is a speculative change for iOS performance bots. The calls to reportAbandonedObjectGraph
1156         were basically redundant, since mainframe navigation will cause GC acceleration anyway via
1157         ScriptController.
1158
1159         This appears successful at recovering the ~0.7% regression I could reproduce locally on newer
1160         hardware but it's a bit too noisy to say for sure.
1161
1162         * runtime/VM.cpp:
1163         (JSC::VM::deleteAllLinkedCode):
1164         (JSC::VM::deleteAllRegExpCode):
1165
1166 2016-06-06  Skachkov Oleksandr  <gskachkov@gmail.com>
1167         [ESNext] Trailing commas in function parameters.
1168         https://bugs.webkit.org/show_bug.cgi?id=158020
1169
1170         Reviewed by Keith Miller.
1171
1172         ESNext allow to add trailing commas in function parameters and function arguments.
1173         Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
1174         Example of using - (function (a, b,) { return a + b; })(1,2,);
1175
1176         * parser/Parser.cpp:
1177         (JSC::Parser<LexerType>::parseFormalParameters):
1178         (JSC::Parser<LexerType>::parseArguments):
1179         * tests/stress/trailing-comma-in-function-paramters.js: Added.
1180
1181 2016-06-05  Gavin & Ellie Barraclough  <barraclough@apple.com>
1182
1183         Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead.
1184         https://bugs.webkit.org/show_bug.cgi?id=158178
1185
1186         Reviewed by Darin Adler.
1187
1188         As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be
1189         overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism.
1190
1191         Deprecate getStatic* functions in Lookup.h
1192
1193         * runtime/Lookup.h:
1194         (JSC::getStaticPropertySlot): Deleted.
1195         (JSC::getStaticFunctionSlot): Deleted.
1196         (JSC::getStaticValueSlot): Deleted.
1197             - No longer required. Static table access now via JSObject.
1198
1199 2016-06-06  Guillaume Emont  <guijemont@igalia.com>
1200
1201         [jsc][mips] Implement absDouble()
1202         https://bugs.webkit.org/show_bug.cgi?id=158206
1203
1204         Reviewed by Mark Lam.
1205
1206         Implement absDouble() for MIPS. This is needed because Math.pow() uses
1207         it since r200208.
1208
1209         * assembler/MIPSAssembler.h:
1210         (JSC::MIPSAssembler::absd):
1211         * assembler/MacroAssemblerMIPS.h:
1212         (JSC::MacroAssemblerMIPS::absDouble):
1213
1214 2016-06-03  Oliver Hunt  <oliver@apple.com>
1215
1216         RegExp unicode parsing reads an extra character before failing
1217         https://bugs.webkit.org/show_bug.cgi?id=158376
1218
1219         Reviewed by Saam Barati.
1220
1221         This was a probably harmless bug, but keeps triggering assertions
1222         for me locally. Essentially we'd see a parse error, set the error
1223         type, but then carry on parsing. In debug builds this asserts, in
1224         release builds you are pretty safe unless you're exceptionally
1225         unlucky with where the error occurs.
1226
1227         * yarr/YarrParser.h:
1228         (JSC::Yarr::Parser::parseEscape):
1229
1230 2016-06-06  Guillaume Emont  <guijemont@igalia.com>
1231
1232         [jsc][mips] fix JIT::emit_op_log_shadow_chicken_prologue/_tail
1233         https://bugs.webkit.org/show_bug.cgi?id=158209
1234
1235         Reviewed by Mark Lam.
1236
1237         On MIPS, changes GPRInfo::nonArgGPR0 to be regT4 instead of regT0,
1238         since the code of JIT::emit_op_log_shadow_chicken_prologue/_tail()
1239         expects nonArgGPR0 to be a different register from regT0 and regT2.
1240
1241         * jit/GPRInfo.h:
1242
1243 2016-06-06  Chris Dumez  <cdumez@apple.com>
1244
1245         Crash under JSObject::getOwnPropertyDescriptor()
1246         https://bugs.webkit.org/show_bug.cgi?id=158382
1247         <rdar://problem/26605004>
1248
1249         Reviewed by Mark Lam.
1250
1251         * runtime/JSObject.h:
1252         (JSC::JSObject::putDirectInternal):
1253         We were crashing under getOwnPropertyDescriptor() because the
1254         CustomAccessor was not properly reset on window.statusbar when
1255         setting it to false (which is allowed because the property is
1256         marked as [Replaceable] in the IDL). We now property reset the
1257         CustomAccessor flag in putDirectInternal() when needed. This
1258         fixes the crash.
1259
1260 2016-06-06  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
1261
1262         [EFL] Move efl include paths to JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
1263         https://bugs.webkit.org/show_bug.cgi?id=158418
1264
1265         Reviewed by Csaba Osztrogon√°c.
1266
1267         In Source/JavaScriptCore/PlatformEfl.cmake, we don't use JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
1268         for efl include paths.
1269
1270         * PlatformEfl.cmake:
1271         * tests/stress/encode-decode-ascii.js: Added.
1272         (shouldBe):
1273         * tests/stress/encode-decode-unicode.js: Added.
1274         (shouldBe):
1275         (isLowSurrogate):
1276         (isHighSurrogate):
1277         (isSurrogate):
1278         * tests/stress/encode-decode-uri-component-surrogates.js: Added.
1279         (shouldBe):
1280         (toHighSurrogate):
1281         (toLowSurrogate):
1282         * tests/stress/encode-decode-uri-surrogates.js: Added.
1283         (shouldBe):
1284         (toHighSurrogate):
1285         (toLowSurrogate):
1286         * tests/stress/encode-decode-zero.js: Added.
1287         (shouldBe):
1288         * tests/stress/escape-unescape-surrogates.js: Added.
1289         (shouldBe):
1290         (toHighSurrogate):
1291         (toLowSurrogate):
1292
1293 2016-06-05  Yusuke Suzuki  <utatane.tea@gmail.com>
1294
1295         Change ProxyObject.[[Get]] not to use custom accessor
1296         https://bugs.webkit.org/show_bug.cgi?id=157080
1297
1298         Reviewed by Darin Adler.
1299
1300         This patch focuses on introducing the second part of the followings.
1301         But to do so, first and third parts are necessary.
1302
1303         1. Insert missing exception checks for getPropertySlot.
1304
1305             While getPropertySlot can perform user-observable behavior if the slot is not VMInquiry,
1306             several places miss exeption checks. For example, ProxyObject's hasProperty already can
1307             throw any errors. Looking through the code, we found several missing error checks after
1308             hasProperty, but this will be fixed in the separated patch[1].
1309
1310         2. Do not use custom accessor to implement ProxyObject's [[Get]].
1311
1312             The caller already allows getOwnPropertySlot to throw an exception if the type
1313             is not VMInquiry. So instead of using custom accessor, we simply implement it
1314             directly in the ProxyObject's method.
1315
1316         3. Strip slotBase from custom accessor.
1317
1318             The custom accessor should not be bound to the specific slot base[2], since it
1319             is just an accessor. There is an alternative design: makeing this custom accessor
1320             to custom value accessor and accept both the slot base and the receiver instead
1321             of allowing throwing an error from getOwnPropertySlot. But we take the first design
1322             that allows getPropertySlot to throw an error, since hasProperty (that does not call
1323             getValue of the custom getters) can already throw any errors.
1324
1325             To query the property with the non-user-observable way, we already provided the way for that:
1326             use VMInquiry and isTaintedByProxy() instead.
1327
1328         Tests just ensure that the current semantics works correctly after this patch.
1329         And this patch is performance neutral.
1330
1331         Later, we will attempt to rename "thisValue" to "receiver"[3].
1332
1333         [1]: https://bugs.webkit.org/show_bug.cgi?id=158398
1334         [2]: https://bugs.webkit.org/show_bug.cgi?id=157978
1335         [3]: https://bugs.webkit.org/show_bug.cgi?id=158397
1336
1337         * API/JSCallbackObject.h:
1338         * API/JSCallbackObjectFunctions.h:
1339         (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
1340         (JSC::JSCallbackObject<Parent>::callbackGetter):
1341         * bytecode/PolymorphicAccess.cpp:
1342         (JSC::AccessCase::generateImpl):
1343         * dfg/DFGOperations.cpp:
1344         * interpreter/Interpreter.cpp:
1345         (JSC::Interpreter::execute):
1346         * jit/JITOperations.cpp:
1347         * jsc.cpp:
1348         (WTF::ImpureGetter::getOwnPropertySlot):
1349         (WTF::CustomGetter::customGetter):
1350         (WTF::RuntimeArray::lengthGetter):
1351         (GlobalObject::finishCreation):
1352         (GlobalObject::moduleLoaderFetch):
1353         (functionGetGetterSetter):
1354         (functionRun):
1355         (functionLoad):
1356         (functionLoadString):
1357         (functionReadFile):
1358         (functionCheckSyntax):
1359         (functionLoadWebAssembly):
1360         (functionLoadModule):
1361         (functionCreateBuiltin):
1362         (functionCheckModuleSyntax):
1363         (dumpException):
1364         (runWithScripts):
1365         (runInteractive):
1366         * llint/LLIntSlowPaths.cpp:
1367         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1368         * runtime/CommonSlowPaths.cpp:
1369         (JSC::SLOW_PATH_DECL):
1370         * runtime/JSBoundSlotBaseFunction.cpp:
1371         (JSC::boundSlotBaseFunctionCall):
1372         * runtime/JSCJSValue.h:
1373         * runtime/JSCJSValueInlines.h:
1374         (JSC::JSValue::getPropertySlot):
1375         * runtime/JSCellInlines.h:
1376         (JSC::ExecState::vm):
1377         This change is super important for performance. We add several `exec->hadException()` calls into the super hot path, like JSC::operationGetByIdOptimize.
1378         Without this change, we call ExecState::vm() and it is not inlined. This causes 1 - 2% performance regression in Octane PDFJS.
1379
1380         * runtime/JSFunction.cpp:
1381         (JSC::JSFunction::argumentsGetter):
1382         (JSC::JSFunction::callerGetter):
1383         * runtime/JSFunction.h:
1384         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1385         (JSC::constructGenericTypedArrayViewWithArguments):
1386         * runtime/JSModuleNamespaceObject.cpp:
1387         (JSC::callbackGetter):
1388         * runtime/JSONObject.cpp:
1389         (JSC::Stringifier::Holder::appendNextProperty):
1390         Here's UNLIKELY is important for Kraken's json-stringify-tinderbox. Without it, we can observe 0.5% regression.
1391
1392         (JSC::Walker::walk):
1393         * runtime/JSObject.h:
1394         (JSC::JSObject::getPropertySlot):
1395         * runtime/ObjectPrototype.cpp:
1396         (JSC::objectProtoFuncToString):
1397         * runtime/PropertySlot.cpp:
1398         (JSC::PropertySlot::customGetter):
1399         * runtime/PropertySlot.h:
1400         (JSC::PropertySlot::thisValue):
1401         * runtime/ProxyObject.cpp:
1402         (JSC::performProxyGet):
1403         (JSC::ProxyObject::performGet):
1404         (JSC::ProxyObject::getOwnPropertySlotCommon):
1405         * runtime/ProxyObject.h:
1406         * runtime/RegExpConstructor.cpp:
1407         (JSC::regExpConstructorDollar):
1408         (JSC::regExpConstructorInput):
1409         (JSC::regExpConstructorMultiline):
1410         (JSC::regExpConstructorLastMatch):
1411         (JSC::regExpConstructorLastParen):
1412         (JSC::regExpConstructorLeftContext):
1413         (JSC::regExpConstructorRightContext):
1414         * tests/stress/get-from-scope-dynamic-onto-proxy.js: Added.
1415         (shouldBe):
1416         (shouldThrow.handler.has):
1417         (handler.has):
1418         (try.handler.has):
1419         * tests/stress/operation-in-throw-error.js: Added.
1420         (testCase.handler.has):
1421         (testCase):
1422         * tests/stress/proxy-and-json-stringify.js: Added.
1423         (shouldThrow):
1424         * tests/stress/proxy-and-typed-array.js: Added.
1425         * tests/stress/proxy-json-path.js: Added.
1426         * tests/stress/proxy-with-statement.js: Added.
1427
1428 2016-06-03  Gavin & Ellie Barraclough  <barraclough@apple.com>
1429
1430         Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead.
1431         https://bugs.webkit.org/show_bug.cgi?id=158178
1432
1433         Reviewed by Darin Adler.
1434
1435         As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be
1436         overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism.
1437
1438         Part 1: Switch JSGlobalObject & JSDOMWindow to use HasStaticPropertyTable.
1439
1440         * runtime/JSGlobalObject.cpp:
1441         (JSC::JSGlobalObject::getOwnPropertySlot):
1442             - Override is still required for symbol table,
1443               but regular property access is now via Base::getOwnPropertySlot.
1444         * runtime/JSGlobalObject.h:
1445             - add HasStaticPropertyTable to structureFlags.
1446
1447 2016-06-03  Benjamin Poulain  <bpoulain@apple.com>
1448
1449         Eager FTL failure for strict comparison of NaN with number check
1450         https://bugs.webkit.org/show_bug.cgi?id=158368
1451
1452         Reviewed by Darin Adler.
1453
1454         DoupleRep with a RealNumberUse starts by handling double
1455         then falls back to Int32 if the unboxed double is NaN.
1456
1457         Before handling integers, the code is checking if the input
1458         is indeed an int32. The problem was that this check failed
1459         to account for NaN as an original input of the DoubleRep.
1460
1461         The call to isNotInt32() filter the doubles checks because
1462         that was handled by the previous block.
1463         The problem is the previous block handles any double except NaN.
1464         If the original input was NaN, the masking by "~SpecFullDouble"
1465         filter that possibility and isNotInt32() fails to test that case.
1466
1467         This patch fixes the issue by changing the filter to SpecDoubleReal.
1468         The type SpecDoubleReal does not include the NaN types.
1469
1470         * ftl/FTLLowerDFGToB3.cpp:
1471         (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
1472         * tests/stress/double-rep-real-number-use-on-nan.js: Added.
1473         To ensure the isNotInt32() does not test anything, we want
1474         proven numbers as input. The (+value) are there to enforce
1475         a ToNumber() which in turn give us a proven Number type.
1476
1477 2016-06-03  Benjamin Poulain  <bpoulain@apple.com>
1478
1479         JSON.stringify replacer function calls with numeric array indices
1480         https://bugs.webkit.org/show_bug.cgi?id=158262
1481         rdar://problem/26613876
1482
1483         Reviewed by Saam Barati.
1484
1485         The spec of SerializeJSONArray is pretty clear that the index
1486         should be transformed into a string before calling SerializeJSONProperty.
1487         See http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray
1488
1489         * runtime/JSONObject.cpp:
1490         (JSC::PropertyNameForFunctionCall::value):
1491
1492 2016-06-03  Saam barati  <sbarati@apple.com>
1493
1494         Proxy.ownKeys should no longer throw an exception when duplicate keys are returned and the target is non-extensible
1495         https://bugs.webkit.org/show_bug.cgi?id=158350
1496         <rdar://problem/26626211>
1497
1498         Reviewed by Michael Saboff.
1499
1500         The spec was recently changes in Proxy [[OwnPropertyKeys]]
1501         to allow for duplicate property names under certain circumstances.
1502         This patch fixes our implementation to match the spec.
1503         See: https://github.com/tc39/ecma262/pull/594
1504
1505         * runtime/ProxyObject.cpp:
1506         (JSC::ProxyObject::performGetOwnPropertyNames):
1507         * tests/stress/proxy-own-keys.js:
1508         (i.catch):
1509         (ownKeys):
1510         (assert):
1511
1512 2016-06-03  Saam barati  <sbarati@apple.com>
1513
1514         Some shadow chicken code is wrong when run on a big endian CPU
1515         https://bugs.webkit.org/show_bug.cgi?id=158361
1516
1517         Reviewed by Mark Lam.
1518
1519         This code was wrong on a big endian CPU, and it was
1520         also an anti-pattern in the file. The code was harmless
1521         on a little endian CPU, but it's better to remove it.
1522
1523         * llint/LowLevelInterpreter64.asm:
1524
1525 2016-06-03  Keith Miller  <keith_miller@apple.com>
1526
1527         Add argument_count bytecode for concat
1528         https://bugs.webkit.org/show_bug.cgi?id=158358
1529
1530         Reviewed by Geoffrey Garen.
1531
1532         This patch adds a new argument count bytecode. Normally, we would
1533         just make sure that the argument.length bytecode was fast enough
1534         that we shouldn't need such an bytecode.  However, for the case of
1535         Array.prototype.concat the overhead of the arguments object
1536         allocation in the LLInt was too high and caused regressions.
1537
1538         * bytecode/BytecodeIntrinsicRegistry.h:
1539         * bytecode/BytecodeList.json:
1540         * bytecode/BytecodeUseDef.h:
1541         (JSC::computeUsesForBytecodeOffset):
1542         (JSC::computeDefsForBytecodeOffset):
1543         * bytecode/CodeBlock.cpp:
1544         (JSC::CodeBlock::dumpBytecode):
1545         * bytecompiler/NodesCodegen.cpp:
1546         (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
1547         * dfg/DFGByteCodeParser.cpp:
1548         (JSC::DFG::ByteCodeParser::getArgumentCount):
1549         (JSC::DFG::ByteCodeParser::parseBlock):
1550         * dfg/DFGCapabilities.cpp:
1551         (JSC::DFG::capabilityLevel):
1552         * jit/JIT.cpp:
1553         (JSC::JIT::privateCompileMainPass):
1554         * jit/JIT.h:
1555         * jit/JITOpcodes.cpp:
1556         (JSC::JIT::emit_op_argument_count):
1557         * llint/LowLevelInterpreter32_64.asm:
1558         * llint/LowLevelInterpreter64.asm:
1559         * tests/stress/argument-count-bytecode.js: Added.
1560         (inlineCount):
1561         (inlineCount1):
1562         (inlineCount2):
1563         (inlineCountVarArgs):
1564         (assert):
1565
1566 2016-06-03  Geoffrey Garen  <ggaren@apple.com>
1567
1568         Clients of PolymorphicAccess::addCases shouldn't have to malloc
1569         https://bugs.webkit.org/show_bug.cgi?id=158357
1570
1571         Reviewed by Keith Miller.
1572
1573         We only ever have 1 or 2 cases, so we can use inline Vector capacity.
1574
1575         This shows up a little in the JSBench profile.
1576
1577         * bytecode/PolymorphicAccess.cpp:
1578         (JSC::PolymorphicAccess::addCases):
1579         (JSC::PolymorphicAccess::addCase):
1580         * bytecode/PolymorphicAccess.h:
1581         * bytecode/StructureStubInfo.cpp:
1582         (JSC::StructureStubInfo::addAccessCase):
1583
1584 2016-06-03  Benjamin Poulain  <bpoulain@apple.com>
1585
1586         Fix some more INFINITI->INFINITY typos
1587
1588         Unreviewed.
1589
1590         The tests were not covering the edge cases they were supposed to test.
1591
1592         * tests/stress/math-ceil-basics.js:
1593         (testMathCeilOnConstants):
1594         * tests/stress/math-clz32-basics.js:
1595         (testMathClz32OnDoubles):
1596         (testMathClz32OnConstants):
1597         * tests/stress/math-floor-basics.js:
1598         (testMathFloorOnConstants):
1599         * tests/stress/math-round-basics.js:
1600         (testMathRoundOnConstants):
1601         * tests/stress/math-trunc-basics.js:
1602         (testMathTruncOnConstants):
1603
1604 2016-06-02  Gavin & Ellie Barraclough  <barraclough@apple.com>
1605
1606         JSGlobalObject::addFunction should call deleteProperty rather than removeDirect
1607         https://bugs.webkit.org/show_bug.cgi?id=158295
1608
1609         Reviewed by Saam Barati.
1610
1611         When a function in declared in program code, this replaces any previosly existing
1612         property from the global object. JSGlobalObject::addFunction is currently calling
1613         removeDirect rather than deleteProperty to remove the existing property. This fails
1614         to remove any properties from static tables.
1615
1616         We currently get away with this because (a) JSObject & JSGlobalObject don't currently
1617         have any properties in static tables, and (b) the current quirky property precedence
1618         means that the symbol table properties end up taking precedence over JSDOMWindow's
1619         static table, so window object properties end up being shadowed.
1620
1621         As a part of bug #158178 the precedence of static tables will change, requiring this
1622         to be fixed.
1623
1624         The deleteProperty function does what we want (has the ability to remove properties,
1625         including those from the static tables). Normally deleteProperty will not remove
1626         properties that are non-configurable (DontDelete) - we need to do so. The function
1627         does already support this, through a flag on VM named 'isInDefineOwnProperty', which
1628         causes configurability to be ignored. Generalize this mechanism for use outside of
1629         defineOwnProperty, renaming & moving DefineOwnPropertyScope helper class out to VM.
1630
1631         * runtime/JSFunction.cpp:
1632         (JSC::JSFunction::deleteProperty):
1633             - isInDefineOwnProperty -> deletePropertyMode.
1634         * runtime/JSGlobalObject.cpp:
1635         (JSC::JSGlobalObject::addFunction):
1636             - removeDirect -> deleteProperty.
1637         * runtime/JSObject.cpp:
1638         (JSC::JSObject::deleteProperty):
1639             - isInDefineOwnProperty -> deletePropertyMode.
1640         (JSC::JSObject::defineOwnNonIndexProperty):
1641             - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
1642         (JSC::DefineOwnPropertyScope::DefineOwnPropertyScope): Deleted.
1643         (JSC::DefineOwnPropertyScope::~DefineOwnPropertyScope): Deleted.
1644             - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
1645         * runtime/VM.cpp:
1646         (JSC::VM::VM):
1647             - removed m_inDefineOwnProperty.
1648         * runtime/VM.h:
1649         (JSC::VM::deletePropertyMode):
1650             - isInDefineOwnProperty -> deletePropertyMode.
1651         (JSC::VM::DeletePropertyModeScope::DeletePropertyModeScope):
1652         (JSC::VM::DeletePropertyModeScope::~DeletePropertyModeScope):
1653             - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
1654         (JSC::VM::setInDefineOwnProperty): Deleted.
1655             - Replaced with deletePropertyMode, can now only be set via VM::DeletePropertyModeScope.
1656         (JSC::VM::isInDefineOwnProperty): Deleted.
1657             - isInDefineOwnProperty -> deletePropertyMode.
1658
1659 2016-06-03  Mark Lam  <mark.lam@apple.com>
1660
1661         ARMv7 vstm and vldm instructions can only operate on a maximum of 16 registers.
1662         https://bugs.webkit.org/show_bug.cgi?id=158349
1663
1664         Reviewed by Filip Pizlo.
1665
1666         According to the ARM Assembler Reference, the vstm and vldm instructions can only
1667         operate on a maximum of 16 registers.  See
1668         http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html
1669         and http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html.
1670
1671         The ARMv7 probe code was wrongly using these instructions to store and load all
1672         32 'd' registers.  This is now fixed.
1673
1674         * assembler/MacroAssemblerARMv7.cpp:
1675
1676 2016-06-03  Mark Lam  <mark.lam@apple.com>
1677
1678         Gardening: CLOOP build fix (needs a #include).
1679
1680         Not reviewed.
1681
1682         * interpreter/StackVisitor.h:
1683
1684 2016-06-03  Andreas Kling  <akling@apple.com>
1685
1686         Eliminate two large sources of temporary StringImpl objects.
1687         <https://webkit.org/b/158336>
1688
1689         Reviewed by Anders Carlsson.
1690
1691         We were jumping through some inefficient hoops when creating Identifiers due to the
1692         convenience of our String(const char*) constructor.
1693
1694         This patch avoids just over 1 million temporary StringImpl objects on the PLUM benchmark.
1695
1696         * runtime/JSObject.h:
1697         (JSC::makeIdentifier): Add an overload for string literals so we can stop creating a temporary
1698         String just for passing to Identifier::fromString().
1699
1700         * runtime/Lookup.h:
1701         (JSC::reifyStaticProperties): Use the Identifier::fromString() that takes an LChar* and a length
1702         instead of creating a temporary String.
1703
1704 2016-06-03  Mark Lam  <mark.lam@apple.com>
1705
1706         Clean up how StackVisitor dumps its frames.
1707         https://bugs.webkit.org/show_bug.cgi?id=158316
1708
1709         Reviewed by Keith Miller.
1710
1711         1. Updated to do dumping to a PrintStream.
1712         2. Added support for printing a prefix for each frame.
1713            This is currently used by JSDollarVMPrototype to print frame numbers.
1714         3. Fix the incrementing of the frame index in StackVisitor.
1715            It was initialized but never incremented before when iterating the frames.
1716
1717         * interpreter/StackVisitor.cpp:
1718         (JSC::StackVisitor::gotoNextFrame):
1719         (JSC::StackVisitor::Frame::codeType):
1720         (JSC::StackVisitor::Frame::functionName):
1721         (JSC::StackVisitor::Frame::sourceURL):
1722         (JSC::StackVisitor::Frame::toString):
1723         (JSC::StackVisitor::Frame::createArguments):
1724         (JSC::StackVisitor::Frame::computeLineAndColumn):
1725         (JSC::StackVisitor::Frame::retrieveExpressionInfo):
1726         (JSC::StackVisitor::Frame::setToEnd):
1727         (JSC::StackVisitor::Frame::dump):
1728         (JSC::StackVisitor::Indent::dump):
1729         (JSC::printIndents): Deleted.
1730         (JSC::log): Deleted.
1731         (JSC::logF): Deleted.
1732         (JSC::StackVisitor::Frame::print): Deleted.
1733         * interpreter/StackVisitor.h:
1734         (JSC::StackVisitor::Indent::Indent):
1735         (JSC::StackVisitor::Indent::operator++):
1736         (JSC::StackVisitor::Indent::operator--):
1737         (JSC::StackVisitor::Frame::isJSFrame):
1738         (JSC::StackVisitor::Frame::isInlinedFrame):
1739         (JSC::StackVisitor::Frame::vmEntryFrame):
1740         (JSC::StackVisitor::Frame::callFrame):
1741         (JSC::StackVisitor::Frame::Frame):
1742         (JSC::StackVisitor::Frame::~Frame):
1743         * tools/JSDollarVMPrototype.cpp:
1744         (JSC::PrintFrameFunctor::operator()):
1745
1746 2016-06-02  Saam Barati  <sbarati@apple.com>
1747
1748         global lexical environment variables are not accessible through functions created using the function constructor
1749         https://bugs.webkit.org/show_bug.cgi?id=158319
1750
1751         Reviewed by Filip Pizlo.
1752
1753         When creating a function using the Function constructor, we were
1754         using the global object instead of the global lexical environment
1755         as the function's scope. We should be using the global lexical environment.
1756
1757         * runtime/FunctionConstructor.cpp:
1758         (JSC::constructFunctionSkippingEvalEnabledCheck):
1759         * tests/stress/function-constructor-reading-from-global-lexical-environment.js: Added.
1760         (assert):
1761         (test):
1762         (ClassTDZ):
1763
1764 2016-06-02  Oliver Hunt  <oliver@apple.com>
1765
1766         JS parser incorrectly handles invalid utf8 in error messages.
1767         https://bugs.webkit.org/show_bug.cgi?id=158128
1768
1769         Reviewed by Saam Barati.
1770
1771         The bug here was caused by us using PrintStream's toString method
1772         to produce the error message for a parse error, even though toString
1773         may produce a null string in the event of invalid utf8 that causes
1774         the error in first case. So when we try to create an error message
1775         containing the invalid character code, we set m_errorMessage to the
1776         null string, as that signals "no error" we don't stop parsing, and
1777         everything goes down hill from there.
1778
1779         Now we use the new toStringWithLatin1Fallback so that we can always
1780         produce an error message, even if it contains invalid unicode. We
1781         also add an additional fallback so that we can guarantee an error
1782         message is set even if we're given a null string. There's a debug
1783         mode assertion to prevent anyone accidentally attempting to clear
1784         the message via setErrorMessage.
1785
1786         * parser/Parser.cpp:
1787         (JSC::Parser<LexerType>::logError):
1788         * parser/Parser.h:
1789         (JSC::Parser::setErrorMessage):
1790
1791 2016-06-02  Saam Barati  <sbarati@apple.com>
1792
1793         Teach bytecode liveness about the debugger
1794         https://bugs.webkit.org/show_bug.cgi?id=158288
1795
1796         Reviewed by Filip Pizlo.
1797
1798         There was a bug where we wouldn't always keep the scope register
1799         on the stack when the debugger is enabled. The debugger always assumes
1800         it can read from the scope. The bug happened in OSR exit from the FTL.
1801         The FTL uses bytecode liveness for OSR exit. Bytecode liveness proved
1802         that the scope register was dead, so the FTL OSR exit wrote `undefined`
1803         into the scope's stack slot when OSR exiting to the baseline.
1804
1805         To fix this, I taught bytecode liveness' computeUsesForBytecodeOffset() that the
1806         scope is used by every instruction except op_enter. This causes the
1807         scope to be live-in at every instruction except op_enter.
1808
1809         * bytecode/BytecodeLivenessAnalysis.cpp:
1810         (JSC::blockContainsBytecodeOffset):
1811         (JSC::addAlwaysLiveLocals):
1812         (JSC::findBasicBlockForBytecodeOffset):
1813         (JSC::stepOverInstruction):
1814         (JSC::computeLocalLivenessForBytecodeOffset):
1815         (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
1816         * bytecode/UnlinkedCodeBlock.cpp:
1817         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1818         * tests/stress/shadow-chicken-reading-from-scope-after-ftl-osr-exit-bytecode-liveness.js: Added.
1819         (foo):
1820         (catch):
1821
1822 2016-06-02  Michael Saboff  <msaboff@apple.com>
1823
1824         REGRESSION(r200694): %ThrowTypeError% is not unique
1825         https://bugs.webkit.org/show_bug.cgi?id=158231
1826
1827         Reviewed by Joseph Pecoraro.
1828
1829         The ES6 standard in section 9.2.7.1 states that %ThrowTypeError% is unique.  This
1830         change reverts the handling of TypeError before r200694 and then rolls in
1831         throwTypeErrorGetterSetter() with the renamed throwTypeErrorArgumentsCalleeAndCallerGetterSetter().
1832
1833         * runtime/ClonedArguments.cpp:
1834         (JSC::ClonedArguments::getOwnPropertySlot):
1835         (JSC::ClonedArguments::materializeSpecials):
1836         * runtime/JSBoundFunction.cpp:
1837         (JSC::JSBoundFunction::finishCreation):
1838         (JSC::JSBoundFunction::visitChildren):
1839         * runtime/JSFunction.cpp:
1840         (JSC::getThrowTypeErrorGetterSetter):
1841         (JSC::JSFunction::callerGetter):
1842         (JSC::JSFunction::defineOwnProperty):
1843         * runtime/JSGlobalObject.cpp:
1844         (JSC::JSGlobalObject::init):
1845         (JSC::JSGlobalObject::visitChildren):
1846         * runtime/JSGlobalObject.h:
1847         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
1848         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
1849         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
1850         (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):
1851         (JSC::JSGlobalObject::moduleLoader):
1852         (JSC::JSGlobalObject::throwTypeErrorGetterSetter): Deleted.
1853         (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter): Deleted.
1854         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter): Deleted.
1855         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter): Deleted.
1856         * runtime/JSGlobalObjectFunctions.cpp:
1857         (JSC::globalFuncThrowTypeError):
1858         (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
1859         (JSC::globalFuncThrowTypeErrorCalleeAndCaller): Deleted.
1860         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode): Deleted.
1861         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext): Deleted.
1862         * runtime/JSGlobalObjectFunctions.h:
1863         * tests/stress/reflect-set.js:
1864
1865 2016-06-02  Michael Saboff  <msaboff@apple.com>
1866
1867         [iOS]: Some JSC stress tests fail running out of executable memory when the LLInt is disabled
1868         https://bugs.webkit.org/show_bug.cgi?id=158317
1869
1870         Reviewed by Saam Barati.
1871
1872         Updated these test to not run the "no-llint" variant when running on ARM machines.
1873
1874         * tests/stress/arrowfunction-lexical-bind-superproperty.js: Skip no-llint for ARM
1875         (testCase):
1876         * tests/stress/proxy-revoke.js: Skipp no-lint for ARM and ARM64
1877         (assert):
1878
1879 2016-06-02  Keith Miller  <keith_miller@apple.com>
1880
1881         Unreviewed, reland r201532. The associated regressions have been fixed
1882         by r201584.
1883
1884 2016-06-02  Filip Pizlo  <fpizlo@apple.com>
1885
1886         Use "= delete" for Locker(int) 
1887
1888         Rubber stamped by Saam Barati.
1889
1890         * runtime/ConcurrentJITLock.h:
1891         (JSC::ConcurrentJITLocker::ConcurrentJITLocker):
1892
1893 2016-06-02  Keith Miller  <keith_miller@apple.com>
1894
1895         ObjectPropertyCondition should have a isStillValidAssumingImpurePropertyWatchpoint function
1896         https://bugs.webkit.org/show_bug.cgi?id=158308
1897
1898         Reviewed by Filip Pizlo.
1899
1900         Recently, structureEnsuresValidityAssumingImpurePropertyWatchpoint was converted to check
1901         what should be isStillValidAssumingImpurePropertyWatchpoint. This patch fixes the API so
1902         it should work as expected. This patch also changes generateConditions in
1903         ObjectPropertyConditionSet to use isStillValidAssumingImpurePropertyWatchpoint.
1904
1905         * bytecode/ObjectPropertyCondition.cpp:
1906         (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
1907         (JSC::ObjectPropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
1908         * bytecode/ObjectPropertyCondition.h:
1909         * bytecode/ObjectPropertyConditionSet.cpp:
1910
1911 2016-06-02  Filip Pizlo  <fpizlo@apple.com>
1912
1913         Make it harder to accidentally pass an integer to a locker.
1914
1915         Rubber stamped by Keith Miller.
1916
1917         * runtime/ConcurrentJITLock.h:
1918         (JSC::ConcurrentJITLocker::ConcurrentJITLocker):
1919
1920 2016-06-02  Filip Pizlo  <fpizlo@apple.com>
1921
1922         Make it easier to use NoLockingNecessary
1923         https://bugs.webkit.org/show_bug.cgi?id=158306
1924
1925         Reviewed by Keith Miller.
1926         
1927         Adapt to the new NoLockingNecessary API. More details in the WTF ChangeLog.
1928
1929         * bytecompiler/BytecodeGenerator.cpp:
1930         (JSC::BytecodeGenerator::BytecodeGenerator):
1931         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1932         (JSC::BytecodeGenerator::instantiateLexicalVariables):
1933         (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
1934         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1935         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1936         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1937         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1938         (JSC::BytecodeGenerator::variable):
1939         (JSC::BytecodeGenerator::createVariable):
1940         (JSC::BytecodeGenerator::emitResolveScope):
1941         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
1942         * runtime/ConcurrentJITLock.h:
1943         (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
1944         (JSC::ConcurrentJITLocker::ConcurrentJITLocker):
1945
1946 2016-06-01  Filip Pizlo  <fpizlo@apple.com>
1947
1948         Structure::previousID() races with Structure::allocateRareData()
1949         https://bugs.webkit.org/show_bug.cgi?id=158280
1950
1951         Reviewed by Mark Lam.
1952         
1953         The problem is that previousID() would test hasRareData() and then either load the
1954         previous Structure from the rare data, or load it directly. allocateRareData() would set
1955         the hasRareData() bit separately from moving the Structure pointer into the rare data. So
1956         we'd have a race that would cause previousID() to sometimes return the rarae data instead
1957         of the previous Structure.
1958
1959         The fix is to get rid of the hasRareData bit. We can use the structureID of the
1960         previousOrRareData cell to determine if it's the previousID or the RareData. This fixes the
1961         race and it's probably not any slower.
1962
1963         * runtime/Structure.cpp:
1964         (JSC::Structure::Structure):
1965         (JSC::Structure::allocateRareData):
1966         * runtime/Structure.h:
1967
1968 2016-06-01  Michael Saboff  <msaboff@apple.com>
1969
1970         Runaway WebContent process CPU & memory @ foxnews.com
1971         https://bugs.webkit.org/show_bug.cgi?id=158290
1972
1973         Reviewed by Mark Lam.
1974
1975         Clear the thrown value at the end of the catch block so that the stack scanner won't
1976         find the value during GC.
1977
1978         Added a new stress test.
1979
1980         * bytecompiler/NodesCodegen.cpp:
1981         (JSC::TryNode::emitBytecode):
1982         * tests/stress/recursive-try-catch.js: Added.
1983         (logError):
1984         (tryCallingBadFunction):
1985         (recurse):
1986         (test):
1987
1988 2016-06-01  Benjamin Poulain  <bpoulain@apple.com>
1989
1990         [JSC] Some setters for components of Date do not timeClip() their result
1991         https://bugs.webkit.org/show_bug.cgi?id=158278
1992         rdar://problem/25131426
1993
1994         Reviewed by Geoffrey Garen.
1995
1996         Many of the setters where not doing timeClip() on the computed UTC
1997         time since Epoch.
1998
1999         See http://www.ecma-international.org/ecma-262/6.0/#sec-date.prototype.setdate
2000         and the following sections for the definition.
2001
2002         * runtime/DatePrototype.cpp:
2003         (JSC::setNewValueFromTimeArgs):
2004         (JSC::setNewValueFromDateArgs):
2005
2006 2016-06-01  Keith Miller  <keith_miller@apple.com>
2007
2008         canOptimizeStringObjectAccess should use ObjectPropertyConditions rather than structure watchpoints
2009         https://bugs.webkit.org/show_bug.cgi?id=158291
2010
2011         Reviewed by Benjamin Poulain.
2012
2013         The old StringObject primitive access code used structure watchpoints. This meant that
2014         if you set a watchpoint on String.prototype prior to tiering up to the DFG then added
2015         a new property to String.prototype then we would never use StringObject optimizations.
2016         This made property caching in the LLInt bad because it meant we would watchpoint
2017         String.prototype very early in the program, which hurt date-format-xpab.js since that
2018         benchmark relies on the StringObject optimizations.
2019
2020         This patch also extends ObjectPropertyConditionSet to be able to handle a slotBase
2021         equivalence condition. Since that makes the code for generating the DFG watchpoints
2022         significantly cleaner.
2023
2024         * bytecode/ObjectPropertyCondition.cpp:
2025         (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
2026         * bytecode/ObjectPropertyConditionSet.cpp:
2027         (JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition):
2028         (JSC::ObjectPropertyConditionSet::slotBaseCondition):
2029         (JSC::generateConditionsForPrototypeEquivalenceConcurrently):
2030         * bytecode/ObjectPropertyConditionSet.h:
2031         * dfg/DFGGraph.cpp:
2032         (JSC::DFG::Graph::isStringPrototypeMethodSane):
2033         (JSC::DFG::Graph::canOptimizeStringObjectAccess):
2034         * dfg/DFGGraph.h:
2035
2036 2016-06-01  Geoffrey Garen  <ggaren@apple.com>
2037
2038         Unreviewed, rolling in r201436.
2039         https://bugs.webkit.org/show_bug.cgi?id=158143
2040
2041         r201562 should haved fixed the Dromaeo DOM core regression.
2042
2043         Restored changeset:
2044
2045         "REGRESSION: JSBench spends a lot of time transitioning
2046         to/from dictionary"
2047         https://bugs.webkit.org/show_bug.cgi?id=158045
2048         http://trac.webkit.org/changeset/201436
2049
2050
2051 2016-06-01  Commit Queue  <commit-queue@webkit.org>
2052
2053         Unreviewed, rolling out r201488.
2054         https://bugs.webkit.org/show_bug.cgi?id=158268
2055
2056         Caused 23% regression on JetStream's crypto-md5 (Requested by
2057         rniwa on #webkit).
2058
2059         Reverted changeset:
2060
2061         "[ESNext] Support trailing commas in function param lists"
2062         https://bugs.webkit.org/show_bug.cgi?id=158020
2063         http://trac.webkit.org/changeset/201488
2064
2065 2016-05-31  Geoffrey Garen  <ggaren@apple.com>
2066
2067         Dictionary property access should be fast
2068         https://bugs.webkit.org/show_bug.cgi?id=158250
2069
2070         Reviewed by Keith Miller.
2071
2072         We have some remnant code that unnecessarily takes a slow path for
2073         dictionaries. This caused the Dromaeo regression in r201436. Let's fix
2074         that.
2075
2076         * jit/Repatch.cpp:
2077         (JSC::tryCacheGetByID): Attempt to flatten a dictionary if necessary, but
2078         not too much. This is our idiom in other places.
2079
2080         (JSC::tryCachePutByID): See tryCacheGetByID.
2081
2082         * llint/LLIntSlowPaths.cpp:
2083         (JSC::LLInt::setupGetByIdPrototypeCache): See tryCacheGetByID.
2084
2085         * runtime/JSObject.cpp:
2086         (JSC::JSObject::fillGetterPropertySlot):
2087         * runtime/JSObject.h:
2088         (JSC::JSObject::fillCustomGetterPropertySlot): The rules for caching a
2089         getter are the same as the rules for caching anything else: We're
2090         allowed to cache even in dictionaries, as long as they're cacheable
2091         dictionaries. Any transition that would change to/from getter/setter
2092         or change other attributes requires a structure transition.
2093
2094 2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
2095
2096         [JSC] Drop "replace" from JSC_COMMON_PRIVATE_IDENTIFIERS_EACH_WELL_KNOWN_SYMBOL_NOT_IMPLEMENTED_YET
2097         https://bugs.webkit.org/show_bug.cgi?id=158223
2098
2099         Reviewed by Darin Adler.
2100
2101         This list maintains "not implemented yet" well-known symbols.
2102         `Symbol.replace` is already implemented.
2103
2104         * runtime/CommonIdentifiers.h:
2105
2106 2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
2107
2108         Unreviewed, roll out r201481, r201523: 0.3% regression in Octane code-load
2109         https://bugs.webkit.org/show_bug.cgi?id=158249
2110
2111         * API/JSScriptRef.cpp:
2112         (parseScript):
2113         * CMakeLists.txt:
2114         * DerivedSources.make:
2115         * JavaScriptCore.xcodeproj/project.pbxproj:
2116         * builtins/AsyncFunctionPrototype.js: Removed.
2117         (asyncFunctionResume): Deleted.
2118         * builtins/BuiltinExecutables.cpp:
2119         (JSC::BuiltinExecutables::createExecutable):
2120         * bytecode/BytecodeList.json:
2121         * bytecode/BytecodeUseDef.h:
2122         (JSC::computeUsesForBytecodeOffset): Deleted.
2123         (JSC::computeDefsForBytecodeOffset): Deleted.
2124         * bytecode/CodeBlock.cpp:
2125         (JSC::CodeBlock::finishCreation):
2126         (JSC::CodeBlock::dumpBytecode): Deleted.
2127         * bytecode/UnlinkedCodeBlock.h:
2128         (JSC::UnlinkedCodeBlock::isArrowFunction):
2129         (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction): Deleted.
2130         (JSC::UnlinkedCodeBlock::isAsyncArrowFunction): Deleted.
2131         * bytecode/UnlinkedFunctionExecutable.cpp:
2132         (JSC::generateUnlinkedFunctionCodeBlock):
2133         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2134         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
2135         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2136         * bytecode/UnlinkedFunctionExecutable.h:
2137         * bytecompiler/BytecodeGenerator.cpp:
2138         (JSC::BytecodeGenerator::BytecodeGenerator):
2139         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
2140         (JSC::BytecodeGenerator::emitNewMethodDefinition):
2141         (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
2142         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): Deleted.
2143         (JSC::BytecodeGenerator::emitNewFunction): Deleted.
2144         * bytecompiler/BytecodeGenerator.h:
2145         (JSC::BytecodeGenerator::makeFunction):
2146         * bytecompiler/NodesCodegen.cpp:
2147         (JSC::FunctionNode::emitBytecode): Deleted.
2148         * inspector/agents/InspectorRuntimeAgent.cpp:
2149         (Inspector::InspectorRuntimeAgent::parse):
2150         * jit/JIT.cpp:
2151         (JSC::JIT::privateCompileMainPass): Deleted.
2152         * jit/JIT.h:
2153         * jit/JITOpcodes.cpp:
2154         (JSC::JIT::emitNewFuncCommon): Deleted.
2155         (JSC::JIT::emit_op_new_async_func): Deleted.
2156         (JSC::JIT::emitNewFuncExprCommon): Deleted.
2157         (JSC::JIT::emit_op_new_async_func_exp): Deleted.
2158         * jit/JITOperations.cpp:
2159         * jit/JITOperations.h:
2160         * jsc.cpp:
2161         (runInteractive):
2162         (printUsageStatement): Deleted.
2163         * llint/LLIntSlowPaths.cpp:
2164         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
2165         * llint/LLIntSlowPaths.h:
2166         * llint/LowLevelInterpreter.asm:
2167         * parser/ASTBuilder.h:
2168         (JSC::ASTBuilder::createAsyncFunctionBody): Deleted.
2169         * parser/Keywords.table:
2170         * parser/Parser.cpp:
2171         (JSC::Parser<LexerType>::Parser):
2172         (JSC::Parser<LexerType>::parseInner):
2173         (JSC::Parser<LexerType>::isArrowFunctionParameters):
2174         (JSC::Parser<LexerType>::parseStatementListItem):
2175         (JSC::Parser<LexerType>::parseStatement):
2176         (JSC::Parser<LexerType>::parseFunctionParameters):
2177         (JSC::Parser<LexerType>::parseFunctionInfo):
2178         (JSC::Parser<LexerType>::parseClass):
2179         (JSC::Parser<LexerType>::parseImportClauseItem):
2180         (JSC::Parser<LexerType>::parseImportDeclaration):
2181         (JSC::Parser<LexerType>::parseExportDeclaration):
2182         (JSC::Parser<LexerType>::parseAssignmentExpression):
2183         (JSC::Parser<LexerType>::parseProperty):
2184         (JSC::Parser<LexerType>::parsePropertyMethod):
2185         (JSC::Parser<LexerType>::parsePrimaryExpression):
2186         (JSC::Parser<LexerType>::parseMemberExpression):
2187         (JSC::Parser<LexerType>::parseArrowFunctionExpression):
2188         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2189         (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements): Deleted.
2190         (JSC::Parser<LexerType>::parseVariableDeclarationList): Deleted.
2191         (JSC::Parser<LexerType>::parseDestructuringPattern): Deleted.
2192         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement): Deleted.
2193         (JSC::Parser<LexerType>::parseFormalParameters): Deleted.
2194         (JSC::stringForFunctionMode): Deleted.
2195         (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): Deleted.
2196         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement): Deleted.
2197         (JSC::Parser<LexerType>::parseAwaitExpression): Deleted.
2198         (JSC::Parser<LexerType>::parseAsyncFunctionExpression): Deleted.
2199         (JSC::Parser<LexerType>::parseUnaryExpression): Deleted.
2200         * parser/Parser.h:
2201         (JSC::Scope::Scope):
2202         (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
2203         (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
2204         (JSC::Parser::pushScope):
2205         (JSC::Parser::popScopeInternal):
2206         (JSC::Parser::matchSpecIdentifier):
2207         (JSC::parse):
2208         (JSC::Scope::setSourceParseMode): Deleted.
2209         (JSC::Scope::isAsyncFunction): Deleted.
2210         (JSC::Scope::isAsyncFunctionBoundary): Deleted.
2211         (JSC::Scope::isModule): Deleted.
2212         (JSC::Scope::setIsFunction): Deleted.
2213         (JSC::Scope::setIsAsyncArrowFunction): Deleted.
2214         (JSC::Scope::setIsAsyncFunction): Deleted.
2215         (JSC::Scope::setIsAsyncFunctionBody): Deleted.
2216         (JSC::Scope::setIsAsyncArrowFunctionBody): Deleted.
2217         (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError): Deleted.
2218         (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction): Deleted.
2219         (JSC::Parser::forceClassifyExpressionError): Deleted.
2220         (JSC::Parser::declarationTypeToVariableKind): Deleted.
2221         (JSC::Parser::upperScope): Deleted.
2222         (JSC::Parser::isDisallowedIdentifierAwait): Deleted.
2223         (JSC::Parser::disallowedIdentifierAwaitReason): Deleted.
2224         * parser/ParserModes.h:
2225         (JSC::isFunctionParseMode):
2226         (JSC::isModuleParseMode):
2227         (JSC::isProgramParseMode):
2228         (JSC::SourceParseModeSet::SourceParseModeSet): Deleted.
2229         (JSC::SourceParseModeSet::contains): Deleted.
2230         (JSC::SourceParseModeSet::mergeSourceParseModes): Deleted.
2231         (JSC::isAsyncFunctionParseMode): Deleted.
2232         (JSC::isAsyncArrowFunctionParseMode): Deleted.
2233         (JSC::isAsyncFunctionWrapperParseMode): Deleted.
2234         (JSC::isAsyncFunctionBodyParseMode): Deleted.
2235         (JSC::constructAbilityForParseMode): Deleted.
2236         * parser/ParserTokens.h:
2237         * parser/SourceCodeKey.h:
2238         (JSC::SourceCodeKey::SourceCodeKey):
2239         (JSC::SourceCodeKey::operator==):
2240         (JSC::SourceCodeKey::runtimeFlags): Deleted.
2241         * parser/SyntaxChecker.h:
2242         (JSC::SyntaxChecker::createAsyncFunctionBody): Deleted.
2243         * runtime/AsyncFunctionConstructor.cpp: Removed.
2244         (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor): Deleted.
2245         (JSC::AsyncFunctionConstructor::finishCreation): Deleted.
2246         (JSC::callAsyncFunctionConstructor): Deleted.
2247         (JSC::constructAsyncFunctionConstructor): Deleted.
2248         (JSC::AsyncFunctionConstructor::getCallData): Deleted.
2249         (JSC::AsyncFunctionConstructor::getConstructData): Deleted.
2250         * runtime/AsyncFunctionConstructor.h: Removed.
2251         (JSC::AsyncFunctionConstructor::create): Deleted.
2252         (JSC::AsyncFunctionConstructor::createStructure): Deleted.
2253         * runtime/AsyncFunctionPrototype.cpp: Removed.
2254         (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype): Deleted.
2255         (JSC::AsyncFunctionPrototype::finishCreation): Deleted.
2256         * runtime/AsyncFunctionPrototype.h: Removed.
2257         (JSC::AsyncFunctionPrototype::create): Deleted.
2258         (JSC::AsyncFunctionPrototype::createStructure): Deleted.
2259         * runtime/CodeCache.cpp:
2260         (JSC::CodeCache::getGlobalCodeBlock):
2261         (JSC::CodeCache::getProgramCodeBlock):
2262         (JSC::CodeCache::getEvalCodeBlock):
2263         (JSC::CodeCache::getModuleProgramCodeBlock):
2264         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2265         * runtime/CodeCache.h:
2266         * runtime/CommonIdentifiers.h:
2267         * runtime/Completion.cpp:
2268         (JSC::checkSyntax):
2269         (JSC::checkModuleSyntax):
2270         * runtime/Completion.h:
2271         * runtime/Executable.cpp:
2272         (JSC::ScriptExecutable::newCodeBlockFor):
2273         (JSC::ProgramExecutable::checkSyntax):
2274         * runtime/Executable.h:
2275         * runtime/FunctionConstructor.cpp:
2276         (JSC::constructFunctionSkippingEvalEnabledCheck):
2277         * runtime/FunctionConstructor.h:
2278         * runtime/JSAsyncFunction.cpp: Removed.
2279         (JSC::JSAsyncFunction::JSAsyncFunction): Deleted.
2280         (JSC::JSAsyncFunction::createImpl): Deleted.
2281         (JSC::JSAsyncFunction::create): Deleted.
2282         (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint): Deleted.
2283         * runtime/JSAsyncFunction.h: Removed.
2284         (JSC::JSAsyncFunction::allocationSize): Deleted.
2285         (JSC::JSAsyncFunction::createStructure): Deleted.
2286         * runtime/JSFunction.cpp:
2287         (JSC::JSFunction::getOwnPropertySlot):
2288         * runtime/JSGlobalObject.cpp:
2289         (JSC::JSGlobalObject::createProgramCodeBlock):
2290         (JSC::JSGlobalObject::createEvalCodeBlock):
2291         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
2292         (JSC::JSGlobalObject::init): Deleted.
2293         * runtime/JSGlobalObject.h:
2294         (JSC::JSGlobalObject::asyncFunctionPrototype): Deleted.
2295         (JSC::JSGlobalObject::asyncFunctionStructure): Deleted.
2296         * runtime/ModuleLoaderObject.cpp:
2297         (JSC::moduleLoaderObjectParseModule):
2298         * runtime/RuntimeFlags.h:
2299         (JSC::RuntimeFlags::operator==): Deleted.
2300         (JSC::RuntimeFlags::operator!=): Deleted.
2301         * tests/stress/async-await-basic.js: Removed.
2302         (shouldBe): Deleted.
2303         (shouldBeAsync): Deleted.
2304         (shouldThrow): Deleted.
2305         (shouldThrowAsync): Deleted.
2306         (shouldThrowSyntaxError): Deleted.
2307         (let.AsyncFunction.async): Deleted.
2308         (async.asyncFunctionForProto): Deleted.
2309         (Object.getPrototypeOf.async): Deleted.
2310         (Object.getPrototypeOf.async.method): Deleted.
2311         (async): Deleted.
2312         (async.method): Deleted.
2313         (async.asyncNonConstructorDecl): Deleted.
2314         (shouldThrow.new.async): Deleted.
2315         (shouldThrow.new.async.nonConstructor): Deleted.
2316         (async.asyncDecl): Deleted.
2317         (async.f): Deleted.
2318         (MyError): Deleted.
2319         (async.asyncDeclThrower): Deleted.
2320         (shouldThrowAsync.async): Deleted.
2321         (resolveLater): Deleted.
2322         (rejectLater): Deleted.
2323         (async.resumeAfterNormal): Deleted.
2324         (O.async.resumeAfterNormal): Deleted.
2325         (resumeAfterNormalArrow.async): Deleted.
2326         (async.resumeAfterThrow): Deleted.
2327         (O.async.resumeAfterThrow): Deleted.
2328         (resumeAfterThrowArrow.async): Deleted.
2329         (catch): Deleted.
2330         * tests/stress/async-await-module-reserved-word.js: Removed.
2331         (shouldThrow): Deleted.
2332         (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await): Deleted.
2333         (checkModuleSyntaxError.String.raw.await): Deleted.
2334         (checkModuleSyntaxError.String.raw.async.await): Deleted.
2335         (SyntaxError.Cannot.declare.named): Deleted.
2336         * tests/stress/async-await-mozilla.js: Removed.
2337         (shouldBe): Deleted.
2338         (shouldBeAsync): Deleted.
2339         (shouldThrow): Deleted.
2340         (shouldThrowAsync): Deleted.
2341         (assert): Deleted.
2342         (shouldThrowSyntaxError): Deleted.
2343         (mozSemantics.async.empty): Deleted.
2344         (mozSemantics.async.simpleReturn): Deleted.
2345         (mozSemantics.async.simpleAwait): Deleted.
2346         (mozSemantics.async.simpleAwaitAsync): Deleted.
2347         (mozSemantics.async.returnOtherAsync): Deleted.
2348         (mozSemantics.async.simpleThrower): Deleted.
2349         (mozSemantics.async.delegatedThrower): Deleted.
2350         (mozSemantics.async.tryCatch): Deleted.
2351         (mozSemantics.async.tryCatchThrow): Deleted.
2352         (mozSemantics.async.wellFinally): Deleted.
2353         (mozSemantics.async.finallyMayFail): Deleted.
2354         (mozSemantics.async.embedded.async.inner): Deleted.
2355         (mozSemantics.async.embedded): Deleted.
2356         (mozSemantics.async.fib): Deleted.
2357         (mozSemantics.async.isOdd.async.isEven): Deleted.
2358         (mozSemantics.async.isOdd): Deleted.
2359         (mozSemantics.hardcoreFib.async.fib2): Deleted.
2360         (mozSemantics.namedAsyncExpr.async.simple): Deleted.
2361         (mozSemantics.async.executionOrder.async.first): Deleted.
2362         (mozSemantics.async.executionOrder.async.second): Deleted.
2363         (mozSemantics.async.executionOrder.async.third): Deleted.
2364         (mozSemantics.async.executionOrder): Deleted.
2365         (mozSemantics.async.miscellaneous): Deleted.
2366         (mozSemantics.thrower): Deleted.
2367         (mozSemantics.async.defaultArgs): Deleted.
2368         (mozSemantics.shouldThrow): Deleted.
2369         (mozSemantics): Deleted.
2370         (mozMethods.X): Deleted.
2371         (mozMethods.X.prototype.async.getValue): Deleted.
2372         (mozMethods.X.prototype.setValue): Deleted.
2373         (mozMethods.X.prototype.async.increment): Deleted.
2374         (mozMethods.X.prototype.async.getBaseClassName): Deleted.
2375         (mozMethods.X.async.getStaticValue): Deleted.
2376         (mozMethods.Y.prototype.async.getBaseClassName): Deleted.
2377         (mozMethods.Y): Deleted.
2378         (mozFunctionNameInferrence.async.test): Deleted.
2379         (mozSyntaxErrors): Deleted.
2380         * tests/stress/async-await-reserved-word.js: Removed.
2381         (assert): Deleted.
2382         (shouldThrowSyntaxError): Deleted.
2383         (AsyncFunction.async): Deleted.
2384         * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Removed.
2385         (shouldBe): Deleted.
2386         (shouldBeAsync): Deleted.
2387         (shouldThrowAsync): Deleted.
2388         (noArgumentsArrow2.async): Deleted.
2389         * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Removed.
2390         (shouldBe): Deleted.
2391         (shouldBeAsync): Deleted.
2392         (shouldThrowAsync): Deleted.
2393         (C1): Deleted.
2394         (C2): Deleted.
2395         (shouldThrowAsync.async): Deleted.
2396         * tests/stress/async_arrow_functions_lexical_super_binding.js: Removed.
2397         (shouldBe): Deleted.
2398         (shouldBeAsync): Deleted.
2399         (BaseClass.prototype.baseClassValue): Deleted.
2400         (BaseClass.prototype.get property): Deleted.
2401         (BaseClass): Deleted.
2402         (ChildClass.prototype.asyncSuperProp): Deleted.
2403         (ChildClass.prototype.asyncSuperProp2): Deleted.
2404         (ChildClass): Deleted.
2405         (ChildClass2): Deleted.
2406         * tests/stress/async_arrow_functions_lexical_this_binding.js: Removed.
2407         (shouldBe): Deleted.
2408         (shouldBeAsync): Deleted.
2409         (d.y): Deleted.
2410
2411 2016-05-31  Commit Queue  <commit-queue@webkit.org>
2412
2413         Unreviewed, rolling out r201363 and r201456.
2414         https://bugs.webkit.org/show_bug.cgi?id=158240
2415
2416         "40% regression on date-format-xparb" (Requested by
2417         keith_miller on #webkit).
2418
2419         Reverted changesets:
2420
2421         "LLInt should be able to cache prototype loads for values in
2422         GetById"
2423         https://bugs.webkit.org/show_bug.cgi?id=158032
2424         http://trac.webkit.org/changeset/201363
2425
2426         "get_by_id should support caching unset properties in the
2427         LLInt"
2428         https://bugs.webkit.org/show_bug.cgi?id=158136
2429         http://trac.webkit.org/changeset/201456
2430
2431 2016-05-31  Commit Queue  <commit-queue@webkit.org>
2432
2433         Unreviewed, rolling out r201359.
2434         https://bugs.webkit.org/show_bug.cgi?id=158238
2435
2436         "It was not a speedup on anything" (Requested by saamyjoon on
2437         #webkit).
2438
2439         Reverted changeset:
2440
2441         "We can cache lookups to JSScope::abstractResolve inside
2442         CodeBlock::finishCreation"
2443         https://bugs.webkit.org/show_bug.cgi?id=158036
2444         http://trac.webkit.org/changeset/201359
2445
2446 2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
2447
2448         [JSC] Recover parser performance regression by async support
2449         https://bugs.webkit.org/show_bug.cgi?id=158228
2450
2451         Reviewed by Saam Barati.
2452
2453         This patch recovers parser performance regression caused in r201481.
2454
2455         Compared to the version that reverts r201481, still ~1% regression remains.
2456         But compared to ToT, this patch significantly improves the code-load performance.
2457
2458         In Linux x64 JSCOnly port, with GCC 5.3.1.
2459
2460         reverted v.s. patched.
2461                                  reverted                  patched
2462
2463         closure              0.61805+-0.00376    ?     0.62280+-0.00525       ?
2464         jquery               8.03778+-0.02114          8.03453+-0.04646
2465
2466         <geometric>          2.22883+-0.00836    ?     2.23688+-0.00995       ? might be 1.0036x slower
2467
2468         ToT v.s. patched.
2469                                  baseline                  patched
2470
2471         closure              0.65490+-0.00351    ^     0.62473+-0.00363       ^ definitely 1.0483x faster
2472         jquery               8.25373+-0.06256    ^     8.04701+-0.03455       ^ definitely 1.0257x faster
2473
2474         <geometric>          2.32488+-0.00921    ^     2.24210+-0.00592       ^ definitely 1.0369x faster
2475
2476         * bytecode/UnlinkedFunctionExecutable.cpp:
2477         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2478         * bytecode/UnlinkedFunctionExecutable.h:
2479         Extend SourceParseMode.
2480
2481         * parser/Parser.cpp:
2482         (JSC::Parser<LexerType>::parseInner):
2483         (JSC::Parser<LexerType>::isArrowFunctionParameters):
2484         Do not call `matchSpecIdentifier()` as much as we can. This greatly improves the performance.
2485
2486         (JSC::Parser<LexerType>::parseStatementListItem):
2487         (JSC::Parser<LexerType>::parseStatement):
2488         (JSC::Parser<LexerType>::parseFunctionParameters):
2489         (JSC::Parser<LexerType>::parseFunctionInfo):
2490         Do not touch `currentScope()->isGenerator()` even if it is unnecessary in parseFunctionInfo.
2491         And accidental `syntaxChecker => context` changes are fixed.
2492
2493         (JSC::Parser<LexerType>::parseClass):
2494         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
2495         (JSC::Parser<LexerType>::parseImportClauseItem):
2496         (JSC::Parser<LexerType>::parseExportDeclaration):
2497         (JSC::Parser<LexerType>::parseAssignmentExpression):
2498         Do not use matchSpecIdentifier() in the hot paths.
2499
2500         (JSC::Parser<LexerType>::parseProperty):
2501         (JSC::Parser<LexerType>::parsePrimaryExpression):
2502         (JSC::Parser<LexerType>::parseMemberExpression):
2503         (JSC::Parser<LexerType>::parseUnaryExpression):
2504         (JSC::Parser<LexerType>::printUnexpectedTokenText): Deleted.
2505         * parser/Parser.h:
2506         (JSC::isIdentifierOrKeyword):
2507         AWAIT shoud be one of the keywords. This AWAIT check is unnecessary.
2508
2509         (JSC::Parser::upperScope):
2510         (JSC::Parser::matchSpecIdentifier):
2511         Touching currentScope() and its member causes significant performance degradation.
2512         We carefully remove the above access in the hot paths.
2513
2514         (JSC::Parser::isDisallowedIdentifierAwait):
2515         * parser/ParserModes.h:
2516         (JSC::SourceParseModeSet::SourceParseModeSet):
2517         (JSC::SourceParseModeSet::contains):
2518         (JSC::SourceParseModeSet::mergeSourceParseModes):
2519         (JSC::isFunctionParseMode):
2520         (JSC::isAsyncFunctionParseMode):
2521         (JSC::isAsyncArrowFunctionParseMode):
2522         (JSC::isAsyncFunctionWrapperParseMode):
2523         (JSC::isAsyncFunctionBodyParseMode):
2524         (JSC::isModuleParseMode):
2525         (JSC::isProgramParseMode):
2526         (JSC::constructAbilityForParseMode):
2527         The parser frequently checks SourceParseMode. And variety of SourceParseMode becomes many.
2528         So using switch onto SourceParseMode degrades the performance. Instead, we use bit tests to guard against
2529         many SourceParseModes. We expect that this will be efficiently compiled into test & jmp.
2530
2531         * parser/ParserTokens.h:
2532         Change AWAIT to one of the keywords, as the same to YIELD / LET.
2533
2534 2016-05-31  Saam Barati  <sbarati@apple.com>
2535
2536         Web Inspector: capturing with Allocations timeline causes GC to take 100x longer and cause frame drops
2537         https://bugs.webkit.org/show_bug.cgi?id=158054
2538         <rdar://problem/25280762>
2539
2540         Reviewed by Joseph Pecoraro.
2541
2542         HeapSnapshot::sweepCell was taking a long time on 
2543         http://bl.ocks.org/syntagmatic/6c149c08fc9cde682635
2544         because it has to do a binary search to find if
2545         an item is or is not in the list. 90% of the binary searches
2546         would not find anything. This resulted in a lot of wasted time.
2547
2548         This patch adds a TinyBloomFilter member variable to HeapSnapshot.
2549         We use this filter to try to bypass doing a binary search when the
2550         filter tells us that a particular JSCell is definitely not in our
2551         list. This is a 2x speedup on the steady state GC of the above
2552         website.
2553
2554         * heap/HeapSnapshot.cpp:
2555         (JSC::HeapSnapshot::appendNode):
2556         (JSC::HeapSnapshot::sweepCell):
2557         (JSC::HeapSnapshot::shrinkToFit):
2558         (JSC::HeapSnapshot::nodeForCell):
2559         * heap/HeapSnapshot.h:
2560
2561 2016-05-29  Saam barati  <sbarati@apple.com>
2562
2563         Stack overflow crashes with deep or cyclic proxy prototype chains
2564         https://bugs.webkit.org/show_bug.cgi?id=157087
2565
2566         Reviewed by Filip Pizlo and Mark Lam.
2567
2568         Because a Proxy can call back into the JS runtime in arbitrary
2569         ways, we may have effectively cyclic prototype chains and property lookups
2570         by using a Proxy. We may also have arbitrarily long Proxy chains
2571         where we call into a C frame for each link in the Proxy chain.
2572         This means that every Proxy hook must be aware that it can stack overflow.
2573         Before, only certain hooks were aware of this fact. That was a bug,
2574         all hooks must assume they can stack overflow.
2575
2576         Also, because we may have effectively cyclic prototype chains, we
2577         compile ProxyObject.cpp with -fno-optimize-sibling-calls. This prevents
2578         tail call optimization from happening on any of the calls from
2579         ProxyObject.cpp. We do this because we rely on the machine stack
2580         growing for throwing a stack overflow error. It's better for developers
2581         to be able to see a stack overflow error than to have their program
2582         infinite loop because the compiler performed TCO.
2583
2584         This patch also fixes a couple call sites of various methods
2585         where we didn't check for an exception.
2586
2587         * CMakeLists.txt:
2588         * JavaScriptCore.xcodeproj/project.pbxproj:
2589         * interpreter/Interpreter.cpp:
2590         (JSC::sizeOfVarargs):
2591         * runtime/InternalFunction.cpp:
2592         (JSC::InternalFunction::createSubclassStructure):
2593         * runtime/JSArray.h:
2594         (JSC::getLength):
2595         * runtime/ObjectPrototype.cpp:
2596         (JSC::objectProtoFuncToString):
2597         * runtime/ProxyObject.cpp:
2598         (JSC::performProxyGet):
2599         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2600         (JSC::ProxyObject::performHasProperty):
2601         (JSC::ProxyObject::getOwnPropertySlotCommon):
2602         (JSC::ProxyObject::performPut):
2603         (JSC::performProxyCall):
2604         (JSC::performProxyConstruct):
2605         (JSC::ProxyObject::performDelete):
2606         (JSC::ProxyObject::performPreventExtensions):
2607         (JSC::ProxyObject::performIsExtensible):
2608         (JSC::ProxyObject::performDefineOwnProperty):
2609         (JSC::ProxyObject::performGetOwnPropertyNames):
2610         (JSC::ProxyObject::getOwnPropertyNames):
2611         (JSC::ProxyObject::getPropertyNames):
2612         (JSC::ProxyObject::getOwnNonIndexPropertyNames):
2613         (JSC::ProxyObject::performSetPrototype):
2614         (JSC::ProxyObject::performGetPrototype):
2615         * runtime/ProxyObject.h:
2616         (JSC::ProxyObject::create):
2617         * tests/stress/proxy-stack-overflow-exceptions.js: Added.
2618         (shouldThrowStackOverflow):
2619         (const.emptyFunction):
2620         (makeLongProxyChain):
2621         (shouldThrowStackOverflow.longProxyChain):
2622         (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain1):
2623         (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain2):
2624         (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain3):
2625         (shouldThrowStackOverflow.longProxyChainBind):
2626         (shouldThrowStackOverflow.longProxyChainPropertyAccess):
2627         (shouldThrowStackOverflow.longProxyChainReflectConstruct):
2628         (shouldThrowStackOverflow.longProxyChainReflectSet):
2629         (shouldThrowStackOverflow.longProxyChainReflectOwnKeys):
2630         (shouldThrowStackOverflow.longProxyChainGetPrototypeOf):
2631         (shouldThrowStackOverflow.longProxyChainSetPrototypeOf):
2632         (shouldThrowStackOverflow.longProxyChainGetOwnPropertyDescriptor):
2633         (shouldThrowStackOverflow.longProxyChainDefineProperty):
2634         (shouldThrowStackOverflow.longProxyChainIsExtensible):
2635         (shouldThrowStackOverflow.longProxyChainPreventExtensions):
2636         (shouldThrowStackOverflow.longProxyChainDeleteProperty):
2637         (shouldThrowStackOverflow.longProxyChainWithScope):
2638         (shouldThrowStackOverflow.longProxyChainWithScope2):
2639         (shouldThrowStackOverflow.longProxyChainWithScope3):
2640         (shouldThrowStackOverflow.longProxyChainArrayPrototypePush):
2641         (shouldThrowStackOverflow.longProxyChainWithScope4):
2642         (shouldThrowStackOverflow.longProxyChainCall):
2643         (shouldThrowStackOverflow.longProxyChainConstruct):
2644         (shouldThrowStackOverflow.longProxyChainHas):
2645
2646 2016-05-28  Andreas Kling  <akling@apple.com>
2647
2648         JSGlobalLexicalEnvironment leaks SegmentedVector due to lack of destructor.
2649         <https://webkit.org/b/158186>
2650
2651         Reviewed by Saam Barati.
2652
2653         Give JSGlobalLexicalEnvironment a destroy() and set up a finalizer for it
2654         like we do with JSGlobalObject. (This is needed because they don't inherit
2655         from JSDestructibleObjects and thus can't use JSCell::needsDestruction to
2656         ask for allocation in destructor space.)
2657
2658         This stops us from leaking all the SegmentedVector backing stores.
2659
2660         * runtime/JSGlobalLexicalEnvironment.cpp:
2661         (JSC::JSGlobalLexicalEnvironment::destroy):
2662         * runtime/JSGlobalLexicalEnvironment.h:
2663         (JSC::JSGlobalLexicalEnvironment::create):
2664
2665 2016-05-28  Skachkov Oleksandr  <gskachkov@gmail.com>
2666         [ESNext] Trailing commas in function parameters.
2667         https://bugs.webkit.org/show_bug.cgi?id=158020
2668
2669         Reviewed by Keith Miller.
2670
2671         ESNext allow to add trailing commas in function parameters and function arguments.
2672         Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
2673         Example of using - (function (a, b,) { return a + b; })(1,2,);
2674
2675         * parser/Parser.cpp:
2676         (JSC::Parser<LexerType>::parseFormalParameters):
2677         (JSC::Parser<LexerType>::parseArguments):
2678         * tests/stress/trailing-comma-in-function-paramters.js: Added.
2679
2680 2016-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
2681
2682         [JSC] op_new_arrow_func_exp is no longer necessary
2683         https://bugs.webkit.org/show_bug.cgi?id=158180
2684
2685         Reviewed by Saam Barati.
2686
2687         This patch removes op_new_arrow_func_exp bytecode since
2688         what op_new_arrow_func_exp is doing is completely the same to op_new_func_exp.
2689
2690         * bytecode/BytecodeList.json:
2691         * bytecode/BytecodeUseDef.h:
2692         (JSC::computeUsesForBytecodeOffset): Deleted.
2693         (JSC::computeDefsForBytecodeOffset): Deleted.
2694         * bytecode/CodeBlock.cpp:
2695         (JSC::CodeBlock::dumpBytecode): Deleted.
2696         * bytecompiler/BytecodeGenerator.cpp:
2697         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
2698         * dfg/DFGByteCodeParser.cpp:
2699         (JSC::DFG::ByteCodeParser::parseBlock):
2700         * dfg/DFGCapabilities.cpp:
2701         (JSC::DFG::capabilityLevel): Deleted.
2702         * jit/JIT.cpp:
2703         (JSC::JIT::privateCompileMainPass): Deleted.
2704         * jit/JIT.h:
2705         * jit/JITOpcodes.cpp:
2706         (JSC::JIT::emitNewFuncExprCommon):
2707         (JSC::JIT::emit_op_new_arrow_func_exp): Deleted.
2708         * llint/LLIntSlowPaths.cpp:
2709         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
2710         * llint/LLIntSlowPaths.h:
2711         * llint/LowLevelInterpreter.asm:
2712
2713 2016-05-27  Caitlin Potter  <caitp@igalia.com>
2714
2715         [JSC] implement async functions proposal
2716         https://bugs.webkit.org/show_bug.cgi?id=156147
2717
2718         Reviewed by Yusuke Suzuki.
2719
2720         Adds support for `async` functions, proposed in https://tc39.github.io/ecmascript-asyncawait/.
2721
2722         On the front-end side, "await" becomes a contextual keyword when used within an async function,
2723         which triggers parsing an AwaitExpression. "await" becomes an illegal identifier name within
2724         these contexts. The bytecode generated from an "await" expression is identical to that generated
2725         in a "yield" expression in a Generator, as AsyncFunction reuses generator's state machine mechanism.
2726
2727         There are numerous syntactic forms for language features, including a variation on ArrowFunctions,
2728         requiring the keyword `async` to precede ArrowFormalParameters, and similarly, MethodDefinitions,
2729         which are ordinary MethodDefinitions preceded by the keyword `async`.
2730
2731         An async function desugars to the following:
2732
2733         ```
2734         async function asyncFn() {
2735         }
2736
2737         becomes:
2738
2739         function asyncFn() {
2740             let generator = {
2741                 @generatorNext: function(@generator, @generatorState, @generatorValue, @generatorResumeMode) {
2742                   // generator state machine stuff here
2743                 },
2744                 @generatorState: 0,
2745                 @generatorThis: this,
2746                 @generatorFrame: null
2747             };
2748             return @asyncFunctionResume(generator, undefined, GeneratorResumeMode::NormalMode);
2749         }
2750         ```
2751
2752         `@asyncFunctionResume()` is similar to `@generatorResume`, with the exception that it will wrap the
2753         result of invoking `@generatorNext()` in a Promise, and will avoid allocating an iterator result
2754         object.
2755
2756         If the generator has yielded (an AwaitExpression has occurred), resumption will occur automatically
2757         once the await-expression operand is finished, via Promise chaining.
2758
2759         * API/JSScriptRef.cpp:
2760         (parseScript):
2761         * CMakeLists.txt:
2762         * DerivedSources.make:
2763         * JavaScriptCore.xcodeproj/project.pbxproj:
2764         * builtins/AsyncFunctionPrototype.js: Added.
2765         (asyncFunctionResume):
2766         * builtins/BuiltinExecutables.cpp:
2767         (JSC::BuiltinExecutables::createExecutable):
2768         * bytecode/BytecodeList.json:
2769         * bytecode/BytecodeUseDef.h:
2770         (JSC::computeUsesForBytecodeOffset):
2771         (JSC::computeDefsForBytecodeOffset):
2772         * bytecode/CodeBlock.cpp:
2773         (JSC::CodeBlock::dumpBytecode):
2774         (JSC::CodeBlock::finishCreation):
2775         * bytecode/UnlinkedCodeBlock.h:
2776         (JSC::UnlinkedCodeBlock::isArrowFunction):
2777         (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction):
2778         (JSC::UnlinkedCodeBlock::isAsyncArrowFunction):
2779         * bytecode/UnlinkedFunctionExecutable.cpp:
2780         (JSC::generateUnlinkedFunctionCodeBlock):
2781         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
2782         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2783         * bytecode/UnlinkedFunctionExecutable.h:
2784         * bytecompiler/BytecodeGenerator.cpp:
2785         (JSC::BytecodeGenerator::BytecodeGenerator):
2786         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
2787         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
2788         (JSC::BytecodeGenerator::emitNewMethodDefinition):
2789         (JSC::BytecodeGenerator::emitNewFunction):
2790         (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
2791         * bytecompiler/BytecodeGenerator.h:
2792         (JSC::BytecodeGenerator::makeFunction):
2793         * bytecompiler/NodesCodegen.cpp:
2794         (JSC::FunctionNode::emitBytecode):
2795         * inspector/agents/InspectorRuntimeAgent.cpp:
2796         (Inspector::InspectorRuntimeAgent::parse):
2797         * jit/JIT.cpp:
2798         (JSC::JIT::privateCompileMainPass):
2799         * jit/JIT.h:
2800         * jit/JITOpcodes.cpp:
2801         (JSC::JIT::emitNewFuncCommon):
2802         (JSC::JIT::emit_op_new_async_func):
2803         (JSC::JIT::emitNewFuncExprCommon):
2804         (JSC::JIT::emit_op_new_async_func_exp):
2805         * jit/JITOperations.cpp:
2806         * jit/JITOperations.h:
2807         * jsc.cpp:
2808         (runInteractive):
2809         (printUsageStatement):
2810         * llint/LLIntSlowPaths.cpp:
2811         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2812         * llint/LLIntSlowPaths.h:
2813         * llint/LowLevelInterpreter.asm:
2814         * parser/ASTBuilder.h:
2815         (JSC::ASTBuilder::createAsyncFunctionBody):
2816         * parser/Keywords.table:
2817         * parser/Parser.cpp:
2818         (JSC::Parser<LexerType>::Parser):
2819         (JSC::Parser<LexerType>::parseInner):
2820         (JSC::Parser<LexerType>::isArrowFunctionParameters):
2821         (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
2822         (JSC::Parser<LexerType>::parseStatementListItem):
2823         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2824         (JSC::Parser<LexerType>::parseDestructuringPattern):
2825         (JSC::Parser<LexerType>::parseStatement):
2826         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
2827         (JSC::Parser<LexerType>::parseFormalParameters):
2828         (JSC::stringForFunctionMode):
2829         (JSC::Parser<LexerType>::parseFunctionParameters):
2830         (JSC::Parser<LexerType>::parseFunctionInfo):
2831         (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
2832         (JSC::Parser<LexerType>::parseClass):
2833         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
2834         (JSC::Parser<LexerType>::parseImportClauseItem):
2835         (JSC::Parser<LexerType>::parseImportDeclaration):
2836         (JSC::Parser<LexerType>::parseExportDeclaration):
2837         (JSC::Parser<LexerType>::parseAssignmentExpression):
2838         (JSC::Parser<LexerType>::parseAwaitExpression):
2839         (JSC::Parser<LexerType>::parseProperty):
2840         (JSC::Parser<LexerType>::parsePropertyMethod):
2841         (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
2842         (JSC::Parser<LexerType>::parsePrimaryExpression):
2843         (JSC::Parser<LexerType>::parseMemberExpression):
2844         (JSC::Parser<LexerType>::parseArrowFunctionExpression):
2845         (JSC::Parser<LexerType>::parseUnaryExpression):
2846         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2847         * parser/Parser.h:
2848         (JSC::isIdentifierOrKeyword):
2849         (JSC::Scope::Scope):
2850         (JSC::Scope::setSourceParseMode):
2851         (JSC::Scope::isAsyncFunction):
2852         (JSC::Scope::isAsyncFunctionBoundary):
2853         (JSC::Scope::isModule):
2854         (JSC::Scope::setIsFunction):
2855         (JSC::Scope::setIsAsyncArrowFunction):
2856         (JSC::Scope::setIsAsyncFunction):
2857         (JSC::Scope::setIsAsyncFunctionBody):
2858         (JSC::Scope::setIsAsyncArrowFunctionBody):
2859         (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError):
2860         (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
2861         (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction):
2862         (JSC::Parser::forceClassifyExpressionError):
2863         (JSC::Parser::declarationTypeToVariableKind):
2864         (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
2865         (JSC::Parser::pushScope):
2866         (JSC::Parser::popScopeInternal):
2867         (JSC::Parser::matchSpecIdentifier):
2868         (JSC::Parser::isDisallowedIdentifierAwait):
2869         (JSC::Parser::disallowedIdentifierAwaitReason):
2870         (JSC::parse):
2871         * parser/ParserModes.h:
2872         (JSC::isFunctionParseMode):
2873         (JSC::isAsyncFunctionParseMode):
2874         (JSC::isAsyncArrowFunctionParseMode):
2875         (JSC::isAsyncFunctionWrapperParseMode):
2876         (JSC::isAsyncFunctionBodyParseMode):
2877         (JSC::isModuleParseMode):
2878         (JSC::isProgramParseMode):
2879         (JSC::constructAbilityForParseMode):
2880         * parser/ParserTokens.h:
2881         * parser/SourceCodeKey.h:
2882         (JSC::SourceCodeKey::SourceCodeKey):
2883         (JSC::SourceCodeKey::runtimeFlags):
2884         (JSC::SourceCodeKey::operator==):
2885         * parser/SyntaxChecker.h:
2886         (JSC::SyntaxChecker::createAsyncFunctionBody):
2887         * runtime/AsyncFunctionConstructor.cpp: Added.
2888         (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
2889         (JSC::AsyncFunctionConstructor::finishCreation):
2890         (JSC::callAsyncFunctionConstructor):
2891         (JSC::constructAsyncFunctionConstructor):
2892         (JSC::AsyncFunctionConstructor::getCallData):
2893         (JSC::AsyncFunctionConstructor::getConstructData):
2894         * runtime/AsyncFunctionConstructor.h: Added.
2895         (JSC::AsyncFunctionConstructor::create):
2896         (JSC::AsyncFunctionConstructor::createStructure):
2897         * runtime/AsyncFunctionPrototype.cpp: Added.
2898         (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype):
2899         (JSC::AsyncFunctionPrototype::finishCreation):
2900         * runtime/AsyncFunctionPrototype.h: Added.
2901         (JSC::AsyncFunctionPrototype::create):
2902         (JSC::AsyncFunctionPrototype::createStructure):
2903         * runtime/CodeCache.cpp:
2904         (JSC::CodeCache::getGlobalCodeBlock):
2905         (JSC::CodeCache::getProgramCodeBlock):
2906         (JSC::CodeCache::getEvalCodeBlock):
2907         (JSC::CodeCache::getModuleProgramCodeBlock):
2908         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2909         * runtime/CodeCache.h:
2910         * runtime/CommonIdentifiers.h:
2911         * runtime/Completion.cpp:
2912         (JSC::checkSyntax):
2913         (JSC::checkModuleSyntax):
2914         * runtime/Completion.h:
2915         * runtime/Executable.cpp:
2916         (JSC::ScriptExecutable::newCodeBlockFor):
2917         (JSC::ProgramExecutable::checkSyntax):
2918         * runtime/Executable.h:
2919         * runtime/FunctionConstructor.cpp:
2920         (JSC::constructFunctionSkippingEvalEnabledCheck):
2921         * runtime/FunctionConstructor.h:
2922         * runtime/JSAsyncFunction.cpp: Added.
2923         (JSC::JSAsyncFunction::JSAsyncFunction):
2924         (JSC::JSAsyncFunction::createImpl):
2925         (JSC::JSAsyncFunction::create):
2926         (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint):
2927         * runtime/JSAsyncFunction.h: Added.
2928         (JSC::JSAsyncFunction::allocationSize):
2929         (JSC::JSAsyncFunction::createStructure):
2930         * runtime/JSFunction.cpp:
2931         (JSC::JSFunction::getOwnPropertySlot):
2932         * runtime/JSGlobalObject.cpp:
2933         (JSC::JSGlobalObject::init):
2934         (JSC::JSGlobalObject::createProgramCodeBlock):
2935         (JSC::JSGlobalObject::createEvalCodeBlock):
2936         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
2937         * runtime/JSGlobalObject.h:
2938         (JSC::JSGlobalObject::asyncFunctionPrototype):
2939         (JSC::JSGlobalObject::asyncFunctionStructure):
2940         * runtime/ModuleLoaderObject.cpp:
2941         (JSC::moduleLoaderObjectParseModule):
2942         * runtime/RuntimeFlags.h:
2943         (JSC::RuntimeFlags::operator==):
2944         (JSC::RuntimeFlags::operator!=):
2945         * tests/stress/async-await-basic.js: Added.
2946         (shouldBe):
2947         (shouldBeAsync):
2948         (shouldThrow):
2949         (shouldThrowAsync):
2950         (let.AsyncFunction.async):
2951         (async.asyncFunctionForProto):
2952         (Object.getPrototypeOf.async):
2953         (Object.getPrototypeOf.async.method):
2954         (async):
2955         (async.method):
2956         (async.asyncNonConstructorDecl):
2957         (shouldThrow.new.async):
2958         (shouldThrow.new.async.nonConstructor):
2959         (async.asyncDecl):
2960         (async.f):
2961         (MyError):
2962         (async.asyncDeclThrower):
2963         (shouldThrowAsync.async):
2964         (resolveLater):
2965         (rejectLater):
2966         (async.resumeAfterNormal):
2967         (O.async.resumeAfterNormal):
2968         (resumeAfterNormalArrow.async):
2969         (async.resumeAfterThrow):
2970         (O.async.resumeAfterThrow):
2971         (resumeAfterThrowArrow.async):
2972         (catch):
2973         * tests/stress/async-await-module-reserved-word.js: Added.
2974         (shouldThrow):
2975         (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await):
2976         (checkModuleSyntaxError.String.raw.await):
2977         (checkModuleSyntaxError.String.raw.async.await):
2978         (SyntaxError.Cannot.declare.named):
2979         * tests/stress/async-await-mozilla.js: Added.
2980         (shouldBe):
2981         (shouldBeAsync):
2982         (shouldThrow):
2983         (shouldThrowAsync):
2984         (assert):
2985         (shouldThrowSyntaxError):
2986         (mozSemantics.async.empty):
2987         (mozSemantics.async.simpleReturn):
2988         (mozSemantics.async.simpleAwait):
2989         (mozSemantics.async.simpleAwaitAsync):
2990         (mozSemantics.async.returnOtherAsync):
2991         (mozSemantics.async.simpleThrower):
2992         (mozSemantics.async.delegatedThrower):
2993         (mozSemantics.async.tryCatch):
2994         (mozSemantics.async.tryCatchThrow):
2995         (mozSemantics.async.wellFinally):
2996         (mozSemantics.async.finallyMayFail):
2997         (mozSemantics.async.embedded.async.inner):
2998         (mozSemantics.async.embedded):
2999         (mozSemantics.async.fib):
3000         (mozSemantics.async.isOdd.async.isEven):
3001         (mozSemantics.async.isOdd):
3002         (mozSemantics.hardcoreFib.async.fib2):
3003         (mozSemantics.namedAsyncExpr.async.simple):
3004         (mozSemantics.async.executionOrder.async.first):
3005         (mozSemantics.async.executionOrder.async.second):
3006         (mozSemantics.async.executionOrder.async.third):
3007         (mozSemantics.async.executionOrder):
3008         (mozSemantics.async.miscellaneous):
3009         (mozSemantics.thrower):
3010         (mozSemantics.async.defaultArgs):
3011         (mozSemantics.shouldThrow):
3012         (mozSemantics):
3013         (mozMethods.X):
3014         (mozMethods.X.prototype.async.getValue):
3015         (mozMethods.X.prototype.setValue):
3016         (mozMethods.X.prototype.async.increment):
3017         (mozMethods.X.prototype.async.getBaseClassName):
3018         (mozMethods.X.async.getStaticValue):
3019         (mozMethods.Y.prototype.async.getBaseClassName):
3020         (mozMethods.Y):
3021         (mozFunctionNameInferrence.async.test):
3022         (mozSyntaxErrors):
3023         * tests/stress/async-await-reserved-word.js: Added.
3024         (assert):
3025         (shouldThrowSyntaxError):
3026         (AsyncFunction.async):
3027         * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Added.
3028         (shouldBe):
3029         (shouldBeAsync):
3030         (shouldThrowAsync):
3031         (noArgumentsArrow2.async):
3032         * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Added.
3033         (shouldBe):
3034         (shouldBeAsync):
3035         (shouldThrowAsync):
3036         (C1):
3037         (C2):
3038         (shouldThrowAsync.async):
3039         * tests/stress/async_arrow_functions_lexical_super_binding.js: Added.
3040         (shouldBe):
3041         (shouldBeAsync):
3042         (BaseClass.prototype.baseClassValue):
3043         (BaseClass):
3044         (ChildClass.prototype.asyncSuperProp):
3045         (ChildClass.prototype.asyncSuperProp2):
3046         (ChildClass):
3047         * tests/stress/async_arrow_functions_lexical_this_binding.js: Added.
3048         (shouldBe):
3049         (shouldBeAsync):
3050         (d.y):
3051
3052 2016-05-27  Saam barati  <sbarati@apple.com>
3053
3054         DebuggerCallFrame crashes when updated with the globalExec because neither ShadowChicken's algorithm nor StackVisitor's algorithm reasons about the globalExec
3055         https://bugs.webkit.org/show_bug.cgi?id=158104
3056
3057         Reviewed by Filip Pizlo.
3058
3059         I think globalExec is a special enough case that it should be handled
3060         at the layers above ShadowChicken and StackVisitor. Those APIs should
3061         deal with real stack frames on the machine stack, not a heap constructed frame.
3062
3063         This patch makes DebuggerCallFrame::create aware that it may be
3064         created with the globalObject->globalExec() by having it construct
3065         a single DebuggerCallFrame that wraps the globalExec.
3066
3067         This fixes a crasher because we will construct a DebuggerCallFrame
3068         with the globalExec when the Inspector is set to pause on all uncaught
3069         exceptions and the JS program has a syntax error. Because the program
3070         hasn't begun execution, there is no machine JS stack frame yet. So
3071         DebuggerCallFrame is created with globalExec, which will cause it
3072         to hit an assertion that dictates that the stack have size greater
3073         than zero.
3074
3075         * debugger/DebuggerCallFrame.cpp:
3076         (JSC::DebuggerCallFrame::create):
3077
3078 2016-05-27  Filip Pizlo  <fpizlo@apple.com>
3079
3080         DFG::LazyJSValue::tryGetStringImpl() crashes for empty values
3081         https://bugs.webkit.org/show_bug.cgi?id=158170
3082
3083         Reviewed by Michael Saboff.
3084
3085         The problem here is that jsDynamicCast<>() is evil! It avoids checking for the empty
3086         value, presumably because this makes it soooper fast. In DFG IR, empty values can appear
3087         anywhere because of TDZ.
3088         
3089         This patch doesn't change jsDynamicCast<>(), but it hardens our wrappers for it in the DFG
3090         and it has the affected code use one of those wrappers.
3091         
3092         * dfg/DFGFrozenValue.h:
3093         (JSC::DFG::FrozenValue::dynamicCast): Harden this.
3094         (JSC::DFG::FrozenValue::cast):
3095         * dfg/DFGLazyJSValue.cpp:
3096         (JSC::DFG::LazyJSValue::tryGetStringImpl): Use the hardened wrapper.
3097         * tests/stress/strcat-emtpy.js: Added. This used to crash every time.
3098         (foo):
3099         (i.catch):
3100
3101 2016-05-27  Filip Pizlo  <fpizlo@apple.com>
3102
3103         regExpProtoFuncSplitFast should OOM before it swaps
3104         https://bugs.webkit.org/show_bug.cgi?id=158157
3105
3106         Reviewed by Mark Lam.
3107         
3108         This is a huge speed-up on some jsfunfuzz test cases because it makes us realize much
3109         sooner that running a regexp split will result in swapping. It uses the same basic
3110         approach as http://trac.webkit.org/changeset/201451: if the result array crosses a certain
3111         size threshold, we proceed with a dry run to see how big the array will get before
3112         allocating anything else. This way, bogus uses of split that would have OOMed only after
3113         killing the user's machine will now OOM before killing the user's machine.
3114         
3115         This is an enormous speed-up on some jsfunfuzz tests: they go from running for a long
3116         time to running instantly.
3117
3118         * runtime/RegExpPrototype.cpp:
3119         (JSC::advanceStringIndex):
3120         (JSC::genericSplit):
3121         (JSC::regExpProtoFuncSplitFast):
3122         * runtime/StringObject.h:
3123         (JSC::jsStringWithReuse):
3124         (JSC::jsSubstring):
3125         * tests/stress/big-split-captures.js: Added.
3126         * tests/stress/big-split.js: Added.
3127
3128 2016-05-27  Saam barati  <sbarati@apple.com>
3129
3130         ShadowChicken/DebuggerCallFrame don't properly handle when the entry stack frame is a tail deleted frame
3131         https://bugs.webkit.org/show_bug.cgi?id=158131
3132
3133         Reviewed by Yusuke Suzuki.
3134
3135         There were bugs both in DebuggerCallFrame and ShadowChicken when the entry stack
3136         frame(s) are tail deleted.
3137
3138         DebuggerCallFrame had an assertion saying that the entry frame shouldn't be
3139         tail deleted. This is clearly wrong. The following program proves that this assertion
3140         was misguided:
3141         ```
3142         "use strict";
3143         setTimeout(function foo() { return bar(); }, 0);
3144         ```
3145
3146         ShadowChicken had a very subtle bug when creating the shadow stack when 
3147         the entry frames of the stack were tail deleted. Because it places frames into its shadow
3148         stack by walking the machine frame and looking up entries in the log,
3149         the machine frame doesn't have any notion of those tail deleted frames
3150         at the entry of execution. ShadowChicken would never find those frames
3151         because it would look for tail deleted frames *before* consulting the
3152         current machine frame. This is wrong because if the entry frames
3153         are tail deleted, then there is no machine frame for them because there
3154         is no machine frame before them! Therefore, we must search for tail deleted
3155         frames *after* consulting a machine frame. This is sound because we will always
3156         have at least one machine frame on the stack (when we are using StackVisitor on a valid ExecState).
3157         So when we consult the machine frame that is the entry frame on the machine stack,
3158         we will search for tail deleted frames that come before it in the shadow stack.
3159         This will allow us to find those tail deleted frames that are the entry frames
3160         for the shadow stack.
3161
3162         * debugger/DebuggerCallFrame.cpp:
3163         (JSC::DebuggerCallFrame::create):
3164         * interpreter/ShadowChicken.cpp:
3165         (JSC::ShadowChicken::Packet::dump):
3166         (JSC::ShadowChicken::update):
3167         (JSC::ShadowChicken::dump):
3168
3169 2016-05-27  Chris Dumez  <cdumez@apple.com>
3170
3171         WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables
3172         https://bugs.webkit.org/show_bug.cgi?id=158111
3173
3174         Reviewed by Darin Adler.
3175
3176         WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables.
3177         These are often used cross-thread and copying the captured lambda variables can be
3178         dangerous (e.g. we do not want to copy a String after calling isolatedCopy() upon
3179         capture).
3180
3181         * runtime/Watchdog.cpp:
3182         (JSC::Watchdog::startTimer):
3183         (JSC::Watchdog::Watchdog): Deleted.
3184         (JSC::Watchdog::setTimeLimit): Deleted.
3185         * runtime/Watchdog.h:
3186
3187 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
3188
3189         Removed unused headers from ExecutableAllocatorFixedVMPool.cpp.
3190         https://bugs.webkit.org/show_bug.cgi?id=158159
3191
3192         Reviewed by Darin Adler.
3193
3194         * jit/ExecutableAllocatorFixedVMPool.cpp:
3195
3196 2016-05-27  Keith Miller  <keith_miller@apple.com>
3197
3198         get_by_id should support caching unset properties in the LLInt
3199         https://bugs.webkit.org/show_bug.cgi?id=158136
3200
3201         Reviewed by Benjamin Poulain.
3202
3203         Recently, we started supporting prototype load caching for get_by_id
3204         in the LLInt. This patch extends that to caching unset properties.
3205         While it is uncommon in general for a program to see a single structure
3206         without a given property, the Array.prototype.concat function needs to
3207         lookup the Symbol.isConcatSpreadable property. For any existing code
3208         That property will never be set as it did not exist prior to ES6.
3209
3210         Similarly to the get_by_id_proto_load bytecode, this patch adds a new
3211         bytecode, get_by_id_unset that checks the structureID of the base and
3212         assigns undefined to the result.
3213
3214         There are no new tests here since we already have many tests that
3215         incidentally cover this change.
3216
3217         * bytecode/BytecodeList.json:
3218         * bytecode/BytecodeUseDef.h:
3219         (JSC::computeUsesForBytecodeOffset):
3220         (JSC::computeDefsForBytecodeOffset):
3221         * bytecode/CodeBlock.cpp:
3222         (JSC::CodeBlock::printGetByIdOp):
3223         (JSC::CodeBlock::dumpBytecode):
3224         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3225         * bytecode/GetByIdStatus.cpp:
3226         (JSC::GetByIdStatus::computeFromLLInt):
3227         * dfg/DFGByteCodeParser.cpp:
3228         (JSC::DFG::ByteCodeParser::parseBlock):
3229         * dfg/DFGCapabilities.cpp:
3230         (JSC::DFG::capabilityLevel):
3231         * jit/JIT.cpp:
3232         (JSC::JIT::privateCompileMainPass):
3233         (JSC::JIT::privateCompileSlowCases):
3234         * llint/LLIntSlowPaths.cpp:
3235         (JSC::LLInt::setupGetByIdPrototypeCache):
3236         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3237         * llint/LLIntSlowPaths.h:
3238         * llint/LowLevelInterpreter32_64.asm:
3239         * llint/LowLevelInterpreter64.asm:
3240
3241 2016-05-26  Filip Pizlo  <fpizlo@apple.com>
3242
3243         Bogus uses of regexp matching should realize that they will OOM before they start swapping
3244         https://bugs.webkit.org/show_bug.cgi?id=158142
3245
3246         Reviewed by Michael Saboff.
3247         
3248         Refactored the RegExpObject::matchGlobal() code so that there is less duplication. Took
3249         advantage of this to make the code more resilient in case of absurd situations: if the
3250         result array gets large, it proceeds with a dry run to detect how many matches there will
3251         be. This allows it to OOM before it starts swapping.
3252         
3253         This also improves the overall performance of the code by using lightweight substrings and
3254         skipping the whole intermediate argument array.
3255         
3256         This makes some jsfunfuzz tests run a lot faster and use a lot less memory.
3257         
3258         * builtins/RegExpPrototype.js:
3259         * CMakeLists.txt:
3260         * JavaScriptCore.xcodeproj/project.pbxproj:
3261         * runtime/MatchResult.cpp: Added.
3262         (JSC::MatchResult::dump):
3263         * runtime/MatchResult.h:
3264         (JSC::MatchResult::empty):
3265         (MatchResult::empty): Deleted.
3266         * runtime/RegExpObject.cpp:
3267         (JSC::RegExpObject::match):
3268         (JSC::collectMatches):
3269         (JSC::RegExpObject::matchGlobal):
3270         * runtime/StringObject.h:
3271         (JSC::jsStringWithReuse):
3272         (JSC::jsSubstring):
3273         * tests/stress/big-match.js: Added. Make sure that this optimization doesn't break big matches.
3274
3275 2016-05-26  Gavin & Ellie Barraclough  <barraclough@apple.com>
3276
3277         Static table property lookup should not require getOwnPropertySlot override.
3278         https://bugs.webkit.org/show_bug.cgi?id=158059
3279
3280         Reviewed by Darin Adler.
3281
3282         Currently JSObject does not handle property lookup of entries in the static
3283         table. Each subclass with static properties mut override getOwnPropertySlot,
3284         and explicitly call the lookup functions. This has the following drawbacks:
3285
3286         - Performance: for any class with static properties, property acces becomes
3287           virtual (via method table).
3288         - Poor encapsulation: implementation detail of static property access is
3289           spread throughout & cross projects, rather than being contained in JSObject.
3290         - Code size: this results in a great many additional functions.
3291         - Inconsistency: static table presence has to be be taken into account in many
3292           other operations, e.g. presence of read-only properties for put.
3293         - Memory: in order to avoid the virtual lookup, DOM prototypes eagerly reify
3294           all properties. This is likely suboptimal.
3295
3296         Instead, JSObject::getPropertySlot / JSObject::getOwnPropertySlot should be
3297         able to handle static properties.
3298
3299         This is actually a fairly small & simple change.
3300
3301         The common pattern is for subclasses of JObject to override getOwnPropertySlot
3302         to first defer to JSObject for property storage lookup, and only if this fails
3303         consult the static table. They just want the static tables to be consulted after
3304         regular property storgae lookup. So just add a fast flag in TypeInfo for JSObject
3305         to check, and where it is set, do so. Then it's just a question of switching
3306         classes over to start setting this flag, and drop the override.
3307
3308         The new mechanism does change static table lookup order from oldest-ancestor
3309         first to most-derived first. The new ordering makes more sense (means derived
3310         class static tables can now override entries from parents), and shoudn't affect
3311         any existing code (since overriding didn't previously work, there likely aren't
3312         shadowing properties in more derived types).
3313
3314         This patch changes all classes in JavaScriptCore over to using the new mechanism,
3315         except JSGlobalObject. I'll move classes in WebCore over as a separate patch
3316         (this is also why I've not moved JSGlobalObject in this patch - doing so would
3317         move JSDOMWindow, and I'd rather handle that separately).
3318
3319         * runtime/JSTypeInfo.h:
3320         (JSC::TypeInfo::hasStaticPropertyTable):
3321             - Add HasStaticPropertyTable flag.
3322         * runtime/Lookup.cpp:
3323         (JSC::setUpStaticFunctionSlot):
3324             - Change setUpStaticFunctionSlot to take a VM&.
3325         * runtime/Lookup.h:
3326         (JSC::getStaticPropertySlotFromTable):
3327             - Added helper function to perform static lookup alone.
3328         (JSC::getStaticPropertySlot):
3329         (JSC::getStaticFunctionSlot):
3330             - setUpStaticFunctionSlot changed to take a VM&.
3331         * runtime/JSObject.cpp:
3332         (JSC::JSObject::getOwnStaticPropertySlot):
3333             - Added, walks ClassInfo chain looking for static properties.
3334         * runtime/JSObject.h:
3335         (JSC::JSObject::getOwnNonIndexPropertySlot):
3336             - getOwnNonIndexPropertySlot is used internally by getPropertySlot
3337               & getOwnPropertySlot. If property is not present in storage array
3338               then check the static table.
3339         * runtime/ArrayConstructor.cpp:
3340         (JSC::ArrayConstructor::finishCreation):
3341         (JSC::constructArrayWithSizeQuirk):
3342         (JSC::ArrayConstructor::getOwnPropertySlot): Deleted.
3343         * runtime/ArrayConstructor.h:
3344         (JSC::ArrayConstructor::create):
3345         * runtime/ArrayIteratorPrototype.cpp:
3346         (JSC::ArrayIteratorPrototype::finishCreation):
3347         (JSC::ArrayIteratorPrototype::getOwnPropertySlot): Deleted.
3348         * runtime/ArrayIteratorPrototype.h:
3349         (JSC::ArrayIteratorPrototype::create):
3350         (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype):
3351         * runtime/BooleanPrototype.cpp:
3352         (JSC::BooleanPrototype::finishCreation):
3353         (JSC::booleanProtoFuncToString):
3354         (JSC::BooleanPrototype::getOwnPropertySlot): Deleted.
3355         * runtime/BooleanPrototype.h:
3356         (JSC::BooleanPrototype::create):
3357         * runtime/DateConstructor.cpp:
3358         (JSC::DateConstructor::finishCreation):
3359         (JSC::millisecondsFromComponents):
3360         (JSC::DateConstructor::getOwnPropertySlot): Deleted.
3361         * runtime/DateConstructor.h:
3362         (JSC::DateConstructor::create):
3363         * runtime/DatePrototype.cpp:
3364         (JSC::DatePrototype::finishCreation):
3365         (JSC::dateProtoFuncToString):
3366         (JSC::DatePrototype::getOwnPropertySlot): Deleted.
3367         * runtime/DatePrototype.h:
3368         (JSC::DatePrototype::create):
3369         * runtime/ErrorPrototype.cpp:
3370         (JSC::ErrorPrototype::finishCreation):
3371         (JSC::ErrorPrototype::getOwnPropertySlot): Deleted.
3372         * runtime/ErrorPrototype.h:
3373         (JSC::ErrorPrototype::create):
3374         * runtime/GeneratorPrototype.cpp:
3375         (JSC::GeneratorPrototype::finishCreation):
3376         (JSC::GeneratorPrototype::getOwnPropertySlot): Deleted.
3377         * runtime/GeneratorPrototype.h:
3378         (JSC::GeneratorPrototype::create):
3379         (JSC::GeneratorPrototype::createStructure):
3380         (JSC::GeneratorPrototype::GeneratorPrototype):
3381         * runtime/InspectorInstrumentationObject.cpp:
3382         (JSC::InspectorInstrumentationObject::finishCreation):
3383         (JSC::InspectorInstrumentationObject::isEnabled):
3384         (JSC::InspectorInstrumentationObject::getOwnPropertySlot): Deleted.
3385         * runtime/InspectorInstrumentationObject.h:
3386         (JSC::InspectorInstrumentationObject::create):
3387         (JSC::InspectorInstrumentationObject::createStructure):
3388         * runtime/IntlCollatorConstructor.cpp:
3389         (JSC::IntlCollatorConstructor::getCallData):
3390         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
3391         (JSC::IntlCollatorConstructor::getOwnPropertySlot): Deleted.
3392         * runtime/IntlCollatorConstructor.h:
3393         * runtime/IntlCollatorPrototype.cpp:
3394         (JSC::IntlCollatorPrototype::finishCreation):
3395         (JSC::IntlCollatorFuncCompare):
3396         (JSC::IntlCollatorPrototype::getOwnPropertySlot): Deleted.
3397         * runtime/IntlCollatorPrototype.h:
3398         * runtime/IntlDateTimeFormatConstructor.cpp:
3399         (JSC::IntlDateTimeFormatConstructor::getCallData):
3400         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
3401         (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): Deleted.
3402         * runtime/IntlDateTimeFormatConstructor.h:
3403         * runtime/IntlDateTimeFormatPrototype.cpp:
3404         (JSC::IntlDateTimeFormatPrototype::finishCreation):
3405         (JSC::IntlDateTimeFormatFuncFormatDateTime):
3406         (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): Deleted.
3407         * runtime/IntlDateTimeFormatPrototype.h:
3408         * runtime/IntlNumberFormatConstructor.cpp:
3409         (JSC::IntlNumberFormatConstructor::getCallData):
3410         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
3411         (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): Deleted.
3412         * runtime/IntlNumberFormatConstructor.h:
3413         * runtime/IntlNumberFormatPrototype.cpp:
3414         (JSC::IntlNumberFormatPrototype::finishCreation):
3415         (JSC::IntlNumberFormatFuncFormatNumber):
3416         (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): Deleted.
3417         * runtime/IntlNumberFormatPrototype.h:
3418         * runtime/JSDataViewPrototype.cpp:
3419         (JSC::JSDataViewPrototype::createStructure):
3420         (JSC::getData):
3421         (JSC::JSDataViewPrototype::getOwnPropertySlot): Deleted.
3422         * runtime/JSDataViewPrototype.h:
3423         * runtime/JSInternalPromiseConstructor.cpp:
3424         (JSC::JSInternalPromiseConstructor::getCallData):
3425         (JSC::JSInternalPromiseConstructor::getOwnPropertySlot): Deleted.
3426         * runtime/JSInternalPromiseConstructor.h:
3427         * runtime/JSONObject.cpp:
3428         (JSC::Walker::Walker):
3429         (JSC::JSONObject::getOwnPropertySlot): Deleted.
3430         * runtime/JSONObject.h:
3431         (JSC::JSONObject::create):
3432         * runtime/JSPromiseConstructor.cpp:
3433         (JSC::JSPromiseConstructor::getCallData):
3434         (JSC::JSPromiseConstructor::getOwnPropertySlot): Deleted.
3435         * runtime/JSPromiseConstructor.h:
3436         * runtime/JSPromisePrototype.cpp:
3437         (JSC::JSPromisePrototype::addOwnInternalSlots):
3438         (JSC::JSPromisePrototype::getOwnPropertySlot): Deleted.
3439         * runtime/JSPromisePrototype.h:
3440         * runtime/MapPrototype.cpp:
3441         (JSC::MapPrototype::finishCreation):
3442         (JSC::getMap):
3443         (JSC::MapPrototype::getOwnPropertySlot): Deleted.
3444         * runtime/MapPrototype.h:
3445         (JSC::MapPrototype::create):
3446         (JSC::MapPrototype::MapPrototype):
3447         * runtime/ModuleLoaderObject.cpp:
3448         (JSC::ModuleLoaderObject::finishCreation):
3449         (JSC::printableModuleKey):
3450         (JSC::ModuleLoaderObject::getOwnPropertySlot): Deleted.
3451         * runtime/ModuleLoaderObject.h:
3452         * runtime/NumberPrototype.cpp:
3453         (JSC::NumberPrototype::finishCreation):
3454         (JSC::toThisNumber):
3455         (JSC::NumberPrototype::getOwnPropertySlot): Deleted.
3456         * runtime/NumberPrototype.h:
3457         (JSC::NumberPrototype::create):
3458         * runtime/ObjectConstructor.cpp:
3459         (JSC::ObjectConstructor::addDefineProperty):
3460         (JSC::constructObject):
3461         (JSC::ObjectConstructor::getOwnPropertySlot): Deleted.
3462         * runtime/ObjectConstructor.h:
3463         (JSC::ObjectConstructor::create):
3464         (JSC::ObjectConstructor::createStructure):
3465         * runtime/ReflectObject.cpp:
3466         (JSC::ReflectObject::finishCreation):
3467         (JSC::ReflectObject::getOwnPropertySlot): Deleted.
3468         * runtime/ReflectObject.h:
3469         (JSC::ReflectObject::create):
3470         (JSC::ReflectObject::createStructure):
3471         * runtime/RegExpConstructor.cpp:
3472         (JSC::RegExpConstructor::getRightContext):
3473         (JSC::regExpConstructorDollar):
3474         (JSC::RegExpConstructor::getOwnPropertySlot): Deleted.
3475         * runtime/RegExpConstructor.h:
3476         (JSC::RegExpConstructor::create):
3477         (JSC::RegExpConstructor::createStructure):
3478         * runtime/SetPrototype.cpp:
3479         (JSC::SetPrototype::finishCreation):
3480         (JSC::getSet):
3481         (JSC::SetPrototype::getOwnPropertySlot): Deleted.
3482         * runtime/SetPrototype.h:
3483         (JSC::SetPrototype::create):
3484         (JSC::SetPrototype::SetPrototype):
3485         * runtime/StringConstructor.cpp:
3486         (JSC::StringConstructor::finishCreation):
3487         (JSC::stringFromCharCodeSlowCase):
3488         (JSC::StringConstructor::getOwnPropertySlot): Deleted.
3489         * runtime/StringConstructor.h:
3490         (JSC::StringConstructor::create):
3491         * runtime/StringIteratorPrototype.cpp:
3492         (JSC::StringIteratorPrototype::finishCreation):
3493         (JSC::StringIteratorPrototype::getOwnPropertySlot): Deleted.
3494         * runtime/StringIteratorPrototype.h:
3495         (JSC::StringIteratorPrototype::create):
3496         (JSC::StringIteratorPrototype::StringIteratorPrototype):
3497         * runtime/StringPrototype.cpp:
3498         (JSC::StringPrototype::create):
3499         (JSC::substituteBackreferencesSlow):
3500         (JSC::StringPrototype::getOwnPropertySlot): Deleted.
3501         * runtime/StringPrototype.h:
3502         * runtime/SymbolConstructor.cpp:
3503         (JSC::SymbolConstructor::finishCreation):
3504         (JSC::callSymbol):
3505         (JSC::SymbolConstructor::getOwnPropertySlot): Deleted.
3506         * runtime/SymbolConstructor.h:
3507         (JSC::SymbolConstructor::create):
3508         * runtime/SymbolPrototype.cpp:
3509         (JSC::SymbolPrototype::finishCreation):
3510         (JSC::SymbolPrototype::getOwnPropertySlot): Deleted.
3511         * runtime/SymbolPrototype.h:
3512         (JSC::SymbolPrototype::create):
3513             - remove getOwnPropertySlot, replace OverridesGetOwnPropertySlot flag with HasStaticPropertyTable.
3514
3515 2016-05-26  Commit Queue  <commit-queue@webkit.org>
3516
3517         Unreviewed, rolling out r201436.
3518         https://bugs.webkit.org/show_bug.cgi?id=158143
3519
3520         Caused 30% regression on Dromaeo DOM core tests (Requested by
3521         rniwa on #webkit).
3522
3523         Reverted changeset:
3524
3525         "REGRESSION: JSBench spends a lot of time transitioning
3526         to/from dictionary"
3527         https://bugs.webkit.org/show_bug.cgi?id=158045
3528         http://trac.webkit.org/changeset/201436
3529
3530 2016-05-26  Geoffrey Garen  <ggaren@apple.com>
3531
3532         REGRESSION: JSBench spends a lot of time transitioning to/from dictionary
3533         https://bugs.webkit.org/show_bug.cgi?id=158045
3534
3535         Reviewed by Saam Barati.
3536
3537         15% speedup on jsbench-amazon-firefox, possibly 5% speedup overall on jsbench.
3538
3539         This regression seems to have two parts:
3540
3541         (1) Transitioning the window object to/from dictionary is more expensive
3542         than it used to be to because the window object has lots more properties.
3543         The window object has more properties because, for WebIDL compatibility,
3544         we reify DOM APIs as properties when you delete.
3545
3546         (2) DOM prototypes transition to/from dictionary upon creation
3547         because, once again for WebIDL compatibility, we reify their static
3548         APIs eagerly.
3549
3550         The solution is to chill out a bit on dictionary transitions.
3551
3552         * bytecode/ObjectPropertyConditionSet.cpp: Don't flatten a dictionary
3553         if we've already done so before. This avoids pathological churn, and it
3554         is our idiom in other places.
3555
3556         * interpreter/Interpreter.cpp:
3557         (JSC::Interpreter::execute): Do flatten the global object unconditionally
3558         if it is an uncacheable dictionary because the global object is super
3559         important.
3560
3561         * runtime/BatchedTransitionOptimizer.h:
3562         (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer):
3563         (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): Deleted.
3564         Don't transition away from dictionary after a batched set of property
3565         puts because normal dictionaries are cacheable and that's a perfectly
3566         fine state to be in -- and the transition is expensive.
3567
3568         * runtime/JSGlobalObject.cpp:
3569         (JSC::JSGlobalObject::init): Do start the global object out as a cacheable
3570         dictionary because it will inevitably have enough properties to become
3571         a dictionary.
3572
3573         * runtime/Operations.h:
3574         (JSC::normalizePrototypeChain): Same as ObjectPropertyConditionSet.cpp.
3575
3576 2016-05-25  Geoffrey Garen  <ggaren@apple.com>
3577
3578         replaceable own properties seem to ignore replacement after property caching
3579         https://bugs.webkit.org/show_bug.cgi?id=158091
3580
3581         Reviewed by Darin Adler.
3582
3583         * runtime/Lookup.h:
3584         (JSC::replaceStaticPropertySlot): New helper function for replacing a
3585         static property with a direct property. We need to do an attribute changed
3586         transition because client code might have cached our static property.
3587
3588 2016-05-25  Benjamin Poulain  <benjamin@webkit.org>
3589
3590         [JSC] RegExp with deeply nested subexpressions overflow the stack in Yarr
3591         https://bugs.webkit.org/show_bug.cgi?id=158011
3592         rdar://problem/25946592
3593
3594         Reviewed by Saam Barati.
3595
3596         When generating the meta-data required for compilation,
3597         Yarr uses a recursive function over the various expression in the pattern.
3598
3599         If you have many nested expressions, you can run out of stack
3600         and crash the WebProcess.
3601         This patch changes that into a soft failure. The expression is just
3602         considered invalid.
3603
3604         * runtime/RegExp.cpp:
3605         (JSC::RegExp::finishCreation):
3606         (JSC::RegExp::compile):
3607         (JSC::RegExp::compileMatchOnly):
3608         * yarr/YarrPattern.cpp:
3609         (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
3610         (JSC::Yarr::YarrPatternConstructor::setupOffsets):
3611         (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):
3612         (JSC::Yarr::YarrPattern::compile):
3613         (JSC::Yarr::YarrPattern::YarrPattern):
3614         (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): Deleted.
3615         (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): Deleted.
3616         * yarr/YarrPattern.h:
3617
3618 2016-05-25  Alex Christensen  <achristensen@webkit.org>
3619
3620         Fix Win64 build after r201335
3621         https://bugs.webkit.org/show_bug.cgi?id=158078
3622
3623         Reviewed by Mark Lam.
3624
3625         * offlineasm/x86.rb:
3626         Add intel implementations for loadbs and loadhs
3627
3628 2016-05-25  Carlos Garcia Campos  <cgarcia@igalia.com>
3629
3630         REGRESSION(r201066): [GTK] Several intl tests started to fail in GTK+ bot after r201066
3631         https://bugs.webkit.org/show_bug.cgi?id=158066
3632
3633         Reviewed by Darin Adler.
3634
3635         run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment
3636         variables at all when using jsc binary. We are using setlocale() with a nullptr locale to get the current one, but
3637         the current one is always "C", because to set the locale according to the environment variables we need to call
3638         setlocale with an empty string as locale. That's done by gtk_init(), which is called by all our binaries (web
3639         process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has
3640         always worked for EFL is because they call ecore_init() in jsc that calls setlocale.
3641
3642         * jsc.cpp:
3643         (main): Call setlocale(LC_ALL, "") on GTK+.
3644
3645 2016-05-25  Csaba Osztrogon√°c  <ossy@webkit.org>
3646
3647         [ARM] Fix the Wcast-align warning in LinkBuffer.cpp
3648         https://bugs.webkit.org/show_bug.cgi?id=157889
3649
3650         Reviewed by Darin Adler.
3651
3652         * assembler/LinkBuffer.cpp:
3653         (JSC::recordLinkOffsets):
3654
3655 2016-05-24  Keith Miller  <keith_miller@apple.com>
3656
3657         TypedArray.prototype.slice should not throw if no arguments are provided
3658         https://bugs.webkit.org/show_bug.cgi?id=158044
3659         <rdar://problem/26433280>
3660
3661         Reviewed by Geoffrey Garen.
3662
3663         We were throwing an exception if the TypedArray.prototype.slice function
3664         was not provided arguments. This was wrong. Instead we should just assume
3665         the first argument was 0.
3666
3667         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3668         (JSC::genericTypedArrayViewProtoFuncSlice): Deleted.
3669         * tests/stress/typedarray-slice.js:
3670
3671 2016-05-24  Keith Miller  <keith_miller@apple.com>
3672
3673         LLInt should be able to cache prototype loads for values in GetById
3674         https://bugs.webkit.org/show_bug.cgi?id=158032
3675
3676         Reviewed by Filip Pizlo.
3677
3678         This patch adds prototype value caching to the LLInt for op_get_by_id.
3679         Two previously unused words in the op_get_by_id bytecode have been
3680         repurposed to hold extra information for the cache. The first is a
3681         counter that records the number of get_by_ids that hit a cacheable value
3682         on a prototype. When the counter is decremented from one to zero we
3683         attempt to cache the prototype load, which will be discussed further
3684         below. The second word is used to hold the prototype object when we have
3685         started caching.
3686
3687         When the counter is decremented to zero we first attempt to generate and
3688         watch the property conditions needed to ensure the validity of prototype
3689         load. If the watchpoints are successfully created and installed we
3690         replace the op_get_by_id opcode with the new op_get_by_id_proto_load
3691         opcode, which tells the LLInt to use the cache prototype object for the
3692         load rather than the base value.
3693
3694         Prior to this patch there was not LLInt specific data onCodeBlocks.
3695         Since the CodeBlock needs to own the Watchpoints for the cache, a weak
3696         map from each base structure to a bag of Watchpoints created for that
3697         structure by some op_get_by_id has been added to the CodeBlock. During
3698         GC, if we find that the a structure in the map has not been marked we
3699         free the associated bag on the CodeBlock.
3700
3701         * JavaScriptCore.xcodeproj/project.pbxproj:
3702         * bytecode/BytecodeList.json:
3703         * bytecode/BytecodeUseDef.h:
3704         (JSC::computeUsesForBytecodeOffset):
3705         (JSC::computeDefsForBytecodeOffset):
3706         * bytecode/CodeBlock.cpp:
3707         (JSC::CodeBlock::printGetByIdOp):
3708         (JSC::CodeBlock::printGetByIdCacheStatus):
3709         (JSC::CodeBlock::dumpBytecode):
3710         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3711         * bytecode/CodeBlock.h:
3712         (JSC::CodeBlock::llintGetByIdWatchpointMap):
3713         (JSC::clearLLIntGetByIdCache):
3714         * bytecode/GetByIdStatus.cpp:
3715         (JSC::GetByIdStatus::computeFromLLInt):
3716         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: Added.
3717         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
3718         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::install):
3719         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
3720         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: Added.
3721         * bytecode/ObjectPropertyConditionSet.cpp:
3722         (JSC::ObjectPropertyConditionSet::isValidAndWatchable):
3723         * bytecode/ObjectPropertyConditionSet.h:
3724         * bytecompiler/BytecodeGenerator.cpp:
3725         (JSC::BytecodeGenerator::emitGetById):
3726         * dfg/DFGByteCodeParser.cpp:
3727         (JSC::DFG::ByteCodeParser::parseBlock):
3728         * dfg/DFGCapabilities.cpp:
3729         (JSC::DFG::capabilityLevel):
3730         * jit/JIT.cpp:
3731         (JSC::JIT::privateCompileMainPass):
3732         (JSC::JIT::privateCompileSlowCases):
3733         * llint/LLIntSlowPaths.cpp:
3734         (JSC::LLInt::setupGetByIdPrototypeCache):
3735         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3736         * llint/LLIntSlowPaths.h:
3737         * llint/LowLevelInterpreter32_64.asm:
3738         * llint/LowLevelInterpreter64.asm:
3739         * runtime/Options.h:
3740         * tests/stress/llint-get-by-id-cache-prototype-load-from-dictionary.js: Added.
3741         (test):
3742
3743 2016-05-24  Keith Miller  <keith_miller@apple.com>
3744
3745         We should be able to use the sampling profiler with DRT/WTR.
3746         https://bugs.webkit.org/show_bug.cgi?id=158041
3747
3748         Reviewed by Saam Barati.
3749
3750         This patch makes the sampling profiler use a new option, samplingProfilerPath, which
3751         specifies the path to a directory to output sampling profiler data when the program
3752         terminates or the VM is destroyed. Additionally, it fixes some other issues with the
3753         bytecode profiler that would cause crashes on debug builds.
3754
3755         * profiler/ProfilerDatabase.cpp:
3756         (JSC::Profiler::Database::ensureBytecodesFor):
3757         (JSC::Profiler::Database::performAtExitSave):
3758         * runtime/Options.h:
3759         * runtime/SamplingProfiler.cpp:
3760         (JSC::SamplingProfiler::registerForReportAtExit):
3761         (JSC::SamplingProfiler::reportDataToOptionFile):
3762         (JSC::SamplingProfiler::reportTopFunctions):
3763         (JSC::SamplingProfiler::reportTopBytecodes):
3764         * runtime/SamplingProfiler.h:
3765         * runtime/VM.cpp:
3766         (JSC::VM::VM):
3767         (JSC::VM::~VM):
3768
3769 2016-05-24  Saam barati  <sbarati@apple.com>
3770
3771         We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation
3772         https://bugs.webkit.org/show_bug.cgi?id=158036
3773
3774         Reviewed by Geoffrey Garen.
3775
3776         This patch implements a 1 item cache for JSScope::abstractResolve. I also tried
3777         implementing the cache as a HashMap, but it seemed either less profitable on some
3778         benchmarks or just as profitable on others. Therefore, it's cleaner to just
3779         use a 1 item cache.
3780
3781         * bytecode/CodeBlock.cpp:
3782         (JSC::CodeBlock::CodeBlock):
3783         (JSC::AbstractResolveKey::AbstractResolveKey):
3784         (JSC::AbstractResolveKey::operator==):
3785         (JSC::AbstractResolveKey::isEmptyValue):
3786         (JSC::CodeBlock::finishCreation):
3787         * runtime/GetPutInfo.h:
3788         (JSC::needsVarInjectionChecks):
3789         (JSC::ResolveOp::ResolveOp):
3790
3791 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
3792
3793         Unreviwed, add a comment to describe the test's failure mode. Suggested by mlam.
3794
3795         * tests/stress/override-map-constructor.js:
3796         (Map):
3797
3798 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
3799
3800         Map should not be in JSGlobalObject's static hashtable because it's initialized eagerly via FOR_EACH_SIMPLE_BUILTIN_TYPE_WITH_CONSTRUCTOR
3801         https://bugs.webkit.org/show_bug.cgi?id=158031
3802         rdar://problem/26353661
3803
3804         Reviewed by Geoffrey Garen.
3805         
3806         We were listing Map as being a lazy class structure. It's not. m_mapStructure is a WriteBarrier<>
3807         not a LazyClassStructure<> and there is nothing lazy about it.
3808
3809         * runtime/JSGlobalObject.cpp: The fix is to remove Map here.
3810         * runtime/Lookup.cpp: Add some dumping on the assert path.
3811         (JSC::setUpStaticFunctionSlot):
3812         * tests/stress/override-map-constructor.js: Added. This test used to crash.
3813         (Map):
3814
3815 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
3816
3817         LLInt64 should have typed array fast paths for get_by_val
3818         https://bugs.webkit.org/show_bug.cgi?id=157931
3819
3820         Reviewed by Keith Miller.
3821
3822         I think that the LLInt should be able to access typed arrays more quickly than it does now.
3823         Ideally we would have fast paths for every major typed array operation and we would use
3824         inline cache optimizations. I don't want to do this all in one go, so my plan is to
3825         incrementally add support for this as time allows.
3826         
3827         This change just adds the easy typed array fast paths for get_by_val in the 64-bit version
3828         of LLInt.
3829         
3830         Another bug, https://bugs.webkit.org/show_bug.cgi?id=157922, tracks the overall task of
3831         adding all typed array fast paths to both versions of the LLInt.
3832         
3833         This is a 30% speed-up on typed array benchmarks in LLInt. This is not a speed-up when the
3834         JITs are enabled.
3835
3836         * llint/LLIntData.cpp:
3837         (JSC::LLInt::Data::performAssertions):
3838         * llint/LLIntOffsetsExtractor.cpp:
3839         * llint/LowLevelInterpreter.asm:
3840         * llint/LowLevelInterpreter64.asm:
3841         * offlineasm/backends.rb:
3842         * runtime/JSArrayBufferView.h:
3843         * runtime/JSType.h:
3844
3845 2016-05-24  Saam barati  <sbarati@apple.com> and Yusuke Suzuki <utatane.tea@gmail.com>
3846
3847         ThisTDZMode is no longer needed
3848         https://bugs.webkit.org/show_bug.cgi?id=157209
3849
3850         Reviewed by Saam Barati.
3851
3852         ThisTDZMode is no longer needed because we have ConstructorKind
3853         and DerivedContextType. The value of ThisTDZMode is strictly less
3854         expressive than the combination of those two values. We were
3855         using those values anyways, and this patch just makes it official
3856         by removing ThisTDZMode.
3857
3858         This patch also cleans up caching keys. We extract SourceCodeFlags
3859         from SourceCodeKey and use it in EvalCodeCache. It correctly