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