FullCodeOrigin for CodeBlock+CodeOrigin printing
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-02-21  JF Bastien  <jfbastien@apple.com>
2
3         FullCodeOrigin for CodeBlock+CodeOrigin printing
4         https://bugs.webkit.org/show_bug.cgi?id=168673
5
6         Reviewed by Filip Pizlo.
7
8         WebAssembly doesn't have a CodeBlock, so printing it isn't
9         valid. This patch adds FullCodeOrigin to handle the
10         CodeBlock+CodeOrigin printing pattern, and uses it through all the
11         places I could find, including Repatch.cpp where it's relevant for
12         WebAssembly.
13
14         * CMakeLists.txt:
15         * JavaScriptCore.xcodeproj/project.pbxproj:
16         * bytecode/CodeBlock.cpp:
17         (JSC::CodeBlock::noticeIncomingCall):
18         * bytecode/FullCodeOrigin.cpp: Added.
19         (JSC::FullCodeOrigin::dump):
20         (JSC::FullCodeOrigin::dumpInContext):
21         * bytecode/FullCodeOrigin.h: Added.
22         (JSC::FullCodeOrigin::FullCodeOrigin):
23         * bytecode/PolymorphicAccess.cpp:
24         (JSC::PolymorphicAccess::regenerate):
25         * jit/PolymorphicCallStubRoutine.cpp:
26         (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
27         * jit/Repatch.cpp:
28         (JSC::linkFor):
29         (JSC::linkDirectFor):
30         (JSC::linkVirtualFor):
31
32 2017-02-21  Filip Pizlo  <fpizlo@apple.com>
33
34         Unreviewed, fix cloop. I managed to have my local patch for relanding be the one without the cloop
35         fix. I keep forgetting about cloop!
36
37         * heap/Heap.cpp:
38         (JSC::Heap::stopThePeriphery):
39         * runtime/JSLock.cpp:
40
41 2017-02-21  Mark Lam  <mark.lam@apple.com>
42
43         Add missing exception checks detected by running marathon.js.
44         https://bugs.webkit.org/show_bug.cgi?id=168687
45
46         Reviewed by Saam Barati.
47
48         When running the marathon.js test from https://bugs.webkit.org/show_bug.cgi?id=168580,
49         we get some crashes due to missing exception checks.  This patch adds those
50         missing exception checks.
51
52         * runtime/JSCJSValueInlines.h:
53         (JSC::JSValue::toPropertyKey):
54         * runtime/JSObject.cpp:
55         (JSC::JSObject::getPrimitiveNumber):
56
57 2017-02-20  Filip Pizlo  <fpizlo@apple.com>
58
59         The collector thread should only start when the mutator doesn't have heap access
60         https://bugs.webkit.org/show_bug.cgi?id=167737
61
62         Reviewed by Keith Miller.
63         
64         This turns the collector thread's workflow into a state machine, so that the mutator thread can
65         run it directly. This reduces the amount of synchronization we do with the collector thread, and
66         means that most apps will never start the collector thread. The collector thread will still start
67         when we need to finish collecting and we don't have heap access.
68         
69         In this new world, "stopping the world" means relinquishing control of collection to the mutator.
70         This means tracking who is conducting collection. I use the GCConductor enum to say who is
71         conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
72         refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
73         So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
74         collector the conn.
75         
76         This meant bringing back the conservative scan of the calling thread. It turns out that this
77         scan was too slow to be called on each GC increment because apparently setjmp() now does system
78         calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
79         whether or not it was correct, so I also made it so that the GC only rarely asks for the register
80         state. I think we still want to use my register saving code instead of setjmp because setjmp
81         seems to save things we don't need, and that could make us overly conservative.
82         
83         It turns out that this new scheduling discipline makes the old space-time scheduler perform
84         better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
85         because the mutator having the conn enables us to time the mutator<->collector context switches
86         by polling. The OS is never involved. So, we can use super precise timing. This allows the old
87         space-time schduler to shine like it hadn't before.
88         
89         The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
90         times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
91         half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
92         effect.
93
94         * CMakeLists.txt:
95         * JavaScriptCore.xcodeproj/project.pbxproj:
96         * bytecode/CodeBlock.cpp:
97         (JSC::CodeBlock::visitChildren):
98         * dfg/DFGWorklist.cpp:
99         (JSC::DFG::Worklist::ThreadBody::ThreadBody):
100         (JSC::DFG::Worklist::dump):
101         (JSC::DFG::numberOfWorklists):
102         (JSC::DFG::ensureWorklistForIndex):
103         (JSC::DFG::existingWorklistForIndexOrNull):
104         (JSC::DFG::existingWorklistForIndex):
105         * dfg/DFGWorklist.h:
106         (JSC::DFG::numberOfWorklists): Deleted.
107         (JSC::DFG::ensureWorklistForIndex): Deleted.
108         (JSC::DFG::existingWorklistForIndexOrNull): Deleted.
109         (JSC::DFG::existingWorklistForIndex): Deleted.
110         * heap/CollectingScope.h: Added.
111         (JSC::CollectingScope::CollectingScope):
112         (JSC::CollectingScope::~CollectingScope):
113         * heap/CollectorPhase.cpp: Added.
114         (JSC::worldShouldBeSuspended):
115         (WTF::printInternal):
116         * heap/CollectorPhase.h: Added.
117         * heap/EdenGCActivityCallback.cpp:
118         (JSC::EdenGCActivityCallback::lastGCLength):
119         * heap/FullGCActivityCallback.cpp:
120         (JSC::FullGCActivityCallback::doCollection):
121         (JSC::FullGCActivityCallback::lastGCLength):
122         * heap/GCConductor.cpp: Added.
123         (JSC::gcConductorShortName):
124         (WTF::printInternal):
125         * heap/GCConductor.h: Added.
126         * heap/GCFinalizationCallback.cpp: Added.
127         (JSC::GCFinalizationCallback::GCFinalizationCallback):
128         (JSC::GCFinalizationCallback::~GCFinalizationCallback):
129         * heap/GCFinalizationCallback.h: Added.
130         (JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
131         (JSC::createGCFinalizationCallback):
132         * heap/Heap.cpp:
133         (JSC::Heap::Thread::Thread):
134         (JSC::Heap::Heap):
135         (JSC::Heap::lastChanceToFinalize):
136         (JSC::Heap::gatherStackRoots):
137         (JSC::Heap::updateObjectCounts):
138         (JSC::Heap::sweepSynchronously):
139         (JSC::Heap::collectAllGarbage):
140         (JSC::Heap::collectAsync):
141         (JSC::Heap::collectSync):
142         (JSC::Heap::shouldCollectInCollectorThread):
143         (JSC::Heap::collectInCollectorThread):
144         (JSC::Heap::checkConn):
145         (JSC::Heap::runNotRunningPhase):
146         (JSC::Heap::runBeginPhase):
147         (JSC::Heap::runFixpointPhase):
148         (JSC::Heap::runConcurrentPhase):
149         (JSC::Heap::runReloopPhase):
150         (JSC::Heap::runEndPhase):
151         (JSC::Heap::changePhase):
152         (JSC::Heap::finishChangingPhase):
153         (JSC::Heap::stopThePeriphery):
154         (JSC::Heap::resumeThePeriphery):
155         (JSC::Heap::stopTheMutator):
156         (JSC::Heap::resumeTheMutator):
157         (JSC::Heap::stopIfNecessarySlow):
158         (JSC::Heap::collectInMutatorThread):
159         (JSC::Heap::waitForCollector):
160         (JSC::Heap::acquireAccessSlow):
161         (JSC::Heap::releaseAccessSlow):
162         (JSC::Heap::relinquishConn):
163         (JSC::Heap::finishRelinquishingConn):
164         (JSC::Heap::handleNeedFinalize):
165         (JSC::Heap::notifyThreadStopping):
166         (JSC::Heap::finalize):
167         (JSC::Heap::addFinalizationCallback):
168         (JSC::Heap::requestCollection):
169         (JSC::Heap::waitForCollection):
170         (JSC::Heap::updateAllocationLimits):
171         (JSC::Heap::didFinishCollection):
172         (JSC::Heap::collectIfNecessaryOrDefer):
173         (JSC::Heap::notifyIsSafeToCollect):
174         (JSC::Heap::preventCollection):
175         (JSC::Heap::performIncrement):
176         (JSC::Heap::markToFixpoint): Deleted.
177         (JSC::Heap::shouldCollectInThread): Deleted.
178         (JSC::Heap::collectInThread): Deleted.
179         (JSC::Heap::stopTheWorld): Deleted.
180         (JSC::Heap::resumeTheWorld): Deleted.
181         * heap/Heap.h:
182         (JSC::Heap::machineThreads):
183         (JSC::Heap::lastFullGCLength):
184         (JSC::Heap::lastEdenGCLength):
185         (JSC::Heap::increaseLastFullGCLength):
186         * heap/HeapInlines.h:
187         (JSC::Heap::mutatorIsStopped): Deleted.
188         * heap/HeapStatistics.cpp: Removed.
189         * heap/HeapStatistics.h: Removed.
190         * heap/HelpingGCScope.h: Removed.
191         * heap/IncrementalSweeper.cpp:
192         (JSC::IncrementalSweeper::stopSweeping):
193         (JSC::IncrementalSweeper::willFinishSweeping): Deleted.
194         * heap/IncrementalSweeper.h:
195         * heap/MachineStackMarker.cpp:
196         (JSC::MachineThreads::gatherFromCurrentThread):
197         (JSC::MachineThreads::gatherConservativeRoots):
198         (JSC::callWithCurrentThreadState):
199         * heap/MachineStackMarker.h:
200         * heap/MarkedAllocator.cpp:
201         (JSC::MarkedAllocator::allocateSlowCaseImpl):
202         * heap/MarkedBlock.cpp:
203         (JSC::MarkedBlock::Handle::sweep):
204         * heap/MarkedSpace.cpp:
205         (JSC::MarkedSpace::sweep):
206         * heap/MutatorState.cpp:
207         (WTF::printInternal):
208         * heap/MutatorState.h:
209         * heap/RegisterState.h: Added.
210         * heap/RunningScope.h: Added.
211         (JSC::RunningScope::RunningScope):
212         (JSC::RunningScope::~RunningScope):
213         * heap/SlotVisitor.cpp:
214         (JSC::SlotVisitor::SlotVisitor):
215         (JSC::SlotVisitor::drain):
216         (JSC::SlotVisitor::drainFromShared):
217         (JSC::SlotVisitor::drainInParallelPassively):
218         (JSC::SlotVisitor::donateAll):
219         (JSC::SlotVisitor::donate):
220         * heap/SlotVisitor.h:
221         (JSC::SlotVisitor::codeName):
222         * heap/StochasticSpaceTimeMutatorScheduler.cpp:
223         (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
224         (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
225         (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
226         * heap/SweepingScope.h: Added.
227         (JSC::SweepingScope::SweepingScope):
228         (JSC::SweepingScope::~SweepingScope):
229         * jit/JITWorklist.cpp:
230         (JSC::JITWorklist::Thread::Thread):
231         * jsc.cpp:
232         (GlobalObject::finishCreation):
233         (functionFlashHeapAccess):
234         * runtime/InitializeThreading.cpp:
235         (JSC::initializeThreading):
236         * runtime/JSCellInlines.h:
237         (JSC::JSCell::classInfo):
238         * runtime/Options.cpp:
239         (JSC::overrideDefaults):
240         * runtime/Options.h:
241         * runtime/TestRunnerUtils.cpp:
242         (JSC::finalizeStatsAtEndOfTesting):
243
244 2017-02-21  Saam Barati  <sbarati@apple.com>
245
246         Air should have a disassembly mode that dumps IR and assembly intermixed
247         https://bugs.webkit.org/show_bug.cgi?id=168629
248
249         Reviewed by Filip Pizlo.
250
251         This will make dumping FTL disassembly dump Air intermixed
252         with the assembly generated by each Air Inst. This is similar
253         to how dumpDFGDisassembly dumps the generated assembly for each
254         Node.
255         
256         Here is what the output will look like:
257         
258         Generated FTL JIT code for foo#CUaFiQ:[0x10b76c960->0x10b76c2d0->0x10b7b6da0, FTLFunctionCall, 40 (NeverInline)], instruction count = 40:
259         BB#0: ; frequency = 1.000000
260                 0x469004e02e00: push %rbp
261                 0x469004e02e01: mov %rsp, %rbp
262                 0x469004e02e04: add $0xffffffffffffffd0, %rsp
263             Move $0x10b76c960, %rax, $4487301472(@16)
264                 0x469004e02e08: mov $0x10b76c960, %rax
265             Move %rax, 16(%rbp), @19
266                 0x469004e02e12: mov %rax, 0x10(%rbp)
267             Patch &Patchpoint2, %rbp, %rax, @20
268                 0x469004e02e16: lea -0x50(%rbp), %rax
269                 0x469004e02e1a: mov $0x1084081e0, %r11
270                 0x469004e02e24: cmp %rax, (%r11)
271                 0x469004e02e27: ja 0x469004e02e9a
272             Move 56(%rbp), %rdx, @23
273                 0x469004e02e2d: mov 0x38(%rbp), %rdx
274             Move $0xffff000000000002, %rax, $-281474976710654(@15)
275                 0x469004e02e31: mov $0xffff000000000002, %rax
276             Patch &BranchTest64(3,SameAsRep)1, NonZero, %rdx, %rax, %rdx, @26
277                 0x469004e02e3b: test %rdx, %rax
278                 0x469004e02e3e: jnz 0x469004e02f08
279             Move 48(%rbp), %rax, @29
280                 0x469004e02e44: mov 0x30(%rbp), %rax
281             Move %rax, %rcx, @31
282                 0x469004e02e48: mov %rax, %rcx
283             Xor64 $6, %rcx, @31
284                 0x469004e02e4b: xor $0x6, %rcx
285             Patch &BranchTest64(3,SameAsRep)1, NonZero, %rcx, $-2, %rax, @35
286                 0x469004e02e4f: test $0xfffffffffffffffe, %rcx
287                 0x469004e02e56: jnz 0x469004e02f12
288             Patch &Branch32(3,SameAsRep)0, NotEqual, (%rdx), $266, %rdx, @45
289                 0x469004e02e5c: cmp $0x10a, (%rdx)
290                 0x469004e02e62: jnz 0x469004e02f1c
291             BranchTest32 NonZero, %rax, $1, @49
292                 0x469004e02e68: test $0x1, %al
293                 0x469004e02e6a: jnz 0x469004e02e91
294           Successors: #3, #1
295         BB#1: ; frequency = 1.000000
296           Predecessors: #0
297             Move $0, %rcx, @65
298                 0x469004e02e70: xor %rcx, %rcx
299             Jump @66
300           Successors: #2
301         BB#2: ; frequency = 1.000000
302           Predecessors: #1, #3
303             Move 24(%rdx), %rax, @58
304                 0x469004e02e73: mov 0x18(%rdx), %rax
305             Patch &BranchAdd32(4,ForceLateUseUnlessRecoverable)3, Overflow, %rcx, %rax, %rcx, %rcx, %rax, @60
306                 0x469004e02e77: add %eax, %ecx
307                 0x469004e02e79: jo 0x469004e02f26
308             Move $0xffff000000000000, %rax, $-281474976710656(@14)
309                 0x469004e02e7f: mov $0xffff000000000000, %rax
310             Add64 %rcx, %rax, %rax, @62
311                 0x469004e02e89: add %rcx, %rax
312             Ret64 %rax, @63
313                 0x469004e02e8c: mov %rbp, %rsp
314                 0x469004e02e8f: pop %rbp
315                 0x469004e02e90: ret 
316         BB#3: ; frequency = 1.000000
317           Predecessors: #0
318             Move 16(%rdx), %rcx, @52
319                 0x469004e02e91: mov 0x10(%rdx), %rcx
320             Jump @55
321                 0x469004e02e95: jmp 0x469004e02e73
322           Successors: #2
323
324         * CMakeLists.txt:
325         * JavaScriptCore.xcodeproj/project.pbxproj:
326         * b3/air/AirCode.h:
327         (JSC::B3::Air::Code::setDisassembler):
328         (JSC::B3::Air::Code::disassembler):
329         * b3/air/AirDisassembler.cpp: Added.
330         (JSC::B3::Air::Disassembler::startEntrypoint):
331         (JSC::B3::Air::Disassembler::endEntrypoint):
332         (JSC::B3::Air::Disassembler::startLatePath):
333         (JSC::B3::Air::Disassembler::endLatePath):
334         (JSC::B3::Air::Disassembler::startBlock):
335         (JSC::B3::Air::Disassembler::addInst):
336         (JSC::B3::Air::Disassembler::dump):
337         * b3/air/AirDisassembler.h: Added.
338         * b3/air/AirGenerate.cpp:
339         (JSC::B3::Air::generate):
340         * ftl/FTLCompile.cpp:
341         (JSC::FTL::compile):
342
343 2017-02-21  Ryan Haddad  <ryanhaddad@apple.com>
344
345         Unreviewed, rolling out r212712.
346
347         This change broke the CLoop build.
348
349         Reverted changeset:
350
351         "JSModuleNamespace object should have IC"
352         https://bugs.webkit.org/show_bug.cgi?id=160590
353         http://trac.webkit.org/changeset/212712
354
355 2017-02-21  Yusuke Suzuki  <utatane.tea@gmail.com>
356
357         JSModuleNamespace object should have IC
358         https://bugs.webkit.org/show_bug.cgi?id=160590
359
360         Reviewed by Saam Barati.
361
362         This patch optimizes accesses to module namespace objects.
363
364         1. Cache the resolutions for module namespace objects.
365
366             When constructing the module namespace object, we already resolves all the exports.
367             The module namespace object caches this result and leverage it in the later access in
368             getOwnPropertySlot. This avoids resolving bindings through resolveExport.
369
370         2. Introduce ModuleNamespaceLoad IC.
371
372             This patch adds new IC for module namespace objects. The mechanism is simple, getOwnPropertySlot
373             tells us about module namespace object resolution. The IC first checks whether the given object
374             is an expected module namespace object. If this check succeeds, we load the value from the module
375             environment.
376
377         3. Introduce DFG/FTL optimization.
378
379             After exploiting module namespace object accesses in (2), DFG can recognize this in ByteCodeParser.
380             DFG will convert it to CheckCell with the namespace object and GetClosureVar from the cached environment.
381             At that time, we have a chance to fold it to the constant.
382
383         This optimization improves the performance of accessing to module namespace objects.
384
385         Before
386             $ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-namespace.js
387             ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m   0.43s user 0.03s system 101% cpu 0.451 total
388             $ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-binding.js
389             ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m   0.08s user 0.02s system 103% cpu 0.104 total
390
391         After
392             $ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-namespace.js
393             ../../WebKitBuild/module-ic/Release/bin/jsc -m   0.11s user 0.01s system 106% cpu 0.109 total
394             $ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.js
395             ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.j  0.08s user 0.02s system 102% cpu 0.105 total
396
397         * CMakeLists.txt:
398         * JavaScriptCore.xcodeproj/project.pbxproj:
399         * bytecode/AccessCase.cpp:
400         (JSC::AccessCase::create):
401         (JSC::AccessCase::guardedByStructureCheck):
402         (JSC::AccessCase::canReplace):
403         (JSC::AccessCase::visitWeak):
404         (JSC::AccessCase::generateWithGuard):
405         (JSC::AccessCase::generateImpl):
406         * bytecode/AccessCase.h:
407         * bytecode/GetByIdStatus.cpp:
408         (JSC::GetByIdStatus::GetByIdStatus):
409         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
410         (JSC::GetByIdStatus::makesCalls):
411         (JSC::GetByIdStatus::dump):
412         * bytecode/GetByIdStatus.h:
413         (JSC::GetByIdStatus::isModuleNamespace):
414         (JSC::GetByIdStatus::takesSlowPath):
415         (JSC::GetByIdStatus::moduleNamespaceObject):
416         (JSC::GetByIdStatus::moduleEnvironment):
417         (JSC::GetByIdStatus::scopeOffset):
418         * bytecode/ModuleNamespaceAccessCase.cpp: Added.
419         (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
420         (JSC::ModuleNamespaceAccessCase::create):
421         (JSC::ModuleNamespaceAccessCase::~ModuleNamespaceAccessCase):
422         (JSC::ModuleNamespaceAccessCase::clone):
423         (JSC::ModuleNamespaceAccessCase::emit):
424         * bytecode/ModuleNamespaceAccessCase.h: Added.
425         (JSC::ModuleNamespaceAccessCase::moduleNamespaceObject):
426         (JSC::ModuleNamespaceAccessCase::moduleEnvironment):
427         (JSC::ModuleNamespaceAccessCase::scopeOffset):
428         * bytecode/PolymorphicAccess.cpp:
429         (WTF::printInternal):
430         * dfg/DFGByteCodeParser.cpp:
431         (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
432         (JSC::DFG::ByteCodeParser::handleGetById):
433         * jit/AssemblyHelpers.h:
434         (JSC::AssemblyHelpers::loadValue):
435         * jit/Repatch.cpp:
436         (JSC::tryCacheGetByID):
437         * runtime/AbstractModuleRecord.cpp:
438         (JSC::AbstractModuleRecord::getModuleNamespace):
439         * runtime/JSModuleNamespaceObject.cpp:
440         (JSC::JSModuleNamespaceObject::finishCreation):
441         (JSC::JSModuleNamespaceObject::visitChildren):
442         (JSC::getValue):
443         (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
444         (JSC::JSModuleNamespaceObject::getOwnPropertyNames):
445         * runtime/JSModuleNamespaceObject.h:
446         (JSC::isJSModuleNamespaceObject):
447         (JSC::JSModuleNamespaceObject::create): Deleted.
448         (JSC::JSModuleNamespaceObject::createStructure): Deleted.
449         (JSC::JSModuleNamespaceObject::moduleRecord): Deleted.
450         * runtime/JSModuleRecord.h:
451         (JSC::JSModuleRecord::moduleEnvironment): Deleted.
452         * runtime/PropertySlot.h:
453         (JSC::PropertySlot::PropertySlot):
454         (JSC::PropertySlot::domJIT):
455         (JSC::PropertySlot::moduleNamespaceSlot):
456         (JSC::PropertySlot::setValueModuleNamespace):
457         (JSC::PropertySlot::setCacheableCustom):
458
459 2017-02-21  Yusuke Suzuki  <utatane.tea@gmail.com>
460
461         ASSERTION FAILED: "!scope.exception()" with Object.isSealed/isFrozen and uninitialized module bindings
462         https://bugs.webkit.org/show_bug.cgi?id=168605
463
464         Reviewed by Saam Barati.
465
466         We should check exception state after calling getOwnPropertyDescriptor() since it can throw errors.
467
468         * runtime/ObjectConstructor.cpp:
469         (JSC::objectConstructorIsSealed):
470         (JSC::objectConstructorIsFrozen):
471
472 2017-02-20  Mark Lam  <mark.lam@apple.com>
473
474         [Re-landing] CachedCall should let GC know to keep its arguments alive.
475         https://bugs.webkit.org/show_bug.cgi?id=168567
476         <rdar://problem/30475767>
477
478         Reviewed by Saam Barati.
479
480         We fix this by having CachedCall use a MarkedArgumentBuffer to store its
481         arguments instead of a Vector.
482
483         Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
484         WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
485         correctness.
486
487         Update: the original patch has a bug in MarkedArgumentBuffer::expandCapacity()
488         where it was copying and calling addMarkSet() on values in m_buffer beyond m_size
489         (up to m_capacity).  As a result, depending on the pre-existing values in
490         m_inlineBuffer, this may result in a computed Heap pointer that is wrong, and
491         subsequently, manifest as a crash.  This is likely to be the cause of the PLT
492         regression.
493
494         I don't have a new test for this fix because the issue relies on sufficiently bad
495         values randomly showing up in m_inlineBuffer when we do an ensureCapacity() which
496         calls expandCapacity().
497
498         * interpreter/CachedCall.h:
499         (JSC::CachedCall::CachedCall):
500         (JSC::CachedCall::call):
501         (JSC::CachedCall::clearArguments):
502         (JSC::CachedCall::appendArgument):
503         (JSC::CachedCall::setArgument): Deleted.
504         * interpreter/CallFrame.h:
505         (JSC::ExecState::emptyList):
506         * interpreter/Interpreter.cpp:
507         (JSC::Interpreter::prepareForRepeatCall):
508         * interpreter/Interpreter.h:
509         * interpreter/ProtoCallFrame.h:
510         * runtime/ArgList.cpp:
511         (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
512         (JSC::MarkedArgumentBuffer::expandCapacity):
513         (JSC::MarkedArgumentBuffer::slowAppend):
514         * runtime/ArgList.h:
515         (JSC::MarkedArgumentBuffer::append):
516         (JSC::MarkedArgumentBuffer::ensureCapacity):
517         * runtime/StringPrototype.cpp:
518         (JSC::replaceUsingRegExpSearch):
519         * runtime/VM.cpp:
520         (JSC::VM::VM):
521         * runtime/VM.h:
522
523 2017-02-20  Commit Queue  <commit-queue@webkit.org>
524
525         Unreviewed, rolling out r212618.
526         https://bugs.webkit.org/show_bug.cgi?id=168609
527
528         "Appears to cause PLT regression" (Requested by mlam on
529         #webkit).
530
531         Reverted changeset:
532
533         "CachedCall should let GC know to keep its arguments alive."
534         https://bugs.webkit.org/show_bug.cgi?id=168567
535         http://trac.webkit.org/changeset/212618
536
537 2017-02-19  Mark Lam  <mark.lam@apple.com>
538
539         BytecodeGenerator should not iterate its m_controlFlowScopeStack using a pointer bump.
540         https://bugs.webkit.org/show_bug.cgi?id=168585
541
542         Reviewed by Yusuke Suzuki.
543
544         This is because m_controlFlowScopeStack is a SegmentedVector, and entries for
545         consecutive indices in the vector are not guaranteed to be consecutive in memory
546         layout.  Instead, we should be using indexing instead.
547
548         This issue was detected by the marathon.js test from
549         https://bugs.webkit.org/show_bug.cgi?id=168580.
550
551         * bytecompiler/BytecodeGenerator.cpp:
552         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
553         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
554
555 2017-02-20  Manuel Rego Casasnovas  <rego@igalia.com>
556
557         [css-grid] Remove compilation flag ENABLE_CSS_GRID_LAYOUT
558         https://bugs.webkit.org/show_bug.cgi?id=167693
559
560         Reviewed by Sergio Villar Senin.
561
562         * Configurations/FeatureDefines.xcconfig:
563
564 2017-02-19  Commit Queue  <commit-queue@webkit.org>
565
566         Unreviewed, rolling out r212472.
567         https://bugs.webkit.org/show_bug.cgi?id=168584
568
569         Broke CLoop builds when r212466 was rolled out in r212616
570         (Requested by rniwa on #webkit).
571
572         Reverted changeset:
573
574         "Unreviewed, fix cloop build."
575         http://trac.webkit.org/changeset/212472
576
577 2017-02-19  Mark Lam  <mark.lam@apple.com>
578
579         functionTestWasmModuleFunctions() should use a MarkedArgumentBuffer for storing args instead of a Vector.
580         https://bugs.webkit.org/show_bug.cgi?id=168574
581
582         Reviewed by Filip Pizlo.
583
584         * jsc.cpp:
585         (callWasmFunction):
586         (functionTestWasmModuleFunctions):
587         * runtime/ArgList.h:
588
589 2017-02-19  Mark Lam  <mark.lam@apple.com>
590
591         CachedCall should let GC know to keep its arguments alive.
592         https://bugs.webkit.org/show_bug.cgi?id=168567
593         <rdar://problem/30475767>
594
595         Reviewed by Saam Barati.
596
597         We fix this by having CachedCall use a MarkedArgumentBuffer to store its
598         arguments instead of a Vector.
599
600         Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
601         WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
602         correctness.
603
604         * interpreter/CachedCall.h:
605         (JSC::CachedCall::CachedCall):
606         (JSC::CachedCall::call):
607         (JSC::CachedCall::clearArguments):
608         (JSC::CachedCall::appendArgument):
609         (JSC::CachedCall::setArgument): Deleted.
610         * interpreter/CallFrame.h:
611         (JSC::ExecState::emptyList):
612         * interpreter/Interpreter.cpp:
613         (JSC::Interpreter::prepareForRepeatCall):
614         * interpreter/Interpreter.h:
615         * interpreter/ProtoCallFrame.h:
616         * runtime/ArgList.cpp:
617         (JSC::MarkedArgumentBuffer::expandCapacity):
618         * runtime/ArgList.h:
619         (JSC::MarkedArgumentBuffer::ensureCapacity):
620         * runtime/StringPrototype.cpp:
621         (JSC::replaceUsingRegExpSearch):
622         * runtime/VM.cpp:
623         (JSC::VM::VM):
624         * runtime/VM.h:
625
626 2017-02-19  Commit Queue  <commit-queue@webkit.org>
627
628         Unreviewed, rolling out r212466.
629         https://bugs.webkit.org/show_bug.cgi?id=168577
630
631         causes crashes on AArch64 on linux, maybe it's causing crashes
632         on iOS too (Requested by pizlo on #webkit).
633
634         Reverted changeset:
635
636         "The collector thread should only start when the mutator
637         doesn't have heap access"
638         https://bugs.webkit.org/show_bug.cgi?id=167737
639         http://trac.webkit.org/changeset/212466
640
641 2017-02-17  Michael Saboff  <msaboff@apple.com>
642
643         Improve ARM64 disassembler handling of pseudo ops, unsupported opcodes and zero reg
644         https://bugs.webkit.org/show_bug.cgi?id=168527
645
646         Reviewed by Filip Pizlo.
647
648         Added support for data processing 1 source instructions like rbit, rev, clz and cls.
649         Added support for the FP conditional select instruction, fcsel.  Consolidated the
650         two classes for handling dmb instructions into one class.  Fixed the instruction
651         selection mask in the integer conditional select class, A64DOpcodeConditionalSelect.
652         Fixed the processing of extract instruction (extr) including the rotate right (ror)
653         pseudo instruction.  Changed the printing of x31 and w31 to xzr and wzr as operands
654         according to the spec.  Added support for common pseudo instructions.  This includes:
655         - mvn x1, X2 in place of orn x1, xzr, x2
656         - lsl x3, x4, #count in place of ubfiz x3, x4, #count, #count
657         - smull x5, w6, w7 in place of smaddl x5, w6, w7, XZR
658         - More understandable mov x8, #-304 in place of movn x8, #0x12f
659         - Eliminated xzr from register index loads and stores, outputing
660           ldr x10, [x11] instead of ldr x10, [x11, xzr]
661
662         Changed the move wide instructions to use hex literals for movz and movk.
663         This makes it much easier to decifer sequences of wide moves for large literals.
664                 Before                       After
665           movz   x17, #26136           movz   x17, #0x6618
666           movk   x17, #672, lsl #16    movk   x17, #0x2a0, lsl #16
667           movk   x17, #1, lsl #32      movk   x17, #0x1, lsl #32
668
669         Verified that all instructions currently generated by the JSC stress tests are
670         disassembled.
671
672         * disassembler/ARM64/A64DOpcode.cpp:
673         (JSC::ARM64Disassembler::A64DOpcodeBitfield::format):
674         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
675         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
676         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing3Source::format):
677         (JSC::ARM64Disassembler::A64DOpcodeExtract::format):
678         (JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::format):
679         (JSC::ARM64Disassembler::A64DOpcodeFloatingPointIntegerConversions::format):
680         (JSC::ARM64Disassembler::A64DOpcodeDmb::format):
681         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreImmediate::format):
682         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterOffset::format):
683         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format):
684         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreUnsignedImmediate::format):
685         (JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::format):
686         (JSC::ARM64Disassembler::A64DOpcodeMoveWide::format):
687         (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format): Deleted.
688         (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format): Deleted.
689         * disassembler/ARM64/A64DOpcode.h:
690         (JSC::ARM64Disassembler::A64DOpcode::appendSignedImmediate64):
691         (JSC::ARM64Disassembler::A64DOpcode::appendUnsignedHexImmediate):
692         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opName):
693         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::sBit):
694         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opCode):
695         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opCode2):
696         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opNameIndex):
697         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing3Source::opName):
698         (JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::opName):
699         (JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::condition):
700         (JSC::ARM64Disassembler::A64DOpcodeDmb::option):
701         (JSC::ARM64Disassembler::A64DOpcodeDmb::crM):
702         (JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::isMov):
703         (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName): Deleted.
704         (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName): Deleted.
705
706 2017-02-17  Zan Dobersek  <zdobersek@igalia.com>
707
708         [GLib] GCActivityCallback::scheduleTimer() keeps pushing dispatch into the future
709         https://bugs.webkit.org/show_bug.cgi?id=168363
710
711         Reviewed by Carlos Garcia Campos.
712
713         Mimic the USE(CF) implementation of GCActivityCallback and HeapTimer by
714         scheduling the timer a decade into the future instead of completely
715         cancelling it. That way new dispatch times for GCActivityCallback can be
716         computed by simply deducting the difference in the new and previous
717         delay from the GSource's current dispatch time. Previously we handled an
718         extra 'paused' state (where m_delay was -1) and allowed for a delay of
719         an infinite value to be valid, complicating the next dispatch time
720         computation.
721
722         HeapTimer gains the static s_decade variable. The dispatch function in
723         heapTimerSourceFunctions only dispatches the callback, which now delays
724         the GSource by a decade. HeapTimer::scheduleTimer() simply schedules the
725         source to dispatch in the specified amount of time, and cancelTimer()
726         'cancels' the source by setting the dispatch time to a decade.
727
728         GCActivityCallback constructor initializes the delay to the s_decade
729         value and immediately sets the ready time for GSource a decade into the
730         future, avoiding the default -1 value as the ready time that would cause
731         problems in scheduleTimer(). scheduleTimer() doesn't special-case the
732         zero-delay value anymore, instead it just computes the difference
733         between the old and the new delay and rolls back the GSource's ready
734         time for that amount. cancelTimer() sets m_delay to the decade value and
735         delays the GSource for that same amount.
736
737         * heap/GCActivityCallback.cpp:
738         (JSC::GCActivityCallback::GCActivityCallback):
739         (JSC::GCActivityCallback::scheduleTimer):
740         (JSC::GCActivityCallback::cancelTimer):
741         * heap/GCActivityCallback.h:
742         * heap/HeapTimer.cpp:
743         (JSC::HeapTimer::HeapTimer):
744         (JSC::HeapTimer::scheduleTimer):
745         (JSC::HeapTimer::cancelTimer):
746         * heap/HeapTimer.h:
747
748 2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>
749
750         [JSC] Drop PassRefPtr from ArrayBuffer
751         https://bugs.webkit.org/show_bug.cgi?id=168455
752
753         Reviewed by Geoffrey Garen.
754
755         This patch finally drops all the PassRefPtr in JSC.
756         We changed PassRefPtr<ArrayBuffer> to RefPtr<ArrayBuffer>&&.
757         Since ArrayBuffer may be nullptr if the array is neutered,
758         we hold it as RefPtr<> instead of Ref<>.
759
760         And we also drops 2 files, TypedArrayBase.h and IntegralTypedArrayBase.h.
761         They are not used (and they are not referenced from the project file).
762
763         * inspector/JavaScriptCallFrame.h:
764         * jsc.cpp:
765         (functionDollarAgentReceiveBroadcast):
766         * runtime/ArrayBufferView.cpp:
767         (JSC::ArrayBufferView::ArrayBufferView):
768         * runtime/ArrayBufferView.h:
769         (JSC::ArrayBufferView::possiblySharedBuffer):
770         (JSC::ArrayBufferView::unsharedBuffer):
771         (JSC::ArrayBufferView::verifySubRangeLength):
772         (JSC::ArrayBufferView::clampOffsetAndNumElements):
773         * runtime/ClassInfo.h:
774         * runtime/DataView.cpp:
775         (JSC::DataView::DataView):
776         (JSC::DataView::create):
777         * runtime/DataView.h:
778         * runtime/GenericTypedArrayView.h:
779         * runtime/GenericTypedArrayViewInlines.h:
780         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
781         (JSC::GenericTypedArrayView<Adaptor>::create):
782         (JSC::GenericTypedArrayView<Adaptor>::subarray):
783         * runtime/IntegralTypedArrayBase.h: Removed.
784         * runtime/JSArrayBuffer.cpp:
785         (JSC::JSArrayBuffer::JSArrayBuffer):
786         (JSC::JSArrayBuffer::create):
787         * runtime/JSArrayBuffer.h:
788         * runtime/JSArrayBufferPrototype.cpp:
789         (JSC::arrayBufferProtoFuncSlice):
790         * runtime/JSArrayBufferView.cpp:
791         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
792         * runtime/JSArrayBufferView.h:
793         * runtime/JSArrayBufferViewInlines.h:
794         (JSC::JSArrayBufferView::possiblySharedImpl):
795         (JSC::JSArrayBufferView::unsharedImpl):
796         * runtime/JSCell.cpp:
797         (JSC::JSCell::slowDownAndWasteMemory):
798         (JSC::JSCell::getTypedArrayImpl):
799         * runtime/JSCell.h:
800         * runtime/JSDataView.cpp:
801         (JSC::JSDataView::create):
802         (JSC::JSDataView::possiblySharedTypedImpl):
803         (JSC::JSDataView::unsharedTypedImpl):
804         (JSC::JSDataView::getTypedArrayImpl):
805         * runtime/JSDataView.h:
806         * runtime/JSGenericTypedArrayView.h:
807         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
808         (JSC::constructGenericTypedArrayViewWithArguments):
809         * runtime/JSGenericTypedArrayViewInlines.h:
810         (JSC::JSGenericTypedArrayView<Adaptor>::create):
811         (JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
812         (JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
813         (JSC::JSGenericTypedArrayView<Adaptor>::getTypedArrayImpl):
814         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
815         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
816         * runtime/JSTypedArrays.cpp:
817         (JSC::createUint8TypedArray):
818         * runtime/TypedArrayBase.h: Removed.
819
820 2017-02-16  Keith Miller  <keith_miller@apple.com>
821
822         ASSERTION FAILED: vm.heap.mutatorState() == MutatorState::Running || vm.apiLock().ownerThread() != std::this_thread::get_id()
823         https://bugs.webkit.org/show_bug.cgi?id=168354
824
825         Reviewed by Geoffrey Garen.
826
827         Instead of adding a custom vmEntryGlobalObject for the debugger
828         we can just have it use vmEntryScope instead.
829
830         * debugger/Debugger.cpp:
831         (JSC::Debugger::detach):
832         * interpreter/CallFrame.cpp:
833         (JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach): Deleted.
834         * interpreter/CallFrame.h:
835
836 2017-02-16  Filip Pizlo  <fpizlo@apple.com>
837
838         Unreviewed, fix cloop build.
839
840         * heap/Heap.cpp:
841         (JSC::Heap::stopThePeriphery):
842         * runtime/JSLock.cpp:
843
844 2017-02-10  Filip Pizlo  <fpizlo@apple.com>
845
846         The collector thread should only start when the mutator doesn't have heap access
847         https://bugs.webkit.org/show_bug.cgi?id=167737
848
849         Reviewed by Keith Miller.
850         
851         This turns the collector thread's workflow into a state machine, so that the mutator thread can
852         run it directly. This reduces the amount of synchronization we do with the collector thread, and
853         means that most apps will never start the collector thread. The collector thread will still start
854         when we need to finish collecting and we don't have heap access.
855         
856         In this new world, "stopping the world" means relinquishing control of collection to the mutator.
857         This means tracking who is conducting collection. I use the GCConductor enum to say who is
858         conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
859         refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
860         So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
861         collector the conn.
862         
863         This meant bringing back the conservative scan of the calling thread. It turns out that this
864         scan was too slow to be called on each GC increment because apparently setjmp() now does system
865         calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
866         whether or not it was correct, so I also made it so that the GC only rarely asks for the register
867         state. I think we still want to use my register saving code instead of setjmp because setjmp
868         seems to save things we don't need, and that could make us overly conservative.
869         
870         It turns out that this new scheduling discipline makes the old space-time scheduler perform
871         better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
872         because the mutator having the conn enables us to time the mutator<->collector context switches
873         by polling. The OS is never involved. So, we can use super precise timing. This allows the old
874         space-time schduler to shine like it hadn't before.
875         
876         The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
877         times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
878         half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
879         effect.
880
881         * CMakeLists.txt:
882         * JavaScriptCore.xcodeproj/project.pbxproj:
883         * dfg/DFGWorklist.cpp:
884         (JSC::DFG::Worklist::ThreadBody::ThreadBody):
885         (JSC::DFG::Worklist::dump):
886         (JSC::DFG::numberOfWorklists):
887         (JSC::DFG::ensureWorklistForIndex):
888         (JSC::DFG::existingWorklistForIndexOrNull):
889         (JSC::DFG::existingWorklistForIndex):
890         * dfg/DFGWorklist.h:
891         (JSC::DFG::numberOfWorklists): Deleted.
892         (JSC::DFG::ensureWorklistForIndex): Deleted.
893         (JSC::DFG::existingWorklistForIndexOrNull): Deleted.
894         (JSC::DFG::existingWorklistForIndex): Deleted.
895         * heap/CollectingScope.h: Added.
896         (JSC::CollectingScope::CollectingScope):
897         (JSC::CollectingScope::~CollectingScope):
898         * heap/CollectorPhase.cpp: Added.
899         (JSC::worldShouldBeSuspended):
900         (WTF::printInternal):
901         * heap/CollectorPhase.h: Added.
902         * heap/EdenGCActivityCallback.cpp:
903         (JSC::EdenGCActivityCallback::lastGCLength):
904         * heap/FullGCActivityCallback.cpp:
905         (JSC::FullGCActivityCallback::doCollection):
906         (JSC::FullGCActivityCallback::lastGCLength):
907         * heap/GCConductor.cpp: Added.
908         (JSC::gcConductorShortName):
909         (WTF::printInternal):
910         * heap/GCConductor.h: Added.
911         * heap/Heap.cpp:
912         (JSC::Heap::Thread::Thread):
913         (JSC::Heap::Heap):
914         (JSC::Heap::lastChanceToFinalize):
915         (JSC::Heap::gatherStackRoots):
916         (JSC::Heap::updateObjectCounts):
917         (JSC::Heap::shouldCollectInCollectorThread):
918         (JSC::Heap::collectInCollectorThread):
919         (JSC::Heap::checkConn):
920         (JSC::Heap::runCurrentPhase):
921         (JSC::Heap::runNotRunningPhase):
922         (JSC::Heap::runBeginPhase):
923         (JSC::Heap::runFixpointPhase):
924         (JSC::Heap::runConcurrentPhase):
925         (JSC::Heap::runReloopPhase):
926         (JSC::Heap::runEndPhase):
927         (JSC::Heap::changePhase):
928         (JSC::Heap::finishChangingPhase):
929         (JSC::Heap::stopThePeriphery):
930         (JSC::Heap::resumeThePeriphery):
931         (JSC::Heap::stopTheMutator):
932         (JSC::Heap::resumeTheMutator):
933         (JSC::Heap::stopIfNecessarySlow):
934         (JSC::Heap::collectInMutatorThread):
935         (JSC::Heap::collectInMutatorThreadImpl):
936         (JSC::Heap::waitForCollector):
937         (JSC::Heap::acquireAccessSlow):
938         (JSC::Heap::releaseAccessSlow):
939         (JSC::Heap::relinquishConn):
940         (JSC::Heap::finishRelinquishingConn):
941         (JSC::Heap::handleNeedFinalize):
942         (JSC::Heap::notifyThreadStopping):
943         (JSC::Heap::finalize):
944         (JSC::Heap::requestCollection):
945         (JSC::Heap::waitForCollection):
946         (JSC::Heap::updateAllocationLimits):
947         (JSC::Heap::didFinishCollection):
948         (JSC::Heap::collectIfNecessaryOrDefer):
949         (JSC::Heap::preventCollection):
950         (JSC::Heap::performIncrement):
951         (JSC::Heap::markToFixpoint): Deleted.
952         (JSC::Heap::shouldCollectInThread): Deleted.
953         (JSC::Heap::collectInThread): Deleted.
954         (JSC::Heap::stopTheWorld): Deleted.
955         (JSC::Heap::resumeTheWorld): Deleted.
956         * heap/Heap.h:
957         (JSC::Heap::machineThreads):
958         (JSC::Heap::lastFullGCLength):
959         (JSC::Heap::lastEdenGCLength):
960         (JSC::Heap::increaseLastFullGCLength):
961         * heap/HeapInlines.h:
962         (JSC::Heap::mutatorIsStopped): Deleted.
963         * heap/HeapStatistics.cpp: Removed.
964         * heap/HeapStatistics.h: Removed.
965         * heap/HelpingGCScope.h: Removed.
966         * heap/MachineStackMarker.cpp:
967         (JSC::MachineThreads::gatherFromCurrentThread):
968         (JSC::MachineThreads::gatherConservativeRoots):
969         * heap/MachineStackMarker.h:
970         * heap/MarkedBlock.cpp:
971         (JSC::MarkedBlock::Handle::sweep):
972         * heap/MutatorState.cpp:
973         (WTF::printInternal):
974         * heap/MutatorState.h:
975         * heap/RegisterState.h: Added.
976         * heap/SlotVisitor.cpp:
977         (JSC::SlotVisitor::drainFromShared):
978         (JSC::SlotVisitor::drainInParallelPassively):
979         (JSC::SlotVisitor::donateAll):
980         * heap/StochasticSpaceTimeMutatorScheduler.cpp:
981         (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
982         (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
983         (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
984         * heap/SweepingScope.h: Added.
985         (JSC::SweepingScope::SweepingScope):
986         (JSC::SweepingScope::~SweepingScope):
987         * jit/JITWorklist.cpp:
988         (JSC::JITWorklist::Thread::Thread):
989         * jsc.cpp:
990         (GlobalObject::finishCreation):
991         (functionFlashHeapAccess):
992         * runtime/InitializeThreading.cpp:
993         (JSC::initializeThreading):
994         * runtime/JSCellInlines.h:
995         (JSC::JSCell::classInfo):
996         * runtime/Options.cpp:
997         (JSC::overrideDefaults):
998         * runtime/Options.h:
999         * runtime/TestRunnerUtils.cpp:
1000         (JSC::finalizeStatsAtEndOfTesting):
1001
1002 2017-02-16  Anders Carlsson  <andersca@apple.com>
1003
1004         Remove EFL from JavaScriptCore
1005         https://bugs.webkit.org/show_bug.cgi?id=168459
1006
1007         Reviewed by Geoffrey Garen.
1008
1009         * heap/GCActivityCallback.cpp:
1010         (JSC::GCActivityCallback::GCActivityCallback):
1011         (JSC::GCActivityCallback::cancelTimer):
1012         (JSC::GCActivityCallback::didAllocate):
1013         * heap/GCActivityCallback.h:
1014         * heap/HeapTimer.cpp:
1015         (JSC::HeapTimer::add): Deleted.
1016         (JSC::HeapTimer::stop): Deleted.
1017         (JSC::HeapTimer::timerEvent): Deleted.
1018         * heap/HeapTimer.h:
1019         * inspector/EventLoop.cpp:
1020         (Inspector::EventLoop::cycle):
1021         * jsc.cpp:
1022         (main):
1023         * tools/CodeProfiling.cpp:
1024         (JSC::CodeProfiling::begin):
1025         (JSC::CodeProfiling::end):
1026
1027 2017-02-15  Brian Burg  <bburg@apple.com>
1028
1029         [Cocoa] Web Inspector: Inspector::fromProtocolString<T> should return std::optional<T>
1030         https://bugs.webkit.org/show_bug.cgi?id=168018
1031         <rdar://problem/30468779>
1032
1033         Reviewed by Joseph Pecoraro.
1034
1035         These methods parse untrusted string inputs, so they should return an optional instead
1036         of asserting or crashing when the input is not usable.
1037
1038         Update various pieces of generated code to handle the error case gracefully.
1039
1040         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
1041         (ObjCBackendDispatcherImplementationGenerator._generate_conversions_for_command):
1042         (ObjCBackendDispatcherImplementationGenerator._generate_invocation_for_command):
1043         The local variable holding the ObjC-friendly converted value should take a std::optional
1044         when converting an enum from a string into an NS_ENUM value. If the enum command parameter
1045         is not optional, then send a response with a command failure message and return.
1046
1047         The optional enum parameter case is not handled correctly, but no existing code requires it.
1048
1049         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
1050         (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_from_protocol_string):
1051         Fix signature and remove default case ASSERT_NOT_REACHED.
1052
1053         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
1054         (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_method_implementation):
1055         Since this code assumes all inputs to be valid and throws an exception otherwise, we
1056         try to convert the enum and throw an exception if it's nullopt. If it's valid, write to outValue.
1057
1058         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
1059         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
1060         The local variable holding the ObjC-friendly converted value should take a std::optional
1061         when converting an enum from a string into an NS_ENUM value. If the enum command parameter
1062         is not optional, then throw an exception if the value is nullopt. Otherwise, allow it to be empty.
1063
1064         * inspector/scripts/codegen/objc_generator.py:
1065         (ObjCGenerator.protocol_to_objc_expression_for_member):
1066         Unconditionally unwrap the optional. This expression is only used inside the typechecked
1067         ObjC protocol objects. In this case we are guaranteed to have already initialized the enum with a valid
1068         value, but must store it as a string inside a wrapped InspectorObject. The getter needs to
1069         re-convert the stored string into an NS_ENUM value.
1070
1071         * inspector/scripts/codegen/objc_generator_templates.py:
1072         Update type template for fromProtocolString<T>().
1073
1074         * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
1075         * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
1076         * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
1077         * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
1078         * inspector/scripts/tests/generic/expected/domain-availability.json-result:
1079         * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
1080         * inspector/scripts/tests/generic/expected/enum-values.json-result:
1081         * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
1082         * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
1083         * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
1084         * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
1085         * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
1086         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
1087         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
1088         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1089         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1090         * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
1091         * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
1092         * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
1093         Rebaseline tests.
1094
1095 2017-02-16  Keith Miller  <keith_miller@apple.com>
1096
1097         ASSERTION FAILED: vm.heap.mutatorState() == MutatorState::Running || vm.apiLock().ownerThread() != std::this_thread::get_id()
1098         https://bugs.webkit.org/show_bug.cgi?id=168354
1099
1100         Reviewed by Filip Pizlo.
1101
1102         Add a new vmEntryGlobalObject method for the debugger so that
1103         the debugger does not crash in debug builds when trying to
1104         detach itself from a global object.
1105
1106         * debugger/Debugger.cpp:
1107         (JSC::Debugger::detach):
1108         * interpreter/CallFrame.cpp:
1109         (JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach):
1110         * interpreter/CallFrame.h:
1111
1112 2017-02-16  Keith Miller  <keith_miller@apple.com>
1113
1114         Refactor AccessCase to be more like B3Value
1115         https://bugs.webkit.org/show_bug.cgi?id=168408
1116
1117         Reviewed by Filip Pizlo.
1118
1119         This patch makes AccessCase (and new subclasses) more like B3Value. In the new system each
1120         type has an associated AccessCase subclass. For instance any getter should use the
1121         GetterSetterAccessCase subclass. The new system is easier to follow since you no longer need
1122         to know exactly which members are used by which types. The subclass to AccessType mapping is:
1123
1124         GetterSetterAccessCase:
1125             Getter
1126             CustomAccessorGetter
1127             CustomValueGetter
1128             Setter
1129
1130         ProxyableAccessCase:
1131             Load
1132             Miss
1133             GetGetter
1134
1135         IntrinsicGetterAccessCase:
1136             IntrinsicGetter
1137
1138         AccessCase:
1139             Everything else
1140
1141         It also has the additional advantage that it uses less memory for the cases where we would have needed
1142         rare data in the past but that case would only use a small bit of it.
1143
1144         This patch also removes megamorphic loads and renames some TryGetById related enum values from Pure to Try.
1145
1146         * CMakeLists.txt:
1147         * JavaScriptCore.xcodeproj/project.pbxproj:
1148         * bytecode/AccessCase.cpp: Added.
1149         (JSC::AccessCase::AccessCase):
1150         (JSC::AccessCase::create):
1151         (JSC::AccessCase::~AccessCase):
1152         (JSC::AccessCase::fromStructureStubInfo):
1153         (JSC::AccessCase::clone):
1154         (JSC::AccessCase::commit):
1155         (JSC::AccessCase::guardedByStructureCheck):
1156         (JSC::AccessCase::doesCalls):
1157         (JSC::AccessCase::couldStillSucceed):
1158         (JSC::AccessCase::canReplace):
1159         (JSC::AccessCase::dump):
1160         (JSC::AccessCase::visitWeak):
1161         (JSC::AccessCase::propagateTransitions):
1162         (JSC::AccessCase::generateWithGuard):
1163         (JSC::AccessCase::generate):
1164         (JSC::AccessCase::generateImpl):
1165         * bytecode/AccessCase.h: Added.
1166         (JSC::AccessCase::as):
1167         (JSC::AccessCase::create):
1168         (JSC::AccessCase::type):
1169         (JSC::AccessCase::state):
1170         (JSC::AccessCase::offset):
1171         (JSC::AccessCase::structure):
1172         (JSC::AccessCase::newStructure):
1173         (JSC::AccessCase::conditionSet):
1174         (JSC::AccessCase::alternateBase):
1175         (JSC::AccessCase::additionalSet):
1176         (JSC::AccessCase::viaProxy):
1177         (JSC::AccessCase::isGetter):
1178         (JSC::AccessCase::isAccessor):
1179         (JSC::AccessCase::dumpImpl):
1180         (JSC::AccessCase::resetState):
1181         * bytecode/GetByIdStatus.cpp:
1182         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
1183         * bytecode/GetterSetterAccessCase.cpp: Added.
1184         (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
1185         (JSC::GetterSetterAccessCase::create):
1186         (JSC::GetterSetterAccessCase::~GetterSetterAccessCase):
1187         (JSC::GetterSetterAccessCase::clone):
1188         (JSC::GetterSetterAccessCase::alternateBase):
1189         (JSC::GetterSetterAccessCase::dumpImpl):
1190         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
1191         * bytecode/GetterSetterAccessCase.h: Added.
1192         (JSC::GetterSetterAccessCase::callLinkInfo):
1193         (JSC::GetterSetterAccessCase::customSlotBase):
1194         (JSC::GetterSetterAccessCase::domJIT):
1195         * bytecode/IntrinsicGetterAccessCase.cpp: Added.
1196         (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
1197         (JSC::IntrinsicGetterAccessCase::create):
1198         (JSC::IntrinsicGetterAccessCase::~IntrinsicGetterAccessCase):
1199         (JSC::IntrinsicGetterAccessCase::clone):
1200         * bytecode/IntrinsicGetterAccessCase.h: Added.
1201         (JSC::IntrinsicGetterAccessCase::intrinsicFunction):
1202         (JSC::IntrinsicGetterAccessCase::intrinsic):
1203         * bytecode/PolymorphicAccess.cpp:
1204         (JSC::PolymorphicAccess::regenerate):
1205         (WTF::printInternal):
1206         (JSC::AccessCase::AccessCase): Deleted.
1207         (JSC::AccessCase::tryGet): Deleted.
1208         (JSC::AccessCase::get): Deleted.
1209         (JSC::AccessCase::megamorphicLoad): Deleted.
1210         (JSC::AccessCase::replace): Deleted.
1211         (JSC::AccessCase::transition): Deleted.
1212         (JSC::AccessCase::setter): Deleted.
1213         (JSC::AccessCase::in): Deleted.
1214         (JSC::AccessCase::getLength): Deleted.
1215         (JSC::AccessCase::getIntrinsic): Deleted.
1216         (JSC::AccessCase::~AccessCase): Deleted.
1217         (JSC::AccessCase::fromStructureStubInfo): Deleted.
1218         (JSC::AccessCase::clone): Deleted.
1219         (JSC::AccessCase::commit): Deleted.
1220         (JSC::AccessCase::guardedByStructureCheck): Deleted.
1221         (JSC::AccessCase::alternateBase): Deleted.
1222         (JSC::AccessCase::doesCalls): Deleted.
1223         (JSC::AccessCase::couldStillSucceed): Deleted.
1224         (JSC::AccessCase::canBeReplacedByMegamorphicLoad): Deleted.
1225         (JSC::AccessCase::canReplace): Deleted.
1226         (JSC::AccessCase::dump): Deleted.
1227         (JSC::AccessCase::visitWeak): Deleted.
1228         (JSC::AccessCase::propagateTransitions): Deleted.
1229         (JSC::AccessCase::generateWithGuard): Deleted.
1230         (JSC::AccessCase::generate): Deleted.
1231         (JSC::AccessCase::generateImpl): Deleted.
1232         (JSC::AccessCase::emitDOMJITGetter): Deleted.
1233         * bytecode/PolymorphicAccess.h:
1234         (JSC::AccessCase::type): Deleted.
1235         (JSC::AccessCase::state): Deleted.
1236         (JSC::AccessCase::offset): Deleted.
1237         (JSC::AccessCase::viaProxy): Deleted.
1238         (JSC::AccessCase::structure): Deleted.
1239         (JSC::AccessCase::newStructure): Deleted.
1240         (JSC::AccessCase::conditionSet): Deleted.
1241         (JSC::AccessCase::intrinsicFunction): Deleted.
1242         (JSC::AccessCase::intrinsic): Deleted.
1243         (JSC::AccessCase::domJIT): Deleted.
1244         (JSC::AccessCase::additionalSet): Deleted.
1245         (JSC::AccessCase::customSlotBase): Deleted.
1246         (JSC::AccessCase::isGetter): Deleted.
1247         (JSC::AccessCase::callLinkInfo): Deleted.
1248         (JSC::AccessCase::RareData::RareData): Deleted.
1249         * bytecode/ProxyableAccessCase.cpp: Added.
1250         (JSC::ProxyableAccessCase::ProxyableAccessCase):
1251         (JSC::ProxyableAccessCase::create):
1252         (JSC::ProxyableAccessCase::~ProxyableAccessCase):
1253         (JSC::ProxyableAccessCase::clone):
1254         (JSC::ProxyableAccessCase::dumpImpl):
1255         * bytecode/ProxyableAccessCase.h: Added.
1256         * bytecode/PutByIdStatus.cpp:
1257         (JSC::PutByIdStatus::computeForStubInfo):
1258         * bytecode/StructureStubInfo.cpp:
1259         (JSC::StructureStubInfo::reset):
1260         * bytecode/StructureStubInfo.h:
1261         * dfg/DFGByteCodeParser.cpp:
1262         (JSC::DFG::ByteCodeParser::parseBlock):
1263         * dfg/DFGSpeculativeJIT.cpp:
1264         (JSC::DFG::SpeculativeJIT::compileTryGetById):
1265         * ftl/FTLLowerDFGToB3.cpp:
1266         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1267         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
1268         * jit/IntrinsicEmitter.cpp:
1269         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1270         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1271         (JSC::AccessCase::canEmitIntrinsicGetter): Deleted.
1272         (JSC::AccessCase::emitIntrinsicGetter): Deleted.
1273         * jit/JITOperations.cpp:
1274         * jit/JITPropertyAccess.cpp:
1275         (JSC::JIT::emit_op_try_get_by_id):
1276         * jit/JITPropertyAccess32_64.cpp:
1277         (JSC::JIT::emit_op_try_get_by_id):
1278         * jit/Repatch.cpp:
1279         (JSC::tryCacheGetByID):
1280         (JSC::tryCachePutByID):
1281         (JSC::tryRepatchIn):
1282         * jit/Repatch.h:
1283         * runtime/Options.h:
1284
1285 2017-02-16  Filip Pizlo  <fpizlo@apple.com>
1286
1287         JSONParseTest needs to hold the lock when the VM is destroyed
1288         https://bugs.webkit.org/show_bug.cgi?id=168450
1289
1290         Rubber stamped by Alex Christensen.
1291
1292         * API/tests/JSONParseTest.cpp:
1293         (testJSONParse):
1294
1295 2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1296
1297         [JSC] Drop PassRefPtr in inspector/
1298         https://bugs.webkit.org/show_bug.cgi?id=168420
1299
1300         Reviewed by Alex Christensen.
1301
1302         Drop PassRefPtr uses.
1303         And use Ref<Inspector::ScriptArguments> and Ref<ScriptCallStack> as much as possible.
1304         It drops some unnecessary null checks.
1305
1306         * debugger/Debugger.cpp:
1307         (JSC::Debugger::hasBreakpoint):
1308         (JSC::Debugger::currentDebuggerCallFrame):
1309         * debugger/Debugger.h:
1310         * inspector/AsyncStackTrace.cpp:
1311         (Inspector::AsyncStackTrace::create):
1312         (Inspector::AsyncStackTrace::AsyncStackTrace):
1313         (Inspector::AsyncStackTrace::buildInspectorObject):
1314         (Inspector::AsyncStackTrace::truncate):
1315         * inspector/AsyncStackTrace.h:
1316         * inspector/ConsoleMessage.cpp:
1317         (Inspector::ConsoleMessage::ConsoleMessage):
1318         * inspector/ConsoleMessage.h:
1319         * inspector/InjectedScriptManager.cpp:
1320         (Inspector::InjectedScriptManager::InjectedScriptManager):
1321         (Inspector::InjectedScriptManager::injectedScriptHost):
1322         * inspector/InjectedScriptManager.h:
1323         * inspector/JSGlobalObjectConsoleClient.cpp:
1324         (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
1325         (Inspector::JSGlobalObjectConsoleClient::count):
1326         (Inspector::JSGlobalObjectConsoleClient::timeEnd):
1327         (Inspector::JSGlobalObjectConsoleClient::timeStamp):
1328         (Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
1329         * inspector/JSGlobalObjectConsoleClient.h:
1330         ConsoleClient now takes Ref<ScriptArgument>&& instead of RefPtr<ScriptArgument>&&.
1331
1332         * inspector/JSGlobalObjectInspectorController.cpp:
1333         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
1334         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
1335         * inspector/JSGlobalObjectInspectorController.h:
1336         * inspector/JSJavaScriptCallFrame.cpp:
1337         (Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame):
1338         (Inspector::toJS):
1339         * inspector/JSJavaScriptCallFrame.h:
1340         (Inspector::JSJavaScriptCallFrame::create):
1341         * inspector/JavaScriptCallFrame.cpp:
1342         (Inspector::JavaScriptCallFrame::JavaScriptCallFrame):
1343         (Inspector::JavaScriptCallFrame::caller):
1344         * inspector/JavaScriptCallFrame.h:
1345         (Inspector::JavaScriptCallFrame::create):
1346         * inspector/ScriptDebugServer.cpp:
1347         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
1348         (Inspector::ScriptDebugServer::dispatchDidPause):
1349         (Inspector::ScriptDebugServer::exceptionOrCaughtValue):
1350         * inspector/agents/InspectorConsoleAgent.cpp:
1351         (Inspector::InspectorConsoleAgent::stopTiming):
1352         (Inspector::InspectorConsoleAgent::count):
1353         * inspector/agents/InspectorConsoleAgent.h:
1354         * inspector/agents/InspectorDebuggerAgent.cpp:
1355         (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
1356         * runtime/ConsoleClient.cpp:
1357         (JSC::ConsoleClient::printConsoleMessageWithArguments):
1358         (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
1359         (JSC::ConsoleClient::logWithLevel):
1360         (JSC::ConsoleClient::dir):
1361         (JSC::ConsoleClient::dirXML):
1362         (JSC::ConsoleClient::table):
1363         (JSC::ConsoleClient::trace):
1364         (JSC::ConsoleClient::assertion):
1365         (JSC::ConsoleClient::group):
1366         (JSC::ConsoleClient::groupCollapsed):
1367         (JSC::ConsoleClient::groupEnd):
1368         * runtime/ConsoleClient.h:
1369         * runtime/ConsoleObject.cpp:
1370         (JSC::consoleLogWithLevel):
1371         (JSC::consoleProtoFuncDir):
1372         (JSC::consoleProtoFuncDirXML):
1373         (JSC::consoleProtoFuncTable):
1374         (JSC::consoleProtoFuncTrace):
1375         (JSC::consoleProtoFuncAssert):
1376         (JSC::consoleProtoFuncCount):
1377         (JSC::consoleProtoFuncTimeStamp):
1378         (JSC::consoleProtoFuncGroup):
1379         (JSC::consoleProtoFuncGroupCollapsed):
1380         (JSC::consoleProtoFuncGroupEnd):
1381
1382 2017-02-15  Keith Miller  <keith_miller@apple.com>
1383
1384         Weak should not use jsCast in its accessors
1385         https://bugs.webkit.org/show_bug.cgi?id=168406
1386
1387         Reviewed by Filip Pizlo.
1388
1389         This can cause assertion failures in WebCore where classes might remove themselves
1390         from a data structure in a weak reference, if that reference is still alive.
1391
1392         * heap/WeakInlines.h:
1393         (JSC::>):
1394         (JSC::Weak<T>::operator):
1395         (JSC::Weak<T>::get):
1396
1397 2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1398
1399         Web Inspector: allow import() inside the inspector
1400         https://bugs.webkit.org/show_bug.cgi?id=167457
1401
1402         Reviewed by Ryosuke Niwa.
1403
1404         We relax import module hook to accept null SourceOrigin.
1405         Such a script can be evaluated from the inspector console.
1406
1407         * jsc.cpp:
1408         (GlobalObject::moduleLoaderImportModule):
1409         * runtime/JSGlobalObjectFunctions.cpp:
1410         (JSC::globalFuncImportModule):
1411
1412 2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1413
1414         [JSC] Update module namespace object according to the latest ECMA262
1415         https://bugs.webkit.org/show_bug.cgi?id=168280
1416
1417         Reviewed by Saam Barati.
1418
1419         Reflect updates to the module namespace object.
1420
1421         1. @@iterator property is dropped[1].
1422         2. @@toStringTag property becomes non-configurable[1].
1423         3. delete with Symbol should be delegated to the JSObject's one[2].
1424
1425         [1]: https://tc39.github.io/ecma262/#sec-module-namespace-objects
1426         [2]: https://github.com/tc39/ecma262/pull/767
1427
1428         * runtime/JSModuleNamespaceObject.cpp:
1429         (JSC::JSModuleNamespaceObject::finishCreation):
1430         (JSC::JSModuleNamespaceObject::deleteProperty):
1431         (JSC::moduleNamespaceObjectSymbolIterator): Deleted.
1432
1433 2017-02-16  Carlos Garcia Campos  <cgarcia@igalia.com>
1434
1435         Unreviewed. Fix the build after r212424.
1436
1437         Add missing file.
1438
1439         * inspector/remote/RemoteInspector.cpp: Added.
1440         (Inspector::RemoteInspector::startDisabled):
1441         (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
1442         (Inspector::RemoteInspector::registerTarget):
1443         (Inspector::RemoteInspector::unregisterTarget):
1444         (Inspector::RemoteInspector::updateTarget):
1445         (Inspector::RemoteInspector::updateClientCapabilities):
1446         (Inspector::RemoteInspector::setRemoteInspectorClient):
1447         (Inspector::RemoteInspector::setupFailed):
1448         (Inspector::RemoteInspector::setupCompleted):
1449         (Inspector::RemoteInspector::waitingForAutomaticInspection):
1450         (Inspector::RemoteInspector::clientCapabilitiesDidChange):
1451         (Inspector::RemoteInspector::stop):
1452         (Inspector::RemoteInspector::listingForTarget):
1453         (Inspector::RemoteInspector::updateHasActiveDebugSession):
1454
1455 2017-02-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1456
1457         [JSC] Drop PassRefPtr in bytecompiler/
1458         https://bugs.webkit.org/show_bug.cgi?id=168374
1459
1460         Reviewed by Sam Weinig.
1461
1462         This patch drops PassRefPtr in bytecompiler directory.
1463         We carefully change this to Ref<>. And we use Ref<Label>
1464         as much as possible instead of using RefPtr<Label>.
1465         And use Label& instead of Label* as much as possible.
1466
1467         Currently we do not apply this change for RefPtr<RegisterID>,
1468         to reduce the size of this patch.
1469
1470         * bytecompiler/BytecodeGenerator.cpp:
1471         (JSC::BytecodeGenerator::BytecodeGenerator):
1472         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
1473         (JSC::BytecodeGenerator::newLabelScope):
1474         (JSC::BytecodeGenerator::newLabel):
1475         (JSC::BytecodeGenerator::newEmittedLabel):
1476         Introduce a new helper function, which returns new label that is emitted right here.
1477
1478         (JSC::BytecodeGenerator::emitLabel):
1479         (JSC::BytecodeGenerator::emitJump):
1480         (JSC::BytecodeGenerator::emitJumpIfTrue):
1481         (JSC::BytecodeGenerator::emitJumpIfFalse):
1482         (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
1483         (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
1484         Drop returning Ref<Label> since nobody uses it.
1485
1486         (JSC::BytecodeGenerator::emitGetByVal):
1487         (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
1488         (JSC::BytecodeGenerator::emitCall):
1489         (JSC::BytecodeGenerator::emitReturn):
1490         (JSC::BytecodeGenerator::emitConstruct):
1491         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1492         (JSC::BytecodeGenerator::breakTarget):
1493         (JSC::BytecodeGenerator::pushTry):
1494         (JSC::BytecodeGenerator::popTry):
1495         (JSC::prepareJumpTableForSwitch):
1496         (JSC::prepareJumpTableForStringSwitch):
1497         (JSC::BytecodeGenerator::endSwitch):
1498         (JSC::BytecodeGenerator::emitEnumeration):
1499         (JSC::BytecodeGenerator::emitIteratorNext):
1500         (JSC::BytecodeGenerator::emitIteratorNextWithValue):
1501         (JSC::BytecodeGenerator::emitIteratorClose):
1502         (JSC::BytecodeGenerator::pushIndexedForInScope):
1503         (JSC::BytecodeGenerator::pushStructureForInScope):
1504         (JSC::BytecodeGenerator::invalidateForInContextForLocal):
1505         (JSC::BytecodeGenerator::emitRequireObjectCoercible):
1506         (JSC::BytecodeGenerator::emitYieldPoint):
1507         (JSC::BytecodeGenerator::emitYield):
1508         (JSC::BytecodeGenerator::emitDelegateYield):
1509         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1510         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1511         (JSC::BytecodeGenerator::emitFinallyCompletion):
1512         (JSC::BytecodeGenerator::emitJumpIf):
1513         * bytecompiler/BytecodeGenerator.h:
1514         FinallyJump, FinallyContext, TryData, TryContext and TryRange hold Ref<Label>
1515         instead of RefPtr<Label>. They are never nullptr.
1516
1517         (JSC::FinallyJump::FinallyJump):
1518         (JSC::FinallyContext::FinallyContext):
1519         (JSC::FinallyContext::registerJump):
1520         (JSC::BytecodeGenerator::emitNodeInConditionContext):
1521         (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
1522         * bytecompiler/Label.h:
1523         Make Label noncopyable.
1524
1525         * bytecompiler/LabelScope.h:
1526         (JSC::LabelScope::LabelScope):
1527         (JSC::LabelScope::breakTarget):
1528         breakTarget always returns Label&. On the other hand, continueTarget may be nullptr.
1529         So it returns Label*.
1530
1531         * bytecompiler/NodesCodegen.cpp:
1532         (JSC::ExpressionNode::emitBytecodeInConditionContext):
1533         (JSC::ConstantNode::emitBytecodeInConditionContext):
1534         (JSC::FunctionCallValueNode::emitBytecode):
1535         (JSC::CallFunctionCallDotNode::emitBytecode):
1536         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1537         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
1538         (JSC::BinaryOpNode::emitBytecodeInConditionContext):
1539         (JSC::InstanceOfNode::emitBytecode):
1540         (JSC::LogicalOpNode::emitBytecode):
1541         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
1542         (JSC::ConditionalNode::emitBytecode):
1543         (JSC::IfElseNode::emitBytecode):
1544         (JSC::DoWhileNode::emitBytecode):
1545         (JSC::WhileNode::emitBytecode):
1546         (JSC::ForNode::emitBytecode):
1547         (JSC::ForInNode::emitBytecode):
1548         (JSC::ContinueNode::trivialTarget):
1549         (JSC::ContinueNode::emitBytecode):
1550         (JSC::BreakNode::trivialTarget):
1551         (JSC::CaseBlockNode::emitBytecodeForBlock):
1552         (JSC::TryNode::emitBytecode):
1553         (JSC::FunctionNode::emitBytecode):
1554         (JSC::ClassExprNode::emitBytecode):
1555         (JSC::assignDefaultValueIfUndefined):
1556         (JSC::ArrayPatternNode::bindValue):
1557         Use Ref<Label> and Label&.
1558
1559         * parser/Nodes.h:
1560
1561 2017-02-15  Alex Christensen  <achristensen@webkit.org>
1562
1563         Unreviewed, rolling out r212394.
1564
1565         Fixed iOS WebInspector
1566
1567         Reverted changeset:
1568
1569         "Unreviewed, rolling out r212169."
1570         https://bugs.webkit.org/show_bug.cgi?id=166681
1571         http://trac.webkit.org/changeset/212394
1572
1573 2017-02-15  Guillaume Emont  <guijemont@igalia.com>
1574
1575         MIPS: add missing implementations of load8SignedExtendTo32()
1576
1577         JSC: missing implementations of MacroAssemblerMIPS::load8SignedExtendTo32()
1578         https://bugs.webkit.org/show_bug.cgi?id=168350
1579
1580         Reviewed by Yusuke Suzuki.
1581
1582         * assembler/MacroAssemblerMIPS.h:
1583         (JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
1584         Add missing implementations
1585
1586 2017-02-15  Alex Christensen  <achristensen@webkit.org>
1587
1588         Unreviewed, rolling out r212169.
1589
1590         Broke iOS WebInspector
1591
1592         Reverted changeset:
1593
1594         "WebInspector: refactor RemoteInspector to move cocoa specific
1595         code to their own files"
1596         https://bugs.webkit.org/show_bug.cgi?id=166681
1597         http://trac.webkit.org/changeset/212169
1598
1599 2017-02-15  Chris Dumez  <cdumez@apple.com>
1600
1601         Expose Symbol.toPrimitive / valueOf on Location instances
1602         https://bugs.webkit.org/show_bug.cgi?id=168295
1603
1604         Reviewed by Geoffrey Garen, Keith Miller and Mark Lam.
1605
1606         Cache origin objectProtoValueOf function on JSGlobalObject.
1607
1608         * runtime/JSGlobalObject.cpp:
1609         (JSC::JSGlobalObject::init):
1610         * runtime/JSGlobalObject.h:
1611         (JSC::JSGlobalObject::objectProtoValueOfFunction):
1612
1613 2017-02-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1614
1615         [JSC] Drop PassRefPtr
1616         https://bugs.webkit.org/show_bug.cgi?id=168320
1617
1618         Reviewed by Saam Barati.
1619
1620         * API/JSContextRef.cpp:
1621         (JSGlobalContextCreateInGroup):
1622         Use Ref<VM> from the factory function.
1623
1624         * API/JSScriptRef.cpp:
1625         (OpaqueJSScript::create):
1626         Return Ref<> instead.
1627
1628         * API/tests/JSONParseTest.cpp:
1629         (testJSONParse):
1630         Use Ref<VM>.
1631
1632         * assembler/LinkBuffer.cpp:
1633         (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
1634         Use reference since we already perform null check.
1635
1636         * assembler/MacroAssemblerCodeRef.h:
1637         (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
1638         Take Ref<>&& instead of PassRefPtr<>.
1639
1640         * bytecode/CallLinkInfo.h:
1641         (JSC::CallLinkInfo::setStub):
1642         (JSC::CallLinkInfo::setSlowStub):
1643         Take Ref<>&& instead of PassRefPtr<>.
1644
1645         * bytecode/CodeBlock.cpp:
1646         (JSC::CodeBlock::CodeBlock):
1647         Take RefPtr<SourceProvider>. Currently, the SourceProvider would be nullptr.
1648         We will change it to Ref<SourceProvider> in https://bugs.webkit.org/show_bug.cgi?id=168325.
1649
1650         (JSC::CodeBlock::finishCreation):
1651         Take Ref<TypeSet>&&.
1652
1653         * bytecode/CodeBlock.h:
1654         (JSC::CodeBlock::setJITCode):
1655         Take Ref<>&& instead.
1656
1657         (JSC::CodeBlock::jitCode):
1658         Return RefPtr<> instead.
1659
1660         * bytecode/EvalCodeBlock.h:
1661         (JSC::EvalCodeBlock::create):
1662         Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1663
1664         (JSC::EvalCodeBlock::EvalCodeBlock):
1665         * bytecode/FunctionCodeBlock.h:
1666         (JSC::FunctionCodeBlock::create):
1667         (JSC::FunctionCodeBlock::FunctionCodeBlock):
1668         Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1669
1670         * bytecode/GlobalCodeBlock.h:
1671         (JSC::GlobalCodeBlock::GlobalCodeBlock):
1672         Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1673
1674         * bytecode/ModuleProgramCodeBlock.h:
1675         (JSC::ModuleProgramCodeBlock::create):
1676         (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
1677         Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1678
1679         * bytecode/ProgramCodeBlock.h:
1680         (JSC::ProgramCodeBlock::create):
1681         (JSC::ProgramCodeBlock::ProgramCodeBlock):
1682         Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1683
1684         * debugger/DebuggerParseData.cpp:
1685         (JSC::gatherDebuggerParseDataForSource):
1686         Ensure the provider is not nullptr. It is OK because we already
1687         touch `provider->xxx` values.
1688
1689         * dfg/DFGBlockInsertionSet.cpp:
1690         (JSC::DFG::BlockInsertionSet::insert):
1691         Take Ref<>&& instead.
1692
1693         * dfg/DFGBlockInsertionSet.h:
1694         * dfg/DFGByteCodeParser.cpp:
1695         (JSC::DFG::ByteCodeParser::inlineCall):
1696         (JSC::DFG::ByteCodeParser::handleInlining):
1697         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1698         Pass Ref<>&& to appendBlock.
1699
1700         * dfg/DFGDriver.cpp:
1701         (JSC::DFG::compileImpl):
1702         (JSC::DFG::compile):
1703         Pass Ref<Plan>&&. And take Ref<>&& callback.
1704
1705         * dfg/DFGDriver.h:
1706         * dfg/DFGGraph.h:
1707         appendBlock takes Ref<>&&.
1708
1709         (JSC::DFG::Graph::appendBlock):
1710         * dfg/DFGJITCompiler.cpp:
1711         (JSC::DFG::JITCompiler::compile):
1712         (JSC::DFG::JITCompiler::compileFunction):
1713         * dfg/DFGJITCompiler.h:
1714         (JSC::DFG::JITCompiler::jitCode):
1715         * dfg/DFGJITFinalizer.cpp:
1716         (JSC::DFG::JITFinalizer::JITFinalizer):
1717         Take Ref<JITCode>&&.
1718
1719         (JSC::DFG::JITFinalizer::finalize):
1720         (JSC::DFG::JITFinalizer::finalizeFunction):
1721         (JSC::DFG::JITFinalizer::finalizeCommon):
1722         Pass compilation reference since we already perform null check.
1723
1724         * dfg/DFGJITFinalizer.h:
1725         * dfg/DFGWorklist.cpp:
1726         (JSC::DFG::Worklist::enqueue):
1727         Take Ref<Plan>&&.
1728
1729         * dfg/DFGWorklist.h:
1730         * ftl/FTLJITFinalizer.cpp:
1731         (JSC::FTL::JITFinalizer::finalizeFunction):
1732         Dereference and pass jitCode & compilation references.
1733
1734         * jit/GCAwareJITStubRoutine.cpp:
1735         (JSC::createJITStubRoutine):
1736         Return Ref<> instead.
1737
1738         * jit/GCAwareJITStubRoutine.h:
1739         (JSC::createJITStubRoutine):
1740         * jit/JIT.cpp:
1741         (JSC::JIT::link):
1742         Pass compilation reference since we already perform null check.
1743
1744         * jit/JITStubRoutine.h:
1745         (JSC::JITStubRoutine::asCodePtr):
1746         Take Ref<>&& instead. And this drops unnecessary null check.
1747
1748         * jit/JITThunks.cpp:
1749         (JSC::JITThunks::hostFunctionStub):
1750         Pass Ref<> to NativeExecutable::create.
1751
1752         * llint/LLIntEntrypoint.cpp:
1753         (JSC::LLInt::setFunctionEntrypoint):
1754         (JSC::LLInt::setEvalEntrypoint):
1755         (JSC::LLInt::setProgramEntrypoint):
1756         (JSC::LLInt::setModuleProgramEntrypoint):
1757         Use Ref<>&& instead.
1758
1759         * parser/SourceCode.h:
1760         (JSC::SourceCode::SourceCode):
1761         (JSC::SourceCode::subExpression):
1762         Add constructors taking Ref<>&&.
1763         We still have constructors that take RefPtr<>&&.
1764         We will change it to Ref<SourceProvider>&& in https://bugs.webkit.org/show_bug.cgi?id=168325.
1765
1766         * parser/UnlinkedSourceCode.h:
1767         (JSC::UnlinkedSourceCode::UnlinkedSourceCode):
1768         Add constructors taking Ref<>&&.
1769         We still have constructors that take RefPtr<>&&.
1770         We will change it to Ref<SourceProvider>&& in https://bugs.webkit.org/show_bug.cgi?id=168325.
1771
1772         * profiler/ProfilerDatabase.cpp:
1773         (JSC::Profiler::Database::addCompilation):
1774         Take Ref<Compilation>&&.
1775
1776         * profiler/ProfilerDatabase.h:
1777         Change data structures to hold Ref<> instead of RefPtr<>.
1778
1779         * runtime/EvalExecutable.h:
1780         (JSC::EvalExecutable::generatedJITCode):
1781         Return Ref<> instead.
1782
1783         * runtime/ExecutableBase.h:
1784         (JSC::ExecutableBase::generatedJITCodeForCall):
1785         (JSC::ExecutableBase::generatedJITCodeForConstruct):
1786         (JSC::ExecutableBase::generatedJITCodeFor):
1787         Return Ref<> instead.
1788
1789         * runtime/Identifier.cpp:
1790         (JSC::Identifier::add):
1791         (JSC::Identifier::add8):
1792         * runtime/Identifier.h:
1793         (JSC::Identifier::add):
1794         * runtime/JSGlobalObject.cpp:
1795         (JSC::JSGlobalObject::setInputCursor):
1796         And take Ref<> in this method.
1797
1798         * runtime/JSGlobalObject.h:
1799         (JSC::JSGlobalObject::inputCursor):
1800         Change m_inputCursor from RefPtr<> to Ref<>.
1801
1802         * runtime/JSPropertyNameEnumerator.cpp:
1803         (JSC::JSPropertyNameEnumerator::create):
1804         (JSC::JSPropertyNameEnumerator::finishCreation):
1805         Take Ref<PropertyNameArray>&&.
1806
1807         * runtime/JSPropertyNameEnumerator.h:
1808         (JSC::propertyNameEnumerator):
1809         * runtime/JSString.h:
1810         (JSC::JSString::JSString):
1811         Take Ref<StringImpl>&& since we do not allow nullptr in this constructor.
1812
1813         (JSC::JSString::create):
1814         (JSC::JSString::createHasOtherOwner):
1815         Take Ref<StringImpl>&& in these factory functions. And drop unnecessary assertions.
1816
1817         (JSC::jsSingleCharacterString):
1818         Use StringImpl::create() which returns Ref<>.
1819
1820         (JSC::jsNontrivialString):
1821         Dereference impl() since we ensure that `s.length() > 1`.
1822
1823         (JSC::jsString):
1824         Use releaseNonNull() since we ensure that `s.length() > 1`.
1825
1826         (JSC::jsOwnedString):
1827         Use releaseNonNull() since we ensure that `s.length() > 1`.
1828
1829         * runtime/ModuleProgramExecutable.h:
1830         * runtime/NativeExecutable.cpp:
1831         (JSC::NativeExecutable::create):
1832         (JSC::NativeExecutable::finishCreation):
1833         Take Ref<JITCode>&&.
1834
1835         * runtime/NativeExecutable.h:
1836         * runtime/ProgramExecutable.h:
1837         Return Ref<JITCode>.
1838
1839         * runtime/PropertyNameArray.h:
1840         (JSC::PropertyNameArray::releaseData):
1841         (JSC::PropertyNameArray::setData): Deleted.
1842         This is not used.
1843
1844         * runtime/RegExpKey.h:
1845         (JSC::RegExpKey::RegExpKey):
1846         Take RefPtr<>&&.
1847
1848         * runtime/SmallStrings.cpp:
1849         (JSC::SmallStringsStorage::rep):
1850         Return StringImpl& since m_reps is already initialized in the constructor.
1851
1852         (JSC::SmallStrings::createEmptyString):
1853         Dereference StringImpl::empty().
1854
1855         (JSC::SmallStrings::createSingleCharacterString):
1856         Use StringImpl&.
1857
1858         (JSC::SmallStrings::singleCharacterStringRep):
1859         Return StringImpl&.
1860
1861         (JSC::SmallStrings::initialize):
1862         Use AtomicStringImpl::add instead.
1863
1864         * runtime/SmallStrings.h:
1865         * runtime/Structure.cpp:
1866         (JSC::Structure::toStructureShape):
1867         Return Ref<>.
1868
1869         * runtime/Structure.h:
1870         * runtime/TypeLocationCache.cpp:
1871         (JSC::TypeLocationCache::getTypeLocation):
1872         Take RefPtr<TypeSet>&&.
1873
1874         * runtime/TypeLocationCache.h:
1875         * runtime/TypeProfilerLog.cpp:
1876         Pass Ref<>&&.
1877
1878         (JSC::TypeProfilerLog::processLogEntries):
1879         * runtime/TypeSet.cpp:
1880         (JSC::TypeSet::addTypeInformation):
1881         Take RefPtr<>&& since it can be nullptr.
1882         And clean up "not found" code.
1883
1884         (JSC::TypeSet::allStructureRepresentations):
1885         Use range based iteration.
1886
1887         (JSC::StructureShape::leastCommonAncestor):
1888         We found that this method accidentally takes `const Vector<>` instead of `const Vector<>&`.
1889         And internally, we just use raw pointers since these StructureShapes are owned by the m_proto trees which starts from the given Vector<>.
1890
1891         (JSC::StructureShape::hasSamePrototypeChain):
1892         Take const reference instead. And use raw pointers internally.
1893
1894         (JSC::StructureShape::merge):
1895         Take Ref<>&&.
1896
1897         * runtime/TypeSet.h:
1898         (JSC::StructureShape::setProto):
1899         Take Ref<>&&.
1900
1901         * runtime/VM.cpp:
1902         (JSC::VM::getHostFunction):
1903         Pass Ref<>&&.
1904
1905         (JSC::VM::queueMicrotask):
1906         Take and pass Ref<>&&.
1907
1908         * runtime/VM.h:
1909         (JSC::QueuedTask::QueuedTask):
1910         Take Ref<>&&.
1911
1912         * tools/FunctionOverrides.cpp:
1913         (JSC::initializeOverrideInfo):
1914         We need this change due to Ref<>&& and RefPtr<>&& ambiguity of SourceCode constructors.
1915         Once SourceCode is fixed to only take Ref<>&&, this change is unnecessary.
1916
1917 2017-02-15  Csaba Osztrogonác  <ossy@webkit.org>
1918
1919         [Mac][cmake] Unreviewed trivial buildfix after r212169.
1920         https://bugs.webkit.org/show_bug.cgi?id=166681
1921
1922         * PlatformMac.cmake: Removed inspector/remote/RemoteInspectorXPCConnection.mm.
1923
1924 2017-02-14  Mark Lam  <mark.lam@apple.com>
1925
1926         Add JSC_sweepSynchronously and fix JSC_useZombieMode options.
1927         https://bugs.webkit.org/show_bug.cgi?id=168257
1928         <rdar://problem/30451496>
1929
1930         Reviewed by Filip Pizlo.
1931
1932         JSC_useZombieMode now basically enables JSC_sweepSynchronously and
1933         JSC_scribbleFreeCells, which together does the job of zombifying dead objects
1934         immediately after a GC.
1935
1936         * heap/Heap.cpp:
1937         (JSC::Heap::sweepSynchronously):
1938         (JSC::Heap::collectAllGarbage):
1939         (JSC::Heap::finalize):
1940         (JSC::Heap::didFinishCollection):
1941         (JSC::Zombify::visit): Deleted.
1942         (JSC::Zombify::operator()): Deleted.
1943         (JSC::Heap::zombifyDeadObjects): Deleted.
1944         * heap/Heap.h:
1945         (JSC::Heap::isZombified): Deleted.
1946         * runtime/Options.cpp:
1947         (JSC::recomputeDependentOptions):
1948         * runtime/Options.h:
1949
1950 2017-02-13  Michael Saboff  <msaboff@apple.com>
1951
1952         asyncDisassembly crashes on iOS
1953         https://bugs.webkit.org/show_bug.cgi?id=168259
1954
1955         Reviewed by Filip Pizlo.
1956
1957         Eliminated the dumping of  the disassembly for the JIT write thunk.
1958         Not only does it fix the crash, but given the nature of the JIT
1959         write thunk, we probably don't want to disassemble it anyway.
1960         
1961         * jit/ExecutableAllocatorFixedVMPool.cpp:
1962         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
1963
1964 2017-02-12  Ryosuke Niwa  <rniwa@webkit.org>
1965
1966         C loop build fix attempt after r212207.
1967
1968         * runtime/Lookup.h:
1969
1970 2017-02-11  Sam Weinig  <sam@webkit.org>
1971
1972         Remove the remaining functions out of JSDOMBinding
1973         https://bugs.webkit.org/show_bug.cgi?id=168179
1974
1975         Reviewed by Darin Adler.
1976
1977         Move utility functions into more appropriate locations.
1978         - Move hasIteratorMethod to IteratorOperations.
1979         - Move nonCachingStaticFunctionGetter to Lookup
1980
1981         * runtime/IteratorOperations.cpp:
1982         (JSC::hasIteratorMethod):
1983         * runtime/IteratorOperations.h:
1984         * runtime/Lookup.h:
1985         (JSC::nonCachingStaticFunctionGetter):
1986
1987 2017-02-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1988
1989         [JSC] Implement (Shared)ArrayBuffer.prototype.byteLength
1990         https://bugs.webkit.org/show_bug.cgi?id=166476
1991
1992         Reviewed by Saam Barati.
1993
1994         `byteLength` becomes getter and is set in ArrayBuffer.prototype
1995         and SharedArrayBuffer.prototype. This patch implements the
1996         above getter in native function. We do not have any optimization
1997         path for that for now since ArrayBuffer.prototype.byteLength is
1998         not considered a hot function: while TypedArrays have [] accesses,
1999         ArrayBuffer does not have that. Thus byteLength getter is not so
2000         meaningful for a hot paths like iterations.
2001
2002         * runtime/JSArrayBuffer.cpp:
2003         (JSC::JSArrayBuffer::getOwnPropertySlot): Deleted.
2004         (JSC::JSArrayBuffer::put): Deleted.
2005         (JSC::JSArrayBuffer::defineOwnProperty): Deleted.
2006         (JSC::JSArrayBuffer::deleteProperty): Deleted.
2007         (JSC::JSArrayBuffer::getOwnNonIndexPropertyNames): Deleted.
2008         * runtime/JSArrayBuffer.h:
2009         (JSC::JSArrayBuffer::impl): Deleted.
2010         * runtime/JSArrayBufferPrototype.cpp:
2011         (JSC::arrayBufferProtoGetterFuncByteLength):
2012         (JSC::sharedArrayBufferProtoGetterFuncByteLength):
2013         (JSC::JSArrayBufferPrototype::finishCreation):
2014
2015 2017-02-10  Saam Barati  <sbarati@apple.com>
2016
2017         Object allocation sinking phase doesn't properly handle control flow when emitting a PutHint of a materialized object into a PromotedHeapLocation of a still sunken object
2018         https://bugs.webkit.org/show_bug.cgi?id=168140
2019         <rdar://problem/30205880>
2020
2021         Reviewed by Filip Pizlo.
2022
2023         This patch fixes a bug in allocation sinking phase where
2024         we don't properly handle control flow when materializing
2025         an object and also PutHinting that materialization into
2026         a still sunken object. We were performing the PutHint
2027         for the materialization at the point of materialization,
2028         however, we may have materialized along both edges
2029         of a control flow diamond, in which case, we need to
2030         also PutHint at the join point. Consider this program:
2031         
2032         ```
2033         bb#0:
2034         b: PhantomActivation()
2035         a: PhantomNewFunction()
2036         c: PutHint(@a, @b, ActivationLoc)
2037         Branch(#1, #2)
2038         
2039         bb#1:
2040         d: MaterializeActivation()
2041         e: PutHint(@a, @d, ActivationLoc)
2042         f: Upsilon(@d, ^p)
2043         Jump(#3)
2044         
2045         bb#2:
2046         g: MaterializeActivation()
2047         h: PutHint(@a, @g, ActivationLoc)
2048         i: Upsilon(@d, ^p)
2049         Jump(#3)
2050         
2051         bb#3:
2052         p: Phi()
2053         // What is PromotedHeapLocation(@a, ActivationLoc) here?
2054         // What would we do if we exited?
2055         ```
2056         Before this patch, we didn't perform a PutHint of the Phi.
2057         However, we need to, otherwise when exit, we won't know
2058         the value of PromotedHeapLocation(@a, ActivationLoc)
2059         
2060         The program we need then, for correctness, is this:
2061         ```
2062         bb#0:
2063         b: PhantomActivation()
2064         a: PhantomNewFunction()
2065         c: PutHint(@a, @b, ActivationLoc)
2066         Branch(#1, #2)
2067         
2068         bb#1:
2069         d: MaterializeActivation()
2070         e: PutHint(@a, @d, ActivationLoc)
2071         f: Upsilon(@d, ^p)
2072         Jump(#3)
2073         
2074         bb#2:
2075         g: MaterializeActivation()
2076         h: PutHint(@a, @g, ActivationLoc)
2077         i: Upsilon(@d, ^p)
2078         Jump(#3)
2079         
2080         bb#3:
2081         p: Phi()
2082         j: PutHint(@a, @p, ActivationLoc)
2083         ```
2084         
2085         This patch makes it so that we emit the necessary PutHint at node `j`.
2086         I've also added more validation to the OSRAvailabilityAnalysisPhase
2087         to catch this problem during validation.
2088
2089         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2090         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
2091         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2092         * ftl/FTLOperations.cpp:
2093         (JSC::FTL::operationMaterializeObjectInOSR):
2094
2095 2017-02-10  Carlos Garcia Campos  <cgarcia@igalia.com>
2096
2097         WebInspector: refactor RemoteInspector to move cocoa specific code to their own files
2098         https://bugs.webkit.org/show_bug.cgi?id=166681
2099
2100         Reviewed by Michael Catanzaro.
2101
2102         Move RemoteConnectionToTarget.mm and RemoteInspector.mm to a cocoa directory renamed with a Cocoa prefix,
2103         because those are now the cocoa implementation of RemoteConnectionToTarget and RemoteInspector. The
2104         cross-platform parts of RemoteInspector have been moced to a new RemoteInspector.cpp file. Also moved to cocoa
2105         directory RemoteInspectorXPCConnection.h and RemoteInspectorXPCConnection.mm keeping the same name. Other than
2106         that there aren't important code changes, only some cocoa specific types like NSString used in common headers,
2107         and some other platform ifdefs needed. This is in preparation for adding a remote inspector implementation for
2108         the GTK+ port.
2109
2110         * API/JSRemoteInspector.cpp:
2111         (JSRemoteInspectorSetParentProcessInformation): Add PLATFORM(COCOA) to the ifdef.
2112         * JavaScriptCore.xcodeproj/project.pbxproj:
2113         * PlatformMac.cmake:
2114         * inspector/remote/RemoteConnectionToTarget.h: Add platform ifdefs for cocoa specific parts and change
2115         sendMessageToTarget to receive a WTF String instead of an NSString.
2116         * inspector/remote/RemoteControllableTarget.h: Add platform ifdefs for CF specific parts.
2117         * inspector/remote/RemoteInspectionTarget.h:
2118         * inspector/remote/RemoteInspector.cpp: Added.
2119         (Inspector::RemoteInspector::startDisabled):
2120         (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
2121         (Inspector::RemoteInspector::registerTarget):
2122         (Inspector::RemoteInspector::unregisterTarget):
2123         (Inspector::RemoteInspector::updateTarget):
2124         (Inspector::RemoteInspector::updateClientCapabilities):
2125         (Inspector::RemoteInspector::setRemoteInspectorClient):
2126         (Inspector::RemoteInspector::setupFailed):
2127         (Inspector::RemoteInspector::setupCompleted):
2128         (Inspector::RemoteInspector::waitingForAutomaticInspection):
2129         (Inspector::RemoteInspector::clientCapabilitiesDidChange):
2130         (Inspector::RemoteInspector::stop):
2131         (Inspector::RemoteInspector::listingForTarget):
2132         (Inspector::RemoteInspector::updateHasActiveDebugSession):
2133         * inspector/remote/RemoteInspector.h: Add platform ifdefs for cocoa specific parts. Also add TargetListing
2134         typedef to define platform specific types for the listings without more ifdefs.
2135         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.mm.
2136         (Inspector::RemoteTargetInitializeGlobalQueue):
2137         (Inspector::RemoteConnectionToTarget::setup):
2138         (Inspector::RemoteConnectionToTarget::close):
2139         (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
2140         (Inspector::RemoteConnectionToTarget::setupRunLoop):
2141         * inspector/remote/cocoa/RemoteInspectorCocoa.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspector.mm.
2142         (Inspector::canAccessWebInspectorMachPort):
2143         (Inspector::RemoteInspector::singleton):
2144         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
2145         (Inspector::RemoteInspector::start):
2146         (Inspector::RemoteInspector::pushListingsSoon):
2147         (Inspector::RemoteInspector::receivedIndicateMessage):
2148         (Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
2149         * inspector/remote/cocoa/RemoteInspectorXPCConnection.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.h.
2150         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.mm.
2151         (Inspector::RemoteInspectorXPCConnection::closeFromMessage):
2152
2153 2017-02-10  Brian Burg  <bburg@apple.com>
2154
2155         [Cocoa] Web Inspector: payload initializers for ObjC protocol types handles special-cased property names incorrectly
2156         https://bugs.webkit.org/show_bug.cgi?id=168141
2157
2158         Reviewed by Joseph Pecoraro.
2159
2160         The generated code erroneously uses the ObjC variable name as the payload key,
2161         rather than the raw type member name. For example, 'identifier' would be used instead of 'id'.
2162
2163         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
2164         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
2165
2166         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
2167         Rebaseline an affected test.
2168
2169 2017-02-10  Mark Lam  <mark.lam@apple.com>
2170
2171         StructureStubInfo::considerCaching() should write barrier its owner CodeBlock when buffering a new Structure.
2172         https://bugs.webkit.org/show_bug.cgi?id=168137
2173         <rdar://problem/28656664>
2174
2175         Reviewed by Filip Pizlo.
2176
2177         If we're adding a new structure to StructureStubInfo's bufferedStructures, we
2178         should write barrier the StubInfo's owner CodeBlock because that structure may be
2179         collected during the next GC.  Write barrier-ing the owner CodeBlock ensures that
2180         CodeBlock::finalizeBaselineJITInlineCaches() is called on it during the GC,
2181         which, in turn, gives the StructureStubInfo the opportunity to filter out the
2182         dead structure.
2183
2184         * bytecode/StructureStubInfo.h:
2185         (JSC::StructureStubInfo::considerCaching):
2186         * jit/JITOperations.cpp:
2187
2188 2017-02-10  Brian Burg  <bburg@apple.com>
2189
2190         [Cocoa] Web Inspector: generate an NS_ENUM containing platforms supported by the protocol code generator
2191         https://bugs.webkit.org/show_bug.cgi?id=168019
2192         <rdar://problem/28718990>
2193
2194         Reviewed by Joseph Pecoraro.
2195
2196         It's useful to have an symbolic value (not a string) for each of the supported platform values.
2197         Generate this once per protocol for the Objective-C bindings. Covered by existing tests.
2198
2199         * inspector/scripts/codegen/generate_objc_header.py:
2200         (ObjCHeaderGenerator.generate_output):
2201         (ObjCHeaderGenerator._generate_enum_for_platforms):
2202         Create an NS_ENUM for Platform values in Platforms.
2203
2204         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
2205         (ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
2206         (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_for_platforms):
2207         Add type conversion/parsing methods for the newly added enum.
2208
2209         * inspector/scripts/codegen/generator.py:
2210         (Generator.stylized_name_for_enum_value):
2211         (Generator.stylized_name_for_enum_value.replaceCallback):
2212         Support arbitrary special-cased substrings in enums, not just all-caps. Add 'IOS' and 'MacOS'.
2213
2214         * inspector/scripts/codegen/models.py:
2215         (Platforms):
2216         Use lower-case string values for platform names, to avoid guesswork.
2217
2218         (Platforms.__metaclass__):
2219         (Platforms.__metaclass__.__iter__):
2220         Make it possible to iterate over Platform instances of Platforms.
2221
2222         * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
2223         * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
2224         * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
2225         * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
2226         * inspector/scripts/tests/generic/expected/domain-availability.json-result:
2227         * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
2228         * inspector/scripts/tests/generic/expected/enum-values.json-result:
2229         * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
2230         * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
2231         * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
2232         * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
2233         * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
2234         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
2235         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
2236         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
2237         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
2238         * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
2239         * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
2240         * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
2241         Rebaseline results.
2242
2243 2017-02-09  Filip Pizlo  <fpizlo@apple.com>
2244
2245         SharedArrayBuffer does not need to be in the transfer list
2246         https://bugs.webkit.org/show_bug.cgi?id=168079
2247
2248         Reviewed by Geoffrey Garen and Keith Miller.
2249         
2250         Exposes a simple shareWith() API for when you know you want to share the contents of
2251         a shared buffer. Also a useful explicit operator bool.
2252
2253         * runtime/ArrayBuffer.cpp:
2254         (JSC::ArrayBuffer::shareWith):
2255         * runtime/ArrayBuffer.h:
2256         (JSC::ArrayBufferContents::operator bool):
2257
2258 2017-02-09  Mark Lam  <mark.lam@apple.com>
2259
2260         B3::Procedure::deleteOrphans() should neutralize upsilons with dead phis.
2261         https://bugs.webkit.org/show_bug.cgi?id=167437
2262         <rdar://problem/30198083>
2263
2264         Reviewed by Filip Pizlo.
2265
2266         * b3/B3Procedure.cpp:
2267         (JSC::B3::Procedure::deleteOrphans):
2268
2269 2017-02-09  Saam Barati  <sbarati@apple.com>
2270
2271         Sloppy mode: We don't properly hoist functions names "arguments" when we have a non-simple parameter list
2272         https://bugs.webkit.org/show_bug.cgi?id=167319
2273         <rdar://problem/30149432>
2274
2275         Reviewed by Mark Lam.
2276
2277         When hoisting a function inside sloppy mode, we were assuming all "var"s are inside
2278         what we call the "var" SymbolTableEntry. This was almost true, execpt for "arguments",
2279         which has sufficiently weird behavior. "arguments" can be visible to the default
2280         parameter expressions inside a function, therefore can't go inside the "var"
2281         SymbolTableEntry since the parameter SymbolTableEntry comes before the "var"
2282         SymbolTableEntry in the scope chain.  Therefore, if we hoist a function named
2283         "arguments", then we must also look for that variable inside the parameter scope
2284         stack entry.
2285
2286         * bytecompiler/BytecodeGenerator.cpp:
2287         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
2288
2289 2017-02-09  Mark Lam  <mark.lam@apple.com>
2290
2291         Fix max length check in ArrayPrototype.js' concatSlowPath().
2292         https://bugs.webkit.org/show_bug.cgi?id=167270
2293         <rdar://problem/30128133>
2294
2295         Reviewed by Filip Pizlo.
2296
2297         1. Fixed concatSlowPath() to ensure that the result array length does not exceed
2298            @MAX_ARRAY_INDEX.  The old code was checking against @MAX_SAFE_INTEGER in some
2299            cases, but this is overly permissive.
2300
2301         2. Changed concatSlowPath() to throw a RangeError instead of a TypeError to be
2302            consistent with the C++ runtime functions in JSArray.cpp.
2303
2304         3. Changed the RangeError message in concatSlowPath() and JSArray.cpp to "Length
2305            exceeded the maximum array length" when the error is that the result length
2306            exceeds MAX_ARRAY_INDEX.  We do this for 2 reasons:
2307            a. "Length exceeded the maximum array length" is more informative than
2308               "Invalid array length".
2309            b. We want to use the same string consistently for the same error.
2310
2311            There are still 2 places in JSArray.cpp that still throws a RangeError with
2312            message "Invalid array length".  In those cases, the error is not necessarily
2313            due to the result length exceeding MAX_ARRAY_INDEX, but is due to attempting to
2314            set a length value that is not an integer that fits in MAX_ARRAY_INDEX e.g.
2315            an attempt to set a fractional length value.  Hence, "Invalid array length" is
2316            appropriate for those cases.
2317
2318         4. Fixed JSArray::appendMemcpy() to handle overflows when computing the result
2319            array length.
2320
2321         * builtins/ArrayPrototype.js:
2322         (concatSlowPath):
2323         * bytecode/BytecodeIntrinsicRegistry.cpp:
2324         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2325         * bytecode/BytecodeIntrinsicRegistry.h:
2326         * runtime/ArrayPrototype.cpp:
2327         (JSC::concatAppendOne):
2328         (JSC::arrayProtoPrivateFuncAppendMemcpy):
2329         * runtime/JSArray.cpp:
2330         (JSC::JSArray::appendMemcpy):
2331         (JSC::JSArray::push):
2332
2333 2017-02-09  Mark Lam  <mark.lam@apple.com>
2334
2335         Constructed object's global object should be the global object of the constructor.
2336         https://bugs.webkit.org/show_bug.cgi?id=167121
2337         <rdar://problem/30054759>
2338
2339         Reviewed by Filip Pizlo and Geoffrey Garen.
2340
2341         The realm (i.e. globalObject) of any object should be the same as the constructor
2342         that instantiated the object.  Changed PrototypeMap::createEmptyStructure() to
2343         be passed the correct globalObject to use instead of assuming it's the same one
2344         as the prototype object.
2345
2346         * bytecode/CodeBlock.cpp:
2347         (JSC::CodeBlock::finishCreation):
2348         * bytecode/InternalFunctionAllocationProfile.h:
2349         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
2350         * bytecode/ObjectAllocationProfile.h:
2351         (JSC::ObjectAllocationProfile::initialize):
2352         * runtime/FunctionRareData.cpp:
2353         (JSC::FunctionRareData::initializeObjectAllocationProfile):
2354         * runtime/FunctionRareData.h:
2355         (JSC::FunctionRareData::createInternalFunctionAllocationStructureFromBase):
2356         * runtime/InternalFunction.cpp:
2357         (JSC::InternalFunction::createSubclassStructure):
2358         * runtime/IteratorOperations.cpp:
2359         (JSC::createIteratorResultObjectStructure):
2360         * runtime/JSBoundFunction.cpp:
2361         (JSC::getBoundFunctionStructure):
2362         * runtime/JSFunction.cpp:
2363         (JSC::JSFunction::allocateAndInitializeRareData):
2364         (JSC::JSFunction::initializeRareData):
2365         * runtime/JSGlobalObject.cpp:
2366         (JSC::JSGlobalObject::init):
2367         * runtime/JSProxy.cpp:
2368         (JSC::JSProxy::setTarget):
2369         * runtime/ObjectConstructor.h:
2370         (JSC::constructEmptyObject):
2371         * runtime/PrototypeMap.cpp:
2372         (JSC::PrototypeMap::createEmptyStructure):
2373         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
2374         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
2375         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
2376         * runtime/PrototypeMap.h:
2377
2378 2017-02-09  Keith Miller  <keith_miller@apple.com>
2379
2380         We should not allow Function.caller to be used on native functions
2381         https://bugs.webkit.org/show_bug.cgi?id=165628
2382
2383         Reviewed by Mark Lam.
2384
2385         Also remove unneeded dynamic cast.
2386
2387         * runtime/JSFunction.cpp:
2388         (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
2389         (JSC::JSFunction::callerGetter):
2390
2391 2017-02-08  Keith Miller  <keith_miller@apple.com>
2392
2393         [JSC] op_in should have ArrayProfile
2394         https://bugs.webkit.org/show_bug.cgi?id=164581
2395
2396         Reviewed by Filip Pizlo.
2397
2398         This patch adds an ArrayProfile to the op_in bytecode. In the
2399         DFG, if we see that we the key is an int32 we will convert the In
2400         DFG node to a HasIndexedProperty node instead.
2401
2402         This patch also flips the two arguments of op_in and the In node
2403         to reflect the other property lookup bytecodes.
2404
2405         * bytecode/BytecodeList.json:
2406         * bytecode/CodeBlock.cpp:
2407         (JSC::CodeBlock::dumpBytecode):
2408         (JSC::CodeBlock::finishCreation):
2409         * bytecompiler/BytecodeGenerator.cpp:
2410         (JSC::BytecodeGenerator::emitIn):
2411         * bytecompiler/BytecodeGenerator.h:
2412         (JSC::BytecodeGenerator::emitIn): Deleted.
2413         * bytecompiler/NodesCodegen.cpp:
2414         (JSC::InNode::emitBytecode):
2415         * dfg/DFGByteCodeParser.cpp:
2416         (JSC::DFG::ByteCodeParser::parseBlock):
2417         * dfg/DFGFixupPhase.cpp:
2418         (JSC::DFG::FixupPhase::fixupNode):
2419         (JSC::DFG::FixupPhase::convertToHasIndexedProperty):
2420         * dfg/DFGNode.h:
2421         (JSC::DFG::Node::hasArrayMode):
2422         (JSC::DFG::Node::hasInternalMethodType):
2423         (JSC::DFG::Node::internalMethodType):
2424         (JSC::DFG::Node::setInternalMethodType):
2425         * dfg/DFGSpeculativeJIT.cpp:
2426         (JSC::DFG::SpeculativeJIT::compileIn):
2427         * dfg/DFGSpeculativeJIT.h:
2428         (JSC::DFG::SpeculativeJIT::callOperation):
2429         * dfg/DFGSpeculativeJIT32_64.cpp:
2430         (JSC::DFG::SpeculativeJIT::compile):
2431         * dfg/DFGSpeculativeJIT64.cpp:
2432         (JSC::DFG::SpeculativeJIT::compile):
2433         * ftl/FTLLowerDFGToB3.cpp:
2434         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
2435         (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
2436         * jit/JITOperations.cpp:
2437         * jit/JITOperations.h:
2438         * llint/LowLevelInterpreter.asm:
2439         * parser/Nodes.h:
2440         * runtime/CommonSlowPaths.cpp:
2441         (JSC::SLOW_PATH_DECL):
2442         * runtime/CommonSlowPaths.h:
2443         (JSC::CommonSlowPaths::opIn):
2444
2445 2017-02-08  Saam Barati  <sbarati@apple.com>
2446
2447         Air IRC might spill a terminal that produces a value after the terminal
2448         https://bugs.webkit.org/show_bug.cgi?id=167919
2449         <rdar://problem/29754721>
2450
2451         Reviewed by Filip Pizlo.
2452
2453         IRC may spill a value-producing terminal (a patchpoint can be a value-producing terminal).
2454         It used to do this by placing the spill *after* the terminal. This produces an invalid
2455         graph because no instructions are allowed after the terminal.
2456         
2457         I fixed this bug by having a cleanup pass over the IR after IRC is done.
2458         The pass detects this problem, and fixes it by moving the spill into the
2459         successors. However, it is careful to detect when the edge to the
2460         successor is a critical edge. If the value-producing patchpoint is
2461         the only predecessor of the successor, it just moves the spill
2462         code to the beginning of the successor. Otherwise, it's a critical
2463         edge and it breaks it by adding a block that does the spilling then
2464         jumps to the successor.
2465
2466         * b3/air/AirInsertionSet.cpp:
2467         * b3/air/AirInsertionSet.h:
2468         (JSC::B3::Air::InsertionSet::insertInsts):
2469         * b3/air/AirIteratedRegisterCoalescing.cpp:
2470         * b3/testb3.cpp:
2471         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
2472         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
2473         (JSC::B3::run):
2474
2475 2017-02-07  Mark Lam  <mark.lam@apple.com>
2476
2477         SigillCrashAnalyzer::analyze() should use a do-while loop instead of a lambda.
2478         https://bugs.webkit.org/show_bug.cgi?id=167950
2479
2480         Reviewed by Michael Saboff.
2481
2482         Lambdas aren't free (apparently, the compiler isn't able to detect that the
2483         lambda does not escape and can be inlined completely).  So, use a do-while loop
2484         instead since we don't really need a lambda here.
2485
2486         * tools/SigillCrashAnalyzer.cpp:
2487
2488 2017-02-05  Mark Lam  <mark.lam@apple.com>
2489
2490         The SigillCrashAnalyzer should play nicer with client code that may install its own SIGILL handler.
2491         https://bugs.webkit.org/show_bug.cgi?id=167858
2492
2493         Reviewed by Michael Saboff.
2494
2495         Here are the scenarios that may come up:
2496
2497         1. Client code did not install a SIGILL handler.
2498            - In this case, once we're done analyzing the SIGILL, we can just restore the
2499              default handler and return to let the OS do the default action i.e. capture
2500              a core dump.
2501
2502         2. Client code installed a SIGILL handler before JSC does.
2503            - In this case, we will see a non-null handler returned as the old signal
2504              handler when we install ours.
2505            - In our signal handler, after doing our crash analysis, we should invoke the
2506              client handler to let it do its work.
2507            - Our analyzer can also tell us if the SIGILL source is from JSC code in
2508              general (right now, this would just mean JIT code).
2509            - If the SIGILL source is not from JSC, we'll just let the client handler
2510              decided how to proceed.  We assume that the client handler will do the right
2511              thing (which is how the old behavior is before the SigillCrashAnalyzer was
2512              introduced).
2513            - If the SIGILL source is from JSC, then we know the SIGILL is an unrecoverable
2514              condition.  Hence, after we have given the client handler a chance to run,
2515              we should restore the default handler and let the OS capture a core dump.
2516              This intentionally overrides whatever signal settings the client handler may
2517              have set.
2518
2519         3. Client code installed a SIGILL handler after JSC does.
2520            - In this case, we are dependent on the client handler to call our handler
2521              after it does its work.  This is compatible with the old behavior before
2522              SigillCrashAnalyzer was introduced.
2523            - In our signal handler, if we determine that the SIGILL source is from JSC
2524              code, then the SIGILL is not recoverable.  We should then restore the
2525              default handler and get a core dump.
2526            - If the SIGILL source is not from JSC, we check to see if there's a client
2527              handler installed after us.
2528            - If we detect a client handler installed after us, we defer judgement on what
2529              to do to the client handler.  Since the client handler did not uninstall
2530              itself, it must have considered itself to have recovered from the SIGILL.
2531              We'll trust the client handler and take no restore action of our own (which
2532              is compatible with old code behavior).
2533            - If we detect no client handler and we have no previous handler, then we
2534              should restore the default handler and get a core dump.
2535
2536         * tools/SigillCrashAnalyzer.cpp:
2537         (JSC::handleCrash):
2538         (JSC::installCrashHandler):
2539         (JSC::SigillCrashAnalyzer::analyze): Deleted.
2540
2541 2017-02-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2542
2543         Unreviewed, manual roll out of r211777
2544         https://bugs.webkit.org/show_bug.cgi?id=167457
2545
2546         * jsc.cpp:
2547         (GlobalObject::moduleLoaderImportModule):
2548         * runtime/JSGlobalObjectFunctions.cpp:
2549         (JSC::globalFuncImportModule):
2550
2551 2017-02-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2552
2553         Web Inspector: allow import() inside the inspector
2554         https://bugs.webkit.org/show_bug.cgi?id=167457
2555
2556         Reviewed by Ryosuke Niwa.
2557
2558         We relax import module hook to accept null SourceOrigin.
2559         Such a script can be evaluated from the inspector console.
2560
2561         * jsc.cpp:
2562         (GlobalObject::moduleLoaderImportModule):
2563         * runtime/JSGlobalObjectFunctions.cpp:
2564         (JSC::globalFuncImportModule):
2565
2566 2017-02-06  Joseph Pecoraro  <pecoraro@apple.com>
2567
2568         Web Inspector: Do not use RunLoop when dispatching inspector GC event
2569         https://bugs.webkit.org/show_bug.cgi?id=167683
2570         <rdar://problem/30167791>
2571
2572         Reviewed by Brian Burg.
2573
2574         Move the RunLoop deferred implementation to WebCore. It is not needed
2575         for JSContext inspection, and in JSContext inspection we are not
2576         guarenteed a RunLoop to defer to.
2577
2578         * inspector/agents/InspectorHeapAgent.h:
2579         * inspector/agents/InspectorHeapAgent.cpp:
2580         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
2581         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
2582         (Inspector::InspectorHeapAgent::disable):
2583         (Inspector::InspectorHeapAgent::didGarbageCollect):
2584         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): Deleted.
2585         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection): Deleted.
2586         (Inspector::SendGarbageCollectionEventsTask::reset): Deleted.
2587         (Inspector::SendGarbageCollectionEventsTask::timerFired): Deleted.
2588
2589         (Inspector::InspectorHeapAgent::dispatchGarbageCollectedEvent):
2590         Make a virtual method so that WebCore implementations of this agent can choose
2591         to dispatch this event asynchronously.
2592
2593         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2594         Remove unnecessary RunLoop include.
2595
2596 2017-02-06  Joseph Pecoraro  <pecoraro@apple.com>
2597
2598         Static Analyzer: JSContext.mm: Incorrect decrement of the reference count of an object
2599         https://bugs.webkit.org/show_bug.cgi?id=167848
2600
2601         Reviewed by Saam Barati.
2602
2603         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
2604             [self.exceptionHandler release];
2605             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2606         1 warning generated.
2607
2608         * API/JSContext.mm:
2609         (-[JSContext dealloc]):
2610         Use the ivar in dealloc instead of going through the getter.
2611
2612 2017-02-05  Mark Lam  <mark.lam@apple.com>
2613
2614         The VMInspector should use an RAII Locker.
2615         https://bugs.webkit.org/show_bug.cgi?id=167854
2616
2617         Reviewed by Saam Barati.
2618
2619         Previously, VMInspector::lock() was returning an expected LockToken, and there's
2620         no way to unlock it when we're done with it.  This was not a problem before
2621         because the VMInspector had only one client, the SigillCrashAnalyzer, that
2622         expected the process to crash due to a SIGILL shortly thereafter.
2623
2624         However, the VMInspector is useful as a debugging tool that we can apply in other
2625         debugging tasks.  Fixing VMInspector::lock() to return an RAII locker will enable
2626         other use cases.  Plus it's just bad form to be able to lock something and never
2627         be able to unlock it.
2628
2629         * tools/SigillCrashAnalyzer.cpp:
2630         (JSC::SigillCrashAnalyzer::analyze):
2631         * tools/VMInspector.cpp:
2632         * tools/VMInspector.h:
2633
2634 2017-02-04  Joseph Pecoraro  <pecoraro@apple.com>
2635
2636         Static Analyzer: Value stored to 'recordedMachineThreads' during its initialization is never read
2637         https://bugs.webkit.org/show_bug.cgi?id=167845
2638
2639         Reviewed by Saam Barati.
2640
2641         Source/JavaScriptCore/heap/MachineStackMarker.cpp:151:14: warning: Value stored to 'recordedMachineThreads' during its initialization is never read
2642                 auto recordedMachineThreads = m_set.take(machineThreads);
2643                      ^~~~~~~~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~
2644
2645         * heap/MachineStackMarker.cpp:
2646         (JSC::ActiveMachineThreadsManager::remove):
2647
2648 2017-02-04  Joseph Pecoraro  <pecoraro@apple.com>
2649
2650         Static Analyzer: Value stored to 'prev' is never read
2651         https://bugs.webkit.org/show_bug.cgi?id=167844
2652
2653         Reviewed by Saam Barati.
2654
2655         Source/JavaScriptCore/runtime/JSMapIterator.h:60:13: warning: Value stored to 'prev' is never read
2656                     prev = bucket;
2657                     ^      ~~~~~~
2658         Source/JavaScriptCore/runtime/JSSetIterator.h:60:13: warning: Value stored to 'prev' is never read
2659                     prev = bucket;
2660                     ^      ~~~~~~
2661
2662         * runtime/JSMapIterator.h:
2663         (JSC::JSMapIterator::advanceIter):
2664         * runtime/JSSetIterator.h:
2665         (JSC::JSSetIterator::advanceIter):
2666
2667 2017-02-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2668
2669         [JSC] Add operationToInt32SensibleSlow to optimize kraken pbkdf2 and sha256
2670         https://bugs.webkit.org/show_bug.cgi?id=167736
2671
2672         Reviewed by Saam Barati.
2673
2674         Add a new function operationToInt32SensibleSlow. This function is only
2675         called after x86 cvttss2si_rr is failed. This means that the
2676         given double number never in range of int32 truncatable numbers.
2677
2678         As a result, exp in operationToInt32 always becomes >= 31. So
2679         we can change the condition from `exp < 32` to `exp == 31`.
2680         This makes missingOne constant. And it leads significantly good
2681         code generation.
2682
2683         The original operationToInt32 code.
2684
2685             170:   66 48 0f 7e c1          movq   %xmm0,%rcx
2686             175:   31 c0                   xor    %eax,%eax
2687             177:   66 48 0f 7e c6          movq   %xmm0,%rsi
2688             17c:   48 c1 f9 34             sar    $0x34,%rcx
2689             180:   81 e1 ff 07 00 00       and    $0x7ff,%ecx
2690             186:   8d 91 01 fc ff ff       lea    -0x3ff(%rcx),%edx
2691             18c:   83 fa 53                cmp    $0x53,%edx
2692             18f:   77 37                   ja     1c8 <_ZN3JSC16operationToInt32Ed+0x58>
2693             191:   83 fa 34                cmp    $0x34,%edx
2694             194:   7f 3a                   jg     1d0 <_ZN3JSC16operationToInt32Ed+0x60>
2695             196:   b9 34 00 00 00          mov    $0x34,%ecx
2696             19b:   66 48 0f 7e c7          movq   %xmm0,%rdi
2697             1a0:   29 d1                   sub    %edx,%ecx
2698             1a2:   48 d3 ff                sar    %cl,%rdi
2699             1a5:   83 fa 1f                cmp    $0x1f,%edx
2700             1a8:   89 f8                   mov    %edi,%eax
2701             1aa:   7f 12                   jg     1be <_ZN3JSC16operationToInt32Ed+0x4e>
2702             1ac:   89 d1                   mov    %edx,%ecx
2703             1ae:   b8 01 00 00 00          mov    $0x1,%eax
2704             1b3:   d3 e0                   shl    %cl,%eax
2705             1b5:   89 c2                   mov    %eax,%edx
2706             1b7:   8d 40 ff                lea    -0x1(%rax),%eax
2707             1ba:   21 f8                   and    %edi,%eax
2708             1bc:   01 d0                   add    %edx,%eax
2709             1be:   89 c2                   mov    %eax,%edx
2710             1c0:   f7 da                   neg    %edx
2711             1c2:   48 85 f6                test   %rsi,%rsi
2712             1c5:   0f 48 c2                cmovs  %edx,%eax
2713             1c8:   f3 c3                   repz retq
2714             1ca:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
2715             1d0:   66 48 0f 7e c0          movq   %xmm0,%rax
2716             1d5:   81 e9 33 04 00 00       sub    $0x433,%ecx
2717             1db:   48 d3 e0                shl    %cl,%rax
2718             1de:   eb de                   jmp    1be <_ZN3JSC16operationToInt32Ed+0x4e>
2719
2720         The operationToInt32SensibleSlow code.
2721
2722             1e0:   66 48 0f 7e c1          movq   %xmm0,%rcx
2723             1e5:   66 48 0f 7e c2          movq   %xmm0,%rdx
2724             1ea:   48 c1 f9 34             sar    $0x34,%rcx
2725             1ee:   81 e1 ff 07 00 00       and    $0x7ff,%ecx
2726             1f4:   8d b1 01 fc ff ff       lea    -0x3ff(%rcx),%esi
2727             1fa:   83 fe 34                cmp    $0x34,%esi
2728             1fd:   7e 21                   jle    220 <_ZN3JSC28operationToInt32SensibleSlowEd+0x40>
2729             1ff:   66 48 0f 7e c0          movq   %xmm0,%rax
2730             204:   81 e9 33 04 00 00       sub    $0x433,%ecx
2731             20a:   48 d3 e0                shl    %cl,%rax
2732             20d:   89 c1                   mov    %eax,%ecx
2733             20f:   f7 d9                   neg    %ecx
2734             211:   48 85 d2                test   %rdx,%rdx
2735             214:   0f 48 c1                cmovs  %ecx,%eax
2736             217:   c3                      retq
2737             218:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
2738             21f:   00
2739             220:   66 48 0f 7e c0          movq   %xmm0,%rax
2740             225:   b9 34 00 00 00          mov    $0x34,%ecx
2741             22a:   29 f1                   sub    %esi,%ecx
2742             22c:   48 d3 f8                sar    %cl,%rax
2743             22f:   89 c1                   mov    %eax,%ecx
2744             231:   81 c9 00 00 00 80       or     $0x80000000,%ecx
2745             237:   83 fe 1f                cmp    $0x1f,%esi
2746             23a:   0f 44 c1                cmove  %ecx,%eax
2747             23d:   89 c1                   mov    %eax,%ecx
2748             23f:   f7 d9                   neg    %ecx
2749             241:   48 85 d2                test   %rdx,%rdx
2750             244:   0f 48 c1                cmovs  %ecx,%eax
2751             247:   c3                      retq
2752             248:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
2753             24f:   00
2754
2755         This improves kraken pbkdf2 by 10.8% and sha256 by 7.5%.
2756
2757                                                        baseline                  patched
2758
2759             stanford-crypto-pbkdf2                 153.195+-2.745      ^     138.204+-2.513         ^ definitely 1.1085x faster
2760             stanford-crypto-sha256-iterative        49.047+-1.038      ^      45.610+-1.235         ^ definitely 1.0754x faster
2761
2762             <arithmetic>                           101.121+-1.379      ^      91.907+-1.500         ^ definitely 1.1003x faster
2763
2764         * assembler/CPU.h:
2765         (JSC::hasSensibleDoubleToInt):
2766         * dfg/DFGSpeculativeJIT.cpp:
2767         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
2768         * ftl/FTLLowerDFGToB3.cpp:
2769         (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
2770         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
2771         * ftl/FTLOutput.cpp:
2772         (JSC::FTL::Output::hasSensibleDoubleToInt): Deleted.
2773         * ftl/FTLOutput.h:
2774         * runtime/MathCommon.cpp:
2775         (JSC::operationToInt32SensibleSlow):
2776         * runtime/MathCommon.h:
2777
2778 2017-02-03  Joseph Pecoraro  <pecoraro@apple.com>
2779
2780         Unreviewed rollout of r211486, r211629.
2781
2782         Original change is not ideal and is causing issues.
2783
2784         * inspector/agents/InspectorHeapAgent.cpp:
2785         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
2786         * runtime/InitializeThreading.cpp:
2787         (JSC::initializeThreading):
2788
2789 2017-02-03  JF Bastien  <jfbastien@apple.com>
2790
2791         OSR entry: delay outer-loop compilation when at inner-loop
2792         https://bugs.webkit.org/show_bug.cgi?id=167149
2793
2794         Reviewed by Filip Pizlo.
2795
2796         r211224 and r211461 were reverted because they caused massive
2797         kraken/ai-astar regressions. This patch instead does the
2798         minimally-disruptive change to fix the original bug as described
2799         below, but omits extra tuning and refactoring which I had
2800         before. I'll commit tuning and refactoring separately, if this
2801         sticks. This patch is therefore very minimal, and layers carefully
2802         on top of the complex spaghetti-logic. The only change it makes is
2803         that it uses triggers to indicate to outer loops that they should
2804         compile, which fixes the immediate bug and seems roughly perf
2805         neutral (maybe a small gain on kraken sometimes, other times a
2806         small regression as would be expected from slightly compiling
2807         later). As opposed to r211461 this patch doesn't unconditionally
2808         unset the trigger because it prevents further DFG executions from
2809         entering. It therefore makes the trigger a tri-state enum class:
2810         don't trigger, compilation done, start compilation. Only "start
2811         compilation" gets reset to "don't trigger". "Compilation done"
2812         does not (unless there's a problem compiling, then it gets set
2813         back to "don't trigger").
2814
2815         As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
2816         compilation can be kicked off for an entry into an outer-loop,
2817         while executing an inner-loop. This is desirable because often the
2818         codegen from an inner-entry isn't as good as the codegen from an
2819         outer-entry, but execution from an inner-loop is often pretty hot
2820         and likely to kick off compilation. This approach provided nice
2821         speedups on Kraken because we'd select to enter to the outer-loop
2822         very reliably, which reduces variability (the inner-loop was
2823         selected roughly 1/5 times from my unscientific measurements).
2824
2825         When compilation starts we take a snapshot of the JSValues at the
2826         current execution state using OSR's recovery mechanism. These
2827         values are passed to the compiler and are used as way to perform
2828         type profiling, and could be used to observe cell types as well as
2829         to perform predictions such as through constant propagation.
2830
2831         It's therefore desired to enter from the outer-loop when we can,
2832         but we need to be executing from that location to capture the
2833         right JSValues, otherwise we're confusing the compiler and giving
2834         it inaccurate JSValues which can lead it to predict the wrong
2835         things, leading to suboptimal code or recompilation due to
2836         misprediction, or in super-corner-cases a crash.
2837
2838         DFG tier-up was added here:
2839         https://bugs.webkit.org/show_bug.cgi?id=112838
2840
2841         * dfg/DFGJITCode.h:
2842         * dfg/DFGJITCompiler.cpp:
2843         (JSC::DFG::JITCompiler::JITCompiler):
2844         * dfg/DFGOperations.cpp:
2845         * dfg/DFGSpeculativeJIT64.cpp:
2846         (JSC::DFG::SpeculativeJIT::compile):
2847         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
2848         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
2849         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
2850         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
2851         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
2852         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
2853
2854 2017-02-03  Saam Barati  <sbarati@apple.com>
2855
2856         When OSR entering to the baseline JIT from the LLInt for a ProgramCodeBlock we can skip compiling a lot of the program
2857         https://bugs.webkit.org/show_bug.cgi?id=167725
2858         <rdar://problem/30339082>
2859
2860         Reviewed by Michael Saboff.
2861
2862         We often want to baseline compile ProgramCode once we hit a loop in the LLInt.
2863         However, some programs execute a non-trivial amount of code before the loop.
2864         This code can never be executed again because ProgramCodeBlocks never run more
2865         than once. We're wasting time and memory by compiling code that is unreachable
2866         from the OSR entry destination. This patch fixes this by only compiling code
2867         that is reachable from the OSR entry destination.
2868
2869         This is a speedup on Kraken/ai-astar for devices with limited CPUs (I've been
2870         testing on devices with 2 CPUs). On ai-astar, we were spending 50-100ms compiling
2871         a huge ProgramCodeBlock in the baseline JIT where the majority of the code
2872         would never execute. If this compilation was kicked off on the main thread,
2873         then we'd be stalled for a long time. If it were started on the baseline JITs
2874         background compilation thread, we'd still waste 50-100ms in that thread, causing
2875         all other baseline compilations to happen on the main thread.
2876
2877         * interpreter/Interpreter.cpp:
2878         (JSC::Interpreter::executeProgram):
2879         * interpreter/Interpreter.h:
2880         * jit/JIT.cpp:
2881         (JSC::JIT::JIT):
2882         (JSC::JIT::privateCompileMainPass):
2883         * jit/JIT.h:
2884         (JSC::JIT::compile):
2885         * jit/JITWorklist.cpp:
2886         (JSC::JITWorklist::Plan::Plan):
2887         (JSC::JITWorklist::Plan::compileNow):
2888         (JSC::JITWorklist::compileLater):
2889         (JSC::JITWorklist::compileNow):
2890         * jit/JITWorklist.h:
2891         * llint/LLIntSlowPaths.cpp:
2892         (JSC::LLInt::jitCompileAndSetHeuristics):
2893         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2894         * runtime/Completion.cpp:
2895         (JSC::evaluate):
2896
2897 2017-02-03  Csaba Osztrogonác  <ossy@webkit.org>
2898
2899         Unreviewed typo fix after r211630.
2900
2901         * CMakeLists.txt:
2902
2903 2017-02-03  Carlos Garcia Campos  <cgarcia@igalia.com>
2904
2905         [GTK] Add initial implementation of resource usage overlay
2906         https://bugs.webkit.org/show_bug.cgi?id=167731
2907
2908         Reviewed by Michael Catanzaro.
2909
2910         Also expose nextFireTime() for GTK+ port.
2911
2912         * heap/GCActivityCallback.cpp:
2913         (JSC::GCActivityCallback::scheduleTimer):
2914         (JSC::GCActivityCallback::cancelTimer):
2915         * heap/GCActivityCallback.h:
2916
2917 2017-02-03  Csaba Osztrogonác  <ossy@webkit.org>
2918
2919         [cmake] Unreviewed AArch64 buildfix after r211603.
2920         https://bugs.webkit.org/show_bug.cgi?id=167714
2921
2922         * CMakeLists.txt:
2923
2924 2017-02-02  Andreas Kling  <akling@apple.com>
2925
2926         [Mac] In-process memory pressure monitor for WebContent processes AKA websam
2927         <https://webkit.org/b/167491>
2928         <rdar://problem/30116072>
2929
2930         Reviewed by Antti Koivisto.
2931
2932         Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
2933         WebCore-side memory footprint monitor.
2934
2935         * heap/Heap.cpp:
2936         (JSC::Heap::updateAllocationLimits):
2937         (JSC::Heap::didExceedMaxLiveSize): Deleted.
2938         * heap/Heap.h:
2939         (JSC::Heap::setMaxLiveSize): Deleted.
2940
2941 2017-02-02  Mark Lam  <mark.lam@apple.com>
2942
2943         Add a SIGILL crash analyzer to make debugging SIGILLs easier.
2944         https://bugs.webkit.org/show_bug.cgi?id=167714
2945         <rdar://problem/30318237>
2946
2947         Not reviewed.
2948
2949         Build fix for CLOOP build.
2950
2951         * tools/VMInspector.cpp:
2952
2953 2017-02-02  Mark Lam  <mark.lam@apple.com>
2954
2955         Add a SIGILL crash analyzer to make debugging SIGILLs easier.
2956         https://bugs.webkit.org/show_bug.cgi?id=167714
2957         <rdar://problem/30318237>
2958
2959         Reviewed by Filip Pizlo.
2960
2961         The current implementation is only for X86_64 and ARM64 on OS(DARWIN).  The
2962         analyzer is not enabled for all other ports.
2963
2964         * CMakeLists.txt:
2965         * JavaScriptCore.xcodeproj/project.pbxproj:
2966         * API/JSVirtualMachine.mm:
2967         * assembler/ARM64Assembler.h:
2968         (JSC::ARM64Assembler::illegalInstruction):
2969         * assembler/MacroAssemblerARM64.h:
2970         (JSC::MacroAssemblerARM64::illegalInstruction):
2971         * assembler/MacroAssemblerX86Common.h:
2972         (JSC::MacroAssemblerX86Common::illegalInstruction):
2973         * assembler/X86Assembler.h:
2974         (JSC::X86Assembler::illegalInstruction):
2975         * heap/Heap.cpp:
2976         (JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
2977         * heap/Heap.h:
2978         * heap/HeapInlines.h:
2979         (JSC::Heap::forEachCodeBlockIgnoringJITPlans):
2980         * runtime/Options.cpp:
2981         (JSC::Options::isAvailable):
2982         (JSC::recomputeDependentOptions):
2983         * runtime/Options.h:
2984         * runtime/VM.cpp:
2985         (JSC::VM::VM):
2986         (JSC::VM::~VM):
2987         * runtime/VM.h:
2988         * tools/SigillCrashAnalyzer.cpp: Added.
2989         (JSC::SignalContext::SignalContext):
2990         (JSC::SignalContext::dump):
2991         (JSC::handleCrash):
2992         (JSC::initializeCrashHandler):
2993         (JSC::ensureSigillCrashAnalyzer):
2994         (JSC::SigillCrashAnalyzer::analyze):
2995         (JSC::SigillCrashAnalyzer::dumpCodeBlock):
2996         * tools/SigillCrashAnalyzer.h: Added.
2997         * tools/VMInspector.cpp: Added.
2998         (JSC::VMInspector::instance):
2999         (JSC::VMInspector::add):
3000         (JSC::VMInspector::remove):
3001         (JSC::ensureIsSafeToLock):
3002         * tools/VMInspector.h: Added.
3003         (JSC::VMInspector::iterate):
3004
3005 2017-02-02  Chris Dumez  <cdumez@apple.com>
3006
3007         {}.toString.call(crossOriginWindow) should return "[object Object]"
3008         https://bugs.webkit.org/show_bug.cgi?id=167701
3009         <rdar://problem/30330797>
3010
3011         Reviewed by Keith Miller.
3012
3013         Have JSProxy forward toStringName calls to its target so Window
3014         can override it.
3015
3016         * runtime/JSProxy.cpp:
3017         (JSC::JSProxy::toStringName):
3018         * runtime/JSProxy.h:
3019
3020 2017-02-02  Commit Queue  <commit-queue@webkit.org>
3021
3022         Unreviewed, rolling out r211571 and r211582.
3023         https://bugs.webkit.org/show_bug.cgi?id=167751
3024
3025         This change caused API test WebKit1.MemoryPressureHandler to
3026         fail with an assertion. (Requested by ryanhaddad on #webkit).
3027
3028         Reverted changesets:
3029
3030         "[Mac] In-process memory pressure monitor for WebContent
3031         processes."
3032         https://bugs.webkit.org/show_bug.cgi?id=167491
3033         http://trac.webkit.org/changeset/211571
3034
3035         "Unreviewed attempt to fix the Windows build after r211571."
3036         http://trac.webkit.org/changeset/211582
3037
3038 2017-02-02  Andreas Kling  <akling@apple.com>
3039
3040         [Mac] In-process memory pressure monitor for WebContent processes.
3041         <https://webkit.org/b/167491>
3042         <rdar://problem/30116072>
3043
3044         Reviewed by Antti Koivisto.
3045
3046         Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
3047         WebCore-side memory footprint monitor.
3048
3049         * heap/Heap.cpp:
3050         (JSC::Heap::updateAllocationLimits):
3051         (JSC::Heap::didExceedMaxLiveSize): Deleted.
3052         * heap/Heap.h:
3053         (JSC::Heap::setMaxLiveSize): Deleted.
3054
3055 2017-02-02  Joseph Pecoraro  <pecoraro@apple.com>
3056
3057         Removed unused m_errorHandlingModeReentry from Interpreter
3058         https://bugs.webkit.org/show_bug.cgi?id=167726
3059
3060         Reviewed by Yusuke Suzuki.
3061
3062         * interpreter/Interpreter.cpp:
3063         (JSC::Interpreter::Interpreter):
3064         * interpreter/Interpreter.h:
3065
3066 2017-02-01  Commit Queue  <commit-queue@webkit.org>
3067
3068         Unreviewed, rolling out r211461.
3069         https://bugs.webkit.org/show_bug.cgi?id=167721
3070
3071         Big regression on kraken (Requested by jfbastien on #webkit).
3072
3073         Reverted changeset:
3074
3075         "OSR entry: delay outer-loop compilation when at inner-loop"
3076         https://bugs.webkit.org/show_bug.cgi?id=167149
3077         http://trac.webkit.org/changeset/211461
3078
3079 2017-02-01  Keith Miller  <keith_miller@apple.com>
3080
3081         Unreviewed, fix unintended change.
3082
3083         * runtime/SamplingProfiler.cpp:
3084         (JSC::SamplingProfiler::StackFrame::displayName):
3085
3086 2017-02-01  Keith Miller  <keith_miller@apple.com>
3087
3088         The sampling profile should have an option to sample from C frames.
3089         https://bugs.webkit.org/show_bug.cgi?id=167614
3090
3091         Reviewed by Saam Barati.
3092
3093         We should be able to use the sampling profiler, at least
3094         internally, to trace C calls.  This patch only modifies the JSC
3095         shell although it would be nice to add it to the Web Inspector in
3096         a future patch.
3097
3098         * runtime/Options.h:
3099         * runtime/SamplingProfiler.cpp:
3100         (JSC::FrameWalker::FrameWalker):
3101         (JSC::FrameWalker::walk):
3102         (JSC::FrameWalker::recordJSFrame):
3103         (JSC::CFrameWalker::CFrameWalker):
3104         (JSC::CFrameWalker::walk):
3105         (JSC::CFrameWalker::isCFrame):
3106         (JSC::CFrameWalker::advanceToParentFrame):
3107         (JSC::CFrameWalker::frame):
3108         (JSC::SamplingProfiler::takeSample):
3109         (JSC::SamplingProfiler::processUnverifiedStackTraces):
3110         (JSC::SamplingProfiler::StackFrame::displayName):
3111         * runtime/SamplingProfiler.h:
3112         (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
3113
3114 2017-02-01  Joseph Pecoraro  <pecoraro@apple.com>
3115
3116         Web Inspector: Use guaranteed RunLoop instead of RunLoop::current for dispatching inspector GC event
3117         https://bugs.webkit.org/show_bug.cgi?id=167683
3118         <rdar://problem/30167791>
3119
3120         Reviewed by Timothy Hatcher.
3121
3122         * inspector/agents/InspectorHeapAgent.cpp:
3123         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
3124         Use RunLoop::main instead of RunLoop::current which may go away.
3125
3126         * runtime/InitializeThreading.cpp:
3127         (JSC::initializeThreading):
3128         Ensure RunLoop::main is initialized when using JSC APIs.
3129
3130 2017-02-01  Yusuke Suzuki  <utatane.tea@gmail.com>
3131
3132         ArityFixup should adjust SP first
3133         https://bugs.webkit.org/show_bug.cgi?id=167239
3134
3135         Reviewed by Michael Saboff.
3136
3137         Arity fixup extends the stack and copy/fill the stack with
3138         the values. At that time, we accidentally read/write stack
3139         space below the stack pointer. As a result, we touch the area
3140         of the stack space below the x64 red zone. These areas are unsafe.
3141         OS may corrupt this space when constructing a signal stack.
3142         The Linux kernel could not populate the pages for this space
3143         and causes segmentation fault. This patch changes the stack
3144         pointer before performing the arity fixup.
3145
3146         * jit/ThunkGenerators.cpp:
3147         (JSC::arityFixupGenerator):
3148         * llint/LowLevelInterpreter32_64.asm:
3149         * llint/LowLevelInterpreter64.asm:
3150
3151 2017-01-31  Filip Pizlo  <fpizlo@apple.com>
3152
3153         Make verifyEdge a RELEASE_ASSERT
3154         <rdar://problem/30296879>
3155
3156         Rubber stamped by Saam Barati.
3157
3158         * dfg/DFGAbstractInterpreterInlines.h:
3159         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3160
3161 2017-01-31  JF Bastien  <jfbastien@apple.com>
3162
3163         OSR entry: delay outer-loop compilation when at inner-loop
3164         https://bugs.webkit.org/show_bug.cgi?id=167149
3165
3166         Reviewed by Filip Pizlo.
3167
3168         r211224 was reverted because it caused a massive kraken/ai-astar
3169         regression. This patch instead does the minimally-disruptive
3170         change to fix the original bug as described below, but omits extra
3171         tuning and refactoring which I had before. I'll commit tuning and
3172         refactoring separately, if this sticks. This patch is therefore
3173         very minimal, and layers carefully on top of the complex
3174         spaghetti-logic. The only change it makes is that it uses triggers
3175         to indicate to outer loops that they should compile, which fixes
3176         the immediate bug and seems roughly perf neutral (maybe a small
3177         gain on kraken sometimes, other times a small regression as would
3178         be expected from compiling later).
3179
3180         As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
3181         compilation can be kicked off for an entry into an outer-loop,
3182         while executing an inner-loop. This is desirable because often the
3183         codegen from an inner-entry isn't as good as the codegen from an
3184         outer-entry, but execution from an inner-loop is often pretty hot
3185         and likely to kick off compilation. This approach provided nice
3186         speedups on Kraken because we'd select to enter to the outer-loop
3187         very reliably, which reduces variability (the inner-loop was
3188         selected roughly 1/5 times from my unscientific measurements).
3189
3190         When compilation starts we take a snapshot of the JSValues at the
3191         current execution state using OSR's recovery mechanism. These
3192         values are passed to the compiler and are used as way to perform
3193         type profiling, and could be used to observe cell types as well as
3194         to perform predictions such as through constant propagation.
3195
3196         It's therefore desired to enter from the outer-loop when we can,
3197         but we need to be executing from that location to capture the
3198         right JSValues, otherwise we're confusing the compiler and giving
3199         it inaccurate JSValues which can lead it to predict the wrong
3200         things, leading to suboptimal code or recompilation due to
3201         misprediction, or in super-corner-cases a crash.
3202
3203         These effects are pretty hard to measure: Fil points out that
3204         marsalis-osr-entry really needs mustHandleValues (the JSValues
3205         from the point of execution) because right now it just happens to
3206         correctly guess int32. I tried removing mustHandleValues entirely
3207         and saw no slowdowns, but our benchmarks probably aren't
3208         sufficient to reliably find issues, sometimes because we happen to
3209         have sufficient mitigations.
3210
3211         DFG tier-up was added here:
3212         https://bugs.webkit.org/show_bug.cgi?id=112838
3213
3214         * dfg/DFGOperations.cpp:
3215
3216 2017-01-31  Filip Pizlo  <fpizlo@apple.com>
3217
3218         The mutator should be able to perform increments of GC work
3219         https://bugs.webkit.org/show_bug.cgi?id=167528
3220
3221         Reviewed by Keith Miller and Geoffrey Garen.
3222
3223         The cool thing about having a concurrent and parallel collector is that it's easy to also make
3224         it incremental, because the load balancer can also hand over work to anyone (including the
3225         mutator) and since the collector is running concurrently anyway, the mutator can usually rely
3226         on the balancer having some spare work.
3227
3228         This change adds a classic work-based incremental mode to the GC. When you allocate K bytes,
3229         you have to do Options::gcIncrementScale() * K "bytes" of draining. This is ammortized so that
3230         it only happens in allocation slow paths.
3231
3232         On computers that have a lot of CPUs, this mode is not profitable and we set gcIncrementScale
3233         to zero. On such computers, Riptide was already performing great because there was no way that
3234         one mutator thread could outpace many GC threads. But on computers with fewer CPUs, there were
3235         problems having to do with making the collector progress quickly enough so that the heap
3236         doesn't grow too much. The stochastic scheduler actually made things worse, because it relies
3237         a lot on the fact that the GC will simply be faster than the mutator anyway. The old scheduler
3238         claimed to address the problem of GC pace, but it used a time-based scheduler, which is not as
3239         precise at keeping pase as the new work-based incremental mode.
3240
3241         In theory, the work-based mode guarantees a bound on how much the heap can grow during a
3242         collection just because each byte allocated means some number of bytes visited. We don't try
3243         to create such a theoretical bound. We're just trying to give the collector an unfair advantage
3244         in any race with the mutator.
3245
3246         Turning on incremental mode, the stochastic scheduler, and passive draining in combination with
3247         each other is a huge splay-latency speed-up on my iPad. It's also a CDjs progression. It does
3248         regress splay-throughput, but I think that's fine (the regression is 11%, the progression is
3249         3x).
3250
3251         * heap/Heap.cpp:
3252         (JSC::Heap::Heap):
3253         (JSC::Heap::~Heap):
3254         (JSC::Heap::markToFixpoint):
3255         (JSC::Heap::updateObjectCounts):
3256         (JSC::Heap::endMarking):
3257         (JSC::Heap::finalize):
3258         (JSC::Heap::didAllocate):
3259         (JSC::Heap::visitCount):
3260         (JSC::Heap::bytesVisited):
3261         (JSC::Heap::forEachSlotVisitor):
3262         (JSC::Heap::performIncrement):
3263         (JSC::Heap::threadVisitCount): Deleted.
3264         (JSC::Heap::threadBytesVisited): Deleted.
3265         * heap/Heap.h:
3266         * heap/MarkStack.cpp:
3267         (JSC::MarkStackArray::transferTo):
3268         * heap/MarkStack.h:
3269         * heap/SlotVisitor.cpp:
3270         (JSC::SlotVisitor::didStartMarking):
3271         (JSC::SlotVisitor::clearMarkStacks):
3272         (JSC::SlotVisitor::appendToMarkStack):
3273         (JSC::SlotVisitor::noteLiveAuxiliaryCell):
3274         (JSC::SlotVisitor::donateKnownParallel):
3275         (JSC::SlotVisitor::drain):
3276         (JSC::SlotVisitor::performIncrementOfDraining):
3277         (JSC::SlotVisitor::didReachTermination):
3278         (JSC::SlotVisitor::hasWork):
3279         (JSC::SlotVisitor::drainFromShared):
3280         (JSC::SlotVisitor::drainInParallelPassively):
3281         (JSC::SlotVisitor::donateAll):
3282         (JSC::SlotVisitor::correspondingGlobalStack):
3283         * heap/SlotVisitor.h:
3284         * heap/SlotVisitorInlines.h:
3285         (JSC::SlotVisitor::reportExtraMemoryVisited):
3286         (JSC::SlotVisitor::forEachMarkStack):
3287         * heap/SpaceTimeMutatorScheduler.cpp:
3288         (JSC::SpaceTimeMutatorScheduler::log):
3289         * heap/StochasticSpaceTimeMutatorScheduler.cpp:
3290         (JSC::StochasticSpaceTimeMutatorScheduler::log):
3291         * jsc.cpp:
3292         (GlobalObject::finishCreation):
3293         (functionHeapCapacity):
3294         * runtime/Options.cpp:
3295         (JSC::overrideDefaults):
3296         * runtime/Options.h:
3297
3298 2017-01-31  Tomas Popela  <tpopela@redhat.com>
3299
3300         Compilation error in JSArrayBufferView.h
3301         https://bugs.webkit.org/show_bug.cgi?id=167642
3302
3303         Reviewed by Alex Christensen.
3304
3305         * runtime/JSArrayBufferView.h:
3306         (JSC::JSArrayBufferView::vector):
3307
3308 2017-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3309
3310         [JSC] Do not reject WebAssembly.compile() with E