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