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