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