199ba2434ce77788336266e695beebd7193ff9a4
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-11-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         Unreviewed, release throw scope
4         https://bugs.webkit.org/show_bug.cgi?id=178726
5
6         * dfg/DFGOperations.cpp:
7
8 2017-11-02  Frederic Wang  <fwang@igalia.com>
9
10         Add references to bug 179167 in FIXME comments
11         https://bugs.webkit.org/show_bug.cgi?id=179168
12
13         Reviewed by Daniel Bates.
14
15         * Configurations/FeatureDefines.xcconfig:
16
17 2017-11-01  Jeremy Jones  <jeremyj@apple.com>
18
19         Implement WKFullscreenWindowController for iOS.
20         https://bugs.webkit.org/show_bug.cgi?id=178924
21         rdar://problem/34697120
22
23         Reviewed by Simon Fraser.
24
25         Enable ENABLE_FULLSCREEN_API for iOS.
26
27         * Configurations/FeatureDefines.xcconfig:
28
29 2017-11-01  Mark Lam  <mark.lam@apple.com>
30
31         Add support to throw OOM if MarkedArgumentBuffer may overflow.
32         https://bugs.webkit.org/show_bug.cgi?id=179092
33         <rdar://problem/35116160>
34
35         Reviewed by Saam Barati.
36
37         The test for overflowing a MarkedArgumentBuffer will run for a ridiculously long
38         time, which renders it unsuitable for automated tests.  Instead, I've run a
39         test manually to verify that an OutOfMemoryError will be thrown when an overflow
40         occurs.
41
42         The MarkedArgumentBuffer's destructor will now assert that the client has indeed
43         checked for an overflow after invoking methods that may result in an overflow i.e.
44         the destructor checks that MarkedArgumentBuffer::hasOverflowed() has been called.
45         This is only done on debug builds.
46
47         * API/JSObjectRef.cpp:
48         (JSObjectMakeFunction):
49         (JSObjectMakeArray):
50         (JSObjectMakeDate):
51         (JSObjectMakeRegExp):
52         (JSObjectCallAsFunction):
53         (JSObjectCallAsConstructor):
54         * dfg/DFGOperations.cpp:
55         * inspector/InjectedScriptManager.cpp:
56         (Inspector::InjectedScriptManager::createInjectedScript):
57         * inspector/JSJavaScriptCallFrame.cpp:
58         (Inspector::JSJavaScriptCallFrame::scopeChain const):
59         * interpreter/Interpreter.cpp:
60         (JSC::Interpreter::executeProgram):
61         * jsc.cpp:
62         (functionDollarAgentReceiveBroadcast):
63         * runtime/ArgList.cpp:
64         (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
65         (JSC::MarkedArgumentBuffer::expandCapacity):
66         (JSC::MarkedArgumentBuffer::slowAppend):
67         * runtime/ArgList.h:
68         (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
69         (JSC::MarkedArgumentBuffer::appendWithAction):
70         (JSC::MarkedArgumentBuffer::append):
71         (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow):
72         (JSC::MarkedArgumentBuffer::hasOverflowed):
73         (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck):
74         (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck):
75         * runtime/ArrayPrototype.cpp:
76         * runtime/CommonSlowPaths.cpp:
77         (JSC::SLOW_PATH_DECL):
78         * runtime/GetterSetter.cpp:
79         (JSC::callSetter):
80         * runtime/IteratorOperations.cpp:
81         (JSC::iteratorNext):
82         (JSC::iteratorClose):
83         * runtime/JSBoundFunction.cpp:
84         (JSC::boundThisNoArgsFunctionCall):
85         (JSC::boundFunctionCall):
86         (JSC::boundThisNoArgsFunctionConstruct):
87         (JSC::boundFunctionConstruct):
88         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
89         (JSC::constructGenericTypedArrayViewFromIterator):
90         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
91         (JSC::genericTypedArrayViewProtoFuncSlice):
92         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
93         * runtime/JSGlobalObject.cpp:
94         (JSC::JSGlobalObject::haveABadTime):
95         * runtime/JSInternalPromise.cpp:
96         (JSC::JSInternalPromise::then):
97         * runtime/JSJob.cpp:
98         (JSC::JSJobMicrotask::run):
99         * runtime/JSMapIterator.cpp:
100         (JSC::JSMapIterator::createPair):
101         * runtime/JSModuleLoader.cpp:
102         (JSC::JSModuleLoader::provideFetch):
103         (JSC::JSModuleLoader::loadAndEvaluateModule):
104         (JSC::JSModuleLoader::loadModule):
105         (JSC::JSModuleLoader::linkAndEvaluateModule):
106         (JSC::JSModuleLoader::requestImportModule):
107         * runtime/JSONObject.cpp:
108         (JSC::Stringifier::toJSONImpl):
109         (JSC::Stringifier::appendStringifiedValue):
110         (JSC::Walker::callReviver):
111         * runtime/JSObject.cpp:
112         (JSC::ordinarySetSlow):
113         (JSC::callToPrimitiveFunction):
114         (JSC::JSObject::hasInstance):
115         * runtime/JSPromise.cpp:
116         (JSC::JSPromise::initialize):
117         (JSC::JSPromise::resolve):
118         * runtime/JSPromiseDeferred.cpp:
119         (JSC::newPromiseCapability):
120         (JSC::callFunction):
121         * runtime/JSSetIterator.cpp:
122         (JSC::JSSetIterator::createPair):
123         * runtime/LiteralParser.cpp:
124         (JSC::LiteralParser<CharType>::parse):
125         * runtime/MapConstructor.cpp:
126         (JSC::constructMap):
127         * runtime/ObjectConstructor.cpp:
128         (JSC::defineProperties):
129         * runtime/ProxyObject.cpp:
130         (JSC::performProxyGet):
131         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
132         (JSC::ProxyObject::performHasProperty):
133         (JSC::ProxyObject::performPut):
134         (JSC::performProxyCall):
135         (JSC::performProxyConstruct):
136         (JSC::ProxyObject::performDelete):
137         (JSC::ProxyObject::performPreventExtensions):
138         (JSC::ProxyObject::performIsExtensible):
139         (JSC::ProxyObject::performDefineOwnProperty):
140         (JSC::ProxyObject::performGetOwnPropertyNames):
141         (JSC::ProxyObject::performSetPrototype):
142         (JSC::ProxyObject::performGetPrototype):
143         * runtime/ReflectObject.cpp:
144         (JSC::reflectObjectConstruct):
145         * runtime/SetConstructor.cpp:
146         (JSC::constructSet):
147         * runtime/StringPrototype.cpp:
148         (JSC::replaceUsingRegExpSearch):
149         (JSC::replaceUsingStringSearch):
150         * runtime/WeakMapConstructor.cpp:
151         (JSC::constructWeakMap):
152         * runtime/WeakSetConstructor.cpp:
153         (JSC::constructWeakSet):
154         * wasm/js/WasmToJS.cpp:
155         (JSC::Wasm::wasmToJS):
156
157 2017-11-01  Michael Saboff  <msaboff@apple.com>
158
159         Integer overflow in code generated by LoadVarargs processing in DFG and FTL.
160         https://bugs.webkit.org/show_bug.cgi?id=179140
161
162         Reviewed by Saam Barati.
163
164         Added overflow checks to computation of arg count plus this.
165
166         * dfg/DFGSpeculativeJIT32_64.cpp:
167         (JSC::DFG::SpeculativeJIT::compile):
168         * dfg/DFGSpeculativeJIT64.cpp:
169         (JSC::DFG::SpeculativeJIT::compile):
170         * ftl/FTLLowerDFGToB3.cpp:
171         (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
172
173 2017-11-01  Yusuke Suzuki  <utatane.tea@gmail.com>
174
175         Unreviewed, use weakPointer instead of FTLOutput::weakPointer
176         https://bugs.webkit.org/show_bug.cgi?id=178934
177
178         * ftl/FTLLowerDFGToB3.cpp:
179         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
180
181 2017-11-01  Yusuke Suzuki  <utatane.tea@gmail.com>
182
183         [JSC] Introduce @toObject
184         https://bugs.webkit.org/show_bug.cgi?id=178726
185
186         Reviewed by Saam Barati.
187
188         This patch introduces @toObject intrinsic. And we introduce op_to_object bytecode and DFG ToObject node.
189         Previously we emulated @toObject behavior in builtin JS. But it consumes much bytecode size while @toObject
190         is frequently seen and defined clearly in the spec. Furthermore, the emulated @toObject always calls
191         ObjectConstructor in LLInt and Baseline.
192
193         We add a new intrinsic `@toObject(target, "error message")`. It takes an error message string constant to
194         offer understandable messages in builtin JS. We can change the frequently seen "emulated ToObject" operation
195
196             if (this === @undefined || this === null)
197                 @throwTypeError("error message");
198             var object = @Object(this);
199
200         with
201
202             var object = @toObject(this, "error message");
203
204         And we handle op_to_object in DFG as ToObject node. While CallObjectConstructor does not throw an error for null/undefined,
205         ToObject needs to throw an error for null/undefined. So it is marked as MustGenerate and it clobbers the world.
206         In fixup phase, we attempt to convert ToObject to CallObjectConstructor with edge filters to relax its side effect.
207
208         It also fixes a bug that CallObjectConstructor DFG node uses Node's semantic GlobalObject instead of function's one.
209
210         * builtins/ArrayConstructor.js:
211         (from):
212         * builtins/ArrayPrototype.js:
213         (values):
214         (keys):
215         (entries):
216         (reduce):
217         (reduceRight):
218         (every):
219         (forEach):
220         (filter):
221         (map):
222         (some):
223         (fill):
224         (find):
225         (findIndex):
226         (includes):
227         (sort):
228         (globalPrivate.concatSlowPath):
229         (copyWithin):
230         * builtins/DatePrototype.js:
231         (toLocaleString.toDateTimeOptionsAnyAll):
232         (toLocaleString):
233         (toLocaleDateString.toDateTimeOptionsDateDate):
234         (toLocaleDateString):
235         (toLocaleTimeString.toDateTimeOptionsTimeTime):
236         (toLocaleTimeString):
237         * builtins/GlobalOperations.js:
238         (globalPrivate.copyDataProperties):
239         (globalPrivate.copyDataPropertiesNoExclusions):
240         * builtins/ObjectConstructor.js:
241         (entries):
242         * builtins/StringConstructor.js:
243         (raw):
244         * builtins/TypedArrayConstructor.js:
245         (from):
246         * builtins/TypedArrayPrototype.js:
247         (map):
248         (filter):
249         * bytecode/BytecodeDumper.cpp:
250         (JSC::BytecodeDumper<Block>::dumpBytecode):
251         * bytecode/BytecodeIntrinsicRegistry.h:
252         * bytecode/BytecodeList.json:
253         * bytecode/BytecodeUseDef.h:
254         (JSC::computeUsesForBytecodeOffset):
255         (JSC::computeDefsForBytecodeOffset):
256         * bytecode/CodeBlock.cpp:
257         (JSC::CodeBlock::finishCreation):
258         * bytecompiler/BytecodeGenerator.cpp:
259         (JSC::BytecodeGenerator::emitToObject):
260         * bytecompiler/BytecodeGenerator.h:
261         * bytecompiler/NodesCodegen.cpp:
262         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toObject):
263         * dfg/DFGAbstractInterpreterInlines.h:
264         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
265         * dfg/DFGByteCodeParser.cpp:
266         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
267         (JSC::DFG::ByteCodeParser::parseBlock):
268         * dfg/DFGCapabilities.cpp:
269         (JSC::DFG::capabilityLevel):
270         * dfg/DFGClobberize.h:
271         (JSC::DFG::clobberize):
272         * dfg/DFGDoesGC.cpp:
273         (JSC::DFG::doesGC):
274         * dfg/DFGFixupPhase.cpp:
275         (JSC::DFG::FixupPhase::fixupNode):
276         (JSC::DFG::FixupPhase::fixupToObject):
277         (JSC::DFG::FixupPhase::fixupCallObjectConstructor):
278         * dfg/DFGNode.h:
279         (JSC::DFG::Node::convertToCallObjectConstructor):
280         (JSC::DFG::Node::convertToNewStringObject):
281         (JSC::DFG::Node::convertToNewObject):
282         (JSC::DFG::Node::hasIdentifier):
283         (JSC::DFG::Node::hasHeapPrediction):
284         (JSC::DFG::Node::hasCellOperand):
285         * dfg/DFGNodeType.h:
286         * dfg/DFGOperations.cpp:
287         * dfg/DFGOperations.h:
288         * dfg/DFGPredictionPropagationPhase.cpp:
289         * dfg/DFGSafeToExecute.h:
290         (JSC::DFG::safeToExecute):
291         * dfg/DFGSpeculativeJIT.cpp:
292         (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor):
293         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
294         * dfg/DFGSpeculativeJIT.h:
295         (JSC::DFG::SpeculativeJIT::callOperation):
296         * dfg/DFGSpeculativeJIT32_64.cpp:
297         (JSC::DFG::SpeculativeJIT::compile):
298         * dfg/DFGSpeculativeJIT64.cpp:
299         (JSC::DFG::SpeculativeJIT::compile):
300         * ftl/FTLCapabilities.cpp:
301         (JSC::FTL::canCompile):
302         * ftl/FTLLowerDFGToB3.cpp:
303         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
304         (JSC::FTL::DFG::LowerDFGToB3::compileToObjectOrCallObjectConstructor):
305         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
306         * jit/JIT.cpp:
307         (JSC::JIT::privateCompileMainPass):
308         (JSC::JIT::privateCompileSlowCases):
309         * jit/JIT.h:
310         * jit/JITOpcodes.cpp:
311         (JSC::JIT::emit_op_to_object):
312         (JSC::JIT::emitSlow_op_to_object):
313         * jit/JITOpcodes32_64.cpp:
314         (JSC::JIT::emit_op_to_object):
315         (JSC::JIT::emitSlow_op_to_object):
316         * jit/JITOperations.cpp:
317         * jit/JITOperations.h:
318         * llint/LowLevelInterpreter32_64.asm:
319         * llint/LowLevelInterpreter64.asm:
320         * runtime/CommonSlowPaths.cpp:
321         (JSC::SLOW_PATH_DECL):
322         * runtime/CommonSlowPaths.h:
323
324 2017-11-01  Fujii Hironori  <Hironori.Fujii@sony.com>
325
326         Use LazyNeverDestroyed instead of DEFINE_GLOBAL
327         https://bugs.webkit.org/show_bug.cgi?id=174979
328
329         Reviewed by Yusuke Suzuki.
330
331         * config.h: Removed definitions of SKIP_STATIC_CONSTRUCTORS_ON_MSVC and SKIP_STATIC_CONSTRUCTORS_ON_GCC.
332
333 2017-10-27  Yusuke Suzuki  <utatane.tea@gmail.com>
334
335         [DFG][FTL] Introduce StringSlice
336         https://bugs.webkit.org/show_bug.cgi?id=178934
337
338         Reviewed by Saam Barati.
339
340         String.prototype.slice is one of the most frequently called function in ARES-6/Babylon.
341         This patch introduces StringSlice DFG node to optimize it in DFG and FTL.
342
343         This patch's StringSlice node optimizes the following things.
344
345         1. Empty string generation is accelerated. It is fully executed inline.
346         2. One char string generation is accelerated. `< 0x100` character is supported right now.
347         It is the same to charAt acceleration.
348         3. We calculate start and end index in DFG/FTL with Int32Use information and call optimized
349         operation.
350
351         We do not inline (3)'s operation right now since we do not have a way to call bmalloc allocation from DFG / FTL.
352         And we do not optimize String.prototype.{substring,substr} right now. But they can be optimized based on this change
353         in subsequent changes.
354
355         This patch improves ARES-6/Babylon performance by 3% in steady state.
356
357         Baseline:
358             Running... Babylon ( 1  to go)
359             firstIteration:     50.05 +- 13.68 ms
360             averageWorstCase:   16.80 +- 1.27 ms
361             steadyState:        7.53 +- 0.22 ms
362
363         Patched:
364             Running... Babylon ( 1  to go)
365             firstIteration:     50.91 +- 13.41 ms
366             averageWorstCase:   16.12 +- 0.99 ms
367             steadyState:        7.30 +- 0.29 ms
368
369         * dfg/DFGAbstractInterpreterInlines.h:
370         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
371         * dfg/DFGBackwardsPropagationPhase.cpp:
372         (JSC::DFG::BackwardsPropagationPhase::propagate):
373         * dfg/DFGByteCodeParser.cpp:
374         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
375         * dfg/DFGClobberize.h:
376         (JSC::DFG::clobberize):
377         * dfg/DFGDoesGC.cpp:
378         (JSC::DFG::doesGC):
379         * dfg/DFGFixupPhase.cpp:
380         (JSC::DFG::FixupPhase::fixupNode):
381         * dfg/DFGNodeType.h:
382         * dfg/DFGOperations.cpp:
383         * dfg/DFGOperations.h:
384         * dfg/DFGPredictionPropagationPhase.cpp:
385         * dfg/DFGSafeToExecute.h:
386         (JSC::DFG::safeToExecute):
387         * dfg/DFGSpeculativeJIT.cpp:
388         (JSC::DFG::SpeculativeJIT::compileStringSlice):
389         (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
390         (JSC::DFG::SpeculativeJIT::compileArraySlice):
391         (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
392         * dfg/DFGSpeculativeJIT.h:
393         (JSC::DFG::SpeculativeJIT::callOperation):
394         * dfg/DFGSpeculativeJIT32_64.cpp:
395         (JSC::DFG::SpeculativeJIT::compile):
396         * dfg/DFGSpeculativeJIT64.cpp:
397         (JSC::DFG::SpeculativeJIT::compile):
398         * ftl/FTLCapabilities.cpp:
399         (JSC::FTL::canCompile):
400         * ftl/FTLLowerDFGToB3.cpp:
401         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
402         (JSC::FTL::DFG::LowerDFGToB3::populateSliceRange):
403         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
404         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
405         * jit/JITOperations.h:
406         * runtime/Intrinsic.cpp:
407         (JSC::intrinsicName):
408         * runtime/Intrinsic.h:
409         * runtime/StringPrototype.cpp:
410         (JSC::StringPrototype::finishCreation):
411
412 2017-10-31  JF Bastien  <jfbastien@apple.com>
413
414         WebAssembly: Wasm::IndexOrName has a raw pointer to Name
415         https://bugs.webkit.org/show_bug.cgi?id=176644
416
417         Reviewed by Michael Saboff.
418
419         IndexOrName now keeps a RefPtr to its original NameSection, which
420         holds the Name (or references nullptr if Index). Holding onto the
421         entire section seems like the better thing to do, since backtraces
422         probably contain multiple names from the same Module.
423
424         * JavaScriptCore.xcodeproj/project.pbxproj:
425         * interpreter/Interpreter.cpp:
426         (JSC::GetStackTraceFunctor::operator() const):
427         * interpreter/StackVisitor.h: Frame is no longer POD because of the
428         RefPtr.
429         * runtime/StackFrame.cpp:
430         (JSC::StackFrame::StackFrame):
431         * runtime/StackFrame.h: Drop the union, size is now 40 bytes.
432         (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead.
433         (JSC::StackFrame::wasm): Deleted. Make it a ctor instead.
434         * wasm/WasmBBQPlanInlines.h:
435         (JSC::Wasm::BBQPlan::initializeCallees):
436         * wasm/WasmCallee.cpp:
437         (JSC::Wasm::Callee::Callee):
438         * wasm/WasmCallee.h:
439         (JSC::Wasm::Callee::create):
440         * wasm/WasmFormat.h: Move NameSection to its own header.
441         (JSC::Wasm::isValidNameType):
442         (JSC::Wasm::NameSection::get): Deleted.
443         * wasm/WasmIndexOrName.cpp:
444         (JSC::Wasm::IndexOrName::IndexOrName):
445         (JSC::Wasm::makeString):
446         * wasm/WasmIndexOrName.h:
447         (JSC::Wasm::IndexOrName::IndexOrName):
448         (JSC::Wasm::IndexOrName::isEmpty const):
449         (JSC::Wasm::IndexOrName::isIndex const):
450         * wasm/WasmModuleInformation.cpp:
451         (JSC::Wasm::ModuleInformation::ModuleInformation):
452         * wasm/WasmModuleInformation.h:
453         (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted.
454         * wasm/WasmNameSection.h:
455         (JSC::Wasm::NameSection::get):
456         (JSC::Wasm::NameSection::create): Deleted.
457         * wasm/WasmNameSectionParser.cpp:
458         (JSC::Wasm::NameSectionParser::parse):
459         * wasm/WasmNameSectionParser.h:
460         * wasm/WasmOMGPlan.cpp:
461         (JSC::Wasm::OMGPlan::work):
462
463 2017-10-31  Tim Horton  <timothy_horton@apple.com>
464
465         Clean up some drag and drop feature flags
466         https://bugs.webkit.org/show_bug.cgi?id=179082
467
468         Reviewed by Simon Fraser.
469
470         * Configurations/FeatureDefines.xcconfig:
471
472 2017-10-31  Commit Queue  <commit-queue@webkit.org>
473
474         Unreviewed, rolling out r224243, r224246, and r224248.
475         https://bugs.webkit.org/show_bug.cgi?id=179083
476
477         The patch and fix broke the Windows build. (Requested by
478         mlewis13 on #webkit).
479
480         Reverted changesets:
481
482         "StructureStubInfo should have GPRReg members not int8_ts"
483         https://bugs.webkit.org/show_bug.cgi?id=179071
484         https://trac.webkit.org/changeset/224243
485
486         "Make all register enums be backed by uint8_t."
487         https://bugs.webkit.org/show_bug.cgi?id=179074
488         https://trac.webkit.org/changeset/224246
489
490         "Unreviewed, windows build fix."
491         https://trac.webkit.org/changeset/224248
492
493 2017-10-31  Tim Horton  <timothy_horton@apple.com>
494
495         Fix up some content filtering feature flags
496         https://bugs.webkit.org/show_bug.cgi?id=179079
497
498         Reviewed by Simon Fraser.
499
500         * Configurations/FeatureDefines.xcconfig:
501
502 2017-10-31  Keith Miller  <keith_miller@apple.com>
503
504         Unreviewed, windows build fix.
505
506         * assembler/X86Assembler.h:
507         (JSC::X86Assembler::numberOfRegisters):
508         (JSC::X86Assembler::numberOfSPRegisters):
509         (JSC::X86Assembler::numberOfFPRegisters):
510
511 2017-10-31  Keith Miller  <keith_miller@apple.com>
512
513         Make all register enums be backed by uint8_t.
514         https://bugs.webkit.org/show_bug.cgi?id=179074
515
516         Reviewed by Mark Lam.
517
518         * assembler/ARM64Assembler.h:
519         * assembler/ARMAssembler.h:
520         * assembler/ARMv7Assembler.h:
521         * assembler/MIPSAssembler.h:
522         * assembler/MacroAssembler.h:
523         * assembler/X86Assembler.h:
524
525 2017-10-31  Keith Miller  <keith_miller@apple.com>
526
527         StructureStubInfo should have GPRReg members not int8_ts
528         https://bugs.webkit.org/show_bug.cgi?id=179071
529
530         Reviewed by Michael Saboff.
531
532         This patch makes the various RegisterID enums be backed by
533         uint8_t. This means that we can remove the old int8_t members in
534         StructureStubInfo and replace them with the correct enum types.
535
536         Also, this fixes an indentation issue in ARMv7Assembler.h.
537
538         * assembler/ARM64Assembler.h:
539         * assembler/ARMAssembler.h:
540         * assembler/ARMv7Assembler.h:
541         (JSC::ARMRegisters::asSingle):
542         (JSC::ARMRegisters::asDouble):
543         * assembler/MIPSAssembler.h:
544         * assembler/X86Assembler.h:
545         * bytecode/InlineAccess.cpp:
546         (JSC::InlineAccess::generateSelfPropertyAccess):
547         (JSC::getScratchRegister):
548         * bytecode/PolymorphicAccess.cpp:
549         (JSC::PolymorphicAccess::regenerate):
550         * bytecode/StructureStubInfo.h:
551         (JSC::StructureStubInfo::valueRegs const):
552         * dfg/DFGSpeculativeJIT.cpp:
553         (JSC::DFG::SpeculativeJIT::compileIn):
554         * ftl/FTLLowerDFGToB3.cpp:
555         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
556         * jit/JITInlineCacheGenerator.cpp:
557         (JSC::JITByIdGenerator::JITByIdGenerator):
558         (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
559
560 2017-10-31  Devin Rousso  <webkit@devinrousso.com>
561
562         Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces
563         https://bugs.webkit.org/show_bug.cgi?id=179048
564
565         Reviewed by Mark Lam.
566
567         * inspector/ScriptCallStackFactory.h:
568         * inspector/ScriptCallStackFactory.cpp:
569         (createScriptCallStack):
570         (createScriptCallStackForConsole):
571         (createScriptCallStackFromException):
572
573         * inspector/ConsoleMessage.cpp:
574         (Inspector::ConsoleMessage::autogenerateMetadata):
575         * inspector/JSGlobalObjectInspectorController.cpp:
576         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
577         * inspector/agents/InspectorConsoleAgent.cpp:
578         (Inspector::InspectorConsoleAgent::count):
579         * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
580         (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
581
582 2017-10-31  Carlos Garcia Campos  <cgarcia@igalia.com>
583
584         Unreviewed. Fix GTK+ make distcheck.
585
586         Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run.
587
588         * CMakeLists.txt:
589
590 2017-10-30  Saam Barati  <sbarati@apple.com>
591
592         We need a storeStoreFence before storing to the instruction stream's live variable catch data
593         https://bugs.webkit.org/show_bug.cgi?id=178649
594
595         Reviewed by Keith Miller.
596
597         * bytecode/CodeBlock.cpp:
598         (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
599
600 2017-10-30  Michael Catanzaro  <mcatanzaro@igalia.com>
601
602         [WPE] Fix build warnings
603         https://bugs.webkit.org/show_bug.cgi?id=178899
604
605         Reviewed by Carlos Alberto Lopez Perez.
606
607         * PlatformWPE.cmake:
608
609 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
610
611         [ARMv7] Fix initial start register support in YarrJIT
612         https://bugs.webkit.org/show_bug.cgi?id=178641
613
614         Reviewed by Saam Barati.
615
616         * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the
617         YarrGenerator class. r6 should be avoided since it's already used inside
618         MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it
619         can be used as the frame pointer register when targetting ARM Thumb2.
620
621 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
622
623         [ARM64][Linux] Re-enable Gigacage
624         https://bugs.webkit.org/show_bug.cgi?id=178130
625
626         Reviewed by Michael Catanzaro.
627
628         Guard the current globaladdr opcode implementation for ARM64 with
629         OS(DARWIN) as it's only usable for Mach-O.
630
631         For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers
632         have to be used. The .loh directive can't be used as it's not supported
633         in GCC or the ld linker.
634
635         On every other OS target, a compilation error is thrown.
636
637         * offlineasm/arm64.rb:
638
639 2017-10-27  Devin Rousso  <webkit@devinrousso.com>
640
641         Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created
642         https://bugs.webkit.org/show_bug.cgi?id=178799
643         <rdar://problem/35175805>
644
645         Reviewed by Brian Burg.
646
647         * inspector/protocol/Canvas.json:
648         Add optional `backtrace` to Canvas type that is an array of Console.CallFrame.
649
650 2017-10-27  Yusuke Suzuki  <utatane.tea@gmail.com>
651
652         [JSC] Tweak ES6 generator function to allow inlining
653         https://bugs.webkit.org/show_bug.cgi?id=178935
654
655         Reviewed by Saam Barati.
656
657         We optimize builtins' generator helper functions to allow them inlined in the caller side.
658         This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow
659         them inlined in DFG.
660
661                                        baseline                  patched
662
663         spread-generator.es6      301.2637+-11.1011    ^    260.5905+-14.2258       ^ definitely 1.1561x faster
664         generator.es6             269.6030+-13.2435    ^    148.8840+-6.7614        ^ definitely 1.8108x faster
665
666         * builtins/GeneratorPrototype.js:
667         (globalPrivate.generatorResume):
668         (next):
669         (return):
670         (throw):
671
672 2017-10-27  Saam Barati  <sbarati@apple.com>
673
674         Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
675         https://bugs.webkit.org/show_bug.cgi?id=178949
676
677         Reviewed by Keith Miller.
678
679         This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
680         so that we don't need to recompute liveness for the same UnlinkedCodeBlock
681         more than once. To do this, this patch solidifies the invariant that CodeBlock
682         linking can't do anything that would change the result of liveness. For example,
683         it can't introduce new locals. This invariant was met my JSC before, because we
684         didn't do anything in bytecode linking that would change liveness. However, it is
685         now a correctness requirement that we don't do anything that would change the
686         result of running liveness. To support this change, I've refactored BytecodeGraph
687         to not be tied to a CodeBlockType*. Things that perform liveness will pass in
688         CodeBlockType* and the instruction stream as needed. This means that we may
689         compute liveness with one CodeBlock*'s instruction stream, and then perform
690         queries on that analysis with a different CodeBlock*'s instruction stream.
691
692         This seems to be a 2% JSBench progression.
693
694         * bytecode/BytecodeGeneratorification.cpp:
695         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
696         (JSC::BytecodeGeneratorification::graph):
697         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
698         (JSC::GeneratorLivenessAnalysis::run):
699         (JSC::BytecodeGeneratorification::run):
700         * bytecode/BytecodeGraph.h:
701         (JSC::BytecodeGraph::BytecodeGraph):
702         (JSC::BytecodeGraph::codeBlock const): Deleted.
703         (JSC::BytecodeGraph::instructions): Deleted.
704         (JSC::BytecodeGraph<Block>::BytecodeGraph): Deleted.
705         * bytecode/BytecodeLivenessAnalysis.cpp:
706         (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
707         (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
708         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
709         (JSC::BytecodeLivenessAnalysis::computeKills):
710         (JSC::BytecodeLivenessAnalysis::dumpResults):
711         (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
712         (JSC::BytecodeLivenessAnalysis::compute): Deleted.
713         * bytecode/BytecodeLivenessAnalysis.h:
714         * bytecode/BytecodeLivenessAnalysisInlines.h:
715         (JSC::BytecodeLivenessPropagation::stepOverInstruction):
716         (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
717         (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
718         (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
719         (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
720         * bytecode/BytecodeRewriter.cpp:
721         (JSC::BytecodeRewriter::applyModification):
722         (JSC::BytecodeRewriter::execute):
723         (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
724         * bytecode/BytecodeRewriter.h:
725         (JSC::BytecodeRewriter::BytecodeRewriter):
726         (JSC::BytecodeRewriter::removeBytecode):
727         (JSC::BytecodeRewriter::graph):
728         * bytecode/CodeBlock.cpp:
729         (JSC::CodeBlock::finishCreation):
730         (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
731         (JSC::CodeBlock::validate):
732         (JSC::CodeBlock::livenessAnalysisSlow): Deleted.
733         * bytecode/CodeBlock.h:
734         (JSC::CodeBlock::livenessAnalysis):
735         * bytecode/UnlinkedCodeBlock.cpp:
736         (JSC::UnlinkedCodeBlock::applyModification):
737         (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
738         * bytecode/UnlinkedCodeBlock.h:
739         (JSC::UnlinkedCodeBlock::livenessAnalysis):
740         * dfg/DFGGraph.cpp:
741         (JSC::DFG::Graph::livenessFor):
742         (JSC::DFG::Graph::killsFor):
743         * dfg/DFGPlan.cpp:
744         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
745         * jit/JIT.cpp:
746         (JSC::JIT::privateCompileMainPass):
747
748 2017-10-27  Keith Miller  <keith_miller@apple.com>
749
750         Add unified source list files and build scripts to Xcode project navigator
751         https://bugs.webkit.org/show_bug.cgi?id=178959
752
753         Reviewed by Andy Estes.
754
755         Also, Add some extra source files for so new .cpp/.mm files don't cause the build
756         to fail right away. We already do this in WebCore.
757
758         * JavaScriptCore.xcodeproj/project.pbxproj:
759         * PlatformMac.cmake:
760         * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt.
761
762 2017-10-27  JF Bastien  <jfbastien@apple.com>
763
764         WebAssembly: update arbitrary limits to what browsers use
765         https://bugs.webkit.org/show_bug.cgi?id=178946
766         <rdar://problem/34257412>
767         <rdar://problem/34501154>
768
769         Reviewed by Saam Barati.
770
771         https://github.com/WebAssembly/design/issues/1138 discusses the
772         arbitrary function size limit, which it turns out Chrome and
773         Firefox didn't enforce. We didn't use it because it was
774         ridiculously low and actual programs ran into that limit (bummer
775         for Edge which just shipped it...). Now that we agree on a high
776         arbitrary program limit, let's update it! While I'm doing this
777         there are a few other spots that I polished to use Checked or
778         better check limits overall.
779
780         * wasm/WasmB3IRGenerator.cpp:
781         (JSC::Wasm::B3IRGenerator::addLocal):
782         * wasm/WasmFormat.cpp:
783         (JSC::Wasm::Segment::create):
784         * wasm/WasmFunctionParser.h:
785         (JSC::Wasm::FunctionParser<Context>::parse):
786         * wasm/WasmInstance.cpp:
787         * wasm/WasmLimits.h:
788         * wasm/WasmModuleParser.cpp:
789         (JSC::Wasm::ModuleParser::parseGlobal):
790         (JSC::Wasm::ModuleParser::parseCode):
791         (JSC::Wasm::ModuleParser::parseData):
792         * wasm/WasmSignature.h:
793         (JSC::Wasm::Signature::allocatedSize):
794         * wasm/WasmTable.cpp:
795         (JSC::Wasm::Table::Table):
796         * wasm/js/JSWebAssemblyTable.cpp:
797         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
798         (JSC::JSWebAssemblyTable::grow):
799
800 2017-10-26  Michael Saboff  <msaboff@apple.com>
801
802         REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
803         https://bugs.webkit.org/show_bug.cgi?id=178890
804
805         Reviewed by Keith Miller.
806
807         We need to let a contained subpattern backtrack before declaring that the containing
808         parenthesis doesn't match.  If the subpattern fails to match backtracking, then we
809         can check to see if we trying to backtrack below the minimum match count.
810         
811         * yarr/YarrInterpreter.cpp:
812         (JSC::Yarr::Interpreter::backtrackParentheses):
813
814 2017-10-26  Mark Lam  <mark.lam@apple.com>
815
816         JSRopeString::RopeBuilder::append() should check for overflows.
817         https://bugs.webkit.org/show_bug.cgi?id=178385
818         <rdar://problem/35027468>
819
820         Reviewed by Saam Barati.
821
822         1. Made RopeString check for overflow like the Checked class does.
823         2. Added a missing overflow check in objectProtoFuncToString().
824
825         * runtime/JSString.cpp:
826         (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
827         (JSC::JSRopeString::RopeBuilder::expand): Deleted.
828         * runtime/JSString.h:
829         * runtime/ObjectPrototype.cpp:
830         (JSC::objectProtoFuncToString):
831         * runtime/Operations.h:
832         (JSC::jsStringFromRegisterArray):
833         (JSC::jsStringFromArguments):
834
835 2017-10-26  JF Bastien  <jfbastien@apple.com>
836
837         WebAssembly: no VM / JS version of our implementation
838         https://bugs.webkit.org/show_bug.cgi?id=177472
839
840         Reviewed by Michael Saboff.
841
842         This patch removes all appearances of "JS" and "VM" in the wasm
843         directory. These now only appear in the wasm/js directory, which
844         is only used in a JS embedding of wasm. It should therefore now be
845         possible to create non-JS embeddings of wasm through JSC, though
846         it'll still require:
847
848           - Mild codegen for wasm<->embedder calls;
849           - A strategy for trap handling (no need for full unwind! Could kill).
850           - Creation of the Wasm::* objects.
851           - Calling convention handling to call the embedder.
852           - Handling of multiple embedders (see #177475, this is optional).
853
854         Most of the patch consists in renaming JSWebAssemblyInstance to
855         Instance, and removing temporary copies which I'd added to make
856         this specific patch very simple.
857
858         * interpreter/CallFrame.cpp:
859         (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
860         which needs to know about who "owns" the Wasm::Instance. In a JS
861         embedding it's the JSWebAssemblyInstance.
862         * wasm/WasmB3IRGenerator.cpp:
863         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
864         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
865         (JSC::Wasm::B3IRGenerator::addGrowMemory):
866         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
867         (JSC::Wasm::B3IRGenerator::getGlobal):
868         (JSC::Wasm::B3IRGenerator::setGlobal):
869         (JSC::Wasm::B3IRGenerator::addCall):
870         (JSC::Wasm::B3IRGenerator::addCallIndirect):
871         * wasm/WasmBinding.cpp:
872         (JSC::Wasm::wasmToWasm):
873         * wasm/WasmContext.cpp:
874         (JSC::Wasm::Context::load const):
875         (JSC::Wasm::Context::store):
876         * wasm/WasmContext.h:
877         * wasm/WasmEmbedder.h:
878         * wasm/WasmInstance.cpp:
879         (JSC::Wasm::Instance::Instance):
880         (JSC::Wasm::Instance::create):
881         (JSC::Wasm::Instance::extraMemoryAllocated const):
882         * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
883         "tail" import information from JSWebAssemblyInstance over to here.
884         (JSC::Wasm::Instance::finalizeCreation):
885         (JSC::Wasm::Instance::owner const):
886         (JSC::Wasm::Instance::offsetOfOwner):
887         (JSC::Wasm::Instance::context const):
888         (JSC::Wasm::Instance::setMemory):
889         (JSC::Wasm::Instance::setTable):
890         (JSC::Wasm::Instance::offsetOfMemory):
891         (JSC::Wasm::Instance::offsetOfGlobals):
892         (JSC::Wasm::Instance::offsetOfTable):
893         (JSC::Wasm::Instance::offsetOfTail):
894         (JSC::Wasm::Instance::numImportFunctions const):
895         (JSC::Wasm::Instance::importFunctionInfo):
896         (JSC::Wasm::Instance::offsetOfTargetInstance):
897         (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
898         (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
899         (JSC::Wasm::Instance::offsetOfImportFunction):
900         (JSC::Wasm::Instance::importFunction):
901         (JSC::Wasm::Instance::allocationSize):
902         (JSC::Wasm::Instance::create): Deleted.
903         * wasm/WasmOMGPlan.cpp:
904         (JSC::Wasm::OMGPlan::runForIndex):
905         * wasm/WasmOMGPlan.h:
906         * wasm/WasmTable.cpp:
907         (JSC::Wasm::Table::Table):
908         (JSC::Wasm::Table::setFunction):
909         * wasm/WasmTable.h:
910         * wasm/WasmThunks.cpp:
911         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
912         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
913         * wasm/js/JSToWasm.cpp:
914         (JSC::Wasm::createJSToWasmWrapper):
915         * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
916         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
917         decides what the import function is. Here we must properly
918         placement-new it to what we've elected (and initialize it later).
919         (JSC::JSWebAssemblyInstance::visitChildren):
920         (JSC::JSWebAssemblyInstance::finalizeCreation):
921         (JSC::JSWebAssemblyInstance::create):
922         * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
923         (JSC::JSWebAssemblyInstance::instance):
924         (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
925         (JSC::JSWebAssemblyInstance::setMemory):
926         (JSC::JSWebAssemblyInstance::table):
927         (JSC::JSWebAssemblyInstance::setTable):
928         (JSC::JSWebAssemblyInstance::offsetOfInstance):
929         (JSC::JSWebAssemblyInstance::offsetOfCallee):
930         (JSC::JSWebAssemblyInstance::context const): Deleted.
931         (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
932         (): Deleted.
933         (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
934         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
935         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
936         (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
937         (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
938         (JSC::JSWebAssemblyInstance::importFunction): Deleted.
939         (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
940         (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
941         (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
942         (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
943         (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
944         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
945         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
946         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
947         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
948         (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
949         (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
950         (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
951         (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
952         (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
953         * wasm/js/JSWebAssemblyTable.cpp:
954         (JSC::JSWebAssemblyTable::setFunction):
955         * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
956         (JSC::Wasm::materializeImportJSCell):
957         (JSC::Wasm::handleBadI64Use):
958         (JSC::Wasm::wasmToJS):
959         (JSC::Wasm::wasmToJSException):
960         * wasm/js/WasmToJS.h:
961         * wasm/js/WebAssemblyFunction.cpp:
962         (JSC::callWebAssemblyFunction):
963         * wasm/js/WebAssemblyInstanceConstructor.cpp:
964         (JSC::constructJSWebAssemblyInstance):
965         * wasm/js/WebAssemblyModuleRecord.cpp:
966         (JSC::WebAssemblyModuleRecord::link):
967         (JSC::WebAssemblyModuleRecord::evaluate):
968         * wasm/js/WebAssemblyPrototype.cpp:
969         (JSC::instantiate):
970         * wasm/js/WebAssemblyWrapperFunction.cpp:
971         (JSC::WebAssemblyWrapperFunction::create):
972
973 2017-10-25  Devin Rousso  <webkit@devinrousso.com>
974
975         Web Inspector: provide a way to enable/disable event listeners
976         https://bugs.webkit.org/show_bug.cgi?id=177451
977         <rdar://problem/34994925>
978
979         Reviewed by Joseph Pecoraro.
980
981         * inspector/protocol/DOM.json:
982         Add `setEventListenerDisabled` command that enables/disables a specific event listener
983         during event dispatch. When a disabled event listener is fired, the listener's callback will
984         not be called.
985
986 2017-10-25  Commit Queue  <commit-queue@webkit.org>
987
988         Unreviewed, rolling out r223691 and r223729.
989         https://bugs.webkit.org/show_bug.cgi?id=178834
990
991         Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
992         by rniwa on #webkit).
993
994         Reverted changesets:
995
996         "Turn recursive tail calls into loops"
997         https://bugs.webkit.org/show_bug.cgi?id=176601
998         https://trac.webkit.org/changeset/223691
999
1000         "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
1001         comparison is always false due to limited range of data type
1002         [-Wtype-limits]"
1003         https://bugs.webkit.org/show_bug.cgi?id=178543
1004         https://trac.webkit.org/changeset/223729
1005
1006 2017-10-25  Michael Saboff  <msaboff@apple.com>
1007
1008         REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
1009         https://bugs.webkit.org/show_bug.cgi?id=178825
1010
1011         Reviewed by Mark Lam.
1012
1013         Enable ARC for ARM64_32.  This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.
1014
1015         * Configurations/ToolExecutable.xcconfig:
1016
1017 2017-10-25  Keith Miller  <keith_miller@apple.com>
1018
1019         Fix implicit cast of enum, which seems to break the windows build of unified sources.
1020         https://bugs.webkit.org/show_bug.cgi?id=178822
1021
1022         Reviewed by Saam Barati.
1023
1024         * bytecode/DFGExitProfile.h:
1025         (JSC::DFG::FrequentExitSite::hash const):
1026
1027 2017-10-24  Michael Saboff  <msaboff@apple.com>
1028
1029         Allow OjbC Weak References when building TestAPI
1030         https://bugs.webkit.org/show_bug.cgi?id=178748
1031
1032         Reviewed by Dan Bernstein.
1033
1034         Set TestAPI build flag Weak References in Manual Retain Release to true.
1035
1036         * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
1037         * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.
1038
1039 2017-10-24  Eric Carlson  <eric.carlson@apple.com>
1040
1041         Web Inspector: Enable WebKit logging configuration and display
1042         https://bugs.webkit.org/show_bug.cgi?id=177027
1043         <rdar://problem/33964767>
1044
1045         Reviewed by Joseph Pecoraro.
1046
1047         * inspector/ConsoleMessage.cpp:
1048         (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage -> 
1049             Inspector::Protocol::Console::ChannelSource.
1050         * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
1051         (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
1052             specific to a JSContext yet, so return an empty channel array.
1053         (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
1054         * inspector/agents/JSGlobalObjectConsoleAgent.h:
1055
1056         * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
1057             and setLoggingChannelLevel.
1058
1059         * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
1060         * inspector/scripts/tests/generic/expected/enum-values.json-result:
1061         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
1062         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
1063         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1064         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1065
1066         * runtime/ConsoleTypes.h: Add Media and WebRTC.
1067
1068 2017-10-24  Michael Saboff  <msaboff@apple.com>
1069
1070         Allow OjbC Weak References when building TestAPI
1071         https://bugs.webkit.org/show_bug.cgi?id=178748
1072
1073         Reviewed by Saam Barati.
1074
1075         Set TestAPI build flag Weak References in Manual Retain Release to true.
1076
1077         * JavaScriptCore.xcodeproj/project.pbxproj:
1078
1079 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1080
1081         [FTL] Support NewStringObject
1082         https://bugs.webkit.org/show_bug.cgi?id=178737
1083
1084         Reviewed by Saam Barati.
1085
1086         FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
1087         After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.
1088
1089         * ftl/FTLAbstractHeapRepository.h:
1090         * ftl/FTLCapabilities.cpp:
1091         (JSC::FTL::canCompile):
1092         * ftl/FTLLowerDFGToB3.cpp:
1093         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1094         (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
1095
1096 2017-10-24  Guillaume Emont  <guijemont@igalia.com>
1097
1098         [mips] fix offsets of branches that have to go over a jump
1099         https://bugs.webkit.org/show_bug.cgi?id=153464
1100
1101         The jump() function creates 8 instructions, but the offsets of branches
1102         meant to go over them only account for 6. In most cases, this is not an
1103         issue as the last two instructions of jump() would be nops, but in the
1104         rarer case where the jump destination is in a different 256 MB segment,
1105         MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
1106         the last 4 instructions would be a 2 instruction load (lui/ori) into
1107         $t9, a "j $t9" and then a nop. The wrong offset will mean that the
1108         previous branches meant to go over the whole jump will branch to the
1109         "j $t9" instruction, which would jump to whatever is currently in $t9
1110         (since lui/ori would not be executed).
1111
1112         Reviewed by Michael Catanzaro.
1113
1114         * assembler/MacroAssemblerMIPS.h:
1115         (JSC::MacroAssemblerMIPS::branchAdd32):
1116         (JSC::MacroAssemblerMIPS::branchMul32):
1117         (JSC::MacroAssemblerMIPS::branchSub32):
1118         Fix the offsets of branches meant to go over code generated by jump().
1119
1120 2017-10-24  JF Bastien  <jfbastien@apple.com>
1121
1122         WebAssembly: NFC renames of things that aren't JS-specific
1123         https://bugs.webkit.org/show_bug.cgi?id=178738
1124
1125         Reviewed by Saam Barati.
1126
1127         * wasm/WasmB3IRGenerator.cpp:
1128         (JSC::Wasm::parseAndCompile):
1129         * wasm/WasmB3IRGenerator.h:
1130         * wasm/WasmBBQPlan.cpp:
1131         (JSC::Wasm::BBQPlan::complete):
1132         * wasm/WasmCodeBlock.cpp:
1133         (JSC::Wasm::CodeBlock::CodeBlock):
1134         * wasm/WasmCodeBlock.h:
1135         (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
1136         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
1137         * wasm/WasmFormat.h:
1138         * wasm/js/JSToWasm.cpp:
1139         (JSC::Wasm::createJSToWasmWrapper):
1140         * wasm/js/WebAssemblyModuleRecord.cpp:
1141         (JSC::WebAssemblyModuleRecord::link):
1142         (JSC::WebAssemblyModuleRecord::evaluate):
1143
1144 2017-10-24  Stephan Szabo  <stephan.szabo@sony.com>
1145
1146         [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
1147         https://bugs.webkit.org/show_bug.cgi?id=177279
1148
1149         Reviewed by Yusuke Suzuki.
1150
1151         * shell/PlatformJSCOnly.cmake: Added.
1152
1153 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1154
1155         [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
1156         https://bugs.webkit.org/show_bug.cgi?id=178308
1157
1158         Reviewed by Mark Lam.
1159
1160         With the change of the spec[1], we now do not need to remember star resolution modules.
1161         We reflect this change to our implementation. Since this change is covered by test262,
1162         this patch improves the score of test262.
1163
1164         We also add logging to ResolveExport to debug it easily.
1165
1166         [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1
1167
1168         * runtime/AbstractModuleRecord.cpp:
1169         (JSC::AbstractModuleRecord::ResolveQuery::dump const):
1170         (JSC::AbstractModuleRecord::resolveExportImpl):
1171
1172 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1173
1174         [JSC] Use emitDumbVirtualCall in 32bit JIT
1175         https://bugs.webkit.org/show_bug.cgi?id=178644
1176
1177         Reviewed by Mark Lam.
1178
1179         This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.
1180
1181         * jit/JITCall32_64.cpp:
1182         (JSC::JIT::compileCallEvalSlowCase):
1183
1184 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1185
1186         [JSC] Drop ArityCheckData
1187         https://bugs.webkit.org/show_bug.cgi?id=178648
1188
1189         Reviewed by Mark Lam.
1190
1191         ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
1192         However, use of `thunkToCall` is removed in 64bit environment at r189575.
1193
1194         We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
1195         Since we no longer need to have the above pair, we can remove ArityCheckData too.
1196
1197         * llint/LowLevelInterpreter32_64.asm:
1198         * llint/LowLevelInterpreter64.asm:
1199         * runtime/CommonSlowPaths.cpp:
1200         (JSC::SLOW_PATH_DECL):
1201         (JSC::setupArityCheckData): Deleted.
1202         * runtime/CommonSlowPaths.h:
1203         * runtime/VM.cpp:
1204         (JSC::VM::VM):
1205         * runtime/VM.h:
1206
1207 2017-10-23  Keith Miller  <keith_miller@apple.com>
1208
1209         Unreviewed, reland r223866
1210
1211         Didn't break the windows build...
1212
1213         Restored changeset:
1214
1215         "WebAssembly: topEntryFrame on Wasm::Instance"
1216         https://bugs.webkit.org/show_bug.cgi?id=178690
1217         https://trac.webkit.org/changeset/223866
1218
1219
1220 2017-10-23  Commit Queue  <commit-queue@webkit.org>
1221
1222         Unreviewed, rolling out r223866.
1223         https://bugs.webkit.org/show_bug.cgi?id=178699
1224
1225         Probably broke the windows build (Requested by keith_miller on
1226         #webkit).
1227
1228         Reverted changeset:
1229
1230         "WebAssembly: topEntryFrame on Wasm::Instance"
1231         https://bugs.webkit.org/show_bug.cgi?id=178690
1232         https://trac.webkit.org/changeset/223866
1233
1234 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
1235
1236         Web Inspector: Remove unused Console.setMonitoringXHREnabled
1237         https://bugs.webkit.org/show_bug.cgi?id=178617
1238
1239         Reviewed by Sam Weinig.
1240
1241         * JavaScriptCore.xcodeproj/project.pbxproj:
1242         * Sources.txt:
1243         * inspector/agents/InspectorConsoleAgent.h:
1244         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1245         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1246         * inspector/protocol/Console.json:
1247         Removed files and method.
1248
1249         * inspector/JSGlobalObjectInspectorController.cpp:
1250         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1251         This can use the base ConsoleAgent now.
1252
1253 2017-10-23  JF Bastien  <jfbastien@apple.com>
1254
1255         WebAssembly: topEntryFrame on Wasm::Instance
1256         https://bugs.webkit.org/show_bug.cgi?id=178690
1257
1258         Reviewed by Saam Barati.
1259
1260         topEntryFrame is usually on VM, but for a no-VM WebAssembly we
1261         need to hold topEntryFrame elsewhere, and generated code cannot
1262         hard-code where topEntryFrame live. Do this at creation time of
1263         Wasm::Instance, and then generated code will just load from
1264         wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
1265         embedding this is still from VM, so all of the unwinding machinery
1266         stays the same.
1267
1268         * dfg/DFGOSREntry.cpp:
1269         (JSC::DFG::prepareOSREntry):
1270         * dfg/DFGOSRExit.cpp:
1271         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
1272         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1273         * ftl/FTLOSRExitCompiler.cpp:
1274         (JSC::FTL::compileStub):
1275         * interpreter/Interpreter.cpp:
1276         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1277         * jit/AssemblyHelpers.cpp:
1278         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1279         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1280         * jit/AssemblyHelpers.h:
1281         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1282         The default parameter was never non-defaulted from any of the
1283         callers. The new version calls the impl directly because it
1284         doesn't have VM and doesn't hard-code the address of
1285         topEntryFrame.
1286         * jit/RegisterSet.cpp:
1287         (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
1288         VM because it's not really VM-specific.
1289         * jit/RegisterSet.h:
1290         * runtime/VM.cpp:
1291         (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
1292         * runtime/VM.h:
1293         (JSC::VM::getCTIStub):
1294         * wasm/WasmB3IRGenerator.cpp:
1295         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1296         (JSC::Wasm::B3IRGenerator::addCall):
1297         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1298         * wasm/WasmInstance.cpp:
1299         (JSC::Wasm::Instance::Instance):
1300         * wasm/WasmInstance.h: topEntryFramePointer will eventually live
1301         here for real. Right now it's mirrored in JSWebAssemblyInstance
1302         because that's the acting Context.
1303         (JSC::Wasm::Instance::create):
1304         (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
1305         * wasm/WasmThunks.cpp:
1306         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1307         * wasm/js/JSWebAssemblyInstance.cpp:
1308         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1309         * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
1310         (JSC::JSWebAssemblyInstance::offsetOfCallee):
1311         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
1312         (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
1313         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1314         (JSC::constructJSWebAssemblyInstance):
1315         * wasm/js/WebAssemblyPrototype.cpp:
1316         (JSC::instantiate):
1317
1318 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
1319
1320         Web Inspector: Please support HAR Export for network traffic
1321         https://bugs.webkit.org/show_bug.cgi?id=146692
1322         <rdar://problem/7463672>
1323
1324         Reviewed by Brian Burg.
1325
1326         * inspector/protocol/Network.json:
1327         Add a walltime to each send request.
1328
1329 2017-10-23  Matt Lewis  <jlewis3@apple.com>
1330
1331         Unreviewed, rolling out r223820.
1332
1333         This caused a build break on Windows.
1334
1335         Reverted changeset:
1336
1337         "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
1338         https://bugs.webkit.org/show_bug.cgi?id=178617
1339         https://trac.webkit.org/changeset/223820
1340
1341 2017-10-23  Yusuke Suzuki  <utatane.tea@gmail.com>
1342
1343         [JSC] Use fastJoin in Array#toString
1344         https://bugs.webkit.org/show_bug.cgi?id=178062
1345
1346         Reviewed by Darin Adler.
1347
1348         Array#toString()'s fast path uses original join operation.
1349         But this should use fastJoin if possible.
1350         This patch adds a fast path using fastJoin in Array#toString.
1351         And we also extend fastJoin to perform fast joining for int32
1352         arrays.
1353
1354                                              baseline                  patched
1355
1356         double-array-to-string          126.6157+-5.8625     ^    103.7343+-4.4968        ^ definitely 1.2206x faster
1357         int32-array-to-string            64.7792+-2.6524           61.2390+-2.1749          might be 1.0578x faster
1358         contiguous-array-to-string       62.6224+-2.6388     ^     56.9899+-2.0852        ^ definitely 1.0988x faster
1359
1360
1361         * runtime/ArrayPrototype.cpp:
1362         (JSC::fastJoin):
1363         (JSC::arrayProtoFuncToString):
1364         (JSC::arrayProtoFuncToLocaleString):
1365         * runtime/JSStringJoiner.h:
1366         (JSC::JSStringJoiner::appendWithoutSideEffects):
1367         (JSC::JSStringJoiner::appendInt32):
1368         (JSC::JSStringJoiner::appendDouble):
1369
1370 2017-10-22  Zan Dobersek  <zdobersek@igalia.com>
1371
1372         [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
1373         https://bugs.webkit.org/show_bug.cgi?id=178452
1374
1375         Reviewed by Yusuke Suzuki.
1376
1377         * heap/RegisterState.h: Re-enable the custom RegisterState and
1378         ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
1379         cause any crashes nowadays.
1380
1381 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1382
1383         [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
1384         https://bugs.webkit.org/show_bug.cgi?id=178647
1385
1386         Reviewed by Saam Barati.
1387
1388         There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
1389         since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
1390         which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
1391         this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
1392
1393         * jit/JIT.h:
1394         (JSC::JIT::linkAllSlowCases):
1395         * jit/JITArithmetic.cpp:
1396         (JSC::JIT::emitSlow_op_unsigned):
1397         (JSC::JIT::emit_compareAndJump):
1398         (JSC::JIT::emit_compareAndJumpSlow):
1399         (JSC::JIT::emitSlow_op_inc):
1400         (JSC::JIT::emitSlow_op_dec):
1401         (JSC::JIT::emitSlow_op_mod):
1402         (JSC::JIT::emitSlow_op_negate):
1403         (JSC::JIT::emitSlow_op_bitand):
1404         (JSC::JIT::emitSlow_op_bitor):
1405         (JSC::JIT::emitSlow_op_bitxor):
1406         (JSC::JIT::emitSlow_op_lshift):
1407         (JSC::JIT::emitSlow_op_rshift):
1408         (JSC::JIT::emitSlow_op_urshift):
1409         (JSC::JIT::emitSlow_op_add):
1410         (JSC::JIT::emitSlow_op_div):
1411         (JSC::JIT::emitSlow_op_mul):
1412         (JSC::JIT::emitSlow_op_sub):
1413         * jit/JITArithmetic32_64.cpp:
1414         (JSC::JIT::emit_compareAndJumpSlow):
1415         (JSC::JIT::emitSlow_op_unsigned):
1416         (JSC::JIT::emitSlow_op_inc):
1417         (JSC::JIT::emitSlow_op_dec):
1418         (JSC::JIT::emitSlow_op_mod):
1419         * jit/JITCall.cpp:
1420         (JSC::JIT::compileCallEvalSlowCase):
1421         (JSC::JIT::compileOpCallSlowCase):
1422         * jit/JITCall32_64.cpp:
1423         (JSC::JIT::compileCallEvalSlowCase):
1424         (JSC::JIT::compileOpCallSlowCase):
1425         * jit/JITInlines.h:
1426         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
1427         * jit/JITOpcodes.cpp:
1428         (JSC::JIT::emitSlow_op_new_object):
1429         (JSC::JIT::emitSlow_op_create_this):
1430         (JSC::JIT::emitSlow_op_check_tdz):
1431         (JSC::JIT::emitSlow_op_to_this):
1432         (JSC::JIT::emitSlow_op_to_primitive):
1433         (JSC::JIT::emitSlow_op_not):
1434         (JSC::JIT::emitSlow_op_eq):
1435         (JSC::JIT::emitSlow_op_neq):
1436         (JSC::JIT::emitSlow_op_stricteq):
1437         (JSC::JIT::emitSlow_op_nstricteq):
1438         (JSC::JIT::emitSlow_op_instanceof):
1439         (JSC::JIT::emitSlow_op_instanceof_custom):
1440         (JSC::JIT::emitSlow_op_to_number):
1441         (JSC::JIT::emitSlow_op_to_string):
1442         (JSC::JIT::emitSlow_op_loop_hint):
1443         (JSC::JIT::emitSlow_op_check_traps):
1444         (JSC::JIT::emitSlow_op_has_indexed_property):
1445         (JSC::JIT::emitSlow_op_get_direct_pname):
1446         (JSC::JIT::emitSlow_op_has_structure_property):
1447         * jit/JITOpcodes32_64.cpp:
1448         (JSC::JIT::emitSlow_op_new_object):
1449         (JSC::JIT::emitSlow_op_instanceof):
1450         (JSC::JIT::emitSlow_op_instanceof_custom):
1451         (JSC::JIT::emitSlow_op_to_primitive):
1452         (JSC::JIT::emitSlow_op_not):
1453         (JSC::JIT::emitSlow_op_stricteq):
1454         (JSC::JIT::emitSlow_op_nstricteq):
1455         (JSC::JIT::emitSlow_op_to_number):
1456         (JSC::JIT::emitSlow_op_to_string):
1457         (JSC::JIT::emitSlow_op_create_this):
1458         (JSC::JIT::emitSlow_op_to_this):
1459         (JSC::JIT::emitSlow_op_check_tdz):
1460         (JSC::JIT::emitSlow_op_has_indexed_property):
1461         (JSC::JIT::emitSlow_op_get_direct_pname):
1462         * jit/JITPropertyAccess.cpp:
1463         (JSC::JIT::emitSlow_op_try_get_by_id):
1464         (JSC::JIT::emitSlow_op_get_by_id):
1465         (JSC::JIT::emitSlow_op_get_by_id_with_this):
1466         (JSC::JIT::emitSlow_op_put_by_id):
1467         (JSC::JIT::emitSlow_op_resolve_scope):
1468         (JSC::JIT::emitSlow_op_get_from_scope):
1469         (JSC::JIT::emitSlow_op_put_to_scope):
1470         * jit/JITPropertyAccess32_64.cpp:
1471         (JSC::JIT::emitSlow_op_try_get_by_id):
1472         (JSC::JIT::emitSlow_op_get_by_id):
1473         (JSC::JIT::emitSlow_op_get_by_id_with_this):
1474         (JSC::JIT::emitSlow_op_put_by_id):
1475         (JSC::JIT::emitSlow_op_resolve_scope):
1476         (JSC::JIT::emitSlow_op_get_from_scope):
1477         (JSC::JIT::emitSlow_op_put_to_scope):
1478
1479 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1480
1481         [JSC] Clean up baseline slow path
1482         https://bugs.webkit.org/show_bug.cgi?id=178646
1483
1484         Reviewed by Saam Barati.
1485
1486         If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
1487         It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
1488         function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
1489         code in baseline JIT.
1490
1491         * jit/JIT.cpp:
1492         (JSC::JIT::privateCompileMainPass):
1493         * jit/JIT.h:
1494         * jit/JITArithmetic.cpp:
1495         (JSC::JIT::emit_op_pow): Deleted.
1496         * jit/JITArithmetic32_64.cpp:
1497         (JSC::JIT::emitSlow_op_mod):
1498         * jit/JITOpcodes.cpp:
1499         (JSC::JIT::emit_op_strcat): Deleted.
1500         (JSC::JIT::emit_op_push_with_scope): Deleted.
1501         (JSC::JIT::emit_op_assert): Deleted.
1502         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1503         (JSC::JIT::emit_op_throw_static_error): Deleted.
1504         (JSC::JIT::emit_op_new_array_with_spread): Deleted.
1505         (JSC::JIT::emit_op_spread): Deleted.
1506         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
1507         (JSC::JIT::emit_op_has_generic_property): Deleted.
1508         (JSC::JIT::emit_op_get_property_enumerator): Deleted.
1509         (JSC::JIT::emit_op_to_index_string): Deleted.
1510         (JSC::JIT::emit_op_create_direct_arguments): Deleted.
1511         (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
1512         (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
1513         (JSC::JIT::emit_op_create_rest): Deleted.
1514         (JSC::JIT::emit_op_unreachable): Deleted.
1515         * jit/JITOpcodes32_64.cpp:
1516         (JSC::JIT::emit_op_strcat): Deleted.
1517         (JSC::JIT::emit_op_push_with_scope): Deleted.
1518         (JSC::JIT::emit_op_assert): Deleted.
1519         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1520         * jit/JITPropertyAccess.cpp:
1521         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
1522         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
1523         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
1524         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
1525         (JSC::JIT::emit_op_define_data_property): Deleted.
1526         (JSC::JIT::emit_op_define_accessor_property): Deleted.
1527         * jit/JITPropertyAccess32_64.cpp:
1528         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
1529         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
1530         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
1531         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
1532
1533 2017-10-21  Joseph Pecoraro  <pecoraro@apple.com>
1534
1535         Web Inspector: Remove unused Console.setMonitoringXHREnabled
1536         https://bugs.webkit.org/show_bug.cgi?id=178617
1537
1538         Reviewed by Sam Weinig.
1539
1540         * JavaScriptCore.xcodeproj/project.pbxproj:
1541         * Sources.txt:
1542         * inspector/agents/InspectorConsoleAgent.h:
1543         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1544         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1545         * inspector/protocol/Console.json:
1546         Removed files and method.
1547
1548         * inspector/JSGlobalObjectInspectorController.cpp:
1549         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1550         This can use the base ConsoleAgent now.
1551
1552 2017-10-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1553
1554         [JSC] Remove per-host-function CTI stub in 32bit environment
1555         https://bugs.webkit.org/show_bug.cgi?id=178581
1556
1557         Reviewed by Saam Barati.
1558
1559         JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
1560         The only difference is that it embed the address of the host function directly in the generated stub. This means
1561         that we have per-host-function CTI stub only in 32bit environment.
1562
1563         This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
1564
1565         * jit/JIT.cpp:
1566         (JSC::JIT::compileCTINativeCall): Deleted.
1567         * jit/JIT.h:
1568         * jit/JITOpcodes.cpp:
1569         (JSC::JIT::privateCompileCTINativeCall): Deleted.
1570         * jit/JITOpcodes32_64.cpp:
1571         (JSC::JIT::privateCompileCTINativeCall): Deleted.
1572         * jit/JITThunks.cpp:
1573         (JSC::JITThunks::hostFunctionStub):
1574
1575 2017-10-20  Antoine Quint  <graouts@apple.com>
1576
1577         [Web Animations] Provide basic timeline and animation interfaces
1578         https://bugs.webkit.org/show_bug.cgi?id=178526
1579
1580         Reviewed by Dean Jackson.
1581
1582         Remove the WEB_ANIMATIONS compile-time flag.
1583
1584         * Configurations/FeatureDefines.xcconfig:
1585
1586 2017-10-20  Commit Queue  <commit-queue@webkit.org>
1587
1588         Unreviewed, rolling out r223744, r223750, and r223751.
1589         https://bugs.webkit.org/show_bug.cgi?id=178594
1590
1591         These caused consistent failures in test that existed and were
1592         added in the patches. (Requested by mlewis13 on #webkit).
1593
1594         Reverted changesets:
1595
1596         "[JSC] ScriptFetcher should be notified directly from module
1597         pipeline"
1598         https://bugs.webkit.org/show_bug.cgi?id=178340
1599         https://trac.webkit.org/changeset/223744
1600
1601         "Unreviewed, fix changed line number in test expect files"
1602         https://bugs.webkit.org/show_bug.cgi?id=178340
1603         https://trac.webkit.org/changeset/223750
1604
1605         "Unreviewed, follow up to reflect comments"
1606         https://bugs.webkit.org/show_bug.cgi?id=178340
1607         https://trac.webkit.org/changeset/223751
1608
1609 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1610
1611         Unreviewed, follow up to reflect comments
1612         https://bugs.webkit.org/show_bug.cgi?id=178340
1613
1614         * runtime/JSModuleLoader.cpp:
1615         (JSC::JSModuleLoader::notifyCompleted):
1616
1617 2017-10-20  Saam Barati  <sbarati@apple.com>
1618
1619         Optimize accesses to how we get the direct prototype
1620         https://bugs.webkit.org/show_bug.cgi?id=178548
1621
1622         Reviewed by Yusuke Suzuki.
1623
1624         This patch makes JSObject::getPrototypeDirect take VM& as a parameter
1625         so it can use the faster version of the structure accessor function.
1626         The reason for making this change is that JSObjet::getPrototypeDirect
1627         is called on the hot path in property lookup.
1628
1629         * API/JSObjectRef.cpp:
1630         (JSObjectGetPrototype):
1631         * jsc.cpp:
1632         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
1633         (WTF::DOMJITGetterBaseJSObject::customGetter):
1634         (functionCreateProxy):
1635         * runtime/ArrayPrototype.cpp:
1636         (JSC::speciesWatchpointIsValid):
1637         * runtime/ErrorInstance.cpp:
1638         (JSC::ErrorInstance::sanitizedToString):
1639         * runtime/JSArray.cpp:
1640         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
1641         * runtime/JSGlobalObject.cpp:
1642         (JSC::JSGlobalObject::init):
1643         (JSC::lastInPrototypeChain):
1644         (JSC::JSGlobalObject::resetPrototype):
1645         (JSC::JSGlobalObject::finishCreation):
1646         * runtime/JSGlobalObjectInlines.h:
1647         (JSC::JSGlobalObject::objectPrototypeIsSane):
1648         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
1649         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
1650         * runtime/JSLexicalEnvironment.cpp:
1651         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
1652         * runtime/JSMap.cpp:
1653         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
1654         * runtime/JSObject.cpp:
1655         (JSC::JSObject::calculatedClassName):
1656         (JSC::JSObject::setPrototypeWithCycleCheck):
1657         (JSC::JSObject::getPrototype):
1658         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
1659         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
1660         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
1661         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
1662         * runtime/JSObject.h:
1663         (JSC::JSObject::finishCreation):
1664         (JSC::JSObject::getPrototypeDirect const):
1665         (JSC::JSObject::getPrototype):
1666         * runtime/JSObjectInlines.h:
1667         (JSC::JSObject::canPerformFastPutInline):
1668         (JSC::JSObject::getPropertySlot):
1669         (JSC::JSObject::getNonIndexPropertySlot):
1670         * runtime/JSProxy.cpp:
1671         (JSC::JSProxy::setTarget):
1672         * runtime/JSSet.cpp:
1673         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
1674         * runtime/ProgramExecutable.cpp:
1675         (JSC::ProgramExecutable::initializeGlobalProperties):
1676         * runtime/StructureInlines.h:
1677         (JSC::Structure::isValid const):
1678
1679 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1680
1681         [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
1682         https://bugs.webkit.org/show_bug.cgi?id=178379
1683
1684         Reviewed by Saam Barati.
1685
1686         We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
1687         in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
1688
1689         * bytecompiler/NodesCodegen.cpp:
1690         (JSC::BinaryOpNode::emitBytecode):
1691
1692 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1693
1694         [JSC] ScriptFetcher should be notified directly from module pipeline
1695         https://bugs.webkit.org/show_bug.cgi?id=178340
1696
1697         Reviewed by Sam Weinig.
1698
1699         Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
1700         We setup JSStdFunction to the resulted promise of the module pipeline. It is super
1701         ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
1702         JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
1703
1704         But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
1705         notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
1706         from the module pipeline by observer style.
1707
1708         This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
1709         completion/failure notifications from the module pipeline.
1710
1711         * builtins/ModuleLoaderPrototype.js:
1712         (loadModule):
1713         (loadAndEvaluateModule):
1714         * runtime/Completion.cpp:
1715         (JSC::loadModule):
1716         * runtime/Completion.h:
1717         * runtime/JSModuleLoader.cpp:
1718         (JSC::jsValueToModuleKey):
1719         (JSC::JSModuleLoader::notifyCompleted):
1720         (JSC::JSModuleLoader::notifyFailed):
1721         * runtime/JSModuleLoader.h:
1722         * runtime/ModuleLoaderPrototype.cpp:
1723         (JSC::moduleLoaderPrototypeNotifyCompleted):
1724         (JSC::moduleLoaderPrototypeNotifyFailed):
1725         * runtime/ScriptFetcher.h:
1726         (JSC::ScriptFetcher::notifyLoadCompleted):
1727         (JSC::ScriptFetcher::notifyLoadFailed):
1728
1729 2017-10-19  JF Bastien  <jfbastien@apple.com>
1730
1731         WebAssembly: no VM / JS version of everything but Instance
1732         https://bugs.webkit.org/show_bug.cgi?id=177473
1733
1734         Reviewed by Filip Pizlo, Saam Barati.
1735
1736         This change entails cleaning up and splitting a bunch of code which we had
1737         intertwined between C++ classes which represent JS objects, and pure C++
1738         implementation objects. This specific change goes most of the way towards
1739         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
1740         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
1741         yet). Because of this we still have a few FIXME identifying places that need to
1742         change. A follow-up change will go the rest of the way.
1743
1744         I went about this change in the simplest way possible: grep the
1745         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
1746         sub-directory (which contains the JS implementation of WebAssembly).
1747
1748         None of this change removes the need for a JIT entitlement to be able to use
1749         WebAssembly. We don't have an interpreter, the process therefore still needs to
1750         be allowed to JIT to use these pure-C++ APIs.
1751
1752         Interesting things to note:
1753
1754           - Remove VM from Plan and associated places. It can just live as a capture in
1755             the callback lambda if it's needed.
1756           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
1757             collect. We now instead pass two lambdas at construction time for this
1758             purpose: one to notify of memory pressure, and the other to ask for
1759             syncrhonous memory reclamation. This allows whoever creates the memory to
1760             dictate how to react to both these cases, and for a JS embedding that's to
1761             call the GC (async or sync, respectively).
1762           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
1763             there, with an enum class for failure types.
1764           - Exceeding max on memory growth now returns a range error as per spec. This
1765             is a (very minor) breaking change: it used to throw OOM error. Update the
1766             corresponding test.
1767           - When generating the grow_memory opcode, no need to get the VM. Instead,
1768             reach directly for Wasm::Memory and grow it.
1769           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
1770             ever called from JS (not from grow_memory as before).
1771           - Wasm::Memory now takes a callback for successful growth. This allows JS
1772             wrappers to register themselves when growth succeeds without Wasm::Memory
1773             knowning anything about JS. It'll also allow creating a list of callbacks
1774             for when we add thread support (we'll want to notify many wrappers, all
1775             under a lock).
1776           - Wasm::Memory is now back to being the source of truth about address / size,
1777             used directly by generated code instead of JSWebAssemblyMemory.
1778           - Move wasmToJS from the general WasmBinding header to its own header under
1779             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
1780             and therefore isn't general WebAssembly.
1781           - Make Wasm::Context an actual type (just a struct holding a
1782             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
1783             doesn't add anything to the Context and doesn't change what actually gets
1784             passed around in JIT code (fast TLS or registers) because these changes
1785             potentially impact performance. The entire purpose of this change is to
1786             allow passing Wasm::Context around without having to know about VM. Since VM
1787             contains a Wasm::Context the JS embedding is effectively the same, but with
1788             this setup a non-JS embedding is much better off.
1789           - Move JSWebAssembly into the JS folder.
1790           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
1791           - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
1792             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
1793             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
1794             called wasm->JS stub. This move means that the embedder must, after creating
1795             a Wasm::CodeBlock, somehow create the stubs to call back into the
1796             embedder. This removes an indirection in the generated code because
1797             the B3 IR generator now reaches into the instance instead of
1798             JSWebAssemblyCodeBlock.
1799           - Move more CodeBlock things. Compilation completion is now marked by its own
1800             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
1801             was causing a deadlock in stack-trace.js because before my changes
1802             JSWebAssemblyCodeBlock did its own completion checking separately from
1803             Wasm::CodeBlock, without getting the lock. Now that everything points to
1804             Wasm::CodeBlock and there's no cached completion marker, the lock was being
1805             acquired in a sanity-check assertion.
1806           - Embedder -> Wasm wrappers are now generated through a function that's passed
1807             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
1808           - WasmMemory doens't need to know about fault handling thunks. Only the IR
1809             generator should know, and should make sure that the exception throwing
1810             thunk is generated if any memory is present (note: with signal handling not
1811             all of them generate an exception check).
1812           - Make exception throwing pluggable: instead of having a hard-coded
1813             JS-specific lambda we now have a regular C++ function being called from JIT
1814             code when a WebAssembly exception is thrown. This allows any embedder to get
1815             called as they wish. For now a process can only have a single of these
1816             functions (i.e. only one embedder per process) because the trap handler is a
1817             singleton. That can be fixed in in #177475.
1818           - Create WasmEmbedder.h where all embedder plugging will live.
1819           - Split up JSWebAssemblyTable into Wasm::Table which is
1820             refcounted. JSWebAssemblyTable now only contains the JS functions in the
1821             table, and Wasm::Table is what's used by the JIT code to lookup where to
1822             call and do the instance check (for context switch). Note that this creates
1823             an extra allocation for all the instances in Wasm::Table, and in exchange
1824             removes an indirection in JIT code because the instance used to be obtained
1825             off of the JS function. Also note that it's the embedder than keeps the
1826             instances alive, not Wasm::Table (which holds a dumb pointer to the
1827             instance), because doing otherwise would cause reference cycles.
1828            - Add WasmInstance. It doesn't do much for now, owns globals.
1829            - JSWebAssembly instance now doesn't just contain the imported functions as
1830              JSObjects, it also has the corresponding import's instance and wasm
1831              entrypoint. This triples the space allocated per instance's imported
1832              function, but there shouldn't be that many imports. This has two upsides: it
1833              creates smaller and faster code, and makes is easier to disassociate
1834              embedder-specific things from embedder-neutral things. The small / faster
1835              win is in two places: B3 IR generator only needs offsetOfImportFunction for
1836              the call opcode (when the called index is an import) to know whether the
1837              import is wasm->wasm or wasm->embedder (this isn't known at compile-time
1838              because it's dependent on the import object), this is now done by seeing if
1839              that import function has an associated target instance (only wasm->wasm
1840              does); the other place is wasmBinding which uses offsetOfImportFunction to
1841              figure out the wasm->wasm target instance, and then gets
1842              WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
1843              call. The disassociation comes because the target instance can be
1844              Wasm::Instance once we change what the Context is, and
1845              WasmEntrypointLoadLocation is already embedder-independent. As a next step I
1846              can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
1847              and leave importFunction in as an opaque pointer which is embedder-specific,
1848              and in JS will remain WriteBarrier<JSObject>.
1849            - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
1850              around instead of VM. This is a first step in allowing entry frames which
1851              aren't stored on VM, but which are instead stored in an embedder-specific
1852              location. That change won't really affect JS except through code churn, but
1853              will allow WebAssembly to use some machinery in a generic manner without
1854              having a VM.
1855
1856         * JavaScriptCore.xcodeproj/project.pbxproj:
1857         * Sources.txt:
1858         * bytecode/PolymorphicAccess.cpp:
1859         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1860         * debugger/Debugger.cpp:
1861         (JSC::Debugger::stepOutOfFunction):
1862         (JSC::Debugger::returnEvent):
1863         (JSC::Debugger::unwindEvent):
1864         (JSC::Debugger::didExecuteProgram):
1865         * dfg/DFGJITCompiler.cpp:
1866         (JSC::DFG::JITCompiler::compileExceptionHandlers):
1867         * dfg/DFGOSREntry.cpp:
1868         (JSC::DFG::prepareOSREntry):
1869         * dfg/DFGOSRExit.cpp:
1870         (JSC::DFG::OSRExit::compileOSRExit):
1871         (JSC::DFG::OSRExit::compileExit):
1872         * dfg/DFGThunks.cpp:
1873         (JSC::DFG::osrEntryThunkGenerator):
1874         * ftl/FTLCompile.cpp:
1875         (JSC::FTL::compile):
1876         * ftl/FTLLink.cpp:
1877         (JSC::FTL::link):
1878         * ftl/FTLLowerDFGToB3.cpp:
1879         (JSC::FTL::DFG::LowerDFGToB3::lower):
1880         * ftl/FTLOSRExitCompiler.cpp:
1881         (JSC::FTL::compileStub):
1882         * interpreter/CallFrame.cpp:
1883         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
1884         (JSC::CallFrame::callerFrame):
1885         (JSC::CallFrame::unsafeCallerFrame):
1886         * interpreter/CallFrame.h:
1887         (JSC::ExecState::callerFrame const):
1888         (JSC::ExecState::callerFrameOrEntryFrame const):
1889         (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
1890         * interpreter/FrameTracers.h:
1891         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
1892         (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
1893         (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
1894         * interpreter/Interpreter.cpp:
1895         (JSC::UnwindFunctor::operator() const):
1896         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1897         (JSC::Interpreter::unwind):
1898         * interpreter/StackVisitor.cpp:
1899         (JSC::StackVisitor::StackVisitor):
1900         (JSC::StackVisitor::gotoNextFrame):
1901         (JSC::StackVisitor::readNonInlinedFrame):
1902         (JSC::StackVisitor::Frame::dump const):
1903         * interpreter/StackVisitor.h:
1904         (JSC::StackVisitor::Frame::callerIsEntryFrame const):
1905         * interpreter/VMEntryRecord.h:
1906         (JSC::VMEntryRecord::prevTopEntryFrame):
1907         (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
1908         (JSC::EntryFrame::vmEntryRecordOffset):
1909         * jit/AssemblyHelpers.cpp:
1910         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1911         (JSC::AssemblyHelpers::loadWasmContextInstance):
1912         (JSC::AssemblyHelpers::storeWasmContextInstance):
1913         (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
1914         (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
1915         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1916         * jit/AssemblyHelpers.h:
1917         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1918         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1919         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
1920         * jit/JIT.cpp:
1921         (JSC::JIT::emitEnterOptimizationCheck):
1922         (JSC::JIT::privateCompileExceptionHandlers):
1923         * jit/JITExceptions.cpp:
1924         (JSC::genericUnwind):
1925         * jit/JITOpcodes.cpp:
1926         (JSC::JIT::emit_op_throw):
1927         (JSC::JIT::emit_op_catch):
1928         (JSC::JIT::emitSlow_op_loop_hint):
1929         * jit/JITOpcodes32_64.cpp:
1930         (JSC::JIT::emit_op_throw):
1931         (JSC::JIT::emit_op_catch):
1932         * jit/JITOperations.cpp:
1933         * jit/ThunkGenerators.cpp:
1934         (JSC::throwExceptionFromCallSlowPathGenerator):
1935         (JSC::nativeForGenerator):
1936         * jsc.cpp:
1937         (functionDumpCallFrame):
1938         * llint/LLIntSlowPaths.cpp:
1939         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1940         * llint/LLIntThunks.cpp:
1941         (JSC::vmEntryRecord):
1942         * llint/LowLevelInterpreter.asm:
1943         * llint/LowLevelInterpreter32_64.asm:
1944         * llint/LowLevelInterpreter64.asm:
1945         * runtime/Options.cpp:
1946         (JSC::recomputeDependentOptions):
1947         * runtime/Options.h:
1948         * runtime/SamplingProfiler.cpp:
1949         (JSC::FrameWalker::FrameWalker):
1950         (JSC::FrameWalker::advanceToParentFrame):
1951         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1952         * runtime/ThrowScope.cpp:
1953         (JSC::ThrowScope::~ThrowScope):
1954         * runtime/VM.cpp:
1955         (JSC::VM::VM):
1956         (JSC::VM::~VM):
1957         * runtime/VM.h:
1958         (JSC::VM::topEntryFrameOffset):
1959         * runtime/VMTraps.cpp:
1960         (JSC::isSaneFrame):
1961         (JSC::VMTraps::tryInstallTrapBreakpoints):
1962         (JSC::VMTraps::invalidateCodeBlocksOnStack):
1963         * wasm/WasmB3IRGenerator.cpp:
1964         (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
1965         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1966         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1967         (JSC::Wasm::B3IRGenerator::addGrowMemory):
1968         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
1969         (JSC::Wasm::B3IRGenerator::addCall):
1970         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1971         (JSC::Wasm::parseAndCompile):
1972         * wasm/WasmB3IRGenerator.h:
1973         * wasm/WasmBBQPlan.cpp:
1974         (JSC::Wasm::BBQPlan::BBQPlan):
1975         (JSC::Wasm::BBQPlan::compileFunctions):
1976         (JSC::Wasm::BBQPlan::complete):
1977         * wasm/WasmBBQPlan.h:
1978         * wasm/WasmBBQPlanInlines.h:
1979         (JSC::Wasm::BBQPlan::initializeCallees):
1980         * wasm/WasmBinding.cpp:
1981         (JSC::Wasm::wasmToWasm):
1982         * wasm/WasmBinding.h:
1983         * wasm/WasmCodeBlock.cpp:
1984         (JSC::Wasm::CodeBlock::create):
1985         (JSC::Wasm::CodeBlock::CodeBlock):
1986         (JSC::Wasm::CodeBlock::compileAsync):
1987         (JSC::Wasm::CodeBlock::setCompilationFinished):
1988         * wasm/WasmCodeBlock.h:
1989         (JSC::Wasm::CodeBlock::offsetOfImportStubs):
1990         (JSC::Wasm::CodeBlock::allocationSize):
1991         (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
1992         (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
1993         (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
1994         (JSC::Wasm::CodeBlock::compilationFinished):
1995         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1996         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1997         * wasm/WasmContext.cpp:
1998         (JSC::Wasm::Context::useFastTLS):
1999         (JSC::Wasm::Context::load const):
2000         (JSC::Wasm::Context::store):
2001         * wasm/WasmContext.h:
2002         * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
2003         * wasm/WasmFaultSignalHandler.cpp:
2004         * wasm/WasmFaultSignalHandler.h:
2005         * wasm/WasmFormat.h:
2006         * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2007         (JSC::Wasm::Instance::Instance):
2008         (JSC::Wasm::Instance::~Instance):
2009         (JSC::Wasm::Instance::extraMemoryAllocated const):
2010         * wasm/WasmInstance.h: Added.
2011         (JSC::Wasm::Instance::create):
2012         (JSC::Wasm::Instance::finalizeCreation):
2013         (JSC::Wasm::Instance::module):
2014         (JSC::Wasm::Instance::codeBlock):
2015         (JSC::Wasm::Instance::memory):
2016         (JSC::Wasm::Instance::table):
2017         (JSC::Wasm::Instance::loadI32Global const):
2018         (JSC::Wasm::Instance::loadI64Global const):
2019         (JSC::Wasm::Instance::loadF32Global const):
2020         (JSC::Wasm::Instance::loadF64Global const):
2021         (JSC::Wasm::Instance::setGlobal):
2022         (JSC::Wasm::Instance::offsetOfCachedStackLimit):
2023         (JSC::Wasm::Instance::cachedStackLimit const):
2024         (JSC::Wasm::Instance::setCachedStackLimit):
2025         * wasm/WasmMemory.cpp:
2026         (JSC::Wasm::Memory::Memory):
2027         (JSC::Wasm::Memory::create):
2028         (JSC::Wasm::Memory::~Memory):
2029         (JSC::Wasm::Memory::grow):
2030         * wasm/WasmMemory.h:
2031         (JSC::Wasm::Memory::offsetOfMemory):
2032         (JSC::Wasm::Memory::offsetOfSize):
2033         * wasm/WasmMemoryInformation.cpp:
2034         (JSC::Wasm::PinnedRegisterInfo::get):
2035         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
2036         * wasm/WasmMemoryInformation.h:
2037         (JSC::Wasm::PinnedRegisterInfo::toSave const):
2038         * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2039         (JSC::Wasm::makeString):
2040         * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2041         * wasm/WasmModule.cpp:
2042         (JSC::Wasm::makeValidationCallback):
2043         (JSC::Wasm::Module::validateSync):
2044         (JSC::Wasm::Module::validateAsync):
2045         (JSC::Wasm::Module::getOrCreateCodeBlock):
2046         (JSC::Wasm::Module::compileSync):
2047         (JSC::Wasm::Module::compileAsync):
2048         * wasm/WasmModule.h:
2049         * wasm/WasmModuleParser.cpp:
2050         (JSC::Wasm::ModuleParser::parseTableHelper):
2051         * wasm/WasmOMGPlan.cpp:
2052         (JSC::Wasm::OMGPlan::OMGPlan):
2053         (JSC::Wasm::OMGPlan::runForIndex):
2054         * wasm/WasmOMGPlan.h:
2055         * wasm/WasmPageCount.h:
2056         (JSC::Wasm::PageCount::isValid const):
2057         * wasm/WasmPlan.cpp:
2058         (JSC::Wasm::Plan::Plan):
2059         (JSC::Wasm::Plan::runCompletionTasks):
2060         (JSC::Wasm::Plan::addCompletionTask):
2061         (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
2062         * wasm/WasmPlan.h:
2063         (JSC::Wasm::Plan::dontFinalize):
2064         * wasm/WasmSignature.cpp:
2065         * wasm/WasmSignature.h:
2066         * wasm/WasmTable.cpp: Added.
2067         (JSC::Wasm::Table::create):
2068         (JSC::Wasm::Table::~Table):
2069         (JSC::Wasm::Table::Table):
2070         (JSC::Wasm::Table::grow):
2071         (JSC::Wasm::Table::clearFunction):
2072         (JSC::Wasm::Table::setFunction):
2073         * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
2074         (JSC::Wasm::Table::maximum const):
2075         (JSC::Wasm::Table::size const):
2076         (JSC::Wasm::Table::offsetOfSize):
2077         (JSC::Wasm::Table::offsetOfFunctions):
2078         (JSC::Wasm::Table::offsetOfInstances):
2079         (JSC::Wasm::Table::isValidSize):
2080         * wasm/WasmThunks.cpp:
2081         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2082         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
2083         (JSC::Wasm::Thunks::setThrowWasmException):
2084         (JSC::Wasm::Thunks::throwWasmException):
2085         * wasm/WasmThunks.h:
2086         * wasm/WasmWorklist.cpp:
2087         (JSC::Wasm::Worklist::stopAllPlansForContext):
2088         * wasm/WasmWorklist.h:
2089         * wasm/js/JSToWasm.cpp: Added.
2090         (JSC::Wasm::createJSToWasmWrapper):
2091         * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2092         * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
2093         * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
2094         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2095         (JSC::JSWebAssemblyCodeBlock::create):
2096         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2097         * wasm/js/JSWebAssemblyCodeBlock.h:
2098         * wasm/js/JSWebAssemblyInstance.cpp:
2099         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2100         (JSC::JSWebAssemblyInstance::finishCreation):
2101         (JSC::JSWebAssemblyInstance::visitChildren):
2102         (JSC::JSWebAssemblyInstance::finalizeCreation):
2103         (JSC::JSWebAssemblyInstance::create):
2104         * wasm/js/JSWebAssemblyInstance.h:
2105         (JSC::JSWebAssemblyInstance::instance):
2106         (JSC::JSWebAssemblyInstance::context const):
2107         (JSC::JSWebAssemblyInstance::table):
2108         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
2109         (JSC::JSWebAssemblyInstance::setMemory):
2110         (JSC::JSWebAssemblyInstance::offsetOfTail):
2111         (JSC::JSWebAssemblyInstance::importFunctionInfo):
2112         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
2113         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
2114         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
2115         (JSC::JSWebAssemblyInstance::importFunction):
2116         (JSC::JSWebAssemblyInstance::internalMemory):
2117         (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
2118         (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
2119         (JSC::JSWebAssemblyInstance::offsetOfCallee):
2120         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2121         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
2122         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
2123         (JSC::JSWebAssemblyInstance::cachedStackLimit const):
2124         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2125         (JSC::JSWebAssemblyInstance::wasmMemory):
2126         (JSC::JSWebAssemblyInstance::wasmModule):
2127         (JSC::JSWebAssemblyInstance::allocationSize):
2128         (JSC::JSWebAssemblyInstance::module const):
2129         * wasm/js/JSWebAssemblyMemory.cpp:
2130         (JSC::JSWebAssemblyMemory::create):
2131         (JSC::JSWebAssemblyMemory::adopt):
2132         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
2133         (JSC::JSWebAssemblyMemory::grow):
2134         (JSC::JSWebAssemblyMemory::growSuccessCallback):
2135         * wasm/js/JSWebAssemblyMemory.h:
2136         * wasm/js/JSWebAssemblyModule.cpp:
2137         (JSC::JSWebAssemblyModule::moduleInformation const):
2138         (JSC::JSWebAssemblyModule::exportSymbolTable const):
2139         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
2140         (JSC::JSWebAssemblyModule::callee const):
2141         (JSC::JSWebAssemblyModule::codeBlock):
2142         (JSC::JSWebAssemblyModule::module):
2143         * wasm/js/JSWebAssemblyModule.h:
2144         * wasm/js/JSWebAssemblyTable.cpp:
2145         (JSC::JSWebAssemblyTable::create):
2146         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2147         (JSC::JSWebAssemblyTable::visitChildren):
2148         (JSC::JSWebAssemblyTable::grow):
2149         (JSC::JSWebAssemblyTable::getFunction):
2150         (JSC::JSWebAssemblyTable::clearFunction):
2151         (JSC::JSWebAssemblyTable::setFunction):
2152         * wasm/js/JSWebAssemblyTable.h:
2153         (JSC::JSWebAssemblyTable::isValidSize):
2154         (JSC::JSWebAssemblyTable::maximum const):
2155         (JSC::JSWebAssemblyTable::size const):
2156         (JSC::JSWebAssemblyTable::table):
2157         * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
2158         (JSC::Wasm::materializeImportJSCell):
2159         (JSC::Wasm::wasmToJS):
2160         (JSC::Wasm::wasmToJSException):
2161         * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2162         * wasm/js/WebAssemblyFunction.cpp:
2163         (JSC::callWebAssemblyFunction):
2164         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2165         (JSC::constructJSWebAssemblyInstance):
2166         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2167         (JSC::constructJSWebAssemblyMemory):
2168         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2169         (JSC::webAssemblyMemoryProtoFuncGrow):
2170         * wasm/js/WebAssemblyModuleConstructor.cpp:
2171         (JSC::constructJSWebAssemblyModule):
2172         (JSC::WebAssemblyModuleConstructor::createModule):
2173         * wasm/js/WebAssemblyModuleConstructor.h:
2174         * wasm/js/WebAssemblyModuleRecord.cpp:
2175         (JSC::WebAssemblyModuleRecord::link):
2176         (JSC::WebAssemblyModuleRecord::evaluate):
2177         * wasm/js/WebAssemblyPrototype.cpp:
2178         (JSC::webAssemblyCompileFunc):
2179         (JSC::instantiate):
2180         (JSC::compileAndInstantiate):
2181         (JSC::webAssemblyValidateFunc):
2182         * wasm/js/WebAssemblyTableConstructor.cpp:
2183         (JSC::constructJSWebAssemblyTable):
2184         * wasm/js/WebAssemblyWrapperFunction.cpp:
2185         (JSC::WebAssemblyWrapperFunction::create):
2186
2187 2017-10-19  Mark Lam  <mark.lam@apple.com>
2188
2189         Stringifier::appendStringifiedValue() is missing an exception check.
2190         https://bugs.webkit.org/show_bug.cgi?id=178386
2191         <rdar://problem/35027610>
2192
2193         Reviewed by Saam Barati.
2194
2195         * runtime/JSONObject.cpp:
2196         (JSC::Stringifier::appendStringifiedValue):
2197
2198 2017-10-19  Saam Barati  <sbarati@apple.com>
2199
2200         REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
2201         https://bugs.webkit.org/show_bug.cgi?id=178543
2202
2203         Reviewed by Filip Pizlo.
2204
2205         * dfg/DFGByteCodeParser.cpp:
2206         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2207
2208 2017-10-19  Saam Barati  <sbarati@apple.com>
2209
2210         re-inline ObjectAllocationProfile::initializeProfile
2211         https://bugs.webkit.org/show_bug.cgi?id=178532
2212
2213         Rubber stamped by Michael Saboff.
2214
2215         I un-inlined this function when implementing poly proto.
2216         This patch re-inlines it. In my testing, it looks like it
2217         might be a 0.5% speedometer progression to inline it.
2218
2219         * JavaScriptCore.xcodeproj/project.pbxproj:
2220         * Sources.txt:
2221         * bytecode/CodeBlock.cpp:
2222         * bytecode/ObjectAllocationProfile.cpp: Removed.
2223         * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
2224         (JSC::ObjectAllocationProfile::initializeProfile):
2225         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
2226         * runtime/FunctionRareData.cpp:
2227
2228 2017-10-19  Michael Saboff  <msaboff@apple.com>
2229
2230         Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
2231         https://bugs.webkit.org/show_bug.cgi?id=178521
2232
2233         Reviewed by JF Bastien.
2234
2235         * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
2236         standard version.  The prior version was the draft 6.0 version.
2237
2238 2017-10-19  Saam Barati  <sbarati@apple.com>
2239
2240         We should hard code the poly proto offset
2241         https://bugs.webkit.org/show_bug.cgi?id=178531
2242
2243         Reviewed by Filip Pizlo.
2244
2245         This patch embraces that the poly proto offset is always zero. It's already
2246         the case that we would always get the inline offset zero for poly proto just
2247         by construction. This just hardcodes this assumption throughout the codebase.
2248         This appears to be a 1% speedometer progression in my testing.
2249         
2250         The downside of this patch is that it may require changing how we do
2251         things when we implement poly proto when inheriting from builtin
2252         types. I think we can face this problem when we decide to implement
2253         that.
2254
2255         * bytecode/AccessCase.cpp:
2256         (JSC::AccessCase::generateWithGuard):
2257         * dfg/DFGOperations.cpp:
2258         * dfg/DFGSpeculativeJIT.cpp:
2259         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2260         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2261         * ftl/FTLLowerDFGToB3.cpp:
2262         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2263         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2264         * jit/JITOpcodes.cpp:
2265         (JSC::JIT::emit_op_instanceof):
2266         * jit/JITOpcodes32_64.cpp:
2267         (JSC::JIT::emit_op_instanceof):
2268         * runtime/CommonSlowPaths.cpp:
2269         (JSC::SLOW_PATH_DECL):
2270         * runtime/JSObject.cpp:
2271         (JSC::JSObject::setPrototypeDirect):
2272         * runtime/JSObject.h:
2273         (JSC::JSObject::locationForOffset const):
2274         (JSC::JSObject::locationForOffset):
2275         (JSC::JSObject::getDirect const):
2276         * runtime/PropertyOffset.h:
2277         * runtime/Structure.cpp:
2278         (JSC::Structure::create):
2279         (JSC::Structure::dump const):
2280         * runtime/Structure.h:
2281         * runtime/StructureInlines.h:
2282         (JSC::Structure::storedPrototype const):
2283         (JSC::Structure::storedPrototypeObject const):
2284
2285 2017-10-19  Saam Barati  <sbarati@apple.com>
2286
2287         Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
2288         https://bugs.webkit.org/show_bug.cgi?id=178529
2289
2290         Reviewed by Mark Lam.
2291
2292         * runtime/Structure.h:
2293         * runtime/StructureInlines.h:
2294         (JSC::Structure::storedPrototypeObject const):
2295         (JSC::Structure::storedPrototypeStructure const):
2296         (JSC::Structure::storedPrototype const):
2297         (JSC::Structure::prototypeForLookup const):
2298         (JSC::Structure::prototypeChain const):
2299
2300 2017-10-19  Saam Barati  <sbarati@apple.com>
2301
2302         Turn poly proto back on by default and remove the option
2303         https://bugs.webkit.org/show_bug.cgi?id=178525
2304
2305         Reviewed by Mark Lam.
2306
2307         I added this option because I thought it'd speed speedometer up because the
2308         original poly proto patch slowed speedometer down. It turns out that
2309         allocating poly proto objects is not what slows speedometer down. It's
2310         other code I added in the runtime that needs to be poly proto aware. I'll
2311         be addressing these in follow up patches.
2312
2313         * runtime/Options.h:
2314         * runtime/StructureInlines.h:
2315         (JSC::Structure::shouldConvertToPolyProto):
2316
2317 2017-10-19  Robin Morisset  <rmorisset@apple.com>
2318
2319         Turn recursive tail calls into loops
2320         https://bugs.webkit.org/show_bug.cgi?id=176601
2321
2322         Reviewed by Saam Barati.
2323
2324         We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
2325         One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
2326         Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
2327         We do this part through modifying the computation of the jump targets.
2328         Importantly, we only do this splitting for functions that have tail calls.
2329         It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
2330
2331         We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
2332         The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
2333
2334         * bytecode/CodeBlock.h:
2335         (JSC::CodeBlock::hasTailCalls const):
2336         * bytecode/PreciseJumpTargets.cpp:
2337         (JSC::getJumpTargetsForBytecodeOffset):
2338         (JSC::computePreciseJumpTargetsInternal):
2339         * bytecode/UnlinkedCodeBlock.cpp:
2340         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2341         * bytecode/UnlinkedCodeBlock.h:
2342         (JSC::UnlinkedCodeBlock::hasTailCalls const):
2343         (JSC::UnlinkedCodeBlock::setHasTailCalls):
2344         * bytecompiler/BytecodeGenerator.cpp:
2345         (JSC::BytecodeGenerator::emitEnter):
2346         (JSC::BytecodeGenerator::emitCallInTailPosition):
2347         * dfg/DFGByteCodeParser.cpp:
2348         (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
2349         (JSC::DFG::ByteCodeParser::makeBlockTargetable):
2350         (JSC::DFG::ByteCodeParser::handleCall):
2351         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2352         (JSC::DFG::ByteCodeParser::parseBlock):
2353         (JSC::DFG::ByteCodeParser::parse):
2354
2355 2017-10-18  Mark Lam  <mark.lam@apple.com>
2356
2357         RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
2358         https://bugs.webkit.org/show_bug.cgi?id=177600
2359         <rdar://problem/34710985>
2360
2361         Reviewed by Saam Barati.
2362
2363         According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
2364         section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
2365         descriptor value is present.
2366
2367         * runtime/RegExpObject.cpp:
2368         (JSC::RegExpObject::defineOwnProperty):
2369
2370 2017-10-18  Keith Miller  <keith_miller@apple.com>
2371
2372         Setup WebCore build to start using unified sources.
2373         https://bugs.webkit.org/show_bug.cgi?id=178362
2374
2375         Reviewed by Tim Horton.
2376
2377         Change comments in source list files. Also, pass explicit names for build files.
2378
2379         * CMakeLists.txt:
2380         * PlatformGTK.cmake:
2381         * PlatformMac.cmake:
2382         * Sources.txt:
2383         * SourcesGTK.txt:
2384         * SourcesMac.txt:
2385
2386 2017-10-18  Commit Queue  <commit-queue@webkit.org>
2387
2388         Unreviewed, rolling out r223321.
2389         https://bugs.webkit.org/show_bug.cgi?id=178476
2390
2391         This protocol change broke some internal builds (Requested by
2392         brrian__ on #webkit).
2393
2394         Reverted changeset:
2395
2396         "Web Inspector: provide a way to enable/disable event
2397         listeners"
2398         https://bugs.webkit.org/show_bug.cgi?id=177451
2399         https://trac.webkit.org/changeset/223321
2400
2401 2017-10-18  Mark Lam  <mark.lam@apple.com>
2402
2403         The compiler should always register a structure when it adds its transitionWatchPointSet.
2404         https://bugs.webkit.org/show_bug.cgi?id=178420
2405         <rdar://problem/34814024>
2406
2407         Reviewed by Saam Barati and Filip Pizlo.
2408
2409         Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
2410         now invoke Graph::registerAndWatchStructureTransition() on the structure.
2411         registerAndWatchStructureTransition() both registers the structure and add its
2412         transitionWatchpointSet to the plan desired watchpoints.
2413
2414         Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
2415         except registerAndWatchStructureTransition() adds the structure's
2416         transitionWatchpointSet unconditionally.
2417
2418         * dfg/DFGArgumentsEliminationPhase.cpp:
2419         * dfg/DFGArrayMode.cpp:
2420         (JSC::DFG::ArrayMode::refine const):
2421         * dfg/DFGByteCodeParser.cpp:
2422         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2423         * dfg/DFGFixupPhase.cpp:
2424         (JSC::DFG::FixupPhase::fixupNode):
2425
2426         * dfg/DFGGraph.cpp:
2427         (JSC::DFG::Graph::registerAndWatchStructureTransition):
2428         * dfg/DFGGraph.h:
2429
2430         * dfg/DFGSpeculativeJIT.cpp:
2431         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2432         - The second set of addLazily()s is redundant.  This set is executed only when
2433           prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
2434           only if we've executed the if statement above it.  That preceding if statement
2435           already registerAndWatchStructureTransition() the same 2 structures.  Hence,
2436           this second set can be deleted.
2437
2438         * dfg/DFGWatchpointCollectionPhase.cpp:
2439         (JSC::DFG::WatchpointCollectionPhase::addLazily):
2440         - Deleted an unused function.
2441
2442         * ftl/FTLLowerDFGToB3.cpp:
2443         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2444
2445 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2446
2447         [JSC] Remove unused private name structure
2448         https://bugs.webkit.org/show_bug.cgi?id=178436
2449
2450         Reviewed by Sam Weinig.
2451
2452         It is no longer used. This patch just removes it.
2453
2454         * runtime/JSGlobalObject.h:
2455         (JSC::JSGlobalObject::numberObjectStructure const):
2456         (JSC::JSGlobalObject::privateNameStructure const): Deleted.
2457
2458 2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>
2459
2460         Fix macOS and iOS builds after r223594.
2461
2462         * JavaScriptCore.xcodeproj/project.pbxproj:
2463
2464 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2465
2466         [JSC] __proto__ getter should be fast
2467         https://bugs.webkit.org/show_bug.cgi?id=178067
2468
2469         Reviewed by Saam Barati.
2470
2471         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2472         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2473         Call node for this. It is inefficient since typically we know the `prototype` of the given
2474         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2475         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2476         we can still change this to efficient access to poly proto slot.
2477
2478         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2479         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2480         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2481         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2482         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2483         for ARES-6 ML.
2484
2485         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2486
2487         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2488         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2489         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2490
2491         This patch improves SixSpeed super.es6 by 3.42x.
2492
2493                                  baseline                  patched
2494
2495         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
2496
2497         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2498
2499         * dfg/DFGAbstractInterpreterInlines.h:
2500         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2501         * dfg/DFGByteCodeParser.cpp:
2502         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2503         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2504         (JSC::DFG::ByteCodeParser::handleGetById):
2505         * dfg/DFGClobberize.h:
2506         (JSC::DFG::clobberize):
2507         * dfg/DFGDoesGC.cpp:
2508         (JSC::DFG::doesGC):
2509         * dfg/DFGFixupPhase.cpp:
2510         (JSC::DFG::FixupPhase::fixupNode):
2511         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2512         * dfg/DFGHeapLocation.cpp:
2513         (WTF::printInternal):
2514         * dfg/DFGHeapLocation.h:
2515         * dfg/DFGNode.h:
2516         (JSC::DFG::Node::hasHeapPrediction):
2517         (JSC::DFG::Node::shouldSpeculateFunction):
2518         * dfg/DFGNodeType.h:
2519         * dfg/DFGOperations.cpp:
2520         * dfg/DFGOperations.h:
2521         * dfg/DFGPredictionPropagationPhase.cpp:
2522         * dfg/DFGSafeToExecute.h:
2523         (JSC::DFG::safeToExecute):
2524         * dfg/DFGSpeculativeJIT.cpp:
2525         (JSC::DFG::SpeculativeJIT::speculateFunction):
2526         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
2527         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2528         * dfg/DFGSpeculativeJIT.h:
2529         (JSC::DFG::SpeculativeJIT::callOperation):
2530         * dfg/DFGSpeculativeJIT32_64.cpp:
2531         (JSC::DFG::SpeculativeJIT::compile):
2532         * dfg/DFGSpeculativeJIT64.cpp:
2533         (JSC::DFG::SpeculativeJIT::compile):
2534         * ftl/FTLCapabilities.cpp:
2535         (JSC::FTL::canCompile):
2536         * ftl/FTLLowerDFGToB3.cpp:
2537         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2538         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2539         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2540         * jit/IntrinsicEmitter.cpp:
2541         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
2542         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2543         * jit/JITOperations.h:
2544         * runtime/Intrinsic.cpp:
2545         (JSC::intrinsicName):
2546         * runtime/Intrinsic.h:
2547         * runtime/JSGlobalObject.cpp:
2548         (JSC::JSGlobalObject::init):
2549         * runtime/JSGlobalObject.h:
2550         (JSC::JSGlobalObject::booleanPrototype const):
2551         (JSC::JSGlobalObject::numberPrototype const):
2552         (JSC::JSGlobalObject::booleanObjectStructure const):
2553         * runtime/JSGlobalObjectFunctions.cpp:
2554         (JSC::globalFuncProtoGetter):
2555         * runtime/JSGlobalObjectFunctions.h:
2556         * runtime/ObjectConstructor.cpp:
2557         * runtime/ReflectObject.cpp:
2558
2559 2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>
2560
2561         Unreviewed, rolling out r223523.
2562
2563         A test for this change is failing on debug JSC bots.
2564
2565         Reverted changeset:
2566
2567         "[JSC] __proto__ getter should be fast"
2568         https://bugs.webkit.org/show_bug.cgi?id=178067
2569         https://trac.webkit.org/changeset/223523
2570
2571 2017-10-17  Youenn Fablet  <youenn@apple.com>
2572
2573         Add preliminary support for fetch event
2574         https://bugs.webkit.org/show_bug.cgi?id=178171
2575
2576         Reviewed by Chris Dumez.
2577
2578         Adding events
2579
2580         * runtime/JSPromise.h:
2581
2582 2017-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2583
2584         [JSC] __proto__ getter should be fast
2585         https://bugs.webkit.org/show_bug.cgi?id=178067
2586
2587         Reviewed by Saam Barati.
2588
2589         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2590         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2591         Call node for this. It is inefficient since typically we know the `prototype` of the given
2592         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2593         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2594         we can still change this to efficient access to poly proto slot.
2595
2596         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2597         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2598         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2599         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2600         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2601         for ARES-6 ML.
2602
2603         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2604
2605         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2606         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2607         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2608
2609         This patch improves SixSpeed super.es6 by 3.42x.
2610
2611                                  baseline                  patched
2612
2613         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
2614
2615         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2616
2617         * dfg/DFGAbstractInterpreterInlines.h:
2618         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2619         * dfg/DFGByteCodeParser.cpp:
2620         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2621         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2622         (JSC::DFG::ByteCodeParser::handleGetById):
2623         * dfg/DFGClobberize.h:
2624         (JSC::DFG::clobberize):
2625         * dfg/DFGDoesGC.cpp:
2626         (JSC::DFG::doesGC):
2627         * dfg/DFGFixupPhase.cpp:
2628         (JSC::DFG::FixupPhase::fixupNode):
2629         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2630         * dfg/DFGHeapLocation.cpp:
2631         (WTF::printInternal):
2632         * dfg/DFGHeapLocation.h:
2633         * dfg/DFGNode.h:
2634         (JSC::DFG::Node::hasHeapPrediction):
2635         (JSC::DFG::Node::shouldSpeculateFunction):
2636         * dfg/DFGNodeType.h:
2637         * dfg/DFGOperations.cpp:
2638         * dfg/DFGOperations.h:
2639         * dfg/DFGPredictionPropagationPhase.cpp:
2640         * dfg/DFGSafeToExecute.h:
2641         (JSC::DFG::safeToExecute):
2642         * dfg/DFGSpeculativeJIT.cpp:
2643         (JSC::DFG::SpeculativeJIT::speculateFunction):
2644         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
2645         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2646         * dfg/DFGSpeculativeJIT.h:
2647         * dfg/DFGSpeculativeJIT32_64.cpp:
2648         (JSC::DFG::SpeculativeJIT::compile):
2649         * dfg/DFGSpeculativeJIT64.cpp:
2650         (JSC::DFG::SpeculativeJIT::compile):
2651         * ftl/FTLCapabilities.cpp:
2652         (JSC::FTL::canCompile):
2653         * ftl/FTLLowerDFGToB3.cpp:
2654         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2655         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2656         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2657         * jit/IntrinsicEmitter.cpp:
2658         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
2659         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2660         * runtime/Intrinsic.cpp:
2661         (JSC::intrinsicName):
2662         * runtime/Intrinsic.h:
2663         * runtime/JSGlobalObject.cpp:
2664         (JSC::JSGlobalObject::init):
2665         * runtime/JSGlobalObjectFunctions.cpp:
2666         (JSC::globalFuncProtoGetter):
2667         * runtime/JSGlobalObjectFunctions.h:
2668         * runtime/ObjectConstructor.cpp:
2669         * runtime/ReflectObject.cpp:
2670
2671 2017-10-17  Keith Miller  <keith_miller@apple.com>
2672
2673         Change WebCore sources to work with unified source builds
2674         https://bugs.webkit.org/show_bug.cgi?id=178229
2675
2676         Rubber stamped by Tim Horton.
2677
2678         * Configurations/FeatureDefines.xcconfig:
2679
2680 2017-10-15  Filip Pizlo  <fpizlo@apple.com>
2681
2682         Make some asserts into release asserts
2683         https://bugs.webkit.org/show_bug.cgi?id=178324
2684
2685         Reviewed by Saam Barati.
2686         
2687         These asserts are not on perf critical paths, so they might as well be release asserts.
2688
2689         * runtime/DataView.h:
2690         (JSC::DataView::get):
2691         (JSC::DataView::set):
2692
2693 2017-10-16  JF Bastien  <jfbastien@apple.com>
2694
2695         JSRunLoopTimer: reduce likely race when used improperly
2696         https://bugs.webkit.org/show_bug.cgi?id=178298
2697         <rdar://problem/32899816>
2698
2699         Reviewed by Saam Barati.
2700
2701         If an API user sets a timer on JSRunLoopTimer, and then racily
2702         destroys the JSRunLoopTimer while the timer is firing then it's
2703         possible for timerDidFire to cause a use-after-free and / or crash
2704         because e.g. m_apiLock becomes a nullptr while timerDidFire is
2705         executing. That results from an invalid use of JSRunLoopTimer, but
2706         we should try to be more resilient for that type of misuse because
2707         it's not necessarily easy to catch by inspection.
2708
2709         With this change the only remaining race is if the timer fires,
2710         and then only timerDidFire's prologue executes, but not the load
2711         of the m_apiLock pointer from `this`. It's a much smaller race.
2712
2713         Separately, I'll reach out to API users who are seemingly misusing
2714         the API.
2715
2716         * runtime/JSRunLoopTimer.cpp:
2717         (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
2718         and checks for nullptr. This prevents loading it twice off of
2719         `this` and turns a nullptr deref into "just" a use-after-free.
2720         (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
2721         calling m_vm->unregisterRunLoopTimer(this), which in turn does
2722         CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
2723         timerDidFire from doing much while the timers are un-registered.
2724         ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
2725         releasing the lock, so it needs its own local copy.
2726
2727 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2728
2729         [JSC] Perform module specifier validation at parsing time
2730         https://bugs.webkit.org/show_bug.cgi?id=178256
2731
2732         Reviewed by Darin Adler.
2733
2734         This patch make module loader's `resolve` operation synchronous. And we validate
2735         module's requested module names when instantiating the module instead of satisfying
2736         module's dependencies. This change is not observable to users. But this is precise
2737         to the spec and this optimizes & simplifies the current module loader a bit by
2738         reducing object allocations.
2739
2740         Previously, we have an object called pair in the module loader. This is pair of
2741         module's name and module's record. And we use it to link one module to dependent
2742         modules. Now, it is replaced with module's registry entry.
2743
2744         We also change our loader functions to take a registry entry instead of a module key.
2745         Previous design is due to the consideration that these APIs may be exposed to users
2746         in whatwg/loader spec. However, this won't happen. This change removes unnecessary
2747         repeatedly hash map lookups.
2748
2749         * builtins/ModuleLoaderPrototype.js:
2750         (globalPrivate.newRegistryEntry):
2751         (requestFetch):
2752         (requestInstantiate):
2753         (requestSatisfy):
2754         (link):
2755         (moduleEvaluation):
2756         (loadModule):
2757         * jsc.cpp:
2758         (GlobalObject::moduleLoaderResolve):
2759         * runtime/AbstractModuleRecord.cpp:
2760         (JSC::AbstractModuleRecord::finishCreation):
2761         (JSC::AbstractModuleRecord::hostResolveImportedModule):
2762         * runtime/JSGlobalObject.h:
2763         * runtime/JSModuleLoader.cpp:
2764         (JSC::JSModuleLoader::resolveSync):
2765         (JSC::JSModuleLoader::resolve):
2766         * runtime/JSModuleLoader.h:
2767         * runtime/ModuleLoaderPrototype.cpp:
2768         (JSC::moduleLoaderPrototypeResolveSync):
2769
2770 2017-10-14  Devin Rousso  <webkit@devinrousso.com>
2771
2772         Web Inspector: provide a way to enable/disable event listeners
2773         https://bugs.webkit.org/show_bug.cgi?id=177451
2774
2775         Reviewed by Joseph Pecoraro.
2776
2777         * inspector/protocol/DOM.json:
2778         Add `setEventListenerDisabled` command that enables/disables a specific event listener
2779         during event dispatch. When a disabled event listener is fired, the listener's callback will
2780         not be called.
2781
2782 2017-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2783
2784         Reland "Add Above/Below comparisons for UInt32 patterns"
2785         https://bugs.webkit.org/show_bug.cgi?id=177281
2786
2787         Reviewed by Saam Barati.
2788
2789         We reland this patch without DFGStrengthReduction change to see what causes
2790         regression in the iOS bot.
2791
2792         Sometimes, we would like to have UInt32 operations in JS. While VM does
2793         not support UInt32 nicely, VM supports efficient Int32 operations. As long
2794         as signedness does not matter, we can just perform Int32 operations instead
2795         and recognize its bit pattern as UInt32.
2796
2797         But of course, some operations respect signedness. The most frequently
2798         used one is comparison. Octane/zlib performs UInt32 comparison by performing
2799         `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
2800         UInt32 in Int32 form. And op_unsigned will generate Double value if
2801         the generated Int32 is < 0 (which should be UInt32).
2802
2803         There is a chance for optimization. The given code pattern is the following.
2804
2805             op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
2806
2807         This can be converted to the following.
2808
2809             op_urshift(@1) below:< op_urshift(@2)
2810
2811         The above conversion is nice since
2812
2813         1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
2814         this check depends on the value of Int32, dropping this check is not as easy as
2815         removing Int32 edge filters.
2816
2817         2. We can perform unsigned comparison in Int32 form. We do not need to convert
2818         them to DoubleRep.
2819
2820         Since the above comparison exists in Octane/zlib's *super* hot path, dropping
2821         op_unsigned offers huge win.
2822
2823         At first, my patch attempts to convert the above thing in DFG pipeline.
2824         However it poses several problems.
2825
2826         1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
2827         2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
2828
2829             2: UInt32ToNumber(@0)
2830             3: MovHint(@2, xxx)
2831             4: UInt32ToNumber(@1)
2832             5: MovHint(@1, xxx)
2833
2834         we could drop @5's MovHint. But @3 is difficult since @4 can exit.
2835
2836         So, instead, we start introducing a simple optimization in the bytecode compiler.
2837         It performs pattern matching for op_urshift and comparison to drop op_unsigned.
2838         We adds op_below and op_above families to bytecodes. They only accept Int32 and
2839         perform unsigned comparison.
2840
2841         This offers 4% performance improvement in Octane/zlib.
2842
2843                                     baseline                  patched
2844
2845         zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster
2846
2847         * bytecode/BytecodeDumper.cpp:
2848         (JSC::BytecodeDumper<Block>::printCompareJump):
2849         (JSC::BytecodeDumper<Block>::dumpBytecode):
2850         * bytecode/BytecodeDumper.h:
2851         * bytecode/BytecodeList.json:
2852         * bytecode/BytecodeUseDef.h:
2853         (JSC::computeUsesForBytecodeOffset):
2854         (JSC::computeDefsForBytecodeOffset):
2855         * bytecode/Opcode.h:
2856         (JSC::isBranch):
2857         * bytecode/PreciseJumpTargetsInlines.h:
2858         (JSC::extractStoredJumpTargetsForBytecodeOffset):
2859         * bytecompiler/BytecodeGenerator.cpp:
2860         (JSC::BytecodeGenerator::emitJumpIfTrue):
2861         (JSC::BytecodeGenerator::emitJumpIfFalse):
2862         * bytecompiler/NodesCodegen.cpp:
2863         (JSC::BinaryOpNode::emitBytecode):
2864         * dfg/DFGAbstractInterpreterInlines.h:
2865         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2866         * dfg/DFGByteCodeParser.cpp:
2867         (JSC::DFG::ByteCodeParser::parseBlock):
2868         * dfg/DFGCapabilities.cpp:
2869         (JSC::DFG::capabilityLevel):
2870         * dfg/DFGClobberize.h:
2871         (JSC::DFG::clobberize):
2872         * dfg/DFGDoesGC.cpp:
2873         (JSC::DFG::doesGC):
2874         * dfg/DFGFixupPhase.cpp:
2875         (JSC::DFG::FixupPhase::fixupNode):
2876         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2877         * dfg/DFGNodeType.h:
2878         * dfg/DFGPredictionPropagationPhase.cpp:
2879         * dfg/DFGSafeToExecute.h:
2880         (JSC::DFG::safeToExecute):
2881         * dfg/DFGSpeculativeJIT.cpp:
2882         (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
2883         * dfg/DFGSpeculativeJIT.h:
2884         * dfg/DFGSpeculativeJIT32_64.cpp:
2885         (JSC::DFG::SpeculativeJIT::compile):
2886         * dfg/DFGSpeculativeJIT64.cpp:
2887         (JSC::DFG::SpeculativeJIT::compile):
2888         * dfg/DFGValidate.cpp:
2889         * ftl/FTLCapabilities.cpp:
2890         (JSC::FTL::canCompile):
2891         * ftl/FTLLowerDFGToB3.cpp:
2892         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2893         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
2894         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
2895         * jit/JIT.cpp:
2896         (JSC::JIT::privateCompileMainPass):
2897         * jit/JIT.h:
2898         * jit/JITArithmetic.cpp:
2899         (JSC::JIT::emit_op_below):
2900         (JSC::JIT::emit_op_beloweq):
2901         (JSC::JIT::emit_op_jbelow):
2902         (JSC::JIT::emit_op_jbeloweq):
2903         (JSC::JIT::emit_compareUnsignedAndJump):
2904         (JSC::JIT::emit_compareUnsigned):
2905         * jit/JITArithmetic32_64.cpp:
2906         (JSC::JIT::emit_compareUnsignedAndJump):
2907         (JSC::JIT::emit_compareUnsigned):
2908         * llint/LowLevelInterpreter.asm:
2909         * llint/LowLevelInterpreter32_64.asm:
2910         * llint/LowLevelInterpreter64.asm:
2911         * parser/Nodes.h:
2912         (JSC::ExpressionNode::isBinaryOpNode const):
2913
2914 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2915
2916         WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
2917         https://bugs.webkit.org/show_bug.cgi?id=178210
2918
2919         Reviewed by Saam Barati.
2920
2921         In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
2922         The former is an exported wasm function and the latter is an imported & exported function. Since they
2923         have [[Call]], they should be categorized into "function" in typeof operation.
2924
2925         However, these functions do not implement our function protocol correctly. They inherit JSFunction.
2926         But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
2927         ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
2928         typeof operation.
2929
2930         In this patch, we address the above issue by the following 2 fixes.
2931
2932         1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
2933         InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
2934         implementation, we cannot make this JSFunctionType.
2935
2936         2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
2937         changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
2938         classes of JSFunction (e.g. JSCustomGetterSetterFunction).
2939
2940         * wasm/js/WebAssemblyFunction.h:
2941         (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
2942         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
2943         (JSC::WebAssemblyFunction::callableFunction const): Deleted.
2944         (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
2945         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
2946         * wasm/js/WebAssemblyWrapperFunction.cpp:
2947         (JSC::WebAssemblyWrapperFunction::createStructure):
2948         * wasm/js/WebAssemblyWrapperFunction.h:
2949         (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
2950         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
2951         (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
2952         (JSC::WebAssemblyWrapperFunction::function): Deleted.
2953
2954 2017-10-12  Per Arne Vollan  <pvollan@apple.com>
2955
2956         [Win64] JSC compile error.
2957         https://bugs.webkit.org/show_bug.cgi?id=178213
2958
2959         Reviewed by Alex Christensen.
2960
2961         Add static cast from int64 to uintptr_t.
2962
2963         * dfg/DFGOSRExit.cpp:
2964         (JSC::DFG::OSRExit::executeOSRExit):
2965
2966 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2967
2968         Enable gigacage on iOS
2969         https://bugs.webkit.org/show_bug.cgi?id=177586
2970
2971         Reviewed by JF Bastien.
2972
2973         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2974         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2975         have Gigacage. So, this teaches ARM64 how to load from global variables.
2976         
2977         Also, this makes the code handle disabling the gigacage a bit better.
2978
2979         * ftl/FTLLowerDFGToB3.cpp:
2980         (JSC::FTL::DFG::LowerDFGToB3::caged):
2981         * jit/AssemblyHelpers.h:
2982         (JSC::AssemblyHelpers::cage):
2983         (JSC::AssemblyHelpers::cageConditionally):
2984         * offlineasm/arm64.rb:
2985         * offlineasm/asm.rb:
2986         * offlineasm/instructions.rb:
2987
2988 2017-10-11  Sam Weinig  <sam@webkit.org>
2989
2990         Remove out-parameter variants of copyToVector
2991         https://bugs.webkit.org/show_bug.cgi?id=178155
2992
2993         Reviewed by Tim Horton.
2994
2995         * inspector/ScriptDebugServer.cpp:
2996         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
2997         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
2998         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
2999         (Inspector::ScriptDebugServer::dispatchDidParseSource):
3000         (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
3001         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
3002             
3003             Replace out-parameter based copyToVector, with one that returns a Vector.
3004
3005 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
3006
3007         Support integrity="" on module scripts
3008         https://bugs.webkit.org/show_bug.cgi?id=177959
3009
3010         Reviewed by Sam Weinig.
3011
3012         This patch adds Subresource Integrity check for module scripts. Currently,
3013         only top-level module can be verified with integrity parameter since there
3014         is no way to perform integrity check onto the imported modules.
3015
3016         In JSC side, we add `parameters` to the entry point of the module loader
3017         pipeline. This is fetching parameters and used when fetching modules.
3018
3019         We separately pass this parameters to the pipeline along with the script fetcher.
3020         The script fetcher is only one for module graph since this is the initiator of
3021         this module graph loading. On the other hand, this parameters is for each
3022         module fetching. While setting "integrity" parameters to this script fetcher is
3023         sufficient to pass parameters to top-level-module's fetching, it is not enough
3024         for the future extension.
3025
3026         In the future, we will investigate a way to pass parameters to each non-top-level
3027         module. At that time, this `parameters` should be per-module. This is because
3028         "integrity" value should be different for each module. For example, we will accept
3029         some form of syntax to add parameters to `import`. Some proposed syntax is like
3030         https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
3031
3032         import "./xxx.js" integrity "xxxxxxx"
3033
3034         In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
3035         `parameters` should be different from the one of top-level-module's one. That's why
3036         we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
3037
3038         On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
3039         is important to offer module-graph-wide information. For example, import.meta would
3040         have `import.meta.scriptElement`, which is the script element fetching the module graph
3041         including this. So, we keep the both, script fetcher and parameters.
3042         https://github.com/tc39/proposal-import-meta
3043
3044         This parameters will be finally used by pipeline's fetch hook, and WebCore side
3045         can use this parameters to fetch modules.
3046
3047         We also further clean up the module pipeline by dropping unnecessary features.
3048
3049         * JavaScriptCore.xcodeproj/project.pbxproj:
3050         * Sources.txt:
3051         * builtins/ModuleLoaderPrototype.js:
3052         (requestFetch):
3053         (requestInstantiate):
3054         (requestSatisfy):
3055         (loadModule):
3056         (loadAndEvaluateModule):
3057         This loadAndEvaluateModule should be implemented by just calling loadModule and
3058         linkAndEvaluateModule. We can drop requestReady and requestLink.
3059
3060         (requestLink): Deleted.
3061         (requestImportModule): Deleted.
3062         * jsc.cpp:
3063         (GlobalObject::moduleLoaderImportModule):
3064         (GlobalObject::moduleLoaderFetch):
3065         import and fetch hook takes parameters. Currently, we always pass `undefined` for
3066         import hook. When dynamic `import()` is extended to accept additional parameters
3067         like integrity, this parameters will be replaced with the actual value.
3068
3069         (functionLoadModule):
3070         (runWithOptions):
3071         * runtime/Completion.cpp:
3072         (JSC::loadAndEvaluateModule):
3073         (JSC::loadModule):
3074         (JSC::importModule):
3075         * runtime/Completion.h:
3076         * runtime/JSGlobalObject.h:
3077         * runtime/JSGlobalObjectFunctions.cpp:
3078         (JSC::globalFuncImportModule):
3079         * runtime/JSModuleLoader.cpp:
3080         (JSC::JSModuleLoader::loadAndEvaluateModule):
3081         (JSC::JSModuleLoader::loadModule):
3082         (JSC::JSModuleLoader::requestImportModule):
3083         (JSC::JSModuleLoader::importModule):
3084         (JSC::JSModuleLoader::fetch):
3085         * runtime/JSModuleLoader.h:
3086         * runtime/JSScriptFetchParameters.cpp: Added.
3087         (JSC::JSScriptFetchParameters::destroy):
3088         * runtime/JSScriptFetchParameters.h: Added.
3089         (JSC::JSScriptFetchParameters::createStructure):
3090         (JSC::JSScriptFetchParameters::create):
3091         (JSC::JSScriptFetchParameters::parameters const):
3092         (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
3093         Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
3094         It is used in the module pipeline.
3095
3096         * runtime/JSType.h:
3097         * runtime/ModuleLoaderPrototype.cpp:
3098         (JSC::moduleLoaderPrototypeFetch):
3099         * runtime/ScriptFetchParameters.h: Added.
3100         (JSC::ScriptFetchParameters::~ScriptFetchParameters):
3101         Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
3102         by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
3103         this.
3104
3105         * runtime/VM.cpp:
3106         (JSC::VM::VM):
3107         * runtime/VM.h:
3108
3109 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3110
3111         import.meta should not be assignable
3112         https://bugs.webkit.org/show_bug.cgi?id=178202
3113
3114         Reviewed by Saam Barati.
3115
3116         `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
3117         and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
3118         We change the parser not to allow assignments for MetaPropertyNode.
3119
3120         * bytecompiler/NodesCodegen.cpp:
3121         (JSC::ImportMetaNode::emitBytecode):
3122         * parser/ASTBuilder.h:
3123         (JSC::ASTBuilder::createImportMetaExpr):
3124         (JSC::ASTBuilder::isMetaProperty):
3125         (JSC::ASTBuilder::isImportMeta):
3126         * parser/NodeConstructors.h:
3127         (JSC::MetaPropertyNode::MetaPropertyNode):
3128         (JSC::NewTargetNode::NewTargetNode):
3129         (JSC::ImportMetaNode::ImportMetaNode):
3130         * parser/Nodes.h:
3131         (JSC::ExpressionNode::isMetaProperty const):
3132         (JSC::ExpressionNode::isImportMeta const):
3133         * parser/Parser.cpp:
3134         (JSC::Parser<LexerType>::metaPropertyName):
3135         (JSC::Parser<LexerType>::parseAssignmentExpression):
3136         (JSC::Parser<LexerType>::parseMemberExpression):
3137         (JSC::Parser<LexerType>::parseUnaryExpression):
3138         * parser/Parser.h:
3139         * parser/SyntaxChecker.h:
3140         (JSC::SyntaxChecker::createImportMetaExpr):
3141         (JSC::SyntaxChecker::isMetaProperty):
3142         (JSC::SyntaxChecker::isImportMeta):
3143
3144 2017-10-11  Saam Barati  <sbarati@apple.com>
3145
3146         Runtime disable poly proto because it may be a 3-4% Speedometer regression
3147         https://bugs.webkit.org/show_bug.cgi?id=178192
3148
3149         Reviewed by JF Bastien.
3150
3151         * runtime/Options.h:
3152         * runtime/StructureInlines.h:
3153         (JSC::Structure::shouldConvertToPolyProto):
3154
3155 2017-10-11  Commit Queue  <commit-queue@webkit.org>
3156
3157         Unreviewed, rolling out r223113 and r223121.
3158         https://bugs.webkit.org/show_bug.cgi?id=178182
3159
3160         Reintroduced 20% regression on Kraken (Requested by rniwa on
3161         #webkit).
3162
3163         Reverted changesets:
3164
3165         "Enable gigacage on iOS"
3166         https://bugs.webkit.org/show_bug.cgi?id=177586
3167         https://trac.webkit.org/changeset/223113
3168
3169         "Use one virtual allocation for all gigacages and their
3170         runways"
3171         https://bugs.webkit.org/show_bug.cgi?id=178050
3172         https://trac.webkit.org/changeset/223121
3173
3174 2017-10-11  Michael Saboff  <msaboff@apple.com>
3175
3176         Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
3177         https://bugs.webkit.org/show_bug.cgi?id=178106
3178
3179         Reviewed by Keith Miller.
3180
3181         * ucd/CaseFolding.txt:
3182
3183 2017-10-11  Caio Lima  <ticaiolima@gmail.com>
3184
3185         Object properties are undefined in super.call() but not in this.call()
3186         https://bugs.webkit.org/show_bug.cgi?id=177230
3187
3188         Reviewed by Saam Barati.
3189
3190         Bytecode generation for "super.call(...)" or "super.apply(...)"
3191         shouldn't be considered as CallFunctionCallDotNode or
3192         ApplyFunctionCallDotNode because they should be considered as common
3193         super property access as any other function. According to spec[1],
3194         "super" is not refering to parent constructor.
3195
3196         [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
3197
3198         * parser/ASTBuilder.h:
3199         (JSC::ASTBuilder::makeFunctionCallNode):
3200         * parser/Parser.cpp:
3201         (JSC::Parser<LexerType>::parseMemberExpression):
3202         * parser/SyntaxChecker.h:
3203         (JSC::SyntaxChecker::makeFunctionCallNode):
3204
3205 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3206
3207         [JSC] Drop Instantiate hook in ES6 module loader
3208         https://bugs.webkit.org/show_bug.cgi?id=178162
3209
3210         Reviewed by Sam Weinig.
3211
3212         This patch is a part of patch series for module loader refactoring to adopt
3213         integrity="" parameters and introduce new whatwg module import mechanism.
3214
3215         In this patch, we drop instantiate hook in module loader. This hook is originally
3216         introduced because it is defined in whatwg/loader spec. But this hook is not
3217         used in our implementation, and this hook won't be used since (1) whatwg/loader
3218         spec is abandoned, and (2) this type of hooks should be done in Service Workers.
3219
3220         In addition, this patch applies some cleaning up of our module loader JS code
3221         to simplify things. This change paves the way to more efficient loader implementation
3222         with great flexibility to adopt integrity="" parameters.
3223
3224         * builtins/ModuleLoaderPrototype.js:
3225         (requestInstantiate):
3226         (provideFetch):
3227         provide is changed to provideFetch since we only used this function with Fetch stage parameter.
3228
3229         (fulfillInstantiate): Deleted.
3230         (commitInstantiated): Deleted.
3231         (instantiation): Deleted.
3232         They are merged into requestInstantiate code. This is simpler.
3233
3234         (provide): Deleted.
3235         * jsc.cpp:
3236         * runtime/Completion.cpp:
3237         (JSC::loadAndEvaluateModule):
3238         (JSC::loadModule):
3239         * runtime/JSGlobalObject.cpp:
3240         * runtime/JSGlobalObject.h:
3241         * runtime/JSModuleLoader.cpp:
3242         (JSC::JSModuleLoader::provideFetch):
3243         (JSC::JSModuleLoader::provide): Deleted.
3244         Changed to provideFetch.
3245
3246         (JSC::JSModuleLoader::instantiate): Deleted.
3247         Drop this hook.
3248
3249         * runtime/JSModuleLoader.h:
3250         * runtime/ModuleLoaderPrototype.cpp:
3251         (JSC::moduleLoaderPrototypeInstantiate): Deleted.
3252         Drop this hook.
3253
3254 2017-10-10  Saam Barati  <sbarati@apple.com>
3255
3256         Prototype structure transition should be a deferred transition
3257         https://bugs.webkit.org/show_bug.cgi?id=177734
3258
3259         Reviewed by Keith Miller.
3260
3261         Absence ObjectPropertyConditions work by verifying both that the Structure 
3262         does not have a particular property and that its prototype has
3263         remained constant. However, the prototype transition was firing
3264         the transition watchpoint before setting the object's structure.
3265         This meant that isValid for Absence would never return false because
3266         the prototype changed. Clearly this is wrong. The reason this didn't
3267         break OPCs in general is that we'd also check if we could still watch
3268         the OPC. In this case, we can't still watch it because we're inspecting
3269         a structure with an invalidated transition watchpoint. To fix
3270         this weird quirk of the code, I'm making it so that doing a prototype
3271         transition uses the DeferredStructureTransitionWatchpointFire machinery.
3272         
3273         This patch also fixes some dead code that I left in regarding
3274         poly proto in OPC.
3275
3276         * bytecode/PropertyCondition.cpp:
3277         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
3278         * runtime/JSObject.cpp:
3279         (JSC::JSObject::setPrototypeDirect):
3280         * runtime/Structure.cpp:
3281         (JSC::Structure::changePrototypeTransition):
3282         * runtime/Structure.h:
3283
3284 2017-10-10  Robin Morisset  <rmorisset@apple.com>
3285
3286         Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
3287         https://bugs.webkit.org/show_bug.cgi?id=177926
3288
3289         Reviewed by Saam Barati.
3290
3291         When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
3292         With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
3293         The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
3294
3295         * dfg/DFGByteCodeParser.cpp:
3296         (JSC::DFG::ByteCodeParser::inlineCall):
3297         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3298         (JSC::DFG::ByteCodeParser::handleInlining):
3299         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
3300         (JSC::DFG::ByteCodeParser::parse):
3301
3302 2017-10-10  Guillaume Emont  <guijemont@igalia.com>
3303
3304         Fix compilation when MASM_PROBE (and therefore DFG) are disabled
3305         https://bugs.webkit.org/show_bug.cgi?id=178134
3306
3307         Reviewed by Saam Barati.
3308
3309         * bytecode/CodeBlock.cpp:
3310         * bytecode/CodeBlock.h:
3311         Disable some code when building without DFG_JIT.
3312
3313 2017-10-10  Sam Weinig  <sam@webkit.org>
3314
3315         Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
3316         https://bugs.webkit.org/show_bug.cgi?id=178102
3317
3318         Reviewed by Tim Horton.
3319
3320         * inspector/agents/InspectorDebuggerAgent.cpp:
3321         (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
3322
3323 2017-10-10  Michael Saboff  <msaboff@apple.com>
3324
3325         Unreviewed build fix.
3326
3327         Removed unused lambda capture.
3328
3329         * yarr/YarrPattern.cpp:
3330         (JSC::Yarr::CharacterClassConstructor::appendInverted):
3331
3332 2017-10-10  Saam Barati  <sbarati@apple.com>
3333
3334         The prototype cache should be aware of the Executable it generates a Structure for
3335         https://bugs.webkit.org/show_bug.cgi?id=177907
3336
3337         Reviewed by Filip Pizlo.
3338
3339         This patch renames PrototypeMap to StructureCache because
3340         it is no longer a map of the prototypes in the VM. It's
3341         only used to cache Structures during object construction.
3342         
3343         The main change of this patch is to guarantee that Structures generated
3344         by the create_this originating from different two different Executables'
3345         bytecode won't hash-cons to the same thing. Previously, we could hash-cons
3346         them depending on the JSObject* prototype pointer. This would cause the last
3347         thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
3348         happened because when we initialize a JSFunction's ObjectAllocationProfile,
3349         we set the resulting Structure's poly proto watchpoint. This could cause a Structure
3350         generating from some Executable e1 to end up with the poly proto watchpoint
3351         for another Executable e2 simply because JSFunctions backed by e1 and e2
3352         shared the same prototype. Then, based on profiling information, we may fire the
3353         wrong Executable's poly proto watchpoint. This patch fixes this bug by
3354         guaranteeing that Structures generating from create_this for different
3355         Executables are unique even if they share the same prototype by adding
3356         the FunctionExecutable* as another field in PrototypeKey.
3357
3358         * JavaScriptCore.xcodeproj/project.pbxproj:
3359         * Sources.txt:
3360         * bytecode/InternalFunctionAllocationProfile.h:
3361         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
3362         * bytecode/ObjectAllocationProfile.cpp:
3363         (JSC::ObjectAllocationProfile::initializeProfile):
3364         * dfg/DFGOperations.cpp:
3365         * runtime/CommonSlowPaths.cpp:
3366         (JSC::SLOW_PATH_DECL):
3367         * runtime/InternalFunction.cpp:
3368         (JSC::InternalFunction::createSubclassStructureSlow):
3369         * runtime/IteratorOperations.cpp:
3370         (JSC::createIteratorResultObjectStructure):
3371         * runtime/JSBoundFunction.cpp:
3372         (JSC::getBoundFunctionStructure):
3373         * runtime/JSGlobalObject.cpp:
3374         (JSC::JSGlobalObject::init):
3375         * runtime/ObjectConstructor.h:
3376         (JSC::constructEmptyObject):
3377         * runtime/PrototypeKey.h:
3378         (JSC::PrototypeKey::PrototypeKey):
3379         (JSC::PrototypeKey::executable const):
3380         (JSC::PrototypeKey::operator== const):
3381         (JSC::PrototypeKey::hash const):
3382         * runtime/PrototypeMap.cpp: Removed.
3383         * runtime/PrototypeMap.h: Removed.
3384         * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
3385         (JSC::StructureCache::createEmptyStructure):
3386         (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
3387         (JSC::StructureCache::emptyObjectStructureForPrototype):
3388         (JSC::PrototypeMap::createEmptyStructure): Deleted.
3389         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
3390         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
3391         * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
3392         (JSC::StructureCache::StructureCache):
3393         (JSC::PrototypeMap::PrototypeMap): Deleted.
3394         * runtime/VM.cpp:
3395         (JSC::VM::VM):
3396         * runtime/VM.h:
3397
3398 2017-10-09  Yusuke Suzuki  <utatane.tea@gmail.com>
3399
3400         `async` should be able to be used as an imported binding name
3401         https://bugs.webkit.org/show_bug.cgi?id=176573
3402
3403         Reviewed by Saam Barati.
3404
3405         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
3406         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
3407         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
3408         For example, import declaration failed to bind imported binding to the name "async" because
3409         the parser considered ASYNC as keyword.
3410
3411         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
3412         the current performance without using this ASYNC keyword.
3413
3414         We also add `escaped` field to token data since contextual keyword is valid only if it does
3415         not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
3416         e.g. `of in for-of`. This improves test262 score.
3417
3418         * parser/Keywords.table:
3419         * parser/Lexer.cpp:
3420         (JSC::Lexer<LChar>::parseIdentifier):
3421         (JSC::Lexer<UChar>::parseIdentifier):
3422         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
3423         * parser/Parser.cpp:
3424         (JSC::Parser<LexerType>::parseStatementListItem):
3425         (JSC::Parser<LexerType>::parseForStatement):
3426         (JSC::Parser<LexerType>::parseStatement):
3427         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
3428         (JSC::Parser<LexerType>::parseClass):
3429         (JSC::Parser<LexerType>::parseExportDeclaration):
3430         (JSC::Parser<LexerType>::parseAssignmentExpression):
3431         (JSC::Parser<LexerType>::parseProperty):
3432         (JSC::Parser<LexerType>::parsePrimaryExpression):
3433         (JSC::Parser<LexerType>::parseMemberExpression):
3434         (JSC::Parser<LexerType>::printUnexpectedTokenText):
3435         * parser/Parser.h:
3436         (JSC::Parser::matchContextualKeyword):
3437         * parser/ParserTokens.h:
3438         * runtime/CommonIdentifiers.h:
3439
3440 2017-10-09  Saam Barati  <sbarati@apple.com>
3441
3442         We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
3443         https://bugs.webkit.org/show_bug.cgi?id=177987
3444
3445         Reviewed by Filip Pizlo.
3446
3447         * runtime/JSProxy.cpp:
3448         (JSC::JSProxy::setTarget):
3449         * runtime/PrototypeMap.cpp:
3450         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
3451         * runtime/PrototypeMap.h:
3452
3453 2017-10-09  Filip Pizlo  <fpizlo@apple.com>
3454
3455         JSCell::didBecomePrototype is racy
3456         https://bugs.webkit.org/show_bug.cgi?id=178110
3457
3458         Reviewed by Saam Barati.
3459         
3460         The indexing type can be modified by any thread using CAS. So, we need to use atomics when
3461         modifying it. We don't need to use atomics when reading it though (since it's just one field).
3462
3463         * runtime/JSCellInlines.h:
3464         (JSC::JSCell::didBecomePrototype):
3465
3466 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
3467
3468         Enable gigacage on iOS
3469         https://bugs.webkit.org/show_bug.cgi?id=177586
3470
3471         Reviewed by JF Bastien.
3472
3473         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
3474         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
3475         have Gigacage. So, this teaches ARM64 how to load from global variables.
3476         
3477         Also, this makes the code handle disabling the gigacage a bit better.
3478
3479         * ftl/FTLLowerDFGToB3.cpp:
3480         (JSC::FTL::DFG::LowerDFGToB3::caged):
3481         * jit/AssemblyHelpers.h:
3482         (JSC::AssemblyHelpers::cage):
3483         (JSC::AssemblyHelpers::cageConditionally):
3484         * offlineasm/arm64.rb:
3485         * offlineasm/asm.rb:
3486         * offlineasm/instructions.rb:
3487
3488 2017-10-09  Robin Morisset  <rmorisset@apple.com>
3489
3490         Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
3491         https://bugs.webkit.org/show_bug.cgi?id=177925
3492
3493         Reviewed by Saam Barati.
3494
3495         We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
3496         the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
3497         that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not).
3498
3499         * dfg/DFGByteCodeParser.cpp:
3500         (JSC::DFG::ByteCodeParser::parseBlock):
3501         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3502
3503 2017-10-09  Robin Morisset  <rmorisset@apple.com>
3504
3505         Refactor the inliner to simplify block linking
3506         https://bugs.webkit.org/show_bug.cgi?id=177922
3507
3508         Reviewed by Saam Barati.
3509
3510         The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
3511         some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
3512         - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
3513         - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
3514         Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
3515         This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
3516         or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
3517         terminal that needs to be taken off m_unlinkedBlocks.
3518         I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
3519         that is the one that holds their target in its m_linkingTargets field.
3520
3521         There are a few much smaller refactors in this patch:
3522         - parse() is now of type void insted of bool (it was always returning true)
3523         - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
3524         - The 9 argument version was cleaned up and simplified
3525         - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
3526         - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
3527         - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)
3528
3529         * dfg/DFGByteCodeParser.cpp:
3530         (JSC::DFG::ByteCodeParser::addToGraph):
3531         (JSC::DFG::ByteCodeParser::handleCall):
3532         (JSC::DFG::ByteCodeParser::refineStatically):
3533         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
3534         (JSC::DFG::ByteCodeParser::handleVarargsCall):
3535         (JSC::DFG::ByteCodeParser::inlineCall):
3536         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3537         (JSC::DFG::ByteCodeParser::handleInlining):
3538         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3539         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3540         (JSC::DFG::ByteCodeParser::parseBlock):
3541         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3542         (JSC::DFG::ByteCodeParser::parse):
3543         (JSC::DFG::parse):
3544         (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
3545         * dfg/DFGByteCodeParser.h:
3546         * dfg/DFGPlan.cpp:
3547         (JSC::DFG::Plan::compileInThreadImpl):
3548
3549 2017-10-09  Michael Saboff  <msaboff@apple.com>
3550
3551         Implement RegExp Unicode property escapes
3552         https://bugs.webkit.org/show_bug.cgi?id=172069
3553
3554         Reviewed by JF Bastien.
3555
3556         Added Unicode Properties by extending the existing CharacterClass processing.
3557
3558         Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
3559         Unicode Database files to create character class data.  The result is a set of functions
3560         that return character classes, one for each of the required Unicode properties.
3561         There are many cases where many properties are handled by one function, primarily due to
3562         property aliases, but also due to Script_Extension properties that are the same as the
3563         Script property for the same script value.
3564
3565         Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
3566         character classes.  Unicode properties are the enum value BaseUnicodePropertyID plus a
3567         zero based value, that value being the index to the corrensponding character class
3568         function.  The generation script also creates static hashing tables similar to what we
3569         use for the generated .lut.h lookup table files.  These hashing tables map property
3570         names to the function index.  Using these hashing tables, we can lookup a property
3571         name and if present convert it to a function index.  We add that index to
3572         BaseUnicodePropertyID to create a BuiltInCharacterClassID.
3573
3574         When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
3575         When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
3576         the actual character class by calling the corresponding generated function.
3577
3578         Added a new CharacterClass constructor that can take literal arrays for ranges and matches
3579         to make the creation of large static character classes more efficent.
3580
3581         Since the Unicode character classes typically have more matches and ranges, the character
3582         class matching in the interpreter has been updated to use binary searching for matches and
3583         ranges with more than 6 entries.
3584
3585         * CMakeLists.txt:
3586         * DerivedSources.make:
3587         * JavaScriptCore.xcodeproj/project.pbxproj:
3588         * Scripts/generateYarrUnicodePropertyTables.py: Added.
3589         (openOrExit):
3590         (openUCDFileOrExit):
3591         (verifyUCDFilesExist):
3592         (ceilingToPowerOf2):
3593         (Aliases):
3594         (Aliases.__init__):
3595         (Aliases.parsePropertyAliasesFile):
3596         (Aliases.parsePropertyValueAliasesFile):
3597         (Aliases.globalAliasesFor):
3598         (Aliases.generalCategoryAliasesFor):
3599         (Aliases.generalCategoryForAlias):
3600         (Aliases.scriptAliasesFor):
3601         (Aliases.scriptNameForAlias):
3602         (PropertyData):
3603         (PropertyData.__init__):
3604         (PropertyData.setAliases):
3605         (PropertyData.makeCopy):
3606         (PropertyData.getIndex):
3607         (PropertyData.getCreateFuncName):
3608         (PropertyData.addMatch):
3609         (PropertyData.addRange):
3610         (PropertyData.addMatchUnorderedForMatchesAndRanges):
3611         (PropertyData.addRangeUnorderedForMatchesAndRanges):
3612         (PropertyData.addMatchUnordered):
3613         (PropertyData.addRangeUnordered):
3614         (PropertyData.removeMatchFromRanges):
3615         (PropertyData.removeMatch):
3616         (PropertyData.dumpMatchData):
3617         (PropertyData.dump):
3618         (PropertyData.dumpAll):
3619         (PropertyData.dumpAll.std):
3620         (PropertyData.createAndDumpHashTable):
3621         (Scripts):
3622         (Scripts.__init__):
3623         (Scripts.parseScriptsFile):
3624         (Scripts.parseScriptExtensionsFile):
3625         (Scripts.dump):
3626         (GeneralCategory):
3627         (GeneralCategory.__init__):
3628         (GeneralCategory.createSpecialPropertyData):
3629         (GeneralCategory.findPropertyGroupFor):
3630         (GeneralCategory.addNextCodePoints):
3631         (GeneralCategory.parse):
3632         (GeneralCategory.dump):
3633         (BinaryProperty):
3634         (BinaryProperty.__init__):
3635         (BinaryProperty.parsePropertyFile):
3636         (BinaryProperty.dump):
3637         * Scripts/hasher.py: Added.
3638         (stringHash):
3639         * Sources.txt:
3640         * ucd/DerivedBinaryProperties.txt: Added.
3641         * ucd/DerivedCoreProperties.txt: Added.
3642         * ucd/DerivedNormalizationProps.txt: Added.
3643         * ucd/PropList.txt: Added.
3644         * ucd/PropertyAliases.txt: Added.
3645         * ucd/PropertyValueAliases.txt: Added.
3646         * ucd/ScriptExtensions.txt: Added.
3647         * ucd/Scripts.txt: Added.
3648         * ucd/UnicodeData.txt: Added.
3649         * ucd/emoji-data.txt: Added.
3650         * yarr/Yarr.h:
3651         * yarr/YarrInterpreter.cpp:
3652         (JSC::Yarr::Interpreter::testCharacterClass):
3653         * yarr/YarrParser.h:
3654         (JSC::Yarr::Parser::parseEscape):
3655         (JSC::Yarr::Parser::parseTokens):
3656         (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
3657         (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
3658         * yarr/YarrPattern.cpp:
3659         (JSC::Yarr::CharacterClassConstructor::appendInverted):
3660         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
3661         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
3662         (JSC::Yarr::YarrPattern::errorMessage):
3663         (JSC::Yarr::PatternTerm::dump):
3664         * yarr/YarrPattern.h:
3665         (JSC::Yarr::CharacterRange::CharacterRange):
3666         (JSC::Yarr::CharacterClass::CharacterClass):
3667         (JSC::Yarr::YarrPattern::reset):
3668         (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
3669         * yarr/YarrUnicodeProperties.cpp: Added.
3670         (JSC::Yarr::HashTable::entry const):
3671         (JSC::Yarr::unicodeMatchPropertyValue):
3672         (JSC::Yarr::unicodeMatchProperty):
3673         (JSC::Yarr::createUnicodeCharacterClassFor):
3674         * yarr/YarrUnicodeProperties.h: Added.
3675
3676 2017-10-09  Commit Queue  <commit-queue@webkit.org>
3677
3678         Unreviewed, rolling out r223015 and r223025.
3679         https://bugs.webkit.org/show_bug.cgi?id=178093
3680
3681         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
3682         #webkit).
3683
3684         Reverted changesets:
3685
3686         "Enable gigacage on iOS"
3687         https://bugs.webkit.org/show_bug.cgi?id=177586
3688         http://trac.webkit.org/changeset/223015
3689
3690         "Unreviewed, disable Gigacage on ARM64 Linux"
3691         https://bugs.webkit.org/show_bug.cgi?id=177586
3692         http://trac.webkit.org/changeset/223025
3693
3694 2017-10-09  Keith Miller  <keith_miller@apple.com>
3695
3696         Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.
3697
3698         * JavaScriptCore.xcodeproj/project.pbxproj:
3699
3700 2017-10-09  Ryan Haddad  <ryanhaddad@apple.com>
3701
3702         Unreviewed, rolling out r223022.
3703
3704         This change introduced 18 test262 failures.
3705
3706         Reverted changeset:
3707
3708         "`async` should be able to be used as an imported binding
3709         name"
3710         https://bugs.webkit.org/show_bug.cgi?id=176573
3711         http://trac.webkit.org/changeset/223022
3712
3713 2017-10-09  Robin Morisset  <rmorisset@apple.com>
3714
3715         Make the names of the options consistent
3716         https://bugs.webkit.org/show_bug.cgi?id=177933
3717
3718         Reviewed by Saam Barati.
3719
3720         I added an alias so the old spelling still works.
3721         I also fixed a bunch of typos in comments all around the codebase.
3722
3723         * b3/B3LowerToAir.cpp:
3724         * dfg/DFGByteCodeParser.cpp:
3725         (JSC::DFG::ByteCodeParser::parseBlock):
3726         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
3727         * dfg/DFGOperations.h:
3728         * dfg/DFGSSAConversionPhase.h:
3729         * dfg/DFGSpeculativeJIT.h:
3730         * ftl/FTLLowerDFGToB3.cpp:
3731         (JSC::FTL::DFG::LowerDFGToB3::lower):
3732         * ftl/FTLOSREntry.cpp:
3733         (JSC::FTL::prepareOSREntry):
3734         * jit/CallFrameShuffler.cpp:
3735         (JSC::CallFrameShuffler::prepareForTailCall):
3736         * parser/Nodes.h:
3737         * parser/Parser.cpp:
3738         (JSC::Parser<LexerType>::parseExportDeclaration):
3739         * runtime/Options.h:
3740
3741 2017-10-09  Oleksandr Skachkov  <gskachkov@gmail.com>
3742
3743         Safari 10 /11 problem with if (!await get(something)).
3744         https://bugs.webkit.org/show_bug.cgi?id=176685
3745
3746         Reviewed by Saam Barati.
3747
3748         Using unary operator before `await` lead to count it as identifier.
3749         According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions
3750         and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator
3751
3752         * parser/Parser.cpp:
3753         (JSC::Parser<LexerType>::parsePrimaryExpression):
3754
3755 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
3756
3757         direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC
3758         https://bugs.webkit.org/show_bug.cgi?id=178051
3759
3760         Reviewed by Saam Barati.
3761         
3762         After I studied the profile of this test, I found two pathologies in our code relating to
3763         prototypes. I think that now that we support poly proto, it's more likely for these pathologies to
3764         happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests
3765         to trigger these pathologies.
3766         
3767         - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns
3768           this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note
3769           that we still have 6 spare bits in cellState, but those are a bit more annoying to get at.
3770         
3771         - WeakGCMap registers itself with GC using a std::function. That means allocating things in the
3772           malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is
3773           a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have
3774           a lot of transition tables. It's good to reduce the amount of memory those require.
3775         
3776         Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while
3777         I was at it. I initially thought that this would have to be part of my solution, but it turned out
3778         not to be. I think it's worth landing anyway since it makes the code a lot more clear.
3779         
3780         This fixes the timeout in that test and probably reduces memory consumption.
3781
3782         * JavaScriptCore.xcodeproj/project.pbxproj:
3783         * dfg/DFGOperations.cpp:
3784         * heap/Heap.cpp:
3785         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
3786         (JSC::Heap::registerWeakGCMap):
3787         (JSC::Heap::unregisterWeakGCMap):
3788         * heap/Heap.h:
3789         * inspector/JSInjectedScriptHostPrototype.cpp:
3790         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3791         * inspector/JSJavaScriptCallFramePrototype.cpp:
3792         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
3793         * runtime/ArrayIteratorPrototype.cpp:
3794         (JSC::ArrayIteratorPrototype::finishCreation):
3795         * runtime/ArrayPrototype.cpp:
3796         (JSC::ArrayPrototype::finishCreation):
3797         * runtime/AsyncFromSyncIteratorPrototype.cpp:
3798         (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
3799         * runtime/AsyncFunctionPrototype.cpp:
3800         (JSC::AsyncFunctionPrototype::finishCreation):
3801         * runtime/AsyncGeneratorFunctionPrototype.cpp:
3802         (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
3803         * runtime/AsyncGeneratorPrototype.cpp:
3804         (JSC::AsyncGeneratorPrototype::finishCreation):
3805         * runtime/AsyncIteratorPrototype.cpp:
3806         (JSC::AsyncIteratorPrototype::finishCreation):
3807         * runtime/CommonSlowPaths.cpp:
3808         (JSC::SLOW_PATH_DECL):
3809         * runtime/GeneratorFunctionPrototype.cpp:
3810         (JSC::GeneratorFunctionPrototype::finishCreation):
3811         * runtime/GeneratorPrototype.cpp:
3812         (JSC::GeneratorPrototype::finishCreation):
3813         * runtime/IndexingType.h:
3814         * runtime/IteratorPrototype.cpp:
3815         (JSC::IteratorPrototype::finishCreation):
3816         * runtime/JSCInlines.h:
3817         * runtime/JSCell.h:
3818         * runtime/JSCellInlines.h:
3819         (JSC::JSCell::mayBePrototype const):
3820         (JSC::JSCell::didBecomePrototype):
3821         * runtime/JSObject.cpp:
3822         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
3823         (JSC::JSObject::setPrototypeDirect):
3824         * runtime/JSProxy.cpp:
3825         (JSC::JSProxy::setTarget):
3826         * runtime/MapIteratorPrototype.cpp:
3827         (JSC::MapIteratorPrototype::finishCreation):
3828         * runtime/MapPrototype.cpp:
3829         (JSC::MapPrototype::finishCreation):
3830         * runtime/ObjectPrototype.cpp:
3831         (JSC::ObjectPrototype::finishCreation):
3832         * runtime/PrototypeKey.h: Added.
3833         (JSC::PrototypeKey::PrototypeKey):
3834         (JSC::PrototypeKey::prototype const):
3835         (JSC::PrototypeKey::inlineCapacity const):
3836         (JSC::PrototypeKey::classInfo const):
3837         (JSC::PrototypeKey::globalObject const):
3838         (JSC::PrototypeKey::operator== const):
3839         (JSC::PrototypeKey::operator!= const):
3840         (JSC::PrototypeKey::operator bool const):
3841         (JSC::PrototypeKey::isHashTableDeletedValue const):
3842         (JSC::PrototypeKey::hash const):
3843         (JSC::PrototypeKeyHash::hash):
3844         (JSC::PrototypeKeyHash::equal):
3845         * runtime/PrototypeMap.cpp:
3846         (JSC::PrototypeMap::createEmptyStructure):
3847         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
3848         * runtime/PrototypeMap.h:
3849         (JSC::PrototypeMap::PrototypeMap):
3850         * runtime/PrototypeMapInlines.h: Removed.
3851         * runtime/SetIteratorPrototype.cpp:
3852         (JSC::SetIteratorPrototype::finishCreation):
3853         * runtime/SetPrototype.cpp:
3854         (JSC::SetPrototype::finishCreation):
3855         * runtime/StringIteratorPrototype.cpp:
3856         (JSC::StringIteratorPrototype::finishCreation):
3857         * runtime/WeakGCMap.h:
3858         (JSC::WeakGCMapBase::~WeakGCMapBase):
3859         * runtime/WeakGCMapInlines.h:
3860         (JSC::KeyTraitsArg>::WeakGCMap):
3861         * runtime/WeakMapPrototype.cpp:
3862         (JSC::WeakMapPrototype::finishCreation):
3863         * runtime/WeakSetPrototype.cpp:
3864         (JSC::WeakSetPrototype::finishCreation):
3865
3866 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
3867
3868         Octane/splay can leak memory due to stray pointers on the stack when run from the command line
3869         https://bugs.webkit.org/show_bug.cgi?id=178054
3870
3871         Reviewed by Saam Barati.
3872         
3873         This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In
3874         most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack
3875         height stays relatively constant.
3876
3877         * dfg/DFGOperations.cpp:
3878         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3879         (JSC::DFG::TierUpCheckInjectionPhase::run):
3880         * ftl/FTLOSREntry.cpp:
3881         * heap/Heap.cpp:
3882         (JSC::Heap::runCurrentPhase):
3883         * heap/MarkedAllocatorInlines.h:
3884