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