46e5a9aebe553ef10e2b546f041d08e5867f5652
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-10-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [ES6] GeneratorFunction (a.k.a. GeneratorWrapperFunction)'s prototype object does not have constructor property
4         https://bugs.webkit.org/show_bug.cgi?id=162849
5
6         Reviewed by Geoffrey Garen.
7
8         Since GeneratorFunction is not constructible, GeneratorFunction.prototype does not have "constructor" property.
9
10             function* generatorFunction() { }
11             generatorFunction.prototype.constructor // undefined
12
13         * runtime/JSFunction.cpp:
14         (JSC::JSFunction::getOwnPropertySlot):
15
16 2016-10-03  Nicolas Breidinger  <Nicolas.Breidinger@sony.com>
17
18         JSStringRef should define JSChar without platform checks
19         https://bugs.webkit.org/show_bug.cgi?id=162808
20
21         Reviewed by Mark Lam.
22
23         * API/JSStringRef.h:
24
25 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
26
27         [ES6] Align attributes of Generator related properties to spec
28         https://bugs.webkit.org/show_bug.cgi?id=162839
29
30         Reviewed by Saam Barati.
31
32         This patch fixes attributes of Generator related properties.
33         These fixes are covered by test262.
34
35         * runtime/GeneratorFunctionConstructor.cpp:
36         (JSC::GeneratorFunctionConstructor::finishCreation):
37         * runtime/GeneratorFunctionConstructor.h:
38         * runtime/GeneratorFunctionPrototype.cpp:
39         (JSC::GeneratorFunctionPrototype::finishCreation):
40         * runtime/GeneratorFunctionPrototype.h:
41         * runtime/GeneratorPrototype.h:
42         * runtime/JSGlobalObject.cpp:
43         (JSC::JSGlobalObject::init):
44
45 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
46
47         [ES6] GeneratorFunction constructor should instantiate generator function
48         https://bugs.webkit.org/show_bug.cgi?id=162838
49
50         Reviewed by Saam Barati.
51
52         GeneratorFunction's constructor should return an instance of JSGeneratorFunction
53         instead of JSFunction. In this patch, we fix the following 2 things.
54
55         1. GeneratorFunction constructor should use JSGeneratorFunction
56
57             Previously, we used JSFunction to construct a result. It's wrong. We use JSGeneratorFunction.
58
59         2. Pass newTarget into GeneratorFunction constructor to make it subclassible
60
61             We did not leverage newTarget when using GeneratorFunction constructor.
62             Using it correctly to create the subclass Structure and making GeneratorFunction subclassible.
63
64         Test262 test covers (1), but (2) is not covered. We add tests that covers both to stress tests.
65
66         * runtime/FunctionConstructor.cpp:
67         (JSC::constructFunctionSkippingEvalEnabledCheck):
68         * runtime/GeneratorFunctionConstructor.cpp:
69         (JSC::constructGeneratorFunctionConstructor):
70         * runtime/JSGeneratorFunction.cpp:
71         (JSC::JSGeneratorFunction::JSGeneratorFunction):
72         (JSC::JSGeneratorFunction::createImpl):
73         (JSC::JSGeneratorFunction::create):
74         (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
75         * runtime/JSGeneratorFunction.h:
76
77 2016-10-01  Filip Pizlo  <fpizlo@apple.com>
78
79         Get rid of isMarkedOrNewlyAllocated
80         https://bugs.webkit.org/show_bug.cgi?id=162842
81
82         Reviewed by Dan Bernstein.
83         
84         This function has become dead code. This change removes it.
85
86         * heap/CellContainer.h:
87         * heap/CellContainerInlines.h:
88         (JSC::CellContainer::isMarkedOrNewlyAllocated): Deleted.
89         * heap/LargeAllocation.h:
90         (JSC::LargeAllocation::isLive):
91         (JSC::LargeAllocation::isMarkedOrNewlyAllocated): Deleted.
92         * heap/MarkedBlock.cpp:
93         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
94         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
95         * heap/MarkedBlock.h:
96         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
97         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
98
99 2016-10-01  Joseph Pecoraro  <pecoraro@apple.com>
100
101         Rename DebugHookID to DebugHookType
102         https://bugs.webkit.org/show_bug.cgi?id=162820
103
104         Reviewed by Alex Christensen.
105
106         * bytecode/CodeBlock.cpp:
107         (JSC::debugHookName):
108         (JSC::CodeBlock::dumpBytecode):
109         * bytecompiler/BytecodeGenerator.cpp:
110         (JSC::BytecodeGenerator::emitDebugHook):
111         * bytecompiler/BytecodeGenerator.h:
112         * interpreter/Interpreter.cpp:
113         (JSC::Interpreter::debug):
114         * interpreter/Interpreter.h:
115         * jit/JITOperations.cpp:
116         * llint/LLIntSlowPaths.cpp:
117         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
118
119 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
120
121         Web Inspector: Stepping to a line with an autoContinue breakpoint should still pause
122         https://bugs.webkit.org/show_bug.cgi?id=161712
123         <rdar://problem/28193970>
124
125         Reviewed by Brian Burg.
126
127         * debugger/Debugger.cpp:
128         (JSC::Debugger::pauseIfNeeded):
129         If we stepped to an auto-continue breakpoint we should continue
130         stepping, not just continue.
131
132 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
133
134         B3 should support trapping memory accesses
135         https://bugs.webkit.org/show_bug.cgi?id=162689
136
137         Reviewed by Geoffrey Garen.
138         
139         This adds a traps flag to B3::Kind. It also makes B3::Kind work more like Air::Kind, in the
140         sense that it's a bag of distinct bits - it doesn't need to be a union unless we get enough
141         things that it would make a difference.
142         
143         The only analysis that needs to know about traps is effects. It now knows that traps implies
144         sideExits, which means that this turns off DCE. The only optimization that needs to know
145         about traps is eliminateCommonSubexpressions(), which needs to pessimize its store
146         elimination if the store traps.
147         
148         The hard part of this change is teaching the instruction selector to faithfully carry the
149         traps flag down to Air. I got this to work by making ArgPromise a non-copyable object that
150         knows whether you've used it in an instruction. It knows when you call consume(). If you do
151         this then ArgPromise cannot be destructed without first passing your inst through it. This,
152         along with a few other hacks, means that all of the load-op and load-op-store fusions
153         correctly carry the trap bit: if any of the B3 loads or stores involved traps then you get
154         traps in Air.
155         
156         This framework also sets us up to do bug 162688, since the ArgPromise::inst() hook is
157         powerful enough to allow wrapping the instruction with a Patch.
158         
159         I added some tests to testb3 that verify that optimizations are appropriately inhibited and
160         that the traps flag survives until the bitter end of Air.
161
162         * b3/B3EliminateCommonSubexpressions.cpp:
163         * b3/B3Kind.cpp:
164         (JSC::B3::Kind::dump):
165         * b3/B3Kind.h:
166         (JSC::B3::Kind::Kind):
167         (JSC::B3::Kind::hasExtraBits):
168         (JSC::B3::Kind::isChill):
169         (JSC::B3::Kind::setIsChill):
170         (JSC::B3::Kind::hasTraps):
171         (JSC::B3::Kind::traps):
172         (JSC::B3::Kind::setTraps):
173         (JSC::B3::Kind::operator==):
174         (JSC::B3::Kind::hash):
175         (JSC::B3::trapping):
176         * b3/B3LowerToAir.cpp:
177         (JSC::B3::Air::LowerToAir::ArgPromise::swap):
178         (JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
179         (JSC::B3::Air::LowerToAir::ArgPromise::operator=):
180         (JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise):
181         (JSC::B3::Air::LowerToAir::ArgPromise::setTraps):
182         (JSC::B3::Air::LowerToAir::ArgPromise::consume):
183         (JSC::B3::Air::LowerToAir::ArgPromise::inst):
184         (JSC::B3::Air::LowerToAir::trappingInst):
185         (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
186         (JSC::B3::Air::LowerToAir::appendUnOp):
187         (JSC::B3::Air::LowerToAir::appendBinOp):
188         (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
189         (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
190         (JSC::B3::Air::LowerToAir::appendStore):
191         (JSC::B3::Air::LowerToAir::append):
192         (JSC::B3::Air::LowerToAir::createGenericCompare):
193         (JSC::B3::Air::LowerToAir::createBranch):
194         (JSC::B3::Air::LowerToAir::createCompare):
195         (JSC::B3::Air::LowerToAir::createSelect):
196         (JSC::B3::Air::LowerToAir::lower):
197         * b3/B3Validate.cpp:
198         * b3/B3Value.cpp:
199         (JSC::B3::Value::effects):
200         * b3/B3Value.h:
201         * b3/air/AirCode.h:
202         * b3/testb3.cpp:
203         (JSC::B3::testTrappingLoad):
204         (JSC::B3::testTrappingStore):
205         (JSC::B3::testTrappingLoadAddStore):
206         (JSC::B3::testTrappingLoadDCE):
207         (JSC::B3::testTrappingStoreElimination):
208         (JSC::B3::run):
209
210 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
211
212         Web Inspector: Stepping over/out of a function sometimes resumes instead of taking you to caller
213         https://bugs.webkit.org/show_bug.cgi?id=162802
214         <rdar://problem/28569982>
215
216         Reviewed by Mark Lam.
217
218         * debugger/Debugger.cpp:
219         (JSC::Debugger::stepOverStatement):
220         (JSC::Debugger::stepOutOfFunction):
221         Enable stepping mode when we start stepping.
222
223 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
224
225         B3::moveConstants should be able to edit code to minimize the number of constants
226         https://bugs.webkit.org/show_bug.cgi?id=162764
227
228         Reviewed by Saam Barati.
229         
230         There are some interesting cases where we can reduce the number of constant materializations if
231         we teach moveConstants() how to edit code. The two examples that this patch supports are:
232         
233             - Loads and stores from a constant pointer. Since loads and stores get an offset for free
234               and the instruction selector is really good at handling it, and since we can query Air to
235               see what kinds of offsets are legal, we can sometimes avoid using a constant pointer that
236               is specific to the absolute address of that load and instead pick some other constant
237               that is within offset distance of ours.
238             
239             - Add and Sub by a constant (x + c, x - c). Since x + c = x - -c and x - c = x + -c, we can
240               flip Add to Sub or vice versa if the negated constant is available.
241         
242         This change makes moveConstants() pick the most dominant constant that works for an value. In
243         the case of memory accesses, it uses Air::Arg::isValidAddrForm() to work out what other
244         constants would work. In the case of Add/Sub, it simply looks for the negated constant. This
245         should result in something like a minimal number of constants since these rules always pick the
246         most dominant constant that works - so if an Add's constant is already most dominant then
247         nothing changes, but if the negated one is more dominant then it becomes a Sub.
248         
249         This is a 0.5% speed-up on LongSpider and neutral elsewhere. It's a speed-up because the
250         absolute address thing reduces the number of address materializations that we have to do, while
251         the add/sub thing prevents us from having to materialize 0x1000000000000 to box doubles.
252         However, this may introduce a pathology, which I've filed a bug for: bug 162796.
253
254         * b3/B3MoveConstants.cpp:
255         * b3/B3MoveConstants.h:
256         * b3/B3UseCounts.h:
257         * b3/air/AirFixObviousSpills.cpp:
258         * b3/testb3.cpp:
259         (JSC::B3::testMoveConstants):
260         (JSC::B3::run):
261
262 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
263
264         Fix modules tests after r206653 handle breakpoint locations in import/export statements
265         https://bugs.webkit.org/show_bug.cgi?id=162807
266
267         Reviewed by Mark Lam.
268
269         * parser/ASTBuilder.h:
270         (JSC::ASTBuilder::createExportDefaultDeclaration):
271         (JSC::ASTBuilder::createExportLocalDeclaration):
272         Don't record an extra breakpoint location for the statement
273         within an export statement.
274
275         * parser/Parser.cpp:
276         (JSC::Parser<LexerType>::parseModuleSourceElements):
277         Record a pause location for import/export statements.
278
279 2016-09-30  Mark Lam  <mark.lam@apple.com>
280
281         Remove the dumping of the stack back trace in VM::verifyExceptionCheckNeedIsSatisfied().
282         https://bugs.webkit.org/show_bug.cgi?id=162797
283
284         Reviewed by Geoffrey Garen.
285
286         This is because the RELEASE_ASSERT() that follows immediately after will also
287         dump the stack back trace.  Hence, the first dump will be redundant.
288
289         Also removed an extra space in the dataLog output.
290
291         * runtime/VM.cpp:
292         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
293
294 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
295
296         Web Inspector: Stepping through `a(); b(); c();` it is unclear where we are and what is about to execute
297         https://bugs.webkit.org/show_bug.cgi?id=161658
298         <rdar://problem/28181254>
299
300         Reviewed by Geoffrey Garen.
301
302         * parser/Parser.cpp:
303         (JSC::Parser<LexerType>::parseAssignmentExpression):
304         Updated pause location for unary expressions.
305
306 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
307
308         Breakpoints on blank lines or comments don't break
309         https://bugs.webkit.org/show_bug.cgi?id=9885
310         <rdar://problem/6134406>
311
312         Reviewed by Mark Lam.
313
314         This change introduces a way to perform a Debugger Parse of a script.
315         This debugger parse gathers a list of breakpoint locations, which
316         the backend uses to resolve breakpoint locations that came from the
317         Inspector frontend to the exact location we would actually pause.
318         We gather this information from the parser so that we can eagerly
319         get this information without requiring the code to have executed (the
320         real op_debugs are generated during bytecode generation when code
321         is actually evaluated).
322
323         If an input location was on a line with whitespace or a comment, the
324         resolved breakpoint location would be before the next statement that
325         will be executed. That may be the next line, or even later. We also
326         update our policy when setting breakpoints on and around function
327         statements to better match user expectations.
328
329         For example, when resolving breakpoints in:
330
331             1.  // Comment
332             2.  before;
333             3.
334             4.  function foo() {
335             5.      inside;
336             6.  }
337             7.
338             8.  after;
339
340         A breakpoint on line 1, a comment, resolves to line 2 the next
341         statement that will execute.
342
343         A breakpoint on line 3 or 7, empty lines, resolves to line 8 the next
344         statement that will execute. This skips past the definition of foo,
345         just like stepping would have done. The creation of foo would have
346         been hoisted, which would have happened before execution of the
347         other statements.
348
349         A breakpoint on line 4, a function signature, resolves to line 5,
350         inside the function. Users would expect to pause inside of a function
351         when setting a breakpoint on that function's name or opening brace.
352
353         A breakpoint on line 6, a function's closing brace, resolves to
354         line 6. The debugger will pause whenever execution leaves foo due to
355         a return and not an exception. This matches stepping behavior. An
356         explicit or implicit return (the implicit return undefined) will
357         pause on the closing brace as we leave the function, giving users
358         an opportunity to inspect the final state before leaving.
359
360         --
361
362         At this point, op_debug's are still emitted at custom locations during
363         bytecode generation of other statements / expressions. In order to
364         ensure the generated op_debugs correspond to locations the Parser
365         determined were breakpoint locations, the Parser sets a "needs debug
366         hook" flag on the nodes it will use for breakpoint locations, and
367         we assert during bytecode generation that op_debugs are only emitted
368         for nodes that were marked as needing debug hooks.
369
370         This still leaves open the possibility that the Parser will mark
371         some nodes that get missed during bytecode generation, so we might
372         fail to emit some op_debugs. The next step will be eliminating the
373         custom emitDebugHooks spread across StatementNode and ExpressionNode
374         subclasses, and instead always generating op_debugs whenever we
375         emit a flagged node.
376
377         --
378
379         * CMakeLists.txt:
380         * JavaScriptCore.xcodeproj/project.pbxproj:
381         New DebuggerParseData files.
382
383         * API/JSScriptRef.cpp:
384         (OpaqueJSScript::OpaqueJSScript):
385         * jsc.cpp:
386         (functionCheckModuleSyntax):
387         * parser/SourceCode.h:
388         (JSC::makeSource):
389         * parser/SourceProvider.cpp:
390         (JSC::SourceProvider::SourceProvider):
391         * parser/SourceProvider.h:
392         (JSC::SourceProvider::sourceType):
393         (JSC::StringSourceProvider::create):
394         (JSC::StringSourceProvider::StringSourceProvider):
395         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
396         (JSC::SourceProvider::startPosition): Deleted.
397         Add a new type on SourceProvider to distinguish if its script was
398         intended to be a Script, Module, or WebAssembly. This information
399         will be needed to know how to best parse this file when the
400         debugger decides to lazily parse.
401
402         * runtime/Executable.cpp:
403         (JSC::EvalExecutable::EvalExecutable):
404         (JSC::ProgramExecutable::ProgramExecutable):
405         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
406         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
407         * runtime/ModuleLoaderPrototype.cpp:
408         (JSC::moduleLoaderPrototypeParseModule):
409         ASSERT the SourceProvider type matches the executable type we are
410         creating for it.
411
412         * parser/ASTBuilder.h:
413         (JSC::ASTBuilder::breakpointLocation):
414         * parser/SyntaxChecker.h:
415         (JSC::SyntaxChecker::operatorStackPop):
416         When gathering breakpoint positions, get the position from the
417         current node. In the SyntaxChecker, return an invalid position.
418
419         * parser/Nodes.h:
420         (JSC::ExpressionNode::needsDebugHook):
421         (JSC::ExpressionNode::setNeedsDebugHook):
422         (JSC::StatementNode::needsDebugHook):
423         (JSC::StatementNode::setNeedsDebugHook):
424         When gathering breakpoint positions, mark the node as needing
425         a debug hook. For now we assert op_debugs generated must come
426         from these nodes. Later we should just generate op_debugs for
427         these nodes.
428
429         * parser/Parser.cpp:
430         (JSC::Parser<LexerType>::Parser):
431         (JSC::Parser<LexerType>::parseStatementListItem):
432         (JSC::Parser<LexerType>::parseDoWhileStatement):
433         (JSC::Parser<LexerType>::parseWhileStatement):
434         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
435         (JSC::Parser<LexerType>::parseForStatement):
436         (JSC::Parser<LexerType>::parseWithStatement):
437         (JSC::Parser<LexerType>::parseSwitchStatement):
438         (JSC::Parser<LexerType>::parseStatement):
439         (JSC::Parser<LexerType>::parseFunctionBody):
440         (JSC::Parser<LexerType>::parseFunctionInfo):
441         (JSC::Parser<LexerType>::parseIfStatement):
442         (JSC::Parser<LexerType>::parseAssignmentExpression):
443         * parser/Parser.h:
444         (JSC::parse):
445         Add an optional DebuggerParseData struct to the Parser. When available
446         the Parser will gather debugger data, and parse all functions with the
447         ASTBuilder instead of SyntaxChecking inner functions.
448
449         * debugger/DebuggerParseData.cpp: Added.
450         (JSC::DebuggerPausePositions::breakpointLocationForLineColumn):
451         (JSC::DebuggerPausePositions::sort):
452         (JSC::gatherDebuggerParseData):
453         (JSC::gatherDebuggerParseDataForSource):
454         * debugger/DebuggerParseData.h: Copied from Source/JavaScriptCore/debugger/DebuggerPrimitives.h.
455         (JSC::DebuggerPausePositions::DebuggerPausePositions):
456         (JSC::DebuggerPausePositions::appendPause):
457         (JSC::DebuggerPausePositions::appendEntry):
458         (JSC::DebuggerPausePositions::appendLeave):
459         The DebuggerParseData struct currently only contains a list of pause positions.
460         Once populated it can resolve an input location to a pause position.
461
462         * bytecompiler/BytecodeGenerator.cpp:
463         (JSC::BytecodeGenerator::emitCall):
464         (JSC::BytecodeGenerator::emitCallVarargs):
465         (JSC::BytecodeGenerator::emitDebugHook):
466         (JSC::BytecodeGenerator::emitEnumeration):
467         * bytecompiler/BytecodeGenerator.h:
468         * bytecompiler/NodesCodegen.cpp:
469         (JSC::EmptyStatementNode::emitBytecode):
470         (JSC::DebuggerStatementNode::emitBytecode):
471         (JSC::ExprStatementNode::emitBytecode):
472         (JSC::DeclarationStatement::emitBytecode):
473         (JSC::IfElseNode::emitBytecode):
474         (JSC::DoWhileNode::emitBytecode):
475         (JSC::WhileNode::emitBytecode):
476         (JSC::ForNode::emitBytecode):
477         (JSC::ForInNode::emitBytecode):
478         (JSC::ContinueNode::emitBytecode):
479         (JSC::BreakNode::emitBytecode):
480         (JSC::ReturnNode::emitBytecode):
481         (JSC::WithNode::emitBytecode):
482         (JSC::SwitchNode::emitBytecode):
483         (JSC::ThrowNode::emitBytecode):
484         Emit op_debugs for the nodes themselves. Assert when we do that the
485         Parser had marked them as needing a debug hook.
486
487         * debugger/Breakpoint.h:
488         (JSC::Breakpoint::Breakpoint):
489         A breakpoint may be resolved or unresolved. Debugger::resolveBreakpoint
490         must be used to resolve the breakpoint. Most methods now require a
491         resolved breakpoint.
492
493         * debugger/Debugger.h:
494         * debugger/Debugger.cpp:
495         (JSC::Debugger::detach):
496         (JSC::Debugger::toggleBreakpoint):
497         (JSC::Debugger::debuggerParseData):
498         (JSC::Debugger::resolveBreakpoint):
499         (JSC::Debugger::setBreakpoint):
500         (JSC::Debugger::clearParsedData):
501         Provide a public method to resolve a breakpoint location in a script.
502         This will gather debugger parse data for the script if none is available.
503         Ensure clients have resolved a breakpoint before attempting to set it.
504         Currently we allow only a single breakpoint at a location. This may
505         need to change if multiple breakpoints resolve to the same location
506         but have different actions.
507
508         * inspector/ScriptDebugListener.h:
509         ScriptDebugServer::Script is effectively duplicating most of the data from
510         a SourceProvider. We should eliminate this and just use SourceProvider.
511
512         * inspector/ScriptDebugServer.cpp:
513         (Inspector::ScriptDebugServer::setBreakpointActions):
514         (Inspector::ScriptDebugServer::removeBreakpointActions):
515         (Inspector::ScriptDebugServer::getActionsForBreakpoint):
516         (Inspector::ScriptDebugServer::clearBreakpointActions):
517         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
518         (Inspector::ScriptDebugServer::dispatchDidParseSource):
519         (Inspector::ScriptDebugServer::handleBreakpointHit):
520         (Inspector::ScriptDebugServer::setBreakpoint): Deleted.
521         (Inspector::ScriptDebugServer::removeBreakpoint): Deleted.
522         (Inspector::ScriptDebugServer::clearBreakpoints): Deleted.
523         * inspector/ScriptDebugServer.h:
524         Reduce ScriptDebugServer's involvement in breakpoints to just handling
525         breakpoint actions. Eventually we should eliminate it alltogether and
526         fold breakpoint logic into Debugger or DebugAgent.
527
528         * inspector/agents/InspectorDebuggerAgent.h:
529         * inspector/agents/InspectorDebuggerAgent.cpp:
530         (Inspector::buildDebuggerLocation):
531         (Inspector::parseLocation):
532         (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
533         (Inspector::InspectorDebuggerAgent::setBreakpoint):
534         (Inspector::InspectorDebuggerAgent::didSetBreakpoint):
535         (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
536         (Inspector::InspectorDebuggerAgent::removeBreakpoint):
537         (Inspector::InspectorDebuggerAgent::continueToLocation):
538         (Inspector::InspectorDebuggerAgent::didParseSource):
539         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
540         The Inspector can set breakpoints in multiple ways.
541         Ensure that once we have the Script that we always
542         resolve the breakpoint location before setting the
543         breakpoint. The different paths are:
544         
545         - setBreakpoint(scriptId, location)
546           - Here we know the SourceProvider by its SourceID
547             - resolve and set
548         
549         - setBreakpointByURL(url, location)
550           - Search for existing Scripts that match the URL
551             - resolve in each and set
552           - When new Scripts are parsed that match the URL
553             - resolve and set
554             
555
556 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
557
558         Web Inspector: Stepping out of a function finishes the line that called it.
559         https://bugs.webkit.org/show_bug.cgi?id=155325
560         <rdar://problem/25094578>
561
562         Reviewed by Mark Lam.
563
564         Also addresses:
565         <https://webkit.org/b/161721> Web Inspector: Stepping all the way through program should not cause a pause on the next program that executes
566         <https://webkit.org/b/161716> Web Inspector: Stepping into a function / program should not require stepping to the first statement
567
568         This change introduces a new op_debug hook: WillExecuteExpression.
569         Currently this new hook is only used for pausing at function calls.
570         We may decide to add it to other places later where pausing with
571         finer granularity then statements (or lines) if useful.
572
573         This updates the location and behavior of some of the existing debug
574         hooks, to be more consistent and useful if the exact location of the
575         pause is displayed. For example, in control flow statements like
576         `if` and `while`, the pause location is the expression itself that
577         will be evaluated, not the location of the `if` or `while` keyword.
578         For example:
579
580             if (|condition)
581             while (|condition)
582
583         Finally, this change gets rid of some unnecessary / useless pause
584         locations such as on entering a function and on entering a program.
585         These pauses are not needed because if there is a statement, we
586         would pause before the statement and it is equivalent. We continue
587         to pause when leaving a function via stepping by uniformly jumping
588         to the closing brace of the function. This gives users a chance
589         to observe state before leaving the function.
590
591         * bytecode/CodeBlock.cpp:
592         (JSC::debugHookName):
593         * bytecode/UnlinkedCodeBlock.cpp:
594         (JSC::dumpLineColumnEntry):
595         Logging strings for the new debug hook.
596
597         * bytecompiler/BytecodeGenerator.h:
598         * bytecompiler/BytecodeGenerator.cpp:
599         (JSC::BytecodeGenerator::emitCallInTailPosition):
600         (JSC::BytecodeGenerator::emitCallEval):
601         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
602         (JSC::BytecodeGenerator::emitConstructVarargs):
603         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
604         (JSC::BytecodeGenerator::emitCallDefineProperty):
605         (JSC::BytecodeGenerator::emitConstruct):
606         (JSC::BytecodeGenerator::emitGetTemplateObject):
607         (JSC::BytecodeGenerator::emitIteratorNext):
608         (JSC::BytecodeGenerator::emitIteratorNextWithValue):
609         (JSC::BytecodeGenerator::emitIteratorClose):
610         (JSC::BytecodeGenerator::emitDelegateYield):
611         All emitCall variants now take an enum to decide whether or not to
612         emit the WillExecuteExpression debug hook.
613
614         (JSC::BytecodeGenerator::emitCall):
615         (JSC::BytecodeGenerator::emitCallVarargs):
616         In the two real implementations, actually decide to emit the debug
617         hook or not based on the parameter.
618
619         (JSC::BytecodeGenerator::emitEnumeration):
620         This is shared looping code used by for..of iteration of iterables.
621         When used by ForOfNode, we want to emit a pause location during
622         iteration.
623
624         (JSC::BytecodeGenerator::emitWillLeaveCallFrameDebugHook):
625         This is shared call frame leave code to emit a consistent pause
626         location when leaving a function.
627
628         * bytecompiler/NodesCodegen.cpp:
629         (JSC::EvalFunctionCallNode::emitBytecode):
630         (JSC::FunctionCallValueNode::emitBytecode):
631         (JSC::FunctionCallResolveNode::emitBytecode):
632         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
633         (JSC::FunctionCallBracketNode::emitBytecode):
634         (JSC::FunctionCallDotNode::emitBytecode):
635         (JSC::CallFunctionCallDotNode::emitBytecode):
636         (JSC::ApplyFunctionCallDotNode::emitBytecode):
637         (JSC::TaggedTemplateNode::emitBytecode):
638         (JSC::ArrayPatternNode::bindValue):
639         All tail position calls are the function calls that we want to emit
640         debug hooks for. All non-tail call calls appear to be internal
641         implementation details, and these should not have the debug hook.
642
643         (JSC::IfElseNode::emitBytecode):
644         (JSC::WhileNode::emitBytecode):
645         (JSC::WithNode::emitBytecode):
646         (JSC::SwitchNode::emitBytecode):
647         Make the pause location consistent at the expression.
648
649         (JSC::DoWhileNode::emitBytecode):
650         Make the pause location consistent at the expression.
651         Remove the errant pause at the do's '}' when entering the do block.
652
653         (JSC::ForNode::emitBytecode):
654         (JSC::ForInNode::emitMultiLoopBytecode):
655         (JSC::ForOfNode::emitBytecode):
656         Make the pause location consistent at expressions.
657         Also allow stepping to the traditional for loop's
658         update expression, which was previously not possible.
659
660         (JSC::ReturnNode::emitBytecode):
661         (JSC::FunctionNode::emitBytecode):
662         Make the pause location when leaving a function consistently be the
663         function's closing brace. The two cases are stepping through a return
664         statement, or the implicit return undefined at the end of a function.
665
666         (JSC::LabelNode::emitBytecode):
667         (JSC::TryNode::emitBytecode):
668         Remove unnecessary pauses that add no value, as they contain a
669         statement and we will then pause at that statement.
670
671         * parser/Nodes.h:
672         (JSC::StatementNode::isFunctionNode):
673         (JSC::StatementNode::isForOfNode):
674         (JSC::EnumerationNode::lexpr):
675         (JSC::ForOfNode::isForOfNode):
676         New virtual methods to distinguish different nodes.
677
678         * debugger/Debugger.h:
679         Rename m_pauseAtNextStatement to m_pauseAtNextOpportunity.
680         This is the finest granularity of stepping, and it can be
681         pausing at a location that is not a statement.
682         Introduce state to properly handle step out and stepping
683         when there are multiple expressions in a statement.
684
685         * debugger/Debugger.cpp:
686         (JSC::Debugger::Debugger):
687         (JSC::Debugger::setPauseOnNextStatement):
688         (JSC::Debugger::breakProgram):
689         (JSC::Debugger::continueProgram):
690         (JSC::Debugger::stepIntoStatement):
691         (JSC::Debugger::exception):
692         (JSC::Debugger::didReachBreakpoint):
693         
694         Use new variable names, and clarify if we should attempt
695         to pause or not.
696
697         (JSC::Debugger::stepOutOfFunction):
698         Set a new state to indicate a step out action.
699
700         (JSC::Debugger::updateCallFrame):
701         (JSC::Debugger::updateCallFrameAndPauseIfNeeded): Deleted.
702         (JSC::Debugger::updateCallFrameInternal):
703         (JSC::Debugger::pauseIfNeeded):
704         Allow updateCallFrame to either attempt a pause or not.
705         
706         (JSC::Debugger::atStatement):
707         Attempt pause and reset the at first expression flag.
708
709         (JSC::Debugger::atExpression):
710         Attempt a pause when not stepping over. Also skip
711         the first expression pause, since that would be
712         equivalent to when we paused for the expression.
713
714         (JSC::Debugger::callEvent):
715         Do not pause when entering a function.
716
717         (JSC::Debugger::returnEvent):
718         Attempt pause when leaving a function.
719         If the user did a step-over and is leaving the
720         function, then behave like step-out.
721         
722         (JSC::Debugger::unwindEvent):
723         Behave like return except don't change any
724         pausing states. If we needed to pause the
725         Debugger::exception will have handled it.
726
727         (JSC::Debugger::willExecuteProgram):
728         Do not pause when entering a program.
729
730         (JSC::Debugger::didExecuteProgram):
731         Attempt pause when leaving a program that has a caller.
732         This can be useful for exiting an eval(...) program.
733         Otherwise treat this like return, and step-over out
734         of the program should behave like step-out. We use
735         pause at next opportunity because there may be extra
736         callframes we do not know about.
737         When the program doesn't have a parent, clear all
738         our state so we don't errantly pause on the next
739         JavaScript microtask that gets executed.
740         
741         (JSC::Debugger::clearNextPauseState):
742         Helper to clear all of the pause states now that
743         it happens in a couple places.
744
745         * interpreter/Interpreter.cpp:
746         (JSC::notifyDebuggerOfUnwinding):
747         Treat unwinding slightly differently from returning.
748         We will not want to pause when unwinding callframes.
749
750         (JSC::Interpreter::debug):
751         * interpreter/Interpreter.h:
752         New debug hook.
753
754         * inspector/agents/InspectorDebuggerAgent.cpp:
755         (Inspector::InspectorDebuggerAgent::stepInto):
756         (Inspector::InspectorDebuggerAgent::didPause):
757         * inspector/agents/InspectorDebuggerAgent.h:
758         Remove unnecessary stepInto code notification for listeners.
759         The listeners are never notified if the debugger resumes,
760         so whatever state they were setting by this is going to
761         get out of date.
762
763 2016-09-30  Saam Barati  <sbarati@apple.com>
764
765         Arrow functions should not allow duplicate parameter names
766         https://bugs.webkit.org/show_bug.cgi?id=162741
767
768         Reviewed by Filip Pizlo.
769
770         This patch makes parsing arrow function parameters throw
771         a syntax error when there are duplicate parameter names.
772         It also starts to make some syntax errors for arrow functions
773         better, however, this is trickier than it seems since we need
774         to choose between two parsing productions when we decide to
775         throw a syntax error. I'm going to work on this problem
776         in another patch specifically devoted to making the error
777         messages better for parsing arrow functions:
778         https://bugs.webkit.org/show_bug.cgi?id=162794
779
780         * parser/Parser.cpp:
781         (JSC::Parser<LexerType>::isArrowFunctionParameters):
782         (JSC::Parser<LexerType>::parseFormalParameters):
783         (JSC::Parser<LexerType>::parseFunctionParameters):
784         (JSC::Parser<LexerType>::parseAssignmentExpression):
785         * parser/Parser.h:
786
787 2016-09-30  Mark Lam  <mark.lam@apple.com>
788
789         Use topVMEntryFrame to determine whether to skip the re-throw of a simulated throw.
790         https://bugs.webkit.org/show_bug.cgi?id=162793
791
792         Reviewed by Saam Barati.
793
794         Change the ThrowScope destructor to use topVMEntryFrame (instead of topCallFrame)
795         in the determination of whether to skip the re-throw of a simulated throw.  This
796         is needed because the topCallFrame is not updated in operationConstructArityCheck()
797         (and does not need to be), whereas topVMEntryFrame is always updated properly.
798         Hence, we should just switch to using the more reliable topVMEntryFrame instead.
799
800         This issue was discovered by existing JSC tests when exception check validation
801         is enabled.
802
803         * runtime/ThrowScope.cpp:
804         (JSC::ThrowScope::~ThrowScope):
805
806 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
807
808         64-bit LLInt needs to have a concurrency-aware barrier
809         https://bugs.webkit.org/show_bug.cgi?id=162790
810
811         Reviewed by Mark Lam.
812
813         In a concurrent GC the barrier definitely has to be after the store, not before it.
814
815         * llint/LowLevelInterpreter64.asm:
816
817 2016-09-29  Filip Pizlo  <fpizlo@apple.com>
818
819         Air should have a way of expressing additional instruction flags
820         https://bugs.webkit.org/show_bug.cgi?id=162699
821
822         Reviewed by Mark Lam.
823         
824         This follows a similar change in B3 (r206595) and replaces Air::Opcode with Air::Kind,
825         which holds onto the opcode and some additional flags. Because Air is an orthogonal ISA
826         (the opcode tells you what the operation does but each operand is allowed to also contain
827         effectively instructions for what to do to read or write that operand), the flags are
828         meant to be orthogonal to opcode. This allows us to say things like Add32<Trap>, which
829         makes sense if any of the operands to the Add32 are addresses.
830         
831         To demonstrate the flags facility this partly adds a trap flag to Air. B3 doesn't use it
832         yet, but I made sure that Air respects it. Basically that means blocking DCE when the flag
833         is set, by making it imply hasNonArgNonControlEffects.
834
835         * CMakeLists.txt:
836         * JavaScriptCore.xcodeproj/project.pbxproj:
837         * b3/B3CheckSpecial.cpp:
838         (JSC::B3::Air::numB3Args):
839         (JSC::B3::CheckSpecial::Key::Key):
840         (JSC::B3::CheckSpecial::Key::dump):
841         (JSC::B3::CheckSpecial::CheckSpecial):
842         (JSC::B3::CheckSpecial::hiddenBranch):
843         (JSC::B3::CheckSpecial::forEachArg):
844         (JSC::B3::CheckSpecial::generate):
845         (JSC::B3::CheckSpecial::dumpImpl):
846         (JSC::B3::CheckSpecial::deepDumpImpl):
847         * b3/B3CheckSpecial.h:
848         (JSC::B3::CheckSpecial::Key::Key):
849         (JSC::B3::CheckSpecial::Key::operator==):
850         (JSC::B3::CheckSpecial::Key::kind):
851         (JSC::B3::CheckSpecial::Key::hash):
852         (JSC::B3::CheckSpecial::Key::opcode): Deleted.
853         * b3/B3Kind.cpp:
854         (JSC::B3::Kind::dump):
855         * b3/air/AirDumpAsJS.cpp:
856         (JSC::B3::Air::dumpAsJS):
857         * b3/air/AirFixObviousSpills.cpp:
858         * b3/air/AirFixPartialRegisterStalls.cpp:
859         * b3/air/AirGenerate.cpp:
860         (JSC::B3::Air::generate):
861         * b3/air/AirHandleCalleeSaves.cpp:
862         (JSC::B3::Air::handleCalleeSaves):
863         * b3/air/AirInst.cpp:
864         (JSC::B3::Air::Inst::jsHash):
865         (JSC::B3::Air::Inst::dump):
866         * b3/air/AirInst.h:
867         (JSC::B3::Air::Inst::Inst):
868         (JSC::B3::Air::Inst::kind):
869         (JSC::B3::Air::Inst::operator bool):
870         (JSC::B3::Air::Inst::opcode): Deleted.
871         * b3/air/AirInstInlines.h:
872         (JSC::B3::Air::Inst::extraClobberedRegs):
873         (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
874         (JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
875         (JSC::B3::Air::Inst::reportUsedRegisters):
876         (JSC::B3::Air::Inst::shouldTryAliasingDef):
877         * b3/air/AirIteratedRegisterCoalescing.cpp:
878         * b3/air/AirKind.cpp: Added.
879         (JSC::B3::Air::Kind::dump):
880         * b3/air/AirKind.h: Added.
881         (JSC::B3::Air::Kind::Kind):
882         (JSC::B3::Air::Kind::operator==):
883         (JSC::B3::Air::Kind::operator!=):
884         (JSC::B3::Air::Kind::hash):
885         (JSC::B3::Air::Kind::operator bool):
886         * b3/air/AirLowerAfterRegAlloc.cpp:
887         (JSC::B3::Air::lowerAfterRegAlloc):
888         * b3/air/AirLowerEntrySwitch.cpp:
889         (JSC::B3::Air::lowerEntrySwitch):
890         * b3/air/AirLowerMacros.cpp:
891         (JSC::B3::Air::lowerMacros):
892         * b3/air/AirOptimizeBlockOrder.cpp:
893         (JSC::B3::Air::optimizeBlockOrder):
894         * b3/air/AirReportUsedRegisters.cpp:
895         (JSC::B3::Air::reportUsedRegisters):
896         * b3/air/AirSimplifyCFG.cpp:
897         (JSC::B3::Air::simplifyCFG):
898         * b3/air/AirTmpWidth.cpp:
899         (JSC::B3::Air::TmpWidth::recompute):
900         * b3/air/AirUseCounts.h:
901         (JSC::B3::Air::UseCounts::UseCounts):
902         * b3/air/AirValidate.cpp:
903         * b3/air/opcode_generator.rb:
904         * b3/testb3.cpp:
905         (JSC::B3::testTernarySubInstructionSelection):
906         (JSC::B3::testBranchBitAndImmFusion):
907
908 2016-09-29  Filip Pizlo  <fpizlo@apple.com>
909
910         REGRESSION(r206555): It made Dromaeo/jslib-style-jquery.html crash
911         https://bugs.webkit.org/show_bug.cgi?id=162721
912
913         Reviewed by Keith Miller.
914         
915         The put_by_id-in-put_by_val optimization had the write barrier in the wrong place and
916         incorrectly filtered on value instead of base.
917         
918         No reduced test case. You really need to run Dromaeo/jslib to catch it. I love Dromaeo's
919         ability to catch GC bugs.
920
921         * jit/JITPropertyAccess.cpp:
922         (JSC::JIT::emitPutByValWithCachedId):
923
924 2016-09-29  Joseph Pecoraro  <pecoraro@apple.com>
925
926         Arrow functions do not infer name from computed property but normal functions do
927         https://bugs.webkit.org/show_bug.cgi?id=162720
928
929         Reviewed by Saam Barati.
930
931         * bytecompiler/BytecodeGenerator.cpp:
932         (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
933         Set function name on arrow functions as well.
934
935 2016-09-29  Joseph Pecoraro  <pecoraro@apple.com>
936
937         test262: class and function names should be inferred in assignment
938         https://bugs.webkit.org/show_bug.cgi?id=146262
939
940         Reviewed by Saam Barati.
941
942         * parser/ASTBuilder.h:
943         (JSC::ASTBuilder::appendParameter):
944         (JSC::ASTBuilder::appendArrayPatternEntry):
945         (JSC::ASTBuilder::appendObjectPatternEntry):
946         (JSC::ASTBuilder::tryInferFunctionNameInPattern):
947         Assign names to default value functions and classes in destructuring.
948
949         (JSC::ASTBuilder::createAssignResolve):
950         (JSC::ASTBuilder::createProperty):
951         (JSC::ASTBuilder::makeAssignNode):
952         Assign names to both normal and arrow functions.
953
954         * parser/Nodes.h:
955         (JSC::ExpressionNode::isBaseFuncExprNode):
956         Both functions and arrow functions infer name, they both extend
957         this base so give the base an is check.
958
959 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
960
961         B3 opcodes should leave room for flags
962         https://bugs.webkit.org/show_bug.cgi?id=162692
963
964         Reviewed by Keith Miller.
965
966         It used to be that the main thing that determined what a Value did was the opcode. The
967         Opcode was how you knew what subclass of Value you had. The opcode told you what the Value
968         actually did. This change replaces Opcode with Kind, which is a tuple of opcode and other
969         stuff.
970         
971         Opcodes are great, and that's how most compilers work. But opcodes are one-dimensional. Here
972         is how this manifests. Say you have an opcode, like Load. You will be happy if your IR has
973         one Load opcode. But then, you might add Load8S/Load8Z/Load16S/Load16Z opcodes, as we have
974         done in B3. B3 has one dimension of Load opcodes, which determines something like the C type
975         of the load. But in the very near future, we will want to add two more dimensions to Loads:
976         
977         - A flag to say if the load traps.
978         - A flag to say if the load has acquire semantics.
979         
980         Mapping these three dimensions (type, trap, acquire) onto the one-dimensional Opcode space
981         would create mayham: Load8S, Load8STrap, Load8SAcquire, Load8STrapAcquire, Load8Z,
982         Load8ZTrap, etc.
983         
984         This happens in other parts of the IR. For example, we have a dimension of arithmetic
985         operations: add, sub, mul, div, mod, etc. Then we have the chill flag. But since opcodes
986         are one-dimensional, that means having ChillDiv and ChillMod, and tons of places in the
987         compiler that case on both Div and ChillDiv, or case on both Mod and ChillMod, since they
988         are only interested in the kind of arithmetic being done and not the chillness.
989         
990         Though the examples all involve bits (chill or not, trapping or not, etc), I can imagine
991         other properties that behave more like small enums, like if we fill out more memory ordering
992         modes other than just "acquire? yes/no". There will eventually have to be something like a
993         std::memory_order associated with memory accesses.
994         
995         One approach to this problem is to have a Value subclass that contains fields with the meta
996         data. I don't like this for two reasons:
997         
998         - In bug 162688, I want to make trapping memory accesses have stackmaps. This means that a
999           trapping memory access would have a different Value subclass than a non-trapping memory
1000           access. So, this meta-data needs to channel into ValueType::accepts(). Currently that
1001           takes Opcode and nothing else.
1002         
1003         - Compiler IRs are all about making common tasks easy. If it becomes commonplace for opcodes
1004           to require a custom Value subclass just for a bit then that's not very easy.
1005         
1006         This change addresses this problem by making the compiler pass around Kinds rather than
1007         Opcodes. A Kind contains an Opcode as well as any number of opcode-specific bits. This
1008         change demonstrates how Kind should be used by converting chillness to it. Kind has
1009         hasIsChill(), isChill(), and setIsChill() methods. hasIsChill() is true only for Div and
1010         Mod. setIsChill() asserts if !hasIsChill(). If you want to create a Chill Div, you say
1011         chill(Div). IR dumps will print it like this:
1012
1013             Int32 @38 = Div<Chill>(@36, @37, DFG:@24, ControlDependent)
1014         
1015         Where "Div<Chill>" is how a Kind that hasExtraBits() dumps itself. If a Kind does not
1016         hasExtraBits() (the normal case) then it dumps like a normal Opcode (without the "<>").
1017         
1018         I replaced many uses of Opcode with Kind. New code has to be mindful that Opcode may not be
1019         the right way to summarize what a value does, and so in many cases it's better to carry
1020         around a Kind instead - especially if you will use it to stamp out new Values. Opcode is no
1021         longer sufficient to perform a dynamic Value cast, since that code now uses Kind. ValueKey
1022         now wants a Kind instead of an Opcode. All Value constructors now take Kind instead of
1023         Opcode. But most opcodes don't get any extra Kind bits, and so the code that operates on
1024         those opcodes is largely unchanged.
1025         
1026         * CMakeLists.txt:
1027         * JavaScriptCore.xcodeproj/project.pbxproj:
1028         * b3/B3ArgumentRegValue.h:
1029         * b3/B3CCallValue.h:
1030         * b3/B3CheckValue.cpp:
1031         (JSC::B3::CheckValue::convertToAdd):
1032         (JSC::B3::CheckValue::CheckValue):
1033         * b3/B3CheckValue.h:
1034         (JSC::B3::CheckValue::accepts):
1035         * b3/B3Const32Value.h:
1036         * b3/B3Const64Value.h:
1037         * b3/B3ConstDoubleValue.h:
1038         * b3/B3ConstFloatValue.h:
1039         * b3/B3FenceValue.h:
1040         * b3/B3Kind.cpp: Added.
1041         (JSC::B3::Kind::dump):
1042         * b3/B3Kind.h: Added.
1043         (JSC::B3::Kind::Kind):
1044         (JSC::B3::Kind::opcode):
1045         (JSC::B3::Kind::setOpcode):
1046         (JSC::B3::Kind::hasExtraBits):
1047         (JSC::B3::Kind::hasIsChill):
1048         (JSC::B3::Kind::isChill):
1049         (JSC::B3::Kind::setIsChill):
1050         (JSC::B3::Kind::operator==):
1051         (JSC::B3::Kind::operator!=):
1052         (JSC::B3::Kind::hash):
1053         (JSC::B3::Kind::isHashTableDeletedValue):
1054         (JSC::B3::chill):
1055         (JSC::B3::KindHash::hash):
1056         (JSC::B3::KindHash::equal):
1057         * b3/B3LowerMacros.cpp:
1058         * b3/B3LowerToAir.cpp:
1059         (JSC::B3::Air::LowerToAir::lower):
1060         * b3/B3MemoryValue.h:
1061         * b3/B3Opcode.cpp:
1062         (WTF::printInternal):
1063         * b3/B3Opcode.h:
1064         * b3/B3PatchpointValue.h:
1065         (JSC::B3::PatchpointValue::accepts):
1066         * b3/B3ReduceStrength.cpp:
1067         * b3/B3SlotBaseValue.h:
1068         * b3/B3StackmapValue.cpp:
1069         (JSC::B3::StackmapValue::StackmapValue):
1070         * b3/B3StackmapValue.h:
1071         * b3/B3SwitchValue.h:
1072         (JSC::B3::SwitchValue::accepts):
1073         * b3/B3UpsilonValue.h:
1074         * b3/B3Validate.cpp:
1075         * b3/B3Value.cpp:
1076         (JSC::B3::Value::dump):
1077         (JSC::B3::Value::deepDump):
1078         (JSC::B3::Value::invertedCompare):
1079         (JSC::B3::Value::effects):
1080         (JSC::B3::Value::key):
1081         (JSC::B3::Value::typeFor):
1082         (JSC::B3::Value::badKind):
1083         (JSC::B3::Value::badOpcode): Deleted.
1084         * b3/B3Value.h:
1085         * b3/B3ValueInlines.h:
1086         (JSC::B3::Value::as):
1087         * b3/B3ValueKey.cpp:
1088         (JSC::B3::ValueKey::dump):
1089         (JSC::B3::ValueKey::materialize):
1090         * b3/B3ValueKey.h:
1091         (JSC::B3::ValueKey::ValueKey):
1092         (JSC::B3::ValueKey::kind):
1093         (JSC::B3::ValueKey::opcode):
1094         (JSC::B3::ValueKey::operator==):
1095         (JSC::B3::ValueKey::hash):
1096         * b3/B3ValueKeyInlines.h:
1097         (JSC::B3::ValueKey::ValueKey):
1098         * b3/B3VariableValue.cpp:
1099         (JSC::B3::VariableValue::VariableValue):
1100         * b3/B3VariableValue.h:
1101         * b3/testb3.cpp:
1102         (JSC::B3::testChillDiv):
1103         (JSC::B3::testChillDivTwice):
1104         (JSC::B3::testChillDiv64):
1105         (JSC::B3::testChillModArg):
1106         (JSC::B3::testChillModArgs):
1107         (JSC::B3::testChillModImms):
1108         (JSC::B3::testChillModArg32):
1109         (JSC::B3::testChillModArgs32):
1110         (JSC::B3::testChillModImms32):
1111         (JSC::B3::testSwitchChillDiv):
1112         (JSC::B3::testEntrySwitchWithCommonPaths):
1113         (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
1114         * ftl/FTLOutput.cpp:
1115         (JSC::FTL::Output::chillDiv):
1116         (JSC::FTL::Output::chillMod):
1117
1118 2016-09-29  Saam Barati  <sbarati@apple.com>
1119
1120         We don't properly propagate non-simple-parameter-list when parsing a setter
1121         https://bugs.webkit.org/show_bug.cgi?id=160483
1122
1123         Reviewed by Joseph Pecoraro.
1124
1125         * parser/Parser.cpp:
1126         (JSC::Parser<LexerType>::parseFunctionParameters):
1127
1128 2016-09-28  Saam Barati  <sbarati@apple.com>
1129
1130         stringProtoFuncRepeatCharacter will return `null` when it should not
1131         https://bugs.webkit.org/show_bug.cgi?id=161944
1132
1133         Reviewed by Yusuke Suzuki.
1134
1135         stringProtoFuncRepeatCharacter was expecting its second argument
1136         to always be a boxed integer. This is not correct. The DFG may decide
1137         to represent a particular value as a double instead of integer. This
1138         function needs to have correct behavior when its second argument is
1139         a boxed double. I also added an assertion stating that the second argument
1140         is always a number. We can guarantee this since it's only called from
1141         builtins.
1142
1143         * runtime/StringPrototype.cpp:
1144         (JSC::stringProtoFuncRepeatCharacter):
1145
1146 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
1147
1148         The write barrier should be down with TSO
1149         https://bugs.webkit.org/show_bug.cgi?id=162316
1150
1151         Reviewed by Geoffrey Garen.
1152         
1153         This makes our write barrier behave correctly when it races with the collector. The
1154         collector wants to do this when visiting:
1155         
1156             object->cellState = black
1157             visit(object)
1158         
1159         The mutator wants to do this when storing:
1160         
1161             object->property = newValue
1162             if (object->cellState == black)
1163                 remember(object)
1164         
1165         Prior to this change, this didn't work right because the compiler would sometimes place
1166         barriers before the store to the property and because the mutator did not have adequate
1167         fences.
1168         
1169         Prior to this change, the DFG and FTL would emit this:
1170         
1171             if (object->cellState == black)
1172                 remember(object)
1173             object->property = newValue
1174         
1175         Which is wrong, because the object could start being scanned just after the cellState
1176         check, at which point the store would be lost. We need to confirm that the state was not
1177         black *after* the store! This change was harder than you'd expect: placing the barrier
1178         after the store broke B3's ability to do its super crazy ninja CSE on some store-load
1179         redundancies. Because the B3 CSE has some moves that the DFG CSE lacks, the DFG CSE's
1180         ability to ignore barriers didn't help. I fixed this by having the FTL convey precise
1181         heap ranges for the patchpoint corresponding to the barrier slow path. It reads the world
1182         (because of the store-load fence) and it writes only cellState (because the B3 heap ranges
1183         don't have any way to represent any of the GC's other state, which means that B3 does not
1184         have to worry about aliasing with any of that).
1185         
1186         The collector already uses a store-load fence on x86 just after setting the cellState and
1187         before visiting the object. The mutator needs to do the same. But we cannot put a
1188         store-load fence of any kind before store barriers, because that causes enormous slow
1189         downs. In the worst case, Octane/richards slowed down by 90%! That's crazy! However, the
1190         overall slow downs were small enough (0-15% on benchmark suite aggregates) that it would be
1191         reasonable if the slow down only happened while the GC was running. Then, the concurrent GC
1192         would lift throughput-while-collecting from 0% of peak to 85% of peak. This changes the
1193         barrier so that it looks like this:
1194         
1195             if (object->cellState <= heap.sneakyBlackThreshold)
1196                 slowPath(object)
1197         
1198         Where sneakyBlackThreshold is the normal blackThreshold when we're not collecting, or a
1199         tautoligical threshold (that makes everything look black) when we are collecting. This
1200         turns out to not be any more expensive than the barrier in tip of tree when the GC is not
1201         running, or a 0-15% slow-down when it is "running". (Of course we don't run the GC
1202         concurrently yet. I still have more work to do.) The slowPath() does some extra work to
1203         check if we are concurrently collecting; if so, it does a fence and rechecks if the object
1204         really did need that barrier.
1205         
1206         This also reintroduces elimination of redundant store barriers, which was lost in the last
1207         store barrier change. We can only do it when there is no possibility of GC, exit, or
1208         exceptions between the two store barriers. We could remove the exit/exception limitation if
1209         we taught OSR exit how to buffer store barriers, which is an insane thing to do considering
1210         that I've never been able to detect a win from redundant store barrier elimination. I just
1211         want us to have it for stupidly obvious situations, like a tight sequence of stores to the
1212         same object. This same optimization also sometimes strength-reduces the store barrier so
1213         that it uses a constant black threshold rather than the sneaky one, thereby saving one
1214         load.
1215         
1216         Even with all of those optimizations, I still had problems with barrier cost. I found that one
1217         of the benchmarks that was being hit particularly hard was JetStream/regexp-2010. Fortunately
1218         that benchmark does most of its barriers in a tight C++ loop in RegExpMatchesArray.h. When we
1219         know what we're doing, we can defer GC around a bunch of object initializations and then remove
1220         all of the barriers between any of the objects allocated within the deferral. Unfortunately,
1221         our GC deferral mechanism isn't really performant enough to make this be a worthwhile
1222         optimization. The most efficient version of such an optimization that I could come up with was
1223         to have a DeferralContext object that houses a boolean that is false by default, but the GC
1224         writes true into it if it would have wanted to GC. You thread a pointer to the deferralContext
1225         through all of your allocations. This kind of mechanism has the overhead of a zero 
1226         initialization on the stack on entry and a zero check on exit. This is probably even efficient
1227         enough that we could start thinking about having the DFG use it, for example if we found a
1228         bounded-time section of code with a lot of barriers and entry/exit sites that aren't totally
1229         wacky. This optimization took this patch from 0.68% JetStream regressed to neutral, according
1230         to my latest data.
1231         
1232         Finally, an earlier version of this change put the store-load fence in B3 IR, so I ended up
1233         adding FTLOutput support for it and AbstractHeapRepository magic for decorating the heaps.
1234         I think we might as well keep that, it'll be useful.
1235
1236         * CMakeLists.txt:
1237         * JavaScriptCore.xcodeproj/project.pbxproj:
1238         * assembler/MacroAssembler.h:
1239         (JSC::MacroAssembler::branch32):
1240         * assembler/MacroAssemblerX86_64.h:
1241         (JSC::MacroAssemblerX86_64::branch32):
1242         (JSC::MacroAssemblerX86_64::branch64): Deleted.
1243         * bytecode/PolymorphicAccess.cpp:
1244         (JSC::AccessCase::generateImpl):
1245         * dfg/DFGAbstractHeap.h:
1246         * dfg/DFGAbstractInterpreterInlines.h:
1247         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1248         * dfg/DFGClobberize.h:
1249         (JSC::DFG::clobberize):
1250         * dfg/DFGClobbersExitState.cpp:
1251         (JSC::DFG::clobbersExitState):
1252         * dfg/DFGDoesGC.cpp:
1253         (JSC::DFG::doesGC):
1254         * dfg/DFGFixupPhase.cpp:
1255         (JSC::DFG::FixupPhase::fixupNode):
1256         * dfg/DFGMayExit.cpp:
1257         * dfg/DFGNode.h:
1258         (JSC::DFG::Node::isStoreBarrier):
1259         * dfg/DFGNodeType.h:
1260         * dfg/DFGPlan.cpp:
1261         (JSC::DFG::Plan::compileInThreadImpl):
1262         * dfg/DFGPredictionPropagationPhase.cpp:
1263         * dfg/DFGSafeToExecute.h:
1264         (JSC::DFG::safeToExecute):
1265         * dfg/DFGSpeculativeJIT.cpp:
1266         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1267         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
1268         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
1269         * dfg/DFGSpeculativeJIT.h:
1270         * dfg/DFGSpeculativeJIT32_64.cpp:
1271         (JSC::DFG::SpeculativeJIT::compile):
1272         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
1273         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
1274         * dfg/DFGSpeculativeJIT64.cpp:
1275         (JSC::DFG::SpeculativeJIT::compile):
1276         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
1277         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
1278         * dfg/DFGStoreBarrierClusteringPhase.cpp: Added.
1279         (JSC::DFG::performStoreBarrierClustering):
1280         * dfg/DFGStoreBarrierClusteringPhase.h: Added.
1281         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1282         * dfg/DFGStoreBarrierInsertionPhase.h:
1283         * ftl/FTLAbstractHeap.h:
1284         (JSC::FTL::AbsoluteAbstractHeap::at):
1285         (JSC::FTL::AbsoluteAbstractHeap::operator[]):
1286         * ftl/FTLAbstractHeapRepository.cpp:
1287         (JSC::FTL::AbstractHeapRepository::decorateFenceRead):
1288         (JSC::FTL::AbstractHeapRepository::decorateFenceWrite):
1289         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
1290         * ftl/FTLAbstractHeapRepository.h:
1291         * ftl/FTLCapabilities.cpp:
1292         (JSC::FTL::canCompile):
1293         * ftl/FTLLowerDFGToB3.cpp:
1294         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1295         (JSC::FTL::DFG::LowerDFGToB3::compileStoreBarrier):
1296         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
1297         (JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
1298         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
1299         * ftl/FTLOutput.cpp:
1300         (JSC::FTL::Output::fence):
1301         (JSC::FTL::Output::absolute):
1302         * ftl/FTLOutput.h:
1303         * heap/CellState.h:
1304         (JSC::isWithinThreshold):
1305         (JSC::isBlack):
1306         * heap/Heap.cpp:
1307         (JSC::Heap::writeBarrierSlowPath):
1308         * heap/Heap.h:
1309         (JSC::Heap::barrierShouldBeFenced):
1310         (JSC::Heap::addressOfBarrierShouldBeFenced):
1311         (JSC::Heap::sneakyBlackThreshold):
1312         (JSC::Heap::addressOfSneakyBlackThreshold):
1313         * heap/HeapInlines.h:
1314         (JSC::Heap::writeBarrier):
1315         (JSC::Heap::writeBarrierWithoutFence):
1316         * jit/AssemblyHelpers.h:
1317         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEdenWithoutFence):
1318         (JSC::AssemblyHelpers::sneakyJumpIfIsRememberedOrInEden):
1319         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
1320         (JSC::AssemblyHelpers::storeBarrierStoreLoadFence):
1321         (JSC::AssemblyHelpers::jumpIfStoreBarrierStoreLoadFenceNotNeeded):
1322         * jit/JITOperations.cpp:
1323         * jit/JITOperations.h:
1324         * jit/JITPropertyAccess.cpp:
1325         (JSC::JIT::emit_op_put_by_id):
1326         (JSC::JIT::emitWriteBarrier):
1327         (JSC::JIT::privateCompilePutByVal):
1328         * jit/JITPropertyAccess32_64.cpp:
1329         (JSC::JIT::emit_op_put_by_id):
1330         * llint/LowLevelInterpreter.asm:
1331         * offlineasm/x86.rb:
1332         * runtime/Options.h:
1333
1334 2016-09-27  Joseph Pecoraro  <pecoraro@apple.com>
1335
1336         Improve useCodeCache Option description string.
1337
1338         * runtime/Options.h:
1339         Address late review comments and clarify description.
1340
1341 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
1342
1343         Optimize B3->Air lowering of Fence on ARM
1344         https://bugs.webkit.org/show_bug.cgi?id=162342
1345
1346         Reviewed by Geoffrey Garen.
1347
1348         This gives us comprehensive support for standalone fences on x86 and ARM. The changes are as
1349         follows:
1350
1351         - Sets in stone the rule that the heaps of a B3::Fence tell you what the fence protects. If the
1352           fence reads, it protects motion of stores. If the fence writes, it protects motion of loads.
1353           This allows us to express for example load-load fences in a portable way: on x86 they will just
1354           block B3 optimizations and emit no code, while on ARM you will get some fence.
1355
1356         - Adds comprehensive support for WTF-style fences in the ARM assembler. I simplified it just a bit
1357           to match what B3, the main client, knows. There are three fences: MemoryFence, StoreFence, and
1358           LoadFence. On x86, MemoryFence is ortop while StoreFence and LoadFence emit no code. On ARM64,
1359           MemoryFence and LoadFence are dmb ish while StoreFence is dmb ishst.
1360
1361         - Tests! To test this, I needed to teach the disassembler how to disassemble dmb ish and dmb
1362           ishst. I think that the canonical way to do it would be to create a group for dmb and then teach
1363           that group how to decode the operands. But I don't actually know what are all of the ways of
1364           encoding dmb, so I'd rather that unrecognized encodings fall through to the ".long blah"
1365           bailout. So, this creates explicit matching rules for "dmb ish" and "dmb ishst", which is the
1366           most conservative thing we can do.
1367
1368         * assembler/ARM64Assembler.h:
1369         (JSC::ARM64Assembler::dmbISH):
1370         (JSC::ARM64Assembler::dmbISHST):
1371         (JSC::ARM64Assembler::dmbSY): Deleted.
1372         * assembler/MacroAssemblerARM64.h:
1373         (JSC::MacroAssemblerARM64::memoryFence):
1374         (JSC::MacroAssemblerARM64::storeFence):
1375         (JSC::MacroAssemblerARM64::loadFence):
1376         * assembler/MacroAssemblerX86Common.h:
1377         (JSC::MacroAssemblerX86Common::storeFence):
1378         (JSC::MacroAssemblerX86Common::loadFence):
1379         * b3/B3FenceValue.h:
1380         * b3/B3LowerToAir.cpp:
1381         (JSC::B3::Air::LowerToAir::lower):
1382         * b3/air/AirOpcode.opcodes:
1383         * b3/testb3.cpp:
1384         (JSC::B3::testMemoryFence):
1385         (JSC::B3::testStoreFence):
1386         (JSC::B3::testLoadFence):
1387         (JSC::B3::run):
1388         (JSC::B3::testX86MFence): Deleted.
1389         (JSC::B3::testX86CompilerFence): Deleted.
1390         * disassembler/ARM64/A64DOpcode.cpp:
1391         (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format):
1392         (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format):
1393         * disassembler/ARM64/A64DOpcode.h:
1394         (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName):
1395         (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName):
1396
1397 2016-09-28  Joseph Pecoraro  <pecoraro@apple.com>
1398
1399         Adopt #pragma once in some generated resources
1400         https://bugs.webkit.org/show_bug.cgi?id=162666
1401
1402         Reviewed by Alex Christensen.
1403
1404         * Scripts/builtins/builtins_generate_combined_header.py:
1405         * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
1406         * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
1407         * Scripts/builtins/builtins_generate_separate_header.py:
1408         * Scripts/builtins/builtins_generate_wrapper_header.py:
1409         * Scripts/builtins/builtins_generate_wrapper_implementation.py:
1410         Remove headerGuard attribute unused by templates.
1411
1412         * Scripts/tests/builtins/expected/JavaScriptCore-Operations.Promise-Combined.js-result: Removed.
1413         No such test exists. It was likely renamed.
1414
1415         * generate-bytecode-files:
1416         Simplify header guard output.
1417
1418         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
1419         (ObjCBackendDispatcherHeaderGenerator.generate_output):
1420         * replay/scripts/CodeGeneratorReplayInputs.py:
1421         (Generator.generate_header):
1422         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
1423         Simplify header guard output.
1424
1425         * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
1426         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
1427         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
1428         * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
1429         * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
1430         * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
1431         * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
1432         * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
1433         Rebaseline.
1434
1435 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
1436
1437         Store-load fences should be a lot cheaper on ARM
1438         https://bugs.webkit.org/show_bug.cgi?id=162461
1439
1440         Rubber stamped by Keith Miller.
1441
1442         It turns out that they are already cheap enough, so this change just make us use them.
1443
1444         * heap/SlotVisitor.cpp:
1445         (JSC::SlotVisitor::visitChildren):
1446
1447 2016-09-28  Ryan Haddad  <ryanhaddad@apple.com>
1448
1449         Unreviewed, rolling out r206522.
1450
1451         Roll r206506 back in since the build fix landed in r206521
1452
1453         Reverted changeset:
1454
1455         "Unreviewed, rolling out r206506."
1456         https://bugs.webkit.org/show_bug.cgi?id=162682
1457         http://trac.webkit.org/changeset/206522
1458
1459 2016-09-28  Commit Queue  <commit-queue@webkit.org>
1460
1461         Unreviewed, rolling out r206506.
1462         https://bugs.webkit.org/show_bug.cgi?id=162682
1463
1464         Broke the Windows and WinCairo builds. (Requested by
1465         ryanhaddad on #webkit).
1466
1467         Reverted changeset:
1468
1469         "Adopt #pragma once in JavaScriptCore"
1470         https://bugs.webkit.org/show_bug.cgi?id=162664
1471         http://trac.webkit.org/changeset/206506
1472
1473 2016-09-28  Joseph Pecoraro  <pecoraro@apple.com>
1474
1475         Adopt #pragma once in JavaScriptCore
1476         https://bugs.webkit.org/show_bug.cgi?id=162664
1477
1478         Reviewed by Saam Barati.
1479
1480         * **/**.h:
1481         Adopt pragma once in all but API headers and generated headers.
1482         Include some namespace closing comments for consistency.
1483
1484 2016-09-27  JF Bastien  <jfbastien@apple.com>
1485
1486         Missing Atomics.h include in MarkedBlock.h
1487         https://bugs.webkit.org/show_bug.cgi?id=162648
1488
1489         Missing include from my previous patch.
1490
1491         Reviewed by Yusuke Suzuki.
1492
1493         * heap/MarkedBlock.h:
1494
1495 2016-09-27  Mark Lam  <mark.lam@apple.com>
1496
1497         createError() and JSObject::calculatedClassName() should not throw any exceptions.
1498         https://bugs.webkit.org/show_bug.cgi?id=162637
1499
1500         Reviewed by Geoffrey Garen.
1501
1502         * runtime/ExceptionHelpers.cpp:
1503         (JSC::createError):
1504         - assert that errorDescriptionForValue() did not throw an exception.
1505
1506         * runtime/JSObject.cpp:
1507         (JSC::JSObject::calculatedClassName):
1508         - the code already ensures that we always return a non-null String.  Just need to
1509           make sure that it catches its own exceptions.
1510
1511 2016-09-27  Filip Pizlo  <fpizlo@apple.com>
1512
1513         B3::lowerMacros forgets to before->updatePredecessorsAfter() when lowering ChillMod on ARM64
1514         https://bugs.webkit.org/show_bug.cgi?id=162644
1515
1516         Reviewed by Keith Miller.
1517
1518         If you forget to update the predecessors of your successors, then bad things will happen if you
1519         do something that requires accurate predecessors for correctness. lowerMacros() uses
1520         BlockInsertionSet, which relies on accurate predecessors.
1521
1522         * b3/B3LowerMacros.cpp:
1523
1524 2016-09-27  JF Bastien  <jfbastien@apple.com>
1525
1526         Speed up Heap::isMarkedConcurrently
1527         https://bugs.webkit.org/show_bug.cgi?id=162095
1528
1529         Reviewed by Filip Pizlo.
1530
1531         Speed up isMarkedConcurrently by using WTF::consumeLoad.
1532
1533         * heap/MarkedBlock.h:
1534         (JSC::MarkedBlock::areMarksStale):
1535         (JSC::MarkedBlock::areMarksStaleWithDependency):
1536         (JSC::MarkedBlock::isMarkedConcurrently): do away with the load-load fence
1537
1538 2016-09-27  Mark Lam  <mark.lam@apple.com>
1539
1540         Add some needed CatchScopes in code that should not throw.
1541         https://bugs.webkit.org/show_bug.cgi?id=162584
1542
1543         Reviewed by Keith Miller.
1544
1545         Re-landing minus the jsc.cpp and ExceptionHelpers.cpp changes.  I'll address
1546         those in a subsequent patch if the need manifests again in my testing.
1547
1548         * API/JSObjectRef.cpp:
1549         (JSObjectSetProperty):
1550         - This function already handles exceptions in its own way.  We're honoring this
1551           contract and catching exceptions and passing it to the handler.
1552
1553         * interpreter/Interpreter.cpp:
1554         (JSC::notifyDebuggerOfUnwinding):
1555         - The debugger should not be throwing any exceptions.
1556
1557         * profiler/ProfilerDatabase.cpp:
1558         (JSC::Profiler::Database::save):
1559         - If an exception was thrown while saving the database, there's nothing we can
1560           really do about it anyway.  Just fail nicely and return false.  This is in line
1561           with existing error checking code in Database::save() that returns false if
1562           it's not able to open the file to save to.
1563
1564         * runtime/JSModuleLoader.cpp:
1565         (JSC::JSModuleLoader::finishCreation):
1566         - The existing code already RELEASE_ASSERT that no exception was thrown.
1567           Hence, it's appropriate to use a CatchScope here.
1568
1569         * runtime/SamplingProfiler.cpp:
1570         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
1571         - The sampling profiler is doing a VMInquiry get here.  It should never throw an
1572           exception.  Hence, we'll just use a CatchScope and assert accordingly.
1573
1574 2016-09-27  Jer Noble  <jer.noble@apple.com>
1575
1576         Remove deprecated ENCRYPTED_MEDIA implementation.
1577         https://bugs.webkit.org/show_bug.cgi?id=161010
1578
1579         Reviewed by Eric Carlson.
1580
1581         Remove ENABLE_ENCRYPTED_MEDIA.
1582
1583         * Configurations/FeatureDefines.xcconfig:
1584
1585 2016-09-27  Michael Catanzaro  <mcatanzaro@igalia.com>
1586
1587         [GTK] Install binaries to pkglibexecdir rather than bindir
1588         https://bugs.webkit.org/show_bug.cgi?id=162602
1589
1590         Reviewed by Carlos Garcia Campos.
1591
1592         Install jsc shell to LIBEXEC_INSTALL_DIR rather than EXEC_INSTALL_DIR.
1593
1594         Note these locations are the same on non-GTK ports.
1595
1596         * shell/CMakeLists.txt:
1597
1598 2016-09-26  Sam Weinig  <sam@webkit.org>
1599
1600         Make DFGSlowPathGenerator a bit more variadic
1601         https://bugs.webkit.org/show_bug.cgi?id=162378
1602
1603         Reviewed by Filip Pizlo.
1604
1605         Make the subclass of CallSlowPathGenerator that takes arguments variadic
1606         so it can take any number of arguments. Also updates the slowPathCall helper
1607         function to be variadic. I had to move the spill mode and exception check 
1608         requirement parameters to before the arguments since the variadic arguments
1609         must be at the end. As a convenience, I added an overload of slowPathCall that
1610         doesn't take spill mode and exception check requirement parameters.
1611
1612         * dfg/DFGSlowPathGenerator.h:
1613         (JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator):
1614         (JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate):
1615         (JSC::DFG::slowPathCall):
1616         (JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator): Deleted.
1617         (JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator): Deleted.
1618         (JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator): Deleted.
1619         (JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator): Deleted.
1620         (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator): Deleted.
1621         (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal): Deleted.
1622         (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator): Deleted.
1623         (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal): Deleted.
1624         * dfg/DFGSpeculativeJIT.cpp:
1625         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1626         (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
1627         * dfg/DFGSpeculativeJIT64.cpp:
1628         (JSC::DFG::SpeculativeJIT::cachedGetById):
1629
1630 2016-09-26  Commit Queue  <commit-queue@webkit.org>
1631
1632         Unreviewed, rolling out r206405.
1633         https://bugs.webkit.org/show_bug.cgi?id=162588
1634
1635         This change caused LayoutTest crashes. (Requested by
1636         ryanhaddad on #webkit).
1637
1638         Reverted changeset:
1639
1640         "Add some needed CatchScopes in code that should not throw."
1641         https://bugs.webkit.org/show_bug.cgi?id=162584
1642         http://trac.webkit.org/changeset/206405
1643
1644 2016-09-26  Mark Lam  <mark.lam@apple.com>
1645
1646         Add some needed CatchScopes in code that should not throw.
1647         https://bugs.webkit.org/show_bug.cgi?id=162584
1648
1649         Reviewed by Keith Miller.
1650
1651         * API/JSObjectRef.cpp:
1652         (JSObjectSetProperty):
1653         - This function already handles exceptions in its own way.  We're honoring this
1654           contract and catching exceptions and passing it to the handler.
1655
1656         * interpreter/Interpreter.cpp:
1657         (JSC::notifyDebuggerOfUnwinding):
1658         - The debugger should not be throwing any exceptions.
1659
1660         * jsc.cpp:
1661         (runJSC):
1662         - the buck stops here.  There's no reason an exception should propagate past here.
1663
1664         * profiler/ProfilerDatabase.cpp:
1665         (JSC::Profiler::Database::save):
1666         - If an exception was thrown while saving the database, there's nothing we can
1667           really do about it anyway.  Just fail nicely and return false.  This is in line
1668           with existing error checking code in Database::save() that returns false if
1669           it's not able to open the file to save to.
1670
1671         * runtime/ExceptionHelpers.cpp:
1672         (JSC::createError):
1673         - If we're not able to stringify the error value, then we'll just use the
1674           provided message as the error string.  It doesn't make sense to have the
1675           Error factory throw an exception that shadows the intended exception that the
1676           client probably wants to throw (assuming that that's why the client is creating
1677           this Error object).
1678
1679         * runtime/JSModuleLoader.cpp:
1680         (JSC::JSModuleLoader::finishCreation):
1681         - The existing code already RELEASE_ASSERT that no exception was thrown.
1682           Hence, it's appropriate to use a CatchScope here.
1683
1684         * runtime/SamplingProfiler.cpp:
1685         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
1686         - The sampling profiler is doing a VMInquiry get here.  It should never throw an
1687           exception.  Hence, we'll just use a CatchScope and assert accordingly.
1688
1689 2016-09-26  Mark Lam  <mark.lam@apple.com>
1690
1691         Exception unwinding code should use a CatchScope instead of a ThrowScope.
1692         https://bugs.webkit.org/show_bug.cgi?id=162583
1693
1694         Reviewed by Geoffrey Garen.
1695
1696         This is because the exception unwinding code does not throw an exception.
1697         It only inspects the thrown exception and passes it to the appropriate handler.
1698
1699         * interpreter/Interpreter.cpp:
1700         (JSC::Interpreter::unwind):
1701         * jit/JITExceptions.cpp:
1702         (JSC::genericUnwind):
1703
1704 2016-09-26  Joseph Pecoraro  <pecoraro@apple.com>
1705
1706         Add an Option to disable the CodeCache
1707         https://bugs.webkit.org/show_bug.cgi?id=162579
1708
1709         Reviewed by Geoffrey Garen.
1710
1711         * runtime/CodeCache.cpp:
1712         (JSC::CodeCache::getGlobalCodeBlock):
1713         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1714         Do not use the cache if the Option is disabled.
1715
1716         * runtime/Options.h:
1717         New option to not use the code cache.
1718
1719 2016-09-26  Daniel Bates  <dabates@apple.com>
1720
1721         Rename IOS_TEXT_AUTOSIZING to TEXT_AUTOSIZING
1722         https://bugs.webkit.org/show_bug.cgi?id=162365
1723
1724         Reviewed by Simon Fraser.
1725
1726         * Configurations/FeatureDefines.xcconfig:
1727
1728 2016-09-26  Benjamin Poulain  <benjamin@webkit.org>
1729
1730         [JSC] Shrink the Math inline caches some more
1731         https://bugs.webkit.org/show_bug.cgi?id=162485
1732
1733         Reviewed by Saam Barati.
1734
1735         This patch applies some lessons learnt from op_negate
1736         to shrink the generated asm of the previous 3 inline
1737         caches.
1738
1739         In order of importance:
1740         -We do not need to pass the pointer to ArithProfile
1741          on the slow path. We can just get the profile out
1742          of the Math IC.
1743          This saves us from materializing a 64bits value
1744          in a register before the call on the slow path.
1745         -We can remove a bunch of mov by setting up the registers
1746          in the way the slow path needs them.
1747          The slow path makes a function calls with the input
1748          as second and third arguments, and return the result in
1749          the "return register". By using those as target when
1750          loading/storing from the stack, we remove 3 mov per slow path.
1751         -When performing integer add, we can set the result directly in
1752          the output register if that does not trashes one of the input
1753          register. This removes one mov per integer add.
1754
1755         The inline cache average sizes on Sunspider change as follow:
1756         -Adds: 147.573099->131.555556 (~10%)
1757         -Muls: 186.882353->170.991597 (~8%)
1758         -Subs: 139.127907->121.523256 (~12%)
1759
1760         * jit/JIT.h:
1761         * jit/JITAddGenerator.cpp:
1762         (JSC::JITAddGenerator::generateInline):
1763         (JSC::JITAddGenerator::generateFastPath):
1764         * jit/JITArithmetic.cpp:
1765         (JSC::JIT::emitMathICFast):
1766         (JSC::JIT::emitMathICSlow):
1767         * jit/JITInlines.h:
1768         (JSC::JIT::callOperation): Deleted.
1769         * jit/JITOperations.cpp:
1770         * jit/JITOperations.h:
1771
1772 2016-09-26  Mark Lam  <mark.lam@apple.com>
1773
1774         Added RETURN_IF_EXCEPTION() macro and use it for exception checks.
1775         https://bugs.webkit.org/show_bug.cgi?id=162521
1776
1777         Reviewed by Saam Barati.
1778
1779         Also, where possible, if the return type is JSValue, changed the returned value
1780         (on exception) to the empty JSValue (instead of sometimes jsUndefined, jsNull,
1781         or the thrown exception value).
1782
1783         There are a few places where I had to continue to return the previously returned
1784         value (instead of the empty JSValue) in order for tests to pass.  This is needed
1785         because there are missing exception checks that will need to be added before I
1786         can change those to return the empty JSValue too.  Identifying all the places
1787         where those checks need to be added is beyond the scope of this patch.  I will
1788         work on adding missing exception checks in a subsequent patch.
1789
1790         In this patch, there is one missing exception check in replaceUsingRegExpSearch()
1791         that was easily identified, and is necessary so that Interpreter::execute()
1792         functions can return JSValue.  I've added this missing check.
1793
1794         This patch has passed the JSC and layout tests.
1795
1796         * dfg/DFGOperations.cpp:
1797         (JSC::DFG::operationPutByValInternal):
1798         * inspector/JSInjectedScriptHost.cpp:
1799         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
1800         (Inspector::JSInjectedScriptHost::getInternalProperties):
1801         (Inspector::JSInjectedScriptHost::weakMapEntries):
1802         (Inspector::JSInjectedScriptHost::weakSetEntries):
1803         (Inspector::JSInjectedScriptHost::iteratorEntries):
1804         * inspector/JSJavaScriptCallFrame.cpp:
1805         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
1806         * interpreter/Interpreter.cpp:
1807         (JSC::eval):
1808         (JSC::sizeOfVarargs):
1809         (JSC::Interpreter::execute):
1810         (JSC::Interpreter::executeCall):
1811         (JSC::Interpreter::executeConstruct):
1812         * interpreter/ShadowChicken.cpp:
1813         (JSC::ShadowChicken::functionsOnStack):
1814         * jit/JITOperations.cpp:
1815         (JSC::getByVal):
1816         * jsc.cpp:
1817         (WTF::ImpureGetter::getOwnPropertySlot):
1818         (functionRun):
1819         (functionRunString):
1820         (functionLoad):
1821         (functionLoadString):
1822         (functionReadFile):
1823         (functionCheckSyntax):
1824         (functionSetRandomSeed):
1825         (functionLoadModule):
1826         (functionCreateBuiltin):
1827         (functionCheckModuleSyntax):
1828         * llint/LLIntSlowPaths.cpp:
1829         (JSC::LLInt::getByVal):
1830         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1831         * profiler/ProfilerBytecodeSequence.cpp:
1832         (JSC::Profiler::BytecodeSequence::addSequenceProperties):
1833         * profiler/ProfilerCompilation.cpp:
1834         (JSC::Profiler::Compilation::toJS):
1835         * profiler/ProfilerDatabase.cpp:
1836         (JSC::Profiler::Database::toJS):
1837         * profiler/ProfilerOSRExitSite.cpp:
1838         (JSC::Profiler::OSRExitSite::toJS):
1839         * profiler/ProfilerOriginStack.cpp:
1840         (JSC::Profiler::OriginStack::toJS):
1841         * runtime/ArrayPrototype.cpp:
1842         (JSC::speciesConstructArray):
1843         (JSC::shift):
1844         (JSC::unshift):
1845         (JSC::arrayProtoFuncToString):
1846         (JSC::arrayProtoFuncToLocaleString):
1847         (JSC::slowJoin):
1848         (JSC::fastJoin):
1849         (JSC::arrayProtoFuncJoin):
1850         (JSC::arrayProtoFuncPop):
1851         (JSC::arrayProtoFuncPush):
1852         (JSC::arrayProtoFuncReverse):
1853         (JSC::arrayProtoFuncShift):
1854         (JSC::arrayProtoFuncSlice):
1855         (JSC::arrayProtoFuncSplice):
1856         (JSC::arrayProtoFuncUnShift):
1857         (JSC::arrayProtoFuncIndexOf):
1858         (JSC::arrayProtoFuncLastIndexOf):
1859         (JSC::moveElements):
1860         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1861         * runtime/BooleanConstructor.cpp:
1862         (JSC::constructWithBooleanConstructor):
1863         * runtime/CommonSlowPaths.h:
1864         (JSC::CommonSlowPaths::opIn):
1865         * runtime/Completion.cpp:
1866         (JSC::loadAndEvaluateModule):
1867         (JSC::loadModule):
1868         * runtime/ConsoleObject.cpp:
1869         (JSC::consoleProtoFuncAssert):
1870         (JSC::consoleProtoFuncProfile):
1871         (JSC::consoleProtoFuncProfileEnd):
1872         (JSC::consoleProtoFuncTakeHeapSnapshot):
1873         (JSC::consoleProtoFuncTime):
1874         (JSC::consoleProtoFuncTimeEnd):
1875         * runtime/DateConstructor.cpp:
1876         (JSC::constructDate):
1877         (JSC::dateParse):
1878         * runtime/DatePrototype.cpp:
1879         (JSC::dateProtoFuncToPrimitiveSymbol):
1880         (JSC::dateProtoFuncToJSON):
1881         * runtime/ErrorConstructor.cpp:
1882         (JSC::Interpreter::constructWithErrorConstructor):
1883         * runtime/ErrorInstance.cpp:
1884         (JSC::ErrorInstance::sanitizedToString):
1885         * runtime/ErrorPrototype.cpp:
1886         (JSC::errorProtoFuncToString):
1887         * runtime/ExceptionScope.h:
1888         * runtime/FunctionConstructor.cpp:
1889         (JSC::constructFunctionSkippingEvalEnabledCheck):
1890         * runtime/GenericArgumentsInlines.h:
1891         (JSC::GenericArguments<Type>::copyToArguments):
1892         * runtime/GetterSetter.cpp:
1893         (JSC::callGetter):
1894         * runtime/HashMapImpl.h:
1895         (JSC::jsMapHash):
1896         (JSC::HashMapImpl::finishCreation):
1897         (JSC::HashMapImpl::findBucket):
1898         (JSC::HashMapImpl::add):
1899         (JSC::HashMapImpl::rehash):
1900         * runtime/InspectorInstrumentationObject.cpp:
1901         (JSC::inspectorInstrumentationObjectLog):
1902         * runtime/InternalFunction.cpp:
1903         (JSC::InternalFunction::createSubclassStructure):
1904         * runtime/IntlCollator.cpp:
1905         (JSC::IntlCollator::initializeCollator):
1906         * runtime/IntlCollatorConstructor.cpp:
1907         (JSC::constructIntlCollator):
1908         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
1909         * runtime/IntlCollatorPrototype.cpp:
1910         (JSC::IntlCollatorFuncCompare):
1911         (JSC::IntlCollatorPrototypeGetterCompare):
1912         * runtime/IntlDateTimeFormat.cpp:
1913         (JSC::toDateTimeOptionsAnyDate):
1914         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
1915         * runtime/IntlDateTimeFormatConstructor.cpp:
1916         (JSC::constructIntlDateTimeFormat):
1917         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
1918         * runtime/IntlDateTimeFormatPrototype.cpp:
1919         (JSC::IntlDateTimeFormatFuncFormatDateTime):
1920         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1921         * runtime/IntlNumberFormat.cpp:
1922         (JSC::IntlNumberFormat::initializeNumberFormat):
1923         * runtime/IntlNumberFormatConstructor.cpp:
1924         (JSC::constructIntlNumberFormat):
1925         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
1926         * runtime/IntlNumberFormatPrototype.cpp:
1927         (JSC::IntlNumberFormatFuncFormatNumber):
1928         (JSC::IntlNumberFormatPrototypeGetterFormat):
1929         * runtime/IntlObject.cpp:
1930         (JSC::intlBooleanOption):
1931         (JSC::intlStringOption):
1932         (JSC::intlNumberOption):
1933         (JSC::canonicalizeLocaleList):
1934         (JSC::supportedLocales):
1935         * runtime/IntlObjectInlines.h:
1936         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
1937         * runtime/IteratorOperations.cpp:
1938         (JSC::iteratorNext):
1939         (JSC::iteratorStep):
1940         (JSC::iteratorClose):
1941         (JSC::iteratorForIterable):
1942         * runtime/IteratorOperations.h:
1943         (JSC::forEachInIterable):
1944         * runtime/JSArray.cpp:
1945         (JSC::JSArray::pop):
1946         (JSC::JSArray::copyToArguments):
1947         * runtime/JSArrayBufferConstructor.cpp:
1948         (JSC::constructArrayBuffer):
1949         * runtime/JSArrayBufferPrototype.cpp:
1950         (JSC::arrayBufferProtoFuncSlice):
1951         * runtime/JSArrayInlines.h:
1952         (JSC::getLength):
1953         (JSC::toLength):
1954         * runtime/JSBoundFunction.cpp:
1955         (JSC::getBoundFunctionStructure):
1956         (JSC::JSBoundFunction::create):
1957         * runtime/JSCJSValue.cpp:
1958         (JSC::JSValue::putToPrimitive):
1959         (JSC::JSValue::toStringSlowCase):
1960         * runtime/JSCJSValueInlines.h:
1961         (JSC::toPreferredPrimitiveType):
1962         (JSC::JSValue::getPropertySlot):
1963         (JSC::JSValue::equalSlowCaseInline):
1964         * runtime/JSDataViewPrototype.cpp:
1965         (JSC::getData):
1966         (JSC::setData):
1967         * runtime/JSFunction.cpp:
1968         (JSC::JSFunction::setFunctionName):
1969         * runtime/JSGenericTypedArrayView.h:
1970         (JSC::JSGenericTypedArrayView::setIndex):
1971         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1972         (JSC::constructGenericTypedArrayViewFromIterator):
1973         (JSC::constructGenericTypedArrayViewWithArguments):
1974         (JSC::constructGenericTypedArrayView):
1975         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1976         (JSC::speciesConstruct):
1977         (JSC::genericTypedArrayViewProtoFuncSet):
1978         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
1979         (JSC::genericTypedArrayViewProtoFuncIncludes):
1980         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1981         (JSC::genericTypedArrayViewProtoFuncJoin):
1982         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1983         (JSC::genericTypedArrayViewProtoFuncSlice):
1984         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
1985         * runtime/JSGlobalObject.h:
1986         (JSC::constructEmptyArray):
1987         (JSC::constructArray):
1988         (JSC::constructArrayNegativeIndexed):
1989         * runtime/JSGlobalObjectFunctions.cpp:
1990         (JSC::globalFuncEval):
1991         * runtime/JSModuleRecord.cpp:
1992         (JSC::JSModuleRecord::instantiateDeclarations):
1993         * runtime/JSONObject.cpp:
1994         (JSC::Stringifier::stringify):
1995         (JSC::Stringifier::toJSON):
1996         (JSC::Stringifier::appendStringifiedValue):
1997         (JSC::Stringifier::Holder::appendNextProperty):
1998         (JSC::Walker::walk):
1999         (JSC::JSONProtoFuncParse):
2000         * runtime/JSObject.cpp:
2001         (JSC::ordinarySetSlow):
2002         (JSC::JSObject::setPrototypeWithCycleCheck):
2003         (JSC::callToPrimitiveFunction):
2004         (JSC::JSObject::defaultHasInstance):
2005         (JSC::JSObject::getPropertyNames):
2006         (JSC::JSObject::toNumber):
2007         (JSC::JSObject::toString):
2008         (JSC::JSObject::defineOwnNonIndexProperty):
2009         (JSC::JSObject::getGenericPropertyNames):
2010         (JSC::JSObject::getMethod):
2011         * runtime/JSObjectInlines.h:
2012         (JSC::createListFromArrayLike):
2013         (JSC::JSObject::getPropertySlot):
2014         (JSC::JSObject::getNonIndexPropertySlot):
2015         * runtime/JSPromiseConstructor.cpp:
2016         (JSC::constructPromise):
2017         * runtime/JSPromiseDeferred.cpp:
2018         (JSC::JSPromiseDeferred::create):
2019         * runtime/JSPropertyNameEnumerator.h:
2020         (JSC::propertyNameEnumerator):
2021         * runtime/JSPropertyNameIterator.cpp:
2022         (JSC::JSPropertyNameIterator::create):
2023         * runtime/JSScope.cpp:
2024         (JSC::isUnscopable):
2025         * runtime/JSString.cpp:
2026         (JSC::JSString::equalSlowCase):
2027         * runtime/JSStringJoiner.cpp:
2028         (JSC::JSStringJoiner::join):
2029         * runtime/LiteralParser.cpp:
2030         (JSC::LiteralParser<CharType>::parse):
2031         * runtime/MapBase.h:
2032         (JSC::MapBase::finishCreation):
2033         * runtime/MapConstructor.cpp:
2034         (JSC::constructMap):
2035         * runtime/MathObject.cpp:
2036         (JSC::mathProtoFuncClz32):
2037         (JSC::mathProtoFuncHypot):
2038         (JSC::mathProtoFuncIMul):
2039         * runtime/ModuleLoaderPrototype.cpp:
2040         (JSC::moduleLoaderPrototypeParseModule):
2041         (JSC::moduleLoaderPrototypeRequestedModules):
2042         (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
2043         * runtime/NativeErrorConstructor.cpp:
2044         (JSC::Interpreter::constructWithNativeErrorConstructor):
2045         * runtime/NumberConstructor.cpp:
2046         (JSC::constructWithNumberConstructor):
2047         * runtime/ObjectConstructor.cpp:
2048         (JSC::constructObject):
2049         (JSC::objectConstructorGetPrototypeOf):
2050         (JSC::objectConstructorSetPrototypeOf):
2051         (JSC::objectConstructorGetOwnPropertyDescriptor):
2052         (JSC::objectConstructorGetOwnPropertyDescriptors):
2053         (JSC::objectConstructorGetOwnPropertyNames):
2054         (JSC::objectConstructorGetOwnPropertySymbols):
2055         (JSC::objectConstructorKeys):
2056         (JSC::ownEnumerablePropertyKeys):
2057         (JSC::toPropertyDescriptor):
2058         (JSC::objectConstructorDefineProperty):
2059         (JSC::defineProperties):
2060         (JSC::objectConstructorSeal):
2061         (JSC::objectConstructorFreeze):
2062         (JSC::objectConstructorIsSealed):
2063         (JSC::objectConstructorIsFrozen):
2064         (JSC::objectConstructorIsExtensible):
2065         (JSC::ownPropertyKeys):
2066         * runtime/ObjectConstructor.h:
2067         (JSC::constructObjectFromPropertyDescriptor):
2068         * runtime/ObjectPrototype.cpp:
2069         (JSC::objectProtoFuncHasOwnProperty):
2070         (JSC::objectProtoFuncIsPrototypeOf):
2071         (JSC::objectProtoFuncDefineGetter):
2072         (JSC::objectProtoFuncDefineSetter):
2073         (JSC::objectProtoFuncLookupGetter):
2074         (JSC::objectProtoFuncLookupSetter):
2075         (JSC::objectProtoFuncPropertyIsEnumerable):
2076         (JSC::objectProtoFuncToLocaleString):
2077         (JSC::objectProtoFuncToString):
2078         * runtime/Operations.cpp:
2079         (JSC::jsAddSlowCase):
2080         * runtime/PropertyDescriptor.cpp:
2081         (JSC::PropertyDescriptor::slowGetterSetter):
2082         * runtime/ProxyConstructor.cpp:
2083         (JSC::makeRevocableProxy):
2084         * runtime/ProxyObject.cpp:
2085         (JSC::performProxyGet):
2086         (JSC::ProxyObject::performGet):
2087         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2088         (JSC::ProxyObject::performHasProperty):
2089         (JSC::ProxyObject::performPut):
2090         (JSC::ProxyObject::putByIndexCommon):
2091         (JSC::performProxyCall):
2092         (JSC::performProxyConstruct):
2093         (JSC::ProxyObject::performDelete):
2094         (JSC::ProxyObject::performPreventExtensions):
2095         (JSC::ProxyObject::performIsExtensible):
2096         (JSC::ProxyObject::performDefineOwnProperty):
2097         (JSC::ProxyObject::performGetOwnPropertyNames):
2098         (JSC::ProxyObject::performSetPrototype):
2099         (JSC::ProxyObject::performGetPrototype):
2100         * runtime/ReflectObject.cpp:
2101         (JSC::reflectObjectConstruct):
2102         (JSC::reflectObjectDefineProperty):
2103         (JSC::reflectObjectGet):
2104         (JSC::reflectObjectGetOwnPropertyDescriptor):
2105         (JSC::reflectObjectIsExtensible):
2106         (JSC::reflectObjectPreventExtensions):
2107         (JSC::reflectObjectSet):
2108         (JSC::reflectObjectSetPrototypeOf):
2109         * runtime/RegExpConstructor.cpp:
2110         (JSC::toFlags):
2111         (JSC::regExpCreate):
2112         (JSC::constructRegExp):
2113         * runtime/RegExpConstructor.h:
2114         (JSC::isRegExp):
2115         * runtime/RegExpObject.cpp:
2116         (JSC::collectMatches):
2117         (JSC::RegExpObject::matchGlobal):
2118         * runtime/RegExpPrototype.cpp:
2119         (JSC::regExpProtoFuncCompile):
2120         (JSC::flagsString):
2121         (JSC::regExpProtoFuncToString):
2122         (JSC::regExpProtoGetterFlags):
2123         (JSC::regExpProtoFuncSearchFast):
2124         (JSC::regExpProtoFuncSplitFast):
2125         * runtime/SetConstructor.cpp:
2126         (JSC::constructSet):
2127         * runtime/StringConstructor.cpp:
2128         (JSC::stringFromCodePoint):
2129         (JSC::constructWithStringConstructor):
2130         * runtime/StringObject.cpp:
2131         (JSC::StringObject::defineOwnProperty):
2132         * runtime/StringPrototype.cpp:
2133         (JSC::replaceUsingRegExpSearch):
2134         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2135         (JSC::replaceUsingStringSearch):
2136         (JSC::replace):
2137         (JSC::stringProtoFuncReplaceUsingRegExp):
2138         (JSC::stringProtoFuncReplaceUsingStringSearch):
2139         (JSC::stringProtoFuncCodePointAt):
2140         (JSC::stringProtoFuncSlice):
2141         (JSC::stringProtoFuncSplitFast):
2142         (JSC::stringProtoFuncSubstr):
2143         (JSC::stringProtoFuncSubstring):
2144         (JSC::stringProtoFuncLocaleCompare):
2145         (JSC::toLocaleCase):
2146         (JSC::stringProtoFuncBig):
2147         (JSC::stringProtoFuncSmall):
2148         (JSC::stringProtoFuncBlink):
2149         (JSC::stringProtoFuncBold):
2150         (JSC::stringProtoFuncFixed):
2151         (JSC::stringProtoFuncItalics):
2152         (JSC::stringProtoFuncStrike):
2153         (JSC::stringProtoFuncSub):
2154         (JSC::stringProtoFuncSup):
2155         (JSC::stringProtoFuncFontcolor):
2156         (JSC::stringProtoFuncFontsize):
2157         (JSC::stringProtoFuncAnchor):
2158         (JSC::stringProtoFuncLink):
2159         (JSC::trimString):
2160         (JSC::stringProtoFuncStartsWith):
2161         (JSC::stringProtoFuncEndsWith):
2162         (JSC::stringIncludesImpl):
2163         (JSC::stringProtoFuncIncludes):
2164         (JSC::builtinStringIncludesInternal):
2165         (JSC::stringProtoFuncNormalize):
2166         * runtime/SymbolConstructor.cpp:
2167         (JSC::symbolConstructorFor):
2168         * runtime/TemplateRegistry.cpp:
2169         (JSC::TemplateRegistry::getTemplateObject):
2170         * runtime/WeakMapConstructor.cpp:
2171         (JSC::constructWeakMap):
2172         * runtime/WeakSetConstructor.cpp:
2173         (JSC::constructWeakSet):
2174         * tools/JSDollarVMPrototype.cpp:
2175         (JSC::functionPrint):
2176
2177 2016-09-26  Don Olmstead  <don.olmstead@am.sony.com>
2178
2179         [JSC] Allow fixedExecutableMemoryPoolSize to be set during build
2180         https://bugs.webkit.org/show_bug.cgi?id=162514
2181
2182         Reviewed by Mark Lam.
2183
2184         * jit/ExecutableAllocator.h:
2185
2186 == Rolled over to ChangeLog-2016-09-26 ==