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