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