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