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