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