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