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