Fix max length check in ArrayPrototype.js' concatSlowPath().
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-02-09  Mark Lam  <mark.lam@apple.com>
2
3         Fix max length check in ArrayPrototype.js' concatSlowPath().
4         https://bugs.webkit.org/show_bug.cgi?id=167270
5         <rdar://problem/30128133>
6
7         Reviewed by Filip Pizlo.
8
9         1. Fixed concatSlowPath() to ensure that the result array length does not exceed
10            @MAX_ARRAY_INDEX.  The old code was checking against @MAX_SAFE_INTEGER in some
11            cases, but this is overly permissive.
12
13         2. Changed concatSlowPath() to throw a RangeError instead of a TypeError to be
14            consistent with the C++ runtime functions in JSArray.cpp.
15
16         3. Changed the RangeError message in concatSlowPath() and JSArray.cpp to "Length
17            exceeded the maximum array length" when the error is that the result length
18            exceeds MAX_ARRAY_INDEX.  We do this for 2 reasons:
19            a. "Length exceeded the maximum array length" is more informative than
20               "Invalid array length".
21            b. We want to use the same string consistently for the same error.
22
23            There are still 2 places in JSArray.cpp that still throws a RangeError with
24            message "Invalid array length".  In those cases, the error is not necessarily
25            due to the result length exceeding MAX_ARRAY_INDEX, but is due to attempting to
26            set a length value that is not an integer that fits in MAX_ARRAY_INDEX e.g.
27            an attempt to set a fractional length value.  Hence, "Invalid array length" is
28            appropriate for those cases.
29
30         4. Fixed JSArray::appendMemcpy() to handle overflows when computing the result
31            array length.
32
33         * builtins/ArrayPrototype.js:
34         (concatSlowPath):
35         * bytecode/BytecodeIntrinsicRegistry.cpp:
36         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
37         * bytecode/BytecodeIntrinsicRegistry.h:
38         * runtime/ArrayPrototype.cpp:
39         (JSC::concatAppendOne):
40         (JSC::arrayProtoPrivateFuncAppendMemcpy):
41         * runtime/JSArray.cpp:
42         (JSC::JSArray::appendMemcpy):
43         (JSC::JSArray::push):
44
45 2017-02-09  Mark Lam  <mark.lam@apple.com>
46
47         Constructed object's global object should be the global object of the constructor.
48         https://bugs.webkit.org/show_bug.cgi?id=167121
49         <rdar://problem/30054759>
50
51         Reviewed by Filip Pizlo and Geoffrey Garen.
52
53         The realm (i.e. globalObject) of any object should be the same as the constructor
54         that instantiated the object.  Changed PrototypeMap::createEmptyStructure() to
55         be passed the correct globalObject to use instead of assuming it's the same one
56         as the prototype object.
57
58         * bytecode/CodeBlock.cpp:
59         (JSC::CodeBlock::finishCreation):
60         * bytecode/InternalFunctionAllocationProfile.h:
61         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
62         * bytecode/ObjectAllocationProfile.h:
63         (JSC::ObjectAllocationProfile::initialize):
64         * runtime/FunctionRareData.cpp:
65         (JSC::FunctionRareData::initializeObjectAllocationProfile):
66         * runtime/FunctionRareData.h:
67         (JSC::FunctionRareData::createInternalFunctionAllocationStructureFromBase):
68         * runtime/InternalFunction.cpp:
69         (JSC::InternalFunction::createSubclassStructure):
70         * runtime/IteratorOperations.cpp:
71         (JSC::createIteratorResultObjectStructure):
72         * runtime/JSBoundFunction.cpp:
73         (JSC::getBoundFunctionStructure):
74         * runtime/JSFunction.cpp:
75         (JSC::JSFunction::allocateAndInitializeRareData):
76         (JSC::JSFunction::initializeRareData):
77         * runtime/JSGlobalObject.cpp:
78         (JSC::JSGlobalObject::init):
79         * runtime/JSProxy.cpp:
80         (JSC::JSProxy::setTarget):
81         * runtime/ObjectConstructor.h:
82         (JSC::constructEmptyObject):
83         * runtime/PrototypeMap.cpp:
84         (JSC::PrototypeMap::createEmptyStructure):
85         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
86         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
87         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
88         * runtime/PrototypeMap.h:
89
90 2017-02-09  Keith Miller  <keith_miller@apple.com>
91
92         We should not allow Function.caller to be used on native functions
93         https://bugs.webkit.org/show_bug.cgi?id=165628
94
95         Reviewed by Mark Lam.
96
97         Also remove unneeded dynamic cast.
98
99         * runtime/JSFunction.cpp:
100         (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
101         (JSC::JSFunction::callerGetter):
102
103 2017-02-08  Keith Miller  <keith_miller@apple.com>
104
105         [JSC] op_in should have ArrayProfile
106         https://bugs.webkit.org/show_bug.cgi?id=164581
107
108         Reviewed by Filip Pizlo.
109
110         This patch adds an ArrayProfile to the op_in bytecode. In the
111         DFG, if we see that we the key is an int32 we will convert the In
112         DFG node to a HasIndexedProperty node instead.
113
114         This patch also flips the two arguments of op_in and the In node
115         to reflect the other property lookup bytecodes.
116
117         * bytecode/BytecodeList.json:
118         * bytecode/CodeBlock.cpp:
119         (JSC::CodeBlock::dumpBytecode):
120         (JSC::CodeBlock::finishCreation):
121         * bytecompiler/BytecodeGenerator.cpp:
122         (JSC::BytecodeGenerator::emitIn):
123         * bytecompiler/BytecodeGenerator.h:
124         (JSC::BytecodeGenerator::emitIn): Deleted.
125         * bytecompiler/NodesCodegen.cpp:
126         (JSC::InNode::emitBytecode):
127         * dfg/DFGByteCodeParser.cpp:
128         (JSC::DFG::ByteCodeParser::parseBlock):
129         * dfg/DFGFixupPhase.cpp:
130         (JSC::DFG::FixupPhase::fixupNode):
131         (JSC::DFG::FixupPhase::convertToHasIndexedProperty):
132         * dfg/DFGNode.h:
133         (JSC::DFG::Node::hasArrayMode):
134         (JSC::DFG::Node::hasInternalMethodType):
135         (JSC::DFG::Node::internalMethodType):
136         (JSC::DFG::Node::setInternalMethodType):
137         * dfg/DFGSpeculativeJIT.cpp:
138         (JSC::DFG::SpeculativeJIT::compileIn):
139         * dfg/DFGSpeculativeJIT.h:
140         (JSC::DFG::SpeculativeJIT::callOperation):
141         * dfg/DFGSpeculativeJIT32_64.cpp:
142         (JSC::DFG::SpeculativeJIT::compile):
143         * dfg/DFGSpeculativeJIT64.cpp:
144         (JSC::DFG::SpeculativeJIT::compile):
145         * ftl/FTLLowerDFGToB3.cpp:
146         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
147         (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
148         * jit/JITOperations.cpp:
149         * jit/JITOperations.h:
150         * llint/LowLevelInterpreter.asm:
151         * parser/Nodes.h:
152         * runtime/CommonSlowPaths.cpp:
153         (JSC::SLOW_PATH_DECL):
154         * runtime/CommonSlowPaths.h:
155         (JSC::CommonSlowPaths::opIn):
156
157 2017-02-08  Saam Barati  <sbarati@apple.com>
158
159         Air IRC might spill a terminal that produces a value after the terminal
160         https://bugs.webkit.org/show_bug.cgi?id=167919
161         <rdar://problem/29754721>
162
163         Reviewed by Filip Pizlo.
164
165         IRC may spill a value-producing terminal (a patchpoint can be a value-producing terminal).
166         It used to do this by placing the spill *after* the terminal. This produces an invalid
167         graph because no instructions are allowed after the terminal.
168         
169         I fixed this bug by having a cleanup pass over the IR after IRC is done.
170         The pass detects this problem, and fixes it by moving the spill into the
171         successors. However, it is careful to detect when the edge to the
172         successor is a critical edge. If the value-producing patchpoint is
173         the only predecessor of the successor, it just moves the spill
174         code to the beginning of the successor. Otherwise, it's a critical
175         edge and it breaks it by adding a block that does the spilling then
176         jumps to the successor.
177
178         * b3/air/AirInsertionSet.cpp:
179         * b3/air/AirInsertionSet.h:
180         (JSC::B3::Air::InsertionSet::insertInsts):
181         * b3/air/AirIteratedRegisterCoalescing.cpp:
182         * b3/testb3.cpp:
183         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
184         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
185         (JSC::B3::run):
186
187 2017-02-07  Mark Lam  <mark.lam@apple.com>
188
189         SigillCrashAnalyzer::analyze() should use a do-while loop instead of a lambda.
190         https://bugs.webkit.org/show_bug.cgi?id=167950
191
192         Reviewed by Michael Saboff.
193
194         Lambdas aren't free (apparently, the compiler isn't able to detect that the
195         lambda does not escape and can be inlined completely).  So, use a do-while loop
196         instead since we don't really need a lambda here.
197
198         * tools/SigillCrashAnalyzer.cpp:
199
200 2017-02-05  Mark Lam  <mark.lam@apple.com>
201
202         The SigillCrashAnalyzer should play nicer with client code that may install its own SIGILL handler.
203         https://bugs.webkit.org/show_bug.cgi?id=167858
204
205         Reviewed by Michael Saboff.
206
207         Here are the scenarios that may come up:
208
209         1. Client code did not install a SIGILL handler.
210            - In this case, once we're done analyzing the SIGILL, we can just restore the
211              default handler and return to let the OS do the default action i.e. capture
212              a core dump.
213
214         2. Client code installed a SIGILL handler before JSC does.
215            - In this case, we will see a non-null handler returned as the old signal
216              handler when we install ours.
217            - In our signal handler, after doing our crash analysis, we should invoke the
218              client handler to let it do its work.
219            - Our analyzer can also tell us if the SIGILL source is from JSC code in
220              general (right now, this would just mean JIT code).
221            - If the SIGILL source is not from JSC, we'll just let the client handler
222              decided how to proceed.  We assume that the client handler will do the right
223              thing (which is how the old behavior is before the SigillCrashAnalyzer was
224              introduced).
225            - If the SIGILL source is from JSC, then we know the SIGILL is an unrecoverable
226              condition.  Hence, after we have given the client handler a chance to run,
227              we should restore the default handler and let the OS capture a core dump.
228              This intentionally overrides whatever signal settings the client handler may
229              have set.
230
231         3. Client code installed a SIGILL handler after JSC does.
232            - In this case, we are dependent on the client handler to call our handler
233              after it does its work.  This is compatible with the old behavior before
234              SigillCrashAnalyzer was introduced.
235            - In our signal handler, if we determine that the SIGILL source is from JSC
236              code, then the SIGILL is not recoverable.  We should then restore the
237              default handler and get a core dump.
238            - If the SIGILL source is not from JSC, we check to see if there's a client
239              handler installed after us.
240            - If we detect a client handler installed after us, we defer judgement on what
241              to do to the client handler.  Since the client handler did not uninstall
242              itself, it must have considered itself to have recovered from the SIGILL.
243              We'll trust the client handler and take no restore action of our own (which
244              is compatible with old code behavior).
245            - If we detect no client handler and we have no previous handler, then we
246              should restore the default handler and get a core dump.
247
248         * tools/SigillCrashAnalyzer.cpp:
249         (JSC::handleCrash):
250         (JSC::installCrashHandler):
251         (JSC::SigillCrashAnalyzer::analyze): Deleted.
252
253 2017-02-07  Yusuke Suzuki  <utatane.tea@gmail.com>
254
255         Unreviewed, manual roll out of r211777
256         https://bugs.webkit.org/show_bug.cgi?id=167457
257
258         * jsc.cpp:
259         (GlobalObject::moduleLoaderImportModule):
260         * runtime/JSGlobalObjectFunctions.cpp:
261         (JSC::globalFuncImportModule):
262
263 2017-02-07  Yusuke Suzuki  <utatane.tea@gmail.com>
264
265         Web Inspector: allow import() inside the inspector
266         https://bugs.webkit.org/show_bug.cgi?id=167457
267
268         Reviewed by Ryosuke Niwa.
269
270         We relax import module hook to accept null SourceOrigin.
271         Such a script can be evaluated from the inspector console.
272
273         * jsc.cpp:
274         (GlobalObject::moduleLoaderImportModule):
275         * runtime/JSGlobalObjectFunctions.cpp:
276         (JSC::globalFuncImportModule):
277
278 2017-02-06  Joseph Pecoraro  <pecoraro@apple.com>
279
280         Web Inspector: Do not use RunLoop when dispatching inspector GC event
281         https://bugs.webkit.org/show_bug.cgi?id=167683
282         <rdar://problem/30167791>
283
284         Reviewed by Brian Burg.
285
286         Move the RunLoop deferred implementation to WebCore. It is not needed
287         for JSContext inspection, and in JSContext inspection we are not
288         guarenteed a RunLoop to defer to.
289
290         * inspector/agents/InspectorHeapAgent.h:
291         * inspector/agents/InspectorHeapAgent.cpp:
292         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
293         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
294         (Inspector::InspectorHeapAgent::disable):
295         (Inspector::InspectorHeapAgent::didGarbageCollect):
296         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): Deleted.
297         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection): Deleted.
298         (Inspector::SendGarbageCollectionEventsTask::reset): Deleted.
299         (Inspector::SendGarbageCollectionEventsTask::timerFired): Deleted.
300
301         (Inspector::InspectorHeapAgent::dispatchGarbageCollectedEvent):
302         Make a virtual method so that WebCore implementations of this agent can choose
303         to dispatch this event asynchronously.
304
305         * inspector/agents/InspectorScriptProfilerAgent.cpp:
306         Remove unnecessary RunLoop include.
307
308 2017-02-06  Joseph Pecoraro  <pecoraro@apple.com>
309
310         Static Analyzer: JSContext.mm: Incorrect decrement of the reference count of an object
311         https://bugs.webkit.org/show_bug.cgi?id=167848
312
313         Reviewed by Saam Barati.
314
315         Source/JavaScriptCore/API/JSContext.mm:87:5: warning: Incorrect decrement of the reference count of an object that is not owned at this point by the caller
316             [self.exceptionHandler release];
317             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
318         1 warning generated.
319
320         * API/JSContext.mm:
321         (-[JSContext dealloc]):
322         Use the ivar in dealloc instead of going through the getter.
323
324 2017-02-05  Mark Lam  <mark.lam@apple.com>
325
326         The VMInspector should use an RAII Locker.
327         https://bugs.webkit.org/show_bug.cgi?id=167854
328
329         Reviewed by Saam Barati.
330
331         Previously, VMInspector::lock() was returning an expected LockToken, and there's
332         no way to unlock it when we're done with it.  This was not a problem before
333         because the VMInspector had only one client, the SigillCrashAnalyzer, that
334         expected the process to crash due to a SIGILL shortly thereafter.
335
336         However, the VMInspector is useful as a debugging tool that we can apply in other
337         debugging tasks.  Fixing VMInspector::lock() to return an RAII locker will enable
338         other use cases.  Plus it's just bad form to be able to lock something and never
339         be able to unlock it.
340
341         * tools/SigillCrashAnalyzer.cpp:
342         (JSC::SigillCrashAnalyzer::analyze):
343         * tools/VMInspector.cpp:
344         * tools/VMInspector.h:
345
346 2017-02-04  Joseph Pecoraro  <pecoraro@apple.com>
347
348         Static Analyzer: Value stored to 'recordedMachineThreads' during its initialization is never read
349         https://bugs.webkit.org/show_bug.cgi?id=167845
350
351         Reviewed by Saam Barati.
352
353         Source/JavaScriptCore/heap/MachineStackMarker.cpp:151:14: warning: Value stored to 'recordedMachineThreads' during its initialization is never read
354                 auto recordedMachineThreads = m_set.take(machineThreads);
355                      ^~~~~~~~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~
356
357         * heap/MachineStackMarker.cpp:
358         (JSC::ActiveMachineThreadsManager::remove):
359
360 2017-02-04  Joseph Pecoraro  <pecoraro@apple.com>
361
362         Static Analyzer: Value stored to 'prev' is never read
363         https://bugs.webkit.org/show_bug.cgi?id=167844
364
365         Reviewed by Saam Barati.
366
367         Source/JavaScriptCore/runtime/JSMapIterator.h:60:13: warning: Value stored to 'prev' is never read
368                     prev = bucket;
369                     ^      ~~~~~~
370         Source/JavaScriptCore/runtime/JSSetIterator.h:60:13: warning: Value stored to 'prev' is never read
371                     prev = bucket;
372                     ^      ~~~~~~
373
374         * runtime/JSMapIterator.h:
375         (JSC::JSMapIterator::advanceIter):
376         * runtime/JSSetIterator.h:
377         (JSC::JSSetIterator::advanceIter):
378
379 2017-02-04  Yusuke Suzuki  <utatane.tea@gmail.com>
380
381         [JSC] Add operationToInt32SensibleSlow to optimize kraken pbkdf2 and sha256
382         https://bugs.webkit.org/show_bug.cgi?id=167736
383
384         Reviewed by Saam Barati.
385
386         Add a new function operationToInt32SensibleSlow. This function is only
387         called after x86 cvttss2si_rr is failed. This means that the
388         given double number never in range of int32 truncatable numbers.
389
390         As a result, exp in operationToInt32 always becomes >= 31. So
391         we can change the condition from `exp < 32` to `exp == 31`.
392         This makes missingOne constant. And it leads significantly good
393         code generation.
394
395         The original operationToInt32 code.
396
397             170:   66 48 0f 7e c1          movq   %xmm0,%rcx
398             175:   31 c0                   xor    %eax,%eax
399             177:   66 48 0f 7e c6          movq   %xmm0,%rsi
400             17c:   48 c1 f9 34             sar    $0x34,%rcx
401             180:   81 e1 ff 07 00 00       and    $0x7ff,%ecx
402             186:   8d 91 01 fc ff ff       lea    -0x3ff(%rcx),%edx
403             18c:   83 fa 53                cmp    $0x53,%edx
404             18f:   77 37                   ja     1c8 <_ZN3JSC16operationToInt32Ed+0x58>
405             191:   83 fa 34                cmp    $0x34,%edx
406             194:   7f 3a                   jg     1d0 <_ZN3JSC16operationToInt32Ed+0x60>
407             196:   b9 34 00 00 00          mov    $0x34,%ecx
408             19b:   66 48 0f 7e c7          movq   %xmm0,%rdi
409             1a0:   29 d1                   sub    %edx,%ecx
410             1a2:   48 d3 ff                sar    %cl,%rdi
411             1a5:   83 fa 1f                cmp    $0x1f,%edx
412             1a8:   89 f8                   mov    %edi,%eax
413             1aa:   7f 12                   jg     1be <_ZN3JSC16operationToInt32Ed+0x4e>
414             1ac:   89 d1                   mov    %edx,%ecx
415             1ae:   b8 01 00 00 00          mov    $0x1,%eax
416             1b3:   d3 e0                   shl    %cl,%eax
417             1b5:   89 c2                   mov    %eax,%edx
418             1b7:   8d 40 ff                lea    -0x1(%rax),%eax
419             1ba:   21 f8                   and    %edi,%eax
420             1bc:   01 d0                   add    %edx,%eax
421             1be:   89 c2                   mov    %eax,%edx
422             1c0:   f7 da                   neg    %edx
423             1c2:   48 85 f6                test   %rsi,%rsi
424             1c5:   0f 48 c2                cmovs  %edx,%eax
425             1c8:   f3 c3                   repz retq
426             1ca:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
427             1d0:   66 48 0f 7e c0          movq   %xmm0,%rax
428             1d5:   81 e9 33 04 00 00       sub    $0x433,%ecx
429             1db:   48 d3 e0                shl    %cl,%rax
430             1de:   eb de                   jmp    1be <_ZN3JSC16operationToInt32Ed+0x4e>
431
432         The operationToInt32SensibleSlow code.
433
434             1e0:   66 48 0f 7e c1          movq   %xmm0,%rcx
435             1e5:   66 48 0f 7e c2          movq   %xmm0,%rdx
436             1ea:   48 c1 f9 34             sar    $0x34,%rcx
437             1ee:   81 e1 ff 07 00 00       and    $0x7ff,%ecx
438             1f4:   8d b1 01 fc ff ff       lea    -0x3ff(%rcx),%esi
439             1fa:   83 fe 34                cmp    $0x34,%esi
440             1fd:   7e 21                   jle    220 <_ZN3JSC28operationToInt32SensibleSlowEd+0x40>
441             1ff:   66 48 0f 7e c0          movq   %xmm0,%rax
442             204:   81 e9 33 04 00 00       sub    $0x433,%ecx
443             20a:   48 d3 e0                shl    %cl,%rax
444             20d:   89 c1                   mov    %eax,%ecx
445             20f:   f7 d9                   neg    %ecx
446             211:   48 85 d2                test   %rdx,%rdx
447             214:   0f 48 c1                cmovs  %ecx,%eax
448             217:   c3                      retq
449             218:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
450             21f:   00
451             220:   66 48 0f 7e c0          movq   %xmm0,%rax
452             225:   b9 34 00 00 00          mov    $0x34,%ecx
453             22a:   29 f1                   sub    %esi,%ecx
454             22c:   48 d3 f8                sar    %cl,%rax
455             22f:   89 c1                   mov    %eax,%ecx
456             231:   81 c9 00 00 00 80       or     $0x80000000,%ecx
457             237:   83 fe 1f                cmp    $0x1f,%esi
458             23a:   0f 44 c1                cmove  %ecx,%eax
459             23d:   89 c1                   mov    %eax,%ecx
460             23f:   f7 d9                   neg    %ecx
461             241:   48 85 d2                test   %rdx,%rdx
462             244:   0f 48 c1                cmovs  %ecx,%eax
463             247:   c3                      retq
464             248:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
465             24f:   00
466
467         This improves kraken pbkdf2 by 10.8% and sha256 by 7.5%.
468
469                                                        baseline                  patched
470
471             stanford-crypto-pbkdf2                 153.195+-2.745      ^     138.204+-2.513         ^ definitely 1.1085x faster
472             stanford-crypto-sha256-iterative        49.047+-1.038      ^      45.610+-1.235         ^ definitely 1.0754x faster
473
474             <arithmetic>                           101.121+-1.379      ^      91.907+-1.500         ^ definitely 1.1003x faster
475
476         * assembler/CPU.h:
477         (JSC::hasSensibleDoubleToInt):
478         * dfg/DFGSpeculativeJIT.cpp:
479         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
480         * ftl/FTLLowerDFGToB3.cpp:
481         (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
482         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
483         * ftl/FTLOutput.cpp:
484         (JSC::FTL::Output::hasSensibleDoubleToInt): Deleted.
485         * ftl/FTLOutput.h:
486         * runtime/MathCommon.cpp:
487         (JSC::operationToInt32SensibleSlow):
488         * runtime/MathCommon.h:
489
490 2017-02-03  Joseph Pecoraro  <pecoraro@apple.com>
491
492         Unreviewed rollout of r211486, r211629.
493
494         Original change is not ideal and is causing issues.
495
496         * inspector/agents/InspectorHeapAgent.cpp:
497         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
498         * runtime/InitializeThreading.cpp:
499         (JSC::initializeThreading):
500
501 2017-02-03  JF Bastien  <jfbastien@apple.com>
502
503         OSR entry: delay outer-loop compilation when at inner-loop
504         https://bugs.webkit.org/show_bug.cgi?id=167149
505
506         Reviewed by Filip Pizlo.
507
508         r211224 and r211461 were reverted because they caused massive
509         kraken/ai-astar regressions. This patch instead does the
510         minimally-disruptive change to fix the original bug as described
511         below, but omits extra tuning and refactoring which I had
512         before. I'll commit tuning and refactoring separately, if this
513         sticks. This patch is therefore very minimal, and layers carefully
514         on top of the complex spaghetti-logic. The only change it makes is
515         that it uses triggers to indicate to outer loops that they should
516         compile, which fixes the immediate bug and seems roughly perf
517         neutral (maybe a small gain on kraken sometimes, other times a
518         small regression as would be expected from slightly compiling
519         later). As opposed to r211461 this patch doesn't unconditionally
520         unset the trigger because it prevents further DFG executions from
521         entering. It therefore makes the trigger a tri-state enum class:
522         don't trigger, compilation done, start compilation. Only "start
523         compilation" gets reset to "don't trigger". "Compilation done"
524         does not (unless there's a problem compiling, then it gets set
525         back to "don't trigger").
526
527         As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
528         compilation can be kicked off for an entry into an outer-loop,
529         while executing an inner-loop. This is desirable because often the
530         codegen from an inner-entry isn't as good as the codegen from an
531         outer-entry, but execution from an inner-loop is often pretty hot
532         and likely to kick off compilation. This approach provided nice
533         speedups on Kraken because we'd select to enter to the outer-loop
534         very reliably, which reduces variability (the inner-loop was
535         selected roughly 1/5 times from my unscientific measurements).
536
537         When compilation starts we take a snapshot of the JSValues at the
538         current execution state using OSR's recovery mechanism. These
539         values are passed to the compiler and are used as way to perform
540         type profiling, and could be used to observe cell types as well as
541         to perform predictions such as through constant propagation.
542
543         It's therefore desired to enter from the outer-loop when we can,
544         but we need to be executing from that location to capture the
545         right JSValues, otherwise we're confusing the compiler and giving
546         it inaccurate JSValues which can lead it to predict the wrong
547         things, leading to suboptimal code or recompilation due to
548         misprediction, or in super-corner-cases a crash.
549
550         DFG tier-up was added here:
551         https://bugs.webkit.org/show_bug.cgi?id=112838
552
553         * dfg/DFGJITCode.h:
554         * dfg/DFGJITCompiler.cpp:
555         (JSC::DFG::JITCompiler::JITCompiler):
556         * dfg/DFGOperations.cpp:
557         * dfg/DFGSpeculativeJIT64.cpp:
558         (JSC::DFG::SpeculativeJIT::compile):
559         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
560         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
561         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
562         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
563         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
564         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
565
566 2017-02-03  Saam Barati  <sbarati@apple.com>
567
568         When OSR entering to the baseline JIT from the LLInt for a ProgramCodeBlock we can skip compiling a lot of the program
569         https://bugs.webkit.org/show_bug.cgi?id=167725
570         <rdar://problem/30339082>
571
572         Reviewed by Michael Saboff.
573
574         We often want to baseline compile ProgramCode once we hit a loop in the LLInt.
575         However, some programs execute a non-trivial amount of code before the loop.
576         This code can never be executed again because ProgramCodeBlocks never run more
577         than once. We're wasting time and memory by compiling code that is unreachable
578         from the OSR entry destination. This patch fixes this by only compiling code
579         that is reachable from the OSR entry destination.
580
581         This is a speedup on Kraken/ai-astar for devices with limited CPUs (I've been
582         testing on devices with 2 CPUs). On ai-astar, we were spending 50-100ms compiling
583         a huge ProgramCodeBlock in the baseline JIT where the majority of the code
584         would never execute. If this compilation was kicked off on the main thread,
585         then we'd be stalled for a long time. If it were started on the baseline JITs
586         background compilation thread, we'd still waste 50-100ms in that thread, causing
587         all other baseline compilations to happen on the main thread.
588
589         * interpreter/Interpreter.cpp:
590         (JSC::Interpreter::executeProgram):
591         * interpreter/Interpreter.h:
592         * jit/JIT.cpp:
593         (JSC::JIT::JIT):
594         (JSC::JIT::privateCompileMainPass):
595         * jit/JIT.h:
596         (JSC::JIT::compile):
597         * jit/JITWorklist.cpp:
598         (JSC::JITWorklist::Plan::Plan):
599         (JSC::JITWorklist::Plan::compileNow):
600         (JSC::JITWorklist::compileLater):
601         (JSC::JITWorklist::compileNow):
602         * jit/JITWorklist.h:
603         * llint/LLIntSlowPaths.cpp:
604         (JSC::LLInt::jitCompileAndSetHeuristics):
605         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
606         * runtime/Completion.cpp:
607         (JSC::evaluate):
608
609 2017-02-03  Csaba Osztrogonác  <ossy@webkit.org>
610
611         Unreviewed typo fix after r211630.
612
613         * CMakeLists.txt:
614
615 2017-02-03  Carlos Garcia Campos  <cgarcia@igalia.com>
616
617         [GTK] Add initial implementation of resource usage overlay
618         https://bugs.webkit.org/show_bug.cgi?id=167731
619
620         Reviewed by Michael Catanzaro.
621
622         Also expose nextFireTime() for GTK+ port.
623
624         * heap/GCActivityCallback.cpp:
625         (JSC::GCActivityCallback::scheduleTimer):
626         (JSC::GCActivityCallback::cancelTimer):
627         * heap/GCActivityCallback.h:
628
629 2017-02-03  Csaba Osztrogonác  <ossy@webkit.org>
630
631         [cmake] Unreviewed AArch64 buildfix after r211603.
632         https://bugs.webkit.org/show_bug.cgi?id=167714
633
634         * CMakeLists.txt:
635
636 2017-02-02  Andreas Kling  <akling@apple.com>
637
638         [Mac] In-process memory pressure monitor for WebContent processes AKA websam
639         <https://webkit.org/b/167491>
640         <rdar://problem/30116072>
641
642         Reviewed by Antti Koivisto.
643
644         Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
645         WebCore-side memory footprint monitor.
646
647         * heap/Heap.cpp:
648         (JSC::Heap::updateAllocationLimits):
649         (JSC::Heap::didExceedMaxLiveSize): Deleted.
650         * heap/Heap.h:
651         (JSC::Heap::setMaxLiveSize): Deleted.
652
653 2017-02-02  Mark Lam  <mark.lam@apple.com>
654
655         Add a SIGILL crash analyzer to make debugging SIGILLs easier.
656         https://bugs.webkit.org/show_bug.cgi?id=167714
657         <rdar://problem/30318237>
658
659         Not reviewed.
660
661         Build fix for CLOOP build.
662
663         * tools/VMInspector.cpp:
664
665 2017-02-02  Mark Lam  <mark.lam@apple.com>
666
667         Add a SIGILL crash analyzer to make debugging SIGILLs easier.
668         https://bugs.webkit.org/show_bug.cgi?id=167714
669         <rdar://problem/30318237>
670
671         Reviewed by Filip Pizlo.
672
673         The current implementation is only for X86_64 and ARM64 on OS(DARWIN).  The
674         analyzer is not enabled for all other ports.
675
676         * CMakeLists.txt:
677         * JavaScriptCore.xcodeproj/project.pbxproj:
678         * API/JSVirtualMachine.mm:
679         * assembler/ARM64Assembler.h:
680         (JSC::ARM64Assembler::illegalInstruction):
681         * assembler/MacroAssemblerARM64.h:
682         (JSC::MacroAssemblerARM64::illegalInstruction):
683         * assembler/MacroAssemblerX86Common.h:
684         (JSC::MacroAssemblerX86Common::illegalInstruction):
685         * assembler/X86Assembler.h:
686         (JSC::X86Assembler::illegalInstruction):
687         * heap/Heap.cpp:
688         (JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
689         * heap/Heap.h:
690         * heap/HeapInlines.h:
691         (JSC::Heap::forEachCodeBlockIgnoringJITPlans):
692         * runtime/Options.cpp:
693         (JSC::Options::isAvailable):
694         (JSC::recomputeDependentOptions):
695         * runtime/Options.h:
696         * runtime/VM.cpp:
697         (JSC::VM::VM):
698         (JSC::VM::~VM):
699         * runtime/VM.h:
700         * tools/SigillCrashAnalyzer.cpp: Added.
701         (JSC::SignalContext::SignalContext):
702         (JSC::SignalContext::dump):
703         (JSC::handleCrash):
704         (JSC::initializeCrashHandler):
705         (JSC::ensureSigillCrashAnalyzer):
706         (JSC::SigillCrashAnalyzer::analyze):
707         (JSC::SigillCrashAnalyzer::dumpCodeBlock):
708         * tools/SigillCrashAnalyzer.h: Added.
709         * tools/VMInspector.cpp: Added.
710         (JSC::VMInspector::instance):
711         (JSC::VMInspector::add):
712         (JSC::VMInspector::remove):
713         (JSC::ensureIsSafeToLock):
714         * tools/VMInspector.h: Added.
715         (JSC::VMInspector::iterate):
716
717 2017-02-02  Chris Dumez  <cdumez@apple.com>
718
719         {}.toString.call(crossOriginWindow) should return "[object Object]"
720         https://bugs.webkit.org/show_bug.cgi?id=167701
721         <rdar://problem/30330797>
722
723         Reviewed by Keith Miller.
724
725         Have JSProxy forward toStringName calls to its target so Window
726         can override it.
727
728         * runtime/JSProxy.cpp:
729         (JSC::JSProxy::toStringName):
730         * runtime/JSProxy.h:
731
732 2017-02-02  Commit Queue  <commit-queue@webkit.org>
733
734         Unreviewed, rolling out r211571 and r211582.
735         https://bugs.webkit.org/show_bug.cgi?id=167751
736
737         This change caused API test WebKit1.MemoryPressureHandler to
738         fail with an assertion. (Requested by ryanhaddad on #webkit).
739
740         Reverted changesets:
741
742         "[Mac] In-process memory pressure monitor for WebContent
743         processes."
744         https://bugs.webkit.org/show_bug.cgi?id=167491
745         http://trac.webkit.org/changeset/211571
746
747         "Unreviewed attempt to fix the Windows build after r211571."
748         http://trac.webkit.org/changeset/211582
749
750 2017-02-02  Andreas Kling  <akling@apple.com>
751
752         [Mac] In-process memory pressure monitor for WebContent processes.
753         <https://webkit.org/b/167491>
754         <rdar://problem/30116072>
755
756         Reviewed by Antti Koivisto.
757
758         Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
759         WebCore-side memory footprint monitor.
760
761         * heap/Heap.cpp:
762         (JSC::Heap::updateAllocationLimits):
763         (JSC::Heap::didExceedMaxLiveSize): Deleted.
764         * heap/Heap.h:
765         (JSC::Heap::setMaxLiveSize): Deleted.
766
767 2017-02-02  Joseph Pecoraro  <pecoraro@apple.com>
768
769         Removed unused m_errorHandlingModeReentry from Interpreter
770         https://bugs.webkit.org/show_bug.cgi?id=167726
771
772         Reviewed by Yusuke Suzuki.
773
774         * interpreter/Interpreter.cpp:
775         (JSC::Interpreter::Interpreter):
776         * interpreter/Interpreter.h:
777
778 2017-02-01  Commit Queue  <commit-queue@webkit.org>
779
780         Unreviewed, rolling out r211461.
781         https://bugs.webkit.org/show_bug.cgi?id=167721
782
783         Big regression on kraken (Requested by jfbastien on #webkit).
784
785         Reverted changeset:
786
787         "OSR entry: delay outer-loop compilation when at inner-loop"
788         https://bugs.webkit.org/show_bug.cgi?id=167149
789         http://trac.webkit.org/changeset/211461
790
791 2017-02-01  Keith Miller  <keith_miller@apple.com>
792
793         Unreviewed, fix unintended change.
794
795         * runtime/SamplingProfiler.cpp:
796         (JSC::SamplingProfiler::StackFrame::displayName):
797
798 2017-02-01  Keith Miller  <keith_miller@apple.com>
799
800         The sampling profile should have an option to sample from C frames.
801         https://bugs.webkit.org/show_bug.cgi?id=167614
802
803         Reviewed by Saam Barati.
804
805         We should be able to use the sampling profiler, at least
806         internally, to trace C calls.  This patch only modifies the JSC
807         shell although it would be nice to add it to the Web Inspector in
808         a future patch.
809
810         * runtime/Options.h:
811         * runtime/SamplingProfiler.cpp:
812         (JSC::FrameWalker::FrameWalker):
813         (JSC::FrameWalker::walk):
814         (JSC::FrameWalker::recordJSFrame):
815         (JSC::CFrameWalker::CFrameWalker):
816         (JSC::CFrameWalker::walk):
817         (JSC::CFrameWalker::isCFrame):
818         (JSC::CFrameWalker::advanceToParentFrame):
819         (JSC::CFrameWalker::frame):
820         (JSC::SamplingProfiler::takeSample):
821         (JSC::SamplingProfiler::processUnverifiedStackTraces):
822         (JSC::SamplingProfiler::StackFrame::displayName):
823         * runtime/SamplingProfiler.h:
824         (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
825
826 2017-02-01  Joseph Pecoraro  <pecoraro@apple.com>
827
828         Web Inspector: Use guaranteed RunLoop instead of RunLoop::current for dispatching inspector GC event
829         https://bugs.webkit.org/show_bug.cgi?id=167683
830         <rdar://problem/30167791>
831
832         Reviewed by Timothy Hatcher.
833
834         * inspector/agents/InspectorHeapAgent.cpp:
835         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
836         Use RunLoop::main instead of RunLoop::current which may go away.
837
838         * runtime/InitializeThreading.cpp:
839         (JSC::initializeThreading):
840         Ensure RunLoop::main is initialized when using JSC APIs.
841
842 2017-02-01  Yusuke Suzuki  <utatane.tea@gmail.com>
843
844         ArityFixup should adjust SP first
845         https://bugs.webkit.org/show_bug.cgi?id=167239
846
847         Reviewed by Michael Saboff.
848
849         Arity fixup extends the stack and copy/fill the stack with
850         the values. At that time, we accidentally read/write stack
851         space below the stack pointer. As a result, we touch the area
852         of the stack space below the x64 red zone. These areas are unsafe.
853         OS may corrupt this space when constructing a signal stack.
854         The Linux kernel could not populate the pages for this space
855         and causes segmentation fault. This patch changes the stack
856         pointer before performing the arity fixup.
857
858         * jit/ThunkGenerators.cpp:
859         (JSC::arityFixupGenerator):
860         * llint/LowLevelInterpreter32_64.asm:
861         * llint/LowLevelInterpreter64.asm:
862
863 2017-01-31  Filip Pizlo  <fpizlo@apple.com>
864
865         Make verifyEdge a RELEASE_ASSERT
866         <rdar://problem/30296879>
867
868         Rubber stamped by Saam Barati.
869
870         * dfg/DFGAbstractInterpreterInlines.h:
871         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
872
873 2017-01-31  JF Bastien  <jfbastien@apple.com>
874
875         OSR entry: delay outer-loop compilation when at inner-loop
876         https://bugs.webkit.org/show_bug.cgi?id=167149
877
878         Reviewed by Filip Pizlo.
879
880         r211224 was reverted because it caused a massive kraken/ai-astar
881         regression. This patch instead does the minimally-disruptive
882         change to fix the original bug as described below, but omits extra
883         tuning and refactoring which I had before. I'll commit tuning and
884         refactoring separately, if this sticks. This patch is therefore
885         very minimal, and layers carefully on top of the complex
886         spaghetti-logic. The only change it makes is that it uses triggers
887         to indicate to outer loops that they should compile, which fixes
888         the immediate bug and seems roughly perf neutral (maybe a small
889         gain on kraken sometimes, other times a small regression as would
890         be expected from compiling later).
891
892         As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
893         compilation can be kicked off for an entry into an outer-loop,
894         while executing an inner-loop. This is desirable because often the
895         codegen from an inner-entry isn't as good as the codegen from an
896         outer-entry, but execution from an inner-loop is often pretty hot
897         and likely to kick off compilation. This approach provided nice
898         speedups on Kraken because we'd select to enter to the outer-loop
899         very reliably, which reduces variability (the inner-loop was
900         selected roughly 1/5 times from my unscientific measurements).
901
902         When compilation starts we take a snapshot of the JSValues at the
903         current execution state using OSR's recovery mechanism. These
904         values are passed to the compiler and are used as way to perform
905         type profiling, and could be used to observe cell types as well as
906         to perform predictions such as through constant propagation.
907
908         It's therefore desired to enter from the outer-loop when we can,
909         but we need to be executing from that location to capture the
910         right JSValues, otherwise we're confusing the compiler and giving
911         it inaccurate JSValues which can lead it to predict the wrong
912         things, leading to suboptimal code or recompilation due to
913         misprediction, or in super-corner-cases a crash.
914
915         These effects are pretty hard to measure: Fil points out that
916         marsalis-osr-entry really needs mustHandleValues (the JSValues
917         from the point of execution) because right now it just happens to
918         correctly guess int32. I tried removing mustHandleValues entirely
919         and saw no slowdowns, but our benchmarks probably aren't
920         sufficient to reliably find issues, sometimes because we happen to
921         have sufficient mitigations.
922
923         DFG tier-up was added here:
924         https://bugs.webkit.org/show_bug.cgi?id=112838
925
926         * dfg/DFGOperations.cpp:
927
928 2017-01-31  Filip Pizlo  <fpizlo@apple.com>
929
930         The mutator should be able to perform increments of GC work
931         https://bugs.webkit.org/show_bug.cgi?id=167528
932
933         Reviewed by Keith Miller and Geoffrey Garen.
934
935         The cool thing about having a concurrent and parallel collector is that it's easy to also make
936         it incremental, because the load balancer can also hand over work to anyone (including the
937         mutator) and since the collector is running concurrently anyway, the mutator can usually rely
938         on the balancer having some spare work.
939
940         This change adds a classic work-based incremental mode to the GC. When you allocate K bytes,
941         you have to do Options::gcIncrementScale() * K "bytes" of draining. This is ammortized so that
942         it only happens in allocation slow paths.
943
944         On computers that have a lot of CPUs, this mode is not profitable and we set gcIncrementScale
945         to zero. On such computers, Riptide was already performing great because there was no way that
946         one mutator thread could outpace many GC threads. But on computers with fewer CPUs, there were
947         problems having to do with making the collector progress quickly enough so that the heap
948         doesn't grow too much. The stochastic scheduler actually made things worse, because it relies
949         a lot on the fact that the GC will simply be faster than the mutator anyway. The old scheduler
950         claimed to address the problem of GC pace, but it used a time-based scheduler, which is not as
951         precise at keeping pase as the new work-based incremental mode.
952
953         In theory, the work-based mode guarantees a bound on how much the heap can grow during a
954         collection just because each byte allocated means some number of bytes visited. We don't try
955         to create such a theoretical bound. We're just trying to give the collector an unfair advantage
956         in any race with the mutator.
957
958         Turning on incremental mode, the stochastic scheduler, and passive draining in combination with
959         each other is a huge splay-latency speed-up on my iPad. It's also a CDjs progression. It does
960         regress splay-throughput, but I think that's fine (the regression is 11%, the progression is
961         3x).
962
963         * heap/Heap.cpp:
964         (JSC::Heap::Heap):
965         (JSC::Heap::~Heap):
966         (JSC::Heap::markToFixpoint):
967         (JSC::Heap::updateObjectCounts):
968         (JSC::Heap::endMarking):
969         (JSC::Heap::finalize):
970         (JSC::Heap::didAllocate):
971         (JSC::Heap::visitCount):
972         (JSC::Heap::bytesVisited):
973         (JSC::Heap::forEachSlotVisitor):
974         (JSC::Heap::performIncrement):
975         (JSC::Heap::threadVisitCount): Deleted.
976         (JSC::Heap::threadBytesVisited): Deleted.
977         * heap/Heap.h:
978         * heap/MarkStack.cpp:
979         (JSC::MarkStackArray::transferTo):
980         * heap/MarkStack.h:
981         * heap/SlotVisitor.cpp:
982         (JSC::SlotVisitor::didStartMarking):
983         (JSC::SlotVisitor::clearMarkStacks):
984         (JSC::SlotVisitor::appendToMarkStack):
985         (JSC::SlotVisitor::noteLiveAuxiliaryCell):
986         (JSC::SlotVisitor::donateKnownParallel):
987         (JSC::SlotVisitor::drain):
988         (JSC::SlotVisitor::performIncrementOfDraining):
989         (JSC::SlotVisitor::didReachTermination):
990         (JSC::SlotVisitor::hasWork):
991         (JSC::SlotVisitor::drainFromShared):
992         (JSC::SlotVisitor::drainInParallelPassively):
993         (JSC::SlotVisitor::donateAll):
994         (JSC::SlotVisitor::correspondingGlobalStack):
995         * heap/SlotVisitor.h:
996         * heap/SlotVisitorInlines.h:
997         (JSC::SlotVisitor::reportExtraMemoryVisited):
998         (JSC::SlotVisitor::forEachMarkStack):
999         * heap/SpaceTimeMutatorScheduler.cpp:
1000         (JSC::SpaceTimeMutatorScheduler::log):
1001         * heap/StochasticSpaceTimeMutatorScheduler.cpp:
1002         (JSC::StochasticSpaceTimeMutatorScheduler::log):
1003         * jsc.cpp:
1004         (GlobalObject::finishCreation):
1005         (functionHeapCapacity):
1006         * runtime/Options.cpp:
1007         (JSC::overrideDefaults):
1008         * runtime/Options.h:
1009
1010 2017-01-31  Tomas Popela  <tpopela@redhat.com>
1011
1012         Compilation error in JSArrayBufferView.h
1013         https://bugs.webkit.org/show_bug.cgi?id=167642
1014
1015         Reviewed by Alex Christensen.
1016
1017         * runtime/JSArrayBufferView.h:
1018         (JSC::JSArrayBufferView::vector):
1019
1020 2017-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>
1021
1022         [JSC] Do not reject WebAssembly.compile() with Exception
1023         https://bugs.webkit.org/show_bug.cgi?id=167585
1024
1025         Reviewed by Mark Lam.
1026
1027         We accidentally reject the promise with Exception instead of Exception::value()
1028         for the result of WebAssembly::compile().
1029
1030         * wasm/JSWebAssembly.cpp:
1031         (JSC::webAssemblyCompileFunc):
1032
1033 2017-01-30  Joseph Pecoraro  <pecoraro@apple.com>
1034
1035         Implement PerformanceObserver
1036         https://bugs.webkit.org/show_bug.cgi?id=167546
1037         <rdar://problem/30247959>
1038
1039         Reviewed by Ryosuke Niwa.
1040
1041         * runtime/CommonIdentifiers.h:
1042
1043 2017-01-30  Matt Baker  <mattbaker@apple.com>
1044
1045         Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
1046         https://bugs.webkit.org/show_bug.cgi?id=165633
1047         <rdar://problem/29738502>
1048
1049         Reviewed by Joseph Pecoraro.
1050
1051         This patch limits the memory used by the Inspector backend to store async
1052         stack trace data.
1053
1054         Asynchronous stack traces are stored as a disjoint set of parent pointer
1055         trees. Tree nodes represent asynchronous operations, and hold a copy of
1056         the stack trace at the time the operation was scheduled. Each tree can
1057         be regarded as a set of stack traces, stored as singly linked lists that
1058         share part of their structure (specifically their tails). Traces belonging
1059         to the same tree will at least share a common root. A stack trace begins
1060         at a leaf node and follows the chain of parent pointers to the root of
1061         of the tree. Leaf nodes always contain pending asynchronous calls.
1062
1063         When an asynchronous operation is scheduled with requestAnimationFrame,
1064         setInterval, etc, a node is created containing the current call stack and
1065         some bookkeeping data for the operation. An unique identifier comprised
1066         of an operation type and callback identifier is mapped to the node. If
1067         scheduling the callback was itself the result of an asynchronous call,
1068         the node becomes a child of the node associated with that call, otherwise
1069         it becomes the root of a new tree.
1070
1071         A node is either `pending`, `active`, `dispatched`, or `canceled`. Nodes
1072         start out as pending. After a callback for a pending node is dispatched
1073         the node is marked as such, unless it is a repeating callback such as
1074         setInterval, in which case it remains pending. Once a node is no longer
1075         pending it is removed, as long as it has no children. Since nodes are
1076         reference counted, it is a property of the stack trace tree that nodes
1077         that are no longer pending and have no children pointing to them will be
1078         automatically pruned from the tree.
1079
1080         If an async operation is canceled (e.g. cancelTimeout), the associated
1081         node is marked as such. If the callback is not being dispatched at the
1082         time, and has no children, it is removed.
1083
1084         Because async operations can be chained indefinitely, stack traces are
1085         limited to a maximum depth. The depth of a stack trace is equal to the
1086         sum of the depths of its nodes, with a node's depth equal to the number
1087         of frames in its associated call stack. For any stack trace,
1088
1089             S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
1090             depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)
1091
1092         A stack trace is truncated when it exceeds the maximum depth. Truncation
1093         occurs on node boundaries, not call frames, consequently the maximum depth
1094         is more of a target than a guarantee:
1095
1096             d = maximum stack trace depth
1097             for all S, depth(S) ≤ d + depth(s𝑘)
1098
1099         Because nodes can belong to multiple stack traces, it may be necessary
1100         to clone the tail of a stack trace being truncated to prevent other traces
1101         from being effected.
1102
1103         * CMakeLists.txt:
1104         * JavaScriptCore.xcodeproj/project.pbxproj:
1105         * inspector/AsyncStackTrace.cpp: Added.
1106         (Inspector::AsyncStackTrace::create):
1107         (Inspector::AsyncStackTrace::AsyncStackTrace):
1108         (Inspector::AsyncStackTrace::~AsyncStackTrace):
1109         (Inspector::AsyncStackTrace::isPending):
1110         (Inspector::AsyncStackTrace::isLocked):
1111         (Inspector::AsyncStackTrace::willDispatchAsyncCall):
1112         (Inspector::AsyncStackTrace::didDispatchAsyncCall):
1113         (Inspector::AsyncStackTrace::didCancelAsyncCall):
1114         (Inspector::AsyncStackTrace::buildInspectorObject):
1115         (Inspector::AsyncStackTrace::truncate):
1116         (Inspector::AsyncStackTrace::remove):
1117         * inspector/AsyncStackTrace.h:
1118         * inspector/agents/InspectorDebuggerAgent.cpp:
1119         (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
1120         (Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
1121         (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
1122         (Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
1123         (Inspector::InspectorDebuggerAgent::didPause):
1124         (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
1125         (Inspector::InspectorDebuggerAgent::buildAsyncStackTrace): Deleted.
1126         (Inspector::InspectorDebuggerAgent::refAsyncCallData): Deleted.
1127         (Inspector::InspectorDebuggerAgent::derefAsyncCallData): Deleted.
1128         * inspector/agents/InspectorDebuggerAgent.h:
1129         * inspector/protocol/Console.json:
1130
1131 2017-01-30  Ryan Haddad  <ryanhaddad@apple.com>
1132
1133         Unreviewed, rolling out r211345.
1134
1135         The LayoutTest for this change is failing an assertion.
1136
1137         Reverted changeset:
1138
1139         "Web Inspector: Need some limit on Async Call Stacks for async
1140         loops (rAF loops)"
1141         https://bugs.webkit.org/show_bug.cgi?id=165633
1142         http://trac.webkit.org/changeset/211345
1143
1144 2017-01-28  Matt Baker  <mattbaker@apple.com>
1145
1146         Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
1147         https://bugs.webkit.org/show_bug.cgi?id=165633
1148         <rdar://problem/29738502>
1149
1150         Reviewed by Joseph Pecoraro.
1151
1152         This patch limits the memory used by the Inspector backend to store async
1153         stack trace data.
1154
1155         Asynchronous stack traces are stored as a disjoint set of parent pointer
1156         trees. Tree nodes represent asynchronous operations, and hold a copy of
1157         the stack trace at the time the operation was scheduled. Each tree can
1158         be regarded as a set of stack traces, stored as singly linked lists that
1159         share part of their structure (specifically their tails). Traces belonging
1160         to the same tree will at least share a common root. A stack trace begins
1161         at a leaf node and follows the chain of parent pointers to the root of
1162         of the tree. Leaf nodes always contain pending asynchronous calls.
1163
1164         When an asynchronous operation is scheduled with requestAnimationFrame,
1165         setInterval, etc, a node is created containing the current call stack and
1166         some bookkeeping data for the operation. An unique identifier comprised
1167         of an operation type and callback identifier is mapped to the node. If
1168         scheduling the callback was itself the result of an asynchronous call,
1169         the node becomes a child of the node associated with that call, otherwise
1170         it becomes the root of a new tree.
1171
1172         A node is either `pending`, `active`, `dispatched`, or `canceled`. Nodes
1173         start out as pending. After a callback for a pending node is dispatched
1174         the node is marked as such, unless it is a repeating callback such as
1175         setInterval, in which case it remains pending. Once a node is no longer
1176         pending it is removed, as long as it has no children. Since nodes are
1177         reference counted, it is a property of the stack trace tree that nodes
1178         that are no longer pending and have no children pointing to them will be
1179         automatically pruned from the tree.
1180
1181         If an async operation is canceled (e.g. cancelTimeout), the associated
1182         node is marked as such. If the callback is not being dispatched at the
1183         time, and has no children, it is removed.
1184
1185         Because async operations can be chained indefinitely, stack traces are
1186         limited to a maximum depth. The depth of a stack trace is equal to the
1187         sum of the depths of its nodes, with a node's depth equal to the number
1188         of frames in its associated call stack. For any stack trace,
1189
1190             S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
1191             depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)
1192
1193         A stack trace is truncated when it exceeds the maximum depth. Truncation
1194         occurs on node boundaries, not call frames, consequently the maximum depth
1195         is more of a target than a guarantee:
1196
1197             d = maximum stack trace depth
1198             for all S, depth(S) ≤ d + depth(s𝑘)
1199
1200         Because nodes can belong to multiple stack traces, it may be necessary
1201         to clone the tail of a stack trace being truncated to prevent other traces
1202         from being effected.
1203
1204         * CMakeLists.txt:
1205         * JavaScriptCore.xcodeproj/project.pbxproj:
1206         * inspector/AsyncStackTrace.cpp: Added.
1207         (Inspector::AsyncStackTrace::create):
1208         (Inspector::AsyncStackTrace::AsyncStackTrace):
1209         (Inspector::AsyncStackTrace::~AsyncStackTrace):
1210         (Inspector::AsyncStackTrace::isPending):
1211         (Inspector::AsyncStackTrace::isLocked):
1212         (Inspector::AsyncStackTrace::willDispatchAsyncCall):
1213         (Inspector::AsyncStackTrace::didDispatchAsyncCall):
1214         (Inspector::AsyncStackTrace::didCancelAsyncCall):
1215         (Inspector::AsyncStackTrace::buildInspectorObject):
1216         (Inspector::AsyncStackTrace::truncate):
1217         (Inspector::AsyncStackTrace::remove):
1218         * inspector/AsyncStackTrace.h:
1219         * inspector/agents/InspectorDebuggerAgent.cpp:
1220         (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
1221         (Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
1222         (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
1223         (Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
1224         (Inspector::InspectorDebuggerAgent::didPause):
1225         (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
1226         (Inspector::InspectorDebuggerAgent::buildAsyncStackTrace): Deleted.
1227         (Inspector::InspectorDebuggerAgent::refAsyncCallData): Deleted.
1228         (Inspector::InspectorDebuggerAgent::derefAsyncCallData): Deleted.
1229         * inspector/agents/InspectorDebuggerAgent.h:
1230         * inspector/protocol/Console.json:
1231
1232 2017-01-28  Joseph Pecoraro  <pecoraro@apple.com>
1233
1234         Remote Inspector: Listing should be updated when a target gains or loses a debugger session
1235         https://bugs.webkit.org/show_bug.cgi?id=167449
1236
1237         Reviewed by Brian Burg.
1238
1239         * inspector/remote/RemoteInspector.h:
1240         * inspector/remote/RemoteInspector.mm:
1241         (Inspector::RemoteInspector::setupFailed):
1242         (Inspector::RemoteInspector::updateTargetListing):
1243         (Inspector::RemoteInspector::receivedSetupMessage):
1244         (Inspector::RemoteInspector::receivedDidCloseMessage):
1245         (Inspector::RemoteInspector::receivedConnectionDiedMessage):
1246         Whenever we add/remove a connection we should update the listing properties
1247         for that target that corresponded to that connection. In this way group
1248         updating active sessions, the target, and pushing listing together.
1249
1250 2017-01-27  Yusuke Suzuki  <utatane.tea@gmail.com>
1251
1252         Lift template escape sequence restrictions in tagged templates
1253         https://bugs.webkit.org/show_bug.cgi?id=166871
1254
1255         Reviewed by Saam Barati.
1256
1257         This patch implements stage 3 Lifting Template Literal Restriction[1].
1258         Prior to this patch, template literal becomes syntax error if it contains
1259         invalid escape sequences. But it is too restricted; Template literal
1260         can have cooked and raw representations and only cooked representation
1261         can escape sequences. So even if invalid escape sequences are included,
1262         the raw representation can be valid.
1263
1264         Lifting Template Literal Restriction relaxes the above restriction.
1265         When invalid escape sequence is included, if target template literals
1266         are used as tagged templates, we make the result of the template including
1267         the invalid escape sequence `undefined` instead of making it SyntaxError
1268         immediately. It allows us to accept the templates including invalid
1269         escape sequences in the raw representations in tagged templates.
1270
1271         On the other hand, the raw representation is only used in tagged templates.
1272         So if invalid escape sequences are included in the usual template literals,
1273         we just make it SyntaxError as before.
1274
1275         [1]: https://github.com/tc39/proposal-template-literal-revision
1276
1277         * bytecompiler/BytecodeGenerator.cpp:
1278         (JSC::BytecodeGenerator::emitGetTemplateObject):
1279         * bytecompiler/NodesCodegen.cpp:
1280         (JSC::TemplateStringNode::emitBytecode):
1281         (JSC::TemplateLiteralNode::emitBytecode):
1282         * parser/ASTBuilder.h:
1283         (JSC::ASTBuilder::createTemplateString):
1284         * parser/Lexer.cpp:
1285         (JSC::Lexer<CharacterType>::parseUnicodeEscape):
1286         (JSC::Lexer<T>::parseTemplateLiteral):
1287         (JSC::Lexer<T>::lex):
1288         (JSC::Lexer<T>::scanTemplateString):
1289         (JSC::Lexer<T>::scanTrailingTemplateString): Deleted.
1290         * parser/Lexer.h:
1291         * parser/NodeConstructors.h:
1292         (JSC::TemplateStringNode::TemplateStringNode):
1293         * parser/Nodes.h:
1294         (JSC::TemplateStringNode::cooked):
1295         (JSC::TemplateStringNode::raw):
1296         * parser/Parser.cpp:
1297         (JSC::Parser<LexerType>::parseAssignmentElement):
1298         (JSC::Parser<LexerType>::parseTemplateString):
1299         (JSC::Parser<LexerType>::parseTemplateLiteral):
1300         (JSC::Parser<LexerType>::parsePrimaryExpression):
1301         (JSC::Parser<LexerType>::parseMemberExpression):
1302         * parser/ParserTokens.h:
1303         * parser/SyntaxChecker.h:
1304         (JSC::SyntaxChecker::createTemplateString):
1305         * runtime/TemplateRegistry.cpp:
1306         (JSC::TemplateRegistry::getTemplateObject):
1307         * runtime/TemplateRegistryKey.h:
1308         (JSC::TemplateRegistryKey::cookedStrings):
1309         (JSC::TemplateRegistryKey::create):
1310         (JSC::TemplateRegistryKey::TemplateRegistryKey):
1311         * runtime/TemplateRegistryKeyTable.cpp:
1312         (JSC::TemplateRegistryKeyTable::createKey):
1313         * runtime/TemplateRegistryKeyTable.h:
1314
1315 2017-01-27  Saam Barati  <sbarati@apple.com>
1316
1317         Make the CLI for the sampling profiler better for inlined call site indices
1318         https://bugs.webkit.org/show_bug.cgi?id=167482
1319
1320         Reviewed by Mark Lam.
1321
1322         This patches changes the command line interface for the sampling
1323         profiler to also dump the machine frame that the semantic code
1324         origin is in if the semantic code origin is inlined. This helps
1325         when doing performance work because it's helpful to know the
1326         context that an inlined frame is in. Before, we used to just
1327         say it was in the baseline JIT if it didn't have its own optimized
1328         compile. Now, we can tell that its inlined into a DFG or FTL frame.
1329
1330         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1331         (Inspector::buildSamples):
1332         * runtime/Options.h:
1333         * runtime/SamplingProfiler.cpp:
1334         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1335         (JSC::SamplingProfiler::reportTopFunctions):
1336         (JSC::SamplingProfiler::reportTopBytecodes):
1337         * runtime/SamplingProfiler.h:
1338         (JSC::SamplingProfiler::StackFrame::CodeLocation::hasCodeBlockHash):
1339         (JSC::SamplingProfiler::StackFrame::CodeLocation::hasBytecodeIndex):
1340         (JSC::SamplingProfiler::StackFrame::CodeLocation::hasExpressionInfo):
1341         (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
1342         (JSC::SamplingProfiler::StackFrame::lineNumber):
1343         (JSC::SamplingProfiler::StackFrame::columnNumber):
1344         (JSC::SamplingProfiler::StackFrame::hasBytecodeIndex): Deleted.
1345         (JSC::SamplingProfiler::StackFrame::hasCodeBlockHash): Deleted.
1346
1347 2017-01-27  Yusuke Suzuki  <utatane.tea@gmail.com>
1348
1349         Extend create_hash_table to specify Intrinsic
1350         https://bugs.webkit.org/show_bug.cgi?id=167505
1351
1352         Reviewed by Sam Weinig.
1353
1354         This patch extends create_hash_table to specify Intrinsic.
1355         We can set Intrinsic in the static property table definition
1356         in runtime/XXX.h.
1357
1358         And drop the adhoc code for String.fromCharCode in create_hash_table.
1359
1360         * create_hash_table:
1361         * runtime/StringConstructor.cpp:
1362
1363 2017-01-27  Filip Pizlo  <fpizlo@apple.com>
1364
1365         scanExternalRememberedSet needs to mergeIfNecessary
1366         https://bugs.webkit.org/show_bug.cgi?id=167523
1367
1368         Reviewed by Keith Miller.
1369         
1370         The protocol for opaque roots is that if you add to them outside of draining, then you need to call
1371         mergeIfNecessary.
1372         
1373         This means that every MarkingConstraint that adds opaque roots needs to mergeIfNecessary after.
1374         
1375         scanExternalRememberedSet transitively calls addOpaqueRoot, is called from a MarkingConstraint, and
1376         was missing a call to mergeIfNecessary. This fixes it.
1377
1378         * API/JSVirtualMachine.mm:
1379         (scanExternalRememberedSet):
1380
1381 2017-01-27  Carlos Garcia Campos  <cgarcia@igalia.com>
1382
1383         Unreviewed. Fix GTK+ debug build after r211247.
1384
1385         * heap/GCAssertions.h:
1386
1387 2017-01-26  Keith Miller  <keith_miller@apple.com>
1388
1389         classInfo should take a VM so it is not materialized from the object on each call
1390         https://bugs.webkit.org/show_bug.cgi?id=167424
1391
1392         Rubber Stamped by Michael Saboff.
1393
1394         Previously, classInfo() would get the VM from the target's
1395         MarkedBlock.  Most callers already have a VM on hand, so it is
1396         wasteful to compute the VM from the marked block every time. This
1397         patch refactors some of the most common callers of classInfo(),
1398         jsDynamicCast and inherits to take a VM as well.
1399
1400         * API/JSCallbackConstructor.cpp:
1401         (JSC::JSCallbackConstructor::finishCreation):
1402         * API/JSCallbackFunction.cpp:
1403         (JSC::JSCallbackFunction::finishCreation):
1404         * API/JSCallbackObjectFunctions.h:
1405         (JSC::JSCallbackObject<Parent>::asCallbackObject):
1406         (JSC::JSCallbackObject<Parent>::finishCreation):
1407         * API/JSObjectRef.cpp:
1408         (JSObjectSetPrototype):
1409         (classInfoPrivate):
1410         (JSObjectGetPrivate):
1411         (JSObjectSetPrivate):
1412         (JSObjectGetPrivateProperty):
1413         (JSObjectSetPrivateProperty):
1414         (JSObjectDeletePrivateProperty):
1415         * API/JSTypedArray.cpp:
1416         (JSValueGetTypedArrayType):
1417         (JSObjectMakeTypedArrayWithArrayBuffer):
1418         (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
1419         (JSObjectGetTypedArrayBytesPtr):
1420         (JSObjectGetTypedArrayLength):
1421         (JSObjectGetTypedArrayByteLength):
1422         (JSObjectGetTypedArrayByteOffset):
1423         (JSObjectGetTypedArrayBuffer):
1424         (JSObjectGetArrayBufferBytesPtr):
1425         (JSObjectGetArrayBufferByteLength):
1426         * API/JSValue.mm:
1427         (isDate):
1428         (isArray):
1429         (valueToObjectWithoutCopy):
1430         * API/JSValueRef.cpp:
1431         (JSValueIsArray):
1432         (JSValueIsDate):
1433         (JSValueIsObjectOfClass):
1434         * API/JSWeakObjectMapRefPrivate.cpp:
1435         * API/JSWrapperMap.mm:
1436         (tryUnwrapObjcObject):
1437         * API/ObjCCallbackFunction.h:
1438         * API/ObjCCallbackFunction.mm:
1439         (tryUnwrapConstructor):
1440         * bindings/ScriptFunctionCall.cpp:
1441         (Deprecated::ScriptFunctionCall::call):
1442         * bytecode/CallVariant.h:
1443         (JSC::CallVariant::internalFunction):
1444         (JSC::CallVariant::function):
1445         (JSC::CallVariant::isClosureCall):
1446         (JSC::CallVariant::executable):
1447         (JSC::CallVariant::functionExecutable):
1448         (JSC::CallVariant::nativeExecutable):
1449         * bytecode/CodeBlock.cpp:
1450         (JSC::CodeBlock::finishCreation):
1451         (JSC::CodeBlock::setConstantRegisters):
1452         (JSC::CodeBlock::replacement):
1453         (JSC::CodeBlock::computeCapabilityLevel):
1454         (JSC::CodeBlock::nameForRegister):
1455         * bytecode/ObjectAllocationProfile.h:
1456         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
1457         * bytecode/ObjectPropertyCondition.cpp:
1458         (JSC::ObjectPropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
1459         * bytecode/ObjectPropertyCondition.h:
1460         (JSC::ObjectPropertyCondition::isValidValueForPresence):
1461         * bytecode/PropertyCondition.cpp:
1462         (JSC::PropertyCondition::isValidValueForAttributes):
1463         (JSC::PropertyCondition::isValidValueForPresence):
1464         (JSC::PropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
1465         * bytecode/PropertyCondition.h:
1466         * bytecode/SpeculatedType.cpp:
1467         (JSC::speculationFromCell):
1468         * debugger/Debugger.cpp:
1469         * debugger/DebuggerCallFrame.cpp:
1470         (JSC::DebuggerCallFrame::functionName):
1471         (JSC::DebuggerCallFrame::scope):
1472         (JSC::DebuggerCallFrame::type):
1473         * debugger/DebuggerScope.cpp:
1474         (JSC::DebuggerScope::name):
1475         (JSC::DebuggerScope::location):
1476         * dfg/DFGAbstractInterpreter.h:
1477         * dfg/DFGAbstractInterpreterInlines.h:
1478         (JSC::DFG::AbstractInterpreter<AbstractStateType>::AbstractInterpreter):
1479         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1480         * dfg/DFGByteCodeParser.cpp:
1481         (JSC::DFG::ByteCodeParser::get):
1482         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1483         (JSC::DFG::ByteCodeParser::planLoad):
1484         (JSC::DFG::ByteCodeParser::checkPresenceLike):
1485         (JSC::DFG::ByteCodeParser::load):
1486         (JSC::DFG::ByteCodeParser::parseBlock):
1487         * dfg/DFGConstantFoldingPhase.cpp:
1488         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1489         * dfg/DFGDesiredWeakReferences.cpp:
1490         (JSC::DFG::DesiredWeakReferences::reallyAdd):
1491         * dfg/DFGFixupPhase.cpp:
1492         (JSC::DFG::FixupPhase::fixupMakeRope):
1493         * dfg/DFGFrozenValue.h:
1494         (JSC::DFG::FrozenValue::FrozenValue):
1495         (JSC::DFG::FrozenValue::dynamicCast):
1496         * dfg/DFGGraph.cpp:
1497         (JSC::DFG::Graph::dump):
1498         (JSC::DFG::Graph::tryGetConstantClosureVar):
1499         (JSC::DFG::Graph::tryGetFoldableView):
1500         (JSC::DFG::Graph::getRegExpPrototypeProperty):
1501         (JSC::DFG::Graph::isStringPrototypeMethodSane):
1502         (JSC::DFG::Graph::canOptimizeStringObjectAccess):
1503         * dfg/DFGLazyJSValue.cpp:
1504         (JSC::DFG::LazyJSValue::tryGetStringImpl):
1505         (JSC::DFG::LazyJSValue::tryGetString):
1506         * dfg/DFGLazyJSValue.h:
1507         * dfg/DFGNode.cpp:
1508         (JSC::DFG::Node::convertToPutStructureHint):
1509         * dfg/DFGNode.h:
1510         (JSC::DFG::Node::dynamicCastConstant):
1511         (JSC::DFG::Node::castConstant):
1512         * dfg/DFGOperations.cpp:
1513         * dfg/DFGSafeToExecute.h:
1514         (JSC::DFG::safeToExecute):
1515         * dfg/DFGSpeculativeJIT.cpp:
1516         (JSC::DFG::SpeculativeJIT::compileIn):
1517         (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
1518         * dfg/DFGSpeculativeJIT32_64.cpp:
1519         (JSC::DFG::SpeculativeJIT::emitCall):
1520         (JSC::DFG::SpeculativeJIT::compile):
1521         * dfg/DFGSpeculativeJIT64.cpp:
1522         (JSC::DFG::SpeculativeJIT::emitCall):
1523         (JSC::DFG::SpeculativeJIT::compile):
1524         * dfg/DFGStrengthReductionPhase.cpp:
1525         (JSC::DFG::StrengthReductionPhase::handleNode):
1526         * ftl/FTLLowerDFGToB3.cpp:
1527         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
1528         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
1529         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
1530         (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
1531         * ftl/FTLOperations.cpp:
1532         (JSC::FTL::operationMaterializeObjectInOSR):
1533         * heap/CodeBlockSet.cpp:
1534         (JSC::CodeBlockSet::lastChanceToFinalize):
1535         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
1536         * heap/CodeBlockSet.h:
1537         * heap/GCAssertions.h:
1538         * heap/Heap.cpp:
1539         (JSC::Heap::lastChanceToFinalize):
1540         (JSC::Heap::protectedObjectTypeCounts):
1541         (JSC::Heap::objectTypeCounts):
1542         (JSC::Heap::deleteUnmarkedCompiledCode):
1543         * heap/HeapSnapshotBuilder.cpp:
1544         (JSC::HeapSnapshotBuilder::json):
1545         * heap/SlotVisitor.cpp:
1546         (JSC::validate):
1547         * inspector/InjectedScriptHost.h:
1548         * inspector/JSGlobalObjectInspectorController.cpp:
1549         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
1550         * inspector/JSInjectedScriptHost.cpp:
1551         (Inspector::JSInjectedScriptHost::finishCreation):
1552         (Inspector::JSInjectedScriptHost::isHTMLAllCollection):
1553         (Inspector::JSInjectedScriptHost::subtype):
1554         (Inspector::JSInjectedScriptHost::functionDetails):
1555         (Inspector::JSInjectedScriptHost::getInternalProperties):
1556         (Inspector::JSInjectedScriptHost::proxyTargetValue):
1557         (Inspector::JSInjectedScriptHost::weakMapSize):
1558         (Inspector::JSInjectedScriptHost::weakMapEntries):
1559         (Inspector::JSInjectedScriptHost::weakSetSize):
1560         (Inspector::JSInjectedScriptHost::weakSetEntries):
1561         (Inspector::JSInjectedScriptHost::iteratorEntries):
1562         * inspector/JSInjectedScriptHostPrototype.cpp:
1563         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1564         (Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
1565         (Inspector::jsInjectedScriptHostPrototypeFunctionInternalConstructorName):
1566         (Inspector::jsInjectedScriptHostPrototypeFunctionIsHTMLAllCollection):
1567         (Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
1568         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
1569         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
1570         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
1571         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
1572         (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
1573         (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
1574         (Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
1575         (Inspector::jsInjectedScriptHostPrototypeFunctionFunctionDetails):
1576         (Inspector::jsInjectedScriptHostPrototypeFunctionGetInternalProperties):
1577         * inspector/JSJavaScriptCallFrame.cpp:
1578         (Inspector::JSJavaScriptCallFrame::finishCreation):
1579         (Inspector::toJSJavaScriptCallFrame): Deleted.
1580         * inspector/JSJavaScriptCallFrame.h:
1581         * inspector/JSJavaScriptCallFramePrototype.cpp:
1582         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
1583         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
1584         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
1585         (Inspector::jsJavaScriptCallFrameAttributeCaller):
1586         (Inspector::jsJavaScriptCallFrameAttributeSourceID):
1587         (Inspector::jsJavaScriptCallFrameAttributeLine):
1588         (Inspector::jsJavaScriptCallFrameAttributeColumn):
1589         (Inspector::jsJavaScriptCallFrameAttributeFunctionName):
1590         (Inspector::jsJavaScriptCallFrameAttributeScopeChain):
1591         (Inspector::jsJavaScriptCallFrameAttributeThisObject):
1592         (Inspector::jsJavaScriptCallFrameAttributeType):
1593         (Inspector::jsJavaScriptCallFrameIsTailDeleted):
1594         * inspector/ScriptArguments.cpp:
1595         (Inspector::ScriptArguments::getFirstArgumentAsString):
1596         * inspector/agents/InspectorHeapAgent.cpp:
1597         (Inspector::InspectorHeapAgent::getPreview):
1598         * interpreter/Interpreter.cpp:
1599         (JSC::notifyDebuggerOfUnwinding):
1600         (JSC::Interpreter::unwind):
1601         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
1602         (JSC::Interpreter::execute):
1603         * interpreter/ShadowChicken.cpp:
1604         (JSC::ShadowChicken::update):
1605         * interpreter/StackVisitor.cpp:
1606         (JSC::StackVisitor::readFrame):
1607         (JSC::StackVisitor::readNonInlinedFrame):
1608         (JSC::StackVisitor::Frame::calleeSaveRegisters):
1609         * jit/JITCode.cpp:
1610         (JSC::JITCode::execute):
1611         * jit/JITOperations.cpp:
1612         (JSC::operationNewFunctionCommon):
1613         * jit/Repatch.cpp:
1614         (JSC::tryCacheGetByID):
1615         * jsc.cpp:
1616         (WTF::CustomGetter::customGetter):
1617         (WTF::RuntimeArray::finishCreation):
1618         (WTF::RuntimeArray::lengthGetter):
1619         (WTF::DOMJITGetter::customGetter):
1620         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
1621         (WTF::DOMJITGetterComplex::functionEnableException):
1622         (WTF::DOMJITGetterComplex::customGetter):
1623         (WTF::DOMJITFunctionObject::safeFunction):
1624         (functionDescribeArray):
1625         (functionCreateElement):
1626         (functionGetElement):
1627         (functionSetElementRoot):
1628         (functionGetHiddenValue):
1629         (functionSetHiddenValue):
1630         (functionSetImpureGetterDelegate):
1631         (functionNoFTL):
1632         (functionDollarEvalScript):
1633         (functionDollarAgentBroadcast):
1634         (functionTransferArrayBuffer):
1635         (functionFindTypeForExpression):
1636         (functionReturnTypeFor):
1637         (functionHasBasicBlockExecuted):
1638         (functionBasicBlockExecutionCount):
1639         (functionEnsureArrayStorage):
1640         * llint/LLIntSlowPaths.cpp:
1641         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1642         * runtime/AbstractModuleRecord.cpp:
1643         (JSC::AbstractModuleRecord::finishCreation):
1644         * runtime/ArrayBuffer.cpp:
1645         (JSC::ArrayBuffer::transferTo):
1646         * runtime/ArrayBuffer.h:
1647         * runtime/ArrayConstructor.cpp:
1648         (JSC::ArrayConstructor::finishCreation):
1649         (JSC::arrayConstructorPrivateFuncIsArraySlow):
1650         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
1651         * runtime/ArrayConstructor.h:
1652         (JSC::isArrayConstructor): Deleted.
1653         * runtime/ArrayIteratorPrototype.cpp:
1654         (JSC::ArrayIteratorPrototype::finishCreation):
1655         * runtime/ArrayPrototype.cpp:
1656         (JSC::ArrayPrototype::finishCreation):
1657         * runtime/AsyncFunctionPrototype.cpp:
1658         (JSC::AsyncFunctionPrototype::finishCreation):
1659         * runtime/AtomicsObject.cpp:
1660         (JSC::AtomicsObject::finishCreation):
1661         (JSC::atomicsFuncWait):
1662         (JSC::atomicsFuncWake):
1663         * runtime/BooleanObject.cpp:
1664         (JSC::BooleanObject::finishCreation):
1665         * runtime/BooleanObject.h:
1666         (JSC::asBooleanObject):
1667         * runtime/BooleanPrototype.cpp:
1668         (JSC::BooleanPrototype::finishCreation):
1669         (JSC::booleanProtoFuncToString):
1670         (JSC::booleanProtoFuncValueOf):
1671         * runtime/ConsoleObject.cpp:
1672         (JSC::ConsoleObject::finishCreation):
1673         * runtime/DateConstructor.cpp:
1674         (JSC::constructDate):
1675         * runtime/DateInstance.cpp:
1676         (JSC::DateInstance::finishCreation):
1677         * runtime/DateInstance.h:
1678         (JSC::asDateInstance):
1679         * runtime/DatePrototype.cpp:
1680         (JSC::formateDateInstance):
1681         (JSC::DatePrototype::finishCreation):
1682         (JSC::dateProtoFuncToISOString):
1683         (JSC::dateProtoFuncToLocaleString):
1684         (JSC::dateProtoFuncToLocaleDateString):
1685         (JSC::dateProtoFuncToLocaleTimeString):
1686         (JSC::dateProtoFuncGetTime):
1687         (JSC::dateProtoFuncGetFullYear):
1688         (JSC::dateProtoFuncGetUTCFullYear):
1689         (JSC::dateProtoFuncGetMonth):
1690         (JSC::dateProtoFuncGetUTCMonth):
1691         (JSC::dateProtoFuncGetDate):
1692         (JSC::dateProtoFuncGetUTCDate):
1693         (JSC::dateProtoFuncGetDay):
1694         (JSC::dateProtoFuncGetUTCDay):
1695         (JSC::dateProtoFuncGetHours):
1696         (JSC::dateProtoFuncGetUTCHours):
1697         (JSC::dateProtoFuncGetMinutes):
1698         (JSC::dateProtoFuncGetUTCMinutes):
1699         (JSC::dateProtoFuncGetSeconds):
1700         (JSC::dateProtoFuncGetUTCSeconds):
1701         (JSC::dateProtoFuncGetMilliSeconds):
1702         (JSC::dateProtoFuncGetUTCMilliseconds):
1703         (JSC::dateProtoFuncGetTimezoneOffset):
1704         (JSC::dateProtoFuncSetTime):
1705         (JSC::setNewValueFromTimeArgs):
1706         (JSC::setNewValueFromDateArgs):
1707         (JSC::dateProtoFuncSetYear):
1708         (JSC::dateProtoFuncGetYear):
1709         * runtime/ErrorInstance.cpp:
1710         (JSC::ErrorInstance::finishCreation):
1711         * runtime/ErrorPrototype.cpp:
1712         (JSC::ErrorPrototype::finishCreation):
1713         * runtime/ExceptionHelpers.cpp:
1714         (JSC::isTerminatedExecutionException):
1715         * runtime/ExceptionHelpers.h:
1716         * runtime/ExecutableBase.cpp:
1717         (JSC::ExecutableBase::clearCode):
1718         (JSC::ExecutableBase::dump):
1719         (JSC::ExecutableBase::hashFor):
1720         * runtime/FunctionPrototype.cpp:
1721         (JSC::functionProtoFuncToString):
1722         * runtime/GeneratorFunctionPrototype.cpp:
1723         (JSC::GeneratorFunctionPrototype::finishCreation):
1724         * runtime/GeneratorPrototype.cpp:
1725         (JSC::GeneratorPrototype::finishCreation):
1726         * runtime/GetterSetter.h:
1727         * runtime/InspectorInstrumentationObject.cpp:
1728         (JSC::InspectorInstrumentationObject::finishCreation):
1729         * runtime/InternalFunction.cpp:
1730         (JSC::InternalFunction::finishCreation):
1731         (JSC::InternalFunction::createSubclassStructure):
1732         * runtime/InternalFunction.h:
1733         (JSC::asInternalFunction):
1734         * runtime/IntlCollator.cpp:
1735         (JSC::IntlCollator::finishCreation):
1736         * runtime/IntlCollatorPrototype.cpp:
1737         (JSC::IntlCollatorPrototypeGetterCompare):
1738         (JSC::IntlCollatorPrototypeFuncResolvedOptions):
1739         * runtime/IntlDateTimeFormat.cpp:
1740         (JSC::IntlDateTimeFormat::finishCreation):
1741         * runtime/IntlDateTimeFormatPrototype.cpp:
1742         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1743         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
1744         * runtime/IntlNumberFormat.cpp:
1745         (JSC::IntlNumberFormat::finishCreation):
1746         * runtime/IntlNumberFormatPrototype.cpp:
1747         (JSC::IntlNumberFormatPrototypeGetterFormat):
1748         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
1749         * runtime/IntlObject.cpp:
1750         (JSC::IntlObject::finishCreation):
1751         * runtime/IntlObjectInlines.h:
1752         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
1753         * runtime/IteratorPrototype.cpp:
1754         (JSC::IteratorPrototype::finishCreation):
1755         * runtime/JSArray.h:
1756         (JSC::asArray):
1757         (JSC::isJSArray):
1758         * runtime/JSArrayBuffer.h:
1759         (JSC::toPossiblySharedArrayBuffer):
1760         (JSC::toUnsharedArrayBuffer):
1761         (JSC::JSArrayBuffer::toWrapped):
1762         * runtime/JSArrayBufferConstructor.cpp:
1763         (JSC::arrayBufferFuncIsView):
1764         * runtime/JSArrayBufferPrototype.cpp:
1765         (JSC::arrayBufferProtoFuncSlice):
1766         * runtime/JSArrayBufferView.h:
1767         * runtime/JSArrayBufferViewInlines.h:
1768         (JSC::JSArrayBufferView::toWrapped):
1769         * runtime/JSBoundFunction.cpp:
1770         (JSC::isBoundFunction):
1771         (JSC::getBoundFunctionStructure):
1772         (JSC::JSBoundFunction::finishCreation):
1773         * runtime/JSCJSValue.cpp:
1774         (JSC::JSValue::dumpForBacktrace):
1775         * runtime/JSCJSValue.h:
1776         * runtime/JSCJSValueInlines.h:
1777         (JSC::JSValue::inherits):
1778         (JSC::JSValue::classInfoOrNull):
1779         * runtime/JSCallee.cpp:
1780         (JSC::JSCallee::finishCreation):
1781         * runtime/JSCell.cpp:
1782         (JSC::JSCell::dumpToStream):
1783         (JSC::JSCell::className):
1784         (JSC::JSCell::isAnyWasmCallee):
1785         * runtime/JSCell.h:
1786         (JSC::jsCast):
1787         (JSC::jsDynamicCast):
1788         * runtime/JSCellInlines.h:
1789         (JSC::JSCell::methodTable):
1790         (JSC::JSCell::inherits):
1791         (JSC::JSCell::classInfo):
1792         * runtime/JSCustomGetterSetterFunction.cpp:
1793         (JSC::JSCustomGetterSetterFunction::finishCreation):
1794         * runtime/JSDataViewPrototype.cpp:
1795         (JSC::getData):
1796         (JSC::setData):
1797         (JSC::dataViewProtoGetterBuffer):
1798         (JSC::dataViewProtoGetterByteLength):
1799         (JSC::dataViewProtoGetterByteOffset):
1800         * runtime/JSFunction.cpp:
1801         (JSC::JSFunction::finishCreation):
1802         (JSC::JSFunction::allocateAndInitializeRareData):
1803         (JSC::JSFunction::initializeRareData):
1804         (JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
1805         (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
1806         (JSC::RetrieveCallerFunctionFunctor::operator()):
1807         (JSC::JSFunction::callerGetter):
1808         (JSC::JSFunction::getOwnNonIndexPropertyNames):
1809         (JSC::getCalculatedDisplayName):
1810         (JSC::JSFunction::reifyBoundNameIfNeeded):
1811         * runtime/JSGenericTypedArrayView.h:
1812         (JSC::toPossiblySharedNativeTypedView):
1813         (JSC::toUnsharedNativeTypedView):
1814         (JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
1815         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1816         (JSC::constructGenericTypedArrayViewWithArguments):
1817         (JSC::constructGenericTypedArrayView):
1818         * runtime/JSGenericTypedArrayViewInlines.h:
1819         (JSC::JSGenericTypedArrayView<Adaptor>::set):
1820         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1821         (JSC::speciesConstruct):
1822         (JSC::genericTypedArrayViewProtoFuncSet):
1823         (JSC::genericTypedArrayViewProtoFuncSlice):
1824         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
1825         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1826         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1827         * runtime/JSGlobalObject.cpp:
1828         (JSC::getTemplateObject):
1829         (JSC::enqueueJob):
1830         (JSC::JSGlobalObject::init):
1831         * runtime/JSGlobalObjectFunctions.cpp:
1832         (JSC::globalFuncProtoGetter):
1833         (JSC::globalFuncProtoSetter):
1834         * runtime/JSInternalPromiseDeferred.cpp:
1835         (JSC::JSInternalPromiseDeferred::create):
1836         * runtime/JSLexicalEnvironment.h:
1837         (JSC::asActivation):
1838         * runtime/JSModuleLoader.cpp:
1839         (JSC::JSModuleLoader::finishCreation):
1840         (JSC::JSModuleLoader::evaluate):
1841         (JSC::JSModuleLoader::getModuleNamespaceObject):
1842         * runtime/JSModuleNamespaceObject.cpp:
1843         (JSC::JSModuleNamespaceObject::finishCreation):
1844         (JSC::moduleNamespaceObjectSymbolIterator):
1845         * runtime/JSModuleRecord.cpp:
1846         (JSC::JSModuleRecord::finishCreation):
1847         * runtime/JSNativeStdFunction.cpp:
1848         (JSC::JSNativeStdFunction::finishCreation):
1849         * runtime/JSONObject.cpp:
1850         (JSC::JSONObject::finishCreation):
1851         (JSC::unwrapBoxedPrimitive):
1852         (JSC::Stringifier::Stringifier):
1853         (JSC::Walker::walk):
1854         * runtime/JSObject.cpp:
1855         (JSC::JSObject::className):
1856         (JSC::JSObject::toStringName):
1857         (JSC::JSObject::calculatedClassName):
1858         (JSC::JSObject::putInlineSlow):
1859         (JSC::JSObject::ensureInt32Slow):
1860         (JSC::JSObject::ensureDoubleSlow):
1861         (JSC::JSObject::ensureContiguousSlow):
1862         (JSC::JSObject::ensureArrayStorageSlow):
1863         (JSC::JSObject::deleteProperty):
1864         (JSC::JSObject::getOwnStaticPropertySlot):
1865         (JSC::JSObject::findPropertyHashEntry):
1866         (JSC::JSObject::getOwnNonIndexPropertyNames):
1867         (JSC::JSObject::reifyAllStaticProperties):
1868         (JSC::JSObject::getOwnPropertyDescriptor):
1869         * runtime/JSObject.h:
1870         (JSC::JSObject::finishCreation):
1871         (JSC::JSNonFinalObject::finishCreation):
1872         (JSC::JSFinalObject::finishCreation):
1873         * runtime/JSPromiseDeferred.cpp:
1874         (JSC::JSPromiseDeferred::create):
1875         * runtime/JSPropertyNameIterator.cpp:
1876         (JSC::JSPropertyNameIterator::finishCreation):
1877         (JSC::propertyNameIteratorFuncNext):
1878         * runtime/JSScope.cpp:
1879         (JSC::JSScope::symbolTable):
1880         * runtime/JSScope.h:
1881         * runtime/JSString.cpp:
1882         (JSC::JSString::dumpToStream):
1883         * runtime/JSStringIterator.cpp:
1884         (JSC::JSStringIterator::finishCreation):
1885         * runtime/JSTypedArrayViewPrototype.cpp:
1886         (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
1887         (JSC::typedArrayViewPrivateFuncLength):
1888         (JSC::typedArrayViewPrivateFuncGetOriginalConstructor):
1889         (JSC::typedArrayViewProtoGetterFuncToStringTag):
1890         (JSC::JSTypedArrayViewPrototype::finishCreation):
1891         * runtime/LazyClassStructure.cpp:
1892         (JSC::LazyClassStructure::Initializer::setConstructor):
1893         * runtime/Lookup.h:
1894         (JSC::putEntry):
1895         * runtime/MapConstructor.cpp:
1896         (JSC::MapConstructor::finishCreation):
1897         * runtime/MapIteratorPrototype.cpp:
1898         (JSC::MapIteratorPrototype::finishCreation):
1899         (JSC::MapIteratorPrototypeFuncNext):
1900         * runtime/MapPrototype.cpp:
1901         (JSC::MapPrototype::finishCreation):
1902         (JSC::mapProtoFuncValues):
1903         (JSC::mapProtoFuncEntries):
1904         (JSC::mapProtoFuncKeys):
1905         (JSC::privateFuncMapIterator):
1906         (JSC::privateFuncMapIteratorNext):
1907         * runtime/MathObject.cpp:
1908         (JSC::MathObject::finishCreation):
1909         * runtime/ModuleLoaderPrototype.cpp:
1910         (JSC::moduleLoaderPrototypeParseModule):
1911         (JSC::moduleLoaderPrototypeRequestedModules):
1912         (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
1913         (JSC::moduleLoaderPrototypeResolve):
1914         (JSC::moduleLoaderPrototypeFetch):
1915         (JSC::moduleLoaderPrototypeInstantiate):
1916         (JSC::moduleLoaderPrototypeGetModuleNamespaceObject):
1917         (JSC::moduleLoaderPrototypeEvaluate):
1918         * runtime/NativeErrorConstructor.cpp:
1919         (JSC::NativeErrorConstructor::finishCreation):
1920         * runtime/NumberConstructor.cpp:
1921         (JSC::NumberConstructor::finishCreation):
1922         * runtime/NumberObject.cpp:
1923         (JSC::NumberObject::finishCreation):
1924         * runtime/NumberPrototype.cpp:
1925         (JSC::NumberPrototype::finishCreation):
1926         * runtime/ObjectConstructor.cpp:
1927         (JSC::ObjectConstructor::finishCreation):
1928         * runtime/ObjectPrototype.cpp:
1929         (JSC::ObjectPrototype::finishCreation):
1930         * runtime/ProxyObject.cpp:
1931         (JSC::ProxyObject::toStringName):
1932         (JSC::ProxyObject::finishCreation):
1933         * runtime/ReflectObject.cpp:
1934         (JSC::ReflectObject::finishCreation):
1935         (JSC::reflectObjectConstruct):
1936         * runtime/RegExpConstructor.cpp:
1937         (JSC::RegExpConstructor::finishCreation):
1938         (JSC::setRegExpConstructorInput):
1939         (JSC::setRegExpConstructorMultiline):
1940         (JSC::constructRegExp):
1941         * runtime/RegExpConstructor.h:
1942         (JSC::asRegExpConstructor):
1943         (JSC::isRegExp):
1944         * runtime/RegExpObject.cpp:
1945         (JSC::RegExpObject::finishCreation):
1946         * runtime/RegExpObject.h:
1947         (JSC::asRegExpObject):
1948         * runtime/RegExpPrototype.cpp:
1949         (JSC::RegExpPrototype::finishCreation):
1950         (JSC::regExpProtoFuncTestFast):
1951         (JSC::regExpProtoFuncExec):
1952         (JSC::regExpProtoFuncMatchFast):
1953         (JSC::regExpProtoFuncCompile):
1954         (JSC::regExpProtoGetterGlobal):
1955         (JSC::regExpProtoGetterIgnoreCase):
1956         (JSC::regExpProtoGetterMultiline):
1957         (JSC::regExpProtoGetterSticky):
1958         (JSC::regExpProtoGetterUnicode):
1959         (JSC::regExpProtoGetterSource):
1960         * runtime/SamplingProfiler.cpp:
1961         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1962         * runtime/ScriptExecutable.cpp:
1963         (JSC::ScriptExecutable::newCodeBlockFor):
1964         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
1965         * runtime/SetConstructor.cpp:
1966         (JSC::SetConstructor::finishCreation):
1967         * runtime/SetIteratorPrototype.cpp:
1968         (JSC::SetIteratorPrototype::finishCreation):
1969         (JSC::SetIteratorPrototypeFuncNext):
1970         * runtime/SetPrototype.cpp:
1971         (JSC::SetPrototype::finishCreation):
1972         (JSC::setProtoFuncValues):
1973         (JSC::setProtoFuncEntries):
1974         (JSC::privateFuncSetIterator):
1975         (JSC::privateFuncSetIteratorNext):
1976         * runtime/StackFrame.cpp:
1977         (JSC::StackFrame::sourceURL):
1978         (JSC::StackFrame::functionName):
1979         * runtime/StringIteratorPrototype.cpp:
1980         (JSC::StringIteratorPrototype::finishCreation):
1981         * runtime/StringObject.cpp:
1982         (JSC::StringObject::finishCreation):
1983         * runtime/StringObject.h:
1984         (JSC::asStringObject):
1985         * runtime/StringPrototype.cpp:
1986         (JSC::StringPrototype::finishCreation):
1987         (JSC::replace):
1988         (JSC::stringProtoFuncReplaceUsingRegExp):
1989         (JSC::stringProtoFuncToString):
1990         * runtime/StructureRareData.cpp:
1991         (JSC::StructureRareData::setObjectToStringValue):
1992         * runtime/Symbol.cpp:
1993         (JSC::Symbol::finishCreation):
1994         * runtime/SymbolConstructor.cpp:
1995         (JSC::SymbolConstructor::finishCreation):
1996         * runtime/SymbolObject.cpp:
1997         (JSC::SymbolObject::finishCreation):
1998         * runtime/SymbolPrototype.cpp:
1999         (JSC::SymbolPrototype::finishCreation):
2000         (JSC::symbolProtoFuncToString):
2001         (JSC::symbolProtoFuncValueOf):
2002         * runtime/TestRunnerUtils.cpp:
2003         (JSC::getExecutableForFunction):
2004         * runtime/ThrowScope.cpp:
2005         (JSC::ThrowScope::throwException):
2006         * runtime/VM.cpp:
2007         (JSC::VM::throwException):
2008         * runtime/WeakMapConstructor.cpp:
2009         (JSC::WeakMapConstructor::finishCreation):
2010         * runtime/WeakMapPrototype.cpp:
2011         (JSC::WeakMapPrototype::finishCreation):
2012         (JSC::getWeakMapData):
2013         * runtime/WeakSetConstructor.cpp:
2014         (JSC::WeakSetConstructor::finishCreation):
2015         * runtime/WeakSetPrototype.cpp:
2016         (JSC::WeakSetPrototype::finishCreation):
2017         (JSC::getWeakMapData):
2018         * tools/JSDollarVMPrototype.cpp:
2019         (JSC::codeBlockFromArg):
2020         * wasm/JSWebAssembly.cpp:
2021         (JSC::JSWebAssembly::finishCreation):
2022         * wasm/js/JSWebAssemblyHelpers.h:
2023         (JSC::getWasmBufferFromValue):
2024         * wasm/js/JSWebAssemblyInstance.cpp:
2025         (JSC::JSWebAssemblyInstance::finishCreation):
2026         * wasm/js/JSWebAssemblyMemory.cpp:
2027         (JSC::JSWebAssemblyMemory::grow):
2028         (JSC::JSWebAssemblyMemory::finishCreation):
2029         (JSC::JSWebAssemblyMemory::destroy):
2030         (JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory): Deleted.
2031         * wasm/js/JSWebAssemblyMemory.h:
2032         * wasm/js/JSWebAssemblyModule.cpp:
2033         (JSC::JSWebAssemblyModule::finishCreation):
2034         * wasm/js/JSWebAssemblyTable.cpp:
2035         (JSC::JSWebAssemblyTable::finishCreation):
2036         * wasm/js/WebAssemblyFunction.cpp:
2037         (JSC::callWebAssemblyFunction):
2038         (JSC::WebAssemblyFunction::finishCreation):
2039         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2040         (JSC::constructJSWebAssemblyInstance):
2041         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2042         (JSC::getMemory):
2043         * wasm/js/WebAssemblyModulePrototype.cpp:
2044         (JSC::webAssemblyModuleProtoCustomSections):
2045         * wasm/js/WebAssemblyModuleRecord.cpp:
2046         (JSC::WebAssemblyModuleRecord::finishCreation):
2047         * wasm/js/WebAssemblyTablePrototype.cpp:
2048         (JSC::getTable):
2049         (JSC::webAssemblyTableProtoFuncSet):
2050
2051 2017-01-26  Mark Lam  <mark.lam@apple.com>
2052
2053         Fix missing exception check in genericTypedArrayViewProtoFuncSet().
2054         https://bugs.webkit.org/show_bug.cgi?id=166812
2055         <rdar://problem/29916672>
2056
2057         Reviewed by Saam Barati.
2058
2059         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2060         (JSC::genericTypedArrayViewProtoFuncSet):
2061
2062 2017-01-26  Commit Queue  <commit-queue@webkit.org>
2063
2064         Unreviewed, rolling out r211224.
2065         https://bugs.webkit.org/show_bug.cgi?id=167479
2066
2067         "It was a Kraken performance regression" (Requested by
2068         saamyjoon on #webkit).
2069
2070         Reverted changeset:
2071
2072         "OSR entry: delay outer-loop compilation when at inner-loop"
2073         https://bugs.webkit.org/show_bug.cgi?id=167149
2074         http://trac.webkit.org/changeset/211224
2075
2076 2017-01-26  Saam Barati  <sbarati@apple.com>
2077
2078         Harden how the compiler references GC objects
2079         https://bugs.webkit.org/show_bug.cgi?id=167277
2080         <rdar://problem/30179506>
2081
2082         Reviewed by Filip Pizlo.
2083
2084         Since r210971, the DFG/FTL will flash safepoints before
2085         each phase. This means that there are more opportunities for
2086         a GC to happen while the compiler is running. Because of this,
2087         the compiler must keep track of all the heap pointers that are part
2088         of the Graph data structure. To accomplish this, I've designed
2089         a new type called RegisteredStructure that can only be constructed
2090         after the Graph becomes aware of its underlying Structure*. I
2091         designed this new type to have the type system in C++ help us catch
2092         errors where we're not informing the graph/plan of a heap pointer.
2093         I've made it a compile error to create an OpInfo with a pointer
2094         T* where T inherits from HeapCell. This encourages an OpInfo
2095         to be created with either a FrozenValue* or a RegisteredStructure.
2096         I've added similar compile time assertions for TrustedImmPtr in DFG::SpeculativeJIT
2097         and FTL::Output::constIntPtr. These static asserts don't save us from all bad
2098         programs because there are ways to write code that's incorrect that compiles,
2099         but the new types do help us ensure that the most obvious way of writing the
2100         code is correct.
2101         
2102         The reason this patch is so big is that I've strung RegisteredStructure and
2103         RegisteredStructureSet through the entire DFG/FTL.
2104
2105         * CMakeLists.txt:
2106         * JavaScriptCore.xcodeproj/project.pbxproj:
2107         * bytecode/CodeBlock.cpp:
2108         (JSC::CodeBlock::determineLiveness):
2109         * bytecode/StructureSet.cpp:
2110         (JSC::StructureSet::filter): Deleted.
2111         (JSC::StructureSet::filterArrayModes): Deleted.
2112         (JSC::StructureSet::speculationFromStructures): Deleted.
2113         (JSC::StructureSet::arrayModesFromStructures): Deleted.
2114         (JSC::StructureSet::validateReferences): Deleted.
2115         * bytecode/StructureSet.h:
2116         * dfg/DFGAbstractInterpreter.h:
2117         (JSC::DFG::AbstractInterpreter::filter):
2118         * dfg/DFGAbstractInterpreterInlines.h:
2119         (JSC::DFG::AbstractInterpreter<AbstractStateType>::booleanResult):
2120         (JSC::DFG::isToThisAnIdentity):
2121         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2122         (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition):
2123         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
2124         * dfg/DFGAbstractValue.cpp:
2125         (JSC::DFG::AbstractValue::set):
2126         (JSC::DFG::AbstractValue::setType):
2127         (JSC::DFG::AbstractValue::mergeOSREntryValue):
2128         (JSC::DFG::AbstractValue::filter):
2129         (JSC::DFG::AbstractValue::changeStructure):
2130         (JSC::DFG::AbstractValue::contains):
2131         * dfg/DFGAbstractValue.h:
2132         (JSC::DFG::AbstractValue::observeTransition):
2133         (JSC::DFG::AbstractValue::TransitionObserver::TransitionObserver):
2134         * dfg/DFGArgumentsEliminationPhase.cpp:
2135         * dfg/DFGArrayMode.cpp:
2136         (JSC::DFG::ArrayMode::alreadyChecked):
2137         * dfg/DFGArrayifySlowPathGenerator.h:
2138         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
2139         * dfg/DFGByteCodeParser.cpp:
2140         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2141         (JSC::DFG::ByteCodeParser::load):
2142         (JSC::DFG::ByteCodeParser::handleGetById):
2143         (JSC::DFG::ByteCodeParser::handlePutById):
2144         (JSC::DFG::ByteCodeParser::parseBlock):
2145         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2146         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2147         (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
2148         (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
2149         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
2150         (JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
2151         * dfg/DFGCommonData.cpp:
2152         (JSC::DFG::CommonData::notifyCompilingStructureTransition):
2153         * dfg/DFGConstantFoldingPhase.cpp:
2154         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2155         (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
2156         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
2157         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
2158         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
2159         * dfg/DFGDesiredWeakReferences.cpp:
2160         (JSC::DFG::DesiredWeakReferences::reallyAdd):
2161         * dfg/DFGFixupPhase.cpp:
2162         (JSC::DFG::FixupPhase::checkArray):
2163         * dfg/DFGGraph.cpp:
2164         (JSC::DFG::Graph::Graph):
2165         (JSC::DFG::Graph::dump):
2166         (JSC::DFG::Graph::tryGetConstantProperty):
2167         (JSC::DFG::Graph::inferredValueForProperty):
2168         (JSC::DFG::Graph::visitChildren):
2169         (JSC::DFG::Graph::freeze):
2170         (JSC::DFG::Graph::registerStructure):
2171         (JSC::DFG::Graph::assertIsRegistered):
2172         * dfg/DFGGraph.h:
2173         (JSC::DFG::Graph::registerStructure):
2174         (JSC::DFG::Graph::addStructureSet):
2175         * dfg/DFGJITCompiler.h:
2176         (JSC::DFG::JITCompiler::branchWeakStructure):
2177         * dfg/DFGMultiGetByOffsetData.cpp:
2178         (JSC::DFG::MultiGetByOffsetCase::dumpInContext):
2179         * dfg/DFGMultiGetByOffsetData.h:
2180         (JSC::DFG::MultiGetByOffsetCase::MultiGetByOffsetCase):
2181         (JSC::DFG::MultiGetByOffsetCase::set):
2182         * dfg/DFGNode.cpp:
2183         (JSC::DFG::Node::convertToPutStructureHint):
2184         * dfg/DFGNode.h:
2185         (JSC::DFG::Node::convertToCheckStructure):
2186         (JSC::DFG::Node::structureSet):
2187         (JSC::DFG::Node::structure):
2188         (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
2189         (JSC::DFG::Node::OpInfoWrapper::operator=):
2190         (JSC::DFG::Node::OpInfoWrapper::asRegisteredStructure):
2191         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2192         * dfg/DFGOpInfo.h:
2193         (JSC::DFG::OpInfo::OpInfo):
2194         * dfg/DFGPlan.cpp:
2195         (JSC::DFG::Plan::compileInThreadImpl):
2196         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2197         * dfg/DFGRegisteredStructure.h: Added.
2198         (JSC::DFG::RegisteredStructure::get):
2199         (JSC::DFG::RegisteredStructure::operator->):
2200         (JSC::DFG::RegisteredStructure::operator==):
2201         (JSC::DFG::RegisteredStructure::operator!=):
2202         (JSC::DFG::RegisteredStructure::operator bool):
2203         (JSC::DFG::RegisteredStructure::RegisteredStructure):
2204         (JSC::DFG::RegisteredStructure::createPrivate):
2205         * dfg/DFGRegisteredStructureSet.cpp: Added.
2206         (JSC::DFG::RegisteredStructureSet::filter):
2207         (JSC::DFG::RegisteredStructureSet::filterArrayModes):
2208         (JSC::DFG::RegisteredStructureSet::speculationFromStructures):
2209         (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures):
2210         (JSC::DFG::RegisteredStructureSet::validateReferences):
2211         * dfg/DFGRegisteredStructureSet.h: Added.
2212         (JSC::DFG::RegisteredStructureSet::RegisteredStructureSet):
2213         (JSC::DFG::RegisteredStructureSet::onlyStructure):
2214         (JSC::DFG::RegisteredStructureSet::toStructureSet):
2215         * dfg/DFGSafeToExecute.h:
2216         (JSC::DFG::safeToExecute):
2217         * dfg/DFGSpeculativeJIT.cpp:
2218         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
2219         (JSC::DFG::SpeculativeJIT::emitGetCallee):
2220         (JSC::DFG::SpeculativeJIT::silentFill):
2221         (JSC::DFG::SpeculativeJIT::checkArray):
2222         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2223         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
2224         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
2225         (JSC::DFG::compileClampDoubleToByte):
2226         (JSC::DFG::SpeculativeJIT::compileMakeRope):
2227         (JSC::DFG::SpeculativeJIT::compileArithRounding):
2228         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
2229         (JSC::DFG::SpeculativeJIT::compileNewFunction):
2230         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
2231         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
2232         (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
2233         (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
2234         (JSC::DFG::SpeculativeJIT::compileSpread):
2235         (JSC::DFG::SpeculativeJIT::compileArraySlice):
2236         (JSC::DFG::SpeculativeJIT::compileTypeOf):
2237         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
2238         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
2239         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
2240         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
2241         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
2242         (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
2243         * dfg/DFGSpeculativeJIT.h:
2244         (JSC::DFG::SpeculativeJIT::TrustedImmPtr::TrustedImmPtr):
2245         (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPointer):
2246         (JSC::DFG::SpeculativeJIT::TrustedImmPtr::operator MacroAssembler::TrustedImmPtr):
2247         (JSC::DFG::SpeculativeJIT::TrustedImmPtr::asIntptr):
2248         (JSC::DFG::SpeculativeJIT::callOperation):
2249         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
2250         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
2251         * dfg/DFGSpeculativeJIT32_64.cpp:
2252         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
2253         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
2254         (JSC::DFG::SpeculativeJIT::emitCall):
2255         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2256         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2257         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2258         (JSC::DFG::SpeculativeJIT::compile):
2259         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
2260         * dfg/DFGSpeculativeJIT64.cpp:
2261         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
2262         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
2263         (JSC::DFG::SpeculativeJIT::emitCall):
2264         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2265         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2266         (JSC::DFG::SpeculativeJIT::compile):
2267         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
2268         * dfg/DFGStrengthReductionPhase.cpp:
2269         (JSC::DFG::StrengthReductionPhase::handleNode):
2270         * dfg/DFGStructureAbstractValue.cpp:
2271         (JSC::DFG::StructureAbstractValue::assertIsRegistered):
2272         (JSC::DFG::StructureAbstractValue::clobber):
2273         (JSC::DFG::StructureAbstractValue::observeTransition):
2274         (JSC::DFG::StructureAbstractValue::observeTransitions):
2275         (JSC::DFG::StructureAbstractValue::add):
2276         (JSC::DFG::StructureAbstractValue::merge):
2277         (JSC::DFG::StructureAbstractValue::mergeNotTop):
2278         (JSC::DFG::StructureAbstractValue::filter):
2279         (JSC::DFG::StructureAbstractValue::filterSlow):
2280         (JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
2281         (JSC::DFG::StructureAbstractValue::contains):
2282         (JSC::DFG::StructureAbstractValue::isSubsetOf):
2283         (JSC::DFG::StructureAbstractValue::isSupersetOf):
2284         (JSC::DFG::StructureAbstractValue::overlaps):
2285         (JSC::DFG::StructureAbstractValue::isSubClassOf):
2286         (JSC::DFG::StructureAbstractValue::dumpInContext):
2287         * dfg/DFGStructureAbstractValue.h:
2288         (JSC::DFG::StructureAbstractValue::StructureAbstractValue):
2289         (JSC::DFG::StructureAbstractValue::operator=):
2290         (JSC::DFG::StructureAbstractValue::set):
2291         (JSC::DFG::StructureAbstractValue::toStructureSet):
2292         (JSC::DFG::StructureAbstractValue::at):
2293         (JSC::DFG::StructureAbstractValue::operator[]):
2294         (JSC::DFG::StructureAbstractValue::onlyStructure):
2295         * dfg/DFGStructureRegistrationPhase.cpp:
2296         (JSC::DFG::StructureRegistrationPhase::StructureRegistrationPhase): Deleted.
2297         (JSC::DFG::StructureRegistrationPhase::run): Deleted.
2298         (JSC::DFG::StructureRegistrationPhase::registerStructures): Deleted.
2299         (JSC::DFG::StructureRegistrationPhase::registerStructure): Deleted.
2300         (JSC::DFG::StructureRegistrationPhase::assertAreRegistered): Deleted.
2301         (JSC::DFG::StructureRegistrationPhase::assertIsRegistered): Deleted.
2302         (JSC::DFG::performStructureRegistration): Deleted.
2303         * dfg/DFGStructureRegistrationPhase.h:
2304         * dfg/DFGTransition.cpp:
2305         (JSC::DFG::Transition::dumpInContext):
2306         * dfg/DFGTransition.h:
2307         (JSC::DFG::Transition::Transition):
2308         * dfg/DFGTypeCheckHoistingPhase.cpp:
2309         (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
2310         (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
2311         * dfg/DFGValidate.cpp:
2312         * ftl/FTLLowerDFGToB3.cpp:
2313         (JSC::FTL::DFG::LowerDFGToB3::lower):
2314         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
2315         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure):
2316         (JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
2317         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
2318         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
2319         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
2320         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
2321         (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
2322         (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
2323         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
2324         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
2325         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
2326         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2327         (JSC::FTL::DFG::LowerDFGToB3::compileAllocatePropertyStorage):
2328         (JSC::FTL::DFG::LowerDFGToB3::compileReallocatePropertyStorage):
2329         (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
2330         (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
2331         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
2332         (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
2333         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
2334         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
2335         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
2336         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
2337         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
2338         (JSC::FTL::DFG::LowerDFGToB3::checkStructure):
2339         (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
2340         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
2341         (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
2342         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2343         (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
2344         (JSC::FTL::DFG::LowerDFGToB3::boolify):
2345         (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
2346         (JSC::FTL::DFG::LowerDFGToB3::lowCell):
2347         (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID):
2348         (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
2349         (JSC::FTL::DFG::LowerDFGToB3::frozenPointer):
2350         (JSC::FTL::DFG::LowerDFGToB3::weakStructureID):
2351         (JSC::FTL::DFG::LowerDFGToB3::weakStructure):
2352         (JSC::FTL::DFG::LowerDFGToB3::crash):
2353         * ftl/FTLOutput.h:
2354         (JSC::FTL::Output::weakPointer):
2355         (JSC::FTL::Output::constIntPtr):
2356
2357 2017-01-26  JF Bastien  <jfbastien@apple.com>
2358
2359         OSR entry: delay outer-loop compilation when at inner-loop
2360         https://bugs.webkit.org/show_bug.cgi?id=167149
2361
2362         Reviewed by Filip Pizlo.
2363
2364         As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
2365         compilation can be kicked off for an entry into an outer-loop,
2366         while executing an inner-loop. This is desirable because often the
2367         codegen from an inner-entry isn't as good as the codegen from an
2368         outer-entry, but execution from an inner-loop is often pretty hot
2369         and likely to kick off compilation. This approach provided nice
2370         speedups on Kraken because we'd select to enter to the outer-loop
2371         very reliably, which reduces variability (the inner-loop was
2372         selected roughly 1/5 times from my unscientific measurements).
2373
2374         When compilation starts we take a snapshot of the JSValues at the
2375         current execution state using OSR's recovery mechanism. These
2376         values are passed to the compiler and are used as way to perform
2377         type profiling, and could be used to observe cell types as well as
2378         to perform predictions such as through constant propagation.
2379
2380         It's therefore desired to enter from the outer-loop when we can,
2381         but we need to be executing from that location to capture the
2382         right JSValues, otherwise we're confusing the compiler and giving
2383         it inaccurate JSValues which can lead it to predict the wrong
2384         things, leading to suboptimal code or recompilation due to
2385         misprediction, or in super-corner-cases a crash.
2386
2387         These effects are pretty hard to measure: Fil points out that
2388         marsalis-osr-entry really needs mustHandleValues (the JSValues
2389         from the point of execution) because right now it just happens to
2390         correctly guess int32. I tried removing mustHandleValues entirely
2391         and saw no slowdowns, but our benchmarks probably aren't
2392         sufficient to reliably find issues, sometimes because we happen to
2393         have sufficient mitigations.
2394
2395         DFG tier-up was added here:
2396         https://bugs.webkit.org/show_bug.cgi?id=112838
2397
2398         * JavaScriptCore.xcodeproj/project.pbxproj:
2399         * dfg/DFGJITCode.h:
2400         * dfg/DFGJITCompiler.cpp:
2401         (JSC::DFG::JITCompiler::JITCompiler):
2402         * dfg/DFGOSREntry.cpp:
2403         (JSC::DFG::prepareOSREntry):
2404         * dfg/DFGOSREntry.h:
2405         (JSC::DFG::prepareOSREntry):
2406         * dfg/DFGOperations.cpp:
2407         * dfg/DFGOperations.h:
2408         * dfg/DFGSpeculativeJIT64.cpp:
2409         (JSC::DFG::SpeculativeJIT::compile):
2410         * dfg/DFGTierUpEntryTrigger.h: Copied from Source/JavaScriptCore/ftl/FTLOSREntry.h.
2411         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
2412         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
2413         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
2414         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
2415         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
2416         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
2417         * ftl/FTLOSREntry.cpp:
2418         (JSC::FTL::prepareOSREntry):
2419         * ftl/FTLOSREntry.h:
2420         * jit/JITOperations.cpp:
2421
2422 2017-01-25  Saam Barati  <sbarati@apple.com>
2423
2424         WebAssembly JS API: coerce return values from imports
2425         https://bugs.webkit.org/show_bug.cgi?id=165480
2426         <rdar://problem/29760318>
2427
2428         Reviewed by Yusuke Suzuki.
2429
2430         This patch does proper coercion for all possible
2431         JSValue return types from an imported function.
2432         
2433         It also adds the spec-compliant code to throw an exception
2434         when calling an import that has an i64 parameter or return
2435         value.
2436
2437         * jit/AssemblyHelpers.cpp:
2438         (JSC::AssemblyHelpers::emitJumpIfException):
2439         * jit/AssemblyHelpers.h:
2440         * wasm/WasmB3IRGenerator.cpp:
2441         * wasm/WasmBinding.cpp:
2442         (JSC::Wasm::wasmToJs):
2443
2444 2017-01-25  Filip Pizlo  <fpizlo@apple.com>
2445
2446         jsc.cpp should have the $.agent stuff for testing SAB
2447         https://bugs.webkit.org/show_bug.cgi?id=167431
2448
2449         Reviewed by Saam Barati.
2450         
2451         This adds some stuff that the SAB branch of test262 needs. None of this is exposed except for our
2452         own tests and the SAB branch of test262. We now pass all of the Atomics tests in the SAB branch
2453         of test262.
2454         
2455         * jsc.cpp:
2456         (Message::releaseContents):
2457         (Message::index):
2458         (GlobalObject::finishCreation):
2459         (GlobalObject::addFunction):
2460         (Message::Message):
2461         (Message::~Message):
2462         (Worker::Worker):
2463         (Worker::~Worker):
2464         (Worker::send):
2465         (Worker::receive):
2466         (Worker::current):
2467         (Worker::currentWorker):
2468         (Workers::Workers):
2469         (Workers::~Workers):
2470         (Workers::broadcast):
2471         (Workers::report):
2472         (Workers::tryGetReport):
2473         (Workers::getReport):
2474         (Workers::singleton):
2475         (functionDollarCreateRealm):
2476         (functionDollarDetachArrayBuffer):
2477         (functionDollarEvalScript):
2478         (functionDollarAgentStart):
2479         (functionDollarAgentReceiveBroadcast):
2480         (functionDollarAgentReport):
2481         (functionDollarAgentSleep):
2482         (functionDollarAgentBroadcast):
2483         (functionDollarAgentGetReport):
2484         (functionWaitForReport):
2485         (checkException):
2486         (runWithScripts):
2487         (runJSC):
2488         (jscmain):
2489         * runtime/JSArrayBuffer.h:
2490
2491 2017-01-25  Filip Pizlo  <fpizlo@apple.com>
2492
2493         ARM/ARM64 stress/atomics-store-return.js fails
2494         <rdar://problem/30192652>
2495
2496         Reviewed by Michael Saboff.
2497         
2498         The problem was relying on double->int casts for anything. We need to use toInt32().
2499
2500         * runtime/AtomicsObject.cpp:
2501         (JSC::atomicsFuncCompareExchange):
2502         (JSC::atomicsFuncExchange):
2503         (JSC::atomicsFuncStore):
2504
2505 2017-01-25  Ryosuke Niwa  <rniwa@webkit.org>
2506
2507         collectMatchingElementsInFlatTree should not find elements inside an user agent shadow tree
2508         https://bugs.webkit.org/show_bug.cgi?id=167409
2509
2510         Reviewed by Antti Koivisto.
2511
2512         Added matchingElementInFlatTree as a common identifier since it's required in the bindings code.
2513
2514         * runtime/CommonIdentifiers.h:
2515
2516 2017-01-24  Joseph Pecoraro  <pecoraro@apple.com>
2517
2518         Fold USER_TIMING into WEB_TIMING and make it a RuntimeEnabledFeature
2519         https://bugs.webkit.org/show_bug.cgi?id=167394
2520
2521         Reviewed by Ryosuke Niwa.
2522
2523         * Configurations/FeatureDefines.xcconfig:
2524         * runtime/CommonIdentifiers.h:
2525
2526 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
2527
2528         Atomics.store should return the int-converted value according to toInteger
2529         https://bugs.webkit.org/show_bug.cgi?id=167399
2530
2531         Reviewed by Saam Barati.
2532         
2533         I keep getting this wrong, but I think I've finally done it right. What we want is for
2534         Atomics.store to return the value it was passed after toInteger, which doesn't clip the value to
2535         any kind of range. It does get truncated to double.
2536         
2537         This changes the code to pass those "integers" as doubles. It doesn't matter that this is slow,
2538         since all of these code paths are slow due to their need to check everything. We'll take care of
2539         that by making them intrinsic later.
2540
2541         * runtime/AtomicsObject.cpp:
2542         (JSC::atomicsFuncAdd):
2543         (JSC::atomicsFuncAnd):
2544         (JSC::atomicsFuncCompareExchange):
2545         (JSC::atomicsFuncExchange):
2546         (JSC::atomicsFuncLoad):
2547         (JSC::atomicsFuncOr):
2548         (JSC::atomicsFuncStore):
2549         (JSC::atomicsFuncSub):
2550         (JSC::atomicsFuncXor):
2551
2552 2017-01-24  Yusuke Suzuki  <utatane.tea@gmail.com>
2553
2554         [JSC] Optimize Number#toString with Int52
2555         https://bugs.webkit.org/show_bug.cgi?id=167303
2556
2557         Reviewed by Sam Weinig.
2558
2559         In kraken crypto-sha256-iterative, we frequently call Number.prototype.toString with
2560         Int52. In that case, toString handles it in the generic double path. But we should
2561         have a fast path for this since it can be represented in int64_t.
2562
2563         The stanford-crypto-sha256-iterative shows 1.6% performance improvement (on Linux machine hanayamata).
2564
2565             Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
2566             sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
2567             function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
2568             milliseconds.
2569
2570                                                        baseline                  patched
2571
2572             stanford-crypto-sha256-iterative        32.853+-0.075      ^      32.325+-0.055         ^ definitely 1.0163x faster
2573
2574         * runtime/JSCJSValue.h:
2575         * runtime/NumberPrototype.cpp:
2576         (JSC::int52ToStringWithRadix):
2577         (JSC::toStringWithRadix):
2578
2579 2017-01-24  Michael Saboff  <msaboff@apple.com>
2580
2581         InferredTypeTable entry manipulation is not TOCTOU race safe
2582         https://bugs.webkit.org/show_bug.cgi?id=167344
2583
2584         Reviewed by Filip Pizlo.
2585
2586         Made the accesses to table values safe from Time of Check,
2587         Time of Use races with local temporary values.
2588
2589         Fixed point that we set an entry in the table to access the
2590         current table entry instead of using the local entry.  In that case,
2591         we reload the now changed entry.
2592
2593         * runtime/InferredTypeTable.cpp:
2594         (JSC::InferredTypeTable::visitChildren):
2595         (JSC::InferredTypeTable::get):
2596         (JSC::InferredTypeTable::willStoreValue):
2597         (JSC::InferredTypeTable::makeTop):
2598
2599 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
2600
2601         Atomics.store should return the int-converted value, not the value that it stored
2602         https://bugs.webkit.org/show_bug.cgi?id=167395
2603
2604         Reviewed by Saam Barati.
2605         
2606         Previously the code was based around passing a lambda that operated over the native type of the
2607         operation (so for example int8_t if we were doing things to Int8Arrays). But to support this
2608         behavior of store, we need it to be able to control how it converts its result to JSValue and it
2609         needs to see its argument as an int32_t. It turns out that it's easy for all of the functions in
2610         AtomicsObject.cpp to also adopt this protocol since the conversion to JSValue is just jsNumber()
2611         from the native type in those cases, and the conversion from int32_t is done for free in
2612         std::atomic.
2613
2614         * runtime/AtomicsObject.cpp:
2615         (JSC::atomicsFuncAdd):
2616         (JSC::atomicsFuncAnd):
2617         (JSC::atomicsFuncCompareExchange):
2618         (JSC::atomicsFuncExchange):
2619         (JSC::atomicsFuncLoad):
2620         (JSC::atomicsFuncOr):
2621         (JSC::atomicsFuncStore):
2622         (JSC::atomicsFuncSub):
2623         (JSC::atomicsFuncXor):
2624
2625 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
2626
2627         -0 is a valid array index and AtomicsObject should know this
2628         https://bugs.webkit.org/show_bug.cgi?id=167386
2629
2630         Reviewed by Mark Lam.
2631
2632         * runtime/AtomicsObject.cpp: The bug title really says it all.
2633
2634 2017-01-24  Commit Queue  <commit-queue@webkit.org>
2635
2636         Unreviewed, rolling out r211091.
2637         https://bugs.webkit.org/show_bug.cgi?id=167384
2638
2639         introduces a subtle bug in InferredTypeTable, huge
2640         Octane/deltablue regression (Requested by pizlo on #webkit).
2641
2642         Reverted changeset:
2643
2644         "InferredTypeTable entry manipulation is not TOCTOU race safe"
2645         https://bugs.webkit.org/show_bug.cgi?id=167344
2646         http://trac.webkit.org/changeset/211091
2647
2648 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
2649
2650         Enable the stochastic space-time scheduler on the larger multicores
2651         https://bugs.webkit.org/show_bug.cgi?id=167382
2652         <rdar://problem/30173375>
2653
2654         Rubber stamped by Saam Barati
2655         
2656         This looks like a 1.3% JetStream speed-up thanks to a 28% splay-latency improvement. This new
2657         scheduler seems to prevent all of the same pathologies as the old one prevented. But instead of
2658         periodically suspending the mutator, this new one will only suspend after an iteration of the
2659         constraint fixpoint. The length of that suspension length is random with the distribution being
2660         governed by mutatorUtilization. Once resumed, the mutator gets to run unimpeded until draining
2661         stalls.
2662         
2663         I'm enabling it on platforms as I benchmark those platforms. It's possible that we will want to
2664         use a different scheduler on different platforms.
2665
2666         * runtime/Options.cpp:
2667         (JSC::overrideDefaults):
2668
2669 2017-01-24  Michael Saboff  <msaboff@apple.com>
2670
2671         JSArray::tryCreateUninitialized should be called JSArray::tryCreateForInitializationPrivate
2672         https://bugs.webkit.org/show_bug.cgi?id=167334
2673
2674         Rubber-stamped by Filip Pizlo.
2675
2676         * dfg/DFGOperations.cpp:
2677         * ftl/FTLOperations.cpp:
2678         (JSC::FTL::operationMaterializeObjectInOSR):
2679         * runtime/ArrayPrototype.cpp:
2680         (JSC::arrayProtoFuncSplice):
2681         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2682         * runtime/CommonSlowPaths.cpp:
2683         (JSC::SLOW_PATH_DECL):
2684         * runtime/JSArray.cpp:
2685         (JSC::JSArray::tryCreateForInitializationPrivate):
2686         (JSC::JSArray::fastSlice):
2687         (JSC::JSArray::tryCreateUninitialized): Deleted.
2688         * runtime/JSArray.h:
2689         (JSC::JSArray::tryCreateForInitializationPrivate):
2690         (JSC::constructArray):
2691         (JSC::constructArrayNegativeIndexed):
2692         (JSC::JSArray::tryCreateUninitialized): Deleted.
2693         * runtime/RegExpMatchesArray.cpp:
2694         (JSC::createEmptyRegExpMatchesArray):
2695         * runtime/RegExpMatchesArray.h:
2696         (JSC::createRegExpMatchesArray):
2697
2698 2017-01-23  Michael Saboff  <msaboff@apple.com>
2699
2700         InferredTypeTable entry manipulation is not TOCTOU race safe
2701         https://bugs.webkit.org/show_bug.cgi?id=167344
2702
2703         Reviewed by Filip Pizlo.
2704
2705         Made the accesses to table values safe from Time of Check,
2706         Time of Use races with local temporary values.
2707
2708         * runtime/InferredTypeTable.cpp:
2709         (JSC::InferredTypeTable::visitChildren):
2710         (JSC::InferredTypeTable::get):
2711         (JSC::InferredTypeTable::willStoreValue):
2712         (JSC::InferredTypeTable::makeTop):
2713
2714 2017-01-23  Joseph Pecoraro  <pecoraro@apple.com>
2715
2716         Web Inspector: Provide a way to trigger a Garbage Collection
2717         https://bugs.webkit.org/show_bug.cgi?id=167345
2718         <rdar://problem/30102853>
2719
2720         Reviewed by Timothy Hatcher.
2721
2722         * inspector/protocol/Console.json:
2723         * inspector/protocol/Debugger.json:
2724         * inspector/protocol/Heap.json:
2725         * inspector/protocol/Runtime.json:
2726         These domains are supported by Worker backends. Label them.
2727
2728         * inspector/scripts/codegen/generate_js_backend_commands.py:
2729         (JSBackendCommandsGenerator.generate_domain):
2730         * inspector/scripts/codegen/models.py:
2731         (Protocol.parse_domain):
2732         (Domain.__init__):
2733         (Domains):
2734         Parse "workerSupported" and include a line in BackendCommands.js
2735         that calls to InspectorBackend.workerSupportedDomain().
2736
2737         * inspector/scripts/tests/generic/domain-availability.json: Added.
2738         * inspector/scripts/tests/generic/expected/domain-availability.json-result: Added.
2739         * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Added.
2740         * inspector/scripts/tests/generic/worker-supported-domains.json: Added.
2741         Tests for domain "workerSupported" and "availability" properties.
2742
2743 2017-01-23  Saam Barati  <sbarati@apple.com>
2744
2745         https://bugs.webkit.org/show_bug.cgi?id=167247
2746         JSC: operationSpreadGeneric uses the wrong global object for the builtin function and slow_path_spread consults the wrong global object to prove if the iterator protocol is unobservable
2747         <rdar://problem/30121809>
2748
2749         Reviewed by Filip Pizlo.
2750
2751         There were two bugs in the different tiers with respect to how
2752         spread handled global objects.
2753         
2754         The first was in the LLInt/baseline inside slow_path_spread:
2755         
2756         We consulted the lexical global object instead of the thing we're
2757         spreading's global object to determine if the array iterator protocol
2758         is unobservable. This is wrong if the incoming array is from a different
2759         global object. We must consult the incoming array's global object
2760         to determine if it can be spread using the fast path.
2761         
2762         The second was in operationSpreadGeneric in the DFG/FTL:
2763         
2764         We were always using the incoming array's global object, even
2765         when going down the slow path. This is wrong because we were
2766         fetching the builtin iteration function helper from the incoming
2767         array's global object, which meant that if the iterator function
2768         were to throw an exception, it could leak objects from a different
2769         global object. We should be executing the iterator function with
2770         the lexical global object.
2771
2772         * dfg/DFGOperations.cpp:
2773         * jsc.cpp:
2774         (GlobalObject::finishCreation):
2775         (functionGlobalObjectForObject):
2776         * runtime/CommonSlowPaths.cpp:
2777         (JSC::SLOW_PATH_DECL):
2778         * runtime/JSArray.h:
2779         * runtime/JSArrayInlines.h:
2780         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
2781
2782 2017-01-22  Filip Pizlo  <fpizlo@apple.com>
2783
2784         Land the stochastic space-time scheduler disabled
2785         https://bugs.webkit.org/show_bug.cgi?id=167249
2786
2787         Reviewed by Saam Barati.
2788         
2789         The space-time scheduler is pretty weird. It uses a periodic scheduler where the next period is
2790         simply determined by an integer multiple of time since when the scheduler last snapped phase. It
2791         snaps phase after constraint solving. Both the snapping of the phase after constraint solving and
2792         the periodicity appear to be necessary for good performance. For example, if the space-time
2793         scheduler decided that it was in the resume part of the phase just by virtue of having just
2794         resumed, then it would be empirically worse than our scheduler which asks "what time is it?" to
2795         decide whether it should be suspended or resumed even if it just suspended or resumed. I've spent
2796         a lot of time wondering why these two features are essential, and I think I found a reason.
2797         
2798         What's happening is that sometimes the GC has an overrun and its increment takes longer than it
2799         should have. The current scheduler forgives overruns when constraint solving, which seems to
2800         make sense because it cannot control whether constraint solving runs with the mutator resumed or
2801         suspended. It has to be suspended currently. Snapping phase after constraint solving accomplishes
2802         this. What's more surprising is how important it is to manage deadline misses during draining.
2803         The relevant kind of deadline miss is when doing mutator-suspended draining to catch up to the
2804         retreating wavefront. Deadline misses while doing this can happen systematically in some
2805         workloads, like JetStream/hash-map and some test in Speedometer. It's because they have some
2806         ginormous object and it takes like ~3ms+-1.5ms just to scan it. The space-time scheduler's use
2807         of time to decide what to do saves the day here: after the deadline miss, the scheduler will
2808         initially realize that it missed its deadline to resume the mutator. But as soon as it does this
2809         it asks: "based on current time since phase snap, what should I do?". In the case of a deadline
2810         miss, this question is essentially a weighted coin flip because of the high noise in the amount
2811         of time that it takes to do things in the GC. If you overrun, you will probably overrun by
2812         multiple milliseconds, which is enough that where you land in the space-time scheduler's timeline
2813         is random. The likelihood that you land in the "resume mutator" part of the timeline has a
2814         probability that is roughly the same as what the space-time scheduler calls mutator utilization.
2815         This is a super weird property. I did not intend for it to have this property, but it appears to
2816         be the most important property of this scheduler.
2817         
2818         Based on this, it seems that the fact that the space-time scheduler could suspend the mutator
2819         before draining runs out of work doesn't accomplish anything. As soon as you resume the
2820         mutator, you have a retreating wavefront to worry about. But if the collector is happily scanning
2821         things then it's almost certain that the collector will outpace the mutator. Also, anything that
2822         the mutator asks us to revisit is deferred anyway.
2823         
2824         In the past I've tried to replace the scheduler in one patch and this turned out to be annoying
2825         because even a poorly conceived scheduler should be iterated on. This patch lands a new scheduler
2826         called the StochasticSpaceTime scheduler. It replaces two of the known-good features of the old
2827         scheduler: (1) it forgives constraint pauses and (2) after deadline overrun its choice is random,
2828         weighted by the mutator utilization target. Unlike the old scheduler, this one will only suspend
2829         the mutator when the draining terminates, but it may pause for any amount of time after an
2830         iteration of constraint solving. It computes the targetPause by measuring constraint solving time
2831         and multiplying by the pauseScale (0.3 by default). If smaller then minimumPause (0.3ms by
2832         default), then it uses minimumPause instead. The stochastic scheduler will then definitely do at
2833         least targetPause worth of suspended draining after the constraint solving iteration, and then
2834         it will decide whether or not to do another one at random. The probability that it will choose to
2835         resume is exactly mutatorUtilization, which is computed exactly as before. Therefore, the
2836         probability of resumption starts at 0.7 and goes down as memory usage rises. Conversely, the
2837         probability that we will stay suspended starts at 0.3 and goes up from there.
2838         
2839         This new scheduler looks like it might be a 25% improvement on splay-latency. It also looks like
2840         a small progression on hash-map. Hash-map is a great test of one of the worst cases of retreating
2841         wavefront, since it is repeatedly storing to a ginormous array. This array is sure to take a
2842         while to scan, and to complete, the GC must be smart enough to visit any new objects it finds
2843         while scanning the array immediately after scanning that array. This new scheduler means that
2844         after scanning the array, the probability that you will scan whatever you found in it starts at
2845         0.3 and rises as the program allocates. It's sure to be 0.3, and not 0.3^k, because after the
2846         wavefront stops advancing, the only object on the mark stack after a constraint iteration will be
2847         that array. Since there is sure to be a 0.3ms or longer pause, the GC will be sure to start
2848         visiting this object. The GC can then complete if it just allows enough time after this to scan
2849         whatever new objects it finds. If scanning the array overruns the deadline (and it almost
2850         certainly will) then the probability that the GC keeps the mutator suspended is simply
2851         1 - mutatorUtilization.
2852         
2853         This scheduler is disabled by default. You can enable it with
2854         --useStochasticMutatorScheduler=true.
2855
2856         * CMakeLists.txt:
2857         * JavaScriptCore.xcodeproj/project.pbxproj:
2858         * heap/Heap.cpp:
2859         (JSC::Heap::Heap):
2860         (JSC::Heap::markToFixpoint):
2861         * heap/Heap.h:
2862         * heap/MarkingConstraintSet.cpp:
2863         (JSC::MarkingConstraintSet::didStartMarking):
2864         (JSC::MarkingConstraintSet::executeConvergenceImpl):
2865         (JSC::MarkingConstraintSet::resetStats): Deleted.
2866         (JSC::MarkingConstraintSet::executeBootstrap): Deleted.
2867         * heap/MarkingConstraintSet.h:
2868         * heap/MutatorScheduler.cpp:
2869         (JSC::MutatorScheduler::didReachTermination):
2870         (JSC::MutatorScheduler::synchronousDrainingDidStall):
2871         * heap/MutatorScheduler.h:
2872         * heap/SlotVisitor.cpp:
2873         (JSC::SlotVisitor::didReachTermination):
2874         (JSC::SlotVisitor::drainFromShared):
2875         * heap/StochasticSpaceTimeMutatorScheduler.cpp: Added.
2876         (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::Snapshot):
2877         (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::now):
2878         (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
2879         (JSC::StochasticSpaceTimeMutatorScheduler::StochasticSpaceTimeMutatorScheduler):
2880         (JSC::StochasticSpaceTimeMutatorScheduler::~StochasticSpaceTimeMutatorScheduler):
2881         (JSC::StochasticSpaceTimeMutatorScheduler::state):
2882         (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
2883         (JSC::StochasticSpaceTimeMutatorScheduler::didStop):
2884         (JSC::StochasticSpaceTimeMutatorScheduler::willResume):
2885         (JSC::StochasticSpaceTimeMutatorScheduler::didReachTermination):
2886         (JSC::StochasticSpaceTimeMutatorScheduler::didExecuteConstraints):
2887         (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
2888         (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
2889         (JSC::StochasticSpaceTimeMutatorScheduler::timeToResume):
2890         (JSC::StochasticSpaceTimeMutatorScheduler::log):
2891         (JSC::StochasticSpaceTimeMutatorScheduler::endCollection):
2892         (JSC::StochasticSpaceTimeMutatorScheduler::setResumeTime):
2893         (JSC::StochasticSpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
2894         (JSC::StochasticSpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
2895         (JSC::StochasticSpaceTimeMutatorScheduler::maxHeadroom):
2896         (JSC::StochasticSpaceTimeMutatorScheduler::headroomFullness):
2897         (JSC::StochasticSpaceTimeMutatorScheduler::mutatorUtilization):
2898         * heap/StochasticSpaceTimeMutatorScheduler.h: Added.
2899         * runtime/Options.cpp:
2900         (JSC::overrideDefaults):
2901         * runtime/Options.h:
2902
2903 2017-01-23  Mark Lam  <mark.lam@apple.com>
2904
2905         Added a comment to clarify an assertion.
2906
2907         Rubber-stamped by Filip Pizlo.
2908
2909         * runtime/JSCellInlines.h:
2910         (JSC::JSCell::classInfo):
2911
2912 2017-01-23  Filip Pizlo  <fpizlo@apple.com>
2913
2914         SharedArrayBuffer plus WebGL should not equal CRASH
2915         https://bugs.webkit.org/show_bug.cgi?id=167329
2916
2917         Reviewed by Saam Barati.
2918         
2919         DOM unwrapping methods should return null rather than crashing. The code expects an
2920         unshared buffer, so we should return null when it's shared. The caller can then decide
2921         if they like null or not.
2922
2923         * runtime/JSArrayBufferViewInlines.h:
2924         (JSC::JSArrayBufferView::toWrapped):
2925
2926 2017-01-23  Mark Lam  <mark.lam@apple.com>
2927
2928         ObjCCallbackFunction::destroy() should not use jsCast().
2929         https://bugs.webkit.org/show_bug.cgi?id=167322
2930
2931         Reviewed by Filip Pizlo.
2932
2933         Since r210829, it is no longer correct for object destructors to use jsCast().
2934         Fixed ObjCCallbackFunction::destroy() to use a static_cast instead.
2935
2936         * API/ObjCCallbackFunction.mm:
2937         (JSC::ObjCCallbackFunction::destroy):
2938
2939 2017-01-23  Michael Saboff  <msaboff@apple.com>
2940
2941         IntlObject uses JSArray::tryCreateUninitialized in an unsafe way
2942         https://bugs.webkit.org/show_bug.cgi?id=167288
2943
2944         Reviewed by Filip Pizlo.
2945
2946         Refactored the following "create" methods into a "tryCreate" method and a
2947         "create" wrapper: JSArray::create(), Butterfly::create() and
2948         createArrayButterfly().
2949
2950         Changed IntlObject.cpp to use JSArray::tryCreate() as it is simpler to use
2951         by not requiring the caller to be GC savey.  The performance benefits of
2952         tryCreateUninitialized() are not needed by the IntlObject c++ code.
2953
2954         Did not add a new test as the bug caused LayoutTests/js/intl.html to fail
2955         reliably with the JSC option values scribbleFreeCells=true,
2956         collectContinuously=true and JSC_useGenerationalGC=false.
2957
2958         * runtime/Butterfly.h:
2959         * runtime/ButterflyInlines.h:
2960         (JSC::Butterfly::tryCreate): Added.
2961         (JSC::Butterfly::create):
2962         * runtime/IntlObject.cpp:
2963         (JSC::canonicalizeLocaleList):
2964         (JSC::lookupSupportedLocales):
2965         (JSC::intlObjectFuncGetCanonicalLocales):
2966         * runtime/JSArray.h:
2967         (JSC::createContiguousArrayButterfly): Deleted.
2968         (JSC::tryCreateArrayButterfly): Added.
2969         (JSC::createArrayButterfly):
2970         (JSC::JSArray::tryCreate): Added.
2971         (JSC::JSArray::create):
2972
2973 2017-01-23  Joseph Pecoraro  <pecoraro@apple.com>
2974
2975         JavaScriptCore has a weak external symbol in it
2976         https://bugs.webkit.org/show_bug.cgi?id=167282
2977
2978         Reviewed by Yusuke Suzuki.
2979
2980         * debugger/Debugger.cpp:
2981         (JSC::Debugger::ProfilingClient::~ProfilingClient):
2982         * debugger/Debugger.h:
2983         Avoid possible weak external symbol.
2984
2985 2017-01-21  Chris Dumez  <cdumez@apple.com>
2986
2987         JavaScript for-of does not work on a lot of collection types (e.g. HTMLCollection)
2988         https://bugs.webkit.org/show_bug.cgi?id=167091
2989
2990         Reviewed by Darin Adler.
2991
2992         Update Array methods to throw a TypeError when (this === null || this === undefined)
2993         instead of when (this == null). This is because (this == null) returns true for types
2994         that masquerades as undefined (such as document.all) and this prevented use of the
2995         Array API on such types. The specification only stays to use ToObject(), which throws
2996         when the input is undefined or null.
2997
2998         The corresponding specification is at:
2999         - https://www.ecma-international.org/ecma-262/7.0/index.html#sec-array.prototype.values
3000         - https://www.ecma-international.org/ecma-262/7.0/index.html#sec-toobject
3001
3002         * builtins/ArrayPrototype.js:
3003         (values):
3004         (keys):
3005         (entries):
3006         (reduce):
3007         (reduceRight):
3008         (every):
3009         (forEach):
3010         (filter):
3011         (map):
3012         (some):
3013         (fill):
3014         (find):
3015         (findIndex):
3016         (includes):
3017         (sort):
3018         (concatSlowPath):
3019         (copyWithin):
3020
3021 2017-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>
3022
3023         [JSC] export JSC::importModule API for WebCore dynamic import
3024         https://bugs.webkit.org/show_bug.cgi?id=167099
3025
3026         Reviewed by Darin Adler.
3027
3028         We newly expose JSC::importModule API. This can be used later
3029         from WebCore to implement WebCore side dynamic import.
3030         And JSC shell also uses this API.
3031
3032         And this patch also cleans up module loader a bit:
3033         Dropping requestInstantiateAll.
3034
3035         * builtins/BuiltinNames.h:
3036         * builtins/ModuleLoaderPrototype.js:
3037         (requestLink):
3038         (requestImportModule):
3039         (requestInstantiateAll): Deleted.
3040         (importModule): Deleted.
3041         * jsc.cpp:
3042         (GlobalObject::moduleLoaderImportModule):
3043         * runtime/Completion.cpp:
3044         (JSC::importModule):
3045         * runtime/Completion.h:
3046         * runtime/JSModuleLoader.cpp:
3047         (JSC::JSModuleLoader::requestImportModule):
3048         * runtime/JSModuleLoader.h:
3049         * runtime/ModuleLoaderPrototype.cpp:
3050
3051 2017-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>
3052
3053         dynamic import is ambiguous with import declaration at module code
3054         https://bugs.webkit.org/show_bug.cgi?id=167098
3055
3056         Reviewed by Darin Adler.
3057
3058         This patch fixes two syntax issues related to dynamic import.
3059
3060         1. Fix member expression parsing with dynamic import results
3061
3062         We should not return import expression immediately after parsing
3063         it in parseMemberExpression. This prohibits us to parse the following
3064         code,
3065
3066             import("...").then(function () {
3067             });
3068
3069         2. dynamic import with import declaration under the module context
3070
3071         Before this patch, we always attempt to parse IMPORT as import declaration
3072         under the module context. It means that import call in the top level
3073         expression statement fails to be parsed since the parser attempts to parse
3074         it as import declaration.
3075
3076             import("...")  // module top level statement.
3077
3078         In this patch, we check the condition `[lookahead != (]` before starting
3079         parsing import declaration. This allows us to put import call in the module
3080         top level statement.
3081
3082         * parser/Parser.cpp:
3083         (JSC::Parser<LexerType>::parseModuleSourceElements):
3084         (JSC::Parser<LexerType>::parseMemberExpression):
3085
3086 2017-01-20  Joseph Pecoraro  <pecoraro@apple.com>
3087
3088         Remove outdated ENABLE(CSP_NEXT) build flag
3089         https://bugs.webkit.org/show_bug.cgi?id=167252
3090
3091         Reviewed by Brent Fulgham.
3092
3093         * Configurations/FeatureDefines.xcconfig:
3094
3095 2017-01-20  Saam Barati  <sbarati@apple.com>
3096
3097         We should flash a safepoint before each DFG/FTL phase
3098         https://bugs.webkit.org/show_bug.cgi?id=167234
3099
3100         Reviewed by Filip Pizlo.
3101
3102         The recent GC changes caused us to regress Kraken because of a
3103         longstanding issue that happened to be hit with higher frequency because
3104         of a change in timing between when a particular GC was happening and 
3105         when a particular FTL compilation was happening. The regression is caused
3106         by the GC was waiting for a large function to make it through the DFG portion
3107         of an FTL compilation. This was taking 20ms-30ms and started happened during a
3108         particular test with much higher frequency.
3109         
3110         This means that anytime the GC waits for this compilation, the test ran at least
3111         ~20ms slower because the GC waits for the compiler threads the mutator is stopped.
3112         
3113         It's good that we have such an easily reproducible case of this performance
3114         issue because it will effect many real JS programs, especially ones with
3115         large functions that get hot.
3116         
3117         The most straight forward solution to fix this is to flash a safepoint before
3118         each phase, allowing the GC to suspend the compiler if needed. In my testing,
3119         this progresses Kraken in the browser, and doesn't regress anything else. This
3120         solution also makes the most sense. I did some analysis on the compilation time
3121         of this function that took ~20-30ms to pass through the DFG phases, and
3122         the phase times were mostly evenly distributed. Some took longer than others,
3123         but no phase was longer than 3ms. Most were in the 0.25ms to 1.5ms range.
3124
3125         * dfg/DFGPlan.cpp:
3126         (JSC::DFG::Plan::compileInThreadImpl):
3127         * dfg/DFGSafepoint.cpp:
3128         (JSC::DFG::Safepoint::begin):
3129         * runtime/Options.h:
3130
3131 2017-01-20  Skachkov Oleksandr  <gskachkov@gmail.com>
3132
3133         Super property access in base class constructor doesn't work
3134         https://bugs.webkit.org/show_bug.cgi?id=166665
3135
3136         Reviewed by Ryosuke Niwa.
3137
3138         Allow to use super inside of the constructor for classes 
3139         without parent class.
3140         Parser checks if super used within the constructor and 
3141         add this information to function metedata, and later it is used
3142         during byte code generation.
3143
3144         * bytecompiler/NodesCodegen.cpp:
3145         (JSC::ClassExprNode::emitBytecode):
3146         * parser/Parser.cpp:
3147         (JSC::Parser<LexerType>::parseFunctionBody):
3148         (JSC::Parser<LexerType>::parseFunctionInfo):
3149         * parser/Parser.h:
3150         (JSC::Scope::usesEval):
3151         (JSC::Scope::fillParametersForSourceProviderCache):
3152         (JSC::Scope::restoreFromSourceProviderCache):
3153         (JSC::Parser::adjustSuperBindingForBaseConstructor):
3154         * parser/SourceProviderCacheItem.h:
3155         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
3156
3157 2017-01-19  Chris Dumez  <cdumez@apple.com>
3158
3159         iterable<> should be enabled on WK1
3160         https://bugs.webkit.org/show_bug.cgi?id=167221
3161         <rdar://problem/30108531>
3162
3163         Reviewed by Youenn Fablet.
3164
3165         * runtime/CommonIdentifiers.h:
3166
3167 2017-01-19  Filip Pizlo  <fpizlo@apple.com>
3168
3169         Structure::pin() needs to be called while holding a lock
3170         https://bugs.webkit.org/show_bug.cgi?id=167220
3171
3172         Reviewed by Saam Barati.
3173
3174         Imagine this race: the mutator calls pin() and the collector calls visitChildren(),
3175         on the same Structure at the same time. In trunk pin() does not require a lock to be
3176         held and it doesn't grab any locks. Meanwhile visitChildren() grabs the lock, checks
3177         if the structure is pinned, and if not, it removes it by overwriting with zero. Now
3178         imagine how this plays out when pin() runs. Since pin() grabs no locks, it is
3179         irrelevant that visitChildren() grabs any locks. So, visitChildren() might check if
3180         the table is pinned before pin() pins it, and then clear the table after it was
3181         already pinned.
3182
3183         The problem here is that pin() should be holding a lock. We could either make pin()
3184         grab that lock by itself, or what this patch does is makes the caller grab the lock.
3185         This is great because it means that sometimes we don't have to introduce any new
3186         locking.
3187
3188         This fixes a materializePropertyTable() checkOffsetConsistency() crash that happens
3189         very rarely, but I was able to get it to reproduce with run-webkit-tests and
3190         aggressive GC settings.
3191
3192         * runtime/ConcurrentJSLock.h:
3193         * runtime/Structure.cpp:
3194         (JSC::Structure::materializePropertyTable):
3195         (JSC::Structure::changePrototypeTransition):
3196         (JSC::Structure::attributeChangeTransition):
3197         (JSC::Structure::toDictionaryTransition):
3198         (JSC::Structure::nonPropertyTransition):
3199         (JSC::Structure::pin):
3200         (JSC::Structure::pinForCaching):
3201         (JSC::Structure::add):
3202         * runtime/Structure.h:
3203         * runtime/StructureInlines.h:
3204         (JSC::Structure::checkOffsetConsistency):
3205         (JSC::Structure::add):
3206         (JSC::Structure::addPropertyWithoutTransition):
3207
3208 2017-01-19  Filip Pizlo  <fpizlo@apple.com>
3209
3210         The mutator needs to fire a barrier after memmoving stuff around in an object that the GC scans
3211         https://bugs.webkit.org/show_bug.cgi?id=167208
3212
3213         Reviewed by Saam Barati.
3214         
3215         It used to be that if you moved a value from one place to another in the same object
3216         then there is no need for a barrier because the generational GC would have no need to
3217         know that some old object still continues to refer to the same other old object.
3218
3219         But the concurrent GC might scan that object as the mutator moves pointers around in
3220         it. If the ordering is right, this could mean that the collector never sees some of
3221         those pointers. This can be fixed by adding a barrier.
3222
3223         This fixes the most obvious cases I found. There may be more and I'll continue to
3224         audit. Most of the other memmove users seem to already use some kind of synchronization
3225         to prevent this. For example, this can also be fixed by just holding the cell lock
3226         around the memmove since we're dealing with indexing storage and the GC reads that
3227         under the cell lock.
3228
3229         * runtime/JSArray.cpp:
3230         (JSC::JSArray::shiftCountWithAnyIndexingType):
3231         (JSC::JSArray::unshiftCountWithAnyIndexingType):
3232
3233 2017-01-19  Myles C. Maxfield  <mmaxfield@apple.com>
3234
3235         [Cocoa] Variation fonts are erroneously disabled on iOS
3236         https://bugs.webkit.org/show_bug.cgi?id=167172
3237
3238         Reviewed by Simon Fraser.
3239
3240         OpenSource builders don't seem to understand sdk=embedded*.
3241
3242         * Configurations/FeatureDefines.xcconfig:
3243
3244 2017-01-19  Skachkov Oleksandr  <gskachkov@gmail.com>
3245
3246         "this" missing after await in async arrow function
3247         https://bugs.webkit.org/show_bug.cgi?id=166919
3248
3249         Reviewed by NOBODY Saam Barati.
3250
3251         This patch fixed issue in async arrow function. Issue appears because in arrow
3252         function _this_ is loaded from arrow function virtual scope. 
3253         Async arrow function can be suspended and when resuming should be used _this_ from 
3254         virtual scope, to allow this we load _this_ from virtual scope before store it to 
3255         generator.generatorThis property 
3256
3257         * bytecompiler/NodesCodegen.cpp:
3258         (JSC::FunctionNode::emitBytecode):
3259
3260 2017-01-18  Yusuke Suzuki  <utatane.tea@gmail.com>
3261
3262         [B3] B3 strength reduction could encounter Value without owner in PureCSE
3263         https://bugs.webkit.org/show_bug.cgi?id=167161
3264
3265         Reviewed by Filip Pizlo.
3266
3267         PureCSE relies on the fact that all the stored Values have owner member.
3268         This assumption is broken when you execute specializeSelect in B3ReduceStrength phase.
3269         It clears owner of Values which are in between Select and Check to clone them to then/else
3270         blocks. If these cleared Values are already stored in PureCSE map, this map poses a Value
3271         with nullptr owner in PureCSE.
3272
3273         This patch changes PureCSE to ignore stored Values tha have nullptr owner. This even means
3274         that a client of PureCSE could deliberately null the owner if they wanted to signal the
3275         Value should be ignored.
3276