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