[JSC] Recover parser performance regression by async support
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [JSC] Recover parser performance regression by async support
4         https://bugs.webkit.org/show_bug.cgi?id=158228
5
6         Reviewed by Saam Barati.
7
8         This patch recovers parser performance regression caused in r201481.
9
10         Compared to the version that reverts r201481, still ~1% regression remains.
11         But compared to ToT, this patch significantly improves the code-load performance.
12
13         In Linux x64 JSCOnly port, with GCC 5.3.1.
14
15         reverted v.s. patched.
16                                  reverted                  patched
17
18         closure              0.61805+-0.00376    ?     0.62280+-0.00525       ?
19         jquery               8.03778+-0.02114          8.03453+-0.04646
20
21         <geometric>          2.22883+-0.00836    ?     2.23688+-0.00995       ? might be 1.0036x slower
22
23         ToT v.s. patched.
24                                  baseline                  patched
25
26         closure              0.65490+-0.00351    ^     0.62473+-0.00363       ^ definitely 1.0483x faster
27         jquery               8.25373+-0.06256    ^     8.04701+-0.03455       ^ definitely 1.0257x faster
28
29         <geometric>          2.32488+-0.00921    ^     2.24210+-0.00592       ^ definitely 1.0369x faster
30
31         * bytecode/UnlinkedFunctionExecutable.cpp:
32         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
33         * bytecode/UnlinkedFunctionExecutable.h:
34         Extend SourceParseMode.
35
36         * parser/Parser.cpp:
37         (JSC::Parser<LexerType>::parseInner):
38         (JSC::Parser<LexerType>::isArrowFunctionParameters):
39         Do not call `matchSpecIdentifier()` as much as we can. This greatly improves the performance.
40
41         (JSC::Parser<LexerType>::parseStatementListItem):
42         (JSC::Parser<LexerType>::parseStatement):
43         (JSC::Parser<LexerType>::parseFunctionParameters):
44         (JSC::Parser<LexerType>::parseFunctionInfo):
45         Do not touch `currentScope()->isGenerator()` even if it is unnecessary in parseFunctionInfo.
46         And accidental `syntaxChecker => context` changes are fixed.
47
48         (JSC::Parser<LexerType>::parseClass):
49         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
50         (JSC::Parser<LexerType>::parseImportClauseItem):
51         (JSC::Parser<LexerType>::parseExportDeclaration):
52         (JSC::Parser<LexerType>::parseAssignmentExpression):
53         Do not use matchSpecIdentifier() in the hot paths.
54
55         (JSC::Parser<LexerType>::parseProperty):
56         (JSC::Parser<LexerType>::parsePrimaryExpression):
57         (JSC::Parser<LexerType>::parseMemberExpression):
58         (JSC::Parser<LexerType>::parseUnaryExpression):
59         (JSC::Parser<LexerType>::printUnexpectedTokenText): Deleted.
60         * parser/Parser.h:
61         (JSC::isIdentifierOrKeyword):
62         AWAIT shoud be one of the keywords. This AWAIT check is unnecessary.
63
64         (JSC::Parser::upperScope):
65         (JSC::Parser::matchSpecIdentifier):
66         Touching currentScope() and its member causes significant performance degradation.
67         We carefully remove the above access in the hot paths.
68
69         (JSC::Parser::isDisallowedIdentifierAwait):
70         * parser/ParserModes.h:
71         (JSC::SourceParseModeSet::SourceParseModeSet):
72         (JSC::SourceParseModeSet::contains):
73         (JSC::SourceParseModeSet::mergeSourceParseModes):
74         (JSC::isFunctionParseMode):
75         (JSC::isAsyncFunctionParseMode):
76         (JSC::isAsyncArrowFunctionParseMode):
77         (JSC::isAsyncFunctionWrapperParseMode):
78         (JSC::isAsyncFunctionBodyParseMode):
79         (JSC::isModuleParseMode):
80         (JSC::isProgramParseMode):
81         (JSC::constructAbilityForParseMode):
82         The parser frequently checks SourceParseMode. And variety of SourceParseMode becomes many.
83         So using switch onto SourceParseMode degrades the performance. Instead, we use bit tests to guard against
84         many SourceParseModes. We expect that this will be efficiently compiled into test & jmp.
85
86         * parser/ParserTokens.h:
87         Change AWAIT to one of the keywords, as the same to YIELD / LET.
88
89 2016-05-31  Saam Barati  <sbarati@apple.com>
90
91         Web Inspector: capturing with Allocations timeline causes GC to take 100x longer and cause frame drops
92         https://bugs.webkit.org/show_bug.cgi?id=158054
93         <rdar://problem/25280762>
94
95         Reviewed by Joseph Pecoraro.
96
97         HeapSnapshot::sweepCell was taking a long time on 
98         http://bl.ocks.org/syntagmatic/6c149c08fc9cde682635
99         because it has to do a binary search to find if
100         an item is or is not in the list. 90% of the binary searches
101         would not find anything. This resulted in a lot of wasted time.
102
103         This patch adds a TinyBloomFilter member variable to HeapSnapshot.
104         We use this filter to try to bypass doing a binary search when the
105         filter tells us that a particular JSCell is definitely not in our
106         list. This is a 2x speedup on the steady state GC of the above
107         website.
108
109         * heap/HeapSnapshot.cpp:
110         (JSC::HeapSnapshot::appendNode):
111         (JSC::HeapSnapshot::sweepCell):
112         (JSC::HeapSnapshot::shrinkToFit):
113         (JSC::HeapSnapshot::nodeForCell):
114         * heap/HeapSnapshot.h:
115
116 2016-05-29  Saam barati  <sbarati@apple.com>
117
118         Stack overflow crashes with deep or cyclic proxy prototype chains
119         https://bugs.webkit.org/show_bug.cgi?id=157087
120
121         Reviewed by Filip Pizlo and Mark Lam.
122
123         Because a Proxy can call back into the JS runtime in arbitrary
124         ways, we may have effectively cyclic prototype chains and property lookups
125         by using a Proxy. We may also have arbitrarily long Proxy chains
126         where we call into a C frame for each link in the Proxy chain.
127         This means that every Proxy hook must be aware that it can stack overflow.
128         Before, only certain hooks were aware of this fact. That was a bug,
129         all hooks must assume they can stack overflow.
130
131         Also, because we may have effectively cyclic prototype chains, we
132         compile ProxyObject.cpp with -fno-optimize-sibling-calls. This prevents
133         tail call optimization from happening on any of the calls from
134         ProxyObject.cpp. We do this because we rely on the machine stack
135         growing for throwing a stack overflow error. It's better for developers
136         to be able to see a stack overflow error than to have their program
137         infinite loop because the compiler performed TCO.
138
139         This patch also fixes a couple call sites of various methods
140         where we didn't check for an exception.
141
142         * CMakeLists.txt:
143         * JavaScriptCore.xcodeproj/project.pbxproj:
144         * interpreter/Interpreter.cpp:
145         (JSC::sizeOfVarargs):
146         * runtime/InternalFunction.cpp:
147         (JSC::InternalFunction::createSubclassStructure):
148         * runtime/JSArray.h:
149         (JSC::getLength):
150         * runtime/ObjectPrototype.cpp:
151         (JSC::objectProtoFuncToString):
152         * runtime/ProxyObject.cpp:
153         (JSC::performProxyGet):
154         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
155         (JSC::ProxyObject::performHasProperty):
156         (JSC::ProxyObject::getOwnPropertySlotCommon):
157         (JSC::ProxyObject::performPut):
158         (JSC::performProxyCall):
159         (JSC::performProxyConstruct):
160         (JSC::ProxyObject::performDelete):
161         (JSC::ProxyObject::performPreventExtensions):
162         (JSC::ProxyObject::performIsExtensible):
163         (JSC::ProxyObject::performDefineOwnProperty):
164         (JSC::ProxyObject::performGetOwnPropertyNames):
165         (JSC::ProxyObject::getOwnPropertyNames):
166         (JSC::ProxyObject::getPropertyNames):
167         (JSC::ProxyObject::getOwnNonIndexPropertyNames):
168         (JSC::ProxyObject::performSetPrototype):
169         (JSC::ProxyObject::performGetPrototype):
170         * runtime/ProxyObject.h:
171         (JSC::ProxyObject::create):
172         * tests/stress/proxy-stack-overflow-exceptions.js: Added.
173         (shouldThrowStackOverflow):
174         (const.emptyFunction):
175         (makeLongProxyChain):
176         (shouldThrowStackOverflow.longProxyChain):
177         (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain1):
178         (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain2):
179         (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain3):
180         (shouldThrowStackOverflow.longProxyChainBind):
181         (shouldThrowStackOverflow.longProxyChainPropertyAccess):
182         (shouldThrowStackOverflow.longProxyChainReflectConstruct):
183         (shouldThrowStackOverflow.longProxyChainReflectSet):
184         (shouldThrowStackOverflow.longProxyChainReflectOwnKeys):
185         (shouldThrowStackOverflow.longProxyChainGetPrototypeOf):
186         (shouldThrowStackOverflow.longProxyChainSetPrototypeOf):
187         (shouldThrowStackOverflow.longProxyChainGetOwnPropertyDescriptor):
188         (shouldThrowStackOverflow.longProxyChainDefineProperty):
189         (shouldThrowStackOverflow.longProxyChainIsExtensible):
190         (shouldThrowStackOverflow.longProxyChainPreventExtensions):
191         (shouldThrowStackOverflow.longProxyChainDeleteProperty):
192         (shouldThrowStackOverflow.longProxyChainWithScope):
193         (shouldThrowStackOverflow.longProxyChainWithScope2):
194         (shouldThrowStackOverflow.longProxyChainWithScope3):
195         (shouldThrowStackOverflow.longProxyChainArrayPrototypePush):
196         (shouldThrowStackOverflow.longProxyChainWithScope4):
197         (shouldThrowStackOverflow.longProxyChainCall):
198         (shouldThrowStackOverflow.longProxyChainConstruct):
199         (shouldThrowStackOverflow.longProxyChainHas):
200
201 2016-05-28  Andreas Kling  <akling@apple.com>
202
203         JSGlobalLexicalEnvironment leaks SegmentedVector due to lack of destructor.
204         <https://webkit.org/b/158186>
205
206         Reviewed by Saam Barati.
207
208         Give JSGlobalLexicalEnvironment a destroy() and set up a finalizer for it
209         like we do with JSGlobalObject. (This is needed because they don't inherit
210         from JSDestructibleObjects and thus can't use JSCell::needsDestruction to
211         ask for allocation in destructor space.)
212
213         This stops us from leaking all the SegmentedVector backing stores.
214
215         * runtime/JSGlobalLexicalEnvironment.cpp:
216         (JSC::JSGlobalLexicalEnvironment::destroy):
217         * runtime/JSGlobalLexicalEnvironment.h:
218         (JSC::JSGlobalLexicalEnvironment::create):
219
220 2016-05-28  Skachkov Oleksandr  <gskachkov@gmail.com>
221         [ESNext] Trailing commas in function parameters.
222         https://bugs.webkit.org/show_bug.cgi?id=158020
223
224         Reviewed by Keith Miller.
225
226         ESNext allow to add trailing commas in function parameters and function arguments.
227         Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
228         Example of using - (function (a, b,) { return a + b; })(1,2,);
229
230         * parser/Parser.cpp:
231         (JSC::Parser<LexerType>::parseFormalParameters):
232         (JSC::Parser<LexerType>::parseArguments):
233         * tests/stress/trailing-comma-in-function-paramters.js: Added.
234
235 2016-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
236
237         [JSC] op_new_arrow_func_exp is no longer necessary
238         https://bugs.webkit.org/show_bug.cgi?id=158180
239
240         Reviewed by Saam Barati.
241
242         This patch removes op_new_arrow_func_exp bytecode since
243         what op_new_arrow_func_exp is doing is completely the same to op_new_func_exp.
244
245         * bytecode/BytecodeList.json:
246         * bytecode/BytecodeUseDef.h:
247         (JSC::computeUsesForBytecodeOffset): Deleted.
248         (JSC::computeDefsForBytecodeOffset): Deleted.
249         * bytecode/CodeBlock.cpp:
250         (JSC::CodeBlock::dumpBytecode): Deleted.
251         * bytecompiler/BytecodeGenerator.cpp:
252         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
253         * dfg/DFGByteCodeParser.cpp:
254         (JSC::DFG::ByteCodeParser::parseBlock):
255         * dfg/DFGCapabilities.cpp:
256         (JSC::DFG::capabilityLevel): Deleted.
257         * jit/JIT.cpp:
258         (JSC::JIT::privateCompileMainPass): Deleted.
259         * jit/JIT.h:
260         * jit/JITOpcodes.cpp:
261         (JSC::JIT::emitNewFuncExprCommon):
262         (JSC::JIT::emit_op_new_arrow_func_exp): Deleted.
263         * llint/LLIntSlowPaths.cpp:
264         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
265         * llint/LLIntSlowPaths.h:
266         * llint/LowLevelInterpreter.asm:
267
268 2016-05-27  Caitlin Potter  <caitp@igalia.com>
269
270         [JSC] implement async functions proposal
271         https://bugs.webkit.org/show_bug.cgi?id=156147
272
273         Reviewed by Yusuke Suzuki.
274
275         Adds support for `async` functions, proposed in https://tc39.github.io/ecmascript-asyncawait/.
276
277         On the front-end side, "await" becomes a contextual keyword when used within an async function,
278         which triggers parsing an AwaitExpression. "await" becomes an illegal identifier name within
279         these contexts. The bytecode generated from an "await" expression is identical to that generated
280         in a "yield" expression in a Generator, as AsyncFunction reuses generator's state machine mechanism.
281
282         There are numerous syntactic forms for language features, including a variation on ArrowFunctions,
283         requiring the keyword `async` to precede ArrowFormalParameters, and similarly, MethodDefinitions,
284         which are ordinary MethodDefinitions preceded by the keyword `async`.
285
286         An async function desugars to the following:
287
288         ```
289         async function asyncFn() {
290         }
291
292         becomes:
293
294         function asyncFn() {
295             let generator = {
296                 @generatorNext: function(@generator, @generatorState, @generatorValue, @generatorResumeMode) {
297                   // generator state machine stuff here
298                 },
299                 @generatorState: 0,
300                 @generatorThis: this,
301                 @generatorFrame: null
302             };
303             return @asyncFunctionResume(generator, undefined, GeneratorResumeMode::NormalMode);
304         }
305         ```
306
307         `@asyncFunctionResume()` is similar to `@generatorResume`, with the exception that it will wrap the
308         result of invoking `@generatorNext()` in a Promise, and will avoid allocating an iterator result
309         object.
310
311         If the generator has yielded (an AwaitExpression has occurred), resumption will occur automatically
312         once the await-expression operand is finished, via Promise chaining.
313
314         * API/JSScriptRef.cpp:
315         (parseScript):
316         * CMakeLists.txt:
317         * DerivedSources.make:
318         * JavaScriptCore.xcodeproj/project.pbxproj:
319         * builtins/AsyncFunctionPrototype.js: Added.
320         (asyncFunctionResume):
321         * builtins/BuiltinExecutables.cpp:
322         (JSC::BuiltinExecutables::createExecutable):
323         * bytecode/BytecodeList.json:
324         * bytecode/BytecodeUseDef.h:
325         (JSC::computeUsesForBytecodeOffset):
326         (JSC::computeDefsForBytecodeOffset):
327         * bytecode/CodeBlock.cpp:
328         (JSC::CodeBlock::dumpBytecode):
329         (JSC::CodeBlock::finishCreation):
330         * bytecode/UnlinkedCodeBlock.h:
331         (JSC::UnlinkedCodeBlock::isArrowFunction):
332         (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction):
333         (JSC::UnlinkedCodeBlock::isAsyncArrowFunction):
334         * bytecode/UnlinkedFunctionExecutable.cpp:
335         (JSC::generateUnlinkedFunctionCodeBlock):
336         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
337         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
338         * bytecode/UnlinkedFunctionExecutable.h:
339         * bytecompiler/BytecodeGenerator.cpp:
340         (JSC::BytecodeGenerator::BytecodeGenerator):
341         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
342         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
343         (JSC::BytecodeGenerator::emitNewMethodDefinition):
344         (JSC::BytecodeGenerator::emitNewFunction):
345         (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
346         * bytecompiler/BytecodeGenerator.h:
347         (JSC::BytecodeGenerator::makeFunction):
348         * bytecompiler/NodesCodegen.cpp:
349         (JSC::FunctionNode::emitBytecode):
350         * inspector/agents/InspectorRuntimeAgent.cpp:
351         (Inspector::InspectorRuntimeAgent::parse):
352         * jit/JIT.cpp:
353         (JSC::JIT::privateCompileMainPass):
354         * jit/JIT.h:
355         * jit/JITOpcodes.cpp:
356         (JSC::JIT::emitNewFuncCommon):
357         (JSC::JIT::emit_op_new_async_func):
358         (JSC::JIT::emitNewFuncExprCommon):
359         (JSC::JIT::emit_op_new_async_func_exp):
360         * jit/JITOperations.cpp:
361         * jit/JITOperations.h:
362         * jsc.cpp:
363         (runInteractive):
364         (printUsageStatement):
365         * llint/LLIntSlowPaths.cpp:
366         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
367         * llint/LLIntSlowPaths.h:
368         * llint/LowLevelInterpreter.asm:
369         * parser/ASTBuilder.h:
370         (JSC::ASTBuilder::createAsyncFunctionBody):
371         * parser/Keywords.table:
372         * parser/Parser.cpp:
373         (JSC::Parser<LexerType>::Parser):
374         (JSC::Parser<LexerType>::parseInner):
375         (JSC::Parser<LexerType>::isArrowFunctionParameters):
376         (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
377         (JSC::Parser<LexerType>::parseStatementListItem):
378         (JSC::Parser<LexerType>::parseVariableDeclarationList):
379         (JSC::Parser<LexerType>::parseDestructuringPattern):
380         (JSC::Parser<LexerType>::parseStatement):
381         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
382         (JSC::Parser<LexerType>::parseFormalParameters):
383         (JSC::stringForFunctionMode):
384         (JSC::Parser<LexerType>::parseFunctionParameters):
385         (JSC::Parser<LexerType>::parseFunctionInfo):
386         (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
387         (JSC::Parser<LexerType>::parseClass):
388         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
389         (JSC::Parser<LexerType>::parseImportClauseItem):
390         (JSC::Parser<LexerType>::parseImportDeclaration):
391         (JSC::Parser<LexerType>::parseExportDeclaration):
392         (JSC::Parser<LexerType>::parseAssignmentExpression):
393         (JSC::Parser<LexerType>::parseAwaitExpression):
394         (JSC::Parser<LexerType>::parseProperty):
395         (JSC::Parser<LexerType>::parsePropertyMethod):
396         (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
397         (JSC::Parser<LexerType>::parsePrimaryExpression):
398         (JSC::Parser<LexerType>::parseMemberExpression):
399         (JSC::Parser<LexerType>::parseArrowFunctionExpression):
400         (JSC::Parser<LexerType>::parseUnaryExpression):
401         (JSC::Parser<LexerType>::printUnexpectedTokenText):
402         * parser/Parser.h:
403         (JSC::isIdentifierOrKeyword):
404         (JSC::Scope::Scope):
405         (JSC::Scope::setSourceParseMode):
406         (JSC::Scope::isAsyncFunction):
407         (JSC::Scope::isAsyncFunctionBoundary):
408         (JSC::Scope::isModule):
409         (JSC::Scope::setIsFunction):
410         (JSC::Scope::setIsAsyncArrowFunction):
411         (JSC::Scope::setIsAsyncFunction):
412         (JSC::Scope::setIsAsyncFunctionBody):
413         (JSC::Scope::setIsAsyncArrowFunctionBody):
414         (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError):
415         (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
416         (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction):
417         (JSC::Parser::forceClassifyExpressionError):
418         (JSC::Parser::declarationTypeToVariableKind):
419         (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
420         (JSC::Parser::pushScope):
421         (JSC::Parser::popScopeInternal):
422         (JSC::Parser::matchSpecIdentifier):
423         (JSC::Parser::isDisallowedIdentifierAwait):
424         (JSC::Parser::disallowedIdentifierAwaitReason):
425         (JSC::parse):
426         * parser/ParserModes.h:
427         (JSC::isFunctionParseMode):
428         (JSC::isAsyncFunctionParseMode):
429         (JSC::isAsyncArrowFunctionParseMode):
430         (JSC::isAsyncFunctionWrapperParseMode):
431         (JSC::isAsyncFunctionBodyParseMode):
432         (JSC::isModuleParseMode):
433         (JSC::isProgramParseMode):
434         (JSC::constructAbilityForParseMode):
435         * parser/ParserTokens.h:
436         * parser/SourceCodeKey.h:
437         (JSC::SourceCodeKey::SourceCodeKey):
438         (JSC::SourceCodeKey::runtimeFlags):
439         (JSC::SourceCodeKey::operator==):
440         * parser/SyntaxChecker.h:
441         (JSC::SyntaxChecker::createAsyncFunctionBody):
442         * runtime/AsyncFunctionConstructor.cpp: Added.
443         (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
444         (JSC::AsyncFunctionConstructor::finishCreation):
445         (JSC::callAsyncFunctionConstructor):
446         (JSC::constructAsyncFunctionConstructor):
447         (JSC::AsyncFunctionConstructor::getCallData):
448         (JSC::AsyncFunctionConstructor::getConstructData):
449         * runtime/AsyncFunctionConstructor.h: Added.
450         (JSC::AsyncFunctionConstructor::create):
451         (JSC::AsyncFunctionConstructor::createStructure):
452         * runtime/AsyncFunctionPrototype.cpp: Added.
453         (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype):
454         (JSC::AsyncFunctionPrototype::finishCreation):
455         * runtime/AsyncFunctionPrototype.h: Added.
456         (JSC::AsyncFunctionPrototype::create):
457         (JSC::AsyncFunctionPrototype::createStructure):
458         * runtime/CodeCache.cpp:
459         (JSC::CodeCache::getGlobalCodeBlock):
460         (JSC::CodeCache::getProgramCodeBlock):
461         (JSC::CodeCache::getEvalCodeBlock):
462         (JSC::CodeCache::getModuleProgramCodeBlock):
463         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
464         * runtime/CodeCache.h:
465         * runtime/CommonIdentifiers.h:
466         * runtime/Completion.cpp:
467         (JSC::checkSyntax):
468         (JSC::checkModuleSyntax):
469         * runtime/Completion.h:
470         * runtime/Executable.cpp:
471         (JSC::ScriptExecutable::newCodeBlockFor):
472         (JSC::ProgramExecutable::checkSyntax):
473         * runtime/Executable.h:
474         * runtime/FunctionConstructor.cpp:
475         (JSC::constructFunctionSkippingEvalEnabledCheck):
476         * runtime/FunctionConstructor.h:
477         * runtime/JSAsyncFunction.cpp: Added.
478         (JSC::JSAsyncFunction::JSAsyncFunction):
479         (JSC::JSAsyncFunction::createImpl):
480         (JSC::JSAsyncFunction::create):
481         (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint):
482         * runtime/JSAsyncFunction.h: Added.
483         (JSC::JSAsyncFunction::allocationSize):
484         (JSC::JSAsyncFunction::createStructure):
485         * runtime/JSFunction.cpp:
486         (JSC::JSFunction::getOwnPropertySlot):
487         * runtime/JSGlobalObject.cpp:
488         (JSC::JSGlobalObject::init):
489         (JSC::JSGlobalObject::createProgramCodeBlock):
490         (JSC::JSGlobalObject::createEvalCodeBlock):
491         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
492         * runtime/JSGlobalObject.h:
493         (JSC::JSGlobalObject::asyncFunctionPrototype):
494         (JSC::JSGlobalObject::asyncFunctionStructure):
495         * runtime/ModuleLoaderObject.cpp:
496         (JSC::moduleLoaderObjectParseModule):
497         * runtime/RuntimeFlags.h:
498         (JSC::RuntimeFlags::operator==):
499         (JSC::RuntimeFlags::operator!=):
500         * tests/stress/async-await-basic.js: Added.
501         (shouldBe):
502         (shouldBeAsync):
503         (shouldThrow):
504         (shouldThrowAsync):
505         (let.AsyncFunction.async):
506         (async.asyncFunctionForProto):
507         (Object.getPrototypeOf.async):
508         (Object.getPrototypeOf.async.method):
509         (async):
510         (async.method):
511         (async.asyncNonConstructorDecl):
512         (shouldThrow.new.async):
513         (shouldThrow.new.async.nonConstructor):
514         (async.asyncDecl):
515         (async.f):
516         (MyError):
517         (async.asyncDeclThrower):
518         (shouldThrowAsync.async):
519         (resolveLater):
520         (rejectLater):
521         (async.resumeAfterNormal):
522         (O.async.resumeAfterNormal):
523         (resumeAfterNormalArrow.async):
524         (async.resumeAfterThrow):
525         (O.async.resumeAfterThrow):
526         (resumeAfterThrowArrow.async):
527         (catch):
528         * tests/stress/async-await-module-reserved-word.js: Added.
529         (shouldThrow):
530         (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await):
531         (checkModuleSyntaxError.String.raw.await):
532         (checkModuleSyntaxError.String.raw.async.await):
533         (SyntaxError.Cannot.declare.named):
534         * tests/stress/async-await-mozilla.js: Added.
535         (shouldBe):
536         (shouldBeAsync):
537         (shouldThrow):
538         (shouldThrowAsync):
539         (assert):
540         (shouldThrowSyntaxError):
541         (mozSemantics.async.empty):
542         (mozSemantics.async.simpleReturn):
543         (mozSemantics.async.simpleAwait):
544         (mozSemantics.async.simpleAwaitAsync):
545         (mozSemantics.async.returnOtherAsync):
546         (mozSemantics.async.simpleThrower):
547         (mozSemantics.async.delegatedThrower):
548         (mozSemantics.async.tryCatch):
549         (mozSemantics.async.tryCatchThrow):
550         (mozSemantics.async.wellFinally):
551         (mozSemantics.async.finallyMayFail):
552         (mozSemantics.async.embedded.async.inner):
553         (mozSemantics.async.embedded):
554         (mozSemantics.async.fib):
555         (mozSemantics.async.isOdd.async.isEven):
556         (mozSemantics.async.isOdd):
557         (mozSemantics.hardcoreFib.async.fib2):
558         (mozSemantics.namedAsyncExpr.async.simple):
559         (mozSemantics.async.executionOrder.async.first):
560         (mozSemantics.async.executionOrder.async.second):
561         (mozSemantics.async.executionOrder.async.third):
562         (mozSemantics.async.executionOrder):
563         (mozSemantics.async.miscellaneous):
564         (mozSemantics.thrower):
565         (mozSemantics.async.defaultArgs):
566         (mozSemantics.shouldThrow):
567         (mozSemantics):
568         (mozMethods.X):
569         (mozMethods.X.prototype.async.getValue):
570         (mozMethods.X.prototype.setValue):
571         (mozMethods.X.prototype.async.increment):
572         (mozMethods.X.prototype.async.getBaseClassName):
573         (mozMethods.X.async.getStaticValue):
574         (mozMethods.Y.prototype.async.getBaseClassName):
575         (mozMethods.Y):
576         (mozFunctionNameInferrence.async.test):
577         (mozSyntaxErrors):
578         * tests/stress/async-await-reserved-word.js: Added.
579         (assert):
580         (shouldThrowSyntaxError):
581         (AsyncFunction.async):
582         * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Added.
583         (shouldBe):
584         (shouldBeAsync):
585         (shouldThrowAsync):
586         (noArgumentsArrow2.async):
587         * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Added.
588         (shouldBe):
589         (shouldBeAsync):
590         (shouldThrowAsync):
591         (C1):
592         (C2):
593         (shouldThrowAsync.async):
594         * tests/stress/async_arrow_functions_lexical_super_binding.js: Added.
595         (shouldBe):
596         (shouldBeAsync):
597         (BaseClass.prototype.baseClassValue):
598         (BaseClass):
599         (ChildClass.prototype.asyncSuperProp):
600         (ChildClass.prototype.asyncSuperProp2):
601         (ChildClass):
602         * tests/stress/async_arrow_functions_lexical_this_binding.js: Added.
603         (shouldBe):
604         (shouldBeAsync):
605         (d.y):
606
607 2016-05-27  Saam barati  <sbarati@apple.com>
608
609         DebuggerCallFrame crashes when updated with the globalExec because neither ShadowChicken's algorithm nor StackVisitor's algorithm reasons about the globalExec
610         https://bugs.webkit.org/show_bug.cgi?id=158104
611
612         Reviewed by Filip Pizlo.
613
614         I think globalExec is a special enough case that it should be handled
615         at the layers above ShadowChicken and StackVisitor. Those APIs should
616         deal with real stack frames on the machine stack, not a heap constructed frame.
617
618         This patch makes DebuggerCallFrame::create aware that it may be
619         created with the globalObject->globalExec() by having it construct
620         a single DebuggerCallFrame that wraps the globalExec.
621
622         This fixes a crasher because we will construct a DebuggerCallFrame
623         with the globalExec when the Inspector is set to pause on all uncaught
624         exceptions and the JS program has a syntax error. Because the program
625         hasn't begun execution, there is no machine JS stack frame yet. So
626         DebuggerCallFrame is created with globalExec, which will cause it
627         to hit an assertion that dictates that the stack have size greater
628         than zero.
629
630         * debugger/DebuggerCallFrame.cpp:
631         (JSC::DebuggerCallFrame::create):
632
633 2016-05-27  Filip Pizlo  <fpizlo@apple.com>
634
635         DFG::LazyJSValue::tryGetStringImpl() crashes for empty values
636         https://bugs.webkit.org/show_bug.cgi?id=158170
637
638         Reviewed by Michael Saboff.
639
640         The problem here is that jsDynamicCast<>() is evil! It avoids checking for the empty
641         value, presumably because this makes it soooper fast. In DFG IR, empty values can appear
642         anywhere because of TDZ.
643         
644         This patch doesn't change jsDynamicCast<>(), but it hardens our wrappers for it in the DFG
645         and it has the affected code use one of those wrappers.
646         
647         * dfg/DFGFrozenValue.h:
648         (JSC::DFG::FrozenValue::dynamicCast): Harden this.
649         (JSC::DFG::FrozenValue::cast):
650         * dfg/DFGLazyJSValue.cpp:
651         (JSC::DFG::LazyJSValue::tryGetStringImpl): Use the hardened wrapper.
652         * tests/stress/strcat-emtpy.js: Added. This used to crash every time.
653         (foo):
654         (i.catch):
655
656 2016-05-27  Filip Pizlo  <fpizlo@apple.com>
657
658         regExpProtoFuncSplitFast should OOM before it swaps
659         https://bugs.webkit.org/show_bug.cgi?id=158157
660
661         Reviewed by Mark Lam.
662         
663         This is a huge speed-up on some jsfunfuzz test cases because it makes us realize much
664         sooner that running a regexp split will result in swapping. It uses the same basic
665         approach as http://trac.webkit.org/changeset/201451: if the result array crosses a certain
666         size threshold, we proceed with a dry run to see how big the array will get before
667         allocating anything else. This way, bogus uses of split that would have OOMed only after
668         killing the user's machine will now OOM before killing the user's machine.
669         
670         This is an enormous speed-up on some jsfunfuzz tests: they go from running for a long
671         time to running instantly.
672
673         * runtime/RegExpPrototype.cpp:
674         (JSC::advanceStringIndex):
675         (JSC::genericSplit):
676         (JSC::regExpProtoFuncSplitFast):
677         * runtime/StringObject.h:
678         (JSC::jsStringWithReuse):
679         (JSC::jsSubstring):
680         * tests/stress/big-split-captures.js: Added.
681         * tests/stress/big-split.js: Added.
682
683 2016-05-27  Saam barati  <sbarati@apple.com>
684
685         ShadowChicken/DebuggerCallFrame don't properly handle when the entry stack frame is a tail deleted frame
686         https://bugs.webkit.org/show_bug.cgi?id=158131
687
688         Reviewed by Yusuke Suzuki.
689
690         There were bugs both in DebuggerCallFrame and ShadowChicken when the entry stack
691         frame(s) are tail deleted.
692
693         DebuggerCallFrame had an assertion saying that the entry frame shouldn't be
694         tail deleted. This is clearly wrong. The following program proves that this assertion
695         was misguided:
696         ```
697         "use strict";
698         setTimeout(function foo() { return bar(); }, 0);
699         ```
700
701         ShadowChicken had a very subtle bug when creating the shadow stack when 
702         the entry frames of the stack were tail deleted. Because it places frames into its shadow
703         stack by walking the machine frame and looking up entries in the log,
704         the machine frame doesn't have any notion of those tail deleted frames
705         at the entry of execution. ShadowChicken would never find those frames
706         because it would look for tail deleted frames *before* consulting the
707         current machine frame. This is wrong because if the entry frames
708         are tail deleted, then there is no machine frame for them because there
709         is no machine frame before them! Therefore, we must search for tail deleted
710         frames *after* consulting a machine frame. This is sound because we will always
711         have at least one machine frame on the stack (when we are using StackVisitor on a valid ExecState).
712         So when we consult the machine frame that is the entry frame on the machine stack,
713         we will search for tail deleted frames that come before it in the shadow stack.
714         This will allow us to find those tail deleted frames that are the entry frames
715         for the shadow stack.
716
717         * debugger/DebuggerCallFrame.cpp:
718         (JSC::DebuggerCallFrame::create):
719         * interpreter/ShadowChicken.cpp:
720         (JSC::ShadowChicken::Packet::dump):
721         (JSC::ShadowChicken::update):
722         (JSC::ShadowChicken::dump):
723
724 2016-05-27  Chris Dumez  <cdumez@apple.com>
725
726         WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables
727         https://bugs.webkit.org/show_bug.cgi?id=158111
728
729         Reviewed by Darin Adler.
730
731         WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables.
732         These are often used cross-thread and copying the captured lambda variables can be
733         dangerous (e.g. we do not want to copy a String after calling isolatedCopy() upon
734         capture).
735
736         * runtime/Watchdog.cpp:
737         (JSC::Watchdog::startTimer):
738         (JSC::Watchdog::Watchdog): Deleted.
739         (JSC::Watchdog::setTimeLimit): Deleted.
740         * runtime/Watchdog.h:
741
742 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
743
744         Removed unused headers from ExecutableAllocatorFixedVMPool.cpp.
745         https://bugs.webkit.org/show_bug.cgi?id=158159
746
747         Reviewed by Darin Adler.
748
749         * jit/ExecutableAllocatorFixedVMPool.cpp:
750
751 2016-05-27  Keith Miller  <keith_miller@apple.com>
752
753         get_by_id should support caching unset properties in the LLInt
754         https://bugs.webkit.org/show_bug.cgi?id=158136
755
756         Reviewed by Benjamin Poulain.
757
758         Recently, we started supporting prototype load caching for get_by_id
759         in the LLInt. This patch extends that to caching unset properties.
760         While it is uncommon in general for a program to see a single structure
761         without a given property, the Array.prototype.concat function needs to
762         lookup the Symbol.isConcatSpreadable property. For any existing code
763         That property will never be set as it did not exist prior to ES6.
764
765         Similarly to the get_by_id_proto_load bytecode, this patch adds a new
766         bytecode, get_by_id_unset that checks the structureID of the base and
767         assigns undefined to the result.
768
769         There are no new tests here since we already have many tests that
770         incidentally cover this change.
771
772         * bytecode/BytecodeList.json:
773         * bytecode/BytecodeUseDef.h:
774         (JSC::computeUsesForBytecodeOffset):
775         (JSC::computeDefsForBytecodeOffset):
776         * bytecode/CodeBlock.cpp:
777         (JSC::CodeBlock::printGetByIdOp):
778         (JSC::CodeBlock::dumpBytecode):
779         (JSC::CodeBlock::finalizeLLIntInlineCaches):
780         * bytecode/GetByIdStatus.cpp:
781         (JSC::GetByIdStatus::computeFromLLInt):
782         * dfg/DFGByteCodeParser.cpp:
783         (JSC::DFG::ByteCodeParser::parseBlock):
784         * dfg/DFGCapabilities.cpp:
785         (JSC::DFG::capabilityLevel):
786         * jit/JIT.cpp:
787         (JSC::JIT::privateCompileMainPass):
788         (JSC::JIT::privateCompileSlowCases):
789         * llint/LLIntSlowPaths.cpp:
790         (JSC::LLInt::setupGetByIdPrototypeCache):
791         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
792         * llint/LLIntSlowPaths.h:
793         * llint/LowLevelInterpreter32_64.asm:
794         * llint/LowLevelInterpreter64.asm:
795
796 2016-05-26  Filip Pizlo  <fpizlo@apple.com>
797
798         Bogus uses of regexp matching should realize that they will OOM before they start swapping
799         https://bugs.webkit.org/show_bug.cgi?id=158142
800
801         Reviewed by Michael Saboff.
802         
803         Refactored the RegExpObject::matchGlobal() code so that there is less duplication. Took
804         advantage of this to make the code more resilient in case of absurd situations: if the
805         result array gets large, it proceeds with a dry run to detect how many matches there will
806         be. This allows it to OOM before it starts swapping.
807         
808         This also improves the overall performance of the code by using lightweight substrings and
809         skipping the whole intermediate argument array.
810         
811         This makes some jsfunfuzz tests run a lot faster and use a lot less memory.
812         
813         * builtins/RegExpPrototype.js:
814         * CMakeLists.txt:
815         * JavaScriptCore.xcodeproj/project.pbxproj:
816         * runtime/MatchResult.cpp: Added.
817         (JSC::MatchResult::dump):
818         * runtime/MatchResult.h:
819         (JSC::MatchResult::empty):
820         (MatchResult::empty): Deleted.
821         * runtime/RegExpObject.cpp:
822         (JSC::RegExpObject::match):
823         (JSC::collectMatches):
824         (JSC::RegExpObject::matchGlobal):
825         * runtime/StringObject.h:
826         (JSC::jsStringWithReuse):
827         (JSC::jsSubstring):
828         * tests/stress/big-match.js: Added. Make sure that this optimization doesn't break big matches.
829
830 2016-05-26  Gavin & Ellie Barraclough  <barraclough@apple.com>
831
832         Static table property lookup should not require getOwnPropertySlot override.
833         https://bugs.webkit.org/show_bug.cgi?id=158059
834
835         Reviewed by Darin Adler.
836
837         Currently JSObject does not handle property lookup of entries in the static
838         table. Each subclass with static properties mut override getOwnPropertySlot,
839         and explicitly call the lookup functions. This has the following drawbacks:
840
841         - Performance: for any class with static properties, property acces becomes
842           virtual (via method table).
843         - Poor encapsulation: implementation detail of static property access is
844           spread throughout & cross projects, rather than being contained in JSObject.
845         - Code size: this results in a great many additional functions.
846         - Inconsistency: static table presence has to be be taken into account in many
847           other operations, e.g. presence of read-only properties for put.
848         - Memory: in order to avoid the virtual lookup, DOM prototypes eagerly reify
849           all properties. This is likely suboptimal.
850
851         Instead, JSObject::getPropertySlot / JSObject::getOwnPropertySlot should be
852         able to handle static properties.
853
854         This is actually a fairly small & simple change.
855
856         The common pattern is for subclasses of JObject to override getOwnPropertySlot
857         to first defer to JSObject for property storage lookup, and only if this fails
858         consult the static table. They just want the static tables to be consulted after
859         regular property storgae lookup. So just add a fast flag in TypeInfo for JSObject
860         to check, and where it is set, do so. Then it's just a question of switching
861         classes over to start setting this flag, and drop the override.
862
863         The new mechanism does change static table lookup order from oldest-ancestor
864         first to most-derived first. The new ordering makes more sense (means derived
865         class static tables can now override entries from parents), and shoudn't affect
866         any existing code (since overriding didn't previously work, there likely aren't
867         shadowing properties in more derived types).
868
869         This patch changes all classes in JavaScriptCore over to using the new mechanism,
870         except JSGlobalObject. I'll move classes in WebCore over as a separate patch
871         (this is also why I've not moved JSGlobalObject in this patch - doing so would
872         move JSDOMWindow, and I'd rather handle that separately).
873
874         * runtime/JSTypeInfo.h:
875         (JSC::TypeInfo::hasStaticPropertyTable):
876             - Add HasStaticPropertyTable flag.
877         * runtime/Lookup.cpp:
878         (JSC::setUpStaticFunctionSlot):
879             - Change setUpStaticFunctionSlot to take a VM&.
880         * runtime/Lookup.h:
881         (JSC::getStaticPropertySlotFromTable):
882             - Added helper function to perform static lookup alone.
883         (JSC::getStaticPropertySlot):
884         (JSC::getStaticFunctionSlot):
885             - setUpStaticFunctionSlot changed to take a VM&.
886         * runtime/JSObject.cpp:
887         (JSC::JSObject::getOwnStaticPropertySlot):
888             - Added, walks ClassInfo chain looking for static properties.
889         * runtime/JSObject.h:
890         (JSC::JSObject::getOwnNonIndexPropertySlot):
891             - getOwnNonIndexPropertySlot is used internally by getPropertySlot
892               & getOwnPropertySlot. If property is not present in storage array
893               then check the static table.
894         * runtime/ArrayConstructor.cpp:
895         (JSC::ArrayConstructor::finishCreation):
896         (JSC::constructArrayWithSizeQuirk):
897         (JSC::ArrayConstructor::getOwnPropertySlot): Deleted.
898         * runtime/ArrayConstructor.h:
899         (JSC::ArrayConstructor::create):
900         * runtime/ArrayIteratorPrototype.cpp:
901         (JSC::ArrayIteratorPrototype::finishCreation):
902         (JSC::ArrayIteratorPrototype::getOwnPropertySlot): Deleted.
903         * runtime/ArrayIteratorPrototype.h:
904         (JSC::ArrayIteratorPrototype::create):
905         (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype):
906         * runtime/BooleanPrototype.cpp:
907         (JSC::BooleanPrototype::finishCreation):
908         (JSC::booleanProtoFuncToString):
909         (JSC::BooleanPrototype::getOwnPropertySlot): Deleted.
910         * runtime/BooleanPrototype.h:
911         (JSC::BooleanPrototype::create):
912         * runtime/DateConstructor.cpp:
913         (JSC::DateConstructor::finishCreation):
914         (JSC::millisecondsFromComponents):
915         (JSC::DateConstructor::getOwnPropertySlot): Deleted.
916         * runtime/DateConstructor.h:
917         (JSC::DateConstructor::create):
918         * runtime/DatePrototype.cpp:
919         (JSC::DatePrototype::finishCreation):
920         (JSC::dateProtoFuncToString):
921         (JSC::DatePrototype::getOwnPropertySlot): Deleted.
922         * runtime/DatePrototype.h:
923         (JSC::DatePrototype::create):
924         * runtime/ErrorPrototype.cpp:
925         (JSC::ErrorPrototype::finishCreation):
926         (JSC::ErrorPrototype::getOwnPropertySlot): Deleted.
927         * runtime/ErrorPrototype.h:
928         (JSC::ErrorPrototype::create):
929         * runtime/GeneratorPrototype.cpp:
930         (JSC::GeneratorPrototype::finishCreation):
931         (JSC::GeneratorPrototype::getOwnPropertySlot): Deleted.
932         * runtime/GeneratorPrototype.h:
933         (JSC::GeneratorPrototype::create):
934         (JSC::GeneratorPrototype::createStructure):
935         (JSC::GeneratorPrototype::GeneratorPrototype):
936         * runtime/InspectorInstrumentationObject.cpp:
937         (JSC::InspectorInstrumentationObject::finishCreation):
938         (JSC::InspectorInstrumentationObject::isEnabled):
939         (JSC::InspectorInstrumentationObject::getOwnPropertySlot): Deleted.
940         * runtime/InspectorInstrumentationObject.h:
941         (JSC::InspectorInstrumentationObject::create):
942         (JSC::InspectorInstrumentationObject::createStructure):
943         * runtime/IntlCollatorConstructor.cpp:
944         (JSC::IntlCollatorConstructor::getCallData):
945         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
946         (JSC::IntlCollatorConstructor::getOwnPropertySlot): Deleted.
947         * runtime/IntlCollatorConstructor.h:
948         * runtime/IntlCollatorPrototype.cpp:
949         (JSC::IntlCollatorPrototype::finishCreation):
950         (JSC::IntlCollatorFuncCompare):
951         (JSC::IntlCollatorPrototype::getOwnPropertySlot): Deleted.
952         * runtime/IntlCollatorPrototype.h:
953         * runtime/IntlDateTimeFormatConstructor.cpp:
954         (JSC::IntlDateTimeFormatConstructor::getCallData):
955         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
956         (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): Deleted.
957         * runtime/IntlDateTimeFormatConstructor.h:
958         * runtime/IntlDateTimeFormatPrototype.cpp:
959         (JSC::IntlDateTimeFormatPrototype::finishCreation):
960         (JSC::IntlDateTimeFormatFuncFormatDateTime):
961         (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): Deleted.
962         * runtime/IntlDateTimeFormatPrototype.h:
963         * runtime/IntlNumberFormatConstructor.cpp:
964         (JSC::IntlNumberFormatConstructor::getCallData):
965         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
966         (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): Deleted.
967         * runtime/IntlNumberFormatConstructor.h:
968         * runtime/IntlNumberFormatPrototype.cpp:
969         (JSC::IntlNumberFormatPrototype::finishCreation):
970         (JSC::IntlNumberFormatFuncFormatNumber):
971         (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): Deleted.
972         * runtime/IntlNumberFormatPrototype.h:
973         * runtime/JSDataViewPrototype.cpp:
974         (JSC::JSDataViewPrototype::createStructure):
975         (JSC::getData):
976         (JSC::JSDataViewPrototype::getOwnPropertySlot): Deleted.
977         * runtime/JSDataViewPrototype.h:
978         * runtime/JSInternalPromiseConstructor.cpp:
979         (JSC::JSInternalPromiseConstructor::getCallData):
980         (JSC::JSInternalPromiseConstructor::getOwnPropertySlot): Deleted.
981         * runtime/JSInternalPromiseConstructor.h:
982         * runtime/JSONObject.cpp:
983         (JSC::Walker::Walker):
984         (JSC::JSONObject::getOwnPropertySlot): Deleted.
985         * runtime/JSONObject.h:
986         (JSC::JSONObject::create):
987         * runtime/JSPromiseConstructor.cpp:
988         (JSC::JSPromiseConstructor::getCallData):
989         (JSC::JSPromiseConstructor::getOwnPropertySlot): Deleted.
990         * runtime/JSPromiseConstructor.h:
991         * runtime/JSPromisePrototype.cpp:
992         (JSC::JSPromisePrototype::addOwnInternalSlots):
993         (JSC::JSPromisePrototype::getOwnPropertySlot): Deleted.
994         * runtime/JSPromisePrototype.h:
995         * runtime/MapPrototype.cpp:
996         (JSC::MapPrototype::finishCreation):
997         (JSC::getMap):
998         (JSC::MapPrototype::getOwnPropertySlot): Deleted.
999         * runtime/MapPrototype.h:
1000         (JSC::MapPrototype::create):
1001         (JSC::MapPrototype::MapPrototype):
1002         * runtime/ModuleLoaderObject.cpp:
1003         (JSC::ModuleLoaderObject::finishCreation):
1004         (JSC::printableModuleKey):
1005         (JSC::ModuleLoaderObject::getOwnPropertySlot): Deleted.
1006         * runtime/ModuleLoaderObject.h:
1007         * runtime/NumberPrototype.cpp:
1008         (JSC::NumberPrototype::finishCreation):
1009         (JSC::toThisNumber):
1010         (JSC::NumberPrototype::getOwnPropertySlot): Deleted.
1011         * runtime/NumberPrototype.h:
1012         (JSC::NumberPrototype::create):
1013         * runtime/ObjectConstructor.cpp:
1014         (JSC::ObjectConstructor::addDefineProperty):
1015         (JSC::constructObject):
1016         (JSC::ObjectConstructor::getOwnPropertySlot): Deleted.
1017         * runtime/ObjectConstructor.h:
1018         (JSC::ObjectConstructor::create):
1019         (JSC::ObjectConstructor::createStructure):
1020         * runtime/ReflectObject.cpp:
1021         (JSC::ReflectObject::finishCreation):
1022         (JSC::ReflectObject::getOwnPropertySlot): Deleted.
1023         * runtime/ReflectObject.h:
1024         (JSC::ReflectObject::create):
1025         (JSC::ReflectObject::createStructure):
1026         * runtime/RegExpConstructor.cpp:
1027         (JSC::RegExpConstructor::getRightContext):
1028         (JSC::regExpConstructorDollar):
1029         (JSC::RegExpConstructor::getOwnPropertySlot): Deleted.
1030         * runtime/RegExpConstructor.h:
1031         (JSC::RegExpConstructor::create):
1032         (JSC::RegExpConstructor::createStructure):
1033         * runtime/SetPrototype.cpp:
1034         (JSC::SetPrototype::finishCreation):
1035         (JSC::getSet):
1036         (JSC::SetPrototype::getOwnPropertySlot): Deleted.
1037         * runtime/SetPrototype.h:
1038         (JSC::SetPrototype::create):
1039         (JSC::SetPrototype::SetPrototype):
1040         * runtime/StringConstructor.cpp:
1041         (JSC::StringConstructor::finishCreation):
1042         (JSC::stringFromCharCodeSlowCase):
1043         (JSC::StringConstructor::getOwnPropertySlot): Deleted.
1044         * runtime/StringConstructor.h:
1045         (JSC::StringConstructor::create):
1046         * runtime/StringIteratorPrototype.cpp:
1047         (JSC::StringIteratorPrototype::finishCreation):
1048         (JSC::StringIteratorPrototype::getOwnPropertySlot): Deleted.
1049         * runtime/StringIteratorPrototype.h:
1050         (JSC::StringIteratorPrototype::create):
1051         (JSC::StringIteratorPrototype::StringIteratorPrototype):
1052         * runtime/StringPrototype.cpp:
1053         (JSC::StringPrototype::create):
1054         (JSC::substituteBackreferencesSlow):
1055         (JSC::StringPrototype::getOwnPropertySlot): Deleted.
1056         * runtime/StringPrototype.h:
1057         * runtime/SymbolConstructor.cpp:
1058         (JSC::SymbolConstructor::finishCreation):
1059         (JSC::callSymbol):
1060         (JSC::SymbolConstructor::getOwnPropertySlot): Deleted.
1061         * runtime/SymbolConstructor.h:
1062         (JSC::SymbolConstructor::create):
1063         * runtime/SymbolPrototype.cpp:
1064         (JSC::SymbolPrototype::finishCreation):
1065         (JSC::SymbolPrototype::getOwnPropertySlot): Deleted.
1066         * runtime/SymbolPrototype.h:
1067         (JSC::SymbolPrototype::create):
1068             - remove getOwnPropertySlot, replace OverridesGetOwnPropertySlot flag with HasStaticPropertyTable.
1069
1070 2016-05-26  Commit Queue  <commit-queue@webkit.org>
1071
1072         Unreviewed, rolling out r201436.
1073         https://bugs.webkit.org/show_bug.cgi?id=158143
1074
1075         Caused 30% regression on Dromaeo DOM core tests (Requested by
1076         rniwa on #webkit).
1077
1078         Reverted changeset:
1079
1080         "REGRESSION: JSBench spends a lot of time transitioning
1081         to/from dictionary"
1082         https://bugs.webkit.org/show_bug.cgi?id=158045
1083         http://trac.webkit.org/changeset/201436
1084
1085 2016-05-26  Geoffrey Garen  <ggaren@apple.com>
1086
1087         REGRESSION: JSBench spends a lot of time transitioning to/from dictionary
1088         https://bugs.webkit.org/show_bug.cgi?id=158045
1089
1090         Reviewed by Saam Barati.
1091
1092         15% speedup on jsbench-amazon-firefox, possibly 5% speedup overall on jsbench.
1093
1094         This regression seems to have two parts:
1095
1096         (1) Transitioning the window object to/from dictionary is more expensive
1097         than it used to be to because the window object has lots more properties.
1098         The window object has more properties because, for WebIDL compatibility,
1099         we reify DOM APIs as properties when you delete.
1100
1101         (2) DOM prototypes transition to/from dictionary upon creation
1102         because, once again for WebIDL compatibility, we reify their static
1103         APIs eagerly.
1104
1105         The solution is to chill out a bit on dictionary transitions.
1106
1107         * bytecode/ObjectPropertyConditionSet.cpp: Don't flatten a dictionary
1108         if we've already done so before. This avoids pathological churn, and it
1109         is our idiom in other places.
1110
1111         * interpreter/Interpreter.cpp:
1112         (JSC::Interpreter::execute): Do flatten the global object unconditionally
1113         if it is an uncacheable dictionary because the global object is super
1114         important.
1115
1116         * runtime/BatchedTransitionOptimizer.h:
1117         (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer):
1118         (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): Deleted.
1119         Don't transition away from dictionary after a batched set of property
1120         puts because normal dictionaries are cacheable and that's a perfectly
1121         fine state to be in -- and the transition is expensive.
1122
1123         * runtime/JSGlobalObject.cpp:
1124         (JSC::JSGlobalObject::init): Do start the global object out as a cacheable
1125         dictionary because it will inevitably have enough properties to become
1126         a dictionary.
1127
1128         * runtime/Operations.h:
1129         (JSC::normalizePrototypeChain): Same as ObjectPropertyConditionSet.cpp.
1130
1131 2016-05-25  Geoffrey Garen  <ggaren@apple.com>
1132
1133         replaceable own properties seem to ignore replacement after property caching
1134         https://bugs.webkit.org/show_bug.cgi?id=158091
1135
1136         Reviewed by Darin Adler.
1137
1138         * runtime/Lookup.h:
1139         (JSC::replaceStaticPropertySlot): New helper function for replacing a
1140         static property with a direct property. We need to do an attribute changed
1141         transition because client code might have cached our static property.
1142
1143 2016-05-25  Benjamin Poulain  <benjamin@webkit.org>
1144
1145         [JSC] RegExp with deeply nested subexpressions overflow the stack in Yarr
1146         https://bugs.webkit.org/show_bug.cgi?id=158011
1147         rdar://problem/25946592
1148
1149         Reviewed by Saam Barati.
1150
1151         When generating the meta-data required for compilation,
1152         Yarr uses a recursive function over the various expression in the pattern.
1153
1154         If you have many nested expressions, you can run out of stack
1155         and crash the WebProcess.
1156         This patch changes that into a soft failure. The expression is just
1157         considered invalid.
1158
1159         * runtime/RegExp.cpp:
1160         (JSC::RegExp::finishCreation):
1161         (JSC::RegExp::compile):
1162         (JSC::RegExp::compileMatchOnly):
1163         * yarr/YarrPattern.cpp:
1164         (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
1165         (JSC::Yarr::YarrPatternConstructor::setupOffsets):
1166         (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):
1167         (JSC::Yarr::YarrPattern::compile):
1168         (JSC::Yarr::YarrPattern::YarrPattern):
1169         (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): Deleted.
1170         (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): Deleted.
1171         * yarr/YarrPattern.h:
1172
1173 2016-05-25  Alex Christensen  <achristensen@webkit.org>
1174
1175         Fix Win64 build after r201335
1176         https://bugs.webkit.org/show_bug.cgi?id=158078
1177
1178         Reviewed by Mark Lam.
1179
1180         * offlineasm/x86.rb:
1181         Add intel implementations for loadbs and loadhs
1182
1183 2016-05-25  Carlos Garcia Campos  <cgarcia@igalia.com>
1184
1185         REGRESSION(r201066): [GTK] Several intl tests started to fail in GTK+ bot after r201066
1186         https://bugs.webkit.org/show_bug.cgi?id=158066
1187
1188         Reviewed by Darin Adler.
1189
1190         run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment
1191         variables at all when using jsc binary. We are using setlocale() with a nullptr locale to get the current one, but
1192         the current one is always "C", because to set the locale according to the environment variables we need to call
1193         setlocale with an empty string as locale. That's done by gtk_init(), which is called by all our binaries (web
1194         process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has
1195         always worked for EFL is because they call ecore_init() in jsc that calls setlocale.
1196
1197         * jsc.cpp:
1198         (main): Call setlocale(LC_ALL, "") on GTK+.
1199
1200 2016-05-25  Csaba Osztrogon√°c  <ossy@webkit.org>
1201
1202         [ARM] Fix the Wcast-align warning in LinkBuffer.cpp
1203         https://bugs.webkit.org/show_bug.cgi?id=157889
1204
1205         Reviewed by Darin Adler.
1206
1207         * assembler/LinkBuffer.cpp:
1208         (JSC::recordLinkOffsets):
1209
1210 2016-05-24  Keith Miller  <keith_miller@apple.com>
1211
1212         TypedArray.prototype.slice should not throw if no arguments are provided
1213         https://bugs.webkit.org/show_bug.cgi?id=158044
1214         <rdar://problem/26433280>
1215
1216         Reviewed by Geoffrey Garen.
1217
1218         We were throwing an exception if the TypedArray.prototype.slice function
1219         was not provided arguments. This was wrong. Instead we should just assume
1220         the first argument was 0.
1221
1222         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1223         (JSC::genericTypedArrayViewProtoFuncSlice): Deleted.
1224         * tests/stress/typedarray-slice.js:
1225
1226 2016-05-24  Keith Miller  <keith_miller@apple.com>
1227
1228         LLInt should be able to cache prototype loads for values in GetById
1229         https://bugs.webkit.org/show_bug.cgi?id=158032
1230
1231         Reviewed by Filip Pizlo.
1232
1233         This patch adds prototype value caching to the LLInt for op_get_by_id.
1234         Two previously unused words in the op_get_by_id bytecode have been
1235         repurposed to hold extra information for the cache. The first is a
1236         counter that records the number of get_by_ids that hit a cacheable value
1237         on a prototype. When the counter is decremented from one to zero we
1238         attempt to cache the prototype load, which will be discussed further
1239         below. The second word is used to hold the prototype object when we have
1240         started caching.
1241
1242         When the counter is decremented to zero we first attempt to generate and
1243         watch the property conditions needed to ensure the validity of prototype
1244         load. If the watchpoints are successfully created and installed we
1245         replace the op_get_by_id opcode with the new op_get_by_id_proto_load
1246         opcode, which tells the LLInt to use the cache prototype object for the
1247         load rather than the base value.
1248
1249         Prior to this patch there was not LLInt specific data onCodeBlocks.
1250         Since the CodeBlock needs to own the Watchpoints for the cache, a weak
1251         map from each base structure to a bag of Watchpoints created for that
1252         structure by some op_get_by_id has been added to the CodeBlock. During
1253         GC, if we find that the a structure in the map has not been marked we
1254         free the associated bag on the CodeBlock.
1255
1256         * JavaScriptCore.xcodeproj/project.pbxproj:
1257         * bytecode/BytecodeList.json:
1258         * bytecode/BytecodeUseDef.h:
1259         (JSC::computeUsesForBytecodeOffset):
1260         (JSC::computeDefsForBytecodeOffset):
1261         * bytecode/CodeBlock.cpp:
1262         (JSC::CodeBlock::printGetByIdOp):
1263         (JSC::CodeBlock::printGetByIdCacheStatus):
1264         (JSC::CodeBlock::dumpBytecode):
1265         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1266         * bytecode/CodeBlock.h:
1267         (JSC::CodeBlock::llintGetByIdWatchpointMap):
1268         (JSC::clearLLIntGetByIdCache):
1269         * bytecode/GetByIdStatus.cpp:
1270         (JSC::GetByIdStatus::computeFromLLInt):
1271         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: Added.
1272         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
1273         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::install):
1274         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
1275         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: Added.
1276         * bytecode/ObjectPropertyConditionSet.cpp:
1277         (JSC::ObjectPropertyConditionSet::isValidAndWatchable):
1278         * bytecode/ObjectPropertyConditionSet.h:
1279         * bytecompiler/BytecodeGenerator.cpp:
1280         (JSC::BytecodeGenerator::emitGetById):
1281         * dfg/DFGByteCodeParser.cpp:
1282         (JSC::DFG::ByteCodeParser::parseBlock):
1283         * dfg/DFGCapabilities.cpp:
1284         (JSC::DFG::capabilityLevel):
1285         * jit/JIT.cpp:
1286         (JSC::JIT::privateCompileMainPass):
1287         (JSC::JIT::privateCompileSlowCases):
1288         * llint/LLIntSlowPaths.cpp:
1289         (JSC::LLInt::setupGetByIdPrototypeCache):
1290         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1291         * llint/LLIntSlowPaths.h:
1292         * llint/LowLevelInterpreter32_64.asm:
1293         * llint/LowLevelInterpreter64.asm:
1294         * runtime/Options.h:
1295         * tests/stress/llint-get-by-id-cache-prototype-load-from-dictionary.js: Added.
1296         (test):
1297
1298 2016-05-24  Keith Miller  <keith_miller@apple.com>
1299
1300         We should be able to use the sampling profiler with DRT/WTR.
1301         https://bugs.webkit.org/show_bug.cgi?id=158041
1302
1303         Reviewed by Saam Barati.
1304
1305         This patch makes the sampling profiler use a new option, samplingProfilerPath, which
1306         specifies the path to a directory to output sampling profiler data when the program
1307         terminates or the VM is destroyed. Additionally, it fixes some other issues with the
1308         bytecode profiler that would cause crashes on debug builds.
1309
1310         * profiler/ProfilerDatabase.cpp:
1311         (JSC::Profiler::Database::ensureBytecodesFor):
1312         (JSC::Profiler::Database::performAtExitSave):
1313         * runtime/Options.h:
1314         * runtime/SamplingProfiler.cpp:
1315         (JSC::SamplingProfiler::registerForReportAtExit):
1316         (JSC::SamplingProfiler::reportDataToOptionFile):
1317         (JSC::SamplingProfiler::reportTopFunctions):
1318         (JSC::SamplingProfiler::reportTopBytecodes):
1319         * runtime/SamplingProfiler.h:
1320         * runtime/VM.cpp:
1321         (JSC::VM::VM):
1322         (JSC::VM::~VM):
1323
1324 2016-05-24  Saam barati  <sbarati@apple.com>
1325
1326         We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation
1327         https://bugs.webkit.org/show_bug.cgi?id=158036
1328
1329         Reviewed by Geoffrey Garen.
1330
1331         This patch implements a 1 item cache for JSScope::abstractResolve. I also tried
1332         implementing the cache as a HashMap, but it seemed either less profitable on some
1333         benchmarks or just as profitable on others. Therefore, it's cleaner to just
1334         use a 1 item cache.
1335
1336         * bytecode/CodeBlock.cpp:
1337         (JSC::CodeBlock::CodeBlock):
1338         (JSC::AbstractResolveKey::AbstractResolveKey):
1339         (JSC::AbstractResolveKey::operator==):
1340         (JSC::AbstractResolveKey::isEmptyValue):
1341         (JSC::CodeBlock::finishCreation):
1342         * runtime/GetPutInfo.h:
1343         (JSC::needsVarInjectionChecks):
1344         (JSC::ResolveOp::ResolveOp):
1345
1346 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
1347
1348         Unreviwed, add a comment to describe the test's failure mode. Suggested by mlam.
1349
1350         * tests/stress/override-map-constructor.js:
1351         (Map):
1352
1353 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
1354
1355         Map should not be in JSGlobalObject's static hashtable because it's initialized eagerly via FOR_EACH_SIMPLE_BUILTIN_TYPE_WITH_CONSTRUCTOR
1356         https://bugs.webkit.org/show_bug.cgi?id=158031
1357         rdar://problem/26353661
1358
1359         Reviewed by Geoffrey Garen.
1360         
1361         We were listing Map as being a lazy class structure. It's not. m_mapStructure is a WriteBarrier<>
1362         not a LazyClassStructure<> and there is nothing lazy about it.
1363
1364         * runtime/JSGlobalObject.cpp: The fix is to remove Map here.
1365         * runtime/Lookup.cpp: Add some dumping on the assert path.
1366         (JSC::setUpStaticFunctionSlot):
1367         * tests/stress/override-map-constructor.js: Added. This test used to crash.
1368         (Map):
1369
1370 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
1371
1372         LLInt64 should have typed array fast paths for get_by_val
1373         https://bugs.webkit.org/show_bug.cgi?id=157931
1374
1375         Reviewed by Keith Miller.
1376
1377         I think that the LLInt should be able to access typed arrays more quickly than it does now.
1378         Ideally we would have fast paths for every major typed array operation and we would use
1379         inline cache optimizations. I don't want to do this all in one go, so my plan is to
1380         incrementally add support for this as time allows.
1381         
1382         This change just adds the easy typed array fast paths for get_by_val in the 64-bit version
1383         of LLInt.
1384         
1385         Another bug, https://bugs.webkit.org/show_bug.cgi?id=157922, tracks the overall task of
1386         adding all typed array fast paths to both versions of the LLInt.
1387         
1388         This is a 30% speed-up on typed array benchmarks in LLInt. This is not a speed-up when the
1389         JITs are enabled.
1390
1391         * llint/LLIntData.cpp:
1392         (JSC::LLInt::Data::performAssertions):
1393         * llint/LLIntOffsetsExtractor.cpp:
1394         * llint/LowLevelInterpreter.asm:
1395         * llint/LowLevelInterpreter64.asm:
1396         * offlineasm/backends.rb:
1397         * runtime/JSArrayBufferView.h:
1398         * runtime/JSType.h:
1399
1400 2016-05-24  Saam barati  <sbarati@apple.com> and Yusuke Suzuki <utatane.tea@gmail.com>
1401
1402         ThisTDZMode is no longer needed
1403         https://bugs.webkit.org/show_bug.cgi?id=157209
1404
1405         Reviewed by Saam Barati.
1406
1407         ThisTDZMode is no longer needed because we have ConstructorKind
1408         and DerivedContextType. The value of ThisTDZMode is strictly less
1409         expressive than the combination of those two values. We were
1410         using those values anyways, and this patch just makes it official
1411         by removing ThisTDZMode.
1412
1413         This patch also cleans up caching keys. We extract SourceCodeFlags
1414         from SourceCodeKey and use it in EvalCodeCache. It correctly
1415         contains needed cache attributes: EvalContextType, DerivedContextType,
1416         etc. Here, we still use specialized keys for EvalCodeCache instead
1417         of SourceCodeKey for performance; it does not include name String and
1418         does not allocate SourceCode.
1419
1420         * bytecode/EvalCodeCache.h:
1421         (JSC::EvalCodeCache::CacheKey::CacheKey):
1422         (JSC::EvalCodeCache::CacheKey::operator==):
1423         (JSC::EvalCodeCache::CacheKey::Hash::equal):
1424         (JSC::EvalCodeCache::tryGet):
1425         (JSC::EvalCodeCache::getSlow):
1426         * bytecompiler/NodesCodegen.cpp:
1427         (JSC::ThisNode::emitBytecode): Deleted.
1428         * debugger/DebuggerCallFrame.cpp:
1429         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
1430         * interpreter/Interpreter.cpp:
1431         (JSC::eval):
1432         * parser/ASTBuilder.h:
1433         (JSC::ASTBuilder::createThisExpr):
1434         * parser/NodeConstructors.h:
1435         (JSC::ThisNode::ThisNode):
1436         * parser/Nodes.h:
1437         * parser/Parser.cpp:
1438         (JSC::Parser<LexerType>::Parser):
1439         (JSC::Parser<LexerType>::parsePrimaryExpression):
1440         * parser/Parser.h:
1441         (JSC::parse):
1442         * parser/ParserModes.h:
1443         * parser/SourceCodeKey.h:
1444         (JSC::SourceCodeFlags::SourceCodeFlags):
1445         (JSC::SourceCodeFlags::operator==):
1446         (JSC::SourceCodeKey::SourceCodeKey):
1447         (JSC::SourceCodeKey::Hash::hash):
1448         (JSC::SourceCodeKey::Hash::equal):
1449         (JSC::SourceCodeKey::HashTraits::isEmptyValue):
1450         (JSC::SourceCodeKeyHash::hash): Deleted.
1451         (JSC::SourceCodeKeyHash::equal): Deleted.
1452         (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
1453         * parser/SyntaxChecker.h:
1454         (JSC::SyntaxChecker::createThisExpr):
1455         * runtime/CodeCache.cpp:
1456         (JSC::CodeCache::getGlobalCodeBlock):
1457         (JSC::CodeCache::getProgramCodeBlock):
1458         (JSC::CodeCache::getEvalCodeBlock):
1459         (JSC::CodeCache::getModuleProgramCodeBlock):
1460         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1461         * runtime/CodeCache.h:
1462         * runtime/Executable.cpp:
1463         (JSC::EvalExecutable::create):
1464         * runtime/Executable.h:
1465         * runtime/JSGlobalObject.cpp:
1466         (JSC::JSGlobalObject::createEvalCodeBlock):
1467         * runtime/JSGlobalObject.h:
1468         * runtime/JSGlobalObjectFunctions.cpp:
1469         (JSC::globalFuncEval):
1470         * tests/stress/code-cache-incorrect-caching.js: Added.
1471         (shouldBe):
1472         (hello):
1473         (catch):
1474         (shouldBe.test.hello):
1475         (globalEval.ok):
1476         (global.hello.hello):
1477
1478 2016-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>
1479
1480         Assertion failure for Reflect.get with Proxy and primitive value as explicit receiver
1481         https://bugs.webkit.org/show_bug.cgi?id=157080
1482
1483         Reviewed by Saam Barati.
1484
1485         In custom accessor getter, the argument "thisValue" can be altered by using `Reflect.get`.
1486         In this patch, we add a new parameter, "slotBase". This represents the base value offering
1487         this custom getter. And use it in ProxyObject's performGet custom accessor getter.
1488
1489         * API/JSCallbackObject.h:
1490         * API/JSCallbackObjectFunctions.h:
1491         (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
1492         (JSC::JSCallbackObject<Parent>::callbackGetter):
1493         * bytecode/PolymorphicAccess.cpp:
1494         (JSC::AccessCase::generateImpl):
1495         In PolymorphicAccess case, the thisValue and the slotBase are always cells.
1496         This is because IC is enabled in the case that the base value is a cell.
1497         And slotBase is always on the prototype chain from this base value.
1498
1499         * jit/CCallHelpers.h:
1500         (JSC::CCallHelpers::setupArgumentsWithExecState):
1501         * jsc.cpp:
1502         (WTF::CustomGetter::customGetter):
1503         (WTF::RuntimeArray::lengthGetter):
1504         * runtime/CustomGetterSetter.cpp:
1505         (JSC::callCustomSetter):
1506         * runtime/JSBoundSlotBaseFunction.cpp:
1507         (JSC::boundSlotBaseFunctionCall):
1508         * runtime/JSFunction.cpp:
1509         (JSC::JSFunction::argumentsGetter):
1510         (JSC::JSFunction::callerGetter):
1511         * runtime/JSFunction.h:
1512         * runtime/JSModuleNamespaceObject.cpp:
1513         (JSC::callbackGetter):
1514         * runtime/PropertySlot.cpp:
1515         (JSC::PropertySlot::customGetter):
1516         * runtime/PropertySlot.h:
1517         * runtime/ProxyObject.cpp:
1518         (JSC::performProxyGet):
1519         * runtime/RegExpConstructor.cpp:
1520         (JSC::regExpConstructorDollar):
1521         (JSC::regExpConstructorInput):
1522         (JSC::regExpConstructorMultiline):
1523         (JSC::regExpConstructorLastMatch):
1524         (JSC::regExpConstructorLastParen):
1525         (JSC::regExpConstructorLeftContext):
1526         (JSC::regExpConstructorRightContext):
1527         (JSC::regExpConstructorDollar1): Deleted.
1528         (JSC::regExpConstructorDollar2): Deleted.
1529         (JSC::regExpConstructorDollar3): Deleted.
1530         (JSC::regExpConstructorDollar4): Deleted.
1531         (JSC::regExpConstructorDollar5): Deleted.
1532         (JSC::regExpConstructorDollar6): Deleted.
1533         (JSC::regExpConstructorDollar7): Deleted.
1534         (JSC::regExpConstructorDollar8): Deleted.
1535         (JSC::regExpConstructorDollar9): Deleted.
1536         * tests/stress/proxy-get-with-primitive-receiver.js: Added.
1537         (shouldBe):
1538
1539 2016-05-23  Geoffrey Garen  <ggaren@apple.com>
1540
1541         REGRESSION (196374): deleting a global property is expensive
1542         https://bugs.webkit.org/show_bug.cgi?id=158005
1543
1544         Reviewed by Chris Dumez.
1545
1546         * runtime/JSObject.cpp:
1547         (JSC::JSObject::deleteProperty): We only need to reify static properties
1548         if the name being deleted matches a static property. Otherwise, we can
1549         be sure that delete won't observe any static properties.
1550
1551 2016-05-23  Saam barati  <sbarati@apple.com>
1552
1553         The baseline JIT crashes when compiling "(1,1)/1"
1554         https://bugs.webkit.org/show_bug.cgi?id=157933
1555
1556         Reviewed by Benjamin Poulain.
1557
1558         op_div in the baseline JIT needed to better handle when both the lhs
1559         and rhs are constants. It needs to make sure to load either the lhs or
1560         the rhs into a register since the div generator can't handle both
1561         the lhs and rhs being constants.
1562
1563         * jit/JITArithmetic.cpp:
1564         (JSC::JIT::emit_op_div):
1565         * tests/stress/jit-gracefully-handle-double-constants-in-math-operators.js: Added.
1566         (assert):
1567         (test):
1568
1569 2016-05-23  Saam barati  <sbarati@apple.com>
1570
1571         String template don't handle let initialization properly inside eval
1572         https://bugs.webkit.org/show_bug.cgi?id=157991
1573
1574         Reviewed by Oliver Hunt.
1575
1576         The fix is to make sure we emit TDZ checks. 
1577
1578         * bytecompiler/NodesCodegen.cpp:
1579         (JSC::TaggedTemplateNode::emitBytecode):
1580         * tests/stress/tagged-template-tdz.js: Added.
1581         (shouldThrowTDZ):
1582         (test):
1583
1584 2016-05-22  Saam barati  <sbarati@apple.com>
1585
1586         Unreviewed. Fixed debug assertion failures from r201235.
1587
1588         * runtime/JSScope.cpp:
1589         (JSC::abstractAccess):
1590
1591 2016-05-22  Brady Eidson  <beidson@apple.com>
1592
1593         Attempted Yosemite build fix after http://trac.webkit.org/changeset/201255
1594
1595         Suggested by and reviewed by Anders Carlsson.
1596
1597         * b3/B3CCallValue.h: Initialize the effects member more conventionally.
1598
1599 2016-05-22  Brady Eidson  <beidson@apple.com>
1600
1601         Move to C++14.
1602         https://bugs.webkit.org/show_bug.cgi?id=157948
1603
1604         Reviewed by Michael Catanzaro.
1605
1606         * Configurations/Base.xcconfig:
1607
1608 2016-05-22  Saam barati  <sbarati@apple.com>
1609
1610         REGRESSION(r199075): String.prototype.replace fails after being used many times with different replace values
1611         https://bugs.webkit.org/show_bug.cgi?id=157968
1612         <rdar://problem/26404735>
1613
1614         Reviewed by Ryosuke Niwa and Filip Pizlo.
1615
1616         There was a bug in the DFG where we were checking a condition
1617         on the wrong variable.
1618
1619         * dfg/DFGStrengthReductionPhase.cpp:
1620         (JSC::DFG::StrengthReductionPhase::handleNode):
1621
1622 2016-05-22  Chris Dumez  <cdumez@apple.com>
1623
1624         Remove uses of PassRefPtr in JS bindings code
1625         https://bugs.webkit.org/show_bug.cgi?id=157949
1626
1627         Reviewed by Andreas Kling.
1628
1629         Remove uses of PassRefPtr in JS bindings code.
1630
1631         * runtime/JSGlobalObject.cpp:
1632         (JSC::JSGlobalObject::queueMicrotask):
1633         * runtime/JSGlobalObject.h:
1634
1635 2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>
1636
1637         Remove LegacyProfiler
1638         https://bugs.webkit.org/show_bug.cgi?id=153565
1639
1640         Reviewed by Mark Lam.
1641
1642         JavaScriptCore now provides a sampling profiler and it is enabled
1643         by all ports. Web Inspector switched months ago to using the
1644         sampling profiler and displaying its data. Remove the legacy
1645         profiler, as it is no longer being used by anything other then
1646         console.profile and tests. We will update console.profile's
1647         behavior soon to have new behavior and use the sampling data.
1648
1649         * API/JSProfilerPrivate.cpp: Removed.
1650         * API/JSProfilerPrivate.h: Removed.
1651         * CMakeLists.txt:
1652         * JavaScriptCore.xcodeproj/project.pbxproj:
1653         * bytecode/BytecodeList.json:
1654         * bytecode/BytecodeUseDef.h:
1655         (JSC::computeUsesForBytecodeOffset): Deleted.
1656         (JSC::computeDefsForBytecodeOffset): Deleted.
1657         * bytecode/CodeBlock.cpp:
1658         (JSC::CodeBlock::dumpBytecode): Deleted.
1659         * bytecode/UnlinkedFunctionExecutable.cpp:
1660         (JSC::generateUnlinkedFunctionCodeBlock):
1661         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1662         * bytecode/UnlinkedFunctionExecutable.h:
1663         * bytecompiler/BytecodeGenerator.cpp:
1664         (JSC::BytecodeGenerator::BytecodeGenerator):
1665         (JSC::BytecodeGenerator::emitCall):
1666         (JSC::BytecodeGenerator::emitCallVarargs):
1667         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
1668         (JSC::BytecodeGenerator::emitConstructVarargs):
1669         (JSC::BytecodeGenerator::emitConstruct):
1670         * bytecompiler/BytecodeGenerator.h:
1671         (JSC::CallArguments::profileHookRegister): Deleted.
1672         (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
1673         * bytecompiler/NodesCodegen.cpp:
1674         (JSC::CallFunctionCallDotNode::emitBytecode):
1675         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1676         (JSC::CallArguments::CallArguments): Deleted.
1677         * dfg/DFGAbstractInterpreterInlines.h:
1678         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
1679         * dfg/DFGByteCodeParser.cpp:
1680         (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
1681         * dfg/DFGCapabilities.cpp:
1682         (JSC::DFG::capabilityLevel): Deleted.
1683         * dfg/DFGClobberize.h:
1684         (JSC::DFG::clobberize): Deleted.
1685         * dfg/DFGDoesGC.cpp:
1686         (JSC::DFG::doesGC): Deleted.
1687         * dfg/DFGFixupPhase.cpp:
1688         (JSC::DFG::FixupPhase::fixupNode): Deleted.
1689         * dfg/DFGNodeType.h:
1690         * dfg/DFGPredictionPropagationPhase.cpp:
1691         * dfg/DFGSafeToExecute.h:
1692         (JSC::DFG::safeToExecute): Deleted.
1693         * dfg/DFGSpeculativeJIT32_64.cpp:
1694         (JSC::DFG::SpeculativeJIT::compile): Deleted.
1695         * dfg/DFGSpeculativeJIT64.cpp:
1696         (JSC::DFG::SpeculativeJIT::compile): Deleted.
1697         * inspector/InjectedScriptBase.cpp:
1698         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
1699         * interpreter/Interpreter.cpp:
1700         (JSC::UnwindFunctor::operator()): Deleted.
1701         (JSC::Interpreter::execute): Deleted.
1702         (JSC::Interpreter::executeCall): Deleted.
1703         (JSC::Interpreter::executeConstruct): Deleted.
1704         * jit/JIT.cpp:
1705         (JSC::JIT::privateCompileMainPass): Deleted.
1706         * jit/JIT.h:
1707         * jit/JITOpcodes.cpp:
1708         (JSC::JIT::emit_op_profile_will_call): Deleted.
1709         (JSC::JIT::emit_op_profile_did_call): Deleted.
1710         * jit/JITOpcodes32_64.cpp:
1711         (JSC::JIT::emit_op_profile_will_call): Deleted.
1712         (JSC::JIT::emit_op_profile_did_call): Deleted.
1713         * jit/JITOperations.cpp:
1714         * jit/JITOperations.h:
1715         * llint/LLIntSlowPaths.cpp:
1716         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
1717         * llint/LLIntSlowPaths.h:
1718         * llint/LowLevelInterpreter.asm:
1719         * parser/ParserModes.h:
1720         * profiler/CallIdentifier.h: Removed.
1721         * profiler/LegacyProfiler.cpp: Removed.
1722         * profiler/LegacyProfiler.h: Removed.
1723         * profiler/Profile.cpp: Removed.
1724         * profiler/Profile.h: Removed.
1725         * profiler/ProfileGenerator.cpp: Removed.
1726         * profiler/ProfileGenerator.h: Removed.
1727         * profiler/ProfileNode.cpp: Removed.
1728         * profiler/ProfileNode.h: Removed.
1729         * profiler/ProfilerJettisonReason.cpp:
1730         (WTF::printInternal): Deleted.
1731         * profiler/ProfilerJettisonReason.h:
1732         * runtime/CodeCache.cpp:
1733         (JSC::CodeCache::getGlobalCodeBlock):
1734         (JSC::CodeCache::getProgramCodeBlock):
1735         (JSC::CodeCache::getEvalCodeBlock):
1736         (JSC::CodeCache::getModuleProgramCodeBlock):
1737         * runtime/CodeCache.h:
1738         * runtime/Executable.cpp:
1739         (JSC::ScriptExecutable::newCodeBlockFor):
1740         * runtime/JSGlobalObject.cpp:
1741         (JSC::JSGlobalObject::createProgramCodeBlock):
1742         (JSC::JSGlobalObject::createEvalCodeBlock):
1743         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
1744         (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
1745         (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
1746         * runtime/JSGlobalObject.h:
1747         * runtime/Options.h:
1748         * runtime/VM.cpp:
1749         (JSC::VM::VM): Deleted.
1750         (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
1751         (JSC::VM::setEnabledProfiler): Deleted.
1752         * runtime/VM.h:
1753         (JSC::VM::enabledProfiler): Deleted.
1754         (JSC::VM::enabledProfilerAddress): Deleted.
1755
1756 2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>
1757
1758         Remove LegacyProfiler
1759         https://bugs.webkit.org/show_bug.cgi?id=153565
1760
1761         Reviewed by Saam Barati.
1762
1763         * inspector/protocol/Timeline.json:
1764         * jsc.cpp:
1765         * runtime/JSGlobalObject.cpp:
1766         (JSC::JSGlobalObject::hasLegacyProfiler):
1767         * runtime/JSGlobalObject.h:
1768         (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
1769
1770 2016-05-20  Saam barati  <sbarati@apple.com>
1771
1772         JSScope::abstractAccess doesn't need to copy the SymbolTableEntry, it can use it by reference
1773         https://bugs.webkit.org/show_bug.cgi?id=157956
1774
1775         Reviewed by Geoffrey Garen.
1776
1777         A SymbolTableEntry may be a FatEntry. Copying a FatEntry is slow because we have to
1778         malloc memory for it, then free the malloced memory once the entry goes out of
1779         scope. abstractAccess uses a SymbolTableEntry temporarily when performing scope
1780         accesses during bytecode linking. It copies out the SymbolTableEntry every time
1781         it does a SymbolTable lookup. This is not cheap when the entry happens to be a
1782         FatEntry. We should really just be using a reference to the entry because
1783         there is no need to copy it in such a scenario.
1784
1785         * runtime/JSScope.cpp:
1786         (JSC::abstractAccess):
1787
1788 2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>
1789
1790         Web Inspector: retained size for typed arrays does not count native backing store
1791         https://bugs.webkit.org/show_bug.cgi?id=157945
1792         <rdar://problem/26392238>
1793
1794         Reviewed by Geoffrey Garen.
1795
1796         * runtime/JSArrayBuffer.h:
1797         * runtime/JSArrayBuffer.cpp:
1798         (JSC::JSArrayBuffer::estimatedSize):
1799         Include an estimatedSize implementation for JSArrayBuffer.
1800         ArrayBuffer has a unique path, different from other data
1801         stored in the Heap.
1802
1803         * tests/heapProfiler/typed-array-sizes.js: Added.
1804         Test sizes of TypedArray with and without an ArrayBuffer.
1805         When the TypedArray is a view wrapping an ArrayBuffer, the
1806         ArrayBuffer has the size.
1807
1808 2016-05-20  Geoffrey Garen  <ggaren@apple.com>
1809
1810         reifyAllStaticProperties makes two copies of every string
1811         https://bugs.webkit.org/show_bug.cgi?id=157953
1812
1813         Reviewed by Mark Lam.
1814
1815         Let's not do that.
1816
1817         * runtime/JSObject.cpp:
1818         (JSC::JSObject::reifyAllStaticProperties): Pass our Identifier to
1819         reifyStaticProperty so it doesn't have to make its own.
1820
1821         * runtime/Lookup.h:
1822         (JSC::reifyStaticProperty): No need to null check because callers never
1823         pass null anymore. No need to make an identifier because callers pass
1824         us one.
1825
1826         (JSC::reifyStaticProperties): Honor new interface.
1827
1828 2016-05-20  Geoffrey Garen  <ggaren@apple.com>
1829
1830         JSBench regression: CodeBlock linking always copies the symbol table
1831         https://bugs.webkit.org/show_bug.cgi?id=157951
1832
1833         Reviewed by Saam Barati.
1834
1835         We always put a SymbolTable into the constant pool, even in simple
1836         functions in which it won't be used -- i.e., there's on eval and there
1837         are no captured variables and so on.
1838
1839         This is costly because linking must copy any provided symbol tables.
1840
1841         * bytecompiler/BytecodeGenerator.cpp:
1842         (JSC::BytecodeGenerator::BytecodeGenerator):
1843         (JSC::BytecodeGenerator::emitProfileType): Only add the symbol table
1844         as a constant if we will use it at runtime.
1845
1846 2016-05-19  Benjamin Poulain  <bpoulain@apple.com>
1847
1848         [JSC] Improve int->float conversion in FTL
1849         https://bugs.webkit.org/show_bug.cgi?id=157936
1850
1851         Reviewed by Filip Pizlo.
1852
1853         The integer -> floating point lowering was very barebone.
1854
1855         For example, converting a constant integer to double
1856         was doing:
1857             mov #const, %eax
1858             xor %xmm0, %xmm0
1859             cvtsi2sd %eax, %xmm0
1860
1861         Conversion from integer to float was also missing.
1862         We were always converting to double then rounding the double
1863         to float.
1864
1865         This patch adds the basics:
1866         -Constant folding.
1867         -Integer to Float opcode.
1868         -Reducing int->double to int->float when used by DoubleToFloat.
1869
1870         * assembler/MacroAssemblerX86Common.h:
1871         (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
1872         * assembler/MacroAssemblerX86_64.h:
1873         (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
1874         (JSC::MacroAssemblerX86_64::convertInt64ToFloat):
1875         * assembler/X86Assembler.h:
1876         (JSC::X86Assembler::cvtsi2ss_rr):
1877         (JSC::X86Assembler::cvtsi2ssq_rr):
1878         (JSC::X86Assembler::cvtsi2sdq_mr):
1879         (JSC::X86Assembler::cvtsi2ssq_mr):
1880         (JSC::X86Assembler::cvtsi2ss_mr):
1881         * assembler/MacroAssemblerARM64.h:
1882         * b3/B3Const32Value.cpp:
1883         (JSC::B3::Const32Value::iToDConstant):
1884         (JSC::B3::Const32Value::iToFConstant):
1885         * b3/B3Const32Value.h:
1886         * b3/B3Const64Value.cpp:
1887         (JSC::B3::Const64Value::iToDConstant):
1888         (JSC::B3::Const64Value::iToFConstant):
1889         * b3/B3Const64Value.h:
1890         * b3/B3LowerToAir.cpp:
1891         (JSC::B3::Air::LowerToAir::lower):
1892         * b3/B3Opcode.cpp:
1893         (WTF::printInternal):
1894         * b3/B3Opcode.h:
1895         * b3/B3ReduceDoubleToFloat.cpp:
1896         * b3/B3ReduceStrength.cpp:
1897         * b3/B3Validate.cpp:
1898         * b3/B3Value.cpp:
1899         (JSC::B3::Value::iToDConstant):
1900         (JSC::B3::Value::iToFConstant):
1901         (JSC::B3::Value::isRounded):
1902         (JSC::B3::Value::effects):
1903         (JSC::B3::Value::key):
1904         (JSC::B3::Value::typeFor):
1905         * b3/B3Value.h:
1906         * b3/B3ValueKey.cpp:
1907         (JSC::B3::ValueKey::materialize):
1908         * b3/air/AirFixPartialRegisterStalls.cpp:
1909         * b3/air/AirOpcode.opcodes:
1910         * b3/testb3.cpp:
1911         (JSC::B3::int64Operands):
1912         (JSC::B3::testIToD64Arg):
1913         (JSC::B3::testIToF64Arg):
1914         (JSC::B3::testIToD32Arg):
1915         (JSC::B3::testIToF32Arg):
1916         (JSC::B3::testIToD64Mem):
1917         (JSC::B3::testIToF64Mem):
1918         (JSC::B3::testIToD32Mem):
1919         (JSC::B3::testIToF32Mem):
1920         (JSC::B3::testIToD64Imm):
1921         (JSC::B3::testIToF64Imm):
1922         (JSC::B3::testIToD32Imm):
1923         (JSC::B3::testIToF32Imm):
1924         (JSC::B3::testIToDReducedToIToF64Arg):
1925         (JSC::B3::testIToDReducedToIToF32Arg):
1926         (JSC::B3::run):
1927
1928 2016-05-19  Benjamin Poulain  <bpoulain@apple.com>
1929
1930         [JSC] FTL can crash on stack overflow
1931         https://bugs.webkit.org/show_bug.cgi?id=157881
1932         rdar://problem/24665964
1933
1934         Reviewed by Michael Saboff.
1935
1936         The VM's m_largestFTLStackSize was never set anywhere (updateFTLLargestStackSize()
1937         was never called). We forgot to change that when implementing B3.
1938
1939         Even when it is set, we still have a problem on OSR Exit.
1940         If the last frame is a FTL frame and it OSR Exits, the space required for
1941         that frame becomes significantly larger. What happens is we crash in the OSR Exit
1942         instead of the FTL frame (this is what happens in rdar://problem/24665964).
1943
1944         This patch changes the stack boundary checks in FTL to be the same as DFG:
1945         we verify that we have enough space for the current optimized function but
1946         also for the baseline version (including inlining) in case of exit.
1947
1948         * ftl/FTLLowerDFGToB3.cpp:
1949         (JSC::FTL::DFG::LowerDFGToB3::lower):
1950         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): Deleted.
1951         * runtime/VM.cpp:
1952         (JSC::VM::VM): Deleted.
1953         (JSC::VM::updateStackLimit): Deleted.
1954         (JSC::VM::updateFTLLargestStackSize): Deleted.
1955         * runtime/VM.h:
1956         (JSC::VM::addressOfFTLStackLimit): Deleted.
1957
1958 2016-05-18  Filip Pizlo  <fpizlo@apple.com>
1959
1960         DFG::LICMPhase shouldn't hoist type checks unless it knows that the check will succeed at the loop pre-header
1961         https://bugs.webkit.org/show_bug.cgi?id=144527
1962
1963         Reviewed by Saam Barati.
1964         
1965         This adds a control flow equivalence analysis (called ControlEquivalenceAnalysis) based on
1966         dominator analysis over the backwards CFG. Two basic blocks are control flow equivalent if
1967         the execution of one implies that the other one must also execute. It means that the two
1968         blocks' forward and backward dominance are reciprocated: (A dom B and B backdom A) or (B dom
1969         A and A backdom B). LICM now uses it to become more conservative about hoisting checks, if
1970         this has caused problems in the past. If we hoist something that may exit from a block that
1971         was not control equivalent to the pre-header then it's possible that the node's speculation
1972         will fail even though it wouldn't have if it wasn't hoisted. So, we flag these nodes'
1973         origins as being "wasHoisted" and we track all of their exits as "HoistingFailed". LICM will
1974         turn off such speculative hoisting if the CodeBlock from which we are hoisting had the
1975         HoistingFailed exit kind.
1976         
1977         Note that this deliberately still allows us to hoist things that may exit even if they are
1978         not control equivalent to the pre-header. This is necessary because the profitability of
1979         hoisting is so huge in all of the cases that we're aware of that it's worth giving it a
1980         shot.
1981         
1982         This is neutral on macrobenchmarks since none of the benchmarks we track have a hoistable
1983         operation that would exit only if hoisted. I added microbenchmarks to illustrate the problem
1984         and two of them speed up by ~40% while one of them is neutral (Int52 saves us from having
1985         problems on that program even though LICM previously did the wrong thing).
1986
1987         * JavaScriptCore.xcodeproj/project.pbxproj:
1988         * bytecode/ExitKind.cpp:
1989         (JSC::exitKindToString):
1990         * bytecode/ExitKind.h:
1991         * dfg/DFGAtTailAbstractState.h:
1992         (JSC::DFG::AtTailAbstractState::operator bool):
1993         (JSC::DFG::AtTailAbstractState::initializeTo):
1994         * dfg/DFGBackwardsCFG.h: Added.
1995         (JSC::DFG::BackwardsCFG::BackwardsCFG):
1996         * dfg/DFGBackwardsDominators.h: Added.
1997         (JSC::DFG::BackwardsDominators::BackwardsDominators):
1998         * dfg/DFGCommon.h:
1999         (JSC::DFG::checkAndSet): Deleted.
2000         * dfg/DFGControlEquivalenceAnalysis.h: Added.
2001         (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis):
2002         (JSC::DFG::ControlEquivalenceAnalysis::dominatesEquivalently):
2003         (JSC::DFG::ControlEquivalenceAnalysis::areEquivalent):
2004         * dfg/DFGGraph.cpp:
2005         (JSC::DFG::Graph::dump):
2006         (JSC::DFG::Graph::dumpBlockHeader):
2007         (JSC::DFG::Graph::invalidateCFG):
2008         (JSC::DFG::Graph::substituteGetLocal):
2009         (JSC::DFG::Graph::handleAssertionFailure):
2010         (JSC::DFG::Graph::ensureDominators):
2011         (JSC::DFG::Graph::ensurePrePostNumbering):
2012         (JSC::DFG::Graph::ensureNaturalLoops):
2013         (JSC::DFG::Graph::ensureBackwardsCFG):
2014         (JSC::DFG::Graph::ensureBackwardsDominators):
2015         (JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
2016         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2017         * dfg/DFGGraph.h:
2018         (JSC::DFG::Graph::hasDebuggerEnabled):
2019         * dfg/DFGInPlaceAbstractState.h:
2020         (JSC::DFG::InPlaceAbstractState::operator bool):
2021         (JSC::DFG::InPlaceAbstractState::createValueForNode):
2022         (JSC::DFG::InPlaceAbstractState::forNode):
2023         * dfg/DFGLICMPhase.cpp:
2024         (JSC::DFG::LICMPhase::run):
2025         (JSC::DFG::LICMPhase::attemptHoist):
2026         * dfg/DFGMayExit.cpp:
2027         (JSC::DFG::mayExit):
2028         * dfg/DFGMayExit.h:
2029         * dfg/DFGNode.h:
2030         * dfg/DFGNodeOrigin.cpp:
2031         (JSC::DFG::NodeOrigin::dump):
2032         * dfg/DFGNodeOrigin.h:
2033         (JSC::DFG::NodeOrigin::takeValidExit):
2034         (JSC::DFG::NodeOrigin::withWasHoisted):
2035         (JSC::DFG::NodeOrigin::forInsertingAfter):
2036         * dfg/DFGNullAbstractState.h: Added.
2037         (JSC::DFG::NullAbstractState::NullAbstractState):
2038         (JSC::DFG::NullAbstractState::operator bool):
2039         (JSC::DFG::NullAbstractState::forNode):
2040         * dfg/DFGOSRExit.cpp:
2041         (JSC::DFG::OSRExit::OSRExit):
2042         * dfg/DFGOSRExitBase.cpp:
2043         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
2044         * dfg/DFGOSRExitBase.h:
2045         (JSC::DFG::OSRExitBase::OSRExitBase):
2046         * dfg/DFGTypeCheckHoistingPhase.cpp:
2047         (JSC::DFG::TypeCheckHoistingPhase::run):
2048         * ftl/FTLOSRExit.cpp:
2049         (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
2050         (JSC::FTL::OSRExit::OSRExit):
2051         * ftl/FTLOSRExit.h:
2052
2053 2016-05-19  Mark Lam  <mark.lam@apple.com>
2054
2055         Code that null checks the VM pointer before any use should ref the VM.
2056         https://bugs.webkit.org/show_bug.cgi?id=157864
2057
2058         Reviewed by Filip Pizlo and Keith Miller.
2059
2060         JSLock::willReleaseLock() and HeapTimer::timerDidFire() need to reference the VM
2061         through a RefPtr.  Otherwise, there's no guarantee that the VM won't be deleted
2062         after their null checks.
2063
2064         * bytecode/CodeBlock.h:
2065         (JSC::CodeBlock::vm):
2066         (JSC::CodeBlock::setVM): Deleted.
2067         - Not used, and suggests that it can be changed during the lifetime of the
2068           CodeBlock (which should not be).
2069
2070         * heap/HeapTimer.cpp:
2071         (JSC::HeapTimer::timerDidFire):
2072         * runtime/JSLock.cpp:
2073         (JSC::JSLock::willReleaseLock):
2074         - Store the VM pointer in a RefPtr first, and null check the RefPtr instead of
2075           the raw VM pointer.  This makes the null check a strong guarantee that the
2076           VM pointer is valid while these functions are using it.
2077
2078 2016-05-19  Saam barati  <sbarati@apple.com>
2079
2080         arrow function lexical environment should reuse the same environment as the function's lexical environment where possible
2081         https://bugs.webkit.org/show_bug.cgi?id=157908
2082
2083         Reviewed by Filip Pizlo.
2084
2085         We can safely combine these two environment when we have
2086         a simple parameter list (no default parameters, no destructring parameters).
2087
2088         * bytecompiler/BytecodeGenerator.cpp:
2089         (JSC::BytecodeGenerator::BytecodeGenerator):
2090         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
2091         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
2092         * bytecompiler/BytecodeGenerator.h:
2093
2094 2016-05-19  Michael Saboff  <msaboff@apple.com>
2095
2096         Unreviewed build fix.
2097
2098         Skipping this new test as it times out on the bots.
2099
2100         Issue tracked in https://bugs.webkit.org/show_bug.cgi?id=157903
2101
2102         * tests/stress/regress-157595.js:
2103         (MyRegExp):
2104
2105 2016-05-19  Guillaume Emont  <guijemont@igalia.com>
2106
2107         JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis
2108         https://bugs.webkit.org/show_bug.cgi?id=157741
2109
2110         Reviewed by Saam Barati.
2111
2112         The PutByValWithThis case needs a special case for MIPS because we
2113         don't have enough registers. The special case needs to be different
2114         from the x86 one because we have a different ABI.
2115
2116         * dfg/DFGSpeculativeJIT32_64.cpp:
2117         (JSC::DFG::SpeculativeJIT::compile):
2118
2119 2016-05-19  Brian Burg  <bburg@apple.com>
2120
2121         Web Inspector: use a consistent prefix for injected scripts
2122         https://bugs.webkit.org/show_bug.cgi?id=157715
2123         <rdar://problem/26287188>
2124
2125         Reviewed by Timothy Hatcher.
2126
2127         * CMakeLists.txt:
2128         * DerivedSources.make:
2129         * inspector/InjectedScriptSource.js:
2130
2131 2016-05-19  Csaba Osztrogon√°c  <ossy@webkit.org>
2132
2133         [ARM] Remove redefined macro after r200606
2134         https://bugs.webkit.org/show_bug.cgi?id=157890
2135
2136         Reviewed by Michael Saboff.
2137
2138         * bytecode/PolymorphicAccess.cpp:
2139         * jit/CCallHelpers.h:
2140
2141 2016-05-18  Saam barati  <sbarati@apple.com>
2142
2143         Function with default parameter values that are arrow functions that capture this isn't working
2144         https://bugs.webkit.org/show_bug.cgi?id=157786
2145         <rdar://problem/26327329>
2146
2147         Reviewed by Geoffrey Garen.
2148
2149         To make the scopes ordered properly, I needed to initialize the arrow 
2150         function lexical environment before initializing default parameter values.
2151         I also made the code easier to reason about by never reusing the function's
2152         var lexical environment for the arrow function lexical environment. The
2153         reason for this is that that code was wrong, and we just didn't have code to
2154         that properly tested it. It was easy for that code to be wrong because
2155         sometimes the function's lexical environment isn't the top-most scope
2156         (namely, when a function's parameter list is non-simple) and sometimes
2157         it is (when the function's parameter list is simple).
2158
2159         Also, because a function's default parameter values may capture the
2160         'arguments' variable inside an arrow function, I needed to take care
2161         to initialize the 'arguments' variable as part of whichever scope
2162         is the top-most scope. It's either the function's var environment
2163         if the parameter list is simple, or it's the function's parameter
2164         environment if the parameter list is non-simple.
2165
2166         * bytecompiler/BytecodeGenerator.cpp:
2167         (JSC::BytecodeGenerator::BytecodeGenerator):
2168         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
2169         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
2170         (JSC::BytecodeGenerator::initializeParameters):
2171         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
2172         (JSC::BytecodeGenerator::visibleNameForParameter):
2173         * bytecompiler/BytecodeGenerator.h:
2174         * tests/stress/arrow-functions-as-default-parameter-values.js: Added.
2175         (assert):
2176         (test):
2177         (test.foo):
2178         * tests/stress/op-push-name-scope-crashes-profiler.js:
2179         (test):
2180
2181 2016-05-18  Michael Saboff  <msaboff@apple.com>
2182
2183         r199812 broke test262
2184         https://bugs.webkit.org/show_bug.cgi?id=157595
2185
2186         Reviewed by Filip Pizlo.
2187
2188         Added a reasonable limit to the size of the match result array to catch possible
2189         infinite loops when matching.
2190         Added a new tests that creates an infinite loop in RegExp.prototype.[Symbol.match]
2191         by creating a subclass of RegExp where the base RegExp's global flag is false and
2192         the subclass overrides .global with a getter that always returns true.
2193
2194         * builtins/RegExpPrototype.js:
2195         (match):
2196         * tests/stress/regress-157595.js: Added.
2197         (MyRegExp):
2198         (MyRegExp.prototype.get global):
2199         (test):
2200         (catch):
2201
2202 2016-05-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2203
2204         [ES6] Namespace object re-export should be handled as local export
2205         https://bugs.webkit.org/show_bug.cgi?id=157806
2206
2207         Reviewed by Mark Lam.
2208
2209         We align the implementation of ExportEntry to the spec; remove Type::Namespace.
2210         This Type::Namespace is used for re-exported namespace object binding. For example,
2211
2212             import * as namespace from "namespace.js"
2213             export { namespace }
2214
2215         In the above case, we used ExportEntry(Type::Namespace). In this patch, we drop this
2216         and use normal local export (Type::Local) instead because namespace object actually has
2217         the local binding in the above module environment. And this handling strictly meets the
2218         spec (Sec 15.2.1.16.1 step 11-a-ii-2-b).
2219
2220         And we also clean up the ExportEntry implementation; dropping unnecessary information.
2221         This change fixes the test262/test/language/module-code/instn-star-equality.js crash.
2222
2223         * parser/ModuleAnalyzer.cpp:
2224         (JSC::ModuleAnalyzer::exportVariable):
2225         * runtime/JSModuleRecord.cpp:
2226         (JSC::getExportedNames):
2227         (JSC::JSModuleRecord::dump): Deleted.
2228         * runtime/JSModuleRecord.h:
2229         * tests/modules/namespace-re-export.js: Added.
2230         * tests/modules/namespace-re-export/namespace-re-export-fixture.js: Added.
2231         * tests/modules/namespace-re-export/namespace-re-export.js: Added.
2232         * tests/modules/resources/assert.js:
2233         (export.shouldNotBe):
2234
2235 2016-05-17  Filip Pizlo  <fpizlo@apple.com>
2236
2237         JSC should detect the right default locale even when it's not embedded in WebCore
2238         https://bugs.webkit.org/show_bug.cgi?id=157755
2239         rdar://problem/24665424
2240
2241         Reviewed by Keith Miller.
2242         
2243         This makes JSC try to use WTF's platform user preferred language detection if the DOM did
2244         not register a defaultLanguage callback. The result is that when JSC runs standalone it
2245         will detect the platform user preferred language almost the same way as when it's embedded
2246         in WebCore. The only difference is that WebCore may have its own additional overrides via
2247         the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls
2248         back to.
2249         
2250         We first found this bug because on iOS, the intl tests would fail because ICU would report
2251         a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall
2252         back to ICU's locale detection. It turns out that the ICU default locale is also bogus on
2253         OS X, just less so. For example, setting things to Poland did not result in the jsc shell
2254         printing dates Polish-style. Now it will print them Polish-style if your system preferences
2255         say so. Also, the tests don't fail on iOS anymore.
2256         
2257         * runtime/IntlObject.cpp:
2258         (JSC::defaultLocale):
2259
2260 2016-05-17  Dean Jackson  <dino@apple.com>
2261
2262         Remove ES6_GENERATORS flag
2263         https://bugs.webkit.org/show_bug.cgi?id=157815
2264         <rdar://problem/26332894>
2265
2266         Reviewed by Geoffrey Garen.
2267
2268         This flag isn't needed. Generators are enabled everywhere and
2269         part of a stable specification.
2270
2271         * Configurations/FeatureDefines.xcconfig:
2272         * parser/Parser.cpp:
2273         (JSC::Parser<LexerType>::parseFunctionDeclaration): Deleted.
2274         (JSC::Parser<LexerType>::parseClass): Deleted.
2275         (JSC::Parser<LexerType>::parseExportDeclaration): Deleted.
2276         (JSC::Parser<LexerType>::parseAssignmentExpression): Deleted.
2277         (JSC::Parser<LexerType>::parseProperty): Deleted.
2278         (JSC::Parser<LexerType>::parseFunctionExpression): Deleted.
2279
2280 2016-05-17  Keith Miller  <keith_miller@apple.com>
2281
2282         Rollout r200426 since it causes PLT regressions.
2283         https://bugs.webkit.org/show_bug.cgi?id=157812
2284
2285         Unreviewed rollout of r200426 since the bots see a ~.6% PLT regression from the patch.
2286
2287 2016-05-17  Keith Miller  <keith_miller@apple.com>
2288
2289         Add test262 harness support code
2290         https://bugs.webkit.org/show_bug.cgi?id=157797
2291
2292         Reviewed by Filip Pizlo.
2293
2294         This patch adds some new tooling needed to run Test262 with the jsc
2295         CLI. There were three options that needed to be added for Test262:
2296
2297         1) "--test262-async" This option overrides the print function in the test runner to look for
2298         'Test262:AsyncTestComplete' instead of printing the passed text. If test262-async mode is on
2299         and that string is not passed then the test is marked as failing.
2300
2301         2) "--strict-file=<file>" This option appends `"use strict";\n` to the beginning of the
2302         passed file before passing the source code to the VM. This option can, in theory, be passed
2303         multiple times.
2304
2305         3) "--exception=<name>" This option asserts that at the end of the last script file passed
2306         the VM has an uncaught exception with its name property equal to the passed name.
2307
2308         * jsc.cpp:
2309         (Script::Script):
2310         (fillBufferWithContentsOfFile):
2311         (functionPrint):
2312         (checkUncaughtException):
2313         (runWithScripts):
2314         (printUsageStatement):
2315         (CommandLine::parseArguments):
2316         (runJSC):
2317
2318 2016-05-17  Filip Pizlo  <fpizlo@apple.com>
2319
2320         WTF should know about Language
2321         https://bugs.webkit.org/show_bug.cgi?id=157756
2322
2323         Reviewed by Geoffrey Garen.
2324
2325         Teach our scripts that a ObjC class beginning with WTF is totally cool.
2326
2327         * JavaScriptCore.xcodeproj/project.pbxproj:
2328
2329 2016-05-17  Joseph Pecoraro  <pecoraro@apple.com>
2330
2331         console namespace breaks putting properties on console.__proto__
2332         https://bugs.webkit.org/show_bug.cgi?id=157782
2333         <rdar://problem/26250526>
2334
2335         Reviewed by Geoffrey Garen.
2336
2337         Some websites currently depend on console.__proto__ existing and being
2338         a separate object from Object.prototype. This patch adds back a basic
2339         console.__proto__ object, but all the console functions are left on
2340         the ConsoleObject itself.
2341
2342         * runtime/JSGlobalObject.cpp:
2343         (JSC::createConsoleProperty):
2344
2345 2016-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2346
2347         Unreviewed, dump more information when math-pow-stable-results.js failed
2348         https://bugs.webkit.org/show_bug.cgi?id=157168
2349
2350         * tests/stress/math-pow-stable-results.js:
2351
2352 2016-05-16  Saam barati  <sbarati@apple.com>
2353
2354         ShadowChicken crashes when reading a scope from the frame during a stack overflow exception
2355         https://bugs.webkit.org/show_bug.cgi?id=157770
2356
2357         Reviewed by Filip Pizlo.
2358
2359         ShadowChicken was reading the scope from a half formed
2360         frame as it threw a stack overflow exception. The frame had
2361         a valid CodeBlock pointer, but it did not have a valid scope.
2362         The code in ShadowChicken's throw packet logging mechanism didn't
2363         account for this. The fix is to respect whether genericUnwind wants
2364         to unwind from the current frame or the caller's frame. For stack
2365         overflow errors, we always unwind the caller's frame.
2366
2367         * jit/JITExceptions.cpp:
2368         (JSC::genericUnwind):
2369
2370 2016-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2371
2372         REGRESSION(r200208): It made 2 JSC stress tests fail on x86
2373         https://bugs.webkit.org/show_bug.cgi?id=157168
2374
2375         Reviewed by Benjamin Poulain.
2376
2377         The fast path in operationMathPow produces different results between x87 and the other environments.
2378         This is because x87 calculates the double value in 80bit precision.
2379         The situation is the following: in x86 32bit environment, floating point operations are compiled to
2380         x87 operations by default even if we can use SSE2. But in DFG environment, we aggressively use SSE2
2381         if the cpuid reports SSE2 is available. As a result, the implementations differ between C runtime
2382         and DFG JIT code. The C runtime uses x87 while DFG JIT code uses SSE2. This causes a precision
2383         problem since x87 has 80bit precision while SSE2 has 64bit precision.
2384
2385         In this patch, in x86 32bit environment, we use `volatile double` if the `-mfpmath=sse and -msse2 (or later)`
2386         is not specified. This will round the x87 value into 64bit per multiplying. Note that this problem does not
2387         occur in OS X clang 32bit environment. This is because `-mfpmath=sse` is enabled by default in OS X clang 32bit.
2388
2389         * b3/B3MathExtras.cpp:
2390         (JSC::B3::powDoubleInt32):
2391         * runtime/MathCommon.cpp:
2392         (JSC::operationMathPow):
2393
2394 2016-05-16  Benjamin Poulain  <bpoulain@apple.com>
2395
2396         [JSC] "return this" in a constructor does not need a branch on isObject(this)
2397         https://bugs.webkit.org/show_bug.cgi?id=157775
2398
2399         Reviewed by Saam Barati and Ryosuke Niwa.
2400
2401         When returning "this" in a constructor, the bytecode generator was generating:
2402             is_object         locX, this
2403             jtrue             locX, 5(->second ret)
2404             ret               this
2405             ret               this
2406
2407         That code is eliminated in DFG but it is pretty costly lower tiers.
2408
2409         This patch changes bytecode generation to avoid the is_object test
2410         when possible and not generate two ret if they encode the same thing.
2411
2412         * bytecompiler/BytecodeGenerator.cpp:
2413         (JSC::BytecodeGenerator::emitReturn):
2414
2415 2016-05-16  Benjamin Poulain  <bpoulain@apple.com>
2416
2417         [JSC] Remove the index check from op_get_by_val/op_put_by_val when the index is constant
2418         https://bugs.webkit.org/show_bug.cgi?id=157766
2419
2420         Reviewed by Geoffrey Garen.
2421
2422         If the index is an integer constant, do not generate the index check.
2423
2424         * jit/JITPropertyAccess.cpp:
2425         (JSC::JIT::emit_op_get_by_val):
2426         (JSC::JIT::emitSlow_op_get_by_val):
2427         (JSC::JIT::emit_op_put_by_val):
2428         (JSC::JIT::emitSlow_op_put_by_val):
2429
2430 2016-05-16  Benjamin Poulain  <bpoulain@apple.com>
2431
2432         [JSC][DFG] Fill spilled Int32 as Int32 instead of JSInt32
2433         https://bugs.webkit.org/show_bug.cgi?id=157700
2434
2435         Reviewed by Michael Saboff.
2436
2437         In general, fillSpeculateInt32() originate from SpeculateInt32
2438         and the user does not care about the tag.
2439
2440         This is particularily obvious on Sunspider's math-spectral-norm.js.
2441         In that test, registers are frequently spilled because of x86's DIV.
2442
2443         When they are re-filled, they were always tagged.
2444         Since the loops are small, all the tagging adds up.
2445
2446         * dfg/DFGSpeculativeJIT64.cpp:
2447         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2448
2449 2016-05-16  Saam barati  <sbarati@apple.com>
2450
2451         Unreviewed Cloop build fix.
2452
2453         * bytecode/CodeBlock.cpp:
2454         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
2455
2456 2016-05-16  Saam barati  <sbarati@apple.com>
2457
2458         Hook up ShadowChicken to the debugger to show tail deleted frames
2459         https://bugs.webkit.org/show_bug.cgi?id=156685
2460         <rdar://problem/25770521>
2461
2462         Reviewed by Filip Pizlo and Mark Lam and Joseph Pecoraro.
2463
2464         The heart of this patch hooks up ShadowChicken to DebuggerCallFrame to
2465         allow the Web Inspector to display the ShadowChicken's shadow stack.
2466         This means the Web Inspector can now display tail deleted frames.
2467         To make this work, I made the necessary changes to ShadowChicken and
2468         DebuggerCallFrame to allow DebuggerCallFrame to keep the same API
2469         when representing both machine frames and tail deleted frames.
2470
2471         - ShadowChicken prologue packets now log the current scope. Tail packets
2472           log the current scope, the 'this' value, the CodeBlock, and the
2473           CallSiteIndex. This allows the inspector to not only show the
2474           tail deleted frame, but also show exactly where the tail call happened (line and column numbers),
2475           with which scope it executed, and with which 'this' value. This
2476           patch also allows DebuggerCallFrame to execute console statements
2477           in a tail deleted frame.
2478
2479         - I changed ShadowChicken's stack resizing algorithm. ShadowChicken
2480           now only keeps a maximum number of tail deleted frames in its shadow stack.
2481           It will happily represent all machine frames without limit. Right now, the
2482           maximum number of tail deleted frames I chose to keep alive is 128.
2483           We will keep frames alive starting from the top of the stack. This
2484           allows us to have a strong defense against runaway memory usage. We will only
2485           keep around at most 128 "shadow" frames that wouldn't have naturally been kept
2486           alive by the executing program. We can play around with this number
2487           if we find that 128 is either too many or too few frames.
2488
2489         - DebuggerCallFrame is no longer a cheap class to create. When it is created,
2490           we will eagerly create the entire virtual debugger stack. So I modified the
2491           existing code to lazily create DebuggerCallFrames only when necessary. We
2492           used to eagerly create them at each op_debug statement even though we would
2493           just throw them away if we didn't hit a breakpoint.
2494
2495         - A valid DebuggerCallFrame will always have a valid CallFrame* pointer
2496           into the stack. This pointer won't always refer to the logical frame
2497           that the DebuggerCallFrame represents because a DebuggerCallFrame can
2498           now represent a tail deleted frame. To do this, DebuggerCallFrame now
2499           has a ShadowChicken::Frame member variable. This allows DebuggerCallFrame
2500           to know when it represents a tail deleted frame and gives DebuggerCallFrame
2501           a mechanism to ask the tail deleted frame for interesting information
2502           (like its 'this' value, scope, CodeBlock, etc). A tail deleted frame's
2503           machine frame pointer will be the machine caller of the tail deleted frame
2504           (or the machine caller of the first of a series of consecutive tail calls).
2505
2506         - I added a new flag to UnlinkedCodeBlock to indicate when it is compiled
2507           with debugging opcodes. I did this because ShadowChicken may read a JSScope
2508           from the machine stack. This is only safe if the machine CodeBlock was
2509           compiled with debugging opcodes. This is safer than asking if the
2510           CodeBlock's global object has an interactive debugger enabled because
2511           it's theoretically possible for the debugger to be enabled while code
2512           compiled without a debugger is still live on the stack. This field is
2513           also now used to indicate to the DFGGraph that the interactive debugger
2514           is enabled.
2515
2516         - Finally, this patch adds a new field to the Inspector's CallFrame protocol
2517           object called 'isTailDeleted' to allow the Inspector to know when a
2518           CallFrame represents a tail deleted frame.
2519
2520         * JavaScriptCore.xcodeproj/project.pbxproj:
2521         * bytecode/BytecodeList.json:
2522         * bytecode/BytecodeUseDef.h:
2523         (JSC::computeUsesForBytecodeOffset):
2524         * bytecode/CodeBlock.cpp:
2525         (JSC::CodeBlock::dumpBytecode):
2526         (JSC::CodeBlock::findPC):
2527         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
2528         * bytecode/CodeBlock.h:
2529         (JSC::CodeBlock::clearDebuggerRequests):
2530         (JSC::CodeBlock::wasCompiledWithDebuggingOpcodes):
2531         * bytecode/UnlinkedCodeBlock.cpp:
2532         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2533         * bytecode/UnlinkedCodeBlock.h:
2534         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes):
2535         (JSC::UnlinkedCodeBlock::finishCreation):
2536         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
2537         * bytecode/UnlinkedFunctionExecutable.cpp:
2538         (JSC::generateUnlinkedFunctionCodeBlock):
2539         * bytecompiler/BytecodeGenerator.cpp:
2540         (JSC::BytecodeGenerator::generate):
2541         (JSC::BytecodeGenerator::BytecodeGenerator):
2542         (JSC::BytecodeGenerator::emitEnter):
2543         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
2544         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
2545         (JSC::BytecodeGenerator::emitCallDefineProperty):
2546         * debugger/Debugger.cpp:
2547         (JSC::DebuggerPausedScope::DebuggerPausedScope):
2548         (JSC::DebuggerPausedScope::~DebuggerPausedScope):
2549         (JSC::Debugger::didReachBreakpoint):
2550         (JSC::Debugger::currentDebuggerCallFrame):
2551         * debugger/Debugger.h:
2552         * debugger/DebuggerCallFrame.cpp:
2553         (JSC::LineAndColumnFunctor::operator()):
2554         (JSC::DebuggerCallFrame::create):
2555         (JSC::DebuggerCallFrame::DebuggerCallFrame):
2556         (JSC::DebuggerCallFrame::callerFrame):
2557         (JSC::DebuggerCallFrame::globalExec):
2558         (JSC::DebuggerCallFrame::vmEntryGlobalObject):
2559         (JSC::DebuggerCallFrame::sourceID):
2560         (JSC::DebuggerCallFrame::functionName):
2561         (JSC::DebuggerCallFrame::scope):
2562         (JSC::DebuggerCallFrame::type):
2563         (JSC::DebuggerCallFrame::thisValue):
2564         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
2565         (JSC::DebuggerCallFrame::invalidate):
2566         (JSC::DebuggerCallFrame::currentPosition):
2567         (JSC::DebuggerCallFrame::positionForCallFrame):
2568         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
2569         (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor): Deleted.
2570         (JSC::FindCallerMidStackFunctor::operator()): Deleted.
2571         (JSC::FindCallerMidStackFunctor::getCallerFrame): Deleted.
2572         (JSC::DebuggerCallFrame::thisValueForCallFrame): Deleted.
2573         * debugger/DebuggerCallFrame.h:
2574         (JSC::DebuggerCallFrame::isValid):
2575         (JSC::DebuggerCallFrame::isTailDeleted):
2576         (JSC::DebuggerCallFrame::create): Deleted.
2577         (JSC::DebuggerCallFrame::exec): Deleted.
2578         * dfg/DFGByteCodeParser.cpp:
2579         (JSC::DFG::ByteCodeParser::parseBlock):
2580         * dfg/DFGFixupPhase.cpp:
2581         (JSC::DFG::FixupPhase::fixupNode):
2582         * dfg/DFGGraph.cpp:
2583         (JSC::DFG::Graph::Graph):
2584         (JSC::DFG::Graph::~Graph):
2585         * dfg/DFGJITCompiler.h:
2586         (JSC::DFG::JITCompiler::addCallSite):
2587         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
2588         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
2589         * dfg/DFGSpeculativeJIT32_64.cpp:
2590         (JSC::DFG::SpeculativeJIT::compile):
2591         * dfg/DFGSpeculativeJIT64.cpp:
2592         (JSC::DFG::SpeculativeJIT::compile):
2593         * ftl/FTLAbstractHeapRepository.h:
2594         * ftl/FTLLowerDFGToB3.cpp:
2595         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
2596         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
2597         (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
2598         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2599         (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
2600         (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket): Deleted.
2601         * inspector/InjectedScriptSource.js:
2602         (InjectedScript.CallFrameProxy):
2603         * inspector/JSJavaScriptCallFrame.cpp:
2604         (Inspector::JSJavaScriptCallFrame::thisObject):
2605         (Inspector::JSJavaScriptCallFrame::isTailDeleted):
2606         (Inspector::JSJavaScriptCallFrame::type):
2607         * inspector/JSJavaScriptCallFrame.h:
2608         * inspector/JSJavaScriptCallFramePrototype.cpp:
2609         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2610         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
2611         (Inspector::jsJavaScriptCallFrameAttributeType):
2612         (Inspector::jsJavaScriptCallFrameIsTailDeleted):
2613         * inspector/JavaScriptCallFrame.h:
2614         (Inspector::JavaScriptCallFrame::type):
2615         (Inspector::JavaScriptCallFrame::scopeChain):
2616         (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
2617         (Inspector::JavaScriptCallFrame::isTailDeleted):
2618         (Inspector::JavaScriptCallFrame::thisValue):
2619         (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
2620         * inspector/ScriptDebugServer.cpp:
2621         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
2622         * inspector/protocol/Debugger.json:
2623         * interpreter/ShadowChicken.cpp:
2624         (JSC::ShadowChicken::update):
2625         (JSC::ShadowChicken::visitChildren):
2626         (JSC::ShadowChicken::reset):
2627         * interpreter/ShadowChicken.h:
2628         (JSC::ShadowChicken::Packet::throwMarker):
2629         (JSC::ShadowChicken::Packet::prologue):
2630         (JSC::ShadowChicken::Packet::tail):
2631         (JSC::ShadowChicken::Frame::Frame):
2632         (JSC::ShadowChicken::Frame::operator==):
2633         * jit/CCallHelpers.cpp:
2634         (JSC::CCallHelpers::logShadowChickenProloguePacket):
2635         (JSC::CCallHelpers::logShadowChickenTailPacket):
2636         (JSC::CCallHelpers::ensureShadowChickenPacket):
2637         (JSC::CCallHelpers::setupShadowChickenPacket): Deleted.
2638         * jit/CCallHelpers.h:
2639         * jit/JITOpcodes.cpp:
2640         (JSC::JIT::emit_op_profile_type):
2641         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2642         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2643         (JSC::JIT::emit_op_get_enumerable_length):
2644         (JSC::JIT::emit_op_resume):
2645         * jit/JITOpcodes32_64.cpp:
2646         (JSC::JIT::emit_op_profile_type):
2647         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2648         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2649         * jit/RegisterSet.cpp:
2650         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
2651         (JSC::RegisterSet::argumentGPRS):
2652         (JSC::RegisterSet::registersToNotSaveForJSCall):
2653         * jit/RegisterSet.h:
2654         * llint/LLIntData.cpp:
2655         (JSC::LLInt::Data::performAssertions):
2656         * llint/LLIntSlowPaths.cpp:
2657         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2658         * llint/LowLevelInterpreter.asm:
2659         * llint/LowLevelInterpreter32_64.asm:
2660         * llint/LowLevelInterpreter64.asm:
2661         * runtime/CodeCache.cpp:
2662         (JSC::CodeCache::getGlobalCodeBlock):
2663         * runtime/Options.h:
2664         * tests/stress/shadow-chicken-enabled.js:
2665         (test5a.foo):
2666         (test5a):
2667         (test5b.foo):
2668         (test5b):
2669         (test6.foo):
2670         (test6):
2671
2672 2016-05-16  Saam barati  <sbarati@apple.com>
2673
2674         TypeSet/StructureShape have a flawed sense of JS prototype chains
2675         https://bugs.webkit.org/show_bug.cgi?id=157760
2676
2677         Reviewed by Joseph Pecoraro.
2678
2679         There was an assumption that we would bottom out in "Object". This is
2680         not true for many reasons. JS objects may not end in Object.prototype.
2681         Also, our mechanism of grabbing an Object's class name may also not
2682         bottom out in "Object". We were seeing this in the JS objects we use
2683         in the InjectedScriptSource.js inspector script.
2684
2685         * runtime/TypeSet.cpp:
2686         (JSC::StructureShape::leastCommonAncestor):
2687         * tests/typeProfiler/weird-prototype-chain.js: Added.
2688         (wrapper.foo):
2689         (wrapper.let.o2):
2690         (wrapper):
2691
2692 2016-05-16  Joseph Pecoraro  <pecoraro@apple.com>
2693
2694         Unreviewed rollout r200924. Caused js/regress/string-replace-generic.html to fail.
2695
2696         * API/JSProfilerPrivate.cpp: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
2697         (JSStartProfiling):
2698         (JSEndProfiling):
2699         * API/JSProfilerPrivate.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
2700         * CMakeLists.txt:
2701         * JavaScriptCore.xcodeproj/project.pbxproj:
2702         * bytecode/BytecodeList.json:
2703         * bytecode/BytecodeUseDef.h:
2704         (JSC::computeUsesForBytecodeOffset):
2705         (JSC::computeDefsForBytecodeOffset):
2706         * bytecode/CodeBlock.cpp:
2707         (JSC::CodeBlock::dumpBytecode):
2708         * bytecode/UnlinkedFunctionExecutable.cpp:
2709         (JSC::generateUnlinkedFunctionCodeBlock):
2710         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2711         * bytecode/UnlinkedFunctionExecutable.h:
2712         * bytecompiler/BytecodeGenerator.cpp:
2713         (JSC::BytecodeGenerator::BytecodeGenerator):
2714         (JSC::BytecodeGenerator::emitCall):
2715         (JSC::BytecodeGenerator::emitCallVarargs):
2716         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2717         (JSC::BytecodeGenerator::emitConstructVarargs):
2718         (JSC::BytecodeGenerator::emitConstruct):
2719         * bytecompiler/BytecodeGenerator.h:
2720         (JSC::CallArguments::profileHookRegister):
2721         (JSC::BytecodeGenerator::shouldEmitProfileHooks):
2722         * bytecompiler/NodesCodegen.cpp:
2723         (JSC::CallArguments::CallArguments):
2724         (JSC::CallFunctionCallDotNode::emitBytecode):
2725         (JSC::ApplyFunctionCallDotNode::emitBytecode):
2726         * dfg/DFGAbstractInterpreterInlines.h:
2727         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2728         * dfg/DFGByteCodeParser.cpp:
2729         (JSC::DFG::ByteCodeParser::parseBlock):
2730         * dfg/DFGCapabilities.cpp:
2731         (JSC::DFG::capabilityLevel):
2732         * dfg/DFGClobberize.h:
2733         (JSC::DFG::clobberize):
2734         * dfg/DFGDoesGC.cpp:
2735         (JSC::DFG::doesGC):
2736         * dfg/DFGFixupPhase.cpp:
2737         (JSC::DFG::FixupPhase::fixupNode):
2738         * dfg/DFGNodeType.h:
2739         * dfg/DFGPredictionPropagationPhase.cpp:
2740         * dfg/DFGSafeToExecute.h:
2741         (JSC::DFG::safeToExecute):
2742         * dfg/DFGSpeculativeJIT32_64.cpp:
2743         (JSC::DFG::SpeculativeJIT::compile):
2744         * dfg/DFGSpeculativeJIT64.cpp:
2745         (JSC::DFG::SpeculativeJIT::compile):
2746         * inspector/InjectedScriptBase.cpp:
2747         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
2748         * inspector/protocol/Timeline.json:
2749         * interpreter/Interpreter.cpp:
2750         (JSC::UnwindFunctor::operator()):
2751         (JSC::Interpreter::execute):
2752         (JSC::Interpreter::executeCall):
2753         (JSC::Interpreter::executeConstruct):
2754         * jit/JIT.cpp:
2755         (JSC::JIT::privateCompileMainPass):
2756         * jit/JIT.h:
2757         * jit/JITOpcodes.cpp:
2758         (JSC::JIT::emit_op_profile_will_call):
2759         (JSC::JIT::emit_op_profile_did_call):
2760         * jit/JITOpcodes32_64.cpp:
2761         (JSC::JIT::emit_op_profile_will_call):
2762         (JSC::JIT::emit_op_profile_did_call):
2763         * jit/JITOperations.cpp:
2764         * jit/JITOperations.h:
2765         * jsc.cpp:
2766         * llint/LLIntSlowPaths.cpp:
2767         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2768         * llint/LLIntSlowPaths.h:
2769         * llint/LowLevelInterpreter.asm:
2770         * parser/ParserModes.h:
2771         * profiler/CallIdentifier.h: Added.
2772         (JSC::CallIdentifier::CallIdentifier):
2773         (JSC::CallIdentifier::functionName):
2774         (JSC::CallIdentifier::url):
2775         (JSC::CallIdentifier::lineNumber):
2776         (JSC::CallIdentifier::columnNumber):
2777         (JSC::CallIdentifier::operator==):
2778         (JSC::CallIdentifier::operator!=):
2779         (JSC::CallIdentifier::Hash::hash):
2780         (JSC::CallIdentifier::Hash::equal):
2781         (JSC::CallIdentifier::hash):
2782         (JSC::CallIdentifier::operator const char*):
2783         (JSC::CallIdentifier::c_str):
2784         (WTF::HashTraits<JSC::CallIdentifier>::constructDeletedValue):
2785         (WTF::HashTraits<JSC::CallIdentifier>::isDeletedValue):
2786         * profiler/LegacyProfiler.cpp: Added.
2787         (JSC::LegacyProfiler::profiler):
2788         (JSC::LegacyProfiler::startProfiling):
2789         (JSC::LegacyProfiler::stopProfiling):
2790         (JSC::callFunctionForProfilesWithGroup):
2791         (JSC::LegacyProfiler::suspendProfiling):
2792         (JSC::LegacyProfiler::unsuspendProfiling):
2793         (JSC::LegacyProfiler::willExecute):
2794         (JSC::LegacyProfiler::didExecute):
2795         (JSC::LegacyProfiler::exceptionUnwind):
2796         (JSC::LegacyProfiler::createCallIdentifier):
2797         (JSC::createCallIdentifierFromFunctionImp):
2798         * profiler/LegacyProfiler.h: Added.
2799         (JSC::LegacyProfiler::currentProfiles):
2800         * profiler/Profile.cpp: Added.
2801         (JSC::Profile::create):
2802         (JSC::Profile::Profile):
2803         (JSC::Profile::~Profile):
2804         (JSC::Profile::debugPrint):
2805         (JSC::functionNameCountPairComparator):
2806         (JSC::Profile::debugPrintSampleStyle):
2807         * profiler/Profile.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
2808         * profiler/ProfileGenerator.cpp: Added.
2809         (JSC::ProfileGenerator::create):
2810         (JSC::ProfileGenerator::ProfileGenerator):
2811         (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor):
2812         (JSC::AddParentForConsoleStartFunctor::foundParent):
2813         (JSC::AddParentForConsoleStartFunctor::operator()):
2814         (JSC::ProfileGenerator::addParentForConsoleStart):
2815         (JSC::ProfileGenerator::title):
2816         (JSC::ProfileGenerator::beginCallEntry):
2817         (JSC::ProfileGenerator::endCallEntry):
2818         (JSC::ProfileGenerator::willExecute):
2819         (JSC::ProfileGenerator::didExecute):
2820         (JSC::ProfileGenerator::exceptionUnwind):
2821         (JSC::ProfileGenerator::stopProfiling):
2822         (JSC::ProfileGenerator::removeProfileStart):
2823         (JSC::ProfileGenerator::removeProfileEnd):
2824         * profiler/ProfileGenerator.h: Added.
2825         (JSC::ProfileGenerator::profile):
2826         (JSC::ProfileGenerator::origin):
2827         (JSC::ProfileGenerator::profileGroup):
2828         (JSC::ProfileGenerator::setIsSuspended):
2829         * profiler/ProfileNode.cpp: Added.
2830         (JSC::ProfileNode::ProfileNode):
2831         (JSC::ProfileNode::addChild):
2832         (JSC::ProfileNode::removeChild):
2833         (JSC::ProfileNode::spliceNode):
2834         (JSC::ProfileNode::traverseNextNodePostOrder):
2835         (JSC::ProfileNode::debugPrint):
2836         (JSC::ProfileNode::debugPrintSampleStyle):
2837         (JSC::ProfileNode::debugPrintRecursively):
2838         (JSC::ProfileNode::debugPrintSampleStyleRecursively):
2839         * profiler/ProfileNode.h: Added.
2840         (JSC::ProfileNode::create):
2841         (JSC::ProfileNode::Call::Call):
2842         (JSC::ProfileNode::Call::startTime):
2843         (JSC::ProfileNode::Call::setStartTime):
2844         (JSC::ProfileNode::Call::elapsedTime):
2845         (JSC::ProfileNode::Call::setElapsedTime):
2846         (JSC::ProfileNode::operator==):
2847         (JSC::ProfileNode::callerCallFrame):
2848         (JSC::ProfileNode::callIdentifier):
2849         (JSC::ProfileNode::id):
2850         (JSC::ProfileNode::functionName):
2851         (JSC::ProfileNode::url):
2852         (JSC::ProfileNode::lineNumber):
2853         (JSC::ProfileNode::columnNumber):
2854         (JSC::ProfileNode::parent):
2855         (JSC::ProfileNode::setParent):
2856         (JSC::ProfileNode::calls):
2857         (JSC::ProfileNode::lastCall):
2858         (JSC::ProfileNode::appendCall):
2859         (JSC::ProfileNode::children):
2860         (JSC::ProfileNode::firstChild):
2861         (JSC::ProfileNode::lastChild):
2862         (JSC::ProfileNode::nextSibling):
2863         (JSC::ProfileNode::setNextSibling):
2864         (JSC::ProfileNode::forEachNodePostorder):
2865         (JSC::CalculateProfileSubtreeDataFunctor::operator()):
2866         (JSC::CalculateProfileSubtreeDataFunctor::returnValue):
2867         * profiler/ProfilerJettisonReason.cpp:
2868         (WTF::printInternal):
2869         * profiler/ProfilerJettisonReason.h:
2870         * runtime/CodeCache.cpp:
2871         (JSC::CodeCache::getGlobalCodeBlock):
2872         (JSC::CodeCache::getProgramCodeBlock):
2873         (JSC::CodeCache::getEvalCodeBlock):
2874         (JSC::CodeCache::getModuleProgramCodeBlock):
2875         * runtime/CodeCache.h:
2876         * runtime/Executable.cpp:
2877         (JSC::ScriptExecutable::newCodeBlockFor):
2878         * runtime/JSGlobalObject.cpp:
2879         (JSC::JSGlobalObject::~JSGlobalObject):
2880         (JSC::JSGlobalObject::hasLegacyProfiler):
2881         (JSC::JSGlobalObject::createProgramCodeBlock):
2882         (JSC::JSGlobalObject::createEvalCodeBlock):
2883         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
2884         * runtime/JSGlobalObject.h:
2885         (JSC::JSGlobalObject::supportsLegacyProfiling):
2886         * runtime/Options.h:
2887         * runtime/VM.cpp:
2888         (JSC::VM::VM):
2889         (JSC::SetEnabledProfilerFunctor::operator()):
2890         (JSC::VM::setEnabledProfiler):
2891         * runtime/VM.h:
2892         (JSC::VM::enabledProfiler):
2893         (JSC::VM::enabledProfilerAddress):
2894
2895 2016-05-16  Konstantin Tokarev  <annulen@yandex.ru>
2896
2897         Unreviewed, fixed typo in a comment.
2898
2899         * assembler/MacroAssembler.h: Replaced "onvenience" with
2900         "convenience".
2901
2902 2016-05-16  Filip Pizlo  <fpizlo@apple.com>
2903
2904         FixupPhase should be more eager to demote bit math to untyped
2905         https://bugs.webkit.org/show_bug.cgi?id=157746
2906
2907         Reviewed by Mark Lam.
2908         
2909         This just makes the logic for how we fixup bit math match the way we do it in other places.
2910         This doesn't affect performance on any major benchmark but it's a big win on new
2911         microbenchmarks added in this change.
2912         
2913         Details:
2914
2915         object-and                                     11.1610+-0.7602     ^      4.8105+-0.1690        ^ definitely 2.3201x faster
2916         object-or                                      11.0845+-0.2487     ^      4.7146+-0.0374        ^ definitely 2.3511x faster
2917         object-xor                                     10.2946+-0.9946     ^      4.7278+-0.0814        ^ definitely 2.1775x faster
2918         object-lshift                                  10.4896+-1.0867     ^      4.7699+-0.0721        ^ definitely 2.1991x faster
2919         object-rshift                                  11.1239+-0.5010     ^      4.7194+-0.0445        ^ definitely 2.3570x faster
2920         object-urshift                                 10.9745+-0.1315     ^      4.7848+-0.0479        ^ definitely 2.2936x faster
2921
2922         * dfg/DFGFixupPhase.cpp:
2923         (JSC::DFG::FixupPhase::fixupNode):
2924
2925 2016-05-15  Michael Saboff  <msaboff@apple.com>
2926
2927         RegExp /y flag incorrect handling of mixed-length alternation
2928         https://bugs.webkit.org/show_bug.cgi?id=157723
2929
2930         Reviewed by Filip Pizlo.
2931
2932         Previously for sticky patterns, we were bailing out and exiting when backtracking
2933         alternatives with dissimilar match lengths.  Deleted that code.  Instead, for
2934         sticky patterns we need to process the backtracking except for advancing to the
2935         next input index.
2936
2937         * yarr/YarrJIT.cpp:
2938         (JSC::Yarr::YarrGenerator::backtrack):
2939
2940 2016-05-15  Filip Pizlo  <fpizlo@apple.com>
2941
2942         DFG::Plan shouldn't read from its VM once it's been cancelled
2943         https://bugs.webkit.org/show_bug.cgi?id=157726
2944
2945         Reviewed by Saam Barati.
2946         
2947         Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a
2948         cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling
2949         the plan.
2950         
2951         Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody
2952         would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard
2953         regression to spot because usually a cancelled plan will still refer to a valid VM.
2954         
2955         This change fixes the regression and makes it a lot easier to spot the regression in the
2956         future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this
2957         mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is
2958         cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to
2959         use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst.
2960         
2961         Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the
2962         plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the
2963         safepoint's VM to determine whether this is one of our safepoints *after* the plan is
2964         already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled
2965         when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's
2966         vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one
2967         loop and a cancel path for Safepoints in the loop after it).
2968
2969         * dfg/DFGJITFinalizer.cpp:
2970         (JSC::DFG::JITFinalizer::finalizeCommon):
2971         * dfg/DFGPlan.cpp:
2972         (JSC::DFG::Plan::Plan):
2973         (JSC::DFG::Plan::computeCompileTimes):
2974         (JSC::DFG::Plan::reportCompileTimes):
2975         (JSC::DFG::Plan::compileInThreadImpl):
2976         (JSC::DFG::Plan::reallyAdd):
2977         (JSC::DFG::Plan::notifyCompiling):
2978         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2979         (JSC::DFG::Plan::cancel):
2980         * dfg/DFGPlan.h:
2981         (JSC::DFG::Plan::canTierUpAndOSREnter):
2982         * dfg/DFGSafepoint.cpp:
2983         (JSC::DFG::Safepoint::cancel):
2984         (JSC::DFG::Safepoint::vm):
2985         * dfg/DFGSafepoint.h:
2986         * dfg/DFGWorklist.cpp:
2987         (JSC::DFG::Worklist::isActiveForVM):
2988         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
2989         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
2990         (JSC::DFG::Worklist::rememberCodeBlocks):
2991         (JSC::DFG::Worklist::visitWeakReferences):
2992         (JSC::DFG::Worklist::removeDeadPlans):
2993         (JSC::DFG::Worklist::runThread):
2994         * ftl/FTLJITFinalizer.cpp:
2995         (JSC::FTL::JITFinalizer::finalizeFunction):
2996
2997 2016-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2998
2999         Modernize Intl constructors; using InternalFunction::createSubclassStructure
3000         https://bugs.webkit.org/show_bug.cgi?id=157082
3001
3002         Reviewed by Darin Adler.
3003
3004         Previously, Intl constructors retrieve "prototype" to inherit the "new.target".
3005         At that time, this mis-assumed that getDirect() always returns meaningful JS value.
3006         Actually, it returns an empty value if a property does not exist.
3007
3008         Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure
3009         in Intl constructors. It is modern and preferable way since it can cache the derived
3010         structures in InternalFunction.
3011
3012         This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat.
3013         Those code are largely duplicate. This is now extracted into
3014         constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not
3015         have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat
3016         and LayoutTests/js/intl-numberformat.
3017
3018         * JavaScriptCore.xcodeproj/project.pbxproj:
3019         * runtime/IntlCollator.cpp:
3020         (JSC::IntlCollator::create):
3021         * runtime/IntlCollator.h:
3022         * runtime/IntlCollatorConstructor.cpp:
3023         (JSC::constructIntlCollator):
3024         (JSC::callIntlCollator):
3025         * runtime/IntlDateTimeFormat.cpp:
3026         (JSC::IntlDateTimeFormat::create):
3027         * runtime/IntlDateTimeFormat.h:
3028         * runtime/IntlDateTimeFormatConstructor.cpp:
3029         (JSC::constructIntlDateTimeFormat):
3030         (JSC::callIntlDateTimeFormat):
3031         * runtime/IntlDateTimeFormatPrototype.cpp:
3032         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
3033         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
3034         * runtime/IntlNumberFormat.cpp:
3035         (JSC::IntlNumberFormat::create):
3036         * runtime/IntlNumberFormat.h:
3037         * runtime/IntlNumberFormatConstructor.cpp:
3038         (JSC::constructIntlNumberFormat):
3039         (JSC::callIntlNumberFormat):
3040         * runtime/IntlNumberFormatPrototype.cpp:
3041         (JSC::IntlNumberFormatPrototypeGetterFormat):
3042         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
3043         * runtime/IntlObjectInlines.h: Added.
3044         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
3045         * tests/stress/intl-constructors-with-proxy.js: Added.
3046         (shouldBe):
3047         (throw.new.Error.Empty):
3048         (throw.new.Error):
3049         (shouldBe.Empty):
3050
3051 2016-05-14  Joseph Pecoraro  <pecoraro@apple.com>
3052
3053         Remove LegacyProfiler
3054         https://bugs.webkit.org/show_bug.cgi?id=153565
3055
3056         Reviewed by Mark Lam.
3057
3058         JavaScriptCore now provides a sampling profiler and it is enabled
3059         by all ports. Web Inspector switched months ago to using the
3060         sampling profiler and displaying its data. Remove the legacy
3061         profiler, as it is no longer being used by anything other then
3062         console.profile and tests. We will update console.profile's
3063         behavior soon to have new behavior and use the sampling data.
3064
3065         * API/JSProfilerPrivate.cpp: Removed.
3066         * API/JSProfilerPrivate.h: Removed.
3067         * CMakeLists.txt:
3068         * JavaScriptCore.xcodeproj/project.pbxproj:
3069         * bytecode/BytecodeList.json:
3070         * bytecode/BytecodeUseDef.h:
3071         (JSC::computeUsesForBytecodeOffset): Deleted.
3072         (JSC::computeDefsForBytecodeOffset): Deleted.
3073         * bytecode/CodeBlock.cpp:
3074         (JSC::CodeBlock::dumpBytecode): Deleted.
3075         * bytecode/UnlinkedFunctionExecutable.cpp:
3076         (JSC::generateUnlinkedFunctionCodeBlock):
3077         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3078         * bytecode/UnlinkedFunctionExecutable.h:
3079         * bytecompiler/BytecodeGenerator.cpp:
3080         (JSC::BytecodeGenerator::BytecodeGenerator):
3081         (JSC::BytecodeGenerator::emitCall):
3082         (JSC::BytecodeGenerator::emitCallVarargs):
3083         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
3084         (JSC::BytecodeGenerator::emitConstructVarargs):
3085         (JSC::BytecodeGenerator::emitConstruct):
3086         * bytecompiler/BytecodeGenerator.h:
3087         (JSC::CallArguments::profileHookRegister): Deleted.
3088         (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
3089         * bytecompiler/NodesCodegen.cpp:
3090         (JSC::CallFunctionCallDotNode::emitBytecode):
3091         (JSC::ApplyFunctionCallDotNode::emitBytecode):
3092         (JSC::CallArguments::CallArguments): Deleted.
3093         * dfg/DFGAbstractInterpreterInlines.h:
3094         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
3095         * dfg/DFGByteCodeParser.cpp:
3096         (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
3097         * dfg/DFGCapabilities.cpp:
3098         (JSC::DFG::capabilityLevel): Deleted.
3099         * dfg/DFGClobberize.h:
3100         (JSC::DFG::clobberize): Deleted.
3101         * dfg/DFGDoesGC.cpp:
3102         (JSC::DFG::doesGC): Deleted.
3103         * dfg/DFGFixupPhase.cpp:
3104         (JSC::DFG::FixupPhase::fixupNode): Deleted.
3105         * dfg/DFGNodeType.h:
3106         * dfg/DFGPredictionPropagationPhase.cpp:
3107         * dfg/DFGSafeToExecute.h:
3108         (JSC::DFG::safeToExecute): Deleted.
3109         * dfg/DFGSpeculativeJIT32_64.cpp:
3110         (JSC::DFG::SpeculativeJIT::compile): Deleted.
3111         * dfg/DFGSpeculativeJIT64.cpp:
3112         (JSC::DFG::SpeculativeJIT::compile): Deleted.
3113         * inspector/InjectedScriptBase.cpp:
3114         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
3115         * inspector/protocol/Timeline.json:
3116         * interpreter/Interpreter.cpp:
3117         (JSC::UnwindFunctor::operator()): Deleted.
3118         (JSC::Interpreter::execute): Deleted.
3119         (JSC::Interpreter::executeCall): Deleted.
3120         (JSC::Interpreter::executeConstruct): Deleted.
3121         * jit/JIT.cpp:
3122         (JSC::JIT::privateCompileMainPass): Deleted.
3123         * jit/JIT.h:
3124         * jit/JITOpcodes.cpp:
3125         (JSC::JIT::emit_op_profile_will_call): Deleted.
3126         (JSC::JIT::emit_op_profile_did_call): Deleted.
3127         * jit/JITOpcodes32_64.cpp:
3128         (JSC::JIT::emit_op_profile_will_call): Deleted.
3129         (JSC::JIT::emit_op_profile_did_call): Deleted.
3130         * jit/JITOperations.cpp:
3131         * jit/JITOperations.h:
3132         * jsc.cpp:
3133         * llint/LLIntSlowPaths.cpp:
3134         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
3135         * llint/LLIntSlowPaths.h:
3136         * llint/LowLevelInterpreter.asm:
3137         * parser/ParserModes.h:
3138         * profiler/CallIdentifier.h: Removed.
3139         * profiler/LegacyProfiler.cpp: Removed.
3140         * profiler/LegacyProfiler.h: Removed.
3141         * profiler/Profile.cpp: Removed.
3142         * profiler/Profile.h: Removed.
3143         * profiler/ProfileGenerator.cpp: Removed.
3144         * profiler/ProfileGenerator.h: Removed.
3145         * profiler/ProfileNode.cpp: Removed.
3146         * profiler/ProfileNode.h: Removed.
3147         * profiler/ProfilerJettisonReason.cpp:
3148         (WTF::printInternal): Deleted.
3149         * profiler/ProfilerJettisonReason.h:
3150         * runtime/CodeCache.cpp:
3151         (JSC::CodeCache::getGlobalCodeBlock):
3152         (JSC::CodeCache::getProgramCodeBlock):
3153         (JSC::CodeCache::getEvalCodeBlock):
3154         (JSC::CodeCache::getModuleProgramCodeBlock):
3155         * runtime/CodeCache.h:
3156         * runtime/Executable.cpp:
3157         (JSC::ScriptExecutable::newCodeBlockFor):
3158         * runtime/JSGlobalObject.cpp:
3159         (JSC::JSGlobalObject::createProgramCodeBlock):
3160         (JSC::JSGlobalObject::createEvalCodeBlock):
3161         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
3162         (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
3163         (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
3164         * runtime/JSGlobalObject.h:
3165         (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
3166         * runtime/Options.h:
3167         * runtime/VM.cpp:
3168         (JSC::VM::VM): Deleted.
3169         (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
3170         (JSC::VM::setEnabledProfiler): Deleted.
3171         * runtime/VM.h:
3172         (JSC::VM::enabledProfiler): Deleted.
3173         (JSC::VM::enabledProfilerAddress): Deleted.
3174
3175 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
3176
3177         jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash
3178         https://bugs.webkit.org/show_bug.cgi?id=157704
3179
3180         Reviewed by Saam Barati.
3181
3182         * jsc.cpp:
3183         (functionStartSamplingProfiler):
3184         (functionSamplingProfilerStackTraces):
3185         Throw an exception instead of crashing if we haven't started sampling.
3186
3187         * inspector/agents/InspectorScriptProfilerAgent.cpp:
3188         (Inspector::InspectorScriptProfilerAgent::startTracking):
3189         * runtime/VM.h:
3190         * runtime/VM.cpp:
3191         (JSC::VM::ensureSamplingProfiler):
3192         Switch ensure to returning a reference, like most other ensures.
3193
3194 2016-05-13  Saam barati  <sbarati@apple.com>
3195
3196         DFG/FTL have a few bugs in their reasoning about the scope
3197         https://bugs.webkit.org/show_bug.cgi?id=157696
3198
3199         Reviewed by Benjamin Poulain.
3200
3201         1. When the debugger is enabled, it is easier for the DFG to reason
3202         about the scope register by simply claiming all nodes read the scope
3203         register. This prevents us from ever entering the runtime where we
3204         may take a stack trace but there isn't a scope on the stack.
3205
3206         2. This patch fixes a bug where the FTL compilation wasn't properly
3207         setting the CodeBlock register. It was only doing this when there
3208         was inline data, but when the debugger is enabled, we never inline.
3209         So this code just needed to be removed from that loop. It was never
3210         right for it to be inside the loop.
3211
3212         * dfg/DFGClobberize.h:
3213         (JSC::DFG::clobberize):
3214         * ftl/FTLCompile.cpp:
3215         (JSC::FTL::compile):
3216
3217 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
3218
3219         [JSC] SetLocal without exit do not need phantoms
3220         https://bugs.webkit.org/show_bug.cgi?id=157653
3221
3222         Reviewed by Filip Pizlo.
3223
3224         I made a mistake in r200498.
3225
3226         If a SetLocal cannot possibly exit, we were not clearing
3227         the source of the operand. As a result, we sometime kept
3228         a value alive up to the end of the block.
3229
3230         That's uncommon because SetLocal typically appear
3231         toward the end of blocks. That's probably why there was
3232         no perf impact with that fix.
3233
3234         * dfg/DFGPhantomInsertionPhase.cpp:
3235
3236 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
3237
3238         [JSC] Move the CheckTierUp function calls out of the main path
3239         https://bugs.webkit.org/show_bug.cgi?id=157668
3240
3241         Reviewed by Mark Lam.
3242
3243         If you have a tiny tiny loop (for example, Sunspider's bits-in-byte),
3244         the size of CheckTierUp is a problem.
3245
3246         On multi-issue CPUs, the node is so big that we do not
3247         get to run anything from the loop in the instruction fetch.
3248
3249         On x86, having a bigger loop also pushes us out of the LSD.
3250
3251         This is a 6% improvement on bits-in-byte. Other Sunspider tests
3252         only improves marginally.
3253
3254         * dfg/DFGSpeculativeJIT.cpp:
3255         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
3256         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
3257         * dfg/DFGSpeculativeJIT.h:
3258         (JSC::DFG::SpeculativeJIT::silentSpill):
3259         (JSC::DFG::SpeculativeJIT::silentFill):
3260         * dfg/DFGSpeculativeJIT64.cpp:
3261         (JSC::DFG::SpeculativeJIT::compile):
3262
3263 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
3264
3265         [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used
3266         https://bugs.webkit.org/show_bug.cgi?id=157671
3267
3268         Reviewed by Mark Lam.
3269
3270         This improves the chances of having a value
3271         when issuing the TEST.
3272
3273         * jit/JITPropertyAccess.cpp:
3274         (JSC::JIT::emitLoadWithStructureCheck):
3275
3276 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
3277
3278         Web Inspector: Inform augmenting client when inspector controller is destroyed
3279         https://bugs.webkit.org/show_bug.cgi?id=157688
3280         <rdar://problem/25832724>
3281
3282         Reviewed by Timothy Hatcher.
3283
3284         * inspector/JSGlobalObjectInspectorController.cpp:
3285         (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
3286         * inspector/augmentable/AugmentableInspectorControllerClient.h:
3287         There is a weak relationship between the InspectorController and the
3288         AugmentingClient. Let the augmenting client know when the controller
3289         is destroyed so it doesn't try to use us anymore.
3290
3291 2016-05-13  Geoffrey Garen  <ggaren@apple.com>
3292
3293         Runaway malloc memory usage in this simple JSC program
3294         https://bugs.webkit.org/show_bug.cgi?id=157682
3295
3296         Reviewed by Mark Lam.
3297
3298         * heap/WeakSet.cpp:
3299         (JSC::WeakSet::sweep): Whenever we might add a block to
3300         m_logicallyEmptyWeakBlocks, be sure also to sweep a block in
3301         m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals
3302         even when all memory is freed.
3303
3304         We do this whenever we *might* add a block and not just whenever we *do*
3305         add a block because we'd like to sweep the entries in
3306         m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this
3307         is a reasonably rate-limited opportunity to do so.
3308
3309 2016-05-13  Mark Lam  <mark.lam@apple.com>
3310
3311         We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM.
3312         https://bugs.webkit.org/show_bug.cgi?id=157537
3313         <rdar://problem/24794845>
3314
3315         Reviewed by Michael Saboff.
3316
3317         The pre-existing code behaves this way:
3318
3319         1. When JS code throws an exception, it saves callee save registers in
3320            the VM calleeSaveRegistersBuffer.  These values are meant to be restored
3321            to the callee save registers later either at the catch handler or at the
3322            uncaught exception handler.
3323
3324         2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect
3325            the exception.  That C++ code can change the values of the callee save