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