1 2017-02-19 Mark Lam <mark.lam@apple.com>
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>
7 Reviewed by Saam Barati.
9 We fix this by having CachedCall use a MarkedArgumentBuffer to store its
10 arguments instead of a Vector.
12 Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
13 WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
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):
31 (JSC::MarkedArgumentBuffer::ensureCapacity):
32 * runtime/StringPrototype.cpp:
33 (JSC::replaceUsingRegExpSearch):
38 2017-02-19 Commit Queue <commit-queue@webkit.org>
40 Unreviewed, rolling out r212466.
41 https://bugs.webkit.org/show_bug.cgi?id=168577
43 causes crashes on AArch64 on linux, maybe it's causing crashes
44 on iOS too (Requested by pizlo on #webkit).
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
53 2017-02-17 Michael Saboff <msaboff@apple.com>
55 Improve ARM64 disassembler handling of pseudo ops, unsupported opcodes and zero reg
56 https://bugs.webkit.org/show_bug.cgi?id=168527
58 Reviewed by Filip Pizlo.
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]
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.
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
81 Verified that all instructions currently generated by the JSC stress tests are
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.
118 2017-02-17 Zan Dobersek <zdobersek@igalia.com>
120 [GLib] GCActivityCallback::scheduleTimer() keeps pushing dispatch into the future
121 https://bugs.webkit.org/show_bug.cgi?id=168363
123 Reviewed by Carlos Garcia Campos.
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
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.
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.
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):
160 2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
162 [JSC] Drop PassRefPtr from ArrayBuffer
163 https://bugs.webkit.org/show_bug.cgi?id=168455
165 Reviewed by Geoffrey Garen.
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<>.
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).
175 * inspector/JavaScriptCallFrame.h:
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):
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.
232 2017-02-16 Keith Miller <keith_miller@apple.com>
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
237 Reviewed by Geoffrey Garen.
239 Instead of adding a custom vmEntryGlobalObject for the debugger
240 we can just have it use vmEntryScope instead.
242 * debugger/Debugger.cpp:
243 (JSC::Debugger::detach):
244 * interpreter/CallFrame.cpp:
245 (JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach): Deleted.
246 * interpreter/CallFrame.h:
248 2017-02-16 Filip Pizlo <fpizlo@apple.com>
250 Unreviewed, fix cloop build.
253 (JSC::Heap::stopThePeriphery):
254 * runtime/JSLock.cpp:
256 2017-02-10 Filip Pizlo <fpizlo@apple.com>
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
261 Reviewed by Keith Miller.
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.
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
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.
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.
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
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):
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.
324 (JSC::Heap::Thread::Thread):
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.
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):
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):
411 * runtime/TestRunnerUtils.cpp:
412 (JSC::finalizeStatsAtEndOfTesting):
414 2017-02-16 Anders Carlsson <andersca@apple.com>
416 Remove EFL from JavaScriptCore
417 https://bugs.webkit.org/show_bug.cgi?id=168459
419 Reviewed by Geoffrey Garen.
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.
431 * inspector/EventLoop.cpp:
432 (Inspector::EventLoop::cycle):
435 * tools/CodeProfiling.cpp:
436 (JSC::CodeProfiling::begin):
437 (JSC::CodeProfiling::end):
439 2017-02-15 Brian Burg <bburg@apple.com>
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>
445 Reviewed by Joseph Pecoraro.
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.
450 Update various pieces of generated code to handle the error case gracefully.
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.
459 The optional enum parameter case is not handled correctly, but no existing code requires it.
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.
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.
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.
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.
483 * inspector/scripts/codegen/objc_generator_templates.py:
484 Update type template for fromProtocolString<T>().
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:
507 2017-02-16 Keith Miller <keith_miller@apple.com>
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
512 Reviewed by Filip Pizlo.
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.
518 * debugger/Debugger.cpp:
519 (JSC::Debugger::detach):
520 * interpreter/CallFrame.cpp:
521 (JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach):
522 * interpreter/CallFrame.h:
524 2017-02-16 Keith Miller <keith_miller@apple.com>
526 Refactor AccessCase to be more like B3Value
527 https://bugs.webkit.org/show_bug.cgi?id=168408
529 Reviewed by Filip Pizlo.
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:
536 GetterSetterAccessCase:
547 IntrinsicGetterAccessCase:
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.
556 This patch also removes megamorphic loads and renames some TryGetById related enum values from Pure to Try.
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):
691 (JSC::tryCacheGetByID):
692 (JSC::tryCachePutByID):
697 2017-02-16 Filip Pizlo <fpizlo@apple.com>
699 JSONParseTest needs to hold the lock when the VM is destroyed
700 https://bugs.webkit.org/show_bug.cgi?id=168450
702 Rubber stamped by Alex Christensen.
704 * API/tests/JSONParseTest.cpp:
707 2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
709 [JSC] Drop PassRefPtr in inspector/
710 https://bugs.webkit.org/show_bug.cgi?id=168420
712 Reviewed by Alex Christensen.
714 Drop PassRefPtr uses.
715 And use Ref<Inspector::ScriptArguments> and Ref<ScriptCallStack> as much as possible.
716 It drops some unnecessary null checks.
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>&&.
744 * inspector/JSGlobalObjectInspectorController.cpp:
745 (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
746 (Inspector::JSGlobalObjectInspectorController::reportAPIException):
747 * inspector/JSGlobalObjectInspectorController.h:
748 * inspector/JSJavaScriptCallFrame.cpp:
749 (Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame):
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):
794 2017-02-15 Keith Miller <keith_miller@apple.com>
796 Weak should not use jsCast in its accessors
797 https://bugs.webkit.org/show_bug.cgi?id=168406
799 Reviewed by Filip Pizlo.
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.
804 * heap/WeakInlines.h:
806 (JSC::Weak<T>::operator):
809 2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
811 Web Inspector: allow import() inside the inspector
812 https://bugs.webkit.org/show_bug.cgi?id=167457
814 Reviewed by Ryosuke Niwa.
816 We relax import module hook to accept null SourceOrigin.
817 Such a script can be evaluated from the inspector console.
820 (GlobalObject::moduleLoaderImportModule):
821 * runtime/JSGlobalObjectFunctions.cpp:
822 (JSC::globalFuncImportModule):
824 2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
826 [JSC] Update module namespace object according to the latest ECMA262
827 https://bugs.webkit.org/show_bug.cgi?id=168280
829 Reviewed by Saam Barati.
831 Reflect updates to the module namespace object.
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].
837 [1]: https://tc39.github.io/ecma262/#sec-module-namespace-objects
838 [2]: https://github.com/tc39/ecma262/pull/767
840 * runtime/JSModuleNamespaceObject.cpp:
841 (JSC::JSModuleNamespaceObject::finishCreation):
842 (JSC::JSModuleNamespaceObject::deleteProperty):
843 (JSC::moduleNamespaceObjectSymbolIterator): Deleted.
845 2017-02-16 Carlos Garcia Campos <cgarcia@igalia.com>
847 Unreviewed. Fix the build after r212424.
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):
867 2017-02-15 Yusuke Suzuki <utatane.tea@gmail.com>
869 [JSC] Drop PassRefPtr in bytecompiler/
870 https://bugs.webkit.org/show_bug.cgi?id=168374
872 Reviewed by Sam Weinig.
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.
879 Currently we do not apply this change for RefPtr<RegisterID>,
880 to reduce the size of this patch.
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.
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.
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.
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.
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*.
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&.
973 2017-02-15 Alex Christensen <achristensen@webkit.org>
975 Unreviewed, rolling out r212394.
977 Fixed iOS WebInspector
981 "Unreviewed, rolling out r212169."
982 https://bugs.webkit.org/show_bug.cgi?id=166681
983 http://trac.webkit.org/changeset/212394
985 2017-02-15 Guillaume Emont <guijemont@igalia.com>
987 MIPS: add missing implementations of load8SignedExtendTo32()
989 JSC: missing implementations of MacroAssemblerMIPS::load8SignedExtendTo32()
990 https://bugs.webkit.org/show_bug.cgi?id=168350
992 Reviewed by Yusuke Suzuki.
994 * assembler/MacroAssemblerMIPS.h:
995 (JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
996 Add missing implementations
998 2017-02-15 Alex Christensen <achristensen@webkit.org>
1000 Unreviewed, rolling out r212169.
1002 Broke iOS WebInspector
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
1011 2017-02-15 Chris Dumez <cdumez@apple.com>
1013 Expose Symbol.toPrimitive / valueOf on Location instances
1014 https://bugs.webkit.org/show_bug.cgi?id=168295
1016 Reviewed by Geoffrey Garen, Keith Miller and Mark Lam.
1018 Cache origin objectProtoValueOf function on JSGlobalObject.
1020 * runtime/JSGlobalObject.cpp:
1021 (JSC::JSGlobalObject::init):
1022 * runtime/JSGlobalObject.h:
1023 (JSC::JSGlobalObject::objectProtoValueOfFunction):
1025 2017-02-15 Yusuke Suzuki <utatane.tea@gmail.com>
1027 [JSC] Drop PassRefPtr
1028 https://bugs.webkit.org/show_bug.cgi?id=168320
1030 Reviewed by Saam Barati.
1032 * API/JSContextRef.cpp:
1033 (JSGlobalContextCreateInGroup):
1034 Use Ref<VM> from the factory function.
1036 * API/JSScriptRef.cpp:
1037 (OpaqueJSScript::create):
1038 Return Ref<> instead.
1040 * API/tests/JSONParseTest.cpp:
1044 * assembler/LinkBuffer.cpp:
1045 (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
1046 Use reference since we already perform null check.
1048 * assembler/MacroAssemblerCodeRef.h:
1049 (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
1050 Take Ref<>&& instead of PassRefPtr<>.
1052 * bytecode/CallLinkInfo.h:
1053 (JSC::CallLinkInfo::setStub):
1054 (JSC::CallLinkInfo::setSlowStub):
1055 Take Ref<>&& instead of PassRefPtr<>.
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.
1062 (JSC::CodeBlock::finishCreation):
1063 Take Ref<TypeSet>&&.
1065 * bytecode/CodeBlock.h:
1066 (JSC::CodeBlock::setJITCode):
1067 Take Ref<>&& instead.
1069 (JSC::CodeBlock::jitCode):
1070 Return RefPtr<> instead.
1072 * bytecode/EvalCodeBlock.h:
1073 (JSC::EvalCodeBlock::create):
1074 Take RefPtr<>&& instead since SourceProvider woule be nullptr.
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.
1082 * bytecode/GlobalCodeBlock.h:
1083 (JSC::GlobalCodeBlock::GlobalCodeBlock):
1084 Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1086 * bytecode/ModuleProgramCodeBlock.h:
1087 (JSC::ModuleProgramCodeBlock::create):
1088 (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
1089 Take RefPtr<>&& instead since SourceProvider woule be nullptr.
1091 * bytecode/ProgramCodeBlock.h:
1092 (JSC::ProgramCodeBlock::create):
1093 (JSC::ProgramCodeBlock::ProgramCodeBlock):
1094 Take RefPtr<>&& instead since SourceProvider woule be nullptr.
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.
1101 * dfg/DFGBlockInsertionSet.cpp:
1102 (JSC::DFG::BlockInsertionSet::insert):
1103 Take Ref<>&& instead.
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.
1112 * dfg/DFGDriver.cpp:
1113 (JSC::DFG::compileImpl):
1114 (JSC::DFG::compile):
1115 Pass Ref<Plan>&&. And take Ref<>&& callback.
1119 appendBlock takes Ref<>&&.
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>&&.
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.
1136 * dfg/DFGJITFinalizer.h:
1137 * dfg/DFGWorklist.cpp:
1138 (JSC::DFG::Worklist::enqueue):
1141 * dfg/DFGWorklist.h:
1142 * ftl/FTLJITFinalizer.cpp:
1143 (JSC::FTL::JITFinalizer::finalizeFunction):
1144 Dereference and pass jitCode & compilation references.
1146 * jit/GCAwareJITStubRoutine.cpp:
1147 (JSC::createJITStubRoutine):
1148 Return Ref<> instead.
1150 * jit/GCAwareJITStubRoutine.h:
1151 (JSC::createJITStubRoutine):
1154 Pass compilation reference since we already perform null check.
1156 * jit/JITStubRoutine.h:
1157 (JSC::JITStubRoutine::asCodePtr):
1158 Take Ref<>&& instead. And this drops unnecessary null check.
1160 * jit/JITThunks.cpp:
1161 (JSC::JITThunks::hostFunctionStub):
1162 Pass Ref<> to NativeExecutable::create.
1164 * llint/LLIntEntrypoint.cpp:
1165 (JSC::LLInt::setFunctionEntrypoint):
1166 (JSC::LLInt::setEvalEntrypoint):
1167 (JSC::LLInt::setProgramEntrypoint):
1168 (JSC::LLInt::setModuleProgramEntrypoint):
1169 Use Ref<>&& instead.
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.
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.
1184 * profiler/ProfilerDatabase.cpp:
1185 (JSC::Profiler::Database::addCompilation):
1186 Take Ref<Compilation>&&.
1188 * profiler/ProfilerDatabase.h:
1189 Change data structures to hold Ref<> instead of RefPtr<>.
1191 * runtime/EvalExecutable.h:
1192 (JSC::EvalExecutable::generatedJITCode):
1193 Return Ref<> instead.
1195 * runtime/ExecutableBase.h:
1196 (JSC::ExecutableBase::generatedJITCodeForCall):
1197 (JSC::ExecutableBase::generatedJITCodeForConstruct):
1198 (JSC::ExecutableBase::generatedJITCodeFor):
1199 Return Ref<> instead.
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.
1210 * runtime/JSGlobalObject.h:
1211 (JSC::JSGlobalObject::inputCursor):
1212 Change m_inputCursor from RefPtr<> to Ref<>.
1214 * runtime/JSPropertyNameEnumerator.cpp:
1215 (JSC::JSPropertyNameEnumerator::create):
1216 (JSC::JSPropertyNameEnumerator::finishCreation):
1217 Take Ref<PropertyNameArray>&&.
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.
1225 (JSC::JSString::create):
1226 (JSC::JSString::createHasOtherOwner):
1227 Take Ref<StringImpl>&& in these factory functions. And drop unnecessary assertions.
1229 (JSC::jsSingleCharacterString):
1230 Use StringImpl::create() which returns Ref<>.
1232 (JSC::jsNontrivialString):
1233 Dereference impl() since we ensure that `s.length() > 1`.
1236 Use releaseNonNull() since we ensure that `s.length() > 1`.
1238 (JSC::jsOwnedString):
1239 Use releaseNonNull() since we ensure that `s.length() > 1`.
1241 * runtime/ModuleProgramExecutable.h:
1242 * runtime/NativeExecutable.cpp:
1243 (JSC::NativeExecutable::create):
1244 (JSC::NativeExecutable::finishCreation):
1245 Take Ref<JITCode>&&.
1247 * runtime/NativeExecutable.h:
1248 * runtime/ProgramExecutable.h:
1249 Return Ref<JITCode>.
1251 * runtime/PropertyNameArray.h:
1252 (JSC::PropertyNameArray::releaseData):
1253 (JSC::PropertyNameArray::setData): Deleted.
1256 * runtime/RegExpKey.h:
1257 (JSC::RegExpKey::RegExpKey):
1260 * runtime/SmallStrings.cpp:
1261 (JSC::SmallStringsStorage::rep):
1262 Return StringImpl& since m_reps is already initialized in the constructor.
1264 (JSC::SmallStrings::createEmptyString):
1265 Dereference StringImpl::empty().
1267 (JSC::SmallStrings::createSingleCharacterString):
1270 (JSC::SmallStrings::singleCharacterStringRep):
1273 (JSC::SmallStrings::initialize):
1274 Use AtomicStringImpl::add instead.
1276 * runtime/SmallStrings.h:
1277 * runtime/Structure.cpp:
1278 (JSC::Structure::toStructureShape):
1281 * runtime/Structure.h:
1282 * runtime/TypeLocationCache.cpp:
1283 (JSC::TypeLocationCache::getTypeLocation):
1284 Take RefPtr<TypeSet>&&.
1286 * runtime/TypeLocationCache.h:
1287 * runtime/TypeProfilerLog.cpp:
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.
1296 (JSC::TypeSet::allStructureRepresentations):
1297 Use range based iteration.
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<>.
1303 (JSC::StructureShape::hasSamePrototypeChain):
1304 Take const reference instead. And use raw pointers internally.
1306 (JSC::StructureShape::merge):
1309 * runtime/TypeSet.h:
1310 (JSC::StructureShape::setProto):
1314 (JSC::VM::getHostFunction):
1317 (JSC::VM::queueMicrotask):
1318 Take and pass Ref<>&&.
1321 (JSC::QueuedTask::QueuedTask):
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.
1329 2017-02-15 Csaba Osztrogonác <ossy@webkit.org>
1331 [Mac][cmake] Unreviewed trivial buildfix after r212169.
1332 https://bugs.webkit.org/show_bug.cgi?id=166681
1334 * PlatformMac.cmake: Removed inspector/remote/RemoteInspectorXPCConnection.mm.
1336 2017-02-14 Mark Lam <mark.lam@apple.com>
1338 Add JSC_sweepSynchronously and fix JSC_useZombieMode options.
1339 https://bugs.webkit.org/show_bug.cgi?id=168257
1340 <rdar://problem/30451496>
1342 Reviewed by Filip Pizlo.
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.
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.
1357 (JSC::Heap::isZombified): Deleted.
1358 * runtime/Options.cpp:
1359 (JSC::recomputeDependentOptions):
1360 * runtime/Options.h:
1362 2017-02-13 Michael Saboff <msaboff@apple.com>
1364 asyncDisassembly crashes on iOS
1365 https://bugs.webkit.org/show_bug.cgi?id=168259
1367 Reviewed by Filip Pizlo.
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.
1373 * jit/ExecutableAllocatorFixedVMPool.cpp:
1374 (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
1376 2017-02-12 Ryosuke Niwa <rniwa@webkit.org>
1378 C loop build fix attempt after r212207.
1382 2017-02-11 Sam Weinig <sam@webkit.org>
1384 Remove the remaining functions out of JSDOMBinding
1385 https://bugs.webkit.org/show_bug.cgi?id=168179
1387 Reviewed by Darin Adler.
1389 Move utility functions into more appropriate locations.
1390 - Move hasIteratorMethod to IteratorOperations.
1391 - Move nonCachingStaticFunctionGetter to Lookup
1393 * runtime/IteratorOperations.cpp:
1394 (JSC::hasIteratorMethod):
1395 * runtime/IteratorOperations.h:
1397 (JSC::nonCachingStaticFunctionGetter):
1399 2017-02-11 Yusuke Suzuki <utatane.tea@gmail.com>
1401 [JSC] Implement (Shared)ArrayBuffer.prototype.byteLength
1402 https://bugs.webkit.org/show_bug.cgi?id=166476
1404 Reviewed by Saam Barati.
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.
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):
1427 2017-02-10 Saam Barati <sbarati@apple.com>
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>
1433 Reviewed by Filip Pizlo.
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:
1446 b: PhantomActivation()
1447 a: PhantomNewFunction()
1448 c: PutHint(@a, @b, ActivationLoc)
1452 d: MaterializeActivation()
1453 e: PutHint(@a, @d, ActivationLoc)
1458 g: MaterializeActivation()
1459 h: PutHint(@a, @g, ActivationLoc)
1465 // What is PromotedHeapLocation(@a, ActivationLoc) here?
1466 // What would we do if we exited?
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)
1472 The program we need then, for correctness, is this:
1475 b: PhantomActivation()
1476 a: PhantomNewFunction()
1477 c: PutHint(@a, @b, ActivationLoc)
1481 d: MaterializeActivation()
1482 e: PutHint(@a, @d, ActivationLoc)
1487 g: MaterializeActivation()
1488 h: PutHint(@a, @g, ActivationLoc)
1494 j: PutHint(@a, @p, ActivationLoc)
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.
1501 * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1502 (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1503 * dfg/DFGObjectAllocationSinkingPhase.cpp:
1504 * ftl/FTLOperations.cpp:
1505 (JSC::FTL::operationMaterializeObjectInOSR):
1507 2017-02-10 Carlos Garcia Campos <cgarcia@igalia.com>
1509 WebInspector: refactor RemoteInspector to move cocoa specific code to their own files
1510 https://bugs.webkit.org/show_bug.cgi?id=166681
1512 Reviewed by Michael Catanzaro.
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
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):
1565 2017-02-10 Brian Burg <bburg@apple.com>
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
1570 Reviewed by Joseph Pecoraro.
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'.
1575 * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
1576 (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
1578 * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1579 Rebaseline an affected test.
1581 2017-02-10 Mark Lam <mark.lam@apple.com>
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>
1587 Reviewed by Filip Pizlo.
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
1596 * bytecode/StructureStubInfo.h:
1597 (JSC::StructureStubInfo::considerCaching):
1598 * jit/JITOperations.cpp:
1600 2017-02-10 Brian Burg <bburg@apple.com>
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>
1606 Reviewed by Joseph Pecoraro.
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.
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.
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.
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'.
1626 * inspector/scripts/codegen/models.py:
1628 Use lower-case string values for platform names, to avoid guesswork.
1630 (Platforms.__metaclass__):
1631 (Platforms.__metaclass__.__iter__):
1632 Make it possible to iterate over Platform instances of Platforms.
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:
1655 2017-02-09 Filip Pizlo <fpizlo@apple.com>
1657 SharedArrayBuffer does not need to be in the transfer list
1658 https://bugs.webkit.org/show_bug.cgi?id=168079
1660 Reviewed by Geoffrey Garen and Keith Miller.
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.
1665 * runtime/ArrayBuffer.cpp:
1666 (JSC::ArrayBuffer::shareWith):
1667 * runtime/ArrayBuffer.h:
1668 (JSC::ArrayBufferContents::operator bool):
1670 2017-02-09 Mark Lam <mark.lam@apple.com>
1672 B3::Procedure::deleteOrphans() should neutralize upsilons with dead phis.
1673 https://bugs.webkit.org/show_bug.cgi?id=167437
1674 <rdar://problem/30198083>
1676 Reviewed by Filip Pizlo.
1678 * b3/B3Procedure.cpp:
1679 (JSC::B3::Procedure::deleteOrphans):
1681 2017-02-09 Saam Barati <sbarati@apple.com>
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>
1687 Reviewed by Mark Lam.
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
1698 * bytecompiler/BytecodeGenerator.cpp:
1699 (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1701 2017-02-09 Mark Lam <mark.lam@apple.com>
1703 Fix max length check in ArrayPrototype.js' concatSlowPath().
1704 https://bugs.webkit.org/show_bug.cgi?id=167270
1705 <rdar://problem/30128133>
1707 Reviewed by Filip Pizlo.
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.
1713 2. Changed concatSlowPath() to throw a RangeError instead of a TypeError to be
1714 consistent with the C++ runtime functions in JSArray.cpp.
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.
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.
1730 4. Fixed JSArray::appendMemcpy() to handle overflows when computing the result
1733 * builtins/ArrayPrototype.js:
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):
1745 2017-02-09 Mark Lam <mark.lam@apple.com>
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>
1751 Reviewed by Filip Pizlo and Geoffrey Garen.
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.
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:
1790 2017-02-09 Keith Miller <keith_miller@apple.com>
1792 We should not allow Function.caller to be used on native functions
1793 https://bugs.webkit.org/show_bug.cgi?id=165628
1795 Reviewed by Mark Lam.
1797 Also remove unneeded dynamic cast.
1799 * runtime/JSFunction.cpp:
1800 (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
1801 (JSC::JSFunction::callerGetter):
1803 2017-02-08 Keith Miller <keith_miller@apple.com>
1805 [JSC] op_in should have ArrayProfile
1806 https://bugs.webkit.org/show_bug.cgi?id=164581
1808 Reviewed by Filip Pizlo.
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.
1814 This patch also flips the two arguments of op_in and the In node
1815 to reflect the other property lookup bytecodes.
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):
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:
1852 * runtime/CommonSlowPaths.cpp:
1853 (JSC::SLOW_PATH_DECL):
1854 * runtime/CommonSlowPaths.h:
1855 (JSC::CommonSlowPaths::opIn):
1857 2017-02-08 Saam Barati <sbarati@apple.com>
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>
1863 Reviewed by Filip Pizlo.
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.
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.
1878 * b3/air/AirInsertionSet.cpp:
1879 * b3/air/AirInsertionSet.h:
1880 (JSC::B3::Air::InsertionSet::insertInsts):
1881 * b3/air/AirIteratedRegisterCoalescing.cpp:
1883 (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
1884 (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
1887 2017-02-07 Mark Lam <mark.lam@apple.com>
1889 SigillCrashAnalyzer::analyze() should use a do-while loop instead of a lambda.
1890 https://bugs.webkit.org/show_bug.cgi?id=167950
1892 Reviewed by Michael Saboff.
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.
1898 * tools/SigillCrashAnalyzer.cpp:
1900 2017-02-05 Mark Lam <mark.lam@apple.com>
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
1905 Reviewed by Michael Saboff.
1907 Here are the scenarios that may come up:
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
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
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
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.
1948 * tools/SigillCrashAnalyzer.cpp:
1950 (JSC::installCrashHandler):
1951 (JSC::SigillCrashAnalyzer::analyze): Deleted.
1953 2017-02-07 Yusuke Suzuki <utatane.tea@gmail.com>
1955 Unreviewed, manual roll out of r211777
1956 https://bugs.webkit.org/show_bug.cgi?id=167457
1959 (GlobalObject::moduleLoaderImportModule):
1960 * runtime/JSGlobalObjectFunctions.cpp:
1961 (JSC::globalFuncImportModule):
1963 2017-02-07 Yusuke Suzuki <utatane.tea@gmail.com>
1965 Web Inspector: allow import() inside the inspector
1966 https://bugs.webkit.org/show_bug.cgi?id=167457
1968 Reviewed by Ryosuke Niwa.
1970 We relax import module hook to accept null SourceOrigin.
1971 Such a script can be evaluated from the inspector console.
1974 (GlobalObject::moduleLoaderImportModule):
1975 * runtime/JSGlobalObjectFunctions.cpp:
1976 (JSC::globalFuncImportModule):
1978 2017-02-06 Joseph Pecoraro <pecoraro@apple.com>
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>
1984 Reviewed by Brian Burg.
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.
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.
2001 (Inspector::InspectorHeapAgent::dispatchGarbageCollectedEvent):
2002 Make a virtual method so that WebCore implementations of this agent can choose
2003 to dispatch this event asynchronously.
2005 * inspector/agents/InspectorScriptProfilerAgent.cpp:
2006 Remove unnecessary RunLoop include.
2008 2017-02-06 Joseph Pecoraro <pecoraro@apple.com>
2010 Static Analyzer: JSContext.mm: Incorrect decrement of the reference count of an object
2011 https://bugs.webkit.org/show_bug.cgi?id=167848
2013 Reviewed by Saam Barati.
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.
2021 (-[JSContext dealloc]):
2022 Use the ivar in dealloc instead of going through the getter.
2024 2017-02-05 Mark Lam <mark.lam@apple.com>
2026 The VMInspector should use an RAII Locker.
2027 https://bugs.webkit.org/show_bug.cgi?id=167854
2029 Reviewed by Saam Barati.
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.
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.
2041 * tools/SigillCrashAnalyzer.cpp:
2042 (JSC::SigillCrashAnalyzer::analyze):
2043 * tools/VMInspector.cpp:
2044 * tools/VMInspector.h:
2046 2017-02-04 Joseph Pecoraro <pecoraro@apple.com>
2048 Static Analyzer: Value stored to 'recordedMachineThreads' during its initialization is never read
2049 https://bugs.webkit.org/show_bug.cgi?id=167845
2051 Reviewed by Saam Barati.
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 ^~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
2057 * heap/MachineStackMarker.cpp:
2058 (JSC::ActiveMachineThreadsManager::remove):
2060 2017-02-04 Joseph Pecoraro <pecoraro@apple.com>
2062 Static Analyzer: Value stored to 'prev' is never read
2063 https://bugs.webkit.org/show_bug.cgi?id=167844
2065 Reviewed by Saam Barati.
2067 Source/JavaScriptCore/runtime/JSMapIterator.h:60:13: warning: Value stored to 'prev' is never read
2070 Source/JavaScriptCore/runtime/JSSetIterator.h:60:13: warning: Value stored to 'prev' is never read
2074 * runtime/JSMapIterator.h:
2075 (JSC::JSMapIterator::advanceIter):
2076 * runtime/JSSetIterator.h:
2077 (JSC::JSSetIterator::advanceIter):
2079 2017-02-04 Yusuke Suzuki <utatane.tea@gmail.com>
2081 [JSC] Add operationToInt32SensibleSlow to optimize kraken pbkdf2 and sha256
2082 https://bugs.webkit.org/show_bug.cgi?id=167736
2084 Reviewed by Saam Barati.
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.
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
2095 The original operationToInt32 code.
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
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>
2132 The operationToInt32SensibleSlow code.
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
2146 211: 48 85 d2 test %rdx,%rdx
2147 214: 0f 48 c1 cmovs %ecx,%eax
2149 218: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
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
2161 241: 48 85 d2 test %rdx,%rdx
2162 244: 0f 48 c1 cmovs %ecx,%eax
2164 248: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
2167 This improves kraken pbkdf2 by 10.8% and sha256 by 7.5%.
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
2174 <arithmetic> 101.121+-1.379 ^ 91.907+-1.500 ^ definitely 1.1003x faster
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.
2186 * runtime/MathCommon.cpp:
2187 (JSC::operationToInt32SensibleSlow):
2188 * runtime/MathCommon.h:
2190 2017-02-03 Joseph Pecoraro <pecoraro@apple.com>
2192 Unreviewed rollout of r211486, r211629.
2194 Original change is not ideal and is causing issues.
2196 * inspector/agents/InspectorHeapAgent.cpp:
2197 (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
2198 * runtime/InitializeThreading.cpp:
2199 (JSC::initializeThreading):
2201 2017-02-03 JF Bastien <jfbastien@apple.com>
2203 OSR entry: delay outer-loop compilation when at inner-loop
2204 https://bugs.webkit.org/show_bug.cgi?id=167149
2206 Reviewed by Filip Pizlo.
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").
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).
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.
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.
2250 DFG tier-up was added here:
2251 https://bugs.webkit.org/show_bug.cgi?id=112838
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:
2266 2017-02-03 Saam Barati <sbarati@apple.com>
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>
2272 Reviewed by Michael Saboff.
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.
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.
2289 * interpreter/Interpreter.cpp:
2290 (JSC::Interpreter::executeProgram):
2291 * interpreter/Interpreter.h:
2294 (JSC::JIT::privateCompileMainPass):
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:
2309 2017-02-03 Csaba Osztrogonác <ossy@webkit.org>
2311 Unreviewed typo fix after r211630.
2315 2017-02-03 Carlos Garcia Campos <cgarcia@igalia.com>
2317 [GTK] Add initial implementation of resource usage overlay
2318 https://bugs.webkit.org/show_bug.cgi?id=167731
2320 Reviewed by Michael Catanzaro.
2322 Also expose nextFireTime() for GTK+ port.
2324 * heap/GCActivityCallback.cpp:
2325 (JSC::GCActivityCallback::scheduleTimer):
2326 (JSC::GCActivityCallback::cancelTimer):
2327 * heap/GCActivityCallback.h:
2329 2017-02-03 Csaba Osztrogonác <ossy@webkit.org>
2331 [cmake] Unreviewed AArch64 buildfix after r211603.
2332 https://bugs.webkit.org/show_bug.cgi?id=167714
2336 2017-02-02 Andreas Kling <akling@apple.com>
2338 [Mac] In-process memory pressure monitor for WebContent processes AKA websam
2339 <https://webkit.org/b/167491>
2340 <rdar://problem/30116072>
2342 Reviewed by Antti Koivisto.
2344 Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
2345 WebCore-side memory footprint monitor.
2348 (JSC::Heap::updateAllocationLimits):
2349 (JSC::Heap::didExceedMaxLiveSize): Deleted.
2351 (JSC::Heap::setMaxLiveSize): Deleted.
2353 2017-02-02 Mark Lam <mark.lam@apple.com>
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>
2361 Build fix for CLOOP build.
2363 * tools/VMInspector.cpp:
2365 2017-02-02 Mark Lam <mark.lam@apple.com>
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>
2371 Reviewed by Filip Pizlo.
2373 The current implementation is only for X86_64 and ARM64 on OS(DARWIN). The
2374 analyzer is not enabled for all other ports.
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):
2388 (JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
2390 * heap/HeapInlines.h:
2391 (JSC::Heap::forEachCodeBlockIgnoringJITPlans):
2392 * runtime/Options.cpp:
2393 (JSC::Options::isAvailable):
2394 (JSC::recomputeDependentOptions):
2395 * runtime/Options.h:
2400 * tools/SigillCrashAnalyzer.cpp: Added.
2401 (JSC::SignalContext::SignalContext):
2402 (JSC::SignalContext::dump):
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):
2417 2017-02-02 Chris Dumez <cdumez@apple.com>
2419 {}.toString.call(crossOriginWindow) should return "[object Object]"
2420 https://bugs.webkit.org/show_bug.cgi?id=167701
2421 <rdar://problem/30330797>
2423 Reviewed by Keith Miller.
2425 Have JSProxy forward toStringName calls to its target so Window
2428 * runtime/JSProxy.cpp:
2429 (JSC::JSProxy::toStringName):
2430 * runtime/JSProxy.h:
2432 2017-02-02 Commit Queue <commit-queue@webkit.org>
2434 Unreviewed, rolling out r211571 and r211582.
2435 https://bugs.webkit.org/show_bug.cgi?id=167751
2437 This change caused API test WebKit1.MemoryPressureHandler to
2438 fail with an assertion. (Requested by ryanhaddad on #webkit).
2440 Reverted changesets:
2442 "[Mac] In-process memory pressure monitor for WebContent
2444 https://bugs.webkit.org/show_bug.cgi?id=167491
2445 http://trac.webkit.org/changeset/211571
2447 "Unreviewed attempt to fix the Windows build after r211571."
2448 http://trac.webkit.org/changeset/211582
2450 2017-02-02 Andreas Kling <akling@apple.com>
2452 [Mac] In-process memory pressure monitor for WebContent processes.
2453 <https://webkit.org/b/167491>
2454 <rdar://problem/30116072>
2456 Reviewed by Antti Koivisto.
2458 Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
2459 WebCore-side memory footprint monitor.
2462 (JSC::Heap::updateAllocationLimits):
2463 (JSC::Heap::didExceedMaxLiveSize): Deleted.
2465 (JSC::Heap::setMaxLiveSize): Deleted.
2467 2017-02-02 Joseph Pecoraro <pecoraro@apple.com>
2469 Removed unused m_errorHandlingModeReentry from Interpreter
2470 https://bugs.webkit.org/show_bug.cgi?id=167726
2472 Reviewed by Yusuke Suzuki.
2474 * interpreter/Interpreter.cpp:
2475 (JSC::Interpreter::Interpreter):
2476 * interpreter/Interpreter.h:
2478 2017-02-01 Commit Queue <commit-queue@webkit.org>
2480 Unreviewed, rolling out r211461.
2481 https://bugs.webkit.org/show_bug.cgi?id=167721
2483 Big regression on kraken (Requested by jfbastien on #webkit).
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
2491 2017-02-01 Keith Miller <keith_miller@apple.com>
2493 Unreviewed, fix unintended change.
2495 * runtime/SamplingProfiler.cpp:
2496 (JSC::SamplingProfiler::StackFrame::displayName):
2498 2017-02-01 Keith Miller <keith_miller@apple.com>
2500 The sampling profile should have an option to sample from C frames.
2501 https://bugs.webkit.org/show_bug.cgi?id=167614
2503 Reviewed by Saam Barati.
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
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):
2526 2017-02-01 Joseph Pecoraro <pecoraro@apple.com>
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>
2532 Reviewed by Timothy Hatcher.
2534 * inspector/agents/InspectorHeapAgent.cpp:
2535 (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
2536 Use RunLoop::main instead of RunLoop::current which may go away.
2538 * runtime/InitializeThreading.cpp:
2539 (JSC::initializeThreading):
2540 Ensure RunLoop::main is initialized when using JSC APIs.
2542 2017-02-01 Yusuke Suzuki <utatane.tea@gmail.com>
2544 ArityFixup should adjust SP first
2545 https://bugs.webkit.org/show_bug.cgi?id=167239
2547 Reviewed by Michael Saboff.
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.
2558 * jit/ThunkGenerators.cpp:
2559 (JSC::arityFixupGenerator):
2560 * llint/LowLevelInterpreter32_64.asm:
2561 * llint/LowLevelInterpreter64.asm:
2563 2017-01-31 Filip Pizlo <fpizlo@apple.com>
2565 Make verifyEdge a RELEASE_ASSERT
2566 <rdar://problem/30296879>
2568 Rubber stamped by Saam Barati.
2570 * dfg/DFGAbstractInterpreterInlines.h:
2571 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2573 2017-01-31 JF Bastien <jfbastien@apple.com>
2575 OSR entry: delay outer-loop compilation when at inner-loop
2576 https://bugs.webkit.org/show_bug.cgi?id=167149
2578 Reviewed by Filip Pizlo.
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).
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).
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.
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.
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.
2623 DFG tier-up was added here:
2624 https://bugs.webkit.org/show_bug.cgi?id=112838
2626 * dfg/DFGOperations.cpp:
2628 2017-01-31 Filip Pizlo <fpizlo@apple.com>
2630 The mutator should be able to perform increments of GC work
2631 https://bugs.webkit.org/show_bug.cgi?id=167528
2633 Reviewed by Keith Miller and Geoffrey Garen.
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.
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.
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.
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.
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
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.
2678 * heap/MarkStack.cpp:
2679 (JSC::MarkStackArray::transferTo):
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):
2704 (GlobalObject::finishCreation):
2705 (functionHeapCapacity):
2706 * runtime/Options.cpp:
2707 (JSC::overrideDefaults):
2708 * runtime/Options.h:
2710 2017-01-31 Tomas Popela <tpopela@redhat.com>
2712 Compilation error in JSArrayBufferView.h
2713 https://bugs.webkit.org/show_bug.cgi?id=167642
2715 Reviewed by Alex Christensen.
2717 * runtime/JSArrayBufferView.h:
2718 (JSC::JSArrayBufferView::vector):
2720 2017-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
2722 [JSC] Do not reject WebAssembly.compile() with Exception
2723 https://bugs.webkit.org/show_bug.cgi?id=167585
2725 Reviewed by Mark Lam.
2727 We accidentally reject the promise with Exception instead of Exception::value()
2728 for the result of WebAssembly::compile().
2730 * wasm/JSWebAssembly.cpp:
2731 (JSC::webAssemblyCompileFunc):
2733 2017-01-30 Joseph Pecoraro <pecoraro@apple.com>
2735 Implement PerformanceObserver
2736 https://bugs.webkit.org/show_bug.cgi?id=167546
2737 <rdar://problem/30247959>
2739 Reviewed by Ryosuke Niwa.
2741 * runtime/CommonIdentifiers.h:
2743 2017-01-30 Matt Baker <mattbaker@apple.com>
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>
2749 Reviewed by Joseph Pecoraro.
2751 This patch limits the memory used by the Inspector backend to store async
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.
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.
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.
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.
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,
2789 S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
2790 depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)
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:
2796 d = maximum stack trace depth
2797 for all S, depth(S) ≤ d + depth(s𝑘)
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.
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:
2831 2017-01-30 Ryan Haddad <ryanhaddad@apple.com>
2833 Unreviewed, rolling out r211345.
2835 The LayoutTest for this change is failing an assertion.
2839 "Web Inspector: Need some limit on Async Call Stacks for async
2841 https://bugs.webkit.org/show_bug.cgi?id=165633
2842 http://trac.webkit.org/changeset/211345
2844 2017-01-28 Matt Baker <mattbaker@apple.com>
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>
2850 Reviewed by Joseph Pecoraro.
2852 This patch limits the memory used by the Inspector backend to store async
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.
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.
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.
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.
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,
2890 S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
2891 depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)
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:
2897 d = maximum stack trace depth
2898 for all S, depth(S) ≤ d + depth(s𝑘)
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.
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:
2932 2017-01-28 Joseph Pecoraro <pecoraro@apple.com>
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
2937 Reviewed by Brian Burg.
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.
2950 2017-01-27 Yusuke Suzuki <utatane.tea@gmail.com>
2952 Lift template escape sequence restrictions in tagged templates
2953 https://bugs.webkit.org/show_bug.cgi?id=166871
2955 Reviewed by Saam Barati.
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.
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.
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.
2975 [1]: https://github.com/tc39/proposal-template-literal-revision
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):
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.
2991 * parser/NodeConstructors.h:
2992 (JSC::TemplateStringNode::TemplateStringNode):
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:
3015 2017-01-27 Saam Barati <sbarati@apple.com>
3017 Make the CLI for the sampling profiler better for inlined call site indices
3018 https://bugs.webkit.org/show_bug.cgi?id=167482
3020 Reviewed by Mark Lam.
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.
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.
3047 2017-01-27 Yusuke Suzuki <utatane.tea@gmail.com>
3049 Extend create_hash_table to specify Intrinsic
3050 https://bugs.webkit.org/show_bug.cgi?id=167505
3052 Reviewed by Sam Weinig.
3054 This patch extends create_hash_table to specify Intrinsic.
3055 We can set Intrinsic in the static property table definition
3058 And drop the adhoc code for String.fromCharCode in create_hash_table.
3060 * create_hash_table:
3061 * runtime/StringConstructor.cpp:
3063 2017-01-27 Filip Pizlo <fpizlo@apple.com>
3065 scanExternalRememberedSet needs to mergeIfNecessary
3066 https://bugs.webkit.org/show_bug.cgi?id=167523
3068 Reviewed by Keith Miller.
3070 The protocol for opaque roots is that if you add to them outside of draining, then you need to call
3073 This means that every MarkingConstraint that adds opaque roots needs to mergeIfNecessary after.
3075 scanExternalRememberedSet transitively calls addOpaqueRoot, is called from a MarkingConstraint, and
3076 was missing a call to mergeIfNecessary. This fixes it.
3078 * API/JSVirtualMachine.mm:
3079 (scanExternalRememberedSet):
3081 2017-01-27 Carlos Garcia Campos <cgarcia@igalia.com>
3083 Unreviewed. Fix GTK+ debug build after r211247.
3085 * heap/GCAssertions.h:
3087 2017-01-26 Keith Miller <keith_miller@apple.com>
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
3092 Rubber Stamped by Michael Saboff.
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.
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):
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):
3129 (valueToObjectWithoutCopy):
3130 * API/JSValueRef.cpp:
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):
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:
3208 (JSC::DFG::Node::convertToPutStructureHint):
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:
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:
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):
git://git.webkit.org / WebKit-https.git / blob