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