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