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