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