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