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