BackwardsGraph needs to consider back edges as the backward's root successor
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-03-28  Saam Barati  <sbarati@apple.com>
2
3         BackwardsGraph needs to consider back edges as the backward's root successor
4         https://bugs.webkit.org/show_bug.cgi?id=195991
5
6         Reviewed by Filip Pizlo.
7
8         * b3/testb3.cpp:
9         (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
10         (JSC::B3::run):
11
12 2019-03-28  Fujii Hironori  <Hironori.Fujii@sony.com>
13
14         Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
15         https://bugs.webkit.org/show_bug.cgi?id=196343
16
17         Reviewed by Saam Barati.
18
19         Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
20         instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.
21
22         * bytecode/Opcode.cpp:
23         (JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
24         this function is used only in Opcode.cpp. Changed macros
25         PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
26         (JSC::compareOpcodePairIndices): Replaced pair with std::pair.
27         * bytecode/Opcode.h:
28         (JSC::padOpcodeName): Moved.
29
30 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
31
32         CodeBlock::jettison() should disallow repatching its own calls
33         https://bugs.webkit.org/show_bug.cgi?id=196359
34         <rdar://problem/48973663>
35
36         Reviewed by Saam Barati.
37
38         CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
39         instruction with the jump to OSR exit. However, if the `hlt` was immediately
40         followed by a call to the CodeBlock being jettisoned, we would write over the
41         OSR exit address while unlinking all the incoming CallLinkInfos later in
42         CodeBlock::jettison().
43
44         Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
45         owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
46         repatching the call during unlinking. This is safe because this call will never
47         be reachable again after the CodeBlock is jettisoned.
48
49         * bytecode/CallLinkInfo.cpp:
50         (JSC::CallLinkInfo::CallLinkInfo):
51         (JSC::CallLinkInfo::setCallee):
52         (JSC::CallLinkInfo::clearCallee):
53         (JSC::CallLinkInfo::setCodeBlock):
54         (JSC::CallLinkInfo::clearCodeBlock):
55         * bytecode/CallLinkInfo.h:
56         (JSC::CallLinkInfo::clearedByJettison):
57         (JSC::CallLinkInfo::setClearedByJettison):
58         * bytecode/CodeBlock.cpp:
59         (JSC::CodeBlock::jettison):
60         * jit/Repatch.cpp:
61         (JSC::revertCall):
62
63 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
64
65         [JSC] Drop VM and Context cache map in JavaScriptCore.framework
66         https://bugs.webkit.org/show_bug.cgi?id=196341
67
68         Reviewed by Saam Barati.
69
70         Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
71         But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
72         JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
73         a pointer to a wrapper in VM and JSGlobalObject.
74
75         This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
76         clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.
77
78         * API/JSContext.mm:
79         (-[JSContext initWithVirtualMachine:]):
80         (-[JSContext dealloc]):
81         (-[JSContext initWithGlobalContextRef:]):
82         (-[JSContext wrapperMap]):
83         (+[JSContext contextWithJSGlobalContextRef:]):
84         * API/JSVirtualMachine.mm:
85         (-[JSVirtualMachine initWithContextGroupRef:]):
86         (-[JSVirtualMachine dealloc]):
87         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
88         (scanExternalObjectGraph):
89         (scanExternalRememberedSet):
90         (initWrapperCache): Deleted.
91         (wrapperCache): Deleted.
92         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
93         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
94         (-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
95         (-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
96         * API/JSVirtualMachineInternal.h:
97         * runtime/JSGlobalObject.h:
98         (JSC::JSGlobalObject::setAPIWrapper):
99         (JSC::JSGlobalObject::apiWrapper const):
100         * runtime/VM.h:
101
102 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
103
104         In-memory code cache should not share bytecode across domains
105         https://bugs.webkit.org/show_bug.cgi?id=196321
106
107         Reviewed by Geoffrey Garen.
108
109         Use the SourceProvider's URL to make sure that the hosts match for the
110         two SourceCodeKeys in operator==.
111
112         * parser/SourceCodeKey.h:
113         (JSC::SourceCodeKey::host const):
114         (JSC::SourceCodeKey::operator== const):
115
116 2019-03-28  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>
117
118         Silence lot of warnings when compiling with clang
119         https://bugs.webkit.org/show_bug.cgi?id=196310
120
121         Reviewed by Michael Catanzaro.
122
123         Initialize variable with default constructor.
124
125         * API/glib/JSCOptions.cpp:
126         (jsc_options_foreach):
127
128 2019-03-27  Saam Barati  <sbarati@apple.com>
129
130         validateOSREntryValue with Int52 should box the value being checked into double format
131         https://bugs.webkit.org/show_bug.cgi?id=196313
132         <rdar://problem/49306703>
133
134         Reviewed by Yusuke Suzuki.
135
136         * dfg/DFGOSREntry.cpp:
137         (JSC::DFG::prepareOSREntry):
138         * ftl/FTLLowerDFGToB3.cpp:
139         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
140
141 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
142
143         [JSC] Owner of watchpoints should validate at GC finalizing phase
144         https://bugs.webkit.org/show_bug.cgi?id=195827
145
146         Reviewed by Filip Pizlo.
147
148         This patch fixes JSC's watchpoint liveness issue by the following two policies.
149
150         1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.
151
152         Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
153         When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
154         be delayed due to incremental sweeper. So the following condition can happen.
155
156         When we have a watchpoint like the following.
157
158             class XXXWatchpoint {
159                 ObjectPropertyCondition m_key;
160                 JSCell* m_owner;
161             };
162
163         Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
164         is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
165         watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
166         we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
167         `m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
168         once the destructor of m_owner is called, this watchpoint will be destroyed too.
169
170         2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer
171
172         Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
173         delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
174         and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
175         in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
176         isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
177         with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
178         We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.
179
180         * JavaScriptCore.xcodeproj/project.pbxproj:
181         * Sources.txt:
182         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
183         (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
184         (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
185         * bytecode/CodeBlockJettisoningWatchpoint.h:
186         (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
187         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
188         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
189         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
190         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
191         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
192         * bytecode/StructureStubClearingWatchpoint.cpp:
193         (JSC::StructureStubClearingWatchpoint::fireInternal):
194         (JSC::WatchpointsOnStructureStubInfo::isValid const):
195         * bytecode/StructureStubClearingWatchpoint.h:
196         (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
197         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
198         (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
199         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
200         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
201         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
202         * dfg/DFGAdaptiveStructureWatchpoint.h:
203         (JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
204         * dfg/DFGDesiredWatchpoints.cpp:
205         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
206         * heap/Heap.cpp:
207         (JSC::Heap::finalizeUnconditionalFinalizers):
208         * llint/LLIntSlowPaths.cpp:
209         (JSC::LLInt::setupGetByIdPrototypeCache):
210         * runtime/ArrayBuffer.cpp:
211         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
212         * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
213         (JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
214         (JSC::ArrayBufferNeuteringWatchpointSet::destroy):
215         (JSC::ArrayBufferNeuteringWatchpointSet::create):
216         (JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
217         (JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
218         * runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
219         * runtime/FunctionRareData.h:
220         * runtime/JSGlobalObject.cpp:
221         (JSC::JSGlobalObject::init):
222         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
223         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
224         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
225         * runtime/StructureRareData.cpp:
226         (JSC::StructureRareData::finalizeUnconditionally):
227         * runtime/StructureRareData.h:
228         * runtime/VM.cpp:
229         (JSC::VM::VM):
230
231 2019-03-26  Saam Barati  <sbarati@apple.com>
232
233         FTL: Emit code to validate AI's state when running the compiled code
234         https://bugs.webkit.org/show_bug.cgi?id=195924
235         <rdar://problem/49003422>
236
237         Reviewed by Filip Pizlo.
238
239         This patch adds code that between the execution of each node that validates
240         the types that AI proves. This option is too expensive to turn on for our
241         regression testing, but we think it will be valuable in other types of running
242         modes, such as when running with a fuzzer.
243         
244         This patch also adds options to only probabilistically run this validation
245         after the execution of each node. As the probability is lowered, there is
246         less of a perf hit.
247         
248         This patch just adds this validation in the FTL. A follow-up patch will land
249         it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
250
251         * ftl/FTLLowerDFGToB3.cpp:
252         (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
253         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
254         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
255         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
256         (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
257         * runtime/Options.h:
258
259 2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>
260
261         WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
262         https://bugs.webkit.org/show_bug.cgi?id=196217
263
264         Reviewed by Saam Barati.
265
266         Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
267         comparison in r243446 to all min and max float operations.
268
269         * wasm/WasmAirIRGenerator.cpp:
270         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
271         (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
272         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
273         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
274         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
275         * wasm/wasm.json:
276
277 2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>
278
279         Intl.DateTimeFormat should obey 2-digit hour
280         https://bugs.webkit.org/show_bug.cgi?id=195974
281
282         Reviewed by Keith Miller.
283
284         * runtime/IntlDateTimeFormat.cpp:
285         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
286
287 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
288
289         Heap::isMarked and friends should be instance methods
290         https://bugs.webkit.org/show_bug.cgi?id=179988
291
292         Reviewed by Saam Barati.
293
294         Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
295         so that we do not need to look up Heap from the cell.
296
297         * API/JSAPIWrapperObject.mm:
298         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
299         * API/JSMarkingConstraintPrivate.cpp:
300         (JSC::isMarked):
301         * API/glib/JSAPIWrapperObjectGLib.cpp:
302         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
303         * builtins/BuiltinExecutables.cpp:
304         (JSC::BuiltinExecutables::finalizeUnconditionally):
305         * bytecode/AccessCase.cpp:
306         (JSC::AccessCase::visitWeak const):
307         (JSC::AccessCase::propagateTransitions const):
308         * bytecode/CallLinkInfo.cpp:
309         (JSC::CallLinkInfo::visitWeak):
310         * bytecode/CallLinkStatus.cpp:
311         (JSC::CallLinkStatus::finalize):
312         * bytecode/CallLinkStatus.h:
313         * bytecode/CallVariant.cpp:
314         (JSC::CallVariant::finalize):
315         * bytecode/CallVariant.h:
316         * bytecode/CodeBlock.cpp:
317         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
318         (JSC::CodeBlock::shouldJettisonDueToOldAge):
319         (JSC::shouldMarkTransition):
320         (JSC::CodeBlock::propagateTransitions):
321         (JSC::CodeBlock::determineLiveness):
322         (JSC::CodeBlock::finalizeLLIntInlineCaches):
323         (JSC::CodeBlock::finalizeUnconditionally):
324         (JSC::CodeBlock::jettison):
325         * bytecode/CodeBlock.h:
326         * bytecode/ExecutableToCodeBlockEdge.cpp:
327         (JSC::ExecutableToCodeBlockEdge::visitChildren):
328         (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
329         (JSC::ExecutableToCodeBlockEdge::runConstraint):
330         * bytecode/GetByIdStatus.cpp:
331         (JSC::GetByIdStatus::finalize):
332         * bytecode/GetByIdStatus.h:
333         * bytecode/GetByIdVariant.cpp:
334         (JSC::GetByIdVariant::finalize):
335         * bytecode/GetByIdVariant.h:
336         * bytecode/InByIdStatus.cpp:
337         (JSC::InByIdStatus::finalize):
338         * bytecode/InByIdStatus.h:
339         * bytecode/InByIdVariant.cpp:
340         (JSC::InByIdVariant::finalize):
341         * bytecode/InByIdVariant.h:
342         * bytecode/ObjectPropertyCondition.cpp:
343         (JSC::ObjectPropertyCondition::isStillLive const):
344         * bytecode/ObjectPropertyCondition.h:
345         * bytecode/ObjectPropertyConditionSet.cpp:
346         (JSC::ObjectPropertyConditionSet::areStillLive const):
347         * bytecode/ObjectPropertyConditionSet.h:
348         * bytecode/PolymorphicAccess.cpp:
349         (JSC::PolymorphicAccess::visitWeak const):
350         * bytecode/PropertyCondition.cpp:
351         (JSC::PropertyCondition::isStillLive const):
352         * bytecode/PropertyCondition.h:
353         * bytecode/PutByIdStatus.cpp:
354         (JSC::PutByIdStatus::finalize):
355         * bytecode/PutByIdStatus.h:
356         * bytecode/PutByIdVariant.cpp:
357         (JSC::PutByIdVariant::finalize):
358         * bytecode/PutByIdVariant.h:
359         * bytecode/RecordedStatuses.cpp:
360         (JSC::RecordedStatuses::finalizeWithoutDeleting):
361         (JSC::RecordedStatuses::finalize):
362         * bytecode/RecordedStatuses.h:
363         * bytecode/StructureSet.cpp:
364         (JSC::StructureSet::isStillAlive const):
365         * bytecode/StructureSet.h:
366         * bytecode/StructureStubInfo.cpp:
367         (JSC::StructureStubInfo::visitWeakReferences):
368         * dfg/DFGPlan.cpp:
369         (JSC::DFG::Plan::finalizeInGC):
370         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
371         * heap/GCIncomingRefCounted.h:
372         * heap/GCIncomingRefCountedInlines.h:
373         (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
374         * heap/GCIncomingRefCountedSet.h:
375         * heap/GCIncomingRefCountedSetInlines.h:
376         (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
377         (JSC::GCIncomingRefCountedSet<T>::sweep):
378         (JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
379         (JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
380         * heap/Heap.cpp:
381         (JSC::Heap::addToRememberedSet):
382         (JSC::Heap::runEndPhase):
383         (JSC::Heap::sweepArrayBuffers):
384         (JSC::Heap::addCoreConstraints):
385         * heap/Heap.h:
386         * heap/HeapInlines.h:
387         (JSC::Heap::isMarked):
388         * heap/HeapSnapshotBuilder.cpp:
389         (JSC::HeapSnapshotBuilder::appendNode):
390         * heap/SlotVisitor.cpp:
391         (JSC::SlotVisitor::appendToMarkStack):
392         (JSC::SlotVisitor::visitChildren):
393         * jit/PolymorphicCallStubRoutine.cpp:
394         (JSC::PolymorphicCallStubRoutine::visitWeak):
395         * runtime/ErrorInstance.cpp:
396         (JSC::ErrorInstance::finalizeUnconditionally):
397         * runtime/InferredValueInlines.h:
398         (JSC::InferredValue::finalizeUnconditionally):
399         * runtime/StackFrame.h:
400         (JSC::StackFrame::isMarked const):
401         * runtime/Structure.cpp:
402         (JSC::Structure::isCheapDuringGC):
403         (JSC::Structure::markIfCheap):
404         * runtime/Structure.h:
405         * runtime/TypeProfiler.cpp:
406         (JSC::TypeProfiler::invalidateTypeSetCache):
407         * runtime/TypeProfiler.h:
408         * runtime/TypeSet.cpp:
409         (JSC::TypeSet::invalidateCache):
410         * runtime/TypeSet.h:
411         * runtime/WeakMapImpl.cpp:
412         (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
413         * runtime/WeakMapImplInlines.h:
414         (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
415
416 2019-03-25  Keith Miller  <keith_miller@apple.com>
417
418         ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
419         https://bugs.webkit.org/show_bug.cgi?id=196176
420
421         Reviewed by Saam Barati.
422
423         convertToCompareEqPtr should allow for either CompareStrictEq or
424         the SameValue DFG node. This fixes the old assertion that only
425         allowed CompareStrictEq.
426
427         * dfg/DFGNode.h:
428         (JSC::DFG::Node::convertToCompareEqPtr):
429
430 2019-03-25  Tadeu Zagallo  <tzagallo@apple.com>
431
432         WebAssembly: f32.max with NaN generates incorrect result
433         https://bugs.webkit.org/show_bug.cgi?id=175691
434         <rdar://problem/33952228>
435
436         Reviewed by Saam Barati.
437
438         Fix the B3 and Air compilation for f32.max. In order to handle the NaN
439         case, we need an extra GreaterThan comparison on top of the existing
440         Equal and LessThan ones.
441
442         * wasm/WasmAirIRGenerator.cpp:
443         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
444         * wasm/wasm.json:
445
446 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
447
448         Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
449         https://bugs.webkit.org/show_bug.cgi?id=195982
450
451         * jit/ExecutableAllocator.h:
452         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
453
454 2019-03-25  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
455
456         Remove NavigatorContentUtils in WebCore/Modules
457         https://bugs.webkit.org/show_bug.cgi?id=196070
458
459         Reviewed by Alex Christensen.
460
461         NavigatorContentUtils was to support the custom scheme spec [1].
462         However, in WebKit side, no port has supported the feature in
463         WebKit layer after EFL port was removed. So there has been the
464         only IDL implementation of the NavigatorContentUtils in WebCore.
465         So we don't need to keep the implementation in WebCore anymore.
466
467         [1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
468
469         * Configurations/FeatureDefines.xcconfig:
470
471 2019-03-23  Mark Lam  <mark.lam@apple.com>
472
473         Rolling out r243032 and r243071 because the fix is incorrect.
474         https://bugs.webkit.org/show_bug.cgi?id=195892
475         <rdar://problem/48981239>
476
477         Not reviewed.
478
479         The fix is incorrect: it relies on being able to determine liveness of an object
480         in an ObjectPropertyCondition based on the state of the object's MarkedBit.
481         However, there's no guarantee that GC has run and that the MarkedBit is already
482         set even if the object is live.  As a result, we may not re-install adaptive
483         watchpoints based on presumed dead objects which are actually live.
484
485         I'm rolling this out, and will implement a more comprehensive fix to handle
486         watchpoint liveness later.
487
488         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
489         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
490         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
491         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
492         * bytecode/ObjectPropertyCondition.cpp:
493         (JSC::ObjectPropertyCondition::dumpInContext const):
494         * bytecode/StructureStubClearingWatchpoint.cpp:
495         (JSC::StructureStubClearingWatchpoint::fireInternal):
496         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
497         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
498         * runtime/StructureRareData.cpp:
499         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
500
501 2019-03-23  Keith Miller  <keith_miller@apple.com>
502
503         Refactor clz/ctz and fix getLSBSet.
504         https://bugs.webkit.org/show_bug.cgi?id=196162
505
506         Reviewed by Saam Barati.
507
508         Refactor references of clz32/64 and ctz32 to use clz and ctz,
509         respectively.
510
511         * dfg/DFGAbstractInterpreterInlines.h:
512         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
513         * dfg/DFGOperations.cpp:
514         * runtime/JSBigInt.cpp:
515         (JSC::JSBigInt::digitDiv):
516         (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
517         (JSC::JSBigInt::calculateMaximumCharactersRequired):
518         (JSC::JSBigInt::toStringBasePowerOfTwo):
519         (JSC::JSBigInt::compareToDouble):
520         * runtime/MathObject.cpp:
521         (JSC::mathProtoFuncClz32):
522
523 2019-03-23  Yusuke Suzuki  <ysuzuki@apple.com>
524
525         [JSC] Shrink sizeof(RegExp)
526         https://bugs.webkit.org/show_bug.cgi?id=196133
527
528         Reviewed by Mark Lam.
529
530         Some applications have many RegExp cells. But RegExp cells are very large (144B).
531         This patch reduces the size from 144B to 48B by,
532
533         1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
534         2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.
535
536         * runtime/RegExp.cpp:
537         (JSC::RegExp::finishCreation):
538         (JSC::RegExp::estimatedSize):
539         (JSC::RegExp::compile):
540         (JSC::RegExp::matchConcurrently):
541         (JSC::RegExp::compileMatchOnly):
542         (JSC::RegExp::deleteCode):
543         (JSC::RegExp::printTraceData):
544         * runtime/RegExp.h:
545         * runtime/RegExpInlines.h:
546         (JSC::RegExp::hasCodeFor):
547         (JSC::RegExp::matchInline):
548         (JSC::RegExp::hasMatchOnlyCodeFor):
549
550 2019-03-22  Keith Rollin  <krollin@apple.com>
551
552         Enable ThinLTO support in Production builds
553         https://bugs.webkit.org/show_bug.cgi?id=190758
554         <rdar://problem/45413233>
555
556         Reviewed by Daniel Bates.
557
558         Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
559         .xcconfig files with regards to LTO settings. However, don't actually
560         enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
561         due to <rdar://problem/24543547>.
562
563         * Configurations/Base.xcconfig:
564
565 2019-03-22  Mark Lam  <mark.lam@apple.com>
566
567         Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
568         https://bugs.webkit.org/show_bug.cgi?id=196154
569         <rdar://problem/49145307>
570
571         Reviewed by Filip Pizlo.
572
573         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
574         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
575
576 2019-03-22  Mark Lam  <mark.lam@apple.com>
577
578         Placate exception check validation in constructJSWebAssemblyLinkError().
579         https://bugs.webkit.org/show_bug.cgi?id=196152
580         <rdar://problem/49145257>
581
582         Reviewed by Michael Saboff.
583
584         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
585         (JSC::constructJSWebAssemblyLinkError):
586
587 2019-03-22  Timothy Hatcher  <timothy@apple.com>
588
589         Change macosx() to macos() in WK_API... and JSC_API... macros.
590         https://bugs.webkit.org/show_bug.cgi?id=196106
591
592         Reviewed by Brian Burg.
593
594         * API/JSBasePrivate.h:
595         * API/JSContext.h:
596         * API/JSContextPrivate.h:
597         * API/JSContextRef.h:
598         * API/JSContextRefInternal.h:
599         * API/JSContextRefPrivate.h:
600         * API/JSManagedValue.h:
601         * API/JSObjectRef.h:
602         * API/JSObjectRefPrivate.h:
603         * API/JSRemoteInspector.h:
604         * API/JSScript.h:
605         * API/JSTypedArray.h:
606         * API/JSValue.h:
607         * API/JSValuePrivate.h:
608         * API/JSValueRef.h:
609         * API/JSVirtualMachinePrivate.h:
610
611 2019-03-22  Yusuke Suzuki  <ysuzuki@apple.com>
612
613         Unreviewed, build fix for Windows
614         https://bugs.webkit.org/show_bug.cgi?id=196122
615
616         * runtime/FunctionExecutable.cpp:
617
618 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
619
620         [JSC] Shrink sizeof(FunctionExecutable) by 16bytes
621         https://bugs.webkit.org/show_bug.cgi?id=196122
622
623         Reviewed by Saam Barati.
624
625         This patch reduces sizeof(FunctionExecutable) by 16 bytes.
626
627         1. ScriptExecutable::m_numParametersForCall and ScriptExecutable::m_numParametersForConstruct are not used in a meaningful way. Removed them.
628         2. ScriptExecutable::m_lastLine and ScriptExecutable::m_endColumn can be calculated from UnlinkedFunctionExecutable. So FunctionExecutable does not need to hold it.
629            This patch adds GlobalExecutable, which are non-function ScriptExecutables, and move m_lastLine and m_endColumn to this class.
630         3. FunctionExecutable still needs to have the feature overriding m_lastLine and m_endColumn. We move overridden data in FunctionExecutable::RareData.
631
632         * CMakeLists.txt:
633         * JavaScriptCore.xcodeproj/project.pbxproj:
634         * Sources.txt:
635         * bytecode/UnlinkedFunctionExecutable.cpp:
636         (JSC::UnlinkedFunctionExecutable::link):
637         * runtime/EvalExecutable.cpp:
638         (JSC::EvalExecutable::EvalExecutable):
639         * runtime/EvalExecutable.h:
640         * runtime/FunctionExecutable.cpp:
641         (JSC::FunctionExecutable::FunctionExecutable):
642         (JSC::FunctionExecutable::ensureRareDataSlow):
643         (JSC::FunctionExecutable::overrideInfo):
644         * runtime/FunctionExecutable.h:
645         * runtime/GlobalExecutable.cpp: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
646         * runtime/GlobalExecutable.h: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
647         (JSC::GlobalExecutable::lastLine const):
648         (JSC::GlobalExecutable::endColumn const):
649         (JSC::GlobalExecutable::recordParse):
650         (JSC::GlobalExecutable::GlobalExecutable):
651         * runtime/ModuleProgramExecutable.cpp:
652         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
653         * runtime/ModuleProgramExecutable.h:
654         * runtime/ProgramExecutable.cpp:
655         (JSC::ProgramExecutable::ProgramExecutable):
656         * runtime/ProgramExecutable.h:
657         * runtime/ScriptExecutable.cpp:
658         (JSC::ScriptExecutable::clearCode):
659         (JSC::ScriptExecutable::installCode):
660         (JSC::ScriptExecutable::hasClearableCode const):
661         (JSC::ScriptExecutable::newCodeBlockFor):
662         (JSC::ScriptExecutable::typeProfilingEndOffset const):
663         (JSC::ScriptExecutable::recordParse):
664         (JSC::ScriptExecutable::lastLine const):
665         (JSC::ScriptExecutable::endColumn const):
666         * runtime/ScriptExecutable.h:
667         (JSC::ScriptExecutable::hasJITCodeForCall const):
668         (JSC::ScriptExecutable::hasJITCodeForConstruct const):
669         (JSC::ScriptExecutable::recordParse):
670         (JSC::ScriptExecutable::lastLine const): Deleted.
671         (JSC::ScriptExecutable::endColumn const): Deleted.
672         * tools/FunctionOverrides.h:
673
674 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
675
676         [JSC] Shrink sizeof(RegExpObject)
677         https://bugs.webkit.org/show_bug.cgi?id=196130
678
679         Reviewed by Saam Barati.
680
681         sizeof(RegExpObject) is 48B due to one bool flag. We should compress this flag into lower bit of RegExp* field so that we can make RegExpObject 32B.
682         It saves memory footprint 1.3% in RAMification's regexp.
683
684         * dfg/DFGSpeculativeJIT.cpp:
685         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
686         (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
687         * ftl/FTLAbstractHeapRepository.h:
688         * ftl/FTLLowerDFGToB3.cpp:
689         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
690         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
691         * runtime/RegExpObject.cpp:
692         (JSC::RegExpObject::RegExpObject):
693         (JSC::RegExpObject::visitChildren):
694         (JSC::RegExpObject::getOwnPropertySlot):
695         (JSC::RegExpObject::defineOwnProperty):
696         * runtime/RegExpObject.h:
697
698 2019-03-21  Tomas Popela  <tpopela@redhat.com>
699
700         [JSC] Fix build after r243232 on unsupported 64bit architectures
701         https://bugs.webkit.org/show_bug.cgi?id=196072
702
703         Reviewed by Keith Miller.
704
705         As Keith suggested we already expect 16 free bits at the top of any
706         pointer for JSValue even for the unsupported 64 bit arches.
707
708         * bytecode/CodeOrigin.h:
709
710 2019-03-21  Mark Lam  <mark.lam@apple.com>
711
712         Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
713         https://bugs.webkit.org/show_bug.cgi?id=196116
714         <rdar://problem/48976951>
715
716         Reviewed by Filip Pizlo.
717
718         The DFG backend should not make assumptions about what optimizations the front end
719         will or will not do.  The assertion asserts that the operand cannot be known to be
720         a cell.  However, it is not guaranteed that the front end will fold away this case.
721         Also, the DFG backend is perfectly capable of generating code to handle the case
722         where the operand is a cell.
723
724         The attached test case demonstrates a case where the operand can be a known cell.
725         The test needs to be run with the concurrent JIT and GC, and is racy.  It used to
726         trip up this assertion about once every 10 runs or so.
727
728         * dfg/DFGSpeculativeJIT64.cpp:
729         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
730
731 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
732
733         JSC::createError should clear exception thrown by errorDescriptionForValue
734         https://bugs.webkit.org/show_bug.cgi?id=196089
735
736         Reviewed by Mark Lam.
737
738         errorDescriptionForValue returns a nullString in case of failure, but it
739         might also throw an OOM exception when resolving a rope string. We need
740         to clear any potential exceptions thrown by errorDescriptionForValue
741         before returning the OOM from JSC::createError.
742
743         * runtime/ExceptionHelpers.cpp:
744         (JSC::createError):
745
746 2019-03-21  Robin Morisset  <rmorisset@apple.com>
747
748         B3::Opcode can fit in a single byte, shrinking B3Value by 8 bytes
749         https://bugs.webkit.org/show_bug.cgi?id=196014
750
751         Reviewed by Keith Miller.
752
753         B3::Opcode has less than one hundred cases, so it can easily fit in one byte (from two currently)
754         This shrinks B3::Kind from 4 bytes to 2 (by removing the byte of padding at the end).
755         This in turns eliminate padding from B3::Value, shrinking it by 8 bytes (out of 80).
756
757         * b3/B3Opcode.h:
758
759 2019-03-21  Michael Catanzaro  <mcatanzaro@igalia.com>
760
761         Unreviewed, more clang 3.8 build fixes
762         https://bugs.webkit.org/show_bug.cgi?id=195947
763         <rdar://problem/49069219>
764
765         In the spirit of making our code worse to please old compilers....
766
767         * bindings/ScriptValue.cpp:
768         (Inspector::jsToInspectorValue):
769         * bytecode/GetterSetterAccessCase.cpp:
770         (JSC::GetterSetterAccessCase::create):
771         (JSC::GetterSetterAccessCase::clone const):
772         * bytecode/InstanceOfAccessCase.cpp:
773         (JSC::InstanceOfAccessCase::clone const):
774         * bytecode/IntrinsicGetterAccessCase.cpp:
775         (JSC::IntrinsicGetterAccessCase::clone const):
776         * bytecode/ModuleNamespaceAccessCase.cpp:
777         (JSC::ModuleNamespaceAccessCase::clone const):
778         * bytecode/ProxyableAccessCase.cpp:
779         (JSC::ProxyableAccessCase::clone const):
780
781 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
782
783         [JSC] Do not create JIT related data under non-JIT mode
784         https://bugs.webkit.org/show_bug.cgi?id=195982
785
786         Reviewed by Mark Lam.
787
788         We avoid creations of JIT related data structures under non-JIT mode.
789         This patch removes the following allocations.
790
791         1. JITThunks
792         2. FTLThunks
793         3. FixedVMPoolExecutableAllocator
794         4. noJITValueProfileSingleton since it is no longer used
795         5. ARM disassembler should be initialized when it is used
796         6. Wasm related data structures are accidentally allocated if VM::canUseJIT() == false &&
797            Options::useWebAssembly() == true. Add Wasm::isSupported() function to check the both conditions.
798
799         * CMakeLists.txt:
800         * JavaScriptCore.xcodeproj/project.pbxproj:
801         * heap/Heap.cpp:
802         (JSC::Heap::runEndPhase):
803         * jit/ExecutableAllocator.cpp:
804         (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
805         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
806         (JSC::ExecutableAllocator::isValid const):
807         (JSC::ExecutableAllocator::underMemoryPressure):
808         (JSC::ExecutableAllocator::memoryPressureMultiplier):
809         (JSC::ExecutableAllocator::allocate):
810         (JSC::ExecutableAllocator::isValidExecutableMemory):
811         (JSC::ExecutableAllocator::getLock const):
812         (JSC::ExecutableAllocator::committedByteCount):
813         (JSC::ExecutableAllocator::dumpProfile):
814         (JSC::startOfFixedExecutableMemoryPoolImpl):
815         (JSC::endOfFixedExecutableMemoryPoolImpl):
816         (JSC::ExecutableAllocator::initialize):
817         (JSC::ExecutableAllocator::initializeAllocator): Deleted.
818         (JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
819         (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
820         * jit/ExecutableAllocator.h:
821         (JSC::ExecutableAllocatorBase::isValid const):
822         (JSC::ExecutableAllocatorBase::underMemoryPressure):
823         (JSC::ExecutableAllocatorBase::memoryPressureMultiplier):
824         (JSC::ExecutableAllocatorBase::dumpProfile):
825         (JSC::ExecutableAllocatorBase::allocate):
826         (JSC::ExecutableAllocatorBase::setJITEnabled):
827         (JSC::ExecutableAllocatorBase::isValidExecutableMemory):
828         (JSC::ExecutableAllocatorBase::committedByteCount):
829         (JSC::ExecutableAllocatorBase::getLock const):
830         (JSC::ExecutableAllocator::isValid const): Deleted.
831         (JSC::ExecutableAllocator::underMemoryPressure): Deleted.
832         (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
833         (JSC::ExecutableAllocator::allocate): Deleted.
834         (JSC::ExecutableAllocator::setJITEnabled): Deleted.
835         (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
836         (JSC::ExecutableAllocator::committedByteCount): Deleted.
837         (JSC::ExecutableAllocator::getLock const): Deleted.
838         * jsc.cpp:
839         (functionWebAssemblyMemoryMode):
840         * runtime/InitializeThreading.cpp:
841         (JSC::initializeThreading):
842         * runtime/JSGlobalObject.cpp:
843         (JSC::JSGlobalObject::init):
844         * runtime/JSLock.cpp:
845         (JSC::JSLock::didAcquireLock):
846         * runtime/Options.cpp:
847         (JSC::recomputeDependentOptions):
848         * runtime/VM.cpp:
849         (JSC::enableAssembler):
850         (JSC::VM::canUseAssembler):
851         (JSC::VM::VM):
852         * runtime/VM.h:
853         * wasm/WasmCapabilities.h: Added.
854         (JSC::Wasm::isSupported):
855         * wasm/WasmFaultSignalHandler.cpp:
856         (JSC::Wasm::enableFastMemory):
857
858 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
859
860         [JSC] Fix JSC build with newer ICU
861         https://bugs.webkit.org/show_bug.cgi?id=196098
862
863         Reviewed by Keith Miller.
864
865         IntlDateTimeFormat and IntlNumberFormat have switch statement over ICU's enums. However it lacks "default" clause so that
866         the compile error occurs when a new enum value is added in ICU side. We should have "default" clause which just fallbacks
867         "unknown"_s case. The behavior is not changed since we already have `return "unknown"_s;` statement anyway after the
868         switch statement. This patch just suppresses a compile error.
869
870         * runtime/IntlDateTimeFormat.cpp:
871         (JSC::IntlDateTimeFormat::partTypeString):
872         * runtime/IntlNumberFormat.cpp:
873         (JSC::IntlNumberFormat::partTypeString):
874
875 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
876
877         JSObject::putDirectIndexSlowOrBeyondVectorLength should check if indexIsSufficientlyBeyondLengthForSparseMap
878         https://bugs.webkit.org/show_bug.cgi?id=196078
879         <rdar://problem/35925380>
880
881         Reviewed by Mark Lam.
882
883         Unlike the other variations of putByIndex, it only checked if the index
884         was larger than MIN_SPARSE_ARRAY_INDEX when the indexingType was
885         ALL_BLANK_INDEXING_TYPES. This resulted in a huge butterfly being
886         allocated for object literals (e.g. `{[9e4]: ...}`) and objects parsed
887         from JSON.
888
889         * runtime/JSObject.cpp:
890         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
891
892 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
893
894         CachedUnlinkedSourceCodeShape::m_provider should be a CachedRefPtr
895         https://bugs.webkit.org/show_bug.cgi?id=196079
896
897         Reviewed by Saam Barati.
898
899         It was mistakenly cached as CachedPtr, which was leaking the decoded SourceProvider.
900
901         * runtime/CachedTypes.cpp:
902         (JSC::CachedUnlinkedSourceCodeShape::encode):
903
904 2019-03-21  Mark Lam  <mark.lam@apple.com>
905
906         Placate exception check validation in operationArrayIndexOfString().
907         https://bugs.webkit.org/show_bug.cgi?id=196067
908         <rdar://problem/49056572>
909
910         Reviewed by Michael Saboff.
911
912         * dfg/DFGOperations.cpp:
913
914 2019-03-21  Xan Lopez  <xan@igalia.com>
915
916         [JSC][x86] Drop support for x87 floating point
917         https://bugs.webkit.org/show_bug.cgi?id=194853
918
919         Reviewed by Don Olmstead.
920
921         Require SSE2 throughout the codebase, and remove x87 support where
922         it was optionally available. SSE2 detection happens at compile
923         time through a static_assert.
924
925         * assembler/MacroAssemblerX86.h:
926         (JSC::MacroAssemblerX86::storeDouble):
927         (JSC::MacroAssemblerX86::moveDoubleToInts):
928         (JSC::MacroAssemblerX86::supportsFloatingPoint):
929         (JSC::MacroAssemblerX86::supportsFloatingPointTruncate):
930         (JSC::MacroAssemblerX86::supportsFloatingPointSqrt):
931         (JSC::MacroAssemblerX86::supportsFloatingPointAbs):
932         * assembler/MacroAssemblerX86Common.cpp:
933         * assembler/MacroAssemblerX86Common.h:
934         (JSC::MacroAssemblerX86Common::moveDouble):
935         (JSC::MacroAssemblerX86Common::loadDouble):
936         (JSC::MacroAssemblerX86Common::loadFloat):
937         (JSC::MacroAssemblerX86Common::storeDouble):
938         (JSC::MacroAssemblerX86Common::storeFloat):
939         (JSC::MacroAssemblerX86Common::convertDoubleToFloat):
940         (JSC::MacroAssemblerX86Common::convertFloatToDouble):
941         (JSC::MacroAssemblerX86Common::addDouble):
942         (JSC::MacroAssemblerX86Common::addFloat):
943         (JSC::MacroAssemblerX86Common::divDouble):
944         (JSC::MacroAssemblerX86Common::divFloat):
945         (JSC::MacroAssemblerX86Common::subDouble):
946         (JSC::MacroAssemblerX86Common::subFloat):
947         (JSC::MacroAssemblerX86Common::mulDouble):
948         (JSC::MacroAssemblerX86Common::mulFloat):
949         (JSC::MacroAssemblerX86Common::convertInt32ToDouble):
950         (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
951         (JSC::MacroAssemblerX86Common::branchDouble):
952         (JSC::MacroAssemblerX86Common::branchFloat):
953         (JSC::MacroAssemblerX86Common::compareDouble):
954         (JSC::MacroAssemblerX86Common::compareFloat):
955         (JSC::MacroAssemblerX86Common::branchTruncateDoubleToInt32):
956         (JSC::MacroAssemblerX86Common::truncateDoubleToInt32):
957         (JSC::MacroAssemblerX86Common::truncateFloatToInt32):
958         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
959         (JSC::MacroAssemblerX86Common::branchDoubleNonZero):
960         (JSC::MacroAssemblerX86Common::branchDoubleZeroOrNaN):
961         (JSC::MacroAssemblerX86Common::lshiftPacked):
962         (JSC::MacroAssemblerX86Common::rshiftPacked):
963         (JSC::MacroAssemblerX86Common::orPacked):
964         (JSC::MacroAssemblerX86Common::move32ToFloat):
965         (JSC::MacroAssemblerX86Common::moveFloatTo32):
966         (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
967         (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
968         * offlineasm/x86.rb:
969         * runtime/MathCommon.cpp:
970         (JSC::operationMathPow):
971
972 2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
973
974         [GLIB] User data not correctly passed to callback of functions and constructors with no parameters
975         https://bugs.webkit.org/show_bug.cgi?id=196073
976
977         Reviewed by Michael Catanzaro.
978
979         This is because GClosure always expects a first parameter as instance. In case of functions or constructors with
980         no parameters we insert a fake instance which is just a null pointer that is ignored by the callback. But
981         if the function/constructor has user data the callback will expect one parameter for the user data. In that case
982         we can simply swap instance/user data so that the fake instance will be the second argument and user data the
983         first one.
984
985         * API/glib/JSCClass.cpp:
986         (jscClassCreateConstructor): Use g_cclosure_new_swap() if parameters is empty and user data was provided.
987         * API/glib/JSCValue.cpp:
988         (jscValueFunctionCreate): Ditto.
989
990 2019-03-21  Pablo Saavedra  <psaavedra@igalia.com>
991
992         [JSC][32-bit] Build failure after r243232
993         https://bugs.webkit.org/show_bug.cgi?id=196068
994
995         Reviewed by Mark Lam.
996
997         * dfg/DFGOSRExit.cpp:
998         (JSC::DFG::reifyInlinedCallFrames):
999         * dfg/DFGOSRExitCompilerCommon.cpp:
1000         (JSC::DFG::reifyInlinedCallFrames):
1001
1002 2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
1003
1004         [GLib] Returning G_TYPE_OBJECT from a method does not work
1005         https://bugs.webkit.org/show_bug.cgi?id=195574
1006
1007         Reviewed by Michael Catanzaro.
1008
1009         Add more documentation to clarify the ownership of wrapped objects when created and when returned by functions.
1010
1011         * API/glib/JSCCallbackFunction.cpp:
1012         (JSC::JSCCallbackFunction::construct): Also allow to return boxed types from a constructor.
1013         * API/glib/JSCClass.cpp:
1014         * API/glib/JSCValue.cpp:
1015
1016 2019-03-21  Mark Lam  <mark.lam@apple.com>
1017
1018         Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.
1019         https://bugs.webkit.org/show_bug.cgi?id=196055
1020         <rdar://problem/49067448>
1021
1022         Reviewed by Yusuke Suzuki.
1023
1024         We are doing this because:
1025         1. We expect the array to be densely packed.
1026         2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent)
1027            expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH
1028            if we don't want to use an ArrayStorage shape.
1029         3. There's no reason why an array with spread needs to be that large anyway.
1030            MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty.
1031
1032         In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and
1033         emitAllocateButterfly() to check for overflows.
1034
1035         * assembler/AbortReason.h:
1036         * dfg/DFGOperations.cpp:
1037         * dfg/DFGSpeculativeJIT.cpp:
1038         (JSC::DFG::SpeculativeJIT::compileCreateRest):
1039         (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
1040         (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
1041         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
1042         * ftl/FTLLowerDFGToB3.cpp:
1043         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
1044         * runtime/ArrayConventions.h:
1045         * runtime/CommonSlowPaths.cpp:
1046         (JSC::SLOW_PATH_DECL):
1047
1048 2019-03-20  Yusuke Suzuki  <ysuzuki@apple.com>
1049
1050         [JSC] Use finalizer in JSGlobalLexicalEnvironment and JSGlobalObject
1051         https://bugs.webkit.org/show_bug.cgi?id=195992
1052
1053         Reviewed by Keith Miller and Mark Lam.
1054
1055         JSGlobalLexicalEnvironment and JSGlobalObject have their own CompleteSubspace to call destructors while they are not inheriting JSDestructibleObject.
1056         But it is too costly since (1) it requires CompleteSubspace in VM, (2) both objects allocate MarkedBlocks while # of them are really small.
1057
1058         Instead of using CompleteSubspace, we just set finalizers for them. Since these objects are rarely allocated, setting finalizers does not show
1059         memory / performance problems (actually, previously we used finalizer for ArrayPrototype due to the same reason, and it does not show any problems).
1060
1061         And we also add following two changes to JSSegmentedVariableObject.
1062
1063         1. Remove one boolean used for debugging in Release build. It enlarges sizeof(JSSegmentedVariableObject) and allocates one more MarkedBlock.
1064         2. Use cellLock() instead.
1065
1066         * CMakeLists.txt:
1067         * JavaScriptCore.xcodeproj/project.pbxproj:
1068         * Sources.txt:
1069         * runtime/JSSegmentedVariableObject.cpp:
1070         (JSC::JSSegmentedVariableObject::findVariableIndex):
1071         (JSC::JSSegmentedVariableObject::addVariables):
1072         (JSC::JSSegmentedVariableObject::visitChildren):
1073         (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
1074         (JSC::JSSegmentedVariableObject::finishCreation):
1075         * runtime/JSSegmentedVariableObject.h:
1076         (JSC::JSSegmentedVariableObject::subspaceFor): Deleted.
1077         * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Removed.
1078         * runtime/JSSegmentedVariableObjectHeapCellType.h: Removed.
1079         * runtime/StringIteratorPrototype.cpp:
1080         * runtime/VM.cpp:
1081         (JSC::VM::VM):
1082         * runtime/VM.h:
1083
1084 2019-03-20  Saam Barati  <sbarati@apple.com>
1085
1086         DFG::AbstractValue::validateOSREntry is wrong when isHeapTop and the incoming value is Empty
1087         https://bugs.webkit.org/show_bug.cgi?id=195721
1088
1089         Reviewed by Filip Pizlo.
1090
1091         There was a check in AbstractValue::validateOSREntry where it checked
1092         if isHeapTop(), and if so, just returned true. However, this is wrong
1093         if the value we're checking against is the empty value, since HeapTop
1094         does not include the Empty value. Instead, this check should be
1095         isBytecodeTop(), which does account for the empty value.
1096         
1097         This patch also does a couple of other things:
1098         - For our OSR entry AbstractValues, we were using HeapTop to mark
1099          a dead value. That is now changed to BytecodeTop. (The idea here
1100          is just to have validateOSREntry return early.)
1101         - It wasn't obvious to me how I could make this fail in JS code.
1102          The symptom we'd end up seeing is something like a nullptr derefernece
1103          from forgetting to do a TDZ check. Instead, I've added a unit test.
1104          This unit test lives in a new test file: testdfg. testdfg is similar
1105          to testb3/testair/testapi.
1106
1107         * JavaScriptCore.xcodeproj/project.pbxproj:
1108         * bytecode/SpeculatedType.h:
1109         * dfg/DFGAbstractValue.h:
1110         (JSC::DFG::AbstractValue::isBytecodeTop const):
1111         (JSC::DFG::AbstractValue::validateOSREntryValue const):
1112         * dfg/testdfg.cpp: Added.
1113         (hiddenTruthBecauseNoReturnIsStupid):
1114         (usage):
1115         (JSC::DFG::testEmptyValueDoesNotValidateWithHeapTop):
1116         (JSC::DFG::run):
1117         (run):
1118         (main):
1119         * shell/CMakeLists.txt:
1120
1121 2019-03-20  Saam Barati  <sbarati@apple.com>
1122
1123         typeOfDoubleSum is wrong for when NaN can be produced
1124         https://bugs.webkit.org/show_bug.cgi?id=196030
1125
1126         Reviewed by Filip Pizlo.
1127
1128         We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
1129         It assumed that the only way the resulting type could be NaN is if one of
1130         the inputs were NaN. However, this is wrong. NaN can be produced in at least
1131         these cases:
1132           Infinity - Infinity
1133           Infinity + (-Infinity)
1134           Infinity * 0
1135
1136         * bytecode/SpeculatedType.cpp:
1137         (JSC::typeOfDoubleSumOrDifferenceOrProduct):
1138         (JSC::typeOfDoubleSum):
1139         (JSC::typeOfDoubleDifference):
1140         (JSC::typeOfDoubleProduct):
1141
1142 2019-03-20  Simon Fraser  <simon.fraser@apple.com>
1143
1144         Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
1145         https://bugs.webkit.org/show_bug.cgi?id=196049
1146
1147         Reviewed by Tim Horton.
1148
1149         This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
1150         overflow scrolling in general, so rename it.
1151
1152         * Configurations/FeatureDefines.xcconfig:
1153
1154 2019-03-20  Saam Barati  <sbarati@apple.com>
1155
1156         GetCallee does not report the correct type in AI
1157         https://bugs.webkit.org/show_bug.cgi?id=195981
1158
1159         Reviewed by Yusuke Suzuki.
1160
1161         I found this as part of my work in:
1162         https://bugs.webkit.org/show_bug.cgi?id=195924
1163         
1164         I'm not sure how to write a test for it.
1165         
1166         GetCallee was always reporting that the result is SpecFunction. However,
1167         for eval, it may result in just a JSCallee object, which is not a JSFunction.
1168
1169         * dfg/DFGAbstractInterpreterInlines.h:
1170         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1171
1172 2019-03-20  Mark Lam  <mark.lam@apple.com>
1173
1174         Open source arm64e code.
1175         https://bugs.webkit.org/show_bug.cgi?id=196012
1176         <rdar://problem/49066237>
1177
1178         Reviewed by Keith Miller.
1179
1180         * JavaScriptCore.xcodeproj/project.pbxproj:
1181         * Sources.txt:
1182         * assembler/ARM64EAssembler.h: Added.
1183         (JSC::ARM64EAssembler::encodeGroup1):
1184         (JSC::ARM64EAssembler::encodeGroup2):
1185         (JSC::ARM64EAssembler::encodeGroup4):
1186         (JSC::ARM64EAssembler::pacia1716):
1187         (JSC::ARM64EAssembler::pacib1716):
1188         (JSC::ARM64EAssembler::autia1716):
1189         (JSC::ARM64EAssembler::autib1716):
1190         (JSC::ARM64EAssembler::paciaz):
1191         (JSC::ARM64EAssembler::paciasp):
1192         (JSC::ARM64EAssembler::pacibz):
1193         (JSC::ARM64EAssembler::pacibsp):
1194         (JSC::ARM64EAssembler::autiaz):
1195         (JSC::ARM64EAssembler::autiasp):
1196         (JSC::ARM64EAssembler::autibz):
1197         (JSC::ARM64EAssembler::autibsp):
1198         (JSC::ARM64EAssembler::xpaclri):
1199         (JSC::ARM64EAssembler::pacia):
1200         (JSC::ARM64EAssembler::pacib):
1201         (JSC::ARM64EAssembler::pacda):
1202         (JSC::ARM64EAssembler::pacdb):
1203         (JSC::ARM64EAssembler::autia):
1204         (JSC::ARM64EAssembler::autib):
1205         (JSC::ARM64EAssembler::autda):
1206         (JSC::ARM64EAssembler::autdb):
1207         (JSC::ARM64EAssembler::paciza):
1208         (JSC::ARM64EAssembler::pacizb):
1209         (JSC::ARM64EAssembler::pacdza):
1210         (JSC::ARM64EAssembler::pacdzb):
1211         (JSC::ARM64EAssembler::autiza):
1212         (JSC::ARM64EAssembler::autizb):
1213         (JSC::ARM64EAssembler::autdza):
1214         (JSC::ARM64EAssembler::autdzb):
1215         (JSC::ARM64EAssembler::xpaci):
1216         (JSC::ARM64EAssembler::xpacd):
1217         (JSC::ARM64EAssembler::pacga):
1218         (JSC::ARM64EAssembler::braa):
1219         (JSC::ARM64EAssembler::brab):
1220         (JSC::ARM64EAssembler::blraa):
1221         (JSC::ARM64EAssembler::blrab):
1222         (JSC::ARM64EAssembler::braaz):
1223         (JSC::ARM64EAssembler::brabz):
1224         (JSC::ARM64EAssembler::blraaz):
1225         (JSC::ARM64EAssembler::blrabz):
1226         (JSC::ARM64EAssembler::retaa):
1227         (JSC::ARM64EAssembler::retab):
1228         (JSC::ARM64EAssembler::eretaa):
1229         (JSC::ARM64EAssembler::eretab):
1230         (JSC::ARM64EAssembler::linkPointer):
1231         (JSC::ARM64EAssembler::repatchPointer):
1232         (JSC::ARM64EAssembler::setPointer):
1233         (JSC::ARM64EAssembler::readPointer):
1234         (JSC::ARM64EAssembler::readCallTarget):
1235         (JSC::ARM64EAssembler::ret):
1236         * assembler/MacroAssembler.cpp:
1237         * assembler/MacroAssembler.h:
1238         * assembler/MacroAssemblerARM64.cpp:
1239         * assembler/MacroAssemblerARM64E.h: Added.
1240         (JSC::MacroAssemblerARM64E::tagReturnAddress):
1241         (JSC::MacroAssemblerARM64E::untagReturnAddress):
1242         (JSC::MacroAssemblerARM64E::tagPtr):
1243         (JSC::MacroAssemblerARM64E::untagPtr):
1244         (JSC::MacroAssemblerARM64E::removePtrTag):
1245         (JSC::MacroAssemblerARM64E::callTrustedPtr):
1246         (JSC::MacroAssemblerARM64E::call):
1247         (JSC::MacroAssemblerARM64E::callRegister):
1248         (JSC::MacroAssemblerARM64E::jump):
1249         * dfg/DFGOSRExit.cpp:
1250         (JSC::DFG::reifyInlinedCallFrames):
1251         * dfg/DFGOSRExitCompilerCommon.cpp:
1252         (JSC::DFG::reifyInlinedCallFrames):
1253         * ftl/FTLThunks.cpp:
1254         (JSC::FTL::genericGenerationThunkGenerator):
1255         * jit/CCallHelpers.h:
1256         (JSC::CCallHelpers::prepareForTailCallSlow):
1257         * jit/CallFrameShuffler.cpp:
1258         (JSC::CallFrameShuffler::prepareForTailCall):
1259         * jit/ExecutableAllocator.cpp:
1260         (JSC::ExecutableAllocator::allocate):
1261         * jit/ThunkGenerators.cpp:
1262         (JSC::arityFixupGenerator):
1263         * llint/LLIntOfflineAsmConfig.h:
1264         * llint/LowLevelInterpreter.asm:
1265         * llint/LowLevelInterpreter64.asm:
1266         * runtime/ClassInfo.h:
1267         * runtime/InitializeThreading.cpp:
1268         (JSC::initializeThreading):
1269         * runtime/JSCPtrTag.cpp: Added.
1270         (JSC::tagForPtr):
1271         (JSC::ptrTagName):
1272         (JSC::initializePtrTagLookup):
1273         * runtime/JSCPtrTag.h:
1274         (JSC::initializePtrTagLookup):
1275         * runtime/Options.cpp:
1276         (JSC::recomputeDependentOptions):
1277
1278 2019-03-20  Tadeu Zagallo  <tzagallo@apple.com>
1279
1280         JSC::createError needs to check for OOM in errorDescriptionForValue
1281         https://bugs.webkit.org/show_bug.cgi?id=196032
1282         <rdar://problem/46842740>
1283
1284         Reviewed by Mark Lam.
1285
1286         We were missing exceptions checks at two levels:
1287         - In errorDescriptionForValue, when the value is a string, we should
1288           check that JSString::value returns a valid string, since we might run
1289           out of memory if it is a rope and we need to resolve it.
1290         - In createError, we should check for the result of errorDescriptionForValue
1291           before concatenating it with the message provided by the caller.
1292
1293         * runtime/ExceptionHelpers.cpp:
1294         (JSC::errorDescriptionForValue):
1295         (JSC::createError):
1296         * runtime/ExceptionHelpers.h:
1297
1298 2019-03-20  Devin Rousso  <drousso@apple.com>
1299
1300         Web Inspector: DOM: include window as part of any event listener chain
1301         https://bugs.webkit.org/show_bug.cgi?id=195730
1302         <rdar://problem/48916872>
1303
1304         Reviewed by Timothy Hatcher.
1305
1306         * inspector/protocol/DOM.json:
1307         Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
1308         used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
1309         when the event listener was retrieved from the `window` object.
1310
1311 2019-03-20  Devin Rousso  <drousso@apple.com>
1312
1313         Web Inspector: Runtime: lazily create the agent
1314         https://bugs.webkit.org/show_bug.cgi?id=195972
1315         <rdar://problem/49039655>
1316
1317         Reviewed by Timothy Hatcher.
1318
1319         * inspector/JSGlobalObjectInspectorController.cpp:
1320         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1321         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1322
1323         * inspector/agents/InspectorRuntimeAgent.h:
1324         (Inspector::InspectorRuntimeAgent::enabled): Deleted.
1325         * inspector/agents/InspectorRuntimeAgent.cpp:
1326         (Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
1327         (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
1328
1329         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
1330         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
1331         (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.
1332
1333 2019-03-20  Michael Saboff  <msaboff@apple.com>
1334
1335         JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
1336         https://bugs.webkit.org/show_bug.cgi?id=195906
1337
1338         Reviewed by Mark Lam.
1339
1340         The problem here as that we may successfully parsed a RegExp without running out of stack,
1341         but later run out of stack when trying to JIT compile the same expression.
1342
1343         Added a check for available stack space when we call into one of the parenthesis compilation
1344         functions that recurse.  When we don't have enough stack space to recurse, we fail the JIT
1345         compilation and let the interpreter handle the expression.
1346
1347         From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
1348         Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
1349         Given that we can reproduce a failure, this is sufficient for now.
1350
1351         This change is covered by the previously added failing test,
1352         JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.
1353
1354         * yarr/YarrInterpreter.cpp:
1355         (JSC::Yarr::Interpreter::interpret):
1356         * yarr/YarrJIT.cpp:
1357         (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
1358         (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
1359         (JSC::Yarr::YarrGenerator::opCompileBody):
1360         (JSC::Yarr::dumpCompileFailure):
1361         * yarr/YarrJIT.h:
1362
1363 2019-03-20  Robin Morisset  <rmorisset@apple.com>
1364
1365         DFGNodeAllocator.h is dead code
1366         https://bugs.webkit.org/show_bug.cgi?id=196019
1367
1368         Reviewed by Yusuke Suzuki.
1369
1370         As explained by Yusuke on IRC, the comment on DFG::Node saying that it cannot have a destructor is obsolete since https://trac.webkit.org/changeset/216815/webkit.
1371         This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.
1372
1373         * dfg/DFGNode.h:
1374         (JSC::DFG::Node::dumpChildren):
1375         * dfg/DFGNodeAllocator.h: Removed.
1376
1377 2019-03-20  Robin Morisset  <rmorisset@apple.com>
1378
1379         Compress CodeOrigin into a single word in the common case
1380         https://bugs.webkit.org/show_bug.cgi?id=195928
1381
1382         Reviewed by Saam Barati.
1383
1384         The trick is that pointers only take 48 bits on x86_64 in practice (and we can even use the bottom three bits of that thanks to alignment), and even less on ARM64.
1385         So we can shove the bytecode index in the top bits almost all the time.
1386         If the bytecodeIndex is too ginormous (1<<16 in practice on x86_64), we just set one bit at the bottom and store a pointer to some out-of-line storage instead.
1387         Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.
1388
1389         The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.
1390
1391         End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
1392         As a reference, during running JetStream2 we allocate more than 35M CodeOrigins. While they won't all be alive at the same time, it is still quite a lot of objects, so I am hoping for some small
1393         improvement to RAMification from this work.
1394
1395         The one slightly tricky part is that we must implement copy and move assignment operators and constructors to make sure that any out-of-line storage belongs to a single CodeOrigin and is destroyed exactly once.
1396
1397         * bytecode/ByValInfo.h:
1398         * bytecode/CallLinkStatus.cpp:
1399         (JSC::CallLinkStatus::computeFor):
1400         * bytecode/CodeBlock.cpp:
1401         (JSC::CodeBlock::globalObjectFor):
1402         (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
1403         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
1404         * bytecode/CodeOrigin.cpp:
1405         (JSC::CodeOrigin::inlineDepth const):
1406         (JSC::CodeOrigin::isApproximatelyEqualTo const):
1407         (JSC::CodeOrigin::approximateHash const):
1408         (JSC::CodeOrigin::inlineStack const):
1409         (JSC::CodeOrigin::codeOriginOwner const):
1410         (JSC::CodeOrigin::stackOffset const):
1411         (JSC::CodeOrigin::dump const):
1412         (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
1413         * bytecode/CodeOrigin.h:
1414         (JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
1415         (JSC::CodeOrigin::CodeOrigin):
1416         (JSC::CodeOrigin::~CodeOrigin):
1417         (JSC::CodeOrigin::isSet const):
1418         (JSC::CodeOrigin::isHashTableDeletedValue const):
1419         (JSC::CodeOrigin::bytecodeIndex const):
1420         (JSC::CodeOrigin::inlineCallFrame const):
1421         (JSC::CodeOrigin::buildCompositeValue):
1422         (JSC::CodeOrigin::hash const):
1423         (JSC::CodeOrigin::operator== const):
1424         (JSC::CodeOrigin::exitingInlineKind const): Deleted.
1425         * bytecode/DeferredSourceDump.h:
1426         * bytecode/GetByIdStatus.cpp:
1427         (JSC::GetByIdStatus::computeForStubInfo):
1428         (JSC::GetByIdStatus::computeFor):
1429         * bytecode/ICStatusMap.cpp:
1430         (JSC::ICStatusContext::isInlined const):
1431         * bytecode/InByIdStatus.cpp:
1432         (JSC::InByIdStatus::computeFor):
1433         (JSC::InByIdStatus::computeForStubInfo):
1434         * bytecode/InlineCallFrame.cpp:
1435         (JSC::InlineCallFrame::dumpInContext const):
1436         * bytecode/InlineCallFrame.h:
1437         (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
1438         (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
1439         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
1440         (JSC::CodeOrigin::walkUpInlineStack):
1441         * bytecode/InstanceOfStatus.h:
1442         * bytecode/PutByIdStatus.cpp:
1443         (JSC::PutByIdStatus::computeForStubInfo):
1444         (JSC::PutByIdStatus::computeFor):
1445         * dfg/DFGAbstractInterpreterInlines.h:
1446         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1447         * dfg/DFGArgumentsEliminationPhase.cpp:
1448         * dfg/DFGArgumentsUtilities.cpp:
1449         (JSC::DFG::argumentsInvolveStackSlot):
1450         (JSC::DFG::emitCodeToGetArgumentsArrayLength):
1451         * dfg/DFGArrayMode.h:
1452         * dfg/DFGByteCodeParser.cpp:
1453         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
1454         (JSC::DFG::ByteCodeParser::setLocal):
1455         (JSC::DFG::ByteCodeParser::setArgument):
1456         (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
1457         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
1458         (JSC::DFG::ByteCodeParser::parseBlock):
1459         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1460         (JSC::DFG::ByteCodeParser::handlePutByVal):
1461         * dfg/DFGClobberize.h:
1462         (JSC::DFG::clobberize):
1463         * dfg/DFGConstantFoldingPhase.cpp:
1464         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1465         * dfg/DFGFixupPhase.cpp:
1466         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
1467         * dfg/DFGForAllKills.h:
1468         (JSC::DFG::forAllKilledOperands):
1469         * dfg/DFGGraph.cpp:
1470         (JSC::DFG::Graph::dumpCodeOrigin):
1471         (JSC::DFG::Graph::dump):
1472         (JSC::DFG::Graph::isLiveInBytecode):
1473         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1474         (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
1475         * dfg/DFGGraph.h:
1476         (JSC::DFG::Graph::executableFor):
1477         (JSC::DFG::Graph::isStrictModeFor):
1478         (JSC::DFG::Graph::hasExitSite):
1479         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
1480         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
1481         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
1482         * dfg/DFGMinifiedNode.cpp:
1483         (JSC::DFG::MinifiedNode::fromNode):
1484         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1485         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
1486         * dfg/DFGOSRExit.cpp:
1487         (JSC::DFG::OSRExit::executeOSRExit):
1488         (JSC::DFG::reifyInlinedCallFrames):
1489         (JSC::DFG::adjustAndJumpToTarget):
1490         (JSC::DFG::printOSRExit):
1491         (JSC::DFG::OSRExit::compileExit):
1492         * dfg/DFGOSRExitBase.cpp:
1493         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
1494         * dfg/DFGOSRExitCompilerCommon.cpp:
1495         (JSC::DFG::handleExitCounts):
1496         (JSC::DFG::reifyInlinedCallFrames):
1497         (JSC::DFG::adjustAndJumpToTarget):
1498         * dfg/DFGOSRExitPreparation.cpp:
1499         (JSC::DFG::prepareCodeOriginForOSRExit):
1500         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1501         * dfg/DFGOperations.cpp:
1502         * dfg/DFGPreciseLocalClobberize.h:
1503         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
1504         * dfg/DFGSpeculativeJIT.cpp:
1505         (JSC::DFG::SpeculativeJIT::emitGetLength):
1506         (JSC::DFG::SpeculativeJIT::emitGetCallee):
1507         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1508         (JSC::DFG::SpeculativeJIT::compileValueAdd):
1509         (JSC::DFG::SpeculativeJIT::compileValueSub):
1510         (JSC::DFG::SpeculativeJIT::compileValueNegate):
1511         (JSC::DFG::SpeculativeJIT::compileValueMul):
1512         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
1513         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
1514         * dfg/DFGSpeculativeJIT32_64.cpp:
1515         (JSC::DFG::SpeculativeJIT::emitCall):
1516         * dfg/DFGSpeculativeJIT64.cpp:
1517         (JSC::DFG::SpeculativeJIT::emitCall):
1518         (JSC::DFG::SpeculativeJIT::compile):
1519         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1520         (JSC::DFG::TierUpCheckInjectionPhase::run):
1521         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
1522         (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
1523         * dfg/DFGTypeCheckHoistingPhase.cpp:
1524         (JSC::DFG::TypeCheckHoistingPhase::run):
1525         * dfg/DFGVariableEventStream.cpp:
1526         (JSC::DFG::VariableEventStream::reconstruct const):
1527         * ftl/FTLLowerDFGToB3.cpp:
1528         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
1529         (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
1530         (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
1531         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
1532         (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
1533         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
1534         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
1535         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
1536         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
1537         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
1538         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
1539         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
1540         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
1541         (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
1542         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
1543         (JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
1544         * ftl/FTLOSRExitCompiler.cpp:
1545         (JSC::FTL::compileStub):
1546         * ftl/FTLOperations.cpp:
1547         (JSC::FTL::operationMaterializeObjectInOSR):
1548         * interpreter/CallFrame.cpp:
1549         (JSC::CallFrame::bytecodeOffset):
1550         * interpreter/StackVisitor.cpp:
1551         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
1552         (JSC::StackVisitor::readFrame):
1553         (JSC::StackVisitor::readNonInlinedFrame):
1554         (JSC::inlinedFrameOffset):
1555         (JSC::StackVisitor::readInlinedFrame):
1556         * interpreter/StackVisitor.h:
1557         * jit/AssemblyHelpers.cpp:
1558         (JSC::AssemblyHelpers::executableFor):
1559         * jit/AssemblyHelpers.h:
1560         (JSC::AssemblyHelpers::isStrictModeFor):
1561         (JSC::AssemblyHelpers::argumentsStart):
1562         (JSC::AssemblyHelpers::argumentCount):
1563         * jit/PCToCodeOriginMap.cpp:
1564         (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
1565         (JSC::PCToCodeOriginMap::findPC const):
1566         * profiler/ProfilerOriginStack.cpp:
1567         (JSC::Profiler::OriginStack::OriginStack):
1568         * profiler/ProfilerOriginStack.h:
1569         * runtime/ErrorInstance.cpp:
1570         (JSC::appendSourceToError):
1571         * runtime/SamplingProfiler.cpp:
1572         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1573
1574 2019-03-20  Devin Rousso  <drousso@apple.com>
1575
1576         Web Inspector: Search: allow DOM searches to be case sensitive
1577         https://bugs.webkit.org/show_bug.cgi?id=194673
1578         <rdar://problem/48087577>
1579
1580         Reviewed by Timothy Hatcher.
1581
1582         Since `DOM.performSearch` also searches by selector and XPath, some results may appear
1583         as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
1584         as although the literal node name ("BODY") didn't match, it did match via selector/XPath.
1585
1586         * inspector/protocol/DOM.json:
1587         Allow `DOM.performSearch` to be case sensitive.
1588
1589 2019-03-20  Saam Barati  <sbarati@apple.com>
1590
1591         AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
1592         https://bugs.webkit.org/show_bug.cgi?id=195980
1593
1594         Reviewed by Yusuke Suzuki.
1595
1596         They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
1597         However, they should have been type: (SpecInt32Only, SpecBigInt)
1598
1599         * dfg/DFGAbstractInterpreterInlines.h:
1600         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1601
1602 2019-03-20  Michael Catanzaro  <mcatanzaro@igalia.com>
1603
1604         Remove copyRef() calls added in r243163
1605         https://bugs.webkit.org/show_bug.cgi?id=195962
1606
1607         Reviewed by Chris Dumez.
1608
1609         As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
1610         value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
1611         without refcount churn by introducing an intermediate variable.
1612
1613         * inspector/scripts/codegen/cpp_generator_templates.py:
1614
1615 2019-03-20  Carlos Garcia Campos  <cgarcia@igalia.com>
1616
1617         [GLIB] Optimize jsc_value_object_define_property_data|accessor
1618         https://bugs.webkit.org/show_bug.cgi?id=195679
1619
1620         Reviewed by Saam Barati.
1621
1622         Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().
1623
1624         * API/glib/JSCValue.cpp:
1625         (jsc_value_object_define_property_data):
1626         (jsc_value_object_define_property_accessor):
1627
1628 2019-03-19  Devin Rousso  <drousso@apple.com>
1629
1630         Web Inspector: Debugger: lazily create the agent
1631         https://bugs.webkit.org/show_bug.cgi?id=195973
1632         <rdar://problem/49039674>
1633
1634         Reviewed by Joseph Pecoraro.
1635
1636         * inspector/JSGlobalObjectInspectorController.cpp:
1637         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1638         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
1639         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1640
1641         * inspector/JSGlobalObjectConsoleClient.h:
1642         (Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
1643         * inspector/JSGlobalObjectConsoleClient.cpp:
1644         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1645         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1646         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1647
1648         * inspector/agents/InspectorDebuggerAgent.h:
1649         (Inspector::InspectorDebuggerAgent::addListener): Added.
1650         (Inspector::InspectorDebuggerAgent::removeListener): Added.
1651         (Inspector::InspectorDebuggerAgent::setListener): Deleted.
1652         * inspector/agents/InspectorDebuggerAgent.cpp:
1653         (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
1654         (Inspector::InspectorDebuggerAgent::enable):
1655         (Inspector::InspectorDebuggerAgent::disable):
1656         (Inspector::InspectorDebuggerAgent::getScriptSource):
1657         (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
1658         (Inspector::InspectorDebuggerAgent::didPause):
1659         (Inspector::InspectorDebuggerAgent::breakProgram):
1660         (Inspector::InspectorDebuggerAgent::clearBreakDetails):
1661         Drive-by: reorder some member variables for better sizing.
1662         Drive-by: rename some member variables for clarity.
1663
1664 2019-03-19  Saam barati  <sbarati@apple.com>
1665
1666         Prune code after ForceOSRExit
1667         https://bugs.webkit.org/show_bug.cgi?id=195913
1668
1669         Reviewed by Keith Miller.
1670
1671         I removed our original implementation of this in r242989 because
1672         it was not sound. It broke backwards propagation because it removed
1673         uses of a node that backwards propagation relied on to be sound.
1674         Essentially, backwards propagation relies on being able to see uses
1675         that would exist in bytecode to be sound.
1676         
1677         The rollout in r242989 was a 1% Speedometer2 regression. This patch
1678         rolls back in the optimization in a sound way.
1679         
1680         This patch augments the code we had prior to r242989 to be sound. In
1681         addition to preserving liveness, we now also convert all uses after
1682         the ForceOSRExit to be Phantom. This may pessimize the optimizations
1683         we do in backwards propagation, but it will prevent that phase from
1684         making unsound optimizations.
1685
1686         * dfg/DFGByteCodeParser.cpp:
1687         (JSC::DFG::ByteCodeParser::addToGraph):
1688         (JSC::DFG::ByteCodeParser::parse):
1689
1690 2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
1691
1692         Build cleanly with GCC 9
1693         https://bugs.webkit.org/show_bug.cgi?id=195920
1694
1695         Reviewed by Chris Dumez.
1696
1697         WebKit triggers three new GCC 9 warnings:
1698
1699         """
1700         -Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
1701         declared copy constructor and assignment operator if one of them is user-provided.
1702         """
1703
1704         Solution is to either add a copy constructor or copy assignment operator, if required, or
1705         else remove one if it is redundant.
1706
1707         """
1708         -Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
1709         -Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
1710         """
1711
1712         These account for most of this patch. Solution is to just remove the bad WTFMove().
1713
1714         Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
1715         These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
1716         would be safer to not use memcpy on nontrivial types, but that's too complex for this
1717         patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)
1718
1719         * b3/B3ValueRep.h:
1720         * bindings/ScriptValue.cpp:
1721         (Inspector::jsToInspectorValue):
1722         * bytecode/GetterSetterAccessCase.cpp:
1723         (JSC::GetterSetterAccessCase::create):
1724         (JSC::GetterSetterAccessCase::clone const):
1725         * bytecode/InstanceOfAccessCase.cpp:
1726         (JSC::InstanceOfAccessCase::clone const):
1727         * bytecode/IntrinsicGetterAccessCase.cpp:
1728         (JSC::IntrinsicGetterAccessCase::clone const):
1729         * bytecode/ModuleNamespaceAccessCase.cpp:
1730         (JSC::ModuleNamespaceAccessCase::clone const):
1731         * bytecode/ProxyableAccessCase.cpp:
1732         (JSC::ProxyableAccessCase::clone const):
1733         * bytecode/StructureSet.h:
1734         * debugger/Breakpoint.h:
1735         * dfg/DFGRegisteredStructureSet.h:
1736         * inspector/agents/InspectorDebuggerAgent.cpp:
1737         (Inspector::buildDebuggerLocation):
1738         * inspector/scripts/codegen/cpp_generator_templates.py:
1739         * parser/UnlinkedSourceCode.h:
1740         * wasm/WasmAirIRGenerator.cpp:
1741         (JSC::Wasm::parseAndCompileAir):
1742         * wasm/WasmB3IRGenerator.cpp:
1743         (JSC::Wasm::parseAndCompile):
1744         * wasm/WasmNameSectionParser.cpp:
1745         (JSC::Wasm::NameSectionParser::parse):
1746         * wasm/WasmStreamingParser.cpp:
1747         (JSC::Wasm::StreamingParser::consume):
1748
1749 2019-03-19  Saam Barati  <sbarati@apple.com>
1750
1751         Style fix: remove C style cast in Instruction.h
1752         https://bugs.webkit.org/show_bug.cgi?id=195917
1753
1754         Reviewed by Filip Pizlo.
1755
1756         * bytecode/Instruction.h:
1757         (JSC::Instruction::wide const):
1758
1759 2019-03-19  Devin Rousso  <drousso@apple.com>
1760
1761         Web Inspector: Provide $event in the console when paused on an event listener
1762         https://bugs.webkit.org/show_bug.cgi?id=188672
1763
1764         Reviewed by Timothy Hatcher.
1765
1766         * inspector/InjectedScript.h:
1767         * inspector/InjectedScript.cpp:
1768         (Inspector::InjectedScript::setEventValue): Added.
1769         (Inspector::InjectedScript::clearEventValue): Added.
1770
1771         * inspector/InjectedScriptManager.h:
1772         * inspector/InjectedScriptManager.cpp:
1773         (Inspector::InjectedScriptManager::clearEventValue): Added.
1774
1775         * inspector/InjectedScriptSource.js:
1776         (WI.InjectedScript.prototype.setEventValue): Added.
1777         (WI.InjectedScript.prototype.clearEventValue): Added.
1778         (BasicCommandLineAPI):
1779
1780 2019-03-19  Devin Rousso  <drousso@apple.com>
1781
1782         Web Inspector: ScriptProfiler: lazily create the agent
1783         https://bugs.webkit.org/show_bug.cgi?id=195591
1784         <rdar://problem/48791756>
1785
1786         Reviewed by Joseph Pecoraro.
1787
1788         * inspector/JSGlobalObjectConsoleClient.h:
1789         (Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
1790         * inspector/JSGlobalObjectConsoleClient.cpp:
1791         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1792         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1793         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1794
1795         * inspector/JSGlobalObjectInspectorController.cpp:
1796         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1797         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1798
1799 2019-03-19  Devin Rousso  <drousso@apple.com>
1800
1801         Web Inspector: Heap: lazily create the agent
1802         https://bugs.webkit.org/show_bug.cgi?id=195590
1803         <rdar://problem/48791750>
1804
1805         Reviewed by Joseph Pecoraro.
1806
1807         * inspector/agents/InspectorHeapAgent.h:
1808         * inspector/agents/InspectorHeapAgent.cpp:
1809         (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
1810
1811         * inspector/agents/InspectorConsoleAgent.h:
1812         (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
1813         * inspector/agents/InspectorConsoleAgent.cpp:
1814         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
1815         (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
1816         (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
1817
1818         * inspector/JSGlobalObjectInspectorController.cpp:
1819         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1820         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1821
1822 2019-03-19  Caio Lima  <ticaiolima@gmail.com>
1823
1824         [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
1825         https://bugs.webkit.org/show_bug.cgi?id=194648
1826
1827         Reviewed by Keith Miller.
1828
1829         1. Making LLIntThunks singleton. 
1830
1831         Motivation: Former implementation has one LLIntThunk per type per VM.
1832         However, the generated code for every kind of thunk is essentially the
1833         same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
1834         when we have 2 or more VM instantiated. Turn these thunks into
1835         singleton will avoid such wasting.
1836
1837         Tradeoff: This change comes with a price, because we will keep thunks
1838         allocated even when there is no VM instantiated. Considering WebCore use case,
1839         the situation of having no VM instantiated is uncommon, since once a
1840         VM is created through `commomVM()`, it will never be destroyed. Given
1841         that, this change does not impact the overall memory comsumption of
1842         WebCore/JSC. It also doesn't impact memory footprint, since thunks are
1843         generated lazily (see results below).
1844
1845         Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
1846         we have the assurance that JITed code will never be deallocated,
1847         given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
1848         To understand why we decided to make LLIntThunks singleton instead of
1849         removing them, please see the comment on `llint/LLIntThunks.cpp`.
1850
1851         2. Making all LLIntEntrypoints singleton
1852
1853         Motivation: With singleton LLIntThunks, we also can have singleton
1854         DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
1855         avoid multiple allocations of objects with the same content.
1856
1857         Tradeoff: As explained before, once we allocate an entrypoint, it
1858         will be alive until the program exits. However, the gains we can
1859         achieve in some use cases justifies such allocations.
1860
1861         As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
1862         `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
1863         will never be less than 1.
1864
1865         3. Memory usage analysis
1866
1867         This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
1868         by 2% and is neutral on JetStream 2. Following results were generated
1869         running each benchmark 6 times and using 95% Student's t distribution
1870         confidence interval.
1871
1872         microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
1873             Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
1874             Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
1875
1876         JetStream2 (Neutral):
1877             Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
1878             Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
1879
1880         4. Performance Analysis
1881
1882         This change is performance neutral on JetStream 2 and Speedometer 2.
1883         See results below.:
1884
1885         JetStream 2 (Neutral):
1886             Mean of score on ToT: 139.58 (confidence interval: 2.44)
1887             Mean of score on Changes: 141.46 (confidence interval: 4.24)
1888
1889         Speedometer run #1
1890            ToT: 110 +- 2.9
1891            Changes: 110 +- 1.8
1892
1893         Speedometer run #2
1894            ToT: 110 +- 1.6
1895            Changes: 108 +- 2.3
1896
1897         Speedometer run #3
1898            ToT: 110 +- 3.0
1899            Changes: 110 +- 1.4
1900
1901         * jit/JSInterfaceJIT.h:
1902         (JSC::JSInterfaceJIT::JSInterfaceJIT):
1903         * llint/LLIntEntrypoint.cpp:
1904
1905         Here we are changing the usage or DirectJITCode by NativeJITCode on cases
1906         where there is no difference from address of calls with and without
1907         ArithCheck.
1908
1909         (JSC::LLInt::setFunctionEntrypoint):
1910         (JSC::LLInt::setEvalEntrypoint):
1911         (JSC::LLInt::setProgramEntrypoint):
1912         (JSC::LLInt::setModuleProgramEntrypoint):
1913         (JSC::LLInt::setEntrypoint):
1914         * llint/LLIntEntrypoint.h:
1915         * llint/LLIntThunks.cpp:
1916         (JSC::LLInt::generateThunkWithJumpTo):
1917         (JSC::LLInt::functionForCallEntryThunk):
1918         (JSC::LLInt::functionForConstructEntryThunk):
1919         (JSC::LLInt::functionForCallArityCheckThunk):
1920         (JSC::LLInt::functionForConstructArityCheckThunk):
1921         (JSC::LLInt::evalEntryThunk):
1922         (JSC::LLInt::programEntryThunk):
1923         (JSC::LLInt::moduleProgramEntryThunk):
1924         (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
1925         (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
1926         (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
1927         (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
1928         (JSC::LLInt::evalEntryThunkGenerator): Deleted.
1929         (JSC::LLInt::programEntryThunkGenerator): Deleted.
1930         (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
1931         * llint/LLIntThunks.h:
1932         * runtime/ScriptExecutable.cpp:
1933         (JSC::setupLLInt):
1934         (JSC::ScriptExecutable::prepareForExecutionImpl):
1935
1936 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
1937
1938         [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
1939         https://bugs.webkit.org/show_bug.cgi?id=195927
1940
1941         Reviewed by Mark Lam.
1942
1943         r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
1944         This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
1945
1946         * runtime/RegExpConstructor.cpp:
1947         (JSC::setRegExpConstructorInput):
1948         (JSC::setRegExpConstructorMultiline):
1949         * runtime/RegExpGlobalData.cpp:
1950         (JSC::RegExpGlobalData::getBackref):
1951         (JSC::RegExpGlobalData::getLastParen):
1952
1953 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
1954
1955         [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
1956         https://bugs.webkit.org/show_bug.cgi?id=195901
1957
1958         Reviewed by Saam Barati.
1959
1960         It is not rare that generators do not need to have any registers to be suspended and resumed.
1961         Since currently we always emit op_create_lexical_environment for generator code, we sometimes
1962         create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
1963         are allocated in RAMification's Basic test.
1964
1965         This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
1966         a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
1967         based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
1968
1969         We run RAMification in 6 times, use average of them.
1970         RAMification's Basic in JIT mode shows 1.4% improvement.
1971         ToT
1972             Current: 55076864.00, Peak: 55080960.00
1973         Patched
1974             Current: 54325930.67, Peak: 54329344.00
1975
1976         RAMification's Basic in non-JIT mode shows 5.0% improvement.
1977         ToT
1978             Current: 12485290.67, Peak: 12485290.67
1979         Patched
1980             Current: 11894101.33, Peak: 11894101.33
1981
1982         * bytecode/BytecodeGeneratorification.cpp:
1983         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
1984         (JSC::BytecodeGeneratorification::generatorFrameData const):
1985         (JSC::BytecodeGeneratorification::run):
1986         * bytecode/BytecodeList.rb:
1987         * bytecode/BytecodeUseDef.h:
1988         (JSC::computeUsesForBytecodeOffset):
1989         (JSC::computeDefsForBytecodeOffset):
1990         * bytecompiler/BytecodeGenerator.cpp:
1991         (JSC::BytecodeGenerator::BytecodeGenerator):
1992         * dfg/DFGCapabilities.cpp:
1993         (JSC::DFG::capabilityLevel):
1994         * llint/LowLevelInterpreter.asm:
1995
1996 2019-03-18  Robin Morisset  <rmorisset@apple.com>
1997
1998         Remove the inline capacity of Operands
1999         https://bugs.webkit.org/show_bug.cgi?id=195898
2000
2001         Reviewed by Yusuke Suzuki.
2002
2003         Operands currently has a vector with an inline capacity of 24.
2004         I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
2005         This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
2006         Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
2007         
2008         So I removed the inline capacity of the vector in Operands, and here are the results:
2009         Baseline Jetstream2:
2010         159.741
2011         159.746
2012         159.989
2013         Baseline RAMification on grouped and jit tests: (end/peak/score)
2014         89.288/89.763/89.526
2015         90.166/90.761/90.418
2016         89.560/90.014/89.787
2017         After optimization Jetstream2:
2018         159.342
2019         161.812
2020         162.037
2021         After optimization RAMification:
2022         89.147/89.644/89.395
2023         89.102.89.585/89.343
2024         88.953/89.536/89.2444
2025         
2026         So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
2027         I hope to land this, and get more accurate results from the bots.
2028
2029         * bytecode/Operands.h:
2030
2031 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
2032
2033         [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
2034         https://bugs.webkit.org/show_bug.cgi?id=195897
2035
2036         Reviewed by Keith Miller.
2037
2038         It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
2039         I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
2040         This patch adds,
2041
2042         1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
2043         2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
2044
2045         While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
2046         we would like to collect heap statistics and dump them to investigate Heap status more.
2047
2048         This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
2049
2050         * heap/Heap.cpp:
2051         (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
2052         (JSC::Heap::lastChanceToFinalize):
2053         * heap/Heap.h:
2054         * jsc.cpp:
2055         (printUsageStatement):
2056         (CommandLine::parseArguments):
2057         (runJSC):
2058         * runtime/Options.h:
2059
2060 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
2061
2062         [JSC] jsSubstring should resolve rope before calling JSRopeString::create
2063         https://bugs.webkit.org/show_bug.cgi?id=195840
2064
2065         Reviewed by Geoffrey Garen.
2066
2067         jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
2068         as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
2069         So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
2070         of single character substrings.
2071
2072         We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
2073         strings to save memory.
2074
2075         This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
2076
2077         * dfg/DFGOperations.cpp:
2078         * runtime/JSString.cpp:
2079         (JSC::JSString::dumpToStream):
2080         * runtime/JSString.h:
2081         (JSC::jsSubstring):
2082         (JSC::jsSubstringOfResolved):
2083         (JSC::jsSingleCharacterString):
2084         * runtime/RegExpCachedResult.cpp:
2085         (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
2086         (JSC::RegExpCachedResult::leftContext):
2087         (JSC::RegExpCachedResult::rightContext):
2088         (JSC::RegExpCachedResult::setInput):
2089         * runtime/RegExpGlobalData.cpp:
2090         (JSC::RegExpGlobalData::getBackref):
2091         (JSC::RegExpGlobalData::getLastParen):
2092         * runtime/StringObject.h:
2093         (JSC::jsStringWithReuse):
2094         (JSC::jsSubstring):
2095         * runtime/StringPrototype.cpp:
2096         (JSC::replaceUsingRegExpSearch):
2097         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2098         (JSC::replaceUsingStringSearch):
2099         (JSC::stringProtoFuncSlice):
2100         (JSC::splitStringByOneCharacterImpl):
2101         (JSC::stringProtoFuncSplitFast):
2102         (JSC::stringProtoFuncSubstr):
2103         (JSC::stringProtoFuncSubstring):
2104         (JSC::stringProtoFuncToLowerCase):
2105         (JSC::stringProtoFuncToUpperCase):
2106         Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
2107
2108         * runtime/StringPrototypeInlines.h:
2109         (JSC::stringSlice):
2110
2111 2019-03-18  Mark Lam  <mark.lam@apple.com>
2112
2113         Missing a ThrowScope release in JSObject::toString().
2114         https://bugs.webkit.org/show_bug.cgi?id=195893
2115         <rdar://problem/48970986>
2116
2117         Reviewed by Michael Saboff.
2118
2119         Placate the validator with a RELEASE_AND_RETURN().
2120
2121         * runtime/JSObject.cpp:
2122         (JSC::JSObject::toString const):
2123
2124 2019-03-18  Mark Lam  <mark.lam@apple.com>
2125
2126         Structure::flattenDictionary() should clear unused property slots.
2127         https://bugs.webkit.org/show_bug.cgi?id=195871
2128         <rdar://problem/48959497>
2129
2130         Reviewed by Michael Saboff.
2131
2132         It currently attempts to do this but fails because it's actually clearing up the
2133         preCapacity region instead.  The fix is simply to account for the preCapacity
2134         when computing the start address of the property slots.
2135
2136         * runtime/Structure.cpp:
2137         (JSC::Structure::flattenDictionaryStructure):
2138
2139 2019-03-18  Robin Morisset  <rmorisset@apple.com>
2140
2141         B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
2142         https://bugs.webkit.org/show_bug.cgi?id=152164
2143
2144         Reviewed by Filip Pizlo.
2145
2146         Turn this: Shl(<S|Z>Shr(@x, @const), @const)
2147         Into this: BitAnd(@x, -(1<<@const))
2148
2149         I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
2150         I also modified a few adjacent tests to remove undefined behaviours.
2151
2152         * b3/B3ReduceStrength.cpp:
2153         * b3/testb3.cpp:
2154         (JSC::B3::testShlImms):
2155         (JSC::B3::testShlArgImm):
2156         (JSC::B3::testShlSShrArgImm):
2157         (JSC::B3::testShlImms32):
2158         (JSC::B3::testShlArgImm32):
2159         (JSC::B3::testShlZShrArgImm32):
2160         (JSC::B3::run):
2161
2162 2019-03-17  Robin Morisset  <rmorisset@apple.com>
2163
2164         ParserError can be shrunk by 8 bytes
2165         https://bugs.webkit.org/show_bug.cgi?id=195496
2166
2167         Reviewed by Mark Lam.
2168
2169         * parser/ParserError.h:
2170
2171 2019-03-17  Diego Pino Garcia  <dpino@igalia.com>
2172
2173         Fix WPE and GTK Debug builds after r243049
2174         https://bugs.webkit.org/show_bug.cgi?id=195860
2175
2176         Unreviewed, build fix after r243049.
2177
2178         * runtime/StringPrototype.cpp:
2179         (JSC::normalizationAffects8Bit):
2180
2181 2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>
2182
2183         REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
2184         https://bugs.webkit.org/show_bug.cgi?id=195858
2185
2186         Reviewed by Mark Lam.
2187
2188         r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
2189         the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
2190         This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
2191         other places to fix the same problem. This bug is caught by existing debug tests for wasm.
2192
2193         * runtime/JSGlobalObject.h:
2194         * wasm/js/JSWebAssemblyCompileError.cpp:
2195         (JSC::createJSWebAssemblyCompileError):
2196         * wasm/js/JSWebAssemblyInstance.cpp:
2197         (JSC::JSWebAssemblyInstance::finalizeCreation):
2198         (JSC::JSWebAssemblyInstance::create):
2199         * wasm/js/JSWebAssemblyLinkError.cpp:
2200         (JSC::createJSWebAssemblyLinkError):
2201         * wasm/js/JSWebAssemblyModule.cpp:
2202         (JSC::JSWebAssemblyModule::createStub):
2203         (JSC::JSWebAssemblyModule::finishCreation):
2204         * wasm/js/WasmToJS.cpp:
2205         (JSC::Wasm::wasmToJSException):
2206         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2207         (JSC::constructJSWebAssemblyCompileError):
2208         (JSC::callJSWebAssemblyCompileError):
2209         * wasm/js/WebAssemblyFunction.cpp:
2210         (JSC::WebAssemblyFunction::create):
2211         * wasm/js/WebAssemblyFunction.h:
2212         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2213         (JSC::constructJSWebAssemblyInstance):
2214         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2215         (JSC::constructJSWebAssemblyLinkError):
2216         (JSC::callJSWebAssemblyLinkError):
2217         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2218         (JSC::constructJSWebAssemblyMemory):
2219         * wasm/js/WebAssemblyModuleConstructor.cpp:
2220         (JSC::WebAssemblyModuleConstructor::createModule):
2221         * wasm/js/WebAssemblyModuleRecord.cpp:
2222         (JSC::WebAssemblyModuleRecord::link):
2223         (JSC::WebAssemblyModuleRecord::evaluate):
2224         * wasm/js/WebAssemblyPrototype.cpp:
2225         (JSC::webAssemblyModuleValidateAsyncInternal):
2226         (JSC::instantiate):
2227         (JSC::compileAndInstantiate):
2228         (JSC::webAssemblyModuleInstantinateAsyncInternal):
2229         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2230         (JSC::constructJSWebAssemblyRuntimeError):
2231         (JSC::callJSWebAssemblyRuntimeError):
2232         * wasm/js/WebAssemblyTableConstructor.cpp:
2233         (JSC::constructJSWebAssemblyTable):
2234         * wasm/js/WebAssemblyToJSCallee.cpp:
2235         (JSC::WebAssemblyToJSCallee::create):
2236         * wasm/js/WebAssemblyToJSCallee.h:
2237         * wasm/js/WebAssemblyWrapperFunction.cpp:
2238         (JSC::WebAssemblyWrapperFunction::create):
2239         * wasm/js/WebAssemblyWrapperFunction.h:
2240
2241 2019-03-16  Darin Adler  <darin@apple.com>
2242
2243         Improve normalization code, including moving from unorm.h to unorm2.h
2244         https://bugs.webkit.org/show_bug.cgi?id=195330
2245
2246         Reviewed by Michael Catanzaro.
2247
2248         * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
2249
2250         * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
2251         (JSC::normalizer): Added. Function to create normalizer object given
2252         enumeration value indicating which is selected. Simplified because we
2253         know the function will not fail and so we don't need error handling code.
2254         (JSC::normalize): Changed this function to take a JSString* so we can
2255         optimize the case where no normalization is needed. Added an early exit
2256         if the string is stored as 8-bit and another if the string is already
2257         normalized, using unorm2_isNormalized. Changed error handling to only
2258         check cases that can actually fail in practice. Also did other small
2259         optimizations like passing VM rather than ExecState.
2260         (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
2261         identical to the names used in the API and normalization parlance rather
2262         than longer ones that expand the acronyms. Updated to pass JSString* to
2263         the normalize function, so we can optimize 8-bit and already-normalized
2264         cases, rather than callling the expensive String::upconvertedCharacters
2265         function. Use throwVMRangeError.
2266
2267 2019-03-15  Mark Lam  <mark.lam@apple.com>
2268
2269         Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
2270         https://bugs.webkit.org/show_bug.cgi?id=195827
2271         <rdar://problem/48845513>
2272
2273         Reviewed by Filip Pizlo.
2274
2275         m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
2276
2277         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
2278         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
2279         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2280         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2281         * bytecode/ObjectPropertyCondition.cpp:
2282         (JSC::ObjectPropertyCondition::dumpInContext const):
2283         * bytecode/StructureStubClearingWatchpoint.cpp:
2284         (JSC::StructureStubClearingWatchpoint::fireInternal):
2285         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
2286         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
2287         * runtime/StructureRareData.cpp:
2288         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2289
2290 2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>
2291
2292         [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
2293         https://bugs.webkit.org/show_bug.cgi?id=195816
2294
2295         Reviewed by Michael Saboff.
2296
2297         This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
2298
2299         1. iteratorResultObjectStructure
2300         2. WebAssembly related objects except for JSWebAssembly top-level object.
2301
2302         * CMakeLists.txt:
2303         * DerivedSources-input.xcfilelist:
2304         * DerivedSources-output.xcfilelist:
2305         * DerivedSources.make:
2306         * runtime/JSGlobalObject.cpp:
2307         (JSC::JSGlobalObject::init):
2308         (JSC::JSGlobalObject::visitChildren):
2309         * runtime/JSGlobalObject.h:
2310         (JSC::JSGlobalObject::iteratorResultObjectStructure const):
2311         (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
2312         (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
2313         (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
2314         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
2315         * wasm/js/JSWebAssembly.cpp:
2316         * wasm/js/JSWebAssembly.h:
2317
2318 2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>
2319
2320         [CMake] Move test .js files into testapiScripts
2321         https://bugs.webkit.org/show_bug.cgi?id=195565
2322
2323         Reviewed by Yusuke Suzuki.
2324
2325         testapi expect .js file in the testapiScripts-directory.
2326
2327         * shell/CMakeLists.txt:
2328
2329 2019-03-15  Mark Lam  <mark.lam@apple.com>
2330
2331         Gardening: add a missing exception check after r242991.
2332         https://bugs.webkit.org/show_bug.cgi?id=195791
2333
2334         Unreviewed.
2335
2336         * tools/JSDollarVM.cpp:
2337         (JSC::functionGetGetterSetter):
2338
2339 2019-03-15  Devin Rousso  <drousso@apple.com>
2340
2341         Web Inspector: provide a way to capture a screenshot of a node from within the page
2342         https://bugs.webkit.org/show_bug.cgi?id=194279
2343         <rdar://problem/10731573>
2344
2345         Reviewed by Joseph Pecoraro.
2346
2347         Add `console.screenshot` functionality, which displays a screenshot of a given object (if
2348         able) within Web Inspector's Console tab. From there, it can be viewed and saved.
2349
2350         Currently, `console.screenshot` will
2351          - capture an image of a `Node` (if provided)
2352          - capture an image of the viewport if nothing is provided
2353
2354         * inspector/protocol/Console.json:
2355         Add `Image` enum value to `ConsoleMessage` type.
2356         * runtime/ConsoleTypes.h:
2357         * inspector/ConsoleMessage.h:
2358         * inspector/ConsoleMessage.cpp:
2359         (Inspector::messageTypeValue):
2360
2361         * runtime/ConsoleClient.h:
2362         * runtime/ConsoleObject.cpp:
2363         (JSC::ConsoleObject::finishCreation):
2364         (JSC::consoleProtoFuncScreenshot): Added.
2365
2366         * inspector/JSGlobalObjectConsoleClient.h:
2367         * inspector/JSGlobalObjectConsoleClient.cpp:
2368         (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
2369
2370 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
2371
2372         [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
2373         https://bugs.webkit.org/show_bug.cgi?id=195791
2374         <rdar://problem/48806130>
2375
2376         Reviewed by Mark Lam.
2377
2378         Consider the following example:
2379
2380             void putByVal(JSObject*, PropertyName propertyName, ...);
2381
2382             putByVal(object, symbol->privateName(), ...);
2383
2384         PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
2385         It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
2386         and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
2387         incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
2388         PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
2389         before passing it to operations which takes it as PropertyName.
2390
2391         1. We use the code pattern like this.
2392
2393             auto propertyName = symbol->privateName();
2394             someOperation(..., propertyName);
2395
2396         This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
2397
2398             auto propertyName = value.toPropertyKey(exec);
2399             RETURN_IF_EXCEPTION(scope, { });
2400             someOperation(..., propertyName);
2401
2402         2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
2403            potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
2404            and they typically need to retain PrivateName.
2405
2406         3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
2407            BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
2408            of `const Identifier&`.
2409
2410         Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
2411         the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
2412
2413         * dfg/DFGOperations.cpp:
2414         * jit/JITOperations.cpp:
2415         (JSC::tryGetByValOptimize):
2416         * runtime/JSFunction.cpp:
2417         (JSC::JSFunction::setFunctionName):
2418         * runtime/JSModuleLoader.cpp:
2419         (JSC::printableModuleKey):
2420         * runtime/JSONObject.cpp:
2421         (JSC::Stringifier::Stringifier):
2422         * runtime/Symbol.cpp:
2423         (JSC::Symbol::descriptiveString const):
2424         (JSC::Symbol::description const):
2425         * runtime/Symbol.h:
2426         * runtime/SymbolConstructor.cpp:
2427         (JSC::symbolConstructorKeyFor):
2428         * tools/JSDollarVM.cpp:
2429         (JSC::functionGetGetterSetter):
2430
2431 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
2432
2433         REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
2434         https://bugs.webkit.org/show_bug.cgi?id=195752
2435
2436         Reviewed by Saam Barati.
2437
2438         We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
2439         was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
2440         falls into wrong condition), our validation does not care AnyInt and Double representations in lower
2441         tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
2442         SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
2443         OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
2444         before entering DFG code.
2445
2446         This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
2447
2448         And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
2449         in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
2450         value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
2451         is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
2452
2453         We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
2454         AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
2455         is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
2456         and it accepts JSValues simply.
2457
2458         * bytecode/SpeculatedType.cpp:
2459         (JSC::dumpSpeculation):
2460         * dfg/DFGAbstractValue.cpp:
2461         (JSC::DFG::AbstractValue::filterValueByType):
2462         * dfg/DFGAbstractValue.h:
2463         (JSC::DFG::AbstractValue::validateOSREntryValue const):
2464         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
2465         (JSC::DFG::AbstractValue::validate const): Deleted.
2466         (JSC::DFG::AbstractValue::validateType const): Deleted.
2467         * dfg/DFGCFAPhase.cpp:
2468         (JSC::DFG::CFAPhase::run):
2469         (JSC::DFG::CFAPhase::injectOSR):
2470         (JSC::DFG::CFAPhase::performBlockCFA):
2471         * dfg/DFGOSREntry.cpp:
2472         (JSC::DFG::prepareOSREntry):
2473
2474 2019-03-14  Saam barati  <sbarati@apple.com>
2475
2476         We can't remove code after ForceOSRExit until after FixupPhase
2477         https://bugs.webkit.org/show_bug.cgi?id=186916
2478         <rdar://problem/41396612>
2479
2480         Reviewed by Yusuke Suzuki.
2481
2482         There was an optimization in the bytecode parser I added in r232742 that converted blocks
2483         with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
2484         this is incorrect because it breaks backwards propagation. For example, it
2485         could incorrectly lead us to think it's safe to not check for overflow in
2486         an Add because such Add has no non-int uses. Backwards propagation relies on
2487         having a view over bytecode uses, and this optimization broke that. This patch
2488         rolls out that optimization, as initial perf data shows it may no longer be
2489         needed.
2490
2491         * dfg/DFGByteCodeParser.cpp:
2492         (JSC::DFG::ByteCodeParser::addToGraph):
2493         (JSC::DFG::ByteCodeParser::parse):
2494
2495 2019-03-14  Saam barati  <sbarati@apple.com>
2496
2497         JSScript should have an accessor saying if it's cached or not
2498         https://bugs.webkit.org/show_bug.cgi?id=195783
2499
2500         Reviewed by Michael Saboff.
2501
2502         * API/JSScript.h:
2503         * API/JSScript.mm:
2504         (-[JSScript isUsingBytecodeCache]):
2505         * API/tests/testapi.mm:
2506         (testIsUsingBytecodeCacheAccessor):
2507         (testObjectiveCAPI):
2508
2509 2019-03-14  Saam barati  <sbarati@apple.com>
2510
2511         Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
2512         https://bugs.webkit.org/show_bug.cgi?id=195782
2513         <rdar://problem/48880625>
2514
2515         Reviewed by Michael Saboff.
2516
2517         This patch fixes two issues with JSScript API:
2518         
2519         1. There was a retain cycle causing us to never destroy a JSScript once it
2520         created a JSSourceCode. The reason for this is that JSScript had a 
2521         Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
2522         
2523         This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
2524         
2525         2. r242585 made it so that JSScript would keep the cache file descriptor open
2526         (and locked) for the duration of the lifetime of the JSScript itself. Our
2527         anticipation here is that it would make implementing iterative cache updates
2528         easier. However, this made using the API super limiting in other ways. For
2529         example, if a program had a loop that cached 3000 different JSScripts, it's
2530         likely that such a program would exhaust the open file count limit. This patch
2531         reverts to the behavior prior to r242585 where we just keep open the file descriptor
2532         while we read or write it.
2533
2534         * API/JSAPIGlobalObject.mm:
2535         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
2536         * API/JSContext.mm:
2537         (-[JSContext evaluateJSScript:]):
2538         * API/JSScript.mm:
2539         (-[JSScript dealloc]):
2540         (-[JSScript readCache]):
2541         (-[JSScript init]):
2542         (-[JSScript sourceCode]):
2543         (-[JSScript jsSourceCode]):
2544         (-[JSScript writeCache:]):
2545         (-[JSScript forceRecreateJSSourceCode]): Deleted.
2546         * API/JSScriptInternal.h:
2547         * API/tests/testapi.mm:
2548         (testCanCacheManyFilesWithTheSameVM):
2549         (testObjectiveCAPI):
2550         (testCacheFileIsExclusive): Deleted.
2551
2552 2019-03-14  Michael Saboff  <msaboff@apple.com>
2553
2554         ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
2555         https://bugs.webkit.org/show_bug.cgi?id=195735
2556
2557         Reviewed by Mark Lam.
2558
2559         There are two bug fixes here.
2560
2561         The first bug happens due to a race condition when we are compiling on a separate thread while the
2562         main thread is compiling the RegExp at a place where it can run out of stack.  When that happens,
2563         the RegExp becomes invalid due to the out of stack error.  If we check the ASSERT condition in the DFG
2564         compilation thread, we crash.  After the main thread throws an exception, it resets the RegExp as
2565         it might compile successfully the next time we try to execute it on a shallower stack.
2566         The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
2567         or any slow path we call out to.  Therefore ASSERTs like this in compilation code can be eliminated.
2568
2569         The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
2570         The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
2571         is != NotCompiled.  We also can't run the RegExp if there the state is ParseError.
2572         Changing hasCode() to take this into account fixes the second issue.
2573
2574         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
2575         * runtime/RegExp.h:
2576         * dfg/DFGSpeculativeJIT.cpp:
2577         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
2578         * runtime/RegExp.h:
2579
2580 2019-03-14  Saam barati  <sbarati@apple.com>
2581
2582         Fixup uses KnownInt32 incorrectly in some nodes
2583         https://bugs.webkit.org/show_bug.cgi?id=195279
2584         <rdar://problem/47915654>
2585
2586         Reviewed by Yusuke Suzuki.
2587
2588         Fixup was sometimes using KnownInt32 edges when it knew some
2589         incoming value is an Int32 based on what the bytecode would return.
2590         However, because bytecode may result in Int32 for some node does
2591         not mean we'll pick Int32 as the value format for that local. For example,
2592         we may choose for a value to be represented as a double. This patch
2593         corrects such uses of KnownInt32.
2594
2595         * dfg/DFGArgumentsEliminationPhase.cpp:
2596         * dfg/DFGFixupPhase.cpp:
2597         (JSC::DFG::FixupPhase::fixupNode):
2598         * dfg/DFGSpeculativeJIT.cpp:
2599         (JSC::DFG::SpeculativeJIT::compileArrayPush):
2600         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
2601         * ftl/FTLLowerDFGToB3.cpp:
2602         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
2603
2604 2019-03-14  Keith Miller  <keith_miller@apple.com>
2605
2606         DFG liveness can't skip tail caller inline frames
2607         https://bugs.webkit.org/show_bug.cgi?id=195715
2608         <rdar://problem/46221598>
2609
2610         Reviewed by Saam Barati.
2611
2612         In order to simplify OSR exit/DFG bytecode parsing our bytecode
2613         generator always emits an op_ret after any tail call. However, the
2614         DFG when computing the liveness of locals, would skip any tail
2615         caller inline frames. This mean that if we ended up inserting a
2616         Check that would OSR to the op_ret we wouldn't have kept
2617         availability data around for it.
2618
2619         * dfg/DFGGraph.cpp:
2620         (JSC::DFG::Graph::isLiveInBytecode):
2621         * dfg/DFGGraph.h:
2622         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2623
2624 2019-03-14  Robin Morisset  <rmorisset@apple.com>
2625
2626         DFG::Worklist can be shrunk by 16 bytes
2627         https://bugs.webkit.org/show_bug.cgi?id=195490
2628
2629         Reviewed by Darin Adler.
2630
2631         * dfg/DFGWorklist.cpp:
2632         (JSC::DFG::Worklist::Worklist):
2633         * dfg/DFGWorklist.h:
2634
2635 2019-03-14  Devin Rousso  <drousso@apple.com>
2636
2637         Web Inspector: Audit: provide a way to get the contents of resources
2638         https://bugs.webkit.org/show_bug.cgi?id=195266
2639         <rdar://problem/48550911>
2640
2641         Reviewed by Joseph Pecoraro.
2642
2643         * inspector/InjectedScriptBase.cpp:
2644         (Inspector::InjectedScriptBase::makeAsyncCall):
2645         Drive-by: fix missing `else`.
2646
2647 2019-03-14  Devin Rousso  <drousso@apple.com>
2648
2649         Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
2650         https://bugs.webkit.org/show_bug.cgi?id=195123
2651         <rdar://problem/48450148>
2652
2653         Reviewed by Joseph Pecoraro.
2654
2655         * inspector/protocol/CSS.json:
2656         Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
2657         which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).
2658
2659 2019-03-13  Caio Lima  <ticaiolima@gmail.com>
2660
2661         [JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
2662         https://bugs.webkit.org/show_bug.cgi?id=195638
2663
2664         Reviewed by Mark Lam.
2665
2666         This patch introduces a m_isShared flag to track whether the
2667         JITCode is shared between many CodeBlocks. This flag is used in
2668         `CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
2669         reporting duplicated extra memory for singleton JITCodes.
2670         With those changes, we now stop counting singleton LLIntEntrypoints
2671         as extra memory, since they are declared as static variables. This
2672         change can potentially avoid unecessary GC pressure, because
2673         extra memory is used by Heap::updateAllocationLimits() to update Heap
2674         limits.
2675         Even though it is hard to show performance difference for this change
2676         (see results below), it is important to keep extra memory usage
2677         correct. Otherwise, it can be a source of a complicated bug on
2678         GC in the future.
2679
2680         Results from last run of Speedometer 2 comparing ToT and changes. We
2681         collected those numbers running Minibrowser on a MacBook Pro 15-inch
2682         with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
2683         since these singleton JITCode are only used by this configuration:
2684
2685         Speedometer2 Run #1
2686             ToT: 58.2 +- 1.1
2687             changes: 57.9 +- 0.99
2688
2689         Speedometer2 Run #2
2690             ToT: 58.5 +- 1.7
2691             changes: 58.0 +- 1.5
2692
2693         Speedometer2 Run #2
2694             ToT: 58.5 +- 0.99
2695             changes: 57.1 +- 1.5
2696
2697         * bytecode/CodeBlock.cpp:
2698         (JSC::CodeBlock::estimatedSize):
2699         (JSC::CodeBlock::visitChildren):
2700         * bytecode/CodeBlock.h:
2701         (JSC::CodeBlock::setJITCode):
2702         * jit/JITCode.cpp:
2703         (JSC::JITCode::JITCode):
2704         (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
2705         (JSC::DirectJITCode::DirectJITCode):
2706         (JSC::NativeJITCode::NativeJITCode):
2707         * jit/JITCode.h:
2708         (JSC::JITCode::isShared const):
2709         * llint/LLIntEntrypoint.cpp:
2710         (JSC::LLInt::setFunctionEntrypoint):
2711         (JSC::LLInt::setEvalEntrypoint):
2712         (JSC::LLInt::setProgramEntrypoint):
2713         (JSC::LLInt::setModuleProgramEntrypoint):
2714
2715 2019-03-13  Keith Rollin  <krollin@apple.com>
2716
2717         Add support for new StagedFrameworks layout
2718         https://bugs.webkit.org/show_bug.cgi?id=195543
2719
2720         Reviewed by Alexey Proskuryakov.
2721
2722         When creating the WebKit layout for out-of-band Safari/WebKit updates,
2723         use an optional path prefix when called for.
2724
2725         * Configurations/Base.xcconfig:
2726
2727 2019-03-13  Mark Lam  <mark.lam@apple.com>
2728
2729         Remove unneeded --tradeDestructorBlocks option.
2730         https://bugs.webkit.org/show_bug.cgi?id=195698
2731         <rdar://problem/39681388>
2732
2733         Reviewed by Yusuke Suzuki.
2734
2735         There's no reason why we would ever want --tradeDestructorBlocks to be false.
2736
2737         Also, there was an assertion in BlockDirectory::endMarking() for when
2738         (!Options::tradeDestructorBlocks() && needsDestruction()).  This assertion is
2739         outdated because the BlockDirectory's m_empty set used to mean the set of all
2740         blocks that have no live (as in not reachable by GC) objects and dead objects
2741         also do not require destructors to be called on them.  The current meaning of
2742         m_empty is that it is the set of all blocks that have no live objects,
2743         independent of whether they needs destructors to be called on them or not.
2744         The assertion is no longer valid for the new meaning of m_empty as m_empty may
2745         now contain destructible blocks.  This assertion is now removed as part of this
2746         patch.
2747
2748         * heap/BlockDirectory.cpp:
2749         (JSC::BlockDirectory::endMarking):
2750         * heap/LocalAllocator.cpp:
2751         (JSC::LocalAllocator::tryAllocateWithoutCollecting):
2752         * runtime/Options.h:
2753
2754 2019-03-13  Dominik Infuehr  <dinfuehr@igalia.com>
2755
2756         String overflow when using StringBuilder in JSC::createError
2757         https://bugs.webkit.org/show_bug.cgi?id=194957
2758
2759         Reviewed by Mark Lam.
2760
2761         StringBuilder in notAFunctionSourceAppender didn't check
2762         for overflows but just failed.
2763
2764         * runtime/ExceptionHelpers.cpp:
2765         (JSC::notAFunctionSourceAppender):
2766
2767 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
2768
2769         [JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
2770         https://bugs.webkit.org/show_bug.cgi?id=195593
2771
2772         Reviewed by Keith Miller.
2773
2774         This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.
2775
2776         1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
2777            not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.
2778
2779         2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
2780            to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
2781            each XXXPrototype / XXXConstructor can encourage the reuse of the code.
2782
2783         * runtime/ArrayPrototype.cpp:
2784         (JSC::ArrayPrototype::create):
2785         (JSC::speciesWatchpointIsValid):
2786         (JSC::ArrayPrototype::destroy): Deleted.
2787         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
2788         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
2789         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
2790         * runtime/ArrayPrototype.h:
2791         * runtime/JSGlobalObject.cpp:
2792         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
2793         we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
2794         requires WatchpointSet is IsWatched state.
2795         * runtime/JSGlobalObject.h:
2796
2797 2019-03-12  Yusuke Suzuki  <ysuzuki@apple.com>
2798
2799         [JSC] OSR entry should respect abstract values in addition to flush formats
2800         https://bugs.webkit.org/show_bug.cgi?id=195653
2801
2802         Reviewed by Mark Lam.
2803
2804         Let's consider the following graph.
2805
2806         Block #0
2807             ...
2808             27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
2809             ...
2810             28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
2811             29:<!0:->     MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
2812             30:< 1:->     SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid)  predicting BytecodeDouble
2813             ...
2814             73:<!0:->     Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)
2815
2816         Block #1 (bc#71): (OSR target) pred, #0
2817             ...
2818            102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid)  predicting BytecodeDouble
2819             ...
2820
2821         CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
2822         However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
2823         Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.
2824
2825         The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
2826         which is None. Then, we hit the breakpoint emitted by @102.
2827
2828         This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
2829         failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.
2830
2831         * dfg/DFGOSREntry.cpp:
2832         (JSC::DFG::prepareOSREntry):
2833
2834 2019-03-12  Michael Saboff  <msaboff@apple.com>
2835
2836         REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
2837         https://bugs.webkit.org/show_bug.cgi?id=195613
2838
2839         Reviewed by Mark Lam.
2840
2841         The bug here is in Yarr JIT backreference matching code.  We are incorrectly
2842         using a checkedOffset / inputPosition correction when checking for the available
2843         length left in a string.  It is improper to do these corrections as a backreference's
2844         match length is based on what was matched in the referenced capture group and not
2845         part of the checkedOffset and inputPosition computed when we compiled the RegExp.
2846         In some cases, the resulting incorrect calculation would allow us to go past
2847         the subject string's length.  Removed these adjustments.
2848
2849         After writing tests for the first bug, found another bug where the non-greedy
2850         backreference backtracking code didn't do an "are we at the end of the input?" check.
2851         This caused an infinite loop as we'd jump from the backtracking code back to
2852         try matching one more backreference, fail and then backtrack.
2853
2854         * yarr/YarrJIT.cpp:
2855         (JSC::Yarr::YarrGenerator::generateBackReference):
2856         (JSC::Yarr::YarrGenerator::backtrackBackReference):
2857
2858 2019-03-12  Robin Morisset  <rmorisset@apple.com>
2859
2860         A lot more classes have padding that can be reduced by reordering their fields
2861         https://bugs.webkit.org/show_bug.cgi?id=195579
2862
2863         Reviewed by Mark Lam.
2864
2865         * assembler/LinkBuffer.h:
2866         * dfg/DFGArrayifySlowPathGenerator.h:
2867         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
2868         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2869         (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
2870         (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
2871         * dfg/DFGGraph.h:
2872         * dfg/DFGNode.h:
2873         (JSC::DFG::SwitchData::SwitchData):
2874         * dfg/DFGPlan.cpp:
2875         (JSC::DFG::Plan::Plan):
2876         * dfg/DFGPlan.h:
2877         * dfg/DFGSlowPathGenerator.h:
2878         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
2879         * dfg/DFGSpeculativeJIT.cpp:
2880         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2881         * dfg/DFGSpeculativeJIT.h:
2882         * domjit/DOMJITSignature.h:
2883         (JSC::DOMJIT::Signature::Signature):
2884         (JSC::DOMJIT::Signature::effect):
2885         (JSC::DOMJIT::Signature::argumentCount): Deleted.
2886         * heap/MarkingConstraintSolver.h:
2887         * heap/SlotVisitor.h:
2888         * jit/CallFrameShuffleData.h:
2889         * jit/JITDivGenerator.h:
2890         * jit/SpillRegistersMode.h:
2891         * parser/Nodes.h:
2892         * profiler/ProfilerOSRExit.cpp:
2893         (JSC::Profiler::OSRExit::OSRExit):
2894         * profiler/ProfilerOSRExit.h:
2895         * runtime/ArrayBufferView.h:
2896         * runtime/SamplingProfiler.cpp:
2897         (JSC::SamplingProfiler::SamplingProfiler):
2898         * runtime/SamplingProfiler.h:
2899         * runtime/TypeSet.cpp:
2900         (JSC::StructureShape::StructureShape):
2901         * runtime/TypeSet.h:
2902         * runtime/Watchdog.h:
2903
2904 2019-03-12  Mark Lam  <mark.lam@apple.com>
2905
2906         The HasIndexedProperty node does GC.
2907         https://bugs.webkit.org/show_bug.cgi?id=195559
2908         <rdar://problem/48767923>
2909
2910         Reviewed by Yusuke Suzuki.
2911
2912         HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
2913         which can eventually call JSString::getIndex(), which can resolve a rope.
2914
2915         * dfg/DFGDoesGC.cpp:
2916         (JSC::DFG::doesGC):
2917
2918 2019-03-12  Devin Rousso  <drousso@apple.com>
2919
2920         Web Inspector: Audit: there should be a centralized place for reusable code
2921         https://bugs.webkit.org/show_bug.cgi?id=195265
2922         <rdar://problem/47040673>
2923
2924         Reviewed by Joseph Pecoraro.
2925
2926         * inspector/protocol/Audit.json:
2927         Increment version.
2928
2929 2019-03-12  Robin Morisset  <rmorisset@apple.com>
2930
2931         blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
2932         https://bugs.webkit.org/show_bug.cgi?id=195595
2933
2934         Reviewed by Saam Barati.
2935
2936         Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>
2937
2938         * dfg/DFGBasicBlock.h:
2939         * dfg/DFGGraph.cpp:
2940         (JSC::DFG::Graph::blocksInPreOrder):
2941         (JSC::DFG::Graph::blocksInPostOrder):
2942
2943 2019-03-11  Ross Kirsling  <ross.kirsling@sony.com>
2944
2945         Add Optional to Forward.h.
2946         https://bugs.webkit.org/show_bug.cgi?id=195586
2947
2948         Reviewed by Darin Adler.
2949
2950         * b3/B3Common.cpp:
2951         * b3/B3Common.h:
2952         * debugger/DebuggerParseData.cpp:
2953         * debugger/DebuggerParseData.h:
2954         * heap/HeapSnapshot.cpp:
2955         * heap/HeapSnapshot.h:
2956         * jit/PCToCodeOriginMap.cpp:
2957         * jit/PCToCodeOriginMap.h:
2958         * runtime/AbstractModuleRecord.cpp:
2959         * runtime/AbstractModuleRecord.h:
2960         * wasm/WasmInstance.h:
2961         * wasm/WasmModuleParser.h:
2962         * wasm/WasmSectionParser.cpp:
2963         * wasm/WasmSectionParser.h:
2964         * wasm/WasmStreamingParser.cpp:
2965         * wasm/WasmStreamingParser.h:
2966         * yarr/YarrFlags.cpp:
2967         * yarr/YarrFlags.h:
2968         * yarr/YarrUnicodeProperties.cpp:
2969         * yarr/YarrUnicodeProperties.h:
2970         Remove unnecessary includes from headers.
2971
2972 2019-03-11  Justin Fan  <justin_fan@apple.com>
2973
2974         [Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
2975         https://bugs.webkit.org/show_bug.cgi?id=194406
2976         <rdar://problem/47892466>
2977
2978         Reviewed by Myles C. Maxfield.
2979
2980         Added WebGPU to inspector context types.
2981
2982         * inspector/protocol/Canvas.json:
2983         * inspector/scripts/codegen/generator.py:
2984
2985 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
2986
2987         [JSC] Reduce # of structures in JSGlobalObject initialization
2988         https://bugs.webkit.org/show_bug.cgi?id=195498
2989
2990         Reviewed by Darin Adler.
2991
2992         This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
2993         MarkedBlock and this patch drops one MarkedBlock used for Structure previously.
2994
2995         * CMakeLists.txt:
2996         * DerivedSources-output.xcfilelist:
2997         * DerivedSources.make:
2998         * JavaScriptCore.xcodeproj/project.pbxproj:
2999         * runtime/ArrayIteratorPrototype.cpp:
3000         (JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
3001         "next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
3002         transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.
3003
3004         * runtime/ArrayPrototype.cpp:
3005         (JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
3006         in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
3007         any performance benefit. This change saves several structures that are not useful.
3008
3009         * runtime/ClonedArguments.cpp:
3010         (JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.
3011
3012         * runtime/JSGlobalObject.cpp:
3013         (JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
3014         since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
3015         operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
3016         we should do here.
3017
3018         (JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
3019         (JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.
3020
3021         * runtime/JSGlobalObject.h:
3022         * runtime/MapIteratorPrototype.cpp:
3023         (JSC::MapIteratorPrototype::finishCreation):
3024         * runtime/NullGetterFunction.h:
3025         * runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
3026         we can use without-transition property addition.
3027
3028         * runtime/StringIteratorPrototype.cpp:
3029         (JSC::StringIteratorPrototype::finishCreation):
3030         * runtime/VM.cpp:
3031         (JSC::VM::VM):
3032         (JSC::VM::setIteratorStructureSlow):
3033         (JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
3034         * runtime/VM.h:
3035         (JSC::VM::setIteratorStructure):
3036         (JSC::VM::mapIteratorStructure):
3037
3038 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
3039
3040         [JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
3041         https://bugs.webkit.org/show_bug.cgi?id=195508
3042
3043         Reviewed by Darin Adler.
3044
3045         Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
3046         Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
3047         many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.
3048
3049         This patch changes two things in BuiltinExecutables.
3050
3051         1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
3052            We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.
3053
3054         2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
3055            This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.
3056
3057         * builtins/BuiltinExecutables.cpp:
3058         (JSC::BuiltinExecutables::BuiltinExecutables):
3059         (JSC::BuiltinExecutables::finalizeUnconditionally):
3060         (JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
3061         (JSC::BuiltinExecutables::finalize): Deleted.
3062         * builtins/BuiltinExecutables.h:
3063         (JSC::BuiltinExecutables::static_cast<unsigned>):
3064         (): Deleted.
3065         * heap/Heap.cpp:
3066         (JSC::Heap::finalizeUnconditionalFinalizers):
3067
3068 2019-03-11  Robin Morisset  <rmorisset@apple.com>
3069
3070         IntlDateTimeFormat can be shrunk by 32 bytes
3071         https://bugs.webkit.org/show_bug.cgi?id=195504
3072
3073         Reviewed by Darin Adler.
3074
3075         * runtime/IntlDateTimeFormat.h:
3076
3077 2019-03-11  Robin Morisset  <rmorisset@apple.com>
3078
3079         IntlCollator can be shrunk by 16 bytes
3080         https://bugs.webkit.org/show_bug.cgi?id=195503
3081
3082         Reviewed by Darin Adler.
3083
3084         * runtime/IntlCollator.h:
3085
3086 2019-03-11  Robin Morisset  <rmorisset@apple.com>
3087
3088         IntlNumberFormat can be shrunk by 16 bytes
3089         https://bugs.webkit.org/show_bug.cgi?id=195505
3090
3091         Reviewed by Darin Adler.
3092
3093         * runtime/IntlNumberFormat.h:
3094
3095 2019-03-11  Caio Lima  <ticaiolima@gmail.com>
3096
3097         [ESNext][BigInt] Implement "~" unary operation
3098         https://bugs.webkit.org/show_bug.cgi?id=182216
3099
3100         Reviewed by Keith Miller.
3101
3102         This patch is adding support of BigInt into op_bitnot operations. In
3103         addition, we are changing ArithBitNot to handle only Number operands,
3104         while introducing a new node named ValueBitNot to handle Untyped and
3105         BigInt. This node follows the same approach we are doing into other
3106         arithimetic operations into DFG.
3107
3108         * dfg/DFGAbstractInterpreterInlines.h:
3109         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3110
3111         It is possible that fixup and prediction propagation don't convert a
3112         ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
3113         analysis are conservative. In such case, we are adding constant
3114         folding rules to ValueBitNot AI.
3115
3116         * dfg/DFGBackwardsPropagationPhase.cpp:
3117         (JSC::DFG::BackwardsPropagationPhase::propagate):
3118
3119         ValueBitNot has same rules as ArithBitNot on backwards propagation.
3120
3121         * dfg/DFGByteCodeParser.cpp:
3122         (JSC::DFG::ByteCodeParser::parseBlock):
3123
3124         We can emit ArithBitNot if we know that operand of op_bitnot is a
3125         Number or any int. Otherwise we fallback to ValueBitNot and rely on
3126         fixup to convert the node to ArithBitNot when it is possible.
3127         ValueBitNot uses heap prediction on prediction propagation and we
3128         collect its type from op_bitnot's value profiler.
3129
3130         * dfg/DFGClobberize.h:
3131         (JSC::DFG::clobberize):
3132
3133         When we have the case with ValueBitNot(BigInt), we don't clobberize
3134         world.
3135
3136         * dfg/DFGDoesGC.cpp:
3137         (JSC::DFG::doesGC):
3138
3139         ValueBitNot can GC on BigIntUse because, right now, all bitNot
3140         operation allocates temporary BigInts to perform calculations and it
3141         can potentially trigger GC.
3142
3143         * dfg/DFGFixupPhase.cpp:
3144         (JSC::DFG::FixupPhase::fixupNode):
3145
3146         ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
3147         other uses, we fallback to ArithBitNot.
3148
3149         * dfg/DFGNode.h:
3150         (JSC::DFG::Node::hasHeapPrediction):
3151         * dfg/DFGNodeType.h:
3152         * dfg/DFGOperations.cpp:
3153         (JSC::DFG::bitwiseBinaryOp):
3154
3155         This template function is abstracting the new semantics of numeric
3156         values operations on bitwise operations. These operations usually
3157         folow these steps:
3158
3159             1. rhsNumeric = GetInt32OrBigInt(rhs)
3160             2. lhsNumeric = GetInt32OrBigInt(lhs)
3161             3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
3162             4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
3163             5. return rhs <int32BitOp> lhs
3164
3165         Since we have almost the same code for every bitwise op,
3166         we use such template to avoid code duplication. The template receives
3167         Int32 and BigInt operations as parameter. Error message is received as
3168         `const char*` instead of `String&` to avoid String allocation even when
3169         there is no error to throw.
3170
3171         * dfg/DFGOperations.h:
3172         * dfg/DFGPredictionPropagationPhase.cpp:
3173         * dfg/DFGSafeToExecute.h:
3174         (JSC::DFG::safeToExecute):
3175         * dfg/DFGSpeculativeJIT.cpp:
3176         (JSC::DFG::SpeculativeJIT::compileValueBitNot):
3177
3178         ValueBitNot generates speculative code for BigIntUse and this code is a
3179         call to `operationBitNotBigInt`. This operation is faster than
3180         `operationValueBitNot` because there is no need to check types of
3181         operands and execute properly operation. We still need to check
3182         exceptions after `operationBitNotBigInt` because it can throw OOM.
3183
3184         (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
3185         * dfg/DFGSpeculativeJIT.h:
3186         * dfg/DFGSpeculativeJIT32_64.cpp:
3187         (JSC::DFG::SpeculativeJIT::compile):
3188         * dfg/DFGSpeculativeJIT64.cpp:
3189         (JSC::DFG::SpeculativeJIT::compile):
3190         * ftl/FTLCapabilities.cpp:
3191         (JSC::FTL::canCompile):
3192         * ftl/FTLLowerDFGToB3.cpp:
3193         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3194         (JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
3195         (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
3196         * runtime/CommonSlowPaths.cpp:
3197         (JSC::SLOW_PATH_DECL):
3198         * runtime/JSBigInt.cpp:
3199         (JSC::JSBigInt::bitwiseNot):
3200         * runtime/JSBigInt.h:
3201
3202 2019-03-11  Darin Adler  <darin@apple.com>
3203
3204         Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
3205         https://bugs.webkit.org/show_bug.cgi?id=195533
3206
3207         Reviewed by Brent Fulgham.
3208
3209         * API/tests/ExecutionTimeLimitTest.cpp:
3210         (testExecutionTimeLimit): Use appendFixedPrecisionNumber.
3211         * runtime/NumberPrototype.cpp:
3212         (JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
3213         * runtime/Options.cpp:
3214         (JSC::Option::dump const): Use appendFixedPrecisionNumber.
3215
3216 2019-03-10  Ross Kirsling  <ross.kirsling@sony.com>
3217
3218         Invalid flags in a RegExp literal should be an early SyntaxError
3219         https://bugs.webkit.org/show_bug.cgi?id=195514
3220
3221         Reviewed by Darin Adler.
3222
3223         Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 
3224
3225           12.2.8.1 Static Semantics: Early Errors
3226             PrimaryExpression : RegularExpressionLiteral
3227               - It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
3228                 using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
3229               - It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
3230                 other than "g", "i", "m",  "s", "u", or "y", or if it contains the same code point more than once.
3231
3232         In fixing this, let's also move flag handling from runtime/ to yarr/.
3233
3234         * yarr/YarrSyntaxChecker.cpp:
3235         (JSC::Yarr::checkSyntax):
3236         Check flags before checking pattern.
3237
3238         * CMakeLists.txt:
3239         * JavaScriptCore.xcodeproj/project.pbxproj:
3240         * Sources.txt:
3241         * bytecompiler/NodesCodegen.cpp:
3242         (JSC::RegExpNode::emitBytecode):
3243         * inspector/ContentSearchUtilities.cpp:
3244         (Inspector::ContentSearchUtilities::findMagicComment):
3245         * runtime/CachedTypes.cpp:
3246         * runtime/RegExp.cpp:
3247         (JSC::RegExp::RegExp):
3248         (JSC::RegExp::createWithoutCaching):
3249         (JSC::RegExp::create):
3250         (JSC::regExpFlags): Deleted.
3251         * runtime/RegExp.h:
3252         * runtime/RegExpCache.cpp:
3253         (JSC::RegExpCache::lookupOrCreate):
3254         (JSC::RegExpCache::ensureEmptyRegExpSlow):
3255         * runtime/RegExpCache.h:
3256         * runtime/RegExpConstructor.cpp:
3257         (JSC::toFlags):
3258         (JSC::regExpCreate):
3259         (JSC::constructRegExp):
3260         * runtime/RegExpKey.h:
3261         (JSC::RegExpKey::RegExpKey):
3262         (WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
3263         (WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
3264         (): Deleted.
3265         * runtime/RegExpPrototype.cpp:
3266         (JSC::regExpProtoFuncCompile):
3267         * testRegExp.cpp:
3268         (parseRegExpLine):
3269         * yarr/RegularExpression.cpp:
3270         (JSC::Yarr::RegularExpression::Private::compile):
3271         * yarr/YarrFlags.cpp: Added.
3272         (JSC::Yarr::parseFlags):
3273         * yarr/YarrFlags.h: Added.
3274         * yarr/YarrInterpreter.h:
3275         (JSC::Yarr::BytecodePattern::ignoreCase const):
3276         (JSC::Yarr::BytecodePattern::multiline const):
3277         (JSC::Yarr::BytecodePattern::sticky const):
3278         (JSC::Yarr::BytecodePattern::unicode const):
3279         (JSC::Yarr::BytecodePattern::dotAll const):
3280         * yarr/YarrPattern.cpp:
3281         (JSC::Yarr::YarrPattern::compile):
3282         (JSC::Yarr::YarrPattern::YarrPattern):
3283         (JSC::Yarr::YarrPattern::dumpPattern):
3284         * yarr/YarrPattern.h:
3285         (JSC::Yarr::YarrPattern::global const):
3286         (JSC::Yarr::YarrPattern::ignoreCase const):
3287         (JSC::Yarr::YarrPattern::multiline const):
3288         (JSC::Yarr::YarrPattern::sticky const):
3289         (JSC::Yarr::YarrPattern::unicode const):
3290         (JSC::Yarr::YarrPattern::dotAll const):
3291         Move flag handling to Yarr and modernize API.
3292
3293 2019-03-09  Robin Morisset  <rmorisset@apple.com>
3294
3295         Compilation can be shrunk by 8 bytes
3296         https://bugs.webkit.org/show_bug.cgi?id=195500
3297
3298         Reviewed by Mark Lam.
3299
3300         * profiler/ProfilerCompilation.cpp:
3301         (JSC::Profiler::Compilation::Compilation):
3302         * profiler/ProfilerCompilation.h:
3303
3304 2019-03-09  Robin Morisset  <rmorisset@apple.com>
3305
3306         BinarySwitch can be shrunk by 8 bytes
3307         https://bugs.webkit.org/show_bug.cgi?id=195493
3308
3309         Reviewed by Mark Lam.
3310
3311         * jit/BinarySwitch.cpp:
3312         (JSC::BinarySwitch::BinarySwitch):
3313         * jit/BinarySwitch.h:
3314
3315 2019-03-09  Robin Morisset  <rmorisset@apple.com>
3316
3317         AsyncStackTrace can be shrunk by 8 bytes
3318         https://bugs.webkit.org/show_bug.cgi?id=195491
3319
3320         Reviewed by Mark Lam.
3321
3322         * inspector/AsyncStackTrace.h:
3323
3324 2019-03-08  Mark Lam  <mark.lam@apple.com>
3325
3326         Stack overflow crash in JSC::JSObject::hasInstance.
3327         https://bugs.webkit.org/show_bug.cgi?id=195458
3328         <rdar://problem/48710195>
3329
3330         Reviewed by Yusuke Suzuki.
3331
3332         * runtime/JSObject.cpp:
3333         (JSC::JSObject::hasInstance):
3334
3335 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3336
3337         IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
3338         https://bugs.webkit.org/show_bug.cgi?id=195487
3339
3340         Reviewed by Saam Barati.
3341
3342         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3343
3344 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3345
3346         TypeLocation can be shrunk by 8 bytes
3347         https://bugs.webkit.org/show_bug.cgi?id=195483
3348
3349         Reviewed by Mark Lam.
3350
3351         * bytecode/TypeLocation.h:
3352         (JSC::TypeLocation::TypeLocation):
3353
3354 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3355
3356         GetByIdStatus can be shrunk by 16 bytes
3357         https://bugs.webkit.org/show_bug.cgi?id=195480
3358
3359         Reviewed by Saam Barati.
3360
3361         8 bytes from reordering fields
3362         8 more bytes by making the enum State only use 1 byte.
3363
3364         * bytecode/GetByIdStatus.cpp:
3365         (JSC::GetByIdStatus::GetByIdStatus):
3366         * bytecode/GetByIdStatus.h:
3367
3368 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3369
3370         PutByIdVariant can be shrunk by 8 bytes
3371         https://bugs.webkit.org/show_bug.cgi?id=195482
3372
3373         Reviewed by Mark Lam.
3374
3375         * bytecode/PutByIdVariant.h:
3376         (JSC::PutByIdVariant::PutByIdVariant):
3377
3378 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
3379
3380         Unreviewed, follow-up after r242568
3381
3382         Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
3383
3384         * dfg/DFGAbstractInterpreterInlines.h:
3385         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3386
3387 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
3388
3389         [JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
3390         https://bugs.webkit.org/show_bug.cgi?id=195447
3391
3392         Reviewed by Filip Pizlo.
3393
3394         This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
3395         caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
3396         To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
3397         to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
3398         to use `putDirectWithoutTransition` instead of `putDirect`.
3399
3400         * inspector/JSInjectedScriptHostPrototype.cpp:
3401         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3402         * inspector/JSJavaScriptCallFramePrototype.cpp:
3403         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
3404         * runtime/ArrayConstructor.cpp:
3405         (JSC::ArrayConstructor::finishCreation):
3406         * runtime/AsyncFunctionConstructor.cpp:
3407         (JSC::AsyncFunctionConstructor::finishCreation):
3408         * runtime/AsyncGeneratorFunctionConstructor.cpp:
3409         (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
3410         * runtime/BigIntConstructor.cpp:
3411         (JSC::BigIntConstructor::finishCreation):
3412         * runtime/BooleanConstructor.cpp:
3413         (JSC::BooleanConstructor::finishCreation):
3414         * runtime/DateConstructor.cpp:
3415         (JSC::DateConstructor::finishCreation):
3416         * runtime/ErrorConstructor.cpp:
3417         (JSC::ErrorConstructor::finishCreation):
3418         * runtime/FunctionConstructor.cpp:
3419         (JSC::FunctionConstructor::finishCreation):
3420         * runtime/FunctionPrototype.cpp:
3421         (JSC::FunctionPrototype::finishCreation):
3422         (JSC::FunctionPrototype::addFunctionProperties):
3423         (JSC::FunctionPrototype::initRestrictedProperties):
3424         * runtime/FunctionPrototype.h:
3425         * runtime/GeneratorFunctionConstructor.cpp:
3426         (JSC::GeneratorFunctionConstructor::finishCreation):
3427         * runtime/InternalFunction.cpp:
3428         (JSC::InternalFunction::finishCreation):
3429         * runtime/InternalFunction.h:
3430         * runtime/IntlCollatorConstructor.cpp:
3431         (JSC::IntlCollatorConstructor::finishCreation):
3432         * runtime/IntlDateTimeFormatConstructor.cpp:
3433         (JSC::IntlDateTimeFormatConstructor::finishCreation):
3434         * runtime/IntlNumberFormatConstructor.cpp:
3435         (JSC::IntlNumberFormatConstructor::finishCreation):
3436         * runtime/IntlPluralRulesConstructor.cpp:
3437         (JSC::IntlPluralRulesConstructor::finishCreation):
3438         * runtime/JSArrayBufferConstructor.cpp:
3439         (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
3440         * runtime/JSArrayBufferPrototype.cpp:
3441         (JSC::JSArrayBufferPrototype::finishCreation):
3442         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3443         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
3444         * runtime/JSGlobalObject.cpp:
3445         (JSC::JSGlobalObject::init):
3446         * runtime/JSObject.cpp:
3447         (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
3448         (JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
3449         * runtime/JSObject.h:
3450         * runtime/JSPromiseConstructor.cpp:
3451         (JSC::JSPromiseConstructor::finishCreation):
3452         * runtime/JSTypedArrayViewConstructor.cpp:
3453         (JSC::JSTypedArrayViewConstructor::finishCreation):
3454         * runtime/JSTypedArrayViewPrototype.cpp:
3455         (JSC::JSTypedArrayViewPrototype::finishCreation):
3456         * runtime/MapConstructor.cpp:
3457         (JSC::MapConstructor::finishCreation):
3458         * runtime/MapPrototype.cpp:
3459         (JSC::MapPrototype::finishCreation):
3460         * runtime/NativeErrorConstructor.cpp:
3461         (JSC::NativeErrorConstructorBase::finishCreation):
3462         * runtime/NullGetterFunction.h:
3463         * runtime/NullSetterFunction.h:
3464         * runtime/NumberConstructor.cpp:
3465         (JSC::NumberConstructor::finishCreation):
3466         * runtime/ObjectConstructor.cpp:
3467         (JSC::ObjectConstructor::finishCreation):
3468         * runtime/ProxyConstructor.cpp:
3469         (JSC::ProxyConstructor::finishCreation):
3470         * runtime/RegExpConstructor.cpp:
3471         (JSC::RegExpConstructor::finishCreation):
3472         * runtime/RegExpPrototype.cpp:
3473         (JSC::RegExpPrototype::finishCreation):
3474         * runtime/SetConstructor.cpp:
3475         (JSC::SetConstructor::finishCreation):
3476         * runtime/SetPrototype.cpp:
3477         (JSC::SetPrototype::finishCreation):
3478         * runtime/StringConstructor.cpp:
3479         (JSC::StringConstructor::finishCreation):
3480         * runtime/SymbolConstructor.cpp:
3481         (JSC::SymbolConstructor::finishCreation):
3482         * runtime/WeakMapConstructor.cpp:
3483         (JSC::WeakMapConstructor::finishCreation):
3484         * runtime/WeakSetConstructor.cpp:
3485         (JSC::WeakSetConstructor::finishCreation):
3486         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
3487         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
3488         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3489         (JSC::WebAssemblyInstanceConstructor::finishCreation):
3490         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
3491         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
3492         * wasm/js/WebAssemblyMemoryConstructor.cpp:
3493         (JSC::WebAssemblyMemoryConstructor::finishCreation):
3494         * wasm/js/WebAssemblyModuleConstructor.cpp:
3495         (JSC::WebAssemblyModuleConstructor::finishCreation):
3496         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
3497         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
3498         * wasm/js/WebAssemblyTableConstructor.cpp:
3499         (JSC::WebAssemblyTableConstructor::finishCreation):
3500
3501 2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
3502
3503         op_check_tdz does not def its argument
3504         https://bugs.webkit.org/show_bug.cgi?id=192880
3505         <rdar://problem/46221598>
3506
3507         Reviewed by Saam Barati.
3508
3509         This prevented the for-in loop optimization in the bytecode generator, since
3510         the analysis sees a redefinition of the loop variable.
3511
3512         * bytecode/BytecodeUseDef.h:
3513         (JSC::computeDefsForBytecodeOffset):
3514
3515 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
3516
3517         [JSC] Make more fields lazy in JSGlobalObject
3518         https://bugs.webkit.org/show_bug.cgi?id=195449
3519
3520         Reviewed by Mark Lam.
3521
3522         This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
3523
3524         1. Some minor structures like moduleRecordStructure.
3525         2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
3526         3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
3527
3528         * interpreter/Interpreter.cpp:
3529         (JSC::Interpreter::execute):
3530         * runtime/JSArrayBufferPrototype.h:
3531         * runtime/JSGlobalObject.cpp:
3532         (JSC::JSGlobalObject::init):
3533         (JSC::JSGlobalObject::visitChildren):
3534         * runtime/JSGlobalObject.h:
3535         (JSC::JSGlobalObject::parseIntFunction const):
3536         (JSC::JSGlobalObject::parseFloatFunction const):
3537         (JSC::JSGlobalObject::evalFunction const):
3538         (JSC::JSGlobalObject::strictEvalActivationStructure const):
3539         (JSC::JSGlobalObject::moduleRecordStructure const):
3540         (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
3541         (JSC::JSGlobalObject::proxyObjectStructure const):
3542         (JSC::JSGlobalObject::callableProxyObjectStructure const):
3543         (JSC::JSGlobalObject::proxyRevokeStructure const):
3544         (JSC::JSGlobalObject::arrayBufferConstructor const):
3545         (JSC::JSGlobalObject::arrayBufferPrototype const):
3546         (JSC::JSGlobalObject::arrayBufferStructure const):
3547         * runtime/ProxyObject.h:
3548         * runtime/StrictEvalActivation.cpp:
3549         (JSC::StrictEvalActivation::StrictEvalActivation):
3550         * runtime/StrictEvalActivation.h:
3551         * wasm/js/JSWebAssemblyMemory.cpp:
3552         (JSC::JSWebAssemblyMemory::buffer):
3553         * wasm/js/WebAssemblyModuleConstructor.cpp:
3554         (JSC::webAssemblyModuleCustomSections):
3555
3556 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
3557
3558         [JSC] Remove merging must handle values into proven types in CFA
3559         https://bugs.webkit.org/show_bug.cgi?id=195444
3560
3561         Reviewed by Saam Barati.
3562
3563         Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
3564         from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
3565
3566             Block #2 (loop header) succ #3, #4
3567             ...
3568             1: ForceOSRExit
3569             ...
3570             2: JSConstant(0)
3571             3: SetLocal(@2, loc6)
3572             ...
3573             4: Branch(#3, #4)
3574
3575             Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
3576             ...
3577             5: GetLocal(loc6)
3578             6: StringFromCharCode(@5)
3579             ...
3580
3581         Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
3582         If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
3583         as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
3584         we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
3585         we should not merge it in CFA.
3586
3587         Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
3588         progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
3589
3590         * dfg/DFGCFAPhase.cpp:
3591         (JSC::DFG::CFAPhase::run):
3592         (JSC::DFG::CFAPhase::performBlockCFA):
3593         (JSC::DFG::CFAPhase::injectOSR): Deleted.
3594
3595 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
3596
3597         [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
3598         https://bugs.webkit.org/show_bug.cgi?id=195429
3599
3600         Reviewed by Saam Barati.
3601
3602         We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
3603         for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
3604         this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
3605         Note that ThunkGenerators's StringFromCharCode thunk was correct.
3606
3607         * dfg/DFGSpeculativeJIT.cpp:
3608         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
3609         * ftl/FTLLowerDFGToB3.cpp:
3610         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
3611
3612 2019-03-07  Mark Lam  <mark.lam@apple.com>
3613
3614         Follow up refactoring in try-finally code after r242591.
3615         https://bugs.webkit.org/show_bug.cgi?id=195428
3616
3617         Reviewed by Saam Barati.
3618
3619         1. Added some comments in emitFinallyCompletion() to describe each completion case.
3620         2. Converted CatchEntry into a struct.
3621         3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
3622            to be more clear about its purpose.
3623
3624         * bytecompiler/BytecodeGenerator.cpp:
3625         (JSC::BytecodeGenerator::generate):
3626         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
3627         (JSC::BytecodeGenerator::emitFinallyCompletion):
3628         * bytecompiler/BytecodeGenerator.h:
3629
3630 2019-03-07  Saam Barati  <sbarati@apple.com>
3631
3632         CompactVariableMap::Handle's copy operator= leaks the previous data
3633         https://bugs.webkit.org/show_bug.cgi?id=195398
3634
3635         Reviewed by Yusuke Suzuki.
3636
3637         The copy constructor was just assigning |this| to the new value,
3638         forgetting to decrement the ref count of the thing pointed to by
3639         the |this| handle. Based on Yusuke's suggestion, this patch refactors
3640         the move constructor, move operator=, and copy operator= to use the
3641         swap() primitive and the copy constructor primitive.
3642
3643         * parser/VariableEnvironment.cpp:
3644         (JSC::CompactVariableMap::Handle::Handle):
3645         (JSC::CompactVariableMap::Handle::swap):
3646         (JSC::CompactVariableMap::Handle::operator=): Deleted.
3647         * parser/VariableEnvironment.h:
3648         (JSC::CompactVariableMap::Handle::Handle):
3649         (JSC::CompactVariableMap::Handle::operator=):
3650
3651 2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
3652
3653         Lazily decode cached bytecode
3654         https://bugs.webkit.org/show_bug.cgi?id=194810
3655
3656         Reviewed by Saam Barati.
3657
3658         Like lazy parsing, we should pause at code block boundaries. Instead
3659         of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
3660         we store their offsets in the executable and lazily decode them on the next
3661         call to `unlinkedCodeBlockFor`.
3662
3663         * bytecode/UnlinkedFunctionExecutable.cpp:
3664         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3665         (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
3666         (JSC::UnlinkedFunctionExecutable::visitChildren):
3667         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3668         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
3669         * bytecode/UnlinkedFunctionExecutable.h:
3670         * runtime/CachedTypes.cpp:
3671         (JSC::Decoder::Decoder):
3672         (JSC::Decoder::~Decoder):
3673         (JSC::Decoder::create):
3674         (JSC::Decoder::offsetOf):
3675         (JSC::Decoder::cacheOffset):
3676         (JSC::Decoder::ptrForOffsetFromBase):
3677         (JSC::Decoder::handleForEnvironment const):
3678         (JSC::Decoder::setHandleForEnvironment):
3679         (JSC::Decoder::addFinalizer):
3680         (JSC::VariableLengthObject::isEmpty const):
3681         (JSC::CachedWriteBarrier::isEmpty const):
3682         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
3683         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
3684         (JSC::CachedFunctionExecutable::decode const):
3685         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3686         (JSC::decodeCodeBlockImpl):
3687         (JSC::isCachedBytecodeStillValid):
3688         (JSC::decodeFunctionCodeBlock):
3689         * runtime/CachedTypes.h:
3690         (JSC::Decoder::vm):
3691
3692 2019-03-06  Mark Lam  <mark.lam@apple.com>
3693
3694         Exception is a JSCell, not a JSObject.
3695         https://bugs.webkit.org/show_bug.cgi?id=195392
3696
3697         Reviewed by Saam Barati.
3698
3699         Exception is a VM implementation construct to carry a stack trace for the point
3700         where it is thrown from.  As a reminder, an Exception is needed because:
3701         1. JS code can throw primitives as well that are non-cells.
3702         2. Error objects capture the stack trace at the point where they are constructed,
3703            which is not always the same as the point where they are thrown (if they are
3704            thrown).
3705
3706         Hence, Exception should not be visible to JS code, and therefore should not be a
3707         JSObject.  Hence, it should not inherit from JSDestructibleObject.
3708
3709         This patch changes the following:
3710
3711         1. Exception now inherits directly from JSCell instead.
3712
3713         2. Places where we return an Exception masquerading as a JSObject* are now
3714            updated to return a nullptr when we encounter an exception.
3715
3716         3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
3717            exception in functions that return JSValue or EncodedJSValue.  This is because
3718            the number that implements the following pattern is too numerous:
3719
3720                 return throw<Some Error>(...)
3721
3722            We'll leave these as is for now.
3723
3724         * bytecode/CodeBlock.h:
3725         (JSC::ScriptExecutable::prepareForExecution):
3726         * interpreter/Interpreter.cpp:
3727         (JSC::Interpreter::executeProgram):
3728         (JSC::Interpreter::executeCall):
3729         (JSC::Interpreter::executeConstruct):
3730         (JSC::Interpreter::prepareForRepeatCall):
3731         (JSC::Interpreter::execute):
3732         (JSC::Interpreter::executeModuleProgram):
3733         * jit/JITOperations.cpp:
3734         * llint/LLIntSlowPaths.cpp:
3735         (JSC::LLInt::setUpCall):
3736         * runtime/ConstructData.cpp:
3737         (JSC::construct):
3738         * runtime/Error.cpp:
3739         (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
3740         (JSC::throwTypeError):
3741         (JSC::throwSyntaxError):
3742         * runtime/Error.h:
3743         (JSC::throwRangeError):
3744         * runtime/Exception.cpp:
3745         (JSC::Exception::createStructure):
3746         * runtime/Exception.h:
3747         * runtime/ExceptionHelpers.cpp:
3748         (JSC::throwOutOfMemoryError):
3749         (JSC::throwStackOverflowError):
3750         (JSC::throwTerminatedExecutionException):
3751         * runtime/ExceptionHelpers.h:
3752         * runtime/FunctionConstructor.cpp:
3753         (JSC::constructFunction):
3754         (JSC::constructFunctionSkippingEvalEnabledCheck):
3755         * runtime/IntlPluralRules.cpp:
3756         (JSC::IntlPluralRules::resolvedOptions):
3757         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3758         (JSC::constructGenericTypedArrayViewWithArguments):
3759         * runtime/JSObject.h:
3760         * runtime/ObjectConstructor.cpp:
3761         (JSC::objectConstructorSeal):
3762         (JSC::objectConstructorFreeze):
3763         * runtime/ProgramExecutable.cpp:
3764         (JSC::ProgramExecutable::initializeGlobalProperties):
3765         * runtime/RegExpConstructor.cpp:
3766         (JSC::regExpCreate):
3767         (JSC::constructRegExp):
3768         * runtime/ScriptExecutable.cpp:
3769         (JSC::ScriptExecutable::newCodeBlockFor):
3770         (JSC::ScriptExecutable::prepareForExecutionImpl):
3771         * runtime/ScriptExecutable.h:
3772         * runtime/ThrowScope.cpp:
3773         (JSC::ThrowScope::throwException):
3774         * runtime/ThrowScope.h:
3775         (JSC::ThrowScope::throwException):
3776         (JSC::throwException):
3777         * runtime/VM.cpp:
3778         (JSC::VM::throwException):
3779         * runtime/VM.h:
3780
3781 2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
3782
3783         [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
3784         https://bugs.webkit.org/show_bug.cgi?id=195346
3785
3786         Reviewed by Fujii Hironori.
3787
3788         * jsc.cpp:
3789         (currentWorkingDirectory):
3790         (fetchModuleFromLocalFileSystem):
3791         * runtime/DateConversion.cpp:
3792         (JSC::formatDateTime):
3793         Use wchar helpers as needed.
3794
3795 2019-03-06  Mark Lam  <mark.lam@apple.com>
3796
3797         Fix incorrect handling of try-finally completion values.
3798         https://bugs.webkit.org/show_bug.cgi?id=195131
3799         <rdar://problem/46222079>
3800
3801         Reviewed by Saam Barati and Yusuke Suzuki.
3802
3803         Consider the following:
3804
3805             function foo() {                        // line 1
3806                 try {
3807                     return 42;                      // line 3
3808                 } finally {
3809                     for (var j = 0; j < 1; j++) {   // line 5
3810                         try {
3811                             throw '';               // line 7
3812                         } finally {
3813                             continue;               // line 9
3814                         }
3815                     }
3816                 }                                   // line 11
3817             }
3818             var result = foo();
3819
3820         With the current (before fix) code base, result will be the exception object thrown
3821         at line 7.  The expected result should be 42, returned at line 3.
3822
3823         The bug is that we were previously only using one set of completion type and
3824         value registers for the entire function.  This is inadequate because the outer
3825         try-finally needs to preserve its own completion type and value ({ Return, 42 }
3826         in this case) in order to be able to complete correctly.
3827
3828         One might be deceived into thinking that the above example should complete with
3829         the exception thrown at line 7.  However, according to Section 13.15.8 of the
3830         ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
3831         completion.  As a result, it overrides the throw from line 7.  After the continue,
3832         execution resumes at the top of the loop at line 5, followed by a normal completion
3833         at line 11.
3834
3835         Also according to Section 13.15.8, given that the completion type of the outer
3836         finally is normal, the resultant completion of the outer try-finally should be
3837         the completion of the outer try block i.e. { Return, 42 }.
3838
3839         This patch makes the following changes:
3840         
3841         1. Fix handling of finally completion to use a unique set of completion
3842            type and value registers for each FinallyContext.
3843
3844         2. Move the setting of Throw completion type to the out of line exception handler.
3845            This makes the mainline code slightly less branchy.
3846
3847         3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
3848            emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
3849            bytecode inline.  Also, these make it clearer when we're emitting a handler
3850            for a catch vs a finally.
3851
3852         4. Allocate the FinallyContext on the stack instead of as a member of the
3853            heap allocated ControlFlowScope.  This simplifies its life-cycle management
3854            and reduces the amount of needed copying.
3855
3856         5. Update emitFinallyCompletion() to propagate the completion type and value to
3857            the outer FinallyContext when needed.
3858
3859         6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
3860            only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
3861            wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
3862            the order needs to be corrected.
3863
3864         7. Remove the unused CompletionType::Break and Continue.  These are encoded with
3865            the jumpIDs of the jump targets instead.
3866
3867         Relevant specifications: