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