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