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