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