2d1f7119f45864c888a9bf89556d41aef3132e24
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-05-08  Robin Morisset  <rmorisset@apple.com>
2
3         All prototypes should call didBecomePrototype()
4         https://bugs.webkit.org/show_bug.cgi?id=196315
5
6         Reviewed by Saam Barati.
7
8         This changelog already landed, but the commit was missing the actual changes.
9
10         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
11
12         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
13         create structures with invalid prototypes.
14         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
15         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
16
17         * runtime/BigIntPrototype.cpp:
18         (JSC::BigIntPrototype::finishCreation):
19         * runtime/BooleanPrototype.cpp:
20         (JSC::BooleanPrototype::finishCreation):
21         * runtime/DatePrototype.cpp:
22         (JSC::DatePrototype::finishCreation):
23         * runtime/ErrorConstructor.cpp:
24         (JSC::ErrorConstructor::finishCreation):
25         * runtime/ErrorPrototype.cpp:
26         (JSC::ErrorPrototype::finishCreation):
27         * runtime/FunctionConstructor.cpp:
28         (JSC::FunctionConstructor::finishCreation):
29         * runtime/FunctionPrototype.cpp:
30         (JSC::FunctionPrototype::finishCreation):
31         * runtime/IntlCollatorPrototype.cpp:
32         (JSC::IntlCollatorPrototype::finishCreation):
33         * runtime/IntlDateTimeFormatPrototype.cpp:
34         (JSC::IntlDateTimeFormatPrototype::finishCreation):
35         * runtime/IntlNumberFormatPrototype.cpp:
36         (JSC::IntlNumberFormatPrototype::finishCreation):
37         * runtime/IntlPluralRulesPrototype.cpp:
38         (JSC::IntlPluralRulesPrototype::finishCreation):
39         * runtime/JSArrayBufferPrototype.cpp:
40         (JSC::JSArrayBufferPrototype::finishCreation):
41         * runtime/JSDataViewPrototype.cpp:
42         (JSC::JSDataViewPrototype::finishCreation):
43         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
44         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
45         * runtime/JSGlobalObject.cpp:
46         (JSC::createConsoleProperty):
47         * runtime/JSPromisePrototype.cpp:
48         (JSC::JSPromisePrototype::finishCreation):
49         * runtime/JSTypedArrayViewConstructor.cpp:
50         (JSC::JSTypedArrayViewConstructor::finishCreation):
51         * runtime/JSTypedArrayViewPrototype.cpp:
52         (JSC::JSTypedArrayViewPrototype::finishCreation):
53         * runtime/NumberPrototype.cpp:
54         (JSC::NumberPrototype::finishCreation):
55         * runtime/RegExpPrototype.cpp:
56         (JSC::RegExpPrototype::finishCreation):
57         * runtime/StringPrototype.cpp:
58         (JSC::StringPrototype::finishCreation):
59         * runtime/Structure.cpp:
60         (JSC::Structure::isValidPrototype):
61         (JSC::Structure::changePrototypeTransition):
62         * runtime/Structure.h:
63         * runtime/SymbolPrototype.cpp:
64         (JSC::SymbolPrototype::finishCreation):
65         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
66         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
67         * wasm/js/WebAssemblyInstancePrototype.cpp:
68         (JSC::WebAssemblyInstancePrototype::finishCreation):
69         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
70         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
71         * wasm/js/WebAssemblyMemoryPrototype.cpp:
72         (JSC::WebAssemblyMemoryPrototype::finishCreation):
73         * wasm/js/WebAssemblyModulePrototype.cpp:
74         (JSC::WebAssemblyModulePrototype::finishCreation):
75         * wasm/js/WebAssemblyPrototype.cpp:
76         (JSC::WebAssemblyPrototype::finishCreation):
77         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
78         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
79         * wasm/js/WebAssemblyTablePrototype.cpp:
80         (JSC::WebAssemblyTablePrototype::finishCreation):
81
82 2019-05-08  Keith Miller  <keith_miller@apple.com>
83
84         Remove Gigacage from arm64 and use PAC for arm64e instead
85         https://bugs.webkit.org/show_bug.cgi?id=197110
86
87         Reviewed by Saam Barati.
88
89         This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.
90
91         Global Changes:
92         Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
93         Update assembler helper methods to use do PAC when caging.
94
95         LLInt:
96         Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
97         Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
98         Refactor caging into two helper macros for Primitive/JSValue cages.
99
100         Baseline/DFG:
101         Add authentication where needed for GetByVal and inline object construction.
102
103         FTL:
104         Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.
105
106         Wasm:
107         Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
108         As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
109         Using fast memories leads to roughly a 2% JetStream2 speedup.
110
111         * assembler/MacroAssemblerARM64E.h:
112         (JSC::MacroAssemblerARM64E::tagArrayPtr):
113         (JSC::MacroAssemblerARM64E::untagArrayPtr):
114         (JSC::MacroAssemblerARM64E::removeArrayPtrTag):
115         * b3/B3LowerToAir.cpp:
116         * b3/B3PatchpointSpecial.cpp:
117         (JSC::B3::PatchpointSpecial::admitsStack):
118         * b3/B3StackmapSpecial.cpp:
119         (JSC::B3::StackmapSpecial::forEachArgImpl):
120         (JSC::B3::StackmapSpecial::isArgValidForRep):
121         * b3/B3Validate.cpp:
122         * b3/B3ValueRep.cpp:
123         (JSC::B3::ValueRep::addUsedRegistersTo const):
124         (JSC::B3::ValueRep::dump const):
125         (WTF::printInternal):
126         * b3/B3ValueRep.h:
127         (JSC::B3::ValueRep::ValueRep):
128         (JSC::B3::ValueRep::isReg const):
129         * dfg/DFGOperations.cpp:
130         (JSC::DFG::newTypedArrayWithSize):
131         * dfg/DFGSpeculativeJIT.cpp:
132         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
133         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
134         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
135         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
136         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
137         * dfg/DFGSpeculativeJIT.h:
138         * dfg/DFGSpeculativeJIT64.cpp:
139         (JSC::DFG::SpeculativeJIT::compile):
140         * ftl/FTLLowerDFGToB3.cpp:
141         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
142         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
143         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
144         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
145         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
146         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
147         (JSC::FTL::DFG::LowerDFGToB3::caged):
148         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
149         * jit/AssemblyHelpers.h:
150         (JSC::AssemblyHelpers::cageConditionally):
151         * jit/IntrinsicEmitter.cpp:
152         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
153         * jit/JITPropertyAccess.cpp:
154         (JSC::JIT::emitDirectArgumentsGetByVal):
155         (JSC::JIT::emitIntTypedArrayGetByVal):
156         (JSC::JIT::emitFloatTypedArrayGetByVal):
157         (JSC::JIT::emitIntTypedArrayPutByVal):
158         (JSC::JIT::emitFloatTypedArrayPutByVal):
159         * jit/PolymorphicCallStubRoutine.cpp:
160         (JSC::PolymorphicCallNode::clearCallLinkInfo):
161         * llint/LowLevelInterpreter64.asm:
162         * offlineasm/arm64.rb:
163         * offlineasm/arm64e.rb: Added.
164         * offlineasm/ast.rb:
165         * offlineasm/instructions.rb:
166         * offlineasm/registers.rb:
167         * offlineasm/x86.rb:
168         * runtime/ArrayBuffer.cpp:
169         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
170         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
171         (JSC::ArrayBufferContents::ArrayBufferContents):
172         (JSC::ArrayBufferContents::destroy):
173         (JSC::ArrayBufferContents::tryAllocate):
174         (JSC::ArrayBufferContents::makeShared):
175         (JSC::ArrayBufferContents::copyTo):
176         * runtime/ArrayBuffer.h:
177         (JSC::SharedArrayBufferContents::data const):
178         (JSC::ArrayBufferContents::data const):
179         (JSC::ArrayBuffer::data):
180         (JSC::ArrayBuffer::data const):
181         (JSC::ArrayBuffer::byteLength const):
182         * runtime/ArrayBufferView.cpp:
183         (JSC::ArrayBufferView::ArrayBufferView):
184         * runtime/ArrayBufferView.h:
185         (JSC::ArrayBufferView::baseAddress const):
186         (JSC::ArrayBufferView::byteLength const):
187         (JSC::ArrayBufferView::setRangeImpl):
188         (JSC::ArrayBufferView::getRangeImpl):
189         * runtime/CachedTypes.cpp:
190         (JSC::CachedScopedArgumentsTable::encode):
191         (JSC::CachedScopedArgumentsTable::decode const):
192         * runtime/CagedBarrierPtr.h:
193         (JSC::CagedBarrierPtr::CagedBarrierPtr):
194         (JSC::CagedBarrierPtr::set):
195         (JSC::CagedBarrierPtr::get const):
196         (JSC::CagedBarrierPtr::getMayBeNull const):
197         (JSC::CagedBarrierPtr::getUnsafe const):
198         (JSC::CagedBarrierPtr::at const):
199         (JSC::CagedBarrierPtr::operator== const):
200         (JSC::CagedBarrierPtr::operator bool const):
201         (JSC::CagedBarrierPtr::setWithoutBarrier):
202         (JSC::CagedBarrierPtr::operator* const): Deleted.
203         (JSC::CagedBarrierPtr::operator-> const): Deleted.
204         (JSC::CagedBarrierPtr::operator[] const): Deleted.
205         (): Deleted.
206         * runtime/DataView.cpp:
207         (JSC::DataView::DataView):
208         * runtime/DataView.h:
209         (JSC::DataView::get):
210         (JSC::DataView::set):
211         * runtime/DirectArguments.cpp:
212         (JSC::DirectArguments::visitChildren):
213         (JSC::DirectArguments::overrideThings):
214         (JSC::DirectArguments::unmapArgument):
215         * runtime/DirectArguments.h:
216         * runtime/GenericArguments.h:
217         * runtime/GenericArgumentsInlines.h:
218         (JSC::GenericArguments<Type>::visitChildren):
219         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
220         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
221         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
222         * runtime/GenericTypedArrayView.h:
223         * runtime/GenericTypedArrayViewInlines.h:
224         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
225         * runtime/JSArrayBufferView.cpp:
226         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
227         (JSC::JSArrayBufferView::JSArrayBufferView):
228         (JSC::JSArrayBufferView::finalize):
229         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
230         * runtime/JSArrayBufferView.h:
231         (JSC::JSArrayBufferView::ConstructionContext::vector const):
232         (JSC::JSArrayBufferView::isNeutered):
233         (JSC::JSArrayBufferView::hasVector const):
234         (JSC::JSArrayBufferView::vector const):
235         * runtime/JSGenericTypedArrayViewInlines.h:
236         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
237         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
238         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
239         * runtime/Options.h:
240         * runtime/ScopedArgumentsTable.cpp:
241         (JSC::ScopedArgumentsTable::clone):
242         (JSC::ScopedArgumentsTable::setLength):
243         * runtime/ScopedArgumentsTable.h:
244         * runtime/SymbolTable.h:
245         * wasm/WasmAirIRGenerator.cpp:
246         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
247         (JSC::Wasm::AirIRGenerator::addCallIndirect):
248         * wasm/WasmB3IRGenerator.cpp:
249         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
250         (JSC::Wasm::B3IRGenerator::addCallIndirect):
251         * wasm/WasmBBQPlan.cpp:
252         (JSC::Wasm::BBQPlan::complete):
253         * wasm/WasmBinding.cpp:
254         (JSC::Wasm::wasmToWasm):
255         * wasm/WasmInstance.h:
256         (JSC::Wasm::Instance::cachedMemory const):
257         (JSC::Wasm::Instance::updateCachedMemory):
258         * wasm/WasmMemory.cpp:
259         (JSC::Wasm::Memory::Memory):
260         (JSC::Wasm::Memory::~Memory):
261         (JSC::Wasm::Memory::grow):
262         (JSC::Wasm::Memory::dump const):
263         * wasm/WasmMemory.h:
264         (JSC::Wasm::Memory::memory const):
265         * wasm/js/JSToWasm.cpp:
266         (JSC::Wasm::createJSToWasmWrapper):
267         * wasm/js/WebAssemblyFunction.cpp:
268         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
269
270 2019-05-08  Caio Lima  <ticaiolima@gmail.com>
271
272         [BigInt] Add ValueMod into DFG
273         https://bugs.webkit.org/show_bug.cgi?id=186174
274
275         Reviewed by Saam Barati.
276
277         This patch is introducing a new DFG node called ValueMod, that is
278         responsible to handle BigInt and Untyped specialization of op_mod.
279         With the introduction of BigInt, we think that cases with
280         ValueMod(Untyped, Untyped) can be more common and we introduced
281         support for such kind of node.
282
283         * dfg/DFGAbstractInterpreter.h:
284         * dfg/DFGAbstractInterpreterInlines.h:
285         (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):
286
287         We are abstracting the constant rules of division operations. It
288         includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
289         the same analysis.
290
291         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
292         * dfg/DFGBackwardsPropagationPhase.cpp:
293         (JSC::DFG::BackwardsPropagationPhase::propagate):
294         * dfg/DFGByteCodeParser.cpp:
295         (JSC::DFG::ByteCodeParser::makeSafe):
296         (JSC::DFG::ByteCodeParser::parseBlock):
297
298         Here we check if lhs and rhs have number result to emit ArithMod.
299         Otherwise, we need to fallback to ValueMod and let fixup replace this
300         operation when possible.
301
302         * dfg/DFGClobberize.h:
303         (JSC::DFG::clobberize):
304
305         ValueMod(BigIntUse) doesn't clobberize world because it only calls
306         `operationModBigInt`.
307
308         * dfg/DFGDoesGC.cpp:
309         (JSC::DFG::doesGC):
310
311         ValueMod(BigIntUse) can trigger GC since it allocates intermediate
312         JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
313         because it can execute arbritary code from user.
314
315         * dfg/DFGFixupPhase.cpp:
316         (JSC::DFG::FixupPhase::fixupArithDivInt32):
317
318         Function created to simplify readability of ArithDiv/AirthMod fixup
319         operation.
320
321         (JSC::DFG::FixupPhase::fixupArithDiv):
322         (JSC::DFG::FixupPhase::fixupNode):
323
324         Following the same fixup rules of ArithDiv.
325
326         * dfg/DFGNodeType.h:
327         * dfg/DFGOperations.cpp:
328         (JSC::DFG::binaryOp):
329         * dfg/DFGOperations.h:
330         * dfg/DFGPredictionPropagationPhase.cpp:
331
332         ValueMod follows the same prediction propagation rules of ArithMod and
333         the same rules for `doDoubleVoting`.
334
335         * dfg/DFGSafeToExecute.h:
336         (JSC::DFG::safeToExecute):
337         * dfg/DFGSpeculativeJIT.cpp:
338         (JSC::DFG::SpeculativeJIT::compileValueMod):
339         * dfg/DFGSpeculativeJIT.h:
340         * dfg/DFGSpeculativeJIT32_64.cpp:
341         (JSC::DFG::SpeculativeJIT::compile):
342         * dfg/DFGSpeculativeJIT64.cpp:
343         (JSC::DFG::SpeculativeJIT::compile):
344         * dfg/DFGValidate.cpp:
345         * ftl/FTLCapabilities.cpp:
346         (JSC::FTL::canCompile):
347         * ftl/FTLLowerDFGToB3.cpp:
348         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
349         (JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
350
351 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
352
353         [JSC] DFG_ASSERT failed in lowInt52
354         https://bugs.webkit.org/show_bug.cgi?id=197569
355
356         Reviewed by Saam Barati.
357
358         GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
359         we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.
360
361         * ftl/FTLLowerDFGToB3.cpp:
362         (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
363
364 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
365
366         [JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
367         https://bugs.webkit.org/show_bug.cgi?id=197645
368
369         Reviewed by Saam Barati.
370
371         We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
372         but this has several memory inefficiency.
373
374         1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
375         2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
376            use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
377            non-movable.
378         3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.
379
380         * bytecode/CodeBlock.cpp:
381         (JSC::CodeBlock::finalizeLLIntInlineCaches):
382         * bytecode/CodeBlock.h:
383         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
384         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
385         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
386         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
387         * bytecode/Watchpoint.h:
388         * llint/LLIntSlowPaths.cpp:
389         (JSC::LLInt::setupGetByIdPrototypeCache):
390
391 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
392
393         JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
394         https://bugs.webkit.org/show_bug.cgi?id=197479
395
396         Reviewed by Saam Barati.
397
398         Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
399         If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
400         To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
401         peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
402         and miss `op_end` case.
403
404         This patch makes the following changes.
405
406         1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
407         2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
408         3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.
409
410         * bytecompiler/BytecodeGenerator.cpp:
411         (JSC::BytecodeGenerator::fuseCompareAndJump):
412         (JSC::BytecodeGenerator::fuseTestAndJmp):
413         (JSC::BytecodeGenerator::emitJumpIfTrue):
414         (JSC::BytecodeGenerator::emitJumpIfFalse):
415         (JSC::BytecodeGenerator::emitEqualityOpImpl):
416         * bytecompiler/BytecodeGenerator.h:
417         (JSC::BytecodeGenerator::canDoPeepholeOptimization const):
418
419 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
420
421         TemplateObject passed to template literal tags are not always identical for the same source location.
422         https://bugs.webkit.org/show_bug.cgi?id=190756
423
424         Reviewed by Saam Barati.
425
426         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
427         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
428
429         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
430         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
431
432         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
433         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
434         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
435         which maps source locations to cached site objects.
436
437         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
438         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
439         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
440         4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.
441
442         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
443         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
444         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
445         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
446         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
447         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
448         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
449         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
450         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
451         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
452         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
453         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
454         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
455         * Scripts/wkbuiltins/builtins_templates.py:
456         * bytecode/CodeBlock.cpp:
457         (JSC::CodeBlock::finishCreation):
458         (JSC::CodeBlock::setConstantRegisters):
459         * bytecode/CodeBlock.h:
460         * bytecode/UnlinkedFunctionExecutable.cpp:
461         (JSC::UnlinkedFunctionExecutable::link):
462         * bytecode/UnlinkedFunctionExecutable.h:
463         * bytecompiler/BytecodeGenerator.cpp:
464         (JSC::BytecodeGenerator::addTemplateObjectConstant):
465         (JSC::BytecodeGenerator::emitGetTemplateObject):
466         * bytecompiler/BytecodeGenerator.h:
467         * parser/ASTBuilder.h:
468         (JSC::ASTBuilder::createTaggedTemplate):
469         * runtime/CachedTypes.cpp:
470         (JSC::CachedTemplateObjectDescriptor::encode):
471         (JSC::CachedTemplateObjectDescriptor::decode const):
472         (JSC::CachedJSValue::encode):
473         (JSC::CachedJSValue::decode const):
474         * runtime/EvalExecutable.cpp:
475         (JSC::EvalExecutable::ensureTemplateObjectMap):
476         (JSC::EvalExecutable::visitChildren):
477         * runtime/EvalExecutable.h:
478         * runtime/FunctionExecutable.cpp:
479         (JSC::FunctionExecutable::finishCreation):
480         (JSC::FunctionExecutable::visitChildren):
481         (JSC::FunctionExecutable::fromGlobalCode):
482         (JSC::FunctionExecutable::ensureRareDataSlow):
483         (JSC::FunctionExecutable::ensureTemplateObjectMap):
484         * runtime/FunctionExecutable.h:
485         * runtime/JSModuleRecord.cpp:
486         (JSC::JSModuleRecord::instantiateDeclarations):
487         * runtime/JSTemplateObjectDescriptor.cpp:
488         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
489         (JSC::JSTemplateObjectDescriptor::create):
490         * runtime/JSTemplateObjectDescriptor.h:
491         * runtime/ModuleProgramExecutable.cpp:
492         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
493         (JSC::ModuleProgramExecutable::visitChildren):
494         * runtime/ModuleProgramExecutable.h:
495         * runtime/ProgramExecutable.cpp:
496         (JSC::ProgramExecutable::ensureTemplateObjectMap):
497         (JSC::ProgramExecutable::visitChildren):
498         * runtime/ProgramExecutable.h:
499         * runtime/ScriptExecutable.cpp:
500         (JSC::ScriptExecutable::topLevelExecutable):
501         (JSC::ScriptExecutable::createTemplateObject):
502         (JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
503         (JSC::ScriptExecutable::ensureTemplateObjectMap):
504         * runtime/ScriptExecutable.h:
505         * tools/JSDollarVM.cpp:
506         (JSC::functionCreateBuiltin):
507         (JSC::functionDeleteAllCodeWhenIdle):
508         (JSC::JSDollarVM::finishCreation):
509
510 2019-05-07  Robin Morisset  <rmorisset@apple.com>
511
512         [B3] Constants should be hoisted to the root block until moveConstants
513         https://bugs.webkit.org/show_bug.cgi?id=197265
514
515         Reviewed by Saam Barati.
516
517         This patch does the following:
518         - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
519         - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
520         - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
521         - I also took the opportunity to fix typos in comments in various parts of the code base.
522
523         Here are a few numbers to justify this patch:
524         - In JetStream2, about 27% of values at the beginning of B3 are constants
525         - In JetStream2, about 11% of values at the end of B3 are Nops
526         - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).
527
528         When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.
529
530         * b3/B3Generate.cpp:
531         (JSC::B3::generateToAir):
532         * b3/B3MoveConstants.cpp:
533         * b3/B3PureCSE.cpp:
534         (JSC::B3::PureCSE::process):
535         * b3/B3PureCSE.h:
536         * b3/B3ReduceStrength.cpp:
537         * bytecode/GetByIdStatus.cpp:
538         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
539         * dfg/DFGCSEPhase.cpp:
540         * dfg/DFGOSRAvailabilityAnalysisPhase.h:
541         * dfg/DFGOSRExit.cpp:
542         (JSC::DFG::OSRExit::executeOSRExit):
543
544 2019-05-07  Robin Morisset  <rmorisset@apple.com>
545
546         All prototypes should call didBecomePrototype()
547         https://bugs.webkit.org/show_bug.cgi?id=196315
548
549         Reviewed by Saam Barati.
550
551         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
552
553         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
554         create structures with invalid prototypes.
555         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
556         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
557
558         * runtime/BigIntPrototype.cpp:
559         (JSC::BigIntPrototype::finishCreation):
560         * runtime/BooleanPrototype.cpp:
561         (JSC::BooleanPrototype::finishCreation):
562         * runtime/DatePrototype.cpp:
563         (JSC::DatePrototype::finishCreation):
564         * runtime/ErrorConstructor.cpp:
565         (JSC::ErrorConstructor::finishCreation):
566         * runtime/ErrorPrototype.cpp:
567         (JSC::ErrorPrototype::finishCreation):
568         * runtime/FunctionConstructor.cpp:
569         (JSC::FunctionConstructor::finishCreation):
570         * runtime/FunctionPrototype.cpp:
571         (JSC::FunctionPrototype::finishCreation):
572         * runtime/IntlCollatorPrototype.cpp:
573         (JSC::IntlCollatorPrototype::finishCreation):
574         * runtime/IntlDateTimeFormatPrototype.cpp:
575         (JSC::IntlDateTimeFormatPrototype::finishCreation):
576         * runtime/IntlNumberFormatPrototype.cpp:
577         (JSC::IntlNumberFormatPrototype::finishCreation):
578         * runtime/IntlPluralRulesPrototype.cpp:
579         (JSC::IntlPluralRulesPrototype::finishCreation):
580         * runtime/JSArrayBufferPrototype.cpp:
581         (JSC::JSArrayBufferPrototype::finishCreation):
582         * runtime/JSDataViewPrototype.cpp:
583         (JSC::JSDataViewPrototype::finishCreation):
584         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
585         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
586         * runtime/JSGlobalObject.cpp:
587         (JSC::createConsoleProperty):
588         * runtime/JSPromisePrototype.cpp:
589         (JSC::JSPromisePrototype::finishCreation):
590         * runtime/JSTypedArrayViewConstructor.cpp:
591         (JSC::JSTypedArrayViewConstructor::finishCreation):
592         * runtime/JSTypedArrayViewPrototype.cpp:
593         (JSC::JSTypedArrayViewPrototype::finishCreation):
594         * runtime/NumberPrototype.cpp:
595         (JSC::NumberPrototype::finishCreation):
596         * runtime/RegExpPrototype.cpp:
597         (JSC::RegExpPrototype::finishCreation):
598         * runtime/StringPrototype.cpp:
599         (JSC::StringPrototype::finishCreation):
600         * runtime/Structure.cpp:
601         (JSC::Structure::isValidPrototype):
602         (JSC::Structure::changePrototypeTransition):
603         * runtime/Structure.h:
604         * runtime/SymbolPrototype.cpp:
605         (JSC::SymbolPrototype::finishCreation):
606         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
607         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
608         * wasm/js/WebAssemblyInstancePrototype.cpp:
609         (JSC::WebAssemblyInstancePrototype::finishCreation):
610         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
611         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
612         * wasm/js/WebAssemblyMemoryPrototype.cpp:
613         (JSC::WebAssemblyMemoryPrototype::finishCreation):
614         * wasm/js/WebAssemblyModulePrototype.cpp:
615         (JSC::WebAssemblyModulePrototype::finishCreation):
616         * wasm/js/WebAssemblyPrototype.cpp:
617         (JSC::WebAssemblyPrototype::finishCreation):
618         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
619         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
620         * wasm/js/WebAssemblyTablePrototype.cpp:
621         (JSC::WebAssemblyTablePrototype::finishCreation):
622
623 2019-05-07  Robin Morisset  <rmorisset@apple.com>
624
625         WTF::BitVector should have an isEmpty() method
626         https://bugs.webkit.org/show_bug.cgi?id=197637
627
628         Reviewed by Keith Miller.
629
630         Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
631
632         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
633
634 2019-05-07  Commit Queue  <commit-queue@webkit.org>
635
636         Unreviewed, rolling out r244978.
637         https://bugs.webkit.org/show_bug.cgi?id=197671
638
639         TemplateObject map should use start/end offsets (Requested by
640         yusukesuzuki on #webkit).
641
642         Reverted changeset:
643
644         "TemplateObject passed to template literal tags are not always
645         identical for the same source location."
646         https://bugs.webkit.org/show_bug.cgi?id=190756
647         https://trac.webkit.org/changeset/244978
648
649 2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>
650
651         tryCachePutByID should not crash if target offset changes
652         https://bugs.webkit.org/show_bug.cgi?id=197311
653         <rdar://problem/48033612>
654
655         Reviewed by Filip Pizlo.
656
657         When tryCachePutID is called with a cacheable setter, if the target object where the setter was
658         found is still in the prototype chain and there's no poly protos in the chain, we use
659         generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
660         It checks for the absence of the property in every object in the prototype chain from the base
661         down to the target object and checks that the property is still present in the target object. It
662         also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
663         chain. However, it does not consider two edge cases:
664         - It asserts that the property should still be at the same offset in the target object, but this
665         assertion does not hold if the setter deletes properties of the object and causes the structure
666         to be flattened after the deletion. Instead of asserting, we just use the updated offset.
667         - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
668
669         * jit/Repatch.cpp:
670         (JSC::tryCachePutByID):
671
672 2019-05-07  Saam Barati  <sbarati@apple.com>
673
674         Don't OSR enter into an FTL CodeBlock that has been jettisoned
675         https://bugs.webkit.org/show_bug.cgi?id=197531
676         <rdar://problem/50162379>
677
678         Reviewed by Yusuke Suzuki.
679
680         Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
681         enter into an FTL OSR entry code block that has been jettisoned already.
682
683         * dfg/DFGJITCode.cpp:
684         (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
685         * dfg/DFGJITCode.h:
686         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
687         * dfg/DFGOSREntry.cpp:
688         (JSC::DFG::prepareOSREntry):
689         (JSC::DFG::prepareCatchOSREntry):
690         * dfg/DFGOperations.cpp:
691         * ftl/FTLOSREntry.cpp:
692         (JSC::FTL::prepareOSREntry):
693
694 2019-05-06  Keith Miller  <keith_miller@apple.com>
695
696         JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
697         https://bugs.webkit.org/show_bug.cgi?id=197324
698         <rdar://problem/50253144>
699
700         Reviewed by Saam Barati.
701
702         The current implementation prevents using JSExport to shadow a
703         method from a super class. This was because we would only add a
704         method if the prototype didn't already claim to have the
705         property. Normally this would only happen if an Objective-C super
706         class already exported a ObjCCallbackFunction for the method,
707         however, if the user exports a property that is already on
708         Object.prototype the overriden method won't be exported.
709
710         This patch fixes the object prototype issue by checking if the
711         property on the prototype chain is an ObjCCallbackFunction, if
712         it's not then it adds an override.
713
714         * API/JSWrapperMap.mm:
715         (copyMethodsToObject):
716         * API/tests/testapi.mm:
717         (-[ToStringClass toString]):
718         (-[ToStringClass other]):
719         (-[ToStringSubclass toString]):
720         (-[ToStringSubclassNoProtocol toString]):
721         (testToString):
722         (testObjectiveCAPI):
723
724 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
725
726         [JSC] We should check OOM for description string of Symbol
727         https://bugs.webkit.org/show_bug.cgi?id=197634
728
729         Reviewed by Keith Miller.
730
731         When resoling JSString for description of Symbol, we should check OOM error.
732         We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
733         without description, (1) to simplify the code and (2) give a way for JSC API
734         to create a symbol value without description.
735
736         * API/JSValueRef.cpp:
737         (JSValueMakeSymbol):
738         * API/tests/testapi.cpp:
739         (TestAPI::symbolsTypeof):
740         (TestAPI::symbolsDescription):
741         (testCAPIViaCpp):
742         * dfg/DFGOperations.cpp:
743         * runtime/Symbol.cpp:
744         (JSC::Symbol::createWithDescription):
745         * runtime/Symbol.h:
746         * runtime/SymbolConstructor.cpp:
747         (JSC::callSymbol):
748
749 2019-05-06  Keith Rollin  <krollin@apple.com>
750
751         Temporarily disable generate-xcfilelists
752         https://bugs.webkit.org/show_bug.cgi?id=197619
753         <rdar://problem/50507392>
754
755         Reviewed by Alex Christensen.
756
757         We need to perform a significant update to the generate-xcfilelist
758         scripts. This work involves coordinated work with another facility. If
759         the work does not occur in tandem, the build will be broken. To avoid
760         this, disable the invoking of the scripts during the transition. The
761         checking will be restored once the new scripts are in place.
762
763         * Scripts/check-xcfilelists.sh:
764
765 2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>
766
767         [PlayStation] Fix build break since r244919
768         https://bugs.webkit.org/show_bug.cgi?id=197627
769
770         Reviewed by Ross Kirsling.
771
772         Bugfix for POSIX socket implementation and suppress warnings.
773
774         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
775         (Inspector::RemoteInspectorConnectionClient::didAccept):
776         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
777         (Inspector::Socket::getPort):
778
779 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
780
781         TemplateObject passed to template literal tags are not always identical for the same source location.
782         https://bugs.webkit.org/show_bug.cgi?id=190756
783
784         Reviewed by Saam Barati.
785
786         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
787         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
788
789         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
790         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
791
792         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
793         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
794         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
795         which maps source locations to cached site objects.
796
797         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
798         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
799         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
800
801         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
802         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
803         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
804         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
805         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
806         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
807         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
808         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
809         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
810         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
811         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
812         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
813         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
814         * Scripts/wkbuiltins/builtins_templates.py:
815         * bytecode/CodeBlock.cpp:
816         (JSC::CodeBlock::finishCreation):
817         (JSC::CodeBlock::setConstantRegisters):
818         * bytecode/CodeBlock.h:
819         * bytecode/UnlinkedFunctionExecutable.cpp:
820         (JSC::UnlinkedFunctionExecutable::link):
821         * bytecode/UnlinkedFunctionExecutable.h:
822         * bytecompiler/BytecodeGenerator.cpp:
823         (JSC::BytecodeGenerator::addTemplateObjectConstant):
824         (JSC::BytecodeGenerator::emitGetTemplateObject):
825         * bytecompiler/BytecodeGenerator.h:
826         * runtime/CachedTypes.cpp:
827         (JSC::CachedTemplateObjectDescriptor::encode):
828         (JSC::CachedTemplateObjectDescriptor::decode const):
829         (JSC::CachedJSValue::encode):
830         (JSC::CachedJSValue::decode const):
831         * runtime/EvalExecutable.cpp:
832         (JSC::EvalExecutable::ensureTemplateObjectMap):
833         (JSC::EvalExecutable::visitChildren):
834         * runtime/EvalExecutable.h:
835         * runtime/FunctionExecutable.cpp:
836         (JSC::FunctionExecutable::finishCreation):
837         (JSC::FunctionExecutable::visitChildren):
838         (JSC::FunctionExecutable::fromGlobalCode):
839         (JSC::FunctionExecutable::ensureRareDataSlow):
840         (JSC::FunctionExecutable::ensureTemplateObjectMap):
841         * runtime/FunctionExecutable.h:
842         * runtime/JSModuleRecord.cpp:
843         (JSC::JSModuleRecord::instantiateDeclarations):
844         * runtime/JSTemplateObjectDescriptor.cpp:
845         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
846         (JSC::JSTemplateObjectDescriptor::create):
847         * runtime/JSTemplateObjectDescriptor.h:
848         * runtime/ModuleProgramExecutable.cpp:
849         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
850         (JSC::ModuleProgramExecutable::visitChildren):
851         * runtime/ModuleProgramExecutable.h:
852         * runtime/ProgramExecutable.cpp:
853         (JSC::ProgramExecutable::ensureTemplateObjectMap):
854         (JSC::ProgramExecutable::visitChildren):
855         * runtime/ProgramExecutable.h:
856         * runtime/ScriptExecutable.cpp:
857         (JSC::ScriptExecutable::topLevelExecutable):
858         (JSC::ScriptExecutable::createTemplateObject):
859         (JSC::ScriptExecutable::ensureTemplateObjectMap):
860         * runtime/ScriptExecutable.h:
861         * tools/JSDollarVM.cpp:
862         (JSC::functionCreateBuiltin):
863         (JSC::functionDeleteAllCodeWhenIdle):
864         (JSC::JSDollarVM::finishCreation):
865
866 2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>
867
868         TypedArrays should not store properties that are canonical numeric indices
869         https://bugs.webkit.org/show_bug.cgi?id=197228
870         <rdar://problem/49557381>
871
872         Reviewed by Saam Barati.
873
874         According to the spec[1]:
875         - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
876         CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
877         functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
878         Infinity and -0.
879         - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
880         descriptor.
881         - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
882
883         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
884
885         * CMakeLists.txt:
886         * JavaScriptCore.xcodeproj/project.pbxproj:
887         * runtime/JSGenericTypedArrayViewInlines.h:
888         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
889         (JSC::JSGenericTypedArrayView<Adaptor>::put):
890         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
891         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
892         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
893         * runtime/PropertyName.h:
894         (JSC::isCanonicalNumericIndexString):
895
896 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
897
898         [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
899         https://bugs.webkit.org/show_bug.cgi?id=197584
900
901         Reviewed by Saam Barati.
902
903         In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
904         However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
905         and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
906         just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
907         This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
908
909         The example is like this.
910
911             a:  SomeValueNode
912              :  MovHint(@a, loc10)
913             b:  SetLocal(@a, loc10)
914                 ...
915             c:  MovHint(@a, loc10)
916
917         Then, this will be converted to the style in SSA conversion.
918
919             a:  SomeValueNode
920              :  KillStack(loc10)
921             b:  PutStack(@a, loc10)
922                 ...
923             c:  KillStack(loc10)
924
925         Then, @b will be removed later since @c kills it.
926
927         * dfg/DFGByteCodeParser.cpp:
928         (JSC::DFG::ByteCodeParser::inlineCall):
929         * heap/MarkedBlock.cpp:
930         (JSC::MarkedBlock::MarkedBlock):
931         (JSC::MarkedBlock::Handle::stopAllocating):
932         (JSC::MarkedBlock::Handle::resumeAllocating):
933         (JSC::MarkedBlock::aboutToMarkSlow):
934         (JSC::MarkedBlock::Handle::didConsumeFreeList):
935
936 2019-05-03  Devin Rousso  <drousso@apple.com>
937
938         Web Inspector: DOM: rename "low power" to "display composited"
939         https://bugs.webkit.org/show_bug.cgi?id=197296
940
941         Reviewed by Joseph Pecoraro.
942
943         Removed specific ChangeLog entries since it is almost entirely mechanical changes.
944
945         * inspector/protocol/DOM.json:
946
947 2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>
948
949         [WinCairo] Implement and enable RemoteInspector Server.
950         https://bugs.webkit.org/show_bug.cgi?id=197432
951
952         Reviewed by Ross Kirsling.
953
954         Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
955         for experimental feature.
956
957         Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
958         for flexible configuration.
959
960         * PlatformWin.cmake:
961         * inspector/remote/RemoteInspector.h:
962         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
963         (Inspector::RemoteInspectorConnectionClient::didAccept):
964         * inspector/remote/socket/RemoteInspectorServer.cpp:
965         (Inspector::RemoteInspectorServer::connect):
966         (Inspector::RemoteInspectorServer::listenForTargets):
967         (Inspector::RemoteInspectorServer::didAccept):
968         (Inspector::RemoteInspectorServer::dispatchMap):
969         (Inspector::RemoteInspectorServer::start):
970         (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
971         * inspector/remote/socket/RemoteInspectorServer.h:
972         (Inspector::RemoteInspectorServer::RemoteInspectorServer):
973         * inspector/remote/socket/RemoteInspectorSocket.cpp:
974         (Inspector::RemoteInspector::RemoteInspector):
975         (Inspector::RemoteInspector::dispatchMap):
976         (Inspector::RemoteInspector::start):
977         (Inspector::RemoteInspector::stopInternal):
978         (Inspector::RemoteInspector::setServerPort):
979         * inspector/remote/socket/RemoteInspectorSocket.h:
980         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
981         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
982         (Inspector::RemoteInspectorSocketEndpoint::getPort const):
983         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
984         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
985         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
986         (Inspector::Socket::init): Added.
987         (Inspector::Socket::listen): Signature changed.
988         (Inspector::Socket::getPort): Added.
989         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
990         (Inspector::Socket::init):
991         (Inspector::Socket::Socket::Socket):
992         (Inspector::Socket::Socket::~Socket):
993         (Inspector::Socket::Socket::close):
994         (Inspector::Socket::Socket::operator PlatformSocketType const):
995         (Inspector::Socket::Socket::operator bool const):
996         (Inspector::Socket::Socket::leak):
997         (Inspector::Socket::Socket::create):
998         (Inspector::Socket::setOpt):
999         (Inspector::Socket::setOptEnabled):
1000         (Inspector::Socket::enableOpt):
1001         (Inspector::Socket::connectTo):
1002         (Inspector::Socket::bindAndListen):
1003         (Inspector::Socket::connect):
1004         (Inspector::Socket::listen):
1005         (Inspector::Socket::accept):
1006         (Inspector::Socket::createPair):
1007         (Inspector::Socket::setup):
1008         (Inspector::Socket::isValid):
1009         (Inspector::Socket::isListening):
1010         (Inspector::Socket::getPort):
1011         (Inspector::Socket::read):
1012         (Inspector::Socket::write):
1013         (Inspector::Socket::close):
1014         (Inspector::Socket::preparePolling):
1015         (Inspector::Socket::poll):
1016         (Inspector::Socket::isReadable):
1017         (Inspector::Socket::isWritable):
1018         (Inspector::Socket::markWaitingWritable):
1019         (Inspector::Socket::clearWaitingWritable):
1020
1021 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
1022
1023         [JSC] Generator CodeBlock generation should be idempotent
1024         https://bugs.webkit.org/show_bug.cgi?id=197552
1025
1026         Reviewed by Keith Miller.
1027
1028         ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
1029         granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
1030         recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
1031         different and it does not have the same state previously used. If we resume the previously created generator with the newly
1032         generator function, resuming is messed up.
1033
1034             function* gen () { ... }
1035             var g = gen();
1036             g.next();
1037
1038             // CodeBlock is destroyed & Debugger is enabled.
1039
1040             g.next();
1041
1042         In this patch,
1043
1044         1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
1045            instructions every time we regenerate the CodeBlock.
1046
1047         2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
1048            and pass them as a parameter, OptionSet<CodeGeneratorMode>.
1049
1050         3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
1051            even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
1052
1053         * bytecode/BytecodeGeneratorification.cpp:
1054         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
1055         (JSC::BytecodeGeneratorification::run):
1056         * bytecode/CodeBlock.cpp:
1057         (JSC::CodeBlock::finishCreation):
1058         (JSC::CodeBlock::setConstantRegisters):
1059         * bytecode/UnlinkedCodeBlock.cpp:
1060         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1061         * bytecode/UnlinkedCodeBlock.h:
1062         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
1063         (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
1064         (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
1065         (JSC::UnlinkedCodeBlock::codeGenerationMode const):
1066         * bytecode/UnlinkedEvalCodeBlock.h:
1067         * bytecode/UnlinkedFunctionCodeBlock.h:
1068         * bytecode/UnlinkedFunctionExecutable.cpp:
1069         (JSC::generateUnlinkedFunctionCodeBlock):
1070         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1071         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1072         * bytecode/UnlinkedFunctionExecutable.h:
1073         * bytecode/UnlinkedGlobalCodeBlock.h:
1074         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
1075         * bytecode/UnlinkedModuleProgramCodeBlock.h:
1076         * bytecode/UnlinkedProgramCodeBlock.h:
1077         * bytecompiler/BytecodeGenerator.cpp:
1078         (JSC::BytecodeGenerator::BytecodeGenerator):
1079         (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
1080         (JSC::BytecodeGenerator::emitProfileType):
1081         (JSC::BytecodeGenerator::emitProfileControlFlow):
1082         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1083         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1084         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1085         (JSC::BytecodeGenerator::emitCall):
1086         (JSC::BytecodeGenerator::emitCallVarargs):
1087         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
1088         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
1089         (JSC::BytecodeGenerator::emitDebugHook):
1090         * bytecompiler/BytecodeGenerator.h:
1091         (JSC::BytecodeGenerator::generate):
1092         (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
1093         (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
1094         (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
1095         * bytecompiler/NodesCodegen.cpp:
1096         (JSC::PrefixNode::emitResolve):
1097         (JSC::EmptyVarExpression::emitBytecode):
1098         (JSC::ReturnNode::emitBytecode):
1099         (JSC::FunctionNode::emitBytecode):
1100         * parser/ParserModes.h:
1101         (): Deleted.
1102         * parser/SourceCodeKey.h:
1103         (JSC::SourceCodeFlags::SourceCodeFlags):
1104         (JSC::SourceCodeKey::SourceCodeKey):
1105         * runtime/CachedTypes.cpp:
1106         (JSC::CachedCodeBlock::isClassContext const):
1107         (JSC::CachedCodeBlock::codeGenerationMode const):
1108         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1109         (JSC::CachedCodeBlock<CodeBlockType>::encode):
1110         (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
1111         * runtime/CodeCache.cpp:
1112         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
1113         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
1114         (JSC::CodeCache::getUnlinkedEvalCodeBlock):
1115         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
1116         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
1117         (JSC::generateUnlinkedCodeBlockForFunctions):
1118         (JSC::sourceCodeKeyForSerializedBytecode):
1119         (JSC::sourceCodeKeyForSerializedProgram):
1120         (JSC::sourceCodeKeyForSerializedModule):
1121         (JSC::serializeBytecode):
1122         * runtime/CodeCache.h:
1123         (JSC::generateUnlinkedCodeBlockImpl):
1124         (JSC::generateUnlinkedCodeBlock):
1125         * runtime/Completion.cpp:
1126         (JSC::generateProgramBytecode):
1127         (JSC::generateModuleBytecode):
1128         * runtime/DirectEvalExecutable.cpp:
1129         (JSC::DirectEvalExecutable::create):
1130         * runtime/IndirectEvalExecutable.cpp:
1131         (JSC::IndirectEvalExecutable::create):
1132         * runtime/JSGlobalObject.h:
1133         (JSC::JSGlobalObject::defaultCodeGenerationMode const):
1134         * runtime/ModuleProgramExecutable.cpp:
1135         (JSC::ModuleProgramExecutable::create):
1136         * runtime/ProgramExecutable.cpp:
1137         (JSC::ProgramExecutable::initializeGlobalProperties):
1138         * runtime/ScriptExecutable.cpp:
1139         (JSC::ScriptExecutable::ScriptExecutable):
1140         (JSC::ScriptExecutable::newCodeBlockFor):
1141         * runtime/ScriptExecutable.h:
1142         * tools/JSDollarVM.cpp:
1143         (JSC::changeDebuggerModeWhenIdle):
1144         (JSC::functionEnableDebuggerModeWhenIdle):
1145         (JSC::functionDisableDebuggerModeWhenIdle):
1146
1147 2019-05-03  Devin Rousso  <drousso@apple.com>
1148
1149         Web Inspector: Record actions performed on WebGL2RenderingContext
1150         https://bugs.webkit.org/show_bug.cgi?id=176008
1151         <rdar://problem/34213884>
1152
1153         Reviewed by Joseph Pecoraro.
1154
1155         * inspector/protocol/Recording.json:
1156         * inspector/scripts/codegen/generator.py:
1157         Add `canvas-webgl2` as a `Type`.
1158
1159 2019-05-03  Commit Queue  <commit-queue@webkit.org>
1160
1161         Unreviewed, rolling out r244881.
1162         https://bugs.webkit.org/show_bug.cgi?id=197559
1163
1164         Breaks compilation of jsconly on linux, breaking compilation
1165         for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
1166         guijemont on #webkit).
1167
1168         Reverted changeset:
1169
1170         "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
1171         WEBKIT_COPY_FILES"
1172         https://bugs.webkit.org/show_bug.cgi?id=197174
1173         https://trac.webkit.org/changeset/244881
1174
1175 2019-05-02  Don Olmstead  <don.olmstead@sony.com>
1176
1177         [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
1178         https://bugs.webkit.org/show_bug.cgi?id=197174
1179
1180         Reviewed by Alex Christensen.
1181
1182         Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
1183         for framework headers explicit.
1184
1185         * CMakeLists.txt:
1186
1187 2019-05-02  Michael Saboff  <msaboff@apple.com>
1188
1189         Unreviewed rollout of r244862.
1190
1191         * runtime/JSObject.cpp:
1192         (JSC::JSObject::getOwnPropertyDescriptor):
1193
1194 2019-05-01  Saam barati  <sbarati@apple.com>
1195
1196         Baseline JIT should do argument value profiling after checking for stack overflow
1197         https://bugs.webkit.org/show_bug.cgi?id=197052
1198         <rdar://problem/50009602>
1199
1200         Reviewed by Yusuke Suzuki.
1201
1202         Otherwise, we may do value profiling without running a write barrier, which
1203         is against the rules of how we do value profiling.
1204
1205         * jit/JIT.cpp:
1206         (JSC::JIT::compileWithoutLinking):
1207
1208 2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>
1209
1210         [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
1211         https://bugs.webkit.org/show_bug.cgi?id=197405
1212
1213         Reviewed by Saam Barati.
1214
1215         When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
1216         Because Inlining can switch on executable, we could have a graph like this.
1217
1218         BB#0
1219             ...
1220             30: GetSetter
1221             31: MovHint(loc10)
1222             32: SetLocal(loc10)
1223             33: MovHint(loc9)
1224             34: SetLocal(loc9)
1225             ...
1226             37: GetExecutable(@30)
1227             ...
1228             41: Switch(@37)
1229
1230         BB#2
1231             42: GetLocal(loc12, bc#7 of caller)
1232             ...
1233             --> callee: loc9 and loc10 are arguments of callee.
1234               ...
1235               <HERE, exit to callee, loc9 and loc10 are required in the bytecode>
1236
1237         When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
1238         However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
1239
1240         This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
1241         We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
1242
1243         Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
1244         inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
1245         the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
1246         catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
1247         to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
1248         This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
1249
1250         * dfg/DFGByteCodeParser.cpp:
1251         (JSC::DFG::ByteCodeParser::inlineCall):
1252         (JSC::DFG::ByteCodeParser::handleGetById):
1253         (JSC::DFG::ByteCodeParser::handlePutById):
1254         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
1255         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
1256
1257 2019-05-01  Michael Saboff  <msaboff@apple.com>
1258
1259         ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
1260         https://bugs.webkit.org/show_bug.cgi?id=197485
1261
1262         Reviewed by Saam Barati.
1263
1264         Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
1265
1266         * runtime/JSObject.cpp:
1267         (JSC::JSObject::getOwnPropertyDescriptor):
1268
1269 2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>
1270
1271         RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
1272         https://bugs.webkit.org/show_bug.cgi?id=197439
1273
1274         Reviewed by Devin Rousso.
1275
1276         On non-Cocoa platforms, automatic inspection is not currently implemented,
1277         so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
1278         This logic already existed in three places, so refactor it into a common private method
1279         and allow our websocket-based RWI implementation to make use of it too.
1280
1281         * inspector/remote/RemoteInspector.cpp:
1282         (Inspector::RemoteInspector::updateTarget):
1283         (Inspector::RemoteInspector::updateTargetMap):
1284         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1285         * inspector/remote/RemoteInspector.h:
1286         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1287         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1288         * inspector/remote/glib/RemoteInspectorGlib.cpp:
1289         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
1290         * inspector/remote/socket/RemoteInspectorSocket.cpp:
1291         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
1292
1293 2019-05-01  Darin Adler  <darin@apple.com>
1294
1295         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
1296         https://bugs.webkit.org/show_bug.cgi?id=195535
1297
1298         Reviewed by Alexey Proskuryakov.
1299
1300         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
1301
1302         * API/JSStringRef.cpp:
1303         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
1304         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
1305         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
1306         since that is the default. Also updated for changes to CompletionResult.
1307
1308         * runtime/JSGlobalObjectFunctions.cpp:
1309         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
1310         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
1311         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
1312         equivalents, since these macros from ICU are correct and efficient.
1313
1314         * wasm/WasmParser.h:
1315         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
1316         convertUTF8ToUTF16.
1317
1318 2019-05-01  Shawn Roberts  <sroberts@apple.com>
1319
1320         Unreviewed, rolling out r244821.
1321
1322         Causing
1323
1324         Reverted changeset:
1325
1326         "WebKit has too much of its own UTF-8 code and should rely
1327         more on ICU's UTF-8 support"
1328         https://bugs.webkit.org/show_bug.cgi?id=195535
1329         https://trac.webkit.org/changeset/244821
1330
1331 2019-04-29  Darin Adler  <darin@apple.com>
1332
1333         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
1334         https://bugs.webkit.org/show_bug.cgi?id=195535
1335
1336         Reviewed by Alexey Proskuryakov.
1337
1338         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
1339
1340         * API/JSStringRef.cpp:
1341         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
1342         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
1343         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
1344         since that is the default. Also updated for changes to CompletionResult.
1345
1346         * runtime/JSGlobalObjectFunctions.cpp:
1347         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
1348         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
1349         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
1350         equivalents, since these macros from ICU are correct and efficient.
1351
1352         * wasm/WasmParser.h:
1353         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
1354         convertUTF8ToUTF16.
1355
1356 2019-04-30  Commit Queue  <commit-queue@webkit.org>
1357
1358         Unreviewed, rolling out r244806.
1359         https://bugs.webkit.org/show_bug.cgi?id=197446
1360
1361         Causing Test262 and JSC test failures on multiple builds
1362         (Requested by ShawnRoberts on #webkit).
1363
1364         Reverted changeset:
1365
1366         "TypeArrays should not store properties that are canonical
1367         numeric indices"
1368         https://bugs.webkit.org/show_bug.cgi?id=197228
1369         https://trac.webkit.org/changeset/244806
1370
1371 2019-04-30  Saam barati  <sbarati@apple.com>
1372
1373         CodeBlock::m_instructionCount is wrong
1374         https://bugs.webkit.org/show_bug.cgi?id=197304
1375
1376         Reviewed by Yusuke Suzuki.
1377
1378         What we were calling instructionCount() was wrong, as evidenced by
1379         us using it incorrectly both in the sampling profiler and when we
1380         dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
1381         instructionCount() was probably valid to do bounds checks against.
1382         However, this is no longer the case. This patch renames what we called
1383         instructionCount() to bytecodeCost(). It is now only used to make decisions
1384         about inlining and tier up heuristics. I've also named options related to
1385         this appropriately.
1386         
1387         This patch also introduces instructionsSize(). The result of this method
1388         is valid to do bounds checks against.
1389
1390         * bytecode/CodeBlock.cpp:
1391         (JSC::CodeBlock::dumpAssumingJITType const):
1392         (JSC::CodeBlock::CodeBlock):
1393         (JSC::CodeBlock::finishCreation):
1394         (JSC::CodeBlock::optimizationThresholdScalingFactor):
1395         (JSC::CodeBlock::predictedMachineCodeSize):
1396         * bytecode/CodeBlock.h:
1397         (JSC::CodeBlock::instructionsSize const):
1398         (JSC::CodeBlock::bytecodeCost const):
1399         (JSC::CodeBlock::instructionCount const): Deleted.
1400         * dfg/DFGByteCodeParser.cpp:
1401         (JSC::DFG::ByteCodeParser::inliningCost):
1402         (JSC::DFG::ByteCodeParser::getInliningBalance):
1403         * dfg/DFGCapabilities.cpp:
1404         (JSC::DFG::mightCompileEval):
1405         (JSC::DFG::mightCompileProgram):
1406         (JSC::DFG::mightCompileFunctionForCall):
1407         (JSC::DFG::mightCompileFunctionForConstruct):
1408         (JSC::DFG::mightInlineFunctionForCall):
1409         (JSC::DFG::mightInlineFunctionForClosureCall):
1410         (JSC::DFG::mightInlineFunctionForConstruct):
1411         * dfg/DFGCapabilities.h:
1412         (JSC::DFG::isSmallEnoughToInlineCodeInto):
1413         * dfg/DFGDisassembler.cpp:
1414         (JSC::DFG::Disassembler::dumpHeader):
1415         * dfg/DFGDriver.cpp:
1416         (JSC::DFG::compileImpl):
1417         * dfg/DFGPlan.cpp:
1418         (JSC::DFG::Plan::compileInThread):
1419         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1420         (JSC::DFG::TierUpCheckInjectionPhase::run):
1421         * ftl/FTLCapabilities.cpp:
1422         (JSC::FTL::canCompile):
1423         * ftl/FTLCompile.cpp:
1424         (JSC::FTL::compile):
1425         * ftl/FTLLink.cpp:
1426         (JSC::FTL::link):
1427         * jit/JIT.cpp:
1428         (JSC::JIT::link):
1429         * jit/JITDisassembler.cpp:
1430         (JSC::JITDisassembler::dumpHeader):
1431         * llint/LLIntSlowPaths.cpp:
1432         (JSC::LLInt::shouldJIT):
1433         * profiler/ProfilerBytecodes.cpp:
1434         (JSC::Profiler::Bytecodes::Bytecodes):
1435         * runtime/Options.h:
1436         * runtime/SamplingProfiler.cpp:
1437         (JSC::tryGetBytecodeIndex):
1438         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1439
1440 2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>
1441
1442         TypeArrays should not store properties that are canonical numeric indices
1443         https://bugs.webkit.org/show_bug.cgi?id=197228
1444         <rdar://problem/49557381>
1445
1446         Reviewed by Darin Adler.
1447
1448         According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
1449         if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
1450         and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
1451         like NaN, Infinity and -0.
1452
1453         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
1454
1455         * CMakeLists.txt:
1456         * JavaScriptCore.xcodeproj/project.pbxproj:
1457         * runtime/JSGenericTypedArrayViewInlines.h:
1458         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
1459         (JSC::JSGenericTypedArrayView<Adaptor>::put):
1460         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
1461         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
1462         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
1463         * runtime/JSTypedArrays.cpp:
1464         * runtime/PropertyName.h:
1465         (JSC::canonicalNumericIndexString):
1466
1467 2019-04-30  Brian Burg  <bburg@apple.com>
1468
1469         Web Automation: use a more informative key to indicate automation availability
1470         https://bugs.webkit.org/show_bug.cgi?id=197377
1471         <rdar://problem/50258069>
1472
1473         Reviewed by Devin Rousso.
1474
1475         The existing WIRAutomationEnabledKey does not encode uncertainty.
1476         Add a new key that provides an 'Unknown' state, and prefer to use it.
1477
1478         Since an application's initial listing is sent from a background dispatch queue
1479         on Cocoa platforms, this can race with main thread initialization that sets up
1480         RemoteInspector::Client. Therefore, the initial listing may not properly represent
1481         the client's capabilites because the client is not yet available. Allowing for
1482         an "Unknown" state that is later upgraded to Available or Not Available makes it
1483         possible to work around this potential race.
1484
1485         * inspector/remote/RemoteInspectorConstants.h:
1486         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1487         (Inspector::RemoteInspector::pushListingsNow):
1488
1489 2019-04-30  Keith Miller  <keith_miller@apple.com>
1490
1491         Fix failing ARM64E wasm tests
1492         https://bugs.webkit.org/show_bug.cgi?id=197420
1493
1494         Reviewed by Saam Barati.
1495
1496         This patch fixes a bug in the slow path of our JS->Wasm IC bridge
1497         where we wouldn't untag the link register before tail calling.
1498
1499         Additionally, this patch fixes a broken assert when using setting
1500         Options::useTailCalls=false.
1501
1502         * bytecompiler/BytecodeGenerator.cpp:
1503         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
1504         * wasm/js/WebAssemblyFunction.cpp:
1505         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1506
1507 2019-04-29  Saam Barati  <sbarati@apple.com>
1508
1509         Make JITType an enum class
1510         https://bugs.webkit.org/show_bug.cgi?id=197394
1511
1512         Reviewed by Yusuke Suzuki.
1513
1514         This makes the code more easily searchable.
1515
1516         * bytecode/CallLinkStatus.cpp:
1517         (JSC::CallLinkStatus::computeFor):
1518         * bytecode/CodeBlock.cpp:
1519         (JSC::CodeBlock::dumpAssumingJITType const):
1520         (JSC::CodeBlock::specialOSREntryBlockOrNull):
1521         (JSC::timeToLive):
1522         (JSC::CodeBlock::propagateTransitions):
1523         (JSC::CodeBlock::baselineAlternative):
1524         (JSC::CodeBlock::baselineVersion):
1525         (JSC::CodeBlock::hasOptimizedReplacement):
1526         (JSC::CodeBlock::noticeIncomingCall):
1527         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
1528         (JSC::CodeBlock::tallyFrequentExitSites):
1529         (JSC::CodeBlock::frameRegisterCount):
1530         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
1531         * bytecode/CodeBlock.h:
1532         (JSC::CodeBlock::jitType const):
1533         (JSC::CodeBlock::hasBaselineJITProfiling const):
1534         * bytecode/CodeBlockWithJITType.h:
1535         (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
1536         * bytecode/DeferredSourceDump.cpp:
1537         (JSC::DeferredSourceDump::DeferredSourceDump):
1538         * bytecode/DeferredSourceDump.h:
1539         * bytecode/ExitingJITType.h:
1540         (JSC::exitingJITTypeFor):
1541         * bytecode/InlineCallFrame.h:
1542         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
1543         * dfg/DFGByteCodeParser.cpp:
1544         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1545         * dfg/DFGDisassembler.cpp:
1546         (JSC::DFG::Disassembler::dumpHeader):
1547         * dfg/DFGDriver.cpp:
1548         (JSC::DFG::compileImpl):
1549         * dfg/DFGGraph.cpp:
1550         (JSC::DFG::Graph::dump):
1551         * dfg/DFGJITCode.cpp:
1552         (JSC::DFG::JITCode::JITCode):
1553         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
1554         (JSC::DFG::JITCode::optimizeNextInvocation):
1555         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
1556         (JSC::DFG::JITCode::optimizeAfterWarmUp):
1557         (JSC::DFG::JITCode::optimizeSoon):
1558         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
1559         (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
1560         * dfg/DFGJITFinalizer.cpp:
1561         (JSC::DFG::JITFinalizer::finalize):
1562         (JSC::DFG::JITFinalizer::finalizeFunction):
1563         * dfg/DFGOSREntry.cpp:
1564         (JSC::DFG::prepareOSREntry):
1565         (JSC::DFG::prepareCatchOSREntry):
1566         * dfg/DFGOSRExit.cpp:
1567         (JSC::DFG::OSRExit::executeOSRExit):
1568         (JSC::DFG::reifyInlinedCallFrames):
1569         (JSC::DFG::OSRExit::compileOSRExit):
1570         * dfg/DFGOSRExitCompilerCommon.cpp:
1571         (JSC::DFG::handleExitCounts):
1572         (JSC::DFG::reifyInlinedCallFrames):
1573         (JSC::DFG::adjustAndJumpToTarget):
1574         * dfg/DFGOSRExitCompilerCommon.h:
1575         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
1576         * dfg/DFGOperations.cpp:
1577         * dfg/DFGThunks.cpp:
1578         (JSC::DFG::osrExitGenerationThunkGenerator):
1579         * dfg/DFGVariableEventStream.cpp:
1580         (JSC::DFG::VariableEventStream::reconstruct const):
1581         * ftl/FTLCompile.cpp:
1582         (JSC::FTL::compile):
1583         * ftl/FTLJITCode.cpp:
1584         (JSC::FTL::JITCode::JITCode):
1585         * ftl/FTLJITFinalizer.cpp:
1586         (JSC::FTL::JITFinalizer::finalizeCommon):
1587         * ftl/FTLLink.cpp:
1588         (JSC::FTL::link):
1589         * ftl/FTLOSRExitCompiler.cpp:
1590         (JSC::FTL::compileFTLOSRExit):
1591         * ftl/FTLThunks.cpp:
1592         (JSC::FTL::genericGenerationThunkGenerator):
1593         * interpreter/CallFrame.cpp:
1594         (JSC::CallFrame::callSiteBitsAreBytecodeOffset const):
1595         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex const):
1596         * interpreter/StackVisitor.cpp:
1597         (JSC::StackVisitor::Frame::dump const):
1598         * jit/AssemblyHelpers.h:
1599         (JSC::AssemblyHelpers::AssemblyHelpers):
1600         * jit/JIT.cpp:
1601         (JSC::JIT::link):
1602         * jit/JITCode.cpp:
1603         (JSC::JITCode::typeName):
1604         (WTF::printInternal):
1605         * jit/JITCode.h:
1606         (JSC::JITCode::bottomTierJIT):
1607         (JSC::JITCode::topTierJIT):
1608         (JSC::JITCode::nextTierJIT):
1609         (JSC::JITCode::isExecutableScript):
1610         (JSC::JITCode::couldBeInterpreted):
1611         (JSC::JITCode::isJIT):
1612         (JSC::JITCode::isOptimizingJIT):
1613         (JSC::JITCode::isBaselineCode):
1614         (JSC::JITCode::jitTypeFor):
1615         * jit/JITDisassembler.cpp:
1616         (JSC::JITDisassembler::dumpHeader):
1617         * jit/JITOperations.cpp:
1618         * jit/JITThunks.cpp:
1619         (JSC::JITThunks::hostFunctionStub):
1620         * jit/JITToDFGDeferredCompilationCallback.cpp:
1621         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1622         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1623         * jit/JITWorklist.cpp:
1624         (JSC::JITWorklist::compileLater):
1625         (JSC::JITWorklist::compileNow):
1626         * jit/Repatch.cpp:
1627         (JSC::readPutICCallTarget):
1628         (JSC::ftlThunkAwareRepatchCall):
1629         * llint/LLIntEntrypoint.cpp:
1630         (JSC::LLInt::setFunctionEntrypoint):
1631         (JSC::LLInt::setEvalEntrypoint):
1632         (JSC::LLInt::setProgramEntrypoint):
1633         (JSC::LLInt::setModuleProgramEntrypoint):
1634         * llint/LLIntSlowPaths.cpp:
1635         (JSC::LLInt::jitCompileAndSetHeuristics):
1636         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1637         * runtime/SamplingProfiler.cpp:
1638         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1639         * runtime/SamplingProfiler.h:
1640         * runtime/VM.cpp:
1641         (JSC::jitCodeForCallTrampoline):
1642         (JSC::jitCodeForConstructTrampoline):
1643         * tools/CodeProfile.cpp:
1644         (JSC::CodeProfile::sample):
1645         * tools/JSDollarVM.cpp:
1646         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
1647         (JSC::CallerFrameJITTypeFunctor::jitType):
1648         (JSC::functionLLintTrue):
1649         (JSC::functionJITTrue):
1650
1651 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1652
1653         Unreivewed, fix FTL implementation of r244760
1654         https://bugs.webkit.org/show_bug.cgi?id=197362
1655
1656         Reviewed by Saam Barati.
1657
1658         Looked with Saam. ValueFromBlock from double case block was overridden by NaN thing now.
1659
1660         * ftl/FTLLowerDFGToB3.cpp:
1661         (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
1662
1663 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1664
1665         normalizeMapKey should normalize NaN to one PureNaN bit pattern to make MapHash same
1666         https://bugs.webkit.org/show_bug.cgi?id=197362
1667
1668         Reviewed by Saam Barati.
1669
1670         Our Map/Set's hash algorithm relies on the bit pattern of JSValue. So our Map/Set has
1671         normalization of the key, which normalizes Int32 / Double etc. But we did not normalize
1672         pure NaNs into one canonicalized pure NaN. So we end up having multiple different pure NaNs
1673         in one Map/Set. This patch normalizes NaN into one jsNaN(), which uses PNaN for the representation.
1674
1675         * dfg/DFGSpeculativeJIT.cpp:
1676         (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
1677         * ftl/FTLLowerDFGToB3.cpp:
1678         (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
1679         * runtime/HashMapImpl.h:
1680         (JSC::normalizeMapKey):
1681
1682 2019-04-29  Alex Christensen  <achristensen@webkit.org>
1683
1684         <rdar://problem/50299396> Fix internal High Sierra build
1685         https://bugs.webkit.org/show_bug.cgi?id=197388
1686
1687         * Configurations/Base.xcconfig:
1688
1689 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1690
1691         JITStubRoutineSet wastes 180KB of HashTable capacity on can.com
1692         https://bugs.webkit.org/show_bug.cgi?id=186732
1693
1694         Reviewed by Saam Barati.
1695
1696         Our current mechanism of JITStubRoutineSet consumes more memory than needed. Basically we have HashMap<uintptr_t, StubRoutine*> and register
1697         each executable address by 16 byte to this entry. So if your StubRoutine has 128bytes, it just adds 8 entries to this hash table.
1698         In Gmail, we see a ~2MB table size.
1699
1700         Instead, this patch uses Vector<pair<uintptr_t, StubRoutine*>> and performs binary search onto this sorted vector. Before conservative
1701         scanning, we sort this vector. And doing binary search with the sorted vector to find executing stub routines from the conservative roots.
1702         This vector includes uintptr_t startAddress to make binary searching fast.
1703
1704         Large amount of conservative scan should be filtered by range check, so I think binary search here is OK, but we can decide based on what the
1705         performance bots say.
1706
1707         * heap/Heap.cpp:
1708         (JSC::Heap::addCoreConstraints):
1709         * heap/JITStubRoutineSet.cpp:
1710         (JSC::JITStubRoutineSet::~JITStubRoutineSet):
1711         (JSC::JITStubRoutineSet::add):
1712         (JSC::JITStubRoutineSet::prepareForConservativeScan):
1713         (JSC::JITStubRoutineSet::clearMarks):
1714         (JSC::JITStubRoutineSet::markSlow):
1715         (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
1716         (JSC::JITStubRoutineSet::traceMarkedStubRoutines):
1717         * heap/JITStubRoutineSet.h:
1718         (JSC::JITStubRoutineSet::mark):
1719         (JSC::JITStubRoutineSet::prepareForConservativeScan):
1720         (JSC::JITStubRoutineSet::size const): Deleted.
1721         (JSC::JITStubRoutineSet::at const): Deleted.
1722
1723 2019-04-29  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1724
1725         [Win] Add flag to enable version information stamping and disable by default.
1726         https://bugs.webkit.org/show_bug.cgi?id=197249
1727         <rdar://problem/50224412>
1728
1729         Reviewed by Ross Kirsling.
1730
1731         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
1732         Then enable it by default on AppleWin.
1733
1734         * CMakeLists.txt:
1735
1736 2019-04-26  Keith Rollin  <krollin@apple.com>
1737
1738         Enable new build rule for post-processing headers when using XCBuild
1739         https://bugs.webkit.org/show_bug.cgi?id=197340
1740         <rdar://problem/50226685>
1741
1742         Reviewed by Brent Fulgham.
1743
1744         In Bug 197116, we conditionally disabled the old method for
1745         post-processing header files when we are using the new XCBuild build
1746         system. This check-in conditionally enables the new post-processing
1747         facility. Note that the old system is disabled and the new system
1748         enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
1749         to YES.
1750
1751         * Configurations/JavaScriptCore.xcconfig:
1752
1753 2019-04-26  Jessie Berlin  <jberlin@webkit.org>
1754
1755         Add new mac target numbers
1756         https://bugs.webkit.org/show_bug.cgi?id=197313
1757
1758         Reviewed by Alex Christensen.
1759
1760         * Configurations/Version.xcconfig:
1761         * Configurations/WebKitTargetConditionals.xcconfig:
1762
1763 2019-04-26  Commit Queue  <commit-queue@webkit.org>
1764
1765         Unreviewed, rolling out r244708.
1766         https://bugs.webkit.org/show_bug.cgi?id=197334
1767
1768         "Broke the debug build" (Requested by rmorisset on #webkit).
1769
1770         Reverted changeset:
1771
1772         "All prototypes should call didBecomePrototype()"
1773         https://bugs.webkit.org/show_bug.cgi?id=196315
1774         https://trac.webkit.org/changeset/244708
1775
1776 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
1777
1778         [CMake] Add WEBKIT_EXECUTABLE macro
1779         https://bugs.webkit.org/show_bug.cgi?id=197206
1780
1781         Reviewed by Konstantin Tokarev.
1782
1783         Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.
1784
1785         * b3/air/testair.cpp:
1786         * b3/testb3.cpp:
1787         * dfg/testdfg.cpp:
1788         * shell/CMakeLists.txt:
1789         * shell/PlatformGTK.cmake:
1790         * shell/PlatformJSCOnly.cmake: Removed.
1791         * shell/PlatformMac.cmake:
1792         * shell/PlatformPlayStation.cmake:
1793         * shell/PlatformWPE.cmake:
1794         * shell/PlatformWin.cmake:
1795
1796 2019-04-25  Yusuke Suzuki  <ysuzuki@apple.com>
1797
1798         [JSC] linkPolymorphicCall now does GC
1799         https://bugs.webkit.org/show_bug.cgi?id=197306
1800
1801         Reviewed by Saam Barati.
1802
1803         Previously, we assumed that linkPolymorphicCall does not perform allocations. So we put CallVariant into a Vector<>.
1804         But now, WebAssemblyFunction's entrypoint generation can allocate JSToWasmICCallee and cause GC. Since CallLinkInfo
1805         does not hold these cells, they can be collected, and we will see dead cells in the middle of linkPolymorphicCall.
1806         We should defer GC for a while in linkPolymorphicCall. We use DeferGCForAWhile instead of DeferGC because the
1807         caller "operationLinkPolymorphicCall" assumes that this function does not cause GC.
1808
1809         * jit/Repatch.cpp:
1810         (JSC::linkPolymorphicCall):
1811
1812 2019-04-26  Robin Morisset  <rmorisset@apple.com>
1813
1814         All prototypes should call didBecomePrototype()
1815         https://bugs.webkit.org/show_bug.cgi?id=196315
1816
1817         Reviewed by Saam Barati.
1818
1819         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
1820
1821         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
1822         create structures with invalid prototypes.
1823         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
1824         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
1825
1826         * runtime/BigIntPrototype.cpp:
1827         (JSC::BigIntPrototype::finishCreation):
1828         * runtime/BooleanPrototype.cpp:
1829         (JSC::BooleanPrototype::finishCreation):
1830         * runtime/DatePrototype.cpp:
1831         (JSC::DatePrototype::finishCreation):
1832         * runtime/ErrorConstructor.cpp:
1833         (JSC::ErrorConstructor::finishCreation):
1834         * runtime/ErrorPrototype.cpp:
1835         (JSC::ErrorPrototype::finishCreation):
1836         * runtime/FunctionConstructor.cpp:
1837         (JSC::FunctionConstructor::finishCreation):
1838         * runtime/FunctionPrototype.cpp:
1839         (JSC::FunctionPrototype::finishCreation):
1840         * runtime/IntlCollatorPrototype.cpp:
1841         (JSC::IntlCollatorPrototype::finishCreation):
1842         * runtime/IntlDateTimeFormatPrototype.cpp:
1843         (JSC::IntlDateTimeFormatPrototype::finishCreation):
1844         * runtime/IntlNumberFormatPrototype.cpp:
1845         (JSC::IntlNumberFormatPrototype::finishCreation):
1846         * runtime/IntlPluralRulesPrototype.cpp:
1847         (JSC::IntlPluralRulesPrototype::finishCreation):
1848         * runtime/JSArrayBufferPrototype.cpp:
1849         (JSC::JSArrayBufferPrototype::finishCreation):
1850         * runtime/JSDataViewPrototype.cpp:
1851         (JSC::JSDataViewPrototype::finishCreation):
1852         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1853         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1854         * runtime/JSGlobalObject.cpp:
1855         (JSC::createConsoleProperty):
1856         * runtime/JSPromisePrototype.cpp:
1857         (JSC::JSPromisePrototype::finishCreation):
1858         * runtime/JSTypedArrayViewConstructor.cpp:
1859         (JSC::JSTypedArrayViewConstructor::finishCreation):
1860         * runtime/JSTypedArrayViewPrototype.cpp:
1861         (JSC::JSTypedArrayViewPrototype::finishCreation):
1862         * runtime/NumberPrototype.cpp:
1863         (JSC::NumberPrototype::finishCreation):
1864         * runtime/RegExpPrototype.cpp:
1865         (JSC::RegExpPrototype::finishCreation):
1866         * runtime/StringPrototype.cpp:
1867         (JSC::StringPrototype::finishCreation):
1868         * runtime/Structure.cpp:
1869         (JSC::Structure::isValidPrototype):
1870         (JSC::Structure::changePrototypeTransition):
1871         * runtime/Structure.h:
1872         * runtime/SymbolPrototype.cpp:
1873         (JSC::SymbolPrototype::finishCreation):
1874         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
1875         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
1876         * wasm/js/WebAssemblyInstancePrototype.cpp:
1877         (JSC::WebAssemblyInstancePrototype::finishCreation):
1878         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
1879         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1880         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1881         (JSC::WebAssemblyMemoryPrototype::finishCreation):
1882         * wasm/js/WebAssemblyModulePrototype.cpp:
1883         (JSC::WebAssemblyModulePrototype::finishCreation):
1884         * wasm/js/WebAssemblyPrototype.cpp:
1885         (JSC::WebAssemblyPrototype::finishCreation):
1886         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
1887         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
1888         * wasm/js/WebAssemblyTablePrototype.cpp:
1889         (JSC::WebAssemblyTablePrototype::finishCreation):
1890
1891 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
1892
1893         Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
1894         https://bugs.webkit.org/show_bug.cgi?id=197291
1895
1896         Reviewed by Konstantin Tokarev.
1897
1898         Replace uses of strcasestr with WTF::findIgnoringASCIICaseWithoutLength.
1899
1900         * API/tests/testapi.cpp:
1901         * assembler/testmasm.cpp:
1902         * b3/air/testair.cpp:
1903         * b3/testb3.cpp:
1904         * dfg/testdfg.cpp:
1905         * dynbench.cpp:
1906
1907 2019-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>
1908
1909         Unreviewed, rolling out r244669.
1910
1911         Windows ports can't clean build.
1912
1913         Reverted changeset:
1914
1915         "[Win] Add flag to enable version information stamping and
1916         disable by default."
1917         https://bugs.webkit.org/show_bug.cgi?id=197249
1918         https://trac.webkit.org/changeset/244669
1919
1920 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1921
1922         [Win] Add flag to enable version information stamping and disable by default.
1923         https://bugs.webkit.org/show_bug.cgi?id=197249
1924
1925         Reviewed by Ross Kirsling.
1926
1927         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
1928         Then enable it by default on AppleWin.
1929
1930         * CMakeLists.txt:
1931
1932 2019-04-25  Timothy Hatcher  <timothy@apple.com>
1933
1934         Disable date and time inputs on iOSMac.
1935         https://bugs.webkit.org/show_bug.cgi?id=197287
1936         rdar://problem/46794376
1937
1938         Reviewed by Wenson Hsieh.
1939
1940         * Configurations/FeatureDefines.xcconfig:
1941
1942 2019-04-25  Alex Christensen  <achristensen@webkit.org>
1943
1944         Fix more builds after r244653
1945         https://bugs.webkit.org/show_bug.cgi?id=197131
1946
1947         * b3/B3Value.h:
1948         There is an older system with libc++ headers that don't have std::conjunction.  Just use constexpr and && instead for the one use of it in WebKit.
1949
1950 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1951
1952         [RemoteInspector] Fix connection and target identifier types.
1953         https://bugs.webkit.org/show_bug.cgi?id=197243
1954
1955         Reviewed by Ross Kirsling.
1956
1957         Give dedicated type for RemoteControllableTarget's identifier as Inspector::TargetID.
1958
1959         Also rename ClientID type used in Socket backend to ConnectionID because this is the identifier
1960         socket endpoint assign to the newly created connection. The size was changed to uint32_t.
1961         Enough size for managing connections.
1962
1963         * inspector/remote/RemoteConnectionToTarget.cpp:
1964         (Inspector::RemoteConnectionToTarget::setup):
1965         (Inspector::RemoteConnectionToTarget::close):
1966         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
1967         * inspector/remote/RemoteConnectionToTarget.h:
1968         * inspector/remote/RemoteControllableTarget.h:
1969         * inspector/remote/RemoteInspector.cpp:
1970         (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
1971         (Inspector::RemoteInspector::registerTarget):
1972         (Inspector::RemoteInspector::unregisterTarget):
1973         (Inspector::RemoteInspector::updateTarget):
1974         (Inspector::RemoteInspector::setupFailed):
1975         (Inspector::RemoteInspector::setupCompleted):
1976         (Inspector::RemoteInspector::waitingForAutomaticInspection):
1977         (Inspector::RemoteInspector::updateTargetListing):
1978         * inspector/remote/RemoteInspector.h:
1979         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
1980         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
1981         (Inspector::RemoteConnectionToTarget::setup):
1982         (Inspector::RemoteConnectionToTarget::close):
1983         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1984         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1985         (Inspector::RemoteInspector::sendMessageToRemote):
1986         (Inspector::RemoteInspector::receivedSetupMessage):
1987         (Inspector::RemoteInspector::receivedDataMessage):
1988         (Inspector::RemoteInspector::receivedDidCloseMessage):
1989         (Inspector::RemoteInspector::receivedIndicateMessage):
1990         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
1991         * inspector/remote/glib/RemoteInspectorGlib.cpp:
1992         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1993         (Inspector::RemoteInspector::sendMessageToRemote):
1994         (Inspector::RemoteInspector::receivedSetupMessage):
1995         (Inspector::RemoteInspector::receivedDataMessage):
1996         (Inspector::RemoteInspector::receivedCloseMessage):
1997         (Inspector::RemoteInspector::setup):
1998         (Inspector::RemoteInspector::sendMessageToTarget):
1999         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
2000         (Inspector::RemoteInspectorConnectionClient::didReceiveWebInspectorEvent):
2001         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
2002         (Inspector::RemoteInspectorConnectionClient::didAccept):
2003         * inspector/remote/socket/RemoteInspectorMessageParser.cpp:
2004         (Inspector::MessageParser::MessageParser):
2005         (Inspector::MessageParser::parse):
2006         * inspector/remote/socket/RemoteInspectorMessageParser.h:
2007         (Inspector::MessageParser::setDidParseMessageListener):
2008         * inspector/remote/socket/RemoteInspectorServer.cpp:
2009         (Inspector::RemoteInspectorServer::didAccept):
2010         (Inspector::RemoteInspectorServer::didClose):
2011         (Inspector::RemoteInspectorServer::dispatchMap):
2012         (Inspector::RemoteInspectorServer::sendWebInspectorEvent):
2013         (Inspector::RemoteInspectorServer::sendCloseEvent):
2014         (Inspector::RemoteInspectorServer::connectionClosed):
2015         * inspector/remote/socket/RemoteInspectorServer.h:
2016         * inspector/remote/socket/RemoteInspectorSocket.cpp:
2017         (Inspector::RemoteInspector::didClose):
2018         (Inspector::RemoteInspector::sendMessageToRemote):
2019         (Inspector::RemoteInspector::setup):
2020         (Inspector::RemoteInspector::sendMessageToTarget):
2021         * inspector/remote/socket/RemoteInspectorSocket.h:
2022         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
2023         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
2024         (Inspector::RemoteInspectorSocketEndpoint::isListening):
2025         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
2026         (Inspector::RemoteInspectorSocketEndpoint::createClient):
2027         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
2028         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
2029         (Inspector::RemoteInspectorSocketEndpoint::send):
2030         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
2031         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
2032
2033 2019-04-25  Alex Christensen  <achristensen@webkit.org>
2034
2035         Start using C++17
2036         https://bugs.webkit.org/show_bug.cgi?id=197131
2037
2038         Reviewed by Darin Alder.
2039
2040         * Configurations/Base.xcconfig:
2041
2042 2019-04-25  Alex Christensen  <achristensen@webkit.org>
2043
2044         Remove DeprecatedOptional
2045         https://bugs.webkit.org/show_bug.cgi?id=197161
2046
2047         Reviewed by Darin Adler.
2048
2049         We need to keep a symbol exported from JavaScriptCore for binary compatibility with iOS12.
2050         We need this symbol to be in a file that doesn't include anything because libcxx's implementation of
2051         std::optional is actually std::__1::optional, which has a different mangled name.  This change will
2052         prevent protocol errors from being reported if you are running the iOS12 simulator with a custom build of WebKit
2053         and using the web inspector with it, but it's necessary to allow us to start using C++17 in WebKit.
2054
2055         * JavaScriptCore.xcodeproj/project.pbxproj:
2056         * inspector/InspectorBackendDispatcher.cpp:
2057         * inspector/InspectorBackendDispatcher.h:
2058         * inspector/InspectorBackendDispatcherCompatibility.cpp: Added.
2059         (Inspector::BackendDispatcher::reportProtocolError):
2060         * inspector/InspectorBackendDispatcherCompatibility.h: Added.
2061
2062 2019-04-24  Saam Barati  <sbarati@apple.com>
2063
2064         Add SPI callbacks for before and after module execution
2065         https://bugs.webkit.org/show_bug.cgi?id=197244
2066         <rdar://problem/50180511>
2067
2068         Reviewed by Yusuke Suzuki.
2069
2070         This is helpful for clients that want to profile execution of modules
2071         in some way. E.g, if they want to time module execution time.
2072
2073         * API/JSAPIGlobalObject.h:
2074         * API/JSAPIGlobalObject.mm:
2075         (JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
2076         * API/JSContextPrivate.h:
2077         * API/tests/testapi.mm:
2078         (+[JSContextFetchDelegate contextWithBlockForFetch:]):
2079         (-[JSContextFetchDelegate willEvaluateModule:]):
2080         (-[JSContextFetchDelegate didEvaluateModule:]):
2081         (testFetch):
2082         (testFetchWithTwoCycle):
2083         (testFetchWithThreeCycle):
2084         (testLoaderResolvesAbsoluteScriptURL):
2085         (testLoaderRejectsNilScriptURL):
2086         * runtime/JSModuleLoader.cpp:
2087         (JSC::JSModuleLoader::evaluate):
2088         (JSC::JSModuleLoader::evaluateNonVirtual):
2089         * runtime/JSModuleLoader.h:
2090
2091 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
2092
2093         [JSC] Shrink DFG::MinifiedNode
2094         https://bugs.webkit.org/show_bug.cgi?id=197224
2095
2096         Reviewed by Filip Pizlo.
2097
2098         Since it is kept alive with compiled DFG code, we should shrink it to save memory.
2099         If it is effective, we should consider minimizing these OSR exit data more aggressively.
2100
2101         * dfg/DFGMinifiedNode.h:
2102
2103 2019-04-23  Saam Barati  <sbarati@apple.com>
2104
2105         LICM incorrectly assumes it'll never insert a node which provably OSR exits
2106         https://bugs.webkit.org/show_bug.cgi?id=196721
2107         <rdar://problem/49556479> 
2108
2109         Reviewed by Filip Pizlo.
2110
2111         Previously, we assumed LICM could never hoist code that caused us
2112         to provably OSR exit. This is a bad assumption, as we may very well
2113         hoist such code. Obviously hoisting such code is not ideal. We shouldn't
2114         hoist something we provably know will OSR exit. However, this is super rare,
2115         and the phase is written in such a way where it's easier to gracefully
2116         handle this case than to prevent us from hoisting such code.
2117         
2118         If we wanted to ensure we never hoisted code that would provably exit, we'd
2119         have to teach the phase to know when it inserted code that provably exits. I
2120         saw two ways to do that:
2121         1: Save and restore the AI state before actually hoisting.
2122         2: Write an analysis that can determine if such a node would exit.
2123         
2124         (1) is bad because it costs in memory and compile time. (2) will inevitably
2125         have bugs as running into this condition is rare.
2126         
2127         So instead of (1) or (2), I opted to have LICM gracefully handle when
2128         it causes a provable exit. When we encounter this, we mark all blocks
2129         in the loop as !cfaHasVisited and !cfaDidFinish.
2130
2131         * dfg/DFGLICMPhase.cpp:
2132         (JSC::DFG::LICMPhase::attemptHoist):
2133
2134 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
2135
2136         [JSC] Use node index as DFG::MinifiedID
2137         https://bugs.webkit.org/show_bug.cgi?id=197186
2138
2139         Reviewed by Saam Barati.
2140
2141         DFG Nodes can be identified with index if the graph is given. We should use unsigned index as a DFG::MinifiedID's underlying
2142         source instead of Node* to reduce the size of VariableEvent from 16 to 12. Vector<VariableEvent> is the main data in DFG's OSR
2143         tracking. It is kept after DFG compilation is done to make OSR work. We saw that this is allocated with large size in GMail.
2144
2145         * JavaScriptCore.xcodeproj/project.pbxproj:
2146         * bytecode/DataFormat.h:
2147         * bytecode/ValueRecovery.h:
2148         * dfg/DFGGenerationInfo.h:
2149         * dfg/DFGMinifiedID.h:
2150         (JSC::DFG::MinifiedID::MinifiedID):
2151         (JSC::DFG::MinifiedID::operator! const):
2152         (JSC::DFG::MinifiedID::operator== const):
2153         (JSC::DFG::MinifiedID::operator!= const):
2154         (JSC::DFG::MinifiedID::operator< const):
2155         (JSC::DFG::MinifiedID::operator> const):
2156         (JSC::DFG::MinifiedID::operator<= const):
2157         (JSC::DFG::MinifiedID::operator>= const):
2158         (JSC::DFG::MinifiedID::hash const):
2159         (JSC::DFG::MinifiedID::dump const):
2160         (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
2161         (JSC::DFG::MinifiedID::fromBits):
2162         (JSC::DFG::MinifiedID::bits const):
2163         (JSC::DFG::MinifiedID::invalidIndex):
2164         (JSC::DFG::MinifiedID::otherInvalidIndex):
2165         (JSC::DFG::MinifiedID::node const): Deleted.
2166         (JSC::DFG::MinifiedID::invalidID): Deleted.
2167         (JSC::DFG::MinifiedID::otherInvalidID): Deleted.
2168         * dfg/DFGMinifiedIDInlines.h: Copied from Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp.
2169         (JSC::DFG::MinifiedID::MinifiedID):
2170         * dfg/DFGMinifiedNode.cpp:
2171         * dfg/DFGValueSource.h:
2172         (JSC::DFG::ValueSource::ValueSource):
2173         * dfg/DFGVariableEvent.h:
2174         (JSC::DFG::VariableEvent::dataFormat const):
2175
2176 2019-04-23  Keith Rollin  <krollin@apple.com>
2177
2178         Add Xcode version check for Header post-processing scripts
2179         https://bugs.webkit.org/show_bug.cgi?id=197116
2180         <rdar://problem/50058968>
2181
2182         Reviewed by Brent Fulgham.
2183
2184         There are several places in our Xcode projects that post-process
2185         header files after they've been exported. Because of XCBuild, we're
2186         moving to a model where the post-processing is performed at the same
2187         time the header files are exported, rather than as a distinct
2188         post-processing step. This patch disables the distinct step when the
2189         inline processing is available.
2190
2191         In practice, this means prefixing appropriate post-processing Custom
2192         Build phases with:
2193
2194         if [ "${XCODE_VERSION_MAJOR}" -ge "1100" -a "${USE_NEW_BUILD_SYSTEM}" = "YES" ]; then
2195             # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.
2196             exit 0
2197         fi
2198
2199         * JavaScriptCore.xcodeproj/project.pbxproj:
2200
2201 2019-04-23  Commit Queue  <commit-queue@webkit.org>
2202
2203         Unreviewed, rolling out r244558.
2204         https://bugs.webkit.org/show_bug.cgi?id=197219
2205
2206         Causing crashes on iOS Sim Release and Debug (Requested by
2207         ShawnRoberts on #webkit).
2208
2209         Reverted changeset:
2210
2211         "Remove DeprecatedOptional"
2212         https://bugs.webkit.org/show_bug.cgi?id=197161
2213         https://trac.webkit.org/changeset/244558
2214
2215 2019-04-23  Devin Rousso  <drousso@apple.com>
2216
2217         Web Inspector: Uncaught Exception: null is not an object (evaluating 'this.ownerDocument.frameIdentifier')
2218         https://bugs.webkit.org/show_bug.cgi?id=196420
2219         <rdar://problem/49444205>
2220
2221         Reviewed by Timothy Hatcher.
2222
2223         * inspector/protocol/DOM.json:
2224         Modify the existing `frameId` to represent the owner frame of the node, rather than the
2225         frame it holds (in the case of an `<iframe>`).
2226
2227 2019-04-23  Alex Christensen  <achristensen@webkit.org>
2228
2229         Remove DeprecatedOptional
2230         https://bugs.webkit.org/show_bug.cgi?id=197161
2231
2232         Reviewed by Darin Adler.
2233
2234         * inspector/InspectorBackendDispatcher.cpp:
2235         * inspector/InspectorBackendDispatcher.h:
2236
2237 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
2238
2239         [JSC] Use volatile load to populate backing page in MarkedBlock::Footer instead of using holdLock
2240         https://bugs.webkit.org/show_bug.cgi?id=197152
2241
2242         Reviewed by Saam Barati.
2243
2244         Emit volatile load instead of using holdLock to populate backing page in MarkedBlock::Footer.
2245
2246         * heap/BlockDirectory.cpp:
2247         (JSC::BlockDirectory::isPagedOut):
2248         * heap/MarkedBlock.h:
2249         (JSC::MarkedBlock::populatePage const):
2250
2251 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
2252
2253         [JSC] useJIT should subsume useRegExpJIT
2254         https://bugs.webkit.org/show_bug.cgi?id=197153
2255
2256         Reviewed by Alex Christensen.
2257
2258         useJIT should subsume useRegExpJIT. We should immediately disable JIT feature if useJIT = false,
2259         even if useRegExpJIT is true.
2260
2261         * dfg/DFGCapabilities.cpp:
2262         (JSC::DFG::isSupported):
2263         * runtime/Options.cpp:
2264         (JSC::recomputeDependentOptions):
2265         * runtime/RegExp.cpp:
2266         (JSC::RegExp::compile):
2267         (JSC::RegExp::compileMatchOnly):
2268         * runtime/VM.cpp:
2269         (JSC::enableAssembler):
2270         (JSC::VM::canUseRegExpJIT): Deleted.
2271         * runtime/VM.h:
2272
2273 2019-04-22  Basuke Suzuki  <basuke.suzuki@sony.com>
2274
2275         [PlayStation] Restructuring Remote Inspector classes to support multiple platform.
2276         https://bugs.webkit.org/show_bug.cgi?id=197030
2277
2278         Reviewed by Don Olmstead.
2279
2280         Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.
2281
2282         What we did is basically:
2283         - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend. 
2284         - Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
2285         - Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
2286         - Defined a new interface functions in `Inspector::Socket` (new) namespace.
2287         - Moved POSIX socket implementation into `posix\RemoteInspectorSocketPOSIX.{h|cpp}`.
2288
2289         * PlatformPlayStation.cmake:
2290         * inspector/remote/RemoteInspector.h:
2291         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Merged into RemoteInspectorSocketEndpoint.
2292         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
2293         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Removed.
2294         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Merged into RemoteInspectorSocketEndpoint.
2295         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
2296         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClientPlayStation.cpp.
2297         * inspector/remote/socket/RemoteInspectorConnectionClient.h: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClient.h.
2298         (Inspector::RemoteInspectorConnectionClient::didAccept):
2299         * inspector/remote/socket/RemoteInspectorMessageParser.cpp: Renamed from inspector\remote\playstation\RemoteInspectorMessageParserPlayStation.cpp.
2300         * inspector/remote/socket/RemoteInspectorMessageParser.h: Renamed from inspector\remote\playstation\RemoteInspectorMessageParser.h.
2301         * inspector/remote/socket/RemoteInspectorServer.cpp: Renamed from inspector\remote\playstation\RemoteInspectorServerPlayStation.cpp.
2302         (Inspector::RemoteInspectorServer::didAccept):
2303         (Inspector::RemoteInspectorServer::start):
2304         * inspector/remote/socket/RemoteInspectorServer.h: Renamed from inspector\remote\playstation\RemoteInspectorServer.h.
2305         * inspector/remote/socket/RemoteInspectorSocket.cpp: Renamed from inspector\remote\playstation\RemoteInspectorPlayStation.cpp.
2306         (Inspector::RemoteInspector::start):
2307         * inspector/remote/socket/RemoteInspectorSocket.h: Copied from inspector\remote\playstation\RemoteInspectorSocket.h.
2308         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Added.
2309         (Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
2310         (Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
2311         (Inspector::RemoteInspectorSocketEndpoint::wakeupWorkerThread):
2312         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
2313         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
2314         (Inspector::RemoteInspectorSocketEndpoint::isListening):
2315         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
2316         (Inspector::RemoteInspectorSocketEndpoint::createClient):
2317         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
2318         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
2319         (Inspector::RemoteInspectorSocketEndpoint::send):
2320         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
2321         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h: Renamed from inspector\remote\playstation\RemoteInspectorSocket.h.
2322         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Added.
2323         (Inspector::Socket::connect):
2324         (Inspector::Socket::listen):
2325         (Inspector::Socket::accept):
2326         (Inspector::Socket::createPair):
2327         (Inspector::Socket::setup):
2328         (Inspector::Socket::isValid):
2329         (Inspector::Socket::isListening):
2330         (Inspector::Socket::read):
2331         (Inspector::Socket::write):
2332         (Inspector::Socket::close):
2333         (Inspector::Socket::preparePolling):
2334         (Inspector::Socket::poll):
2335         (Inspector::Socket::isReadable):
2336         (Inspector::Socket::isWritable):
2337         (Inspector::Socket::markWaitingWritable):
2338         (Inspector::Socket::clearWaitingWritable):
2339
2340 2019-04-20  Yusuke Suzuki  <ysuzuki@apple.com>
2341
2342         Unreviewed, suppress warnings in non Darwin environments
2343
2344         * jit/ExecutableAllocator.cpp:
2345         (JSC::dumpJITMemory):
2346
2347 2019-04-19  Saam Barati  <sbarati@apple.com>
2348
2349         AbstractValue can represent more than int52
2350         https://bugs.webkit.org/show_bug.cgi?id=197118
2351         <rdar://problem/49969960>
2352
2353         Reviewed by Michael Saboff.
2354
2355         Let's analyze this control flow diamond:
2356         
2357         #0
2358         branch #1, #2
2359         
2360         #1:
2361         PutStack(JSValue, loc42)
2362         Jump #3
2363         
2364         #2:
2365         PutStack(Int52, loc42)
2366         Jump #3
2367         
2368         #3:
2369         ...
2370         
2371         Our abstract value for loc42 at the head of #3 will contain an abstract
2372         value that us the union of Int52 with other things. Obviously in the
2373         above program, a GetStack for loc42 would be inavlid, since it might
2374         be loading either JSValue or Int52. However, the abstract interpreter
2375         just tracks what the value could be, and it could be Int52 or JSValue.
2376         
2377         When I did the Int52 refactoring, I expected such things to never happen,
2378         but it turns out it does. We should just allow for this instead of asserting
2379         against it since it's valid IR to do the above.
2380
2381         * bytecode/SpeculatedType.cpp:
2382         (JSC::dumpSpeculation):
2383         * dfg/DFGAbstractValue.cpp:
2384         (JSC::DFG::AbstractValue::checkConsistency const):
2385         * dfg/DFGAbstractValue.h:
2386         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
2387
2388 2019-04-19  Tadeu Zagallo  <tzagallo@apple.com>
2389
2390         Add option to dump JIT memory
2391         https://bugs.webkit.org/show_bug.cgi?id=197062
2392         <rdar://problem/49744332>
2393
2394         Reviewed by Saam Barati.
2395
2396         Dump all writes into JIT memory to the specified file. The format is:
2397         - 64-bit destination address for the write
2398         - 64-bit size of the content written
2399         - Copy of the data that was written to JIT memory
2400
2401         * assembler/LinkBuffer.cpp:
2402         (JSC::LinkBuffer::copyCompactAndLinkCode):
2403         * jit/ExecutableAllocator.cpp:
2404         (JSC::dumpJITMemory):
2405         * jit/ExecutableAllocator.h:
2406         (JSC::performJITMemcpy):
2407         * runtime/Options.h:
2408
2409 2019-04-19  Keith Rollin  <krollin@apple.com>
2410
2411         Add postprocess-header-rule scripts
2412         https://bugs.webkit.org/show_bug.cgi?id=197072
2413         <rdar://problem/50027299>
2414
2415         Reviewed by Brent Fulgham.
2416
2417         Several projects have post-processing build phases where exported
2418         headers are tweaked after they've been copied. This post-processing is
2419         performed via scripts called postprocess-headers.sh. For reasons
2420         related to XCBuild, we are now transitioning to a build process where
2421         the post-processing is performed at the same time as the
2422         exporting/copying. To support this process, add similar scripts named
2423         postprocess-header-rule, which are geared towards processing a single
2424         file at a time rather than all exported files at once. Also add a
2425         build rule that makes use of these scripts. These scripts and build
2426         rules are not used at the moment; they will come into use in an
2427         imminent patch.
2428
2429         Note that I've named these postprocess-header-rule rather than
2430         postprocess-header-rule.sh. Scripts in Tools/Scripts do not have
2431         suffixes indicating how the tool is implemented. Scripts in
2432         per-project Scripts folders appear to be mixed regarding the use of
2433         suffixes. I'm opting here to follow the Tools/Scripts convention, with
2434         the expectation that over time we completely standardize on that.
2435
2436         * JavaScriptCore.xcodeproj/project.pbxproj:
2437         * Scripts/postprocess-header-rule: Added.
2438
2439 2019-04-18  Saam barati  <sbarati@apple.com>
2440
2441         Remove useConcurrentBarriers option
2442         https://bugs.webkit.org/show_bug.cgi?id=197066
2443
2444         Reviewed by Michael Saboff.
2445
2446         This isn't a helpful option as it will lead us to crash when using the
2447         concurrent GC.
2448
2449         * dfg/DFGStoreBarrierClusteringPhase.cpp:
2450         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2451         * jit/AssemblyHelpers.h:
2452         (JSC::AssemblyHelpers::barrierStoreLoadFence):
2453         * runtime/Options.h:
2454
2455 2019-04-17  Saam Barati  <sbarati@apple.com>
2456
2457         Remove deprecated JSScript SPI
2458         https://bugs.webkit.org/show_bug.cgi?id=194909
2459         <rdar://problem/48283499>
2460
2461         Reviewed by Keith Miller.
2462
2463         * API/JSAPIGlobalObject.mm:
2464         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
2465         * API/JSScript.h:
2466         * API/JSScript.mm:
2467         (+[JSScript scriptWithSource:inVirtualMachine:]): Deleted.
2468         (fillBufferWithContentsOfFile): Deleted.
2469         (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
2470         (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
2471         (-[JSScript setSourceURL:]): Deleted.
2472         * API/JSScriptInternal.h:
2473         * API/tests/testapi.mm:
2474         (testFetch):
2475         (testFetchWithTwoCycle):
2476         (testFetchWithThreeCycle):
2477         (testLoaderResolvesAbsoluteScriptURL):
2478         (testImportModuleTwice):
2479         (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
2480
2481 2019-04-17  Keith Rollin  <krollin@apple.com>
2482
2483         Remove JSCBuiltins.cpp from Copy Headers phase
2484         https://bugs.webkit.org/show_bug.cgi?id=196981
2485         <rdar://problem/49952133>
2486
2487         Reviewed by Alex Christensen.
2488
2489         JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
2490         Headers phase. Checking its history, it seems to have been added
2491         accidentally at the same time that JSCBuiltins.h was added.
2492
2493         * JavaScriptCore.xcodeproj/project.pbxproj:
2494
2495 2019-04-16  Stephan Szabo  <stephan.szabo@sony.com>
2496
2497         [PlayStation] Update port for system library changes
2498         https://bugs.webkit.org/show_bug.cgi?id=196978
2499
2500         Reviewed by Ross Kirsling.
2501
2502         * shell/playstation/Initializer.cpp:
2503         Add reference to new posix compatibility library.
2504
2505 2019-04-16  Robin Morisset  <rmorisset@apple.com>
2506
2507         [WTF] holdLock should be marked WARN_UNUSED_RETURN
2508         https://bugs.webkit.org/show_bug.cgi?id=196922
2509
2510         Reviewed by Keith Miller.
2511
2512         There was one case where holdLock was used and the result ignored.
2513         From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
2514         So I brought back a variant of the comment, and made the ignoring of the return explicit.
2515
2516         * heap/BlockDirectory.cpp:
2517         (JSC::BlockDirectory::isPagedOut):
2518
2519 2019-04-16  Caitlin Potter  <caitp@igalia.com>
2520
2521         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
2522         https://bugs.webkit.org/show_bug.cgi?id=176810
2523
2524         Reviewed by Saam Barati.
2525
2526         This adds conditional logic following the invariant checks, to perform
2527         filtering in common uses of getOwnPropertyNames.
2528
2529         While this would ideally only be done in JSPropertyNameEnumerator, adding
2530         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
2531         invariant that the EnumerationMode is properly followed.
2532
2533         This was originally rolled out in r244020, as DontEnum filtering code
2534         in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
2535         now redundant due to being handled in ProxyObject::getOwnPropertyNames().
2536
2537         * runtime/PropertyNameArray.h:
2538         (JSC::PropertyNameArray::reset):
2539         * runtime/ProxyObject.cpp:
2540         (JSC::ProxyObject::performGetOwnPropertyNames):
2541
2542 2019-04-15  Saam barati  <sbarati@apple.com>
2543
2544         Modify how we do SetArgument when we inline varargs calls
2545         https://bugs.webkit.org/show_bug.cgi?id=196712
2546         <rdar://problem/49605012>
2547
2548         Reviewed by Michael Saboff.
2549
2550         When we inline varargs calls, we guarantee that the number of arguments that
2551         go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
2552         However, we can't statically guarantee that the arguments between these two
2553         ranges was filled out by Load/ForwardVarargs. This is because in the general
2554         case we don't know the argument count statically.
2555         
2556         However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
2557         all arguments, even when some arguments aren't guaranteed to be in a valid
2558         state. Emitting these SetArgumentDefinitely were helpful because they let us
2559         handle variable liveness and OSR exit metadata. However, when we converted
2560         to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
2561         
2562         This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
2563         actually looking at a range of the stack that are guaranteed to be initialized.
2564         This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
2565         of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
2566         
2567         However, it differs in a couple key ways:
2568         1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
2569         you might be loading uninitialized stack. (This same rule applies when you do
2570         the full data flow reachability analysis over CPS Phis.) If someone logically
2571         wanted to emit code like this, the correct node to emit would be GetArgument,
2572         not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
2573         invalid IR.
2574         2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
2575         of SetArgumentMaybe.
2576         3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
2577         should be no data flow user of SetArgumentMaybe.
2578         
2579         SetArgumentDefinitely guarantees that the stack slot is initialized.
2580         SetArgumentMaybe makes no such guarantee.
2581
2582         * dfg/DFGAbstractInterpreterInlines.h:
2583         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2584         * dfg/DFGByteCodeParser.cpp:
2585         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
2586         * dfg/DFGCPSRethreadingPhase.cpp:
2587         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2588         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2589         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2590         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2591         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
2592         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2593         * dfg/DFGClobberize.h:
2594         (JSC::DFG::clobberize):
2595         * dfg/DFGCommon.h:
2596         * dfg/DFGDoesGC.cpp:
2597         (JSC::DFG::doesGC):
2598         * dfg/DFGFixupPhase.cpp:
2599         (JSC::DFG::FixupPhase::fixupNode):
2600         * dfg/DFGInPlaceAbstractState.cpp:
2601         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
2602         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2603         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
2604         * dfg/DFGMaximalFlushInsertionPhase.cpp:
2605         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
2606         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
2607         * dfg/DFGMayExit.cpp:
2608         * dfg/DFGNode.cpp:
2609         (JSC::DFG::Node::hasVariableAccessData):
2610         * dfg/DFGNodeType.h:
2611         * dfg/DFGPhantomInsertionPhase.cpp:
2612         * dfg/DFGPredictionPropagationPhase.cpp:
2613         * dfg/DFGSSAConversionPhase.cpp:
2614         (JSC::DFG::SSAConversionPhase::run):
2615         * dfg/DFGSafeToExecute.h:
2616         (JSC::DFG::safeToExecute):
2617         * dfg/DFGSpeculativeJIT32_64.cpp:
2618         (JSC::DFG::SpeculativeJIT::compile):
2619         * dfg/DFGSpeculativeJIT64.cpp:
2620         (JSC::DFG::SpeculativeJIT::compile):
2621         * dfg/DFGValidate.cpp:
2622         * ftl/FTLCapabilities.cpp:
2623         (JSC::FTL::canCompile):
2624
2625 2019-04-15  Commit Queue  <commit-queue@webkit.org>
2626
2627         Unreviewed, rolling out r243672.
2628         https://bugs.webkit.org/show_bug.cgi?id=196952
2629
2630         [JSValue release] should be thread-safe (Requested by
2631         yusukesuzuki on #webkit).
2632
2633         Reverted changeset:
2634
2635         "[JSC] JSWrapperMap should not use Objective-C Weak map
2636         (NSMapTable with NSPointerFunctionsWeakMemory) for
2637         m_cachedObjCWrappers"
2638         https://bugs.webkit.org/show_bug.cgi?id=196392
2639         https://trac.webkit.org/changeset/243672
2640
2641 2019-04-15  Saam barati  <sbarati@apple.com>
2642
2643         SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
2644         https://bugs.webkit.org/show_bug.cgi?id=196945
2645         <rdar://problem/49802750>
2646
2647         Reviewed by Filip Pizlo.
2648
2649         * dfg/DFGSafeToExecute.h:
2650         (JSC::DFG::safeToExecute):
2651
2652 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2653
2654         DFG should be able to constant fold Object.create() with a constant prototype operand
2655         https://bugs.webkit.org/show_bug.cgi?id=196886
2656
2657         Reviewed by Yusuke Suzuki.
2658
2659
2660         It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
2661         But when it applies it can be a significant win:
2662                                                         Baseline                   Optim                                       
2663         object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
2664         object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
2665         object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
2666         object-create-untyped-prototype               8.8873+-0.1240     ?      8.9806+-0.1202        ? might be 1.0105x slower
2667         <geometric>                                   8.6967+-0.1208     ^      7.2408+-0.1367        ^ definitely 1.2011x faster
2668
2669         The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
2670         I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
2671         I expect it to be extremely low contention, but will watch the bots just in case.
2672         The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).
2673
2674         * dfg/DFGAbstractInterpreterInlines.h:
2675         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2676         * dfg/DFGConstantFoldingPhase.cpp:
2677         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2678         * runtime/StructureCache.cpp:
2679         (JSC::StructureCache::createEmptyStructure):
2680         (JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
2681         * runtime/StructureCache.h:
2682
2683 2019-04-15  Devin Rousso  <drousso@apple.com>
2684
2685         Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
2686         https://bugs.webkit.org/show_bug.cgi?id=196484
2687         <rdar://problem/49114725>
2688
2689         Reviewed by Joseph Pecoraro.
2690
2691         Only add a catch handler when the promise is reachable via a native getter and is known to
2692         have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
2693         isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
2694         functions, instead only getting the function object itself.
2695
2696         * inspector/InjectedScriptSource.js:
2697         (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
2698
2699         * inspector/JSInjectedScriptHost.h:
2700         * inspector/JSInjectedScriptHost.cpp:
2701         (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
2702         * inspector/JSInjectedScriptHostPrototype.cpp:
2703         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2704         (Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.
2705
2706         * runtime/ErrorInstance.h:
2707         (JSC::ErrorInstance::setNativeGetterTypeError): Added.
2708         (JSC::ErrorInstance::isNativeGetterTypeError const): Added.
2709
2710         * runtime/Error.h:
2711         (JSC::throwVMGetterTypeError): Added.
2712         * runtime/Error.cpp:
2713         (JSC::createGetterTypeError): Added.
2714         (JSC::throwGetterTypeError): Added.
2715         (JSC::throwDOMAttributeGetterTypeError):
2716
2717 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2718
2719         B3::Value should have different kinds of adjacency lists
2720         https://bugs.webkit.org/show_bug.cgi?id=196091
2721
2722         Reviewed by Filip Pizlo.
2723
2724         The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
2725         - Nothing (0 bytes)
2726         - 1 Value* (8 bytes)
2727         - 2 Value* (16 bytes)
2728         - 3 Value* (24 bytes)
2729         - A Vector<Value*, 3>
2730         after the end of the Value object, depending on the kind of the Value.
2731         So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
2732         This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).
2733
2734         A few implementation points:
2735         - Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
2736         - We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
2737         - We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
2738           Thankfully, we have an extra byte of padding to use in the middle of B3::Value
2739         - In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
2740         - Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
2741         - To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
2742           This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
2743         - In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
2744         - I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough
2745
2746         * JavaScriptCore.xcodeproj/project.pbxproj:
2747         * b3/B3ArgumentRegValue.cpp:
2748         (JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
2749         * b3/B3ArgumentRegValue.h:
2750         * b3/B3AtomicValue.cpp:
2751         (JSC::B3::AtomicValue::AtomicValue):
2752         (JSC::B3::AtomicValue::cloneImpl const): Deleted.
2753         * b3/B3AtomicValue.h:
2754         * b3/B3BasicBlock.h:
2755         * b3/B3BasicBlockInlines.h:
2756         (JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
2757         * b3/B3CCallValue.cpp:
2758         (JSC::B3::CCallValue::appendArgs):
2759         (JSC::B3::CCallValue::cloneImpl const): Deleted.
2760         * b3/B3CCallValue.h:
2761         * b3/B3CheckValue.cpp:
2762         (JSC::B3::CheckValue::cloneImpl const): Deleted.
2763         * b3/B3CheckValue.h:
2764         * b3/B3Const32Value.cpp:
2765         (JSC::B3::Const32Value::cloneImpl const): Deleted.
2766         * b3/B3Const32Value.h:
2767         * b3/B3Const64Value.cpp:
2768         (JSC::B3::Const64Value::cloneImpl const): Deleted.
2769         * b3/B3Const64Value.h:
2770         * b3/B3ConstDoubleValue.cpp:
2771         (JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
2772         * b3/B3ConstDoubleValue.h:
2773         * b3/B3ConstFloatValue.cpp:
2774         (JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
2775         * b3/B3ConstFloatValue.h:
2776         * b3/B3ConstPtrValue.h:
2777         (JSC::B3::ConstPtrValue::opcodeFromConstructor):
2778         * b3/B3FenceValue.cpp:
2779         (JSC::B3::FenceValue::FenceValue):
2780         (JSC::B3::FenceValue::cloneImpl const): Deleted.
2781         * b3/B3FenceValue.h:
2782         * b3/B3MemoryValue.cpp:
2783         (JSC::B3::MemoryValue::MemoryValue):
2784         (JSC::B3::MemoryValue::cloneImpl const): Deleted.
2785         * b3/B3MemoryValue.h:
2786         * b3/B3MoveConstants.cpp:
2787         * b3/B3PatchpointValue.cpp:
2788         (JSC::B3::PatchpointValue::cloneImpl const): Deleted.
2789         * b3/B3PatchpointValue.h:
2790         (JSC::B3::PatchpointValue::opcodeFromConstructor):
2791         * b3/B3Procedure.cpp:
2792         * b3/B3Procedure.h:
2793         * b3/B3ProcedureInlines.h:
2794         (JSC::B3::Procedure::add):
2795         * b3/B3SlotBaseValue.cpp:
2796         (JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
2797         * b3/B3SlotBaseValue.h:
2798         * b3/B3StackmapSpecial.cpp:
2799         (JSC::B3::StackmapSpecial::forEachArgImpl):
2800         (JSC::B3::StackmapSpecial::isValidImpl):
2801         * b3/B3StackmapValue.cpp:
2802         (JSC::B3::StackmapValue::append):
2803         (JSC::B3::StackmapValue::StackmapValue):
2804         * b3/B3StackmapValue.h:
2805         * b3/B3SwitchValue.cpp:
2806         (JSC::B3::SwitchValue::SwitchValue):
2807         (JSC::B3::SwitchValue::cloneImpl const): Deleted.
2808         * b3/B3SwitchValue.h:
2809         (JSC::B3::SwitchValue::opcodeFromConstructor):
2810         * b3/B3UpsilonValue.cpp:
2811         (JSC::B3::UpsilonValue::cloneImpl const): Deleted.
2812         * b3/B3UpsilonValue.h:
2813         * b3/B3Value.cpp:
2814         (JSC::B3::DeepValueDump::dump const):
2815         (JSC::B3::Value::~Value):
2816         (JSC::B3::Value::replaceWithIdentity):
2817         (JSC::B3::Value::replaceWithNopIgnoringType):
2818         (JSC::B3::Value::replaceWithPhi):
2819         (JSC::B3::Value::replaceWithJump):
2820         (JSC::B3::Value::replaceWithOops):
2821         (JSC::B3::Value::replaceWith):
2822         (JSC::B3::Value::invertedCompare const):
2823         (JSC::B3::Value::returnsBool const):
2824         (JSC::B3::Value::cloneImpl const): Deleted.
2825         * b3/B3Value.h:
2826         (JSC::B3::DeepValueDump::dump const): Deleted.
2827         * b3/B3ValueInlines.h:
2828         (JSC::B3::Value::adjacencyListOffset const):
2829         (JSC::B3::Value::cloneImpl const):
2830         * b3/B3VariableValue.cpp:
2831         (JSC::B3::VariableValue::VariableValue):
2832         (JSC::B3::VariableValue::cloneImpl const): Deleted.
2833         * b3/B3VariableValue.h:
2834         * b3/B3WasmAddressValue.cpp:
2835         (JSC::B3::WasmAddressValue::WasmAddressValue):
2836         (JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
2837         * b3/B3WasmAddressValue.h:
2838         * b3/B3WasmBoundsCheckValue.cpp:
2839         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2840         (JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
2841         * b3/B3WasmBoundsCheckValue.h:
2842         (JSC::B3::WasmBoundsCheckValue::accepts):
2843         (JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
2844         * b3/testb3.cpp:
2845         (JSC::B3::testCallFunctionWithHellaArguments):
2846         (JSC::B3::testCallFunctionWithHellaArguments2):
2847         (JSC::B3::testCallFunctionWithHellaArguments3):
2848         (JSC::B3::testCallFunctionWithHellaDoubleArguments):
2849         (JSC::B3::testCallFunctionWithHellaFloatArguments):
2850         * ftl/FTLOutput.h:
2851         (JSC::FTL::Output::call):
2852
2853 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
2854
2855         Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
2856         https://bugs.webkit.org/show_bug.cgi?id=196878
2857
2858         Reviewed by Saam Barati.
2859
2860         Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
2861         including the full source if it's a StringSourceProvider. This wasn't an issue,
2862         since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
2863         would avoid encoding the provider multiple times. With the addition of the
2864         incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
2865         means we can no longer deduplicate it and the full program text was being encoded
2866         multiple times in the cache.
2867         As a work around, this patch adds a custom cached type for encoding the SourceCode
2868         without its provider, and later injects the SourceProvider through the Decoder.
2869
2870         * parser/SourceCode.h:
2871         * parser/UnlinkedSourceCode.h:
2872         (JSC::UnlinkedSourceCode::provider const):
2873         * runtime/CachedTypes.cpp:
2874         (JSC::Decoder::Decoder):
2875         (JSC::Decoder::create):
2876         (JSC::Decoder::provider const):
2877         (JSC::CachedSourceCodeWithoutProvider::encode):
2878         (JSC::CachedSourceCodeWithoutProvider::decode const):
2879         (JSC::decodeCodeBlockImpl):
2880         * runtime/CachedTypes.h:
2881
2882 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2883
2884         MarkedSpace.cpp is not in the Xcode workspace
2885         https://bugs.webkit.org/show_bug.cgi?id=196928
2886
2887         Reviewed by Saam Barati.
2888
2889         * JavaScriptCore.xcodeproj/project.pbxproj:
2890
2891 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
2892
2893         Incremental bytecode cache should not append function updates when loaded from memory
2894         https://bugs.webkit.org/show_bug.cgi?id=196865
2895
2896         Reviewed by Filip Pizlo.
2897
2898         Function updates hold the assumption that a function can only be executed/cached
2899         after its containing code block has already been cached. This assumptions does
2900         not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
2901         we might have two independent SourceProviders executing different paths of the
2902         code and causing the same UnlinkedCodeBlock to be modified in memory.
2903         Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
2904         between a new, empty cache and a cache that was not loaded and therefore cannot be updated.
2905
2906         * jsc.cpp:
2907         (ShellSourceProvider::ShellSourceProvider):
2908
2909 2019-04-15  Saam barati  <sbarati@apple.com>
2910
2911         mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
2912         https://bugs.webkit.org/show_bug.cgi?id=196918
2913
2914         Reviewed by Yusuke Suzuki.
2915
2916         r244238 lead to some debug failures because we were calling checkConsistency()
2917         before doing fixTypeForRepresentation when merging in must handle values in
2918         CFA. This patch fixes that.
2919         
2920         However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
2921         was possible it could merge in a value/type outside of the variable's flushed type.
2922         Once the flush format types are locked in, we can't introduce a type out of
2923         that range. This probably never lead to any crashes as our profiling injection
2924         and speculation decision code is solid. However, what we were doing is clearly
2925         wrong, and something a fuzzer could have found if we fuzzed the must handle
2926         values inside prediction injection. We should do that fuzzing:
2927         https://bugs.webkit.org/show_bug.cgi?id=196924
2928
2929         * dfg/DFGAbstractValue.cpp:
2930         (JSC::DFG::AbstractValue::mergeOSREntryValue):
2931         * dfg/DFGAbstractValue.h:
2932         * dfg/DFGCFAPhase.cpp:
2933         (JSC::DFG::CFAPhase::injectOSR):
2934
2935 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2936
2937         Several structures and enums in the Yarr interpreter can be shrunk
2938         https://bugs.webkit.org/show_bug.cgi?id=196923
2939
2940         Reviewed by Saam Barati.
2941
2942         YarrOp: 88 -> 80
2943         RegularExpression: 40 -> 32
2944         ByteTerm: 56 -> 48
2945         PatternTerm: 56 -> 48
2946
2947         * yarr/RegularExpression.cpp:
2948         * yarr/YarrInterpreter.h:
2949         * yarr/YarrJIT.cpp:
2950         (JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
2951         * yarr/YarrParser.h:
2952         * yarr/YarrPattern.h:
2953
2954 2019-04-15  Devin Rousso  <drousso@apple.com>
2955
2956         Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
2957         https://bugs.webkit.org/show_bug.cgi?id=196925
2958         <rdar://problem/49873994>
2959
2960         Reviewed by Joseph Pecoraro.
2961
2962         Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
2963         functions so that callers can be guaranteed to have a valid instance of the agent.
2964
2965         * inspector/JSGlobalObjectInspectorController.h:
2966         * inspector/JSGlobalObjectInspectorController.cpp:
2967         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
2968         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
2969         (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
2970         (Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
2971         (Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
2972         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2973
2974 2019-04-14  Don Olmstead  <don.olmstead@sony.com>
2975
2976         [CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
2977         https://bugs.webkit.org/show_bug.cgi?id=196742
2978
2979         Reviewed by Konstantin Tokarev.
2980
2981         Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
2982         to support moving the JavaScriptCore derived sources outside of a shared directory.
2983
2984         Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.
2985
2986         * CMakeLists.txt:
2987
2988 2019-04-13  Tadeu Zagallo  <tzagallo@apple.com>
2989
2990         CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
2991         https://bugs.webkit.org/show_bug.cgi?id=196880
2992
2993         Reviewed by Yusuke Suzuki.
2994
2995         CodeCache should not tell the SourceProvider to cache the bytecode if it failed
2996         to create the UnlinkedCodeBlock.
2997
2998         * runtime/CodeCache.cpp:
2999         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
3000
3001 2019-04-12  Saam barati  <sbarati@apple.com>
3002
3003         r244079 logically broke shouldSpeculateInt52
3004         https://bugs.webkit.org/show_bug.cgi?id=196884
3005
3006         Reviewed by Yusuke Suzuki.
3007
3008         In r244079, I changed shouldSpeculateInt52 to only return true
3009         when the prediction is isAnyInt52Speculation(). However, it was
3010         wrong to not to include SpecInt32 in this for two reasons:
3011
3012         1. We diligently write code that first checks if we should speculate Int32.
3013         For example:
3014         if (shouldSpeculateInt32()) ... 
3015         else if (shouldSpeculateInt52()) ...
3016
3017         It would be wrong not to fall back to Int52 if we're dealing with the union of
3018         Int32 and Int52.
3019
3020         It would be a performance mistake to not include Int32 here because
3021         data flow can easily tell us that we have variables that are the union
3022         of Int32 and Int52 values. It's better to speculate Int52 than Double
3023         in that situation.
3024
3025         2. We also write code where we ask if the inputs can be Int52, e.g, if
3026         we know via profiling that an Add overflows, we may not emit an Int32 add.
3027         However, we only emit such an add if both inputs can be Int52, and Int32
3028         can trivially become Int52.
3029
3030        This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.
3031
3032         * bytecode/SpeculatedType.h:
3033         (JSC::isInt32SpeculationForArithmetic):
3034         (JSC::isInt32OrBooleanSpeculationForArithmetic):
3035         (JSC::isInt32OrInt52Speculation):
3036         * dfg/DFGFixupPhase.cpp:
3037         (JSC::DFG::FixupPhase::observeUseKindOnNode):
3038         * dfg/DFGNode.h:
3039         (JSC::DFG::Node::shouldSpeculateInt52):
3040         * dfg/DFGPredictionPropagationPhase.cpp:
3041         * dfg/DFGVariableAccessData.cpp:
3042         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
3043
3044 2019-04-12  Saam barati  <sbarati@apple.com>
3045
3046         Unreviewed. Build fix after r244233.
3047
3048         * assembler/CPU.cpp:
3049
3050 2019-04-12  Saam barati  <sbarati@apple.com>
3051
3052         Sometimes we need to user fewer CPUs in our threading calculations
3053         https://bugs.webkit.org/show_bug.cgi?id=196794
3054         <rdar://problem/49389497>
3055
3056         Reviewed by Yusuke Suzuki.
3057
3058         * JavaScriptCore.xcodeproj/project.pbxproj:
3059         * Sources.txt:
3060         * assembler/CPU.cpp: Added.
3061         (JSC::isKernTCSMAvailable):
3062         (JSC::enableKernTCSM):
3063         (JSC::kernTCSMAwareNumberOfProcessorCores):
3064         * assembler/CPU.h:
3065         (JSC::isKernTCSMAvailable):
3066         (JSC::enableKernTCSM):
3067         (JSC::kernTCSMAwareNumberOfProcessorCores):
3068         * heap/MachineStackMarker.h:
3069         (JSC::MachineThreads::addCurrentThread):
3070         * runtime/JSLock.cpp:
3071         (JSC::JSLock::didAcquireLock):
3072         * runtime/Options.cpp:
3073         (JSC::computeNumberOfWorkerThreads):
3074         (JSC::computePriorityDeltaOfWorkerThreads):
3075         * wasm/WasmWorklist.cpp:
3076         (JSC::Wasm::Worklist::Worklist):
3077
3078 2019-04-12  Robin Morisset  <rmorisset@apple.com>
3079
3080         Use padding at end of ArrayBuffer
3081         https://bugs.webkit.org/show_bug.cgi?id=196823
3082
3083         Reviewed by Filip Pizlo.
3084
3085         * runtime/ArrayBuffer.h:
3086
3087 2019-04-11  Yusuke Suzuki  <ysuzuki@apple.com>
3088
3089         [JSC] op_has_indexed_property should not assume subscript part is Uint32
3090         https://bugs.webkit.org/show_bug.cgi?id=196850
3091
3092         Reviewed by Saam Barati.
3093
3094         op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
3095         DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
3096         In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.
3097
3098         * jit/JITOpcodes.cpp:
3099         (JSC::JIT::emit_op_has_indexed_property):
3100         * jit/JITOpcodes32_64.cpp:
3101         (JSC::JIT::emit_op_has_indexed_property):
3102         * jit/JITOperations.cpp:
3103         * runtime/CommonSlowPaths.cpp:
3104         (JSC::SLOW_PATH_DECL):
3105
3106 2019-04-11  Saam barati  <sbarati@apple.com>
3107
3108         Remove invalid assertion in operationInstanceOfCustom
3109         https://bugs.webkit.org/show_bug.cgi?id=196842
3110         <rdar://problem/49725493>
3111
3112         Reviewed by Michael Saboff.
3113
3114         In the generated JIT code, we go to the slow path when the incoming function
3115         isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
3116         in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
3117         functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
3118         inlining across global objects as exec->lexicalGlobalObject() uses the machine
3119         frame for procuring the global object. There is no harm when this assertion fails
3120         as we just execute the slow path. This patch removes the assertion. (However, this
3121         does shed light on the deficiency in our exec->lexicalGlobalObject() function with
3122         respect to inlining. However, this isn't new -- we've known about this for a while.)
3123
3124         * jit/JITOperations.cpp:
3125
3126 2019-04-11  Michael Saboff  <msaboff@apple.com>
3127
3128         Improve the Inline Cache Stats code
3129         https://bugs.webkit.org/show_bug.cgi?id=196836
3130
3131         Reviewed by Saam Barati.
3132
3133         Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
3134         and InstanceOfReplaceWithJump.
3135
3136         Added the ability to log the location of a GetBy and PutBy property as either on self or up the
3137         protocol chain.
3138
3139         * jit/ICStats.cpp:
3140         (JSC::ICEvent::operator< const):
3141         (JSC::ICEvent::dump const):
3142         * jit/ICStats.h:
3143         (JSC::ICEvent::ICEvent):
3144         (JSC::ICEvent::hash const):
3145         * jit/JITOperations.cpp:
3146         * jit/Repatch.cpp:
3147         (JSC::tryCacheGetByID):
3148         (JSC::tryCachePutByID):
3149         (JSC::tryCacheInByID):
3150
3151 2019-04-11  Devin Rousso  <drousso@apple.com>
3152
3153         Web Inspector: Timelines: can't reliably stop/start a recording
3154         https://bugs.webkit.org/show_bug.cgi?id=196778
3155         <rdar://problem/47606798>
3156
3157         Reviewed by Timothy Hatcher.
3158
3159         * inspector/protocol/ScriptProfiler.json:
3160         * inspector/protocol/Timeline.json:
3161         It is possible to determine when programmatic capturing starts/stops in the frontend based
3162         on the state when the backend causes the state to change, such as if the state is "inactive"
3163         when the frontend is told that the backend has started capturing.
3164
3165         * inspector/protocol/CPUProfiler.json:
3166         * inspector/protocol/Memory.json:
3167         Send an end timestamp to match other instruments.
3168
3169         * inspector/JSGlobalObjectConsoleClient.cpp:
3170         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
3171         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
3172
3173         * inspector/agents/InspectorScriptProfilerAgent.h:
3174         * inspector/agents/InspectorScriptProfilerAgent.cpp:
3175         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
3176         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
3177         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
3178
3179 2019-04-11  Saam barati  <sbarati@apple.com>
3180
3181         Rename SetArgument to SetArgumentDefinitely
3182         https://bugs.webkit.org/show_bug.cgi?id=196828
3183
3184         Reviewed by Yusuke Suzuki.
3185
3186         This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
3187         where we will introduce a node named SetArgumentMaybe. Doing this refactoring
3188         first will make reviewing that other patch easier.
3189
3190         * dfg/DFGAbstractInterpreterInlines.h:
3191         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3192         * dfg/DFGByteCodeParser.cpp:
3193         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
3194         (JSC::DFG::ByteCodeParser::parseBlock):
3195         * dfg/DFGCPSRethreadingPhase.cpp:
3196         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
3197         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
3198         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
3199         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3200         (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
3201         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
3202         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
3203         * dfg/DFGClobberize.h:
3204         (JSC::DFG::clobberize):
3205         * dfg/DFGCommon.h:
3206         * dfg/DFGDoesGC.cpp:
3207         (JSC::DFG::doesGC):
3208         * dfg/DFGFixupPhase.cpp:
3209         (JSC::DFG::FixupPhase::fixupNode):
3210         * dfg/DFGGraph.cpp:
3211         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
3212         * dfg/DFGGraph.h:
3213         * dfg/DFGInPlaceAbstractState.cpp:
3214         (JSC::DFG::InPlaceAbstractState::initialize):
3215         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
3216         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
3217         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
3218         * dfg/DFGMaximalFlushInsertionPhase.cpp:
3219         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
3220         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
3221         * dfg/DFGMayExit.cpp:
3222         * dfg/DFGNode.cpp:
3223         (JSC::DFG::Node::hasVariableAccessData):
3224         * dfg/DFGNode.h:
3225         (JSC::DFG::Node::convertPhantomToPhantomLocal):
3226         * dfg/DFGNodeType.h:
3227         * dfg/DFGOSREntrypointCreationPhase.cpp:
3228         (JSC::DFG::OSREntrypointCreationPhase::run):
3229         * dfg/DFGPhantomInsertionPhase.cpp:
3230         * dfg/DFGPredictionPropagationPhase.cpp:
3231         * dfg/DFGSSAConversionPhase.cpp:
3232         (JSC::DFG::SSAConversionPhase::run):
3233         * dfg/DFGSafeToExecute.h:
3234         (JSC::DFG::safeToExecute):
3235         * dfg/DFGSpeculativeJIT.cpp:
3236         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
3237         * dfg/DFGSpeculativeJIT32_64.cpp:
3238         (JSC::DFG::SpeculativeJIT::compile):
3239         * dfg/DFGSpeculativeJIT64.cpp:
3240         (JSC::DFG::SpeculativeJIT::compile):
3241         * dfg/DFGTypeCheckHoistingPhase.cpp:
3242         (JSC::DFG::TypeCheckHoistingPhase::run):
3243         * dfg/DFGValidate.cpp:
3244         * ftl/FTLCapabilities.cpp:
3245         (JSC::FTL::canCompile):
3246
3247 2019-04-11  Truitt Savell  <tsavell@apple.com>
3248
3249         Unreviewed, rolling out r244158.
3250
3251         Casued 8 inspector/timeline/ test failures.
3252
3253         Reverted changeset:
3254
3255         "Web Inspector: Timelines: can't reliably stop/start a
3256         recording"
3257         https://bugs.webkit.org/show_bug.cgi?id=196778
3258         https://trac.webkit.org/changeset/244158
3259
3260 2019-04-10  Saam Barati  <sbarati@apple.com>
3261
3262         AbstractValue::validateOSREntryValue is wrong for Int52 constants
3263         https://bugs.webkit.org/show_bug.cgi?id=196801
3264         <rdar://problem/49771122>
3265
3266         Reviewed by Yusuke Suzuki.
3267
3268         validateOSREntryValue should not care about the format of the incoming
3269         value for Int52s. This patch normalizes the format of m_value and
3270         the incoming value when comparing them.
3271
3272         * dfg/DFGAbstractValue.h:
3273         (JSC::DFG::AbstractValue::validateOSREntryValue const):
3274
3275 2019-04-10  Saam Barati  <sbarati@apple.com>
3276
3277         ArithSub over Int52 has shouldCheckOverflow as always true
3278         https://bugs.webkit.org/show_bug.cgi?id=196796
3279
3280         Reviewed by Yusuke Suzuki.
3281
3282         AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
3283         shouldCheckOverflow is always true, so !shouldCheckOverflow is always
3284         false. We shouldn't check something we assert against.
3285
3286         * dfg/DFGAbstractInterpreterInlines.h:
3287         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3288
3289 2019-04-10  Basuke Suzuki  <basuke.suzuki@sony.com>
3290
3291         [PlayStation] Specify byte order clearly on Remote Inspector Protocol
3292         https://bugs.webkit.org/show_bug.cgi?id=196790
3293
3294         Reviewed by Ross Kirsling.
3295
3296         Original implementation lacks byte order specification. Network byte order is the
3297         good candidate if there's no strong reason to choose other.
3298         Currently no client exists for PlayStation remote inspector protocol, so we can
3299         change the byte order without care.
3300
3301         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
3302         (Inspector::MessageParser::createMessage):
3303         (Inspector::MessageParser::parse):
3304
3305 2019-04-10  Devin Rousso  <drousso@apple.com>
3306
3307        Web Inspector: Inspector: lazily create the agent
3308        https://bugs.webkit.org/show_bug.cgi?id=195971
3309        <rdar://problem/49039645>
3310
3311        Reviewed by Joseph Pecoraro.
3312
3313        * inspector/JSGlobalObjectInspectorController.cpp:
3314        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
3315        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
3316        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
3317        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
3318
3319        * inspector/agents/InspectorAgent.h:
3320        * inspector/agents/InspectorAgent.cpp:
3321
3322 2019-04-10  Saam Barati  <sbarati@apple.com>
3323
3324         Work around an arm64_32 LLVM miscompile bug
3325         https://bugs.webkit.org/show_bug.cgi?id=196788
3326
3327