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