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