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