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