[JSC] Remove per-host-function CTI stub in 32bit environment
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-10-21  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [JSC] Remove per-host-function CTI stub in 32bit environment
4         https://bugs.webkit.org/show_bug.cgi?id=178581
5
6         Reviewed by Saam Barati.
7
8         JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
9         The only difference is that it embed the address of the host function directly in the generated stub. This means
10         that we have per-host-function CTI stub only in 32bit environment.
11
12         This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
13
14         * jit/JIT.cpp:
15         (JSC::JIT::compileCTINativeCall): Deleted.
16         * jit/JIT.h:
17         * jit/JITOpcodes.cpp:
18         (JSC::JIT::privateCompileCTINativeCall): Deleted.
19         * jit/JITOpcodes32_64.cpp:
20         (JSC::JIT::privateCompileCTINativeCall): Deleted.
21         * jit/JITThunks.cpp:
22         (JSC::JITThunks::hostFunctionStub):
23
24 2017-10-20  Antoine Quint  <graouts@apple.com>
25
26         [Web Animations] Provide basic timeline and animation interfaces
27         https://bugs.webkit.org/show_bug.cgi?id=178526
28
29         Reviewed by Dean Jackson.
30
31         Remove the WEB_ANIMATIONS compile-time flag.
32
33         * Configurations/FeatureDefines.xcconfig:
34
35 2017-10-20  Commit Queue  <commit-queue@webkit.org>
36
37         Unreviewed, rolling out r223744, r223750, and r223751.
38         https://bugs.webkit.org/show_bug.cgi?id=178594
39
40         These caused consistent failures in test that existed and were
41         added in the patches. (Requested by mlewis13 on #webkit).
42
43         Reverted changesets:
44
45         "[JSC] ScriptFetcher should be notified directly from module
46         pipeline"
47         https://bugs.webkit.org/show_bug.cgi?id=178340
48         https://trac.webkit.org/changeset/223744
49
50         "Unreviewed, fix changed line number in test expect files"
51         https://bugs.webkit.org/show_bug.cgi?id=178340
52         https://trac.webkit.org/changeset/223750
53
54         "Unreviewed, follow up to reflect comments"
55         https://bugs.webkit.org/show_bug.cgi?id=178340
56         https://trac.webkit.org/changeset/223751
57
58 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
59
60         Unreviewed, follow up to reflect comments
61         https://bugs.webkit.org/show_bug.cgi?id=178340
62
63         * runtime/JSModuleLoader.cpp:
64         (JSC::JSModuleLoader::notifyCompleted):
65
66 2017-10-20  Saam Barati  <sbarati@apple.com>
67
68         Optimize accesses to how we get the direct prototype
69         https://bugs.webkit.org/show_bug.cgi?id=178548
70
71         Reviewed by Yusuke Suzuki.
72
73         This patch makes JSObject::getPrototypeDirect take VM& as a parameter
74         so it can use the faster version of the structure accessor function.
75         The reason for making this change is that JSObjet::getPrototypeDirect
76         is called on the hot path in property lookup.
77
78         * API/JSObjectRef.cpp:
79         (JSObjectGetPrototype):
80         * jsc.cpp:
81         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
82         (WTF::DOMJITGetterBaseJSObject::customGetter):
83         (functionCreateProxy):
84         * runtime/ArrayPrototype.cpp:
85         (JSC::speciesWatchpointIsValid):
86         * runtime/ErrorInstance.cpp:
87         (JSC::ErrorInstance::sanitizedToString):
88         * runtime/JSArray.cpp:
89         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
90         * runtime/JSGlobalObject.cpp:
91         (JSC::JSGlobalObject::init):
92         (JSC::lastInPrototypeChain):
93         (JSC::JSGlobalObject::resetPrototype):
94         (JSC::JSGlobalObject::finishCreation):
95         * runtime/JSGlobalObjectInlines.h:
96         (JSC::JSGlobalObject::objectPrototypeIsSane):
97         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
98         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
99         * runtime/JSLexicalEnvironment.cpp:
100         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
101         * runtime/JSMap.cpp:
102         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
103         * runtime/JSObject.cpp:
104         (JSC::JSObject::calculatedClassName):
105         (JSC::JSObject::setPrototypeWithCycleCheck):
106         (JSC::JSObject::getPrototype):
107         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
108         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
109         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
110         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
111         * runtime/JSObject.h:
112         (JSC::JSObject::finishCreation):
113         (JSC::JSObject::getPrototypeDirect const):
114         (JSC::JSObject::getPrototype):
115         * runtime/JSObjectInlines.h:
116         (JSC::JSObject::canPerformFastPutInline):
117         (JSC::JSObject::getPropertySlot):
118         (JSC::JSObject::getNonIndexPropertySlot):
119         * runtime/JSProxy.cpp:
120         (JSC::JSProxy::setTarget):
121         * runtime/JSSet.cpp:
122         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
123         * runtime/ProgramExecutable.cpp:
124         (JSC::ProgramExecutable::initializeGlobalProperties):
125         * runtime/StructureInlines.h:
126         (JSC::Structure::isValid const):
127
128 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
129
130         [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
131         https://bugs.webkit.org/show_bug.cgi?id=178379
132
133         Reviewed by Saam Barati.
134
135         We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
136         in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
137
138         * bytecompiler/NodesCodegen.cpp:
139         (JSC::BinaryOpNode::emitBytecode):
140
141 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
142
143         [JSC] ScriptFetcher should be notified directly from module pipeline
144         https://bugs.webkit.org/show_bug.cgi?id=178340
145
146         Reviewed by Sam Weinig.
147
148         Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
149         We setup JSStdFunction to the resulted promise of the module pipeline. It is super
150         ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
151         JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
152
153         But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
154         notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
155         from the module pipeline by observer style.
156
157         This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
158         completion/failure notifications from the module pipeline.
159
160         * builtins/ModuleLoaderPrototype.js:
161         (loadModule):
162         (loadAndEvaluateModule):
163         * runtime/Completion.cpp:
164         (JSC::loadModule):
165         * runtime/Completion.h:
166         * runtime/JSModuleLoader.cpp:
167         (JSC::jsValueToModuleKey):
168         (JSC::JSModuleLoader::notifyCompleted):
169         (JSC::JSModuleLoader::notifyFailed):
170         * runtime/JSModuleLoader.h:
171         * runtime/ModuleLoaderPrototype.cpp:
172         (JSC::moduleLoaderPrototypeNotifyCompleted):
173         (JSC::moduleLoaderPrototypeNotifyFailed):
174         * runtime/ScriptFetcher.h:
175         (JSC::ScriptFetcher::notifyLoadCompleted):
176         (JSC::ScriptFetcher::notifyLoadFailed):
177
178 2017-10-19  JF Bastien  <jfbastien@apple.com>
179
180         WebAssembly: no VM / JS version of everything but Instance
181         https://bugs.webkit.org/show_bug.cgi?id=177473
182
183         Reviewed by Filip Pizlo, Saam Barati.
184
185         This change entails cleaning up and splitting a bunch of code which we had
186         intertwined between C++ classes which represent JS objects, and pure C++
187         implementation objects. This specific change goes most of the way towards
188         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
189         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
190         yet). Because of this we still have a few FIXME identifying places that need to
191         change. A follow-up change will go the rest of the way.
192
193         I went about this change in the simplest way possible: grep the
194         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
195         sub-directory (which contains the JS implementation of WebAssembly).
196
197         None of this change removes the need for a JIT entitlement to be able to use
198         WebAssembly. We don't have an interpreter, the process therefore still needs to
199         be allowed to JIT to use these pure-C++ APIs.
200
201         Interesting things to note:
202
203           - Remove VM from Plan and associated places. It can just live as a capture in
204             the callback lambda if it's needed.
205           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
206             collect. We now instead pass two lambdas at construction time for this
207             purpose: one to notify of memory pressure, and the other to ask for
208             syncrhonous memory reclamation. This allows whoever creates the memory to
209             dictate how to react to both these cases, and for a JS embedding that's to
210             call the GC (async or sync, respectively).
211           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
212             there, with an enum class for failure types.
213           - Exceeding max on memory growth now returns a range error as per spec. This
214             is a (very minor) breaking change: it used to throw OOM error. Update the
215             corresponding test.
216           - When generating the grow_memory opcode, no need to get the VM. Instead,
217             reach directly for Wasm::Memory and grow it.
218           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
219             ever called from JS (not from grow_memory as before).
220           - Wasm::Memory now takes a callback for successful growth. This allows JS
221             wrappers to register themselves when growth succeeds without Wasm::Memory
222             knowning anything about JS. It'll also allow creating a list of callbacks
223             for when we add thread support (we'll want to notify many wrappers, all
224             under a lock).
225           - Wasm::Memory is now back to being the source of truth about address / size,
226             used directly by generated code instead of JSWebAssemblyMemory.
227           - Move wasmToJS from the general WasmBinding header to its own header under
228             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
229             and therefore isn't general WebAssembly.
230           - Make Wasm::Context an actual type (just a struct holding a
231             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
232             doesn't add anything to the Context and doesn't change what actually gets
233             passed around in JIT code (fast TLS or registers) because these changes
234             potentially impact performance. The entire purpose of this change is to
235             allow passing Wasm::Context around without having to know about VM. Since VM
236             contains a Wasm::Context the JS embedding is effectively the same, but with
237             this setup a non-JS embedding is much better off.
238           - Move JSWebAssembly into the JS folder.
239           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
240           - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
241             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
242             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
243             called wasm->JS stub. This move means that the embedder must, after creating
244             a Wasm::CodeBlock, somehow create the stubs to call back into the
245             embedder. This removes an indirection in the generated code because
246             the B3 IR generator now reaches into the instance instead of
247             JSWebAssemblyCodeBlock.
248           - Move more CodeBlock things. Compilation completion is now marked by its own
249             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
250             was causing a deadlock in stack-trace.js because before my changes
251             JSWebAssemblyCodeBlock did its own completion checking separately from
252             Wasm::CodeBlock, without getting the lock. Now that everything points to
253             Wasm::CodeBlock and there's no cached completion marker, the lock was being
254             acquired in a sanity-check assertion.
255           - Embedder -> Wasm wrappers are now generated through a function that's passed
256             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
257           - WasmMemory doens't need to know about fault handling thunks. Only the IR
258             generator should know, and should make sure that the exception throwing
259             thunk is generated if any memory is present (note: with signal handling not
260             all of them generate an exception check).
261           - Make exception throwing pluggable: instead of having a hard-coded
262             JS-specific lambda we now have a regular C++ function being called from JIT
263             code when a WebAssembly exception is thrown. This allows any embedder to get
264             called as they wish. For now a process can only have a single of these
265             functions (i.e. only one embedder per process) because the trap handler is a
266             singleton. That can be fixed in in #177475.
267           - Create WasmEmbedder.h where all embedder plugging will live.
268           - Split up JSWebAssemblyTable into Wasm::Table which is
269             refcounted. JSWebAssemblyTable now only contains the JS functions in the
270             table, and Wasm::Table is what's used by the JIT code to lookup where to
271             call and do the instance check (for context switch). Note that this creates
272             an extra allocation for all the instances in Wasm::Table, and in exchange
273             removes an indirection in JIT code because the instance used to be obtained
274             off of the JS function. Also note that it's the embedder than keeps the
275             instances alive, not Wasm::Table (which holds a dumb pointer to the
276             instance), because doing otherwise would cause reference cycles.
277            - Add WasmInstance. It doesn't do much for now, owns globals.
278            - JSWebAssembly instance now doesn't just contain the imported functions as
279              JSObjects, it also has the corresponding import's instance and wasm
280              entrypoint. This triples the space allocated per instance's imported
281              function, but there shouldn't be that many imports. This has two upsides: it
282              creates smaller and faster code, and makes is easier to disassociate
283              embedder-specific things from embedder-neutral things. The small / faster
284              win is in two places: B3 IR generator only needs offsetOfImportFunction for
285              the call opcode (when the called index is an import) to know whether the
286              import is wasm->wasm or wasm->embedder (this isn't known at compile-time
287              because it's dependent on the import object), this is now done by seeing if
288              that import function has an associated target instance (only wasm->wasm
289              does); the other place is wasmBinding which uses offsetOfImportFunction to
290              figure out the wasm->wasm target instance, and then gets
291              WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
292              call. The disassociation comes because the target instance can be
293              Wasm::Instance once we change what the Context is, and
294              WasmEntrypointLoadLocation is already embedder-independent. As a next step I
295              can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
296              and leave importFunction in as an opaque pointer which is embedder-specific,
297              and in JS will remain WriteBarrier<JSObject>.
298            - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
299              around instead of VM. This is a first step in allowing entry frames which
300              aren't stored on VM, but which are instead stored in an embedder-specific
301              location. That change won't really affect JS except through code churn, but
302              will allow WebAssembly to use some machinery in a generic manner without
303              having a VM.
304
305         * JavaScriptCore.xcodeproj/project.pbxproj:
306         * Sources.txt:
307         * bytecode/PolymorphicAccess.cpp:
308         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
309         * debugger/Debugger.cpp:
310         (JSC::Debugger::stepOutOfFunction):
311         (JSC::Debugger::returnEvent):
312         (JSC::Debugger::unwindEvent):
313         (JSC::Debugger::didExecuteProgram):
314         * dfg/DFGJITCompiler.cpp:
315         (JSC::DFG::JITCompiler::compileExceptionHandlers):
316         * dfg/DFGOSREntry.cpp:
317         (JSC::DFG::prepareOSREntry):
318         * dfg/DFGOSRExit.cpp:
319         (JSC::DFG::OSRExit::compileOSRExit):
320         (JSC::DFG::OSRExit::compileExit):
321         * dfg/DFGThunks.cpp:
322         (JSC::DFG::osrEntryThunkGenerator):
323         * ftl/FTLCompile.cpp:
324         (JSC::FTL::compile):
325         * ftl/FTLLink.cpp:
326         (JSC::FTL::link):
327         * ftl/FTLLowerDFGToB3.cpp:
328         (JSC::FTL::DFG::LowerDFGToB3::lower):
329         * ftl/FTLOSRExitCompiler.cpp:
330         (JSC::FTL::compileStub):
331         * interpreter/CallFrame.cpp:
332         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
333         (JSC::CallFrame::callerFrame):
334         (JSC::CallFrame::unsafeCallerFrame):
335         * interpreter/CallFrame.h:
336         (JSC::ExecState::callerFrame const):
337         (JSC::ExecState::callerFrameOrEntryFrame const):
338         (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
339         * interpreter/FrameTracers.h:
340         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
341         (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
342         (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
343         * interpreter/Interpreter.cpp:
344         (JSC::UnwindFunctor::operator() const):
345         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
346         (JSC::Interpreter::unwind):
347         * interpreter/StackVisitor.cpp:
348         (JSC::StackVisitor::StackVisitor):
349         (JSC::StackVisitor::gotoNextFrame):
350         (JSC::StackVisitor::readNonInlinedFrame):
351         (JSC::StackVisitor::Frame::dump const):
352         * interpreter/StackVisitor.h:
353         (JSC::StackVisitor::Frame::callerIsEntryFrame const):
354         * interpreter/VMEntryRecord.h:
355         (JSC::VMEntryRecord::prevTopEntryFrame):
356         (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
357         (JSC::EntryFrame::vmEntryRecordOffset):
358         * jit/AssemblyHelpers.cpp:
359         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
360         (JSC::AssemblyHelpers::loadWasmContextInstance):
361         (JSC::AssemblyHelpers::storeWasmContextInstance):
362         (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
363         (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
364         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
365         * jit/AssemblyHelpers.h:
366         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
367         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
368         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
369         * jit/JIT.cpp:
370         (JSC::JIT::emitEnterOptimizationCheck):
371         (JSC::JIT::privateCompileExceptionHandlers):
372         * jit/JITExceptions.cpp:
373         (JSC::genericUnwind):
374         * jit/JITOpcodes.cpp:
375         (JSC::JIT::emit_op_throw):
376         (JSC::JIT::emit_op_catch):
377         (JSC::JIT::emitSlow_op_loop_hint):
378         * jit/JITOpcodes32_64.cpp:
379         (JSC::JIT::emit_op_throw):
380         (JSC::JIT::emit_op_catch):
381         * jit/JITOperations.cpp:
382         * jit/ThunkGenerators.cpp:
383         (JSC::throwExceptionFromCallSlowPathGenerator):
384         (JSC::nativeForGenerator):
385         * jsc.cpp:
386         (functionDumpCallFrame):
387         * llint/LLIntSlowPaths.cpp:
388         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
389         * llint/LLIntThunks.cpp:
390         (JSC::vmEntryRecord):
391         * llint/LowLevelInterpreter.asm:
392         * llint/LowLevelInterpreter32_64.asm:
393         * llint/LowLevelInterpreter64.asm:
394         * runtime/Options.cpp:
395         (JSC::recomputeDependentOptions):
396         * runtime/Options.h:
397         * runtime/SamplingProfiler.cpp:
398         (JSC::FrameWalker::FrameWalker):
399         (JSC::FrameWalker::advanceToParentFrame):
400         (JSC::SamplingProfiler::processUnverifiedStackTraces):
401         * runtime/ThrowScope.cpp:
402         (JSC::ThrowScope::~ThrowScope):
403         * runtime/VM.cpp:
404         (JSC::VM::VM):
405         (JSC::VM::~VM):
406         * runtime/VM.h:
407         (JSC::VM::topEntryFrameOffset):
408         * runtime/VMTraps.cpp:
409         (JSC::isSaneFrame):
410         (JSC::VMTraps::tryInstallTrapBreakpoints):
411         (JSC::VMTraps::invalidateCodeBlocksOnStack):
412         * wasm/WasmB3IRGenerator.cpp:
413         (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
414         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
415         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
416         (JSC::Wasm::B3IRGenerator::addGrowMemory):
417         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
418         (JSC::Wasm::B3IRGenerator::addCall):
419         (JSC::Wasm::B3IRGenerator::addCallIndirect):
420         (JSC::Wasm::parseAndCompile):
421         * wasm/WasmB3IRGenerator.h:
422         * wasm/WasmBBQPlan.cpp:
423         (JSC::Wasm::BBQPlan::BBQPlan):
424         (JSC::Wasm::BBQPlan::compileFunctions):
425         (JSC::Wasm::BBQPlan::complete):
426         * wasm/WasmBBQPlan.h:
427         * wasm/WasmBBQPlanInlines.h:
428         (JSC::Wasm::BBQPlan::initializeCallees):
429         * wasm/WasmBinding.cpp:
430         (JSC::Wasm::wasmToWasm):
431         * wasm/WasmBinding.h:
432         * wasm/WasmCodeBlock.cpp:
433         (JSC::Wasm::CodeBlock::create):
434         (JSC::Wasm::CodeBlock::CodeBlock):
435         (JSC::Wasm::CodeBlock::compileAsync):
436         (JSC::Wasm::CodeBlock::setCompilationFinished):
437         * wasm/WasmCodeBlock.h:
438         (JSC::Wasm::CodeBlock::offsetOfImportStubs):
439         (JSC::Wasm::CodeBlock::allocationSize):
440         (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
441         (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
442         (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
443         (JSC::Wasm::CodeBlock::compilationFinished):
444         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
445         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
446         * wasm/WasmContext.cpp:
447         (JSC::Wasm::Context::useFastTLS):
448         (JSC::Wasm::Context::load const):
449         (JSC::Wasm::Context::store):
450         * wasm/WasmContext.h:
451         * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
452         * wasm/WasmFaultSignalHandler.cpp:
453         * wasm/WasmFaultSignalHandler.h:
454         * wasm/WasmFormat.h:
455         * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
456         (JSC::Wasm::Instance::Instance):
457         (JSC::Wasm::Instance::~Instance):
458         (JSC::Wasm::Instance::extraMemoryAllocated const):
459         * wasm/WasmInstance.h: Added.
460         (JSC::Wasm::Instance::create):
461         (JSC::Wasm::Instance::finalizeCreation):
462         (JSC::Wasm::Instance::module):
463         (JSC::Wasm::Instance::codeBlock):
464         (JSC::Wasm::Instance::memory):
465         (JSC::Wasm::Instance::table):
466         (JSC::Wasm::Instance::loadI32Global const):
467         (JSC::Wasm::Instance::loadI64Global const):
468         (JSC::Wasm::Instance::loadF32Global const):
469         (JSC::Wasm::Instance::loadF64Global const):
470         (JSC::Wasm::Instance::setGlobal):
471         (JSC::Wasm::Instance::offsetOfCachedStackLimit):
472         (JSC::Wasm::Instance::cachedStackLimit const):
473         (JSC::Wasm::Instance::setCachedStackLimit):
474         * wasm/WasmMemory.cpp:
475         (JSC::Wasm::Memory::Memory):
476         (JSC::Wasm::Memory::create):
477         (JSC::Wasm::Memory::~Memory):
478         (JSC::Wasm::Memory::grow):
479         * wasm/WasmMemory.h:
480         (JSC::Wasm::Memory::offsetOfMemory):
481         (JSC::Wasm::Memory::offsetOfSize):
482         * wasm/WasmMemoryInformation.cpp:
483         (JSC::Wasm::PinnedRegisterInfo::get):
484         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
485         * wasm/WasmMemoryInformation.h:
486         (JSC::Wasm::PinnedRegisterInfo::toSave const):
487         * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
488         (JSC::Wasm::makeString):
489         * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
490         * wasm/WasmModule.cpp:
491         (JSC::Wasm::makeValidationCallback):
492         (JSC::Wasm::Module::validateSync):
493         (JSC::Wasm::Module::validateAsync):
494         (JSC::Wasm::Module::getOrCreateCodeBlock):
495         (JSC::Wasm::Module::compileSync):
496         (JSC::Wasm::Module::compileAsync):
497         * wasm/WasmModule.h:
498         * wasm/WasmModuleParser.cpp:
499         (JSC::Wasm::ModuleParser::parseTableHelper):
500         * wasm/WasmOMGPlan.cpp:
501         (JSC::Wasm::OMGPlan::OMGPlan):
502         (JSC::Wasm::OMGPlan::runForIndex):
503         * wasm/WasmOMGPlan.h:
504         * wasm/WasmPageCount.h:
505         (JSC::Wasm::PageCount::isValid const):
506         * wasm/WasmPlan.cpp:
507         (JSC::Wasm::Plan::Plan):
508         (JSC::Wasm::Plan::runCompletionTasks):
509         (JSC::Wasm::Plan::addCompletionTask):
510         (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
511         * wasm/WasmPlan.h:
512         (JSC::Wasm::Plan::dontFinalize):
513         * wasm/WasmSignature.cpp:
514         * wasm/WasmSignature.h:
515         * wasm/WasmTable.cpp: Added.
516         (JSC::Wasm::Table::create):
517         (JSC::Wasm::Table::~Table):
518         (JSC::Wasm::Table::Table):
519         (JSC::Wasm::Table::grow):
520         (JSC::Wasm::Table::clearFunction):
521         (JSC::Wasm::Table::setFunction):
522         * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
523         (JSC::Wasm::Table::maximum const):
524         (JSC::Wasm::Table::size const):
525         (JSC::Wasm::Table::offsetOfSize):
526         (JSC::Wasm::Table::offsetOfFunctions):
527         (JSC::Wasm::Table::offsetOfInstances):
528         (JSC::Wasm::Table::isValidSize):
529         * wasm/WasmThunks.cpp:
530         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
531         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
532         (JSC::Wasm::Thunks::setThrowWasmException):
533         (JSC::Wasm::Thunks::throwWasmException):
534         * wasm/WasmThunks.h:
535         * wasm/WasmWorklist.cpp:
536         (JSC::Wasm::Worklist::stopAllPlansForContext):
537         * wasm/WasmWorklist.h:
538         * wasm/js/JSToWasm.cpp: Added.
539         (JSC::Wasm::createJSToWasmWrapper):
540         * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
541         * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
542         * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
543         * wasm/js/JSWebAssemblyCodeBlock.cpp:
544         (JSC::JSWebAssemblyCodeBlock::create):
545         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
546         * wasm/js/JSWebAssemblyCodeBlock.h:
547         * wasm/js/JSWebAssemblyInstance.cpp:
548         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
549         (JSC::JSWebAssemblyInstance::finishCreation):
550         (JSC::JSWebAssemblyInstance::visitChildren):
551         (JSC::JSWebAssemblyInstance::finalizeCreation):
552         (JSC::JSWebAssemblyInstance::create):
553         * wasm/js/JSWebAssemblyInstance.h:
554         (JSC::JSWebAssemblyInstance::instance):
555         (JSC::JSWebAssemblyInstance::context const):
556         (JSC::JSWebAssemblyInstance::table):
557         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
558         (JSC::JSWebAssemblyInstance::setMemory):
559         (JSC::JSWebAssemblyInstance::offsetOfTail):
560         (JSC::JSWebAssemblyInstance::importFunctionInfo):
561         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
562         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
563         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
564         (JSC::JSWebAssemblyInstance::importFunction):
565         (JSC::JSWebAssemblyInstance::internalMemory):
566         (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
567         (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
568         (JSC::JSWebAssemblyInstance::offsetOfCallee):
569         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
570         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
571         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
572         (JSC::JSWebAssemblyInstance::cachedStackLimit const):
573         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
574         (JSC::JSWebAssemblyInstance::wasmMemory):
575         (JSC::JSWebAssemblyInstance::wasmModule):
576         (JSC::JSWebAssemblyInstance::allocationSize):
577         (JSC::JSWebAssemblyInstance::module const):
578         * wasm/js/JSWebAssemblyMemory.cpp:
579         (JSC::JSWebAssemblyMemory::create):
580         (JSC::JSWebAssemblyMemory::adopt):
581         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
582         (JSC::JSWebAssemblyMemory::grow):
583         (JSC::JSWebAssemblyMemory::growSuccessCallback):
584         * wasm/js/JSWebAssemblyMemory.h:
585         * wasm/js/JSWebAssemblyModule.cpp:
586         (JSC::JSWebAssemblyModule::moduleInformation const):
587         (JSC::JSWebAssemblyModule::exportSymbolTable const):
588         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
589         (JSC::JSWebAssemblyModule::callee const):
590         (JSC::JSWebAssemblyModule::codeBlock):
591         (JSC::JSWebAssemblyModule::module):
592         * wasm/js/JSWebAssemblyModule.h:
593         * wasm/js/JSWebAssemblyTable.cpp:
594         (JSC::JSWebAssemblyTable::create):
595         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
596         (JSC::JSWebAssemblyTable::visitChildren):
597         (JSC::JSWebAssemblyTable::grow):
598         (JSC::JSWebAssemblyTable::getFunction):
599         (JSC::JSWebAssemblyTable::clearFunction):
600         (JSC::JSWebAssemblyTable::setFunction):
601         * wasm/js/JSWebAssemblyTable.h:
602         (JSC::JSWebAssemblyTable::isValidSize):
603         (JSC::JSWebAssemblyTable::maximum const):
604         (JSC::JSWebAssemblyTable::size const):
605         (JSC::JSWebAssemblyTable::table):
606         * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
607         (JSC::Wasm::materializeImportJSCell):
608         (JSC::Wasm::wasmToJS):
609         (JSC::Wasm::wasmToJSException):
610         * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
611         * wasm/js/WebAssemblyFunction.cpp:
612         (JSC::callWebAssemblyFunction):
613         * wasm/js/WebAssemblyInstanceConstructor.cpp:
614         (JSC::constructJSWebAssemblyInstance):
615         * wasm/js/WebAssemblyMemoryConstructor.cpp:
616         (JSC::constructJSWebAssemblyMemory):
617         * wasm/js/WebAssemblyMemoryPrototype.cpp:
618         (JSC::webAssemblyMemoryProtoFuncGrow):
619         * wasm/js/WebAssemblyModuleConstructor.cpp:
620         (JSC::constructJSWebAssemblyModule):
621         (JSC::WebAssemblyModuleConstructor::createModule):
622         * wasm/js/WebAssemblyModuleConstructor.h:
623         * wasm/js/WebAssemblyModuleRecord.cpp:
624         (JSC::WebAssemblyModuleRecord::link):
625         (JSC::WebAssemblyModuleRecord::evaluate):
626         * wasm/js/WebAssemblyPrototype.cpp:
627         (JSC::webAssemblyCompileFunc):
628         (JSC::instantiate):
629         (JSC::compileAndInstantiate):
630         (JSC::webAssemblyValidateFunc):
631         * wasm/js/WebAssemblyTableConstructor.cpp:
632         (JSC::constructJSWebAssemblyTable):
633         * wasm/js/WebAssemblyWrapperFunction.cpp:
634         (JSC::WebAssemblyWrapperFunction::create):
635
636 2017-10-19  Mark Lam  <mark.lam@apple.com>
637
638         Stringifier::appendStringifiedValue() is missing an exception check.
639         https://bugs.webkit.org/show_bug.cgi?id=178386
640         <rdar://problem/35027610>
641
642         Reviewed by Saam Barati.
643
644         * runtime/JSONObject.cpp:
645         (JSC::Stringifier::appendStringifiedValue):
646
647 2017-10-19  Saam Barati  <sbarati@apple.com>
648
649         REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
650         https://bugs.webkit.org/show_bug.cgi?id=178543
651
652         Reviewed by Filip Pizlo.
653
654         * dfg/DFGByteCodeParser.cpp:
655         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
656
657 2017-10-19  Saam Barati  <sbarati@apple.com>
658
659         re-inline ObjectAllocationProfile::initializeProfile
660         https://bugs.webkit.org/show_bug.cgi?id=178532
661
662         Rubber stamped by Michael Saboff.
663
664         I un-inlined this function when implementing poly proto.
665         This patch re-inlines it. In my testing, it looks like it
666         might be a 0.5% speedometer progression to inline it.
667
668         * JavaScriptCore.xcodeproj/project.pbxproj:
669         * Sources.txt:
670         * bytecode/CodeBlock.cpp:
671         * bytecode/ObjectAllocationProfile.cpp: Removed.
672         * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
673         (JSC::ObjectAllocationProfile::initializeProfile):
674         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
675         * runtime/FunctionRareData.cpp:
676
677 2017-10-19  Michael Saboff  <msaboff@apple.com>
678
679         Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
680         https://bugs.webkit.org/show_bug.cgi?id=178521
681
682         Reviewed by JF Bastien.
683
684         * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
685         standard version.  The prior version was the draft 6.0 version.
686
687 2017-10-19  Saam Barati  <sbarati@apple.com>
688
689         We should hard code the poly proto offset
690         https://bugs.webkit.org/show_bug.cgi?id=178531
691
692         Reviewed by Filip Pizlo.
693
694         This patch embraces that the poly proto offset is always zero. It's already
695         the case that we would always get the inline offset zero for poly proto just
696         by construction. This just hardcodes this assumption throughout the codebase.
697         This appears to be a 1% speedometer progression in my testing.
698         
699         The downside of this patch is that it may require changing how we do
700         things when we implement poly proto when inheriting from builtin
701         types. I think we can face this problem when we decide to implement
702         that.
703
704         * bytecode/AccessCase.cpp:
705         (JSC::AccessCase::generateWithGuard):
706         * dfg/DFGOperations.cpp:
707         * dfg/DFGSpeculativeJIT.cpp:
708         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
709         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
710         * ftl/FTLLowerDFGToB3.cpp:
711         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
712         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
713         * jit/JITOpcodes.cpp:
714         (JSC::JIT::emit_op_instanceof):
715         * jit/JITOpcodes32_64.cpp:
716         (JSC::JIT::emit_op_instanceof):
717         * runtime/CommonSlowPaths.cpp:
718         (JSC::SLOW_PATH_DECL):
719         * runtime/JSObject.cpp:
720         (JSC::JSObject::setPrototypeDirect):
721         * runtime/JSObject.h:
722         (JSC::JSObject::locationForOffset const):
723         (JSC::JSObject::locationForOffset):
724         (JSC::JSObject::getDirect const):
725         * runtime/PropertyOffset.h:
726         * runtime/Structure.cpp:
727         (JSC::Structure::create):
728         (JSC::Structure::dump const):
729         * runtime/Structure.h:
730         * runtime/StructureInlines.h:
731         (JSC::Structure::storedPrototype const):
732         (JSC::Structure::storedPrototypeObject const):
733
734 2017-10-19  Saam Barati  <sbarati@apple.com>
735
736         Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
737         https://bugs.webkit.org/show_bug.cgi?id=178529
738
739         Reviewed by Mark Lam.
740
741         * runtime/Structure.h:
742         * runtime/StructureInlines.h:
743         (JSC::Structure::storedPrototypeObject const):
744         (JSC::Structure::storedPrototypeStructure const):
745         (JSC::Structure::storedPrototype const):
746         (JSC::Structure::prototypeForLookup const):
747         (JSC::Structure::prototypeChain const):
748
749 2017-10-19  Saam Barati  <sbarati@apple.com>
750
751         Turn poly proto back on by default and remove the option
752         https://bugs.webkit.org/show_bug.cgi?id=178525
753
754         Reviewed by Mark Lam.
755
756         I added this option because I thought it'd speed speedometer up because the
757         original poly proto patch slowed speedometer down. It turns out that
758         allocating poly proto objects is not what slows speedometer down. It's
759         other code I added in the runtime that needs to be poly proto aware. I'll
760         be addressing these in follow up patches.
761
762         * runtime/Options.h:
763         * runtime/StructureInlines.h:
764         (JSC::Structure::shouldConvertToPolyProto):
765
766 2017-10-19  Robin Morisset  <rmorisset@apple.com>
767
768         Turn recursive tail calls into loops
769         https://bugs.webkit.org/show_bug.cgi?id=176601
770
771         Reviewed by Saam Barati.
772
773         We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
774         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.
775         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.
776         We do this part through modifying the computation of the jump targets.
777         Importantly, we only do this splitting for functions that have tail calls.
778         It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
779
780         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.
781         The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
782
783         * bytecode/CodeBlock.h:
784         (JSC::CodeBlock::hasTailCalls const):
785         * bytecode/PreciseJumpTargets.cpp:
786         (JSC::getJumpTargetsForBytecodeOffset):
787         (JSC::computePreciseJumpTargetsInternal):
788         * bytecode/UnlinkedCodeBlock.cpp:
789         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
790         * bytecode/UnlinkedCodeBlock.h:
791         (JSC::UnlinkedCodeBlock::hasTailCalls const):
792         (JSC::UnlinkedCodeBlock::setHasTailCalls):
793         * bytecompiler/BytecodeGenerator.cpp:
794         (JSC::BytecodeGenerator::emitEnter):
795         (JSC::BytecodeGenerator::emitCallInTailPosition):
796         * dfg/DFGByteCodeParser.cpp:
797         (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
798         (JSC::DFG::ByteCodeParser::makeBlockTargetable):
799         (JSC::DFG::ByteCodeParser::handleCall):
800         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
801         (JSC::DFG::ByteCodeParser::parseBlock):
802         (JSC::DFG::ByteCodeParser::parse):
803
804 2017-10-18  Mark Lam  <mark.lam@apple.com>
805
806         RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
807         https://bugs.webkit.org/show_bug.cgi?id=177600
808         <rdar://problem/34710985>
809
810         Reviewed by Saam Barati.
811
812         According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
813         section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
814         descriptor value is present.
815
816         * runtime/RegExpObject.cpp:
817         (JSC::RegExpObject::defineOwnProperty):
818
819 2017-10-18  Keith Miller  <keith_miller@apple.com>
820
821         Setup WebCore build to start using unified sources.
822         https://bugs.webkit.org/show_bug.cgi?id=178362
823
824         Reviewed by Tim Horton.
825
826         Change comments in source list files. Also, pass explicit names for build files.
827
828         * CMakeLists.txt:
829         * PlatformGTK.cmake:
830         * PlatformMac.cmake:
831         * Sources.txt:
832         * SourcesGTK.txt:
833         * SourcesMac.txt:
834
835 2017-10-18  Commit Queue  <commit-queue@webkit.org>
836
837         Unreviewed, rolling out r223321.
838         https://bugs.webkit.org/show_bug.cgi?id=178476
839
840         This protocol change broke some internal builds (Requested by
841         brrian__ on #webkit).
842
843         Reverted changeset:
844
845         "Web Inspector: provide a way to enable/disable event
846         listeners"
847         https://bugs.webkit.org/show_bug.cgi?id=177451
848         https://trac.webkit.org/changeset/223321
849
850 2017-10-18  Mark Lam  <mark.lam@apple.com>
851
852         The compiler should always register a structure when it adds its transitionWatchPointSet.
853         https://bugs.webkit.org/show_bug.cgi?id=178420
854         <rdar://problem/34814024>
855
856         Reviewed by Saam Barati and Filip Pizlo.
857
858         Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
859         now invoke Graph::registerAndWatchStructureTransition() on the structure.
860         registerAndWatchStructureTransition() both registers the structure and add its
861         transitionWatchpointSet to the plan desired watchpoints.
862
863         Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
864         except registerAndWatchStructureTransition() adds the structure's
865         transitionWatchpointSet unconditionally.
866
867         * dfg/DFGArgumentsEliminationPhase.cpp:
868         * dfg/DFGArrayMode.cpp:
869         (JSC::DFG::ArrayMode::refine const):
870         * dfg/DFGByteCodeParser.cpp:
871         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
872         * dfg/DFGFixupPhase.cpp:
873         (JSC::DFG::FixupPhase::fixupNode):
874
875         * dfg/DFGGraph.cpp:
876         (JSC::DFG::Graph::registerAndWatchStructureTransition):
877         * dfg/DFGGraph.h:
878
879         * dfg/DFGSpeculativeJIT.cpp:
880         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
881         - The second set of addLazily()s is redundant.  This set is executed only when
882           prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
883           only if we've executed the if statement above it.  That preceding if statement
884           already registerAndWatchStructureTransition() the same 2 structures.  Hence,
885           this second set can be deleted.
886
887         * dfg/DFGWatchpointCollectionPhase.cpp:
888         (JSC::DFG::WatchpointCollectionPhase::addLazily):
889         - Deleted an unused function.
890
891         * ftl/FTLLowerDFGToB3.cpp:
892         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
893
894 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
895
896         [JSC] Remove unused private name structure
897         https://bugs.webkit.org/show_bug.cgi?id=178436
898
899         Reviewed by Sam Weinig.
900
901         It is no longer used. This patch just removes it.
902
903         * runtime/JSGlobalObject.h:
904         (JSC::JSGlobalObject::numberObjectStructure const):
905         (JSC::JSGlobalObject::privateNameStructure const): Deleted.
906
907 2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>
908
909         Fix macOS and iOS builds after r223594.
910
911         * JavaScriptCore.xcodeproj/project.pbxproj:
912
913 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
914
915         [JSC] __proto__ getter should be fast
916         https://bugs.webkit.org/show_bug.cgi?id=178067
917
918         Reviewed by Saam Barati.
919
920         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
921         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
922         Call node for this. It is inefficient since typically we know the `prototype` of the given
923         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
924         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
925         we can still change this to efficient access to poly proto slot.
926
927         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
928         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
929         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
930         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
931         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
932         for ARES-6 ML.
933
934         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
935
936         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
937         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
938         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
939
940         This patch improves SixSpeed super.es6 by 3.42x.
941
942                                  baseline                  patched
943
944         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
945
946         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
947
948         * dfg/DFGAbstractInterpreterInlines.h:
949         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
950         * dfg/DFGByteCodeParser.cpp:
951         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
952         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
953         (JSC::DFG::ByteCodeParser::handleGetById):
954         * dfg/DFGClobberize.h:
955         (JSC::DFG::clobberize):
956         * dfg/DFGDoesGC.cpp:
957         (JSC::DFG::doesGC):
958         * dfg/DFGFixupPhase.cpp:
959         (JSC::DFG::FixupPhase::fixupNode):
960         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
961         * dfg/DFGHeapLocation.cpp:
962         (WTF::printInternal):
963         * dfg/DFGHeapLocation.h:
964         * dfg/DFGNode.h:
965         (JSC::DFG::Node::hasHeapPrediction):
966         (JSC::DFG::Node::shouldSpeculateFunction):
967         * dfg/DFGNodeType.h:
968         * dfg/DFGOperations.cpp:
969         * dfg/DFGOperations.h:
970         * dfg/DFGPredictionPropagationPhase.cpp:
971         * dfg/DFGSafeToExecute.h:
972         (JSC::DFG::safeToExecute):
973         * dfg/DFGSpeculativeJIT.cpp:
974         (JSC::DFG::SpeculativeJIT::speculateFunction):
975         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
976         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
977         * dfg/DFGSpeculativeJIT.h:
978         (JSC::DFG::SpeculativeJIT::callOperation):
979         * dfg/DFGSpeculativeJIT32_64.cpp:
980         (JSC::DFG::SpeculativeJIT::compile):
981         * dfg/DFGSpeculativeJIT64.cpp:
982         (JSC::DFG::SpeculativeJIT::compile):
983         * ftl/FTLCapabilities.cpp:
984         (JSC::FTL::canCompile):
985         * ftl/FTLLowerDFGToB3.cpp:
986         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
987         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
988         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
989         * jit/IntrinsicEmitter.cpp:
990         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
991         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
992         * jit/JITOperations.h:
993         * runtime/Intrinsic.cpp:
994         (JSC::intrinsicName):
995         * runtime/Intrinsic.h:
996         * runtime/JSGlobalObject.cpp:
997         (JSC::JSGlobalObject::init):
998         * runtime/JSGlobalObject.h:
999         (JSC::JSGlobalObject::booleanPrototype const):
1000         (JSC::JSGlobalObject::numberPrototype const):
1001         (JSC::JSGlobalObject::booleanObjectStructure const):
1002         * runtime/JSGlobalObjectFunctions.cpp:
1003         (JSC::globalFuncProtoGetter):
1004         * runtime/JSGlobalObjectFunctions.h:
1005         * runtime/ObjectConstructor.cpp:
1006         * runtime/ReflectObject.cpp:
1007
1008 2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>
1009
1010         Unreviewed, rolling out r223523.
1011
1012         A test for this change is failing on debug JSC bots.
1013
1014         Reverted changeset:
1015
1016         "[JSC] __proto__ getter should be fast"
1017         https://bugs.webkit.org/show_bug.cgi?id=178067
1018         https://trac.webkit.org/changeset/223523
1019
1020 2017-10-17  Youenn Fablet  <youenn@apple.com>
1021
1022         Add preliminary support for fetch event
1023         https://bugs.webkit.org/show_bug.cgi?id=178171
1024
1025         Reviewed by Chris Dumez.
1026
1027         Adding events
1028
1029         * runtime/JSPromise.h:
1030
1031 2017-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
1032
1033         [JSC] __proto__ getter should be fast
1034         https://bugs.webkit.org/show_bug.cgi?id=178067
1035
1036         Reviewed by Saam Barati.
1037
1038         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1039         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1040         Call node for this. It is inefficient since typically we know the `prototype` of the given
1041         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1042         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1043         we can still change this to efficient access to poly proto slot.
1044
1045         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1046         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1047         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1048         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1049         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1050         for ARES-6 ML.
1051
1052         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1053
1054         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1055         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1056         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1057
1058         This patch improves SixSpeed super.es6 by 3.42x.
1059
1060                                  baseline                  patched
1061
1062         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
1063
1064         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1065
1066         * dfg/DFGAbstractInterpreterInlines.h:
1067         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1068         * dfg/DFGByteCodeParser.cpp:
1069         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1070         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1071         (JSC::DFG::ByteCodeParser::handleGetById):
1072         * dfg/DFGClobberize.h:
1073         (JSC::DFG::clobberize):
1074         * dfg/DFGDoesGC.cpp:
1075         (JSC::DFG::doesGC):
1076         * dfg/DFGFixupPhase.cpp:
1077         (JSC::DFG::FixupPhase::fixupNode):
1078         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1079         * dfg/DFGHeapLocation.cpp:
1080         (WTF::printInternal):
1081         * dfg/DFGHeapLocation.h:
1082         * dfg/DFGNode.h:
1083         (JSC::DFG::Node::hasHeapPrediction):
1084         (JSC::DFG::Node::shouldSpeculateFunction):
1085         * dfg/DFGNodeType.h:
1086         * dfg/DFGOperations.cpp:
1087         * dfg/DFGOperations.h:
1088         * dfg/DFGPredictionPropagationPhase.cpp:
1089         * dfg/DFGSafeToExecute.h:
1090         (JSC::DFG::safeToExecute):
1091         * dfg/DFGSpeculativeJIT.cpp:
1092         (JSC::DFG::SpeculativeJIT::speculateFunction):
1093         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1094         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1095         * dfg/DFGSpeculativeJIT.h:
1096         * dfg/DFGSpeculativeJIT32_64.cpp:
1097         (JSC::DFG::SpeculativeJIT::compile):
1098         * dfg/DFGSpeculativeJIT64.cpp:
1099         (JSC::DFG::SpeculativeJIT::compile):
1100         * ftl/FTLCapabilities.cpp:
1101         (JSC::FTL::canCompile):
1102         * ftl/FTLLowerDFGToB3.cpp:
1103         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1104         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1105         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1106         * jit/IntrinsicEmitter.cpp:
1107         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1108         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1109         * runtime/Intrinsic.cpp:
1110         (JSC::intrinsicName):
1111         * runtime/Intrinsic.h:
1112         * runtime/JSGlobalObject.cpp:
1113         (JSC::JSGlobalObject::init):
1114         * runtime/JSGlobalObjectFunctions.cpp:
1115         (JSC::globalFuncProtoGetter):
1116         * runtime/JSGlobalObjectFunctions.h:
1117         * runtime/ObjectConstructor.cpp:
1118         * runtime/ReflectObject.cpp:
1119
1120 2017-10-17  Keith Miller  <keith_miller@apple.com>
1121
1122         Change WebCore sources to work with unified source builds
1123         https://bugs.webkit.org/show_bug.cgi?id=178229
1124
1125         Rubber stamped by Tim Horton.
1126
1127         * Configurations/FeatureDefines.xcconfig:
1128
1129 2017-10-15  Filip Pizlo  <fpizlo@apple.com>
1130
1131         Make some asserts into release asserts
1132         https://bugs.webkit.org/show_bug.cgi?id=178324
1133
1134         Reviewed by Saam Barati.
1135         
1136         These asserts are not on perf critical paths, so they might as well be release asserts.
1137
1138         * runtime/DataView.h:
1139         (JSC::DataView::get):
1140         (JSC::DataView::set):
1141
1142 2017-10-16  JF Bastien  <jfbastien@apple.com>
1143
1144         JSRunLoopTimer: reduce likely race when used improperly
1145         https://bugs.webkit.org/show_bug.cgi?id=178298
1146         <rdar://problem/32899816>
1147
1148         Reviewed by Saam Barati.
1149
1150         If an API user sets a timer on JSRunLoopTimer, and then racily
1151         destroys the JSRunLoopTimer while the timer is firing then it's
1152         possible for timerDidFire to cause a use-after-free and / or crash
1153         because e.g. m_apiLock becomes a nullptr while timerDidFire is
1154         executing. That results from an invalid use of JSRunLoopTimer, but
1155         we should try to be more resilient for that type of misuse because
1156         it's not necessarily easy to catch by inspection.
1157
1158         With this change the only remaining race is if the timer fires,
1159         and then only timerDidFire's prologue executes, but not the load
1160         of the m_apiLock pointer from `this`. It's a much smaller race.
1161
1162         Separately, I'll reach out to API users who are seemingly misusing
1163         the API.
1164
1165         * runtime/JSRunLoopTimer.cpp:
1166         (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
1167         and checks for nullptr. This prevents loading it twice off of
1168         `this` and turns a nullptr deref into "just" a use-after-free.
1169         (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
1170         calling m_vm->unregisterRunLoopTimer(this), which in turn does
1171         CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
1172         timerDidFire from doing much while the timers are un-registered.
1173         ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
1174         releasing the lock, so it needs its own local copy.
1175
1176 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1177
1178         [JSC] Perform module specifier validation at parsing time
1179         https://bugs.webkit.org/show_bug.cgi?id=178256
1180
1181         Reviewed by Darin Adler.
1182
1183         This patch make module loader's `resolve` operation synchronous. And we validate
1184         module's requested module names when instantiating the module instead of satisfying
1185         module's dependencies. This change is not observable to users. But this is precise
1186         to the spec and this optimizes & simplifies the current module loader a bit by
1187         reducing object allocations.
1188
1189         Previously, we have an object called pair in the module loader. This is pair of
1190         module's name and module's record. And we use it to link one module to dependent
1191         modules. Now, it is replaced with module's registry entry.
1192
1193         We also change our loader functions to take a registry entry instead of a module key.
1194         Previous design is due to the consideration that these APIs may be exposed to users
1195         in whatwg/loader spec. However, this won't happen. This change removes unnecessary
1196         repeatedly hash map lookups.
1197
1198         * builtins/ModuleLoaderPrototype.js:
1199         (globalPrivate.newRegistryEntry):
1200         (requestFetch):
1201         (requestInstantiate):
1202         (requestSatisfy):
1203         (link):
1204         (moduleEvaluation):
1205         (loadModule):
1206         * jsc.cpp:
1207         (GlobalObject::moduleLoaderResolve):
1208         * runtime/AbstractModuleRecord.cpp:
1209         (JSC::AbstractModuleRecord::finishCreation):
1210         (JSC::AbstractModuleRecord::hostResolveImportedModule):
1211         * runtime/JSGlobalObject.h:
1212         * runtime/JSModuleLoader.cpp:
1213         (JSC::JSModuleLoader::resolveSync):
1214         (JSC::JSModuleLoader::resolve):
1215         * runtime/JSModuleLoader.h:
1216         * runtime/ModuleLoaderPrototype.cpp:
1217         (JSC::moduleLoaderPrototypeResolveSync):
1218
1219 2017-10-14  Devin Rousso  <webkit@devinrousso.com>
1220
1221         Web Inspector: provide a way to enable/disable event listeners
1222         https://bugs.webkit.org/show_bug.cgi?id=177451
1223
1224         Reviewed by Joseph Pecoraro.
1225
1226         * inspector/protocol/DOM.json:
1227         Add `setEventListenerDisabled` command that enables/disables a specific event listener
1228         during event dispatch. When a disabled event listener is fired, the listener's callback will
1229         not be called.
1230
1231 2017-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1232
1233         Reland "Add Above/Below comparisons for UInt32 patterns"
1234         https://bugs.webkit.org/show_bug.cgi?id=177281
1235
1236         Reviewed by Saam Barati.
1237
1238         We reland this patch without DFGStrengthReduction change to see what causes
1239         regression in the iOS bot.
1240
1241         Sometimes, we would like to have UInt32 operations in JS. While VM does
1242         not support UInt32 nicely, VM supports efficient Int32 operations. As long
1243         as signedness does not matter, we can just perform Int32 operations instead
1244         and recognize its bit pattern as UInt32.
1245
1246         But of course, some operations respect signedness. The most frequently
1247         used one is comparison. Octane/zlib performs UInt32 comparison by performing
1248         `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
1249         UInt32 in Int32 form. And op_unsigned will generate Double value if
1250         the generated Int32 is < 0 (which should be UInt32).
1251
1252         There is a chance for optimization. The given code pattern is the following.
1253
1254             op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
1255
1256         This can be converted to the following.
1257
1258             op_urshift(@1) below:< op_urshift(@2)
1259
1260         The above conversion is nice since
1261
1262         1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
1263         this check depends on the value of Int32, dropping this check is not as easy as
1264         removing Int32 edge filters.
1265
1266         2. We can perform unsigned comparison in Int32 form. We do not need to convert
1267         them to DoubleRep.
1268
1269         Since the above comparison exists in Octane/zlib's *super* hot path, dropping
1270         op_unsigned offers huge win.
1271
1272         At first, my patch attempts to convert the above thing in DFG pipeline.
1273         However it poses several problems.
1274
1275         1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
1276         2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
1277
1278             2: UInt32ToNumber(@0)
1279             3: MovHint(@2, xxx)
1280             4: UInt32ToNumber(@1)
1281             5: MovHint(@1, xxx)
1282
1283         we could drop @5's MovHint. But @3 is difficult since @4 can exit.
1284
1285         So, instead, we start introducing a simple optimization in the bytecode compiler.
1286         It performs pattern matching for op_urshift and comparison to drop op_unsigned.
1287         We adds op_below and op_above families to bytecodes. They only accept Int32 and
1288         perform unsigned comparison.
1289
1290         This offers 4% performance improvement in Octane/zlib.
1291
1292                                     baseline                  patched
1293
1294         zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster
1295
1296         * bytecode/BytecodeDumper.cpp:
1297         (JSC::BytecodeDumper<Block>::printCompareJump):
1298         (JSC::BytecodeDumper<Block>::dumpBytecode):
1299         * bytecode/BytecodeDumper.h:
1300         * bytecode/BytecodeList.json:
1301         * bytecode/BytecodeUseDef.h:
1302         (JSC::computeUsesForBytecodeOffset):
1303         (JSC::computeDefsForBytecodeOffset):
1304         * bytecode/Opcode.h:
1305         (JSC::isBranch):
1306         * bytecode/PreciseJumpTargetsInlines.h:
1307         (JSC::extractStoredJumpTargetsForBytecodeOffset):
1308         * bytecompiler/BytecodeGenerator.cpp:
1309         (JSC::BytecodeGenerator::emitJumpIfTrue):
1310         (JSC::BytecodeGenerator::emitJumpIfFalse):
1311         * bytecompiler/NodesCodegen.cpp:
1312         (JSC::BinaryOpNode::emitBytecode):
1313         * dfg/DFGAbstractInterpreterInlines.h:
1314         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1315         * dfg/DFGByteCodeParser.cpp:
1316         (JSC::DFG::ByteCodeParser::parseBlock):
1317         * dfg/DFGCapabilities.cpp:
1318         (JSC::DFG::capabilityLevel):
1319         * dfg/DFGClobberize.h:
1320         (JSC::DFG::clobberize):
1321         * dfg/DFGDoesGC.cpp:
1322         (JSC::DFG::doesGC):
1323         * dfg/DFGFixupPhase.cpp:
1324         (JSC::DFG::FixupPhase::fixupNode):
1325         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1326         * dfg/DFGNodeType.h:
1327         * dfg/DFGPredictionPropagationPhase.cpp:
1328         * dfg/DFGSafeToExecute.h:
1329         (JSC::DFG::safeToExecute):
1330         * dfg/DFGSpeculativeJIT.cpp:
1331         (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
1332         * dfg/DFGSpeculativeJIT.h:
1333         * dfg/DFGSpeculativeJIT32_64.cpp:
1334         (JSC::DFG::SpeculativeJIT::compile):
1335         * dfg/DFGSpeculativeJIT64.cpp:
1336         (JSC::DFG::SpeculativeJIT::compile):
1337         * dfg/DFGValidate.cpp:
1338         * ftl/FTLCapabilities.cpp:
1339         (JSC::FTL::canCompile):
1340         * ftl/FTLLowerDFGToB3.cpp:
1341         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1342         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
1343         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
1344         * jit/JIT.cpp:
1345         (JSC::JIT::privateCompileMainPass):
1346         * jit/JIT.h:
1347         * jit/JITArithmetic.cpp:
1348         (JSC::JIT::emit_op_below):
1349         (JSC::JIT::emit_op_beloweq):
1350         (JSC::JIT::emit_op_jbelow):
1351         (JSC::JIT::emit_op_jbeloweq):
1352         (JSC::JIT::emit_compareUnsignedAndJump):
1353         (JSC::JIT::emit_compareUnsigned):
1354         * jit/JITArithmetic32_64.cpp:
1355         (JSC::JIT::emit_compareUnsignedAndJump):
1356         (JSC::JIT::emit_compareUnsigned):
1357         * llint/LowLevelInterpreter.asm:
1358         * llint/LowLevelInterpreter32_64.asm:
1359         * llint/LowLevelInterpreter64.asm:
1360         * parser/Nodes.h:
1361         (JSC::ExpressionNode::isBinaryOpNode const):
1362
1363 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1364
1365         WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
1366         https://bugs.webkit.org/show_bug.cgi?id=178210
1367
1368         Reviewed by Saam Barati.
1369
1370         In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
1371         The former is an exported wasm function and the latter is an imported & exported function. Since they
1372         have [[Call]], they should be categorized into "function" in typeof operation.
1373
1374         However, these functions do not implement our function protocol correctly. They inherit JSFunction.
1375         But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
1376         ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
1377         typeof operation.
1378
1379         In this patch, we address the above issue by the following 2 fixes.
1380
1381         1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
1382         InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
1383         implementation, we cannot make this JSFunctionType.
1384
1385         2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
1386         changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
1387         classes of JSFunction (e.g. JSCustomGetterSetterFunction).
1388
1389         * wasm/js/WebAssemblyFunction.h:
1390         (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
1391         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
1392         (JSC::WebAssemblyFunction::callableFunction const): Deleted.
1393         (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
1394         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
1395         * wasm/js/WebAssemblyWrapperFunction.cpp:
1396         (JSC::WebAssemblyWrapperFunction::createStructure):
1397         * wasm/js/WebAssemblyWrapperFunction.h:
1398         (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
1399         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
1400         (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
1401         (JSC::WebAssemblyWrapperFunction::function): Deleted.
1402
1403 2017-10-12  Per Arne Vollan  <pvollan@apple.com>
1404
1405         [Win64] JSC compile error.
1406         https://bugs.webkit.org/show_bug.cgi?id=178213
1407
1408         Reviewed by Alex Christensen.
1409
1410         Add static cast from int64 to uintptr_t.
1411
1412         * dfg/DFGOSRExit.cpp:
1413         (JSC::DFG::OSRExit::executeOSRExit):
1414
1415 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1416
1417         Enable gigacage on iOS
1418         https://bugs.webkit.org/show_bug.cgi?id=177586
1419
1420         Reviewed by JF Bastien.
1421
1422         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
1423         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
1424         have Gigacage. So, this teaches ARM64 how to load from global variables.
1425         
1426         Also, this makes the code handle disabling the gigacage a bit better.
1427
1428         * ftl/FTLLowerDFGToB3.cpp:
1429         (JSC::FTL::DFG::LowerDFGToB3::caged):
1430         * jit/AssemblyHelpers.h:
1431         (JSC::AssemblyHelpers::cage):
1432         (JSC::AssemblyHelpers::cageConditionally):
1433         * offlineasm/arm64.rb:
1434         * offlineasm/asm.rb:
1435         * offlineasm/instructions.rb:
1436
1437 2017-10-11  Sam Weinig  <sam@webkit.org>
1438
1439         Remove out-parameter variants of copyToVector
1440         https://bugs.webkit.org/show_bug.cgi?id=178155
1441
1442         Reviewed by Tim Horton.
1443
1444         * inspector/ScriptDebugServer.cpp:
1445         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
1446         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
1447         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
1448         (Inspector::ScriptDebugServer::dispatchDidParseSource):
1449         (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
1450         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
1451             
1452             Replace out-parameter based copyToVector, with one that returns a Vector.
1453
1454 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1455
1456         Support integrity="" on module scripts
1457         https://bugs.webkit.org/show_bug.cgi?id=177959
1458
1459         Reviewed by Sam Weinig.
1460
1461         This patch adds Subresource Integrity check for module scripts. Currently,
1462         only top-level module can be verified with integrity parameter since there
1463         is no way to perform integrity check onto the imported modules.
1464
1465         In JSC side, we add `parameters` to the entry point of the module loader
1466         pipeline. This is fetching parameters and used when fetching modules.
1467
1468         We separately pass this parameters to the pipeline along with the script fetcher.
1469         The script fetcher is only one for module graph since this is the initiator of
1470         this module graph loading. On the other hand, this parameters is for each
1471         module fetching. While setting "integrity" parameters to this script fetcher is
1472         sufficient to pass parameters to top-level-module's fetching, it is not enough
1473         for the future extension.
1474
1475         In the future, we will investigate a way to pass parameters to each non-top-level
1476         module. At that time, this `parameters` should be per-module. This is because
1477         "integrity" value should be different for each module. For example, we will accept
1478         some form of syntax to add parameters to `import`. Some proposed syntax is like
1479         https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
1480
1481         import "./xxx.js" integrity "xxxxxxx"
1482
1483         In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
1484         `parameters` should be different from the one of top-level-module's one. That's why
1485         we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
1486
1487         On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
1488         is important to offer module-graph-wide information. For example, import.meta would
1489         have `import.meta.scriptElement`, which is the script element fetching the module graph
1490         including this. So, we keep the both, script fetcher and parameters.
1491         https://github.com/tc39/proposal-import-meta
1492
1493         This parameters will be finally used by pipeline's fetch hook, and WebCore side
1494         can use this parameters to fetch modules.
1495
1496         We also further clean up the module pipeline by dropping unnecessary features.
1497
1498         * JavaScriptCore.xcodeproj/project.pbxproj:
1499         * Sources.txt:
1500         * builtins/ModuleLoaderPrototype.js:
1501         (requestFetch):
1502         (requestInstantiate):
1503         (requestSatisfy):
1504         (loadModule):
1505         (loadAndEvaluateModule):
1506         This loadAndEvaluateModule should be implemented by just calling loadModule and
1507         linkAndEvaluateModule. We can drop requestReady and requestLink.
1508
1509         (requestLink): Deleted.
1510         (requestImportModule): Deleted.
1511         * jsc.cpp:
1512         (GlobalObject::moduleLoaderImportModule):
1513         (GlobalObject::moduleLoaderFetch):
1514         import and fetch hook takes parameters. Currently, we always pass `undefined` for
1515         import hook. When dynamic `import()` is extended to accept additional parameters
1516         like integrity, this parameters will be replaced with the actual value.
1517
1518         (functionLoadModule):
1519         (runWithOptions):
1520         * runtime/Completion.cpp:
1521         (JSC::loadAndEvaluateModule):
1522         (JSC::loadModule):
1523         (JSC::importModule):
1524         * runtime/Completion.h:
1525         * runtime/JSGlobalObject.h:
1526         * runtime/JSGlobalObjectFunctions.cpp:
1527         (JSC::globalFuncImportModule):
1528         * runtime/JSModuleLoader.cpp:
1529         (JSC::JSModuleLoader::loadAndEvaluateModule):
1530         (JSC::JSModuleLoader::loadModule):
1531         (JSC::JSModuleLoader::requestImportModule):
1532         (JSC::JSModuleLoader::importModule):
1533         (JSC::JSModuleLoader::fetch):
1534         * runtime/JSModuleLoader.h:
1535         * runtime/JSScriptFetchParameters.cpp: Added.
1536         (JSC::JSScriptFetchParameters::destroy):
1537         * runtime/JSScriptFetchParameters.h: Added.
1538         (JSC::JSScriptFetchParameters::createStructure):
1539         (JSC::JSScriptFetchParameters::create):
1540         (JSC::JSScriptFetchParameters::parameters const):
1541         (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
1542         Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
1543         It is used in the module pipeline.
1544
1545         * runtime/JSType.h:
1546         * runtime/ModuleLoaderPrototype.cpp:
1547         (JSC::moduleLoaderPrototypeFetch):
1548         * runtime/ScriptFetchParameters.h: Added.
1549         (JSC::ScriptFetchParameters::~ScriptFetchParameters):
1550         Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
1551         by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
1552         this.
1553
1554         * runtime/VM.cpp:
1555         (JSC::VM::VM):
1556         * runtime/VM.h:
1557
1558 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1559
1560         import.meta should not be assignable
1561         https://bugs.webkit.org/show_bug.cgi?id=178202
1562
1563         Reviewed by Saam Barati.
1564
1565         `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
1566         and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
1567         We change the parser not to allow assignments for MetaPropertyNode.
1568
1569         * bytecompiler/NodesCodegen.cpp:
1570         (JSC::ImportMetaNode::emitBytecode):
1571         * parser/ASTBuilder.h:
1572         (JSC::ASTBuilder::createImportMetaExpr):
1573         (JSC::ASTBuilder::isMetaProperty):
1574         (JSC::ASTBuilder::isImportMeta):
1575         * parser/NodeConstructors.h:
1576         (JSC::MetaPropertyNode::MetaPropertyNode):
1577         (JSC::NewTargetNode::NewTargetNode):
1578         (JSC::ImportMetaNode::ImportMetaNode):
1579         * parser/Nodes.h:
1580         (JSC::ExpressionNode::isMetaProperty const):
1581         (JSC::ExpressionNode::isImportMeta const):
1582         * parser/Parser.cpp:
1583         (JSC::Parser<LexerType>::metaPropertyName):
1584         (JSC::Parser<LexerType>::parseAssignmentExpression):
1585         (JSC::Parser<LexerType>::parseMemberExpression):
1586         (JSC::Parser<LexerType>::parseUnaryExpression):
1587         * parser/Parser.h:
1588         * parser/SyntaxChecker.h:
1589         (JSC::SyntaxChecker::createImportMetaExpr):
1590         (JSC::SyntaxChecker::isMetaProperty):
1591         (JSC::SyntaxChecker::isImportMeta):
1592
1593 2017-10-11  Saam Barati  <sbarati@apple.com>
1594
1595         Runtime disable poly proto because it may be a 3-4% Speedometer regression
1596         https://bugs.webkit.org/show_bug.cgi?id=178192
1597
1598         Reviewed by JF Bastien.
1599
1600         * runtime/Options.h:
1601         * runtime/StructureInlines.h:
1602         (JSC::Structure::shouldConvertToPolyProto):
1603
1604 2017-10-11  Commit Queue  <commit-queue@webkit.org>
1605
1606         Unreviewed, rolling out r223113 and r223121.
1607         https://bugs.webkit.org/show_bug.cgi?id=178182
1608
1609         Reintroduced 20% regression on Kraken (Requested by rniwa on
1610         #webkit).
1611
1612         Reverted changesets:
1613
1614         "Enable gigacage on iOS"
1615         https://bugs.webkit.org/show_bug.cgi?id=177586
1616         https://trac.webkit.org/changeset/223113
1617
1618         "Use one virtual allocation for all gigacages and their
1619         runways"
1620         https://bugs.webkit.org/show_bug.cgi?id=178050
1621         https://trac.webkit.org/changeset/223121
1622
1623 2017-10-11  Michael Saboff  <msaboff@apple.com>
1624
1625         Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
1626         https://bugs.webkit.org/show_bug.cgi?id=178106
1627
1628         Reviewed by Keith Miller.
1629
1630         * ucd/CaseFolding.txt:
1631
1632 2017-10-11  Caio Lima  <ticaiolima@gmail.com>
1633
1634         Object properties are undefined in super.call() but not in this.call()
1635         https://bugs.webkit.org/show_bug.cgi?id=177230
1636
1637         Reviewed by Saam Barati.
1638
1639         Bytecode generation for "super.call(...)" or "super.apply(...)"
1640         shouldn't be considered as CallFunctionCallDotNode or
1641         ApplyFunctionCallDotNode because they should be considered as common
1642         super property access as any other function. According to spec[1],
1643         "super" is not refering to parent constructor.
1644
1645         [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
1646
1647         * parser/ASTBuilder.h:
1648         (JSC::ASTBuilder::makeFunctionCallNode):
1649         * parser/Parser.cpp:
1650         (JSC::Parser<LexerType>::parseMemberExpression):
1651         * parser/SyntaxChecker.h:
1652         (JSC::SyntaxChecker::makeFunctionCallNode):
1653
1654 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1655
1656         [JSC] Drop Instantiate hook in ES6 module loader
1657         https://bugs.webkit.org/show_bug.cgi?id=178162
1658
1659         Reviewed by Sam Weinig.
1660
1661         This patch is a part of patch series for module loader refactoring to adopt
1662         integrity="" parameters and introduce new whatwg module import mechanism.
1663
1664         In this patch, we drop instantiate hook in module loader. This hook is originally
1665         introduced because it is defined in whatwg/loader spec. But this hook is not
1666         used in our implementation, and this hook won't be used since (1) whatwg/loader
1667         spec is abandoned, and (2) this type of hooks should be done in Service Workers.
1668
1669         In addition, this patch applies some cleaning up of our module loader JS code
1670         to simplify things. This change paves the way to more efficient loader implementation
1671         with great flexibility to adopt integrity="" parameters.
1672
1673         * builtins/ModuleLoaderPrototype.js:
1674         (requestInstantiate):
1675         (provideFetch):
1676         provide is changed to provideFetch since we only used this function with Fetch stage parameter.
1677
1678         (fulfillInstantiate): Deleted.
1679         (commitInstantiated): Deleted.
1680         (instantiation): Deleted.
1681         They are merged into requestInstantiate code. This is simpler.
1682
1683         (provide): Deleted.
1684         * jsc.cpp:
1685         * runtime/Completion.cpp:
1686         (JSC::loadAndEvaluateModule):
1687         (JSC::loadModule):
1688         * runtime/JSGlobalObject.cpp:
1689         * runtime/JSGlobalObject.h:
1690         * runtime/JSModuleLoader.cpp:
1691         (JSC::JSModuleLoader::provideFetch):
1692         (JSC::JSModuleLoader::provide): Deleted.
1693         Changed to provideFetch.
1694
1695         (JSC::JSModuleLoader::instantiate): Deleted.
1696         Drop this hook.
1697
1698         * runtime/JSModuleLoader.h:
1699         * runtime/ModuleLoaderPrototype.cpp:
1700         (JSC::moduleLoaderPrototypeInstantiate): Deleted.
1701         Drop this hook.
1702
1703 2017-10-10  Saam Barati  <sbarati@apple.com>
1704
1705         Prototype structure transition should be a deferred transition
1706         https://bugs.webkit.org/show_bug.cgi?id=177734
1707
1708         Reviewed by Keith Miller.
1709
1710         Absence ObjectPropertyConditions work by verifying both that the Structure 
1711         does not have a particular property and that its prototype has
1712         remained constant. However, the prototype transition was firing
1713         the transition watchpoint before setting the object's structure.
1714         This meant that isValid for Absence would never return false because
1715         the prototype changed. Clearly this is wrong. The reason this didn't
1716         break OPCs in general is that we'd also check if we could still watch
1717         the OPC. In this case, we can't still watch it because we're inspecting
1718         a structure with an invalidated transition watchpoint. To fix
1719         this weird quirk of the code, I'm making it so that doing a prototype
1720         transition uses the DeferredStructureTransitionWatchpointFire machinery.
1721         
1722         This patch also fixes some dead code that I left in regarding
1723         poly proto in OPC.
1724
1725         * bytecode/PropertyCondition.cpp:
1726         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
1727         * runtime/JSObject.cpp:
1728         (JSC::JSObject::setPrototypeDirect):
1729         * runtime/Structure.cpp:
1730         (JSC::Structure::changePrototypeTransition):
1731         * runtime/Structure.h:
1732
1733 2017-10-10  Robin Morisset  <rmorisset@apple.com>
1734
1735         Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
1736         https://bugs.webkit.org/show_bug.cgi?id=177926
1737
1738         Reviewed by Saam Barati.
1739
1740         When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
1741         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.
1742         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.
1743
1744         * dfg/DFGByteCodeParser.cpp:
1745         (JSC::DFG::ByteCodeParser::inlineCall):
1746         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1747         (JSC::DFG::ByteCodeParser::handleInlining):
1748         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1749         (JSC::DFG::ByteCodeParser::parse):
1750
1751 2017-10-10  Guillaume Emont  <guijemont@igalia.com>
1752
1753         Fix compilation when MASM_PROBE (and therefore DFG) are disabled
1754         https://bugs.webkit.org/show_bug.cgi?id=178134
1755
1756         Reviewed by Saam Barati.
1757
1758         * bytecode/CodeBlock.cpp:
1759         * bytecode/CodeBlock.h:
1760         Disable some code when building without DFG_JIT.
1761
1762 2017-10-10  Sam Weinig  <sam@webkit.org>
1763
1764         Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
1765         https://bugs.webkit.org/show_bug.cgi?id=178102
1766
1767         Reviewed by Tim Horton.
1768
1769         * inspector/agents/InspectorDebuggerAgent.cpp:
1770         (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
1771
1772 2017-10-10  Michael Saboff  <msaboff@apple.com>
1773
1774         Unreviewed build fix.
1775
1776         Removed unused lambda capture.
1777
1778         * yarr/YarrPattern.cpp:
1779         (JSC::Yarr::CharacterClassConstructor::appendInverted):
1780
1781 2017-10-10  Saam Barati  <sbarati@apple.com>
1782
1783         The prototype cache should be aware of the Executable it generates a Structure for
1784         https://bugs.webkit.org/show_bug.cgi?id=177907
1785
1786         Reviewed by Filip Pizlo.
1787
1788         This patch renames PrototypeMap to StructureCache because
1789         it is no longer a map of the prototypes in the VM. It's
1790         only used to cache Structures during object construction.
1791         
1792         The main change of this patch is to guarantee that Structures generated
1793         by the create_this originating from different two different Executables'
1794         bytecode won't hash-cons to the same thing. Previously, we could hash-cons
1795         them depending on the JSObject* prototype pointer. This would cause the last
1796         thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
1797         happened because when we initialize a JSFunction's ObjectAllocationProfile,
1798         we set the resulting Structure's poly proto watchpoint. This could cause a Structure
1799         generating from some Executable e1 to end up with the poly proto watchpoint
1800         for another Executable e2 simply because JSFunctions backed by e1 and e2
1801         shared the same prototype. Then, based on profiling information, we may fire the
1802         wrong Executable's poly proto watchpoint. This patch fixes this bug by
1803         guaranteeing that Structures generating from create_this for different
1804         Executables are unique even if they share the same prototype by adding
1805         the FunctionExecutable* as another field in PrototypeKey.
1806
1807         * JavaScriptCore.xcodeproj/project.pbxproj:
1808         * Sources.txt:
1809         * bytecode/InternalFunctionAllocationProfile.h:
1810         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
1811         * bytecode/ObjectAllocationProfile.cpp:
1812         (JSC::ObjectAllocationProfile::initializeProfile):
1813         * dfg/DFGOperations.cpp:
1814         * runtime/CommonSlowPaths.cpp:
1815         (JSC::SLOW_PATH_DECL):
1816         * runtime/InternalFunction.cpp:
1817         (JSC::InternalFunction::createSubclassStructureSlow):
1818         * runtime/IteratorOperations.cpp:
1819         (JSC::createIteratorResultObjectStructure):
1820         * runtime/JSBoundFunction.cpp:
1821         (JSC::getBoundFunctionStructure):
1822         * runtime/JSGlobalObject.cpp:
1823         (JSC::JSGlobalObject::init):
1824         * runtime/ObjectConstructor.h:
1825         (JSC::constructEmptyObject):
1826         * runtime/PrototypeKey.h:
1827         (JSC::PrototypeKey::PrototypeKey):
1828         (JSC::PrototypeKey::executable const):
1829         (JSC::PrototypeKey::operator== const):
1830         (JSC::PrototypeKey::hash const):
1831         * runtime/PrototypeMap.cpp: Removed.
1832         * runtime/PrototypeMap.h: Removed.
1833         * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
1834         (JSC::StructureCache::createEmptyStructure):
1835         (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
1836         (JSC::StructureCache::emptyObjectStructureForPrototype):
1837         (JSC::PrototypeMap::createEmptyStructure): Deleted.
1838         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
1839         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
1840         * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
1841         (JSC::StructureCache::StructureCache):
1842         (JSC::PrototypeMap::PrototypeMap): Deleted.
1843         * runtime/VM.cpp:
1844         (JSC::VM::VM):
1845         * runtime/VM.h:
1846
1847 2017-10-09  Yusuke Suzuki  <utatane.tea@gmail.com>
1848
1849         `async` should be able to be used as an imported binding name
1850         https://bugs.webkit.org/show_bug.cgi?id=176573
1851
1852         Reviewed by Saam Barati.
1853
1854         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
1855         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
1856         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
1857         For example, import declaration failed to bind imported binding to the name "async" because
1858         the parser considered ASYNC as keyword.
1859
1860         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
1861         the current performance without using this ASYNC keyword.
1862
1863         We also add `escaped` field to token data since contextual keyword is valid only if it does
1864         not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
1865         e.g. `of in for-of`. This improves test262 score.
1866
1867         * parser/Keywords.table:
1868         * parser/Lexer.cpp:
1869         (JSC::Lexer<LChar>::parseIdentifier):
1870         (JSC::Lexer<UChar>::parseIdentifier):
1871         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
1872         * parser/Parser.cpp:
1873         (JSC::Parser<LexerType>::parseStatementListItem):
1874         (JSC::Parser<LexerType>::parseForStatement):
1875         (JSC::Parser<LexerType>::parseStatement):
1876         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
1877         (JSC::Parser<LexerType>::parseClass):
1878         (JSC::Parser<LexerType>::parseExportDeclaration):
1879         (JSC::Parser<LexerType>::parseAssignmentExpression):
1880         (JSC::Parser<LexerType>::parseProperty):
1881         (JSC::Parser<LexerType>::parsePrimaryExpression):
1882         (JSC::Parser<LexerType>::parseMemberExpression):
1883         (JSC::Parser<LexerType>::printUnexpectedTokenText):
1884         * parser/Parser.h:
1885         (JSC::Parser::matchContextualKeyword):
1886         * parser/ParserTokens.h:
1887         * runtime/CommonIdentifiers.h:
1888
1889 2017-10-09  Saam Barati  <sbarati@apple.com>
1890
1891         We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
1892         https://bugs.webkit.org/show_bug.cgi?id=177987
1893
1894         Reviewed by Filip Pizlo.
1895
1896         * runtime/JSProxy.cpp:
1897         (JSC::JSProxy::setTarget):
1898         * runtime/PrototypeMap.cpp:
1899         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
1900         * runtime/PrototypeMap.h:
1901
1902 2017-10-09  Filip Pizlo  <fpizlo@apple.com>
1903
1904         JSCell::didBecomePrototype is racy
1905         https://bugs.webkit.org/show_bug.cgi?id=178110
1906
1907         Reviewed by Saam Barati.
1908         
1909         The indexing type can be modified by any thread using CAS. So, we need to use atomics when
1910         modifying it. We don't need to use atomics when reading it though (since it's just one field).
1911
1912         * runtime/JSCellInlines.h:
1913         (JSC::JSCell::didBecomePrototype):
1914
1915 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1916
1917         Enable gigacage on iOS
1918         https://bugs.webkit.org/show_bug.cgi?id=177586
1919
1920         Reviewed by JF Bastien.
1921
1922         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
1923         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
1924         have Gigacage. So, this teaches ARM64 how to load from global variables.
1925         
1926         Also, this makes the code handle disabling the gigacage a bit better.
1927
1928         * ftl/FTLLowerDFGToB3.cpp:
1929         (JSC::FTL::DFG::LowerDFGToB3::caged):
1930         * jit/AssemblyHelpers.h:
1931         (JSC::AssemblyHelpers::cage):
1932         (JSC::AssemblyHelpers::cageConditionally):
1933         * offlineasm/arm64.rb:
1934         * offlineasm/asm.rb:
1935         * offlineasm/instructions.rb:
1936
1937 2017-10-09  Robin Morisset  <rmorisset@apple.com>
1938
1939         Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
1940         https://bugs.webkit.org/show_bug.cgi?id=177925
1941
1942         Reviewed by Saam Barati.
1943
1944         We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
1945         the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
1946         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).
1947
1948         * dfg/DFGByteCodeParser.cpp:
1949         (JSC::DFG::ByteCodeParser::parseBlock):
1950         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1951
1952 2017-10-09  Robin Morisset  <rmorisset@apple.com>
1953
1954         Refactor the inliner to simplify block linking
1955         https://bugs.webkit.org/show_bug.cgi?id=177922
1956
1957         Reviewed by Saam Barati.
1958
1959         The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
1960         some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
1961         - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
1962         - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
1963         Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
1964         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,
1965         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
1966         terminal that needs to be taken off m_unlinkedBlocks.
1967         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,
1968         that is the one that holds their target in its m_linkingTargets field.
1969
1970         There are a few much smaller refactors in this patch:
1971         - parse() is now of type void insted of bool (it was always returning true)
1972         - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
1973         - The 9 argument version was cleaned up and simplified
1974         - 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
1975         - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
1976         - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)
1977
1978         * dfg/DFGByteCodeParser.cpp:
1979         (JSC::DFG::ByteCodeParser::addToGraph):
1980         (JSC::DFG::ByteCodeParser::handleCall):
1981         (JSC::DFG::ByteCodeParser::refineStatically):
1982         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
1983         (JSC::DFG::ByteCodeParser::handleVarargsCall):
1984         (JSC::DFG::ByteCodeParser::inlineCall):
1985         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1986         (JSC::DFG::ByteCodeParser::handleInlining):
1987         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1988         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1989         (JSC::DFG::ByteCodeParser::parseBlock):
1990         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1991         (JSC::DFG::ByteCodeParser::parse):
1992         (JSC::DFG::parse):
1993         (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
1994         * dfg/DFGByteCodeParser.h:
1995         * dfg/DFGPlan.cpp:
1996         (JSC::DFG::Plan::compileInThreadImpl):
1997
1998 2017-10-09  Michael Saboff  <msaboff@apple.com>
1999
2000         Implement RegExp Unicode property escapes
2001         https://bugs.webkit.org/show_bug.cgi?id=172069
2002
2003         Reviewed by JF Bastien.
2004
2005         Added Unicode Properties by extending the existing CharacterClass processing.
2006
2007         Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
2008         Unicode Database files to create character class data.  The result is a set of functions
2009         that return character classes, one for each of the required Unicode properties.
2010         There are many cases where many properties are handled by one function, primarily due to
2011         property aliases, but also due to Script_Extension properties that are the same as the
2012         Script property for the same script value.
2013
2014         Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
2015         character classes.  Unicode properties are the enum value BaseUnicodePropertyID plus a
2016         zero based value, that value being the index to the corrensponding character class
2017         function.  The generation script also creates static hashing tables similar to what we
2018         use for the generated .lut.h lookup table files.  These hashing tables map property
2019         names to the function index.  Using these hashing tables, we can lookup a property
2020         name and if present convert it to a function index.  We add that index to
2021         BaseUnicodePropertyID to create a BuiltInCharacterClassID.
2022
2023         When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
2024         When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
2025         the actual character class by calling the corresponding generated function.
2026
2027         Added a new CharacterClass constructor that can take literal arrays for ranges and matches
2028         to make the creation of large static character classes more efficent.
2029
2030         Since the Unicode character classes typically have more matches and ranges, the character
2031         class matching in the interpreter has been updated to use binary searching for matches and
2032         ranges with more than 6 entries.
2033
2034         * CMakeLists.txt:
2035         * DerivedSources.make:
2036         * JavaScriptCore.xcodeproj/project.pbxproj:
2037         * Scripts/generateYarrUnicodePropertyTables.py: Added.
2038         (openOrExit):
2039         (openUCDFileOrExit):
2040         (verifyUCDFilesExist):
2041         (ceilingToPowerOf2):
2042         (Aliases):
2043         (Aliases.__init__):
2044         (Aliases.parsePropertyAliasesFile):
2045         (Aliases.parsePropertyValueAliasesFile):
2046         (Aliases.globalAliasesFor):
2047         (Aliases.generalCategoryAliasesFor):
2048         (Aliases.generalCategoryForAlias):
2049         (Aliases.scriptAliasesFor):
2050         (Aliases.scriptNameForAlias):
2051         (PropertyData):
2052         (PropertyData.__init__):
2053         (PropertyData.setAliases):
2054         (PropertyData.makeCopy):
2055         (PropertyData.getIndex):
2056         (PropertyData.getCreateFuncName):
2057         (PropertyData.addMatch):
2058         (PropertyData.addRange):
2059         (PropertyData.addMatchUnorderedForMatchesAndRanges):
2060         (PropertyData.addRangeUnorderedForMatchesAndRanges):
2061         (PropertyData.addMatchUnordered):
2062         (PropertyData.addRangeUnordered):
2063         (PropertyData.removeMatchFromRanges):
2064         (PropertyData.removeMatch):
2065         (PropertyData.dumpMatchData):
2066         (PropertyData.dump):
2067         (PropertyData.dumpAll):
2068         (PropertyData.dumpAll.std):
2069         (PropertyData.createAndDumpHashTable):
2070         (Scripts):
2071         (Scripts.__init__):
2072         (Scripts.parseScriptsFile):
2073         (Scripts.parseScriptExtensionsFile):
2074         (Scripts.dump):
2075         (GeneralCategory):
2076         (GeneralCategory.__init__):
2077         (GeneralCategory.createSpecialPropertyData):
2078         (GeneralCategory.findPropertyGroupFor):
2079         (GeneralCategory.addNextCodePoints):
2080         (GeneralCategory.parse):
2081         (GeneralCategory.dump):
2082         (BinaryProperty):
2083         (BinaryProperty.__init__):
2084         (BinaryProperty.parsePropertyFile):
2085         (BinaryProperty.dump):
2086         * Scripts/hasher.py: Added.
2087         (stringHash):
2088         * Sources.txt:
2089         * ucd/DerivedBinaryProperties.txt: Added.
2090         * ucd/DerivedCoreProperties.txt: Added.
2091         * ucd/DerivedNormalizationProps.txt: Added.
2092         * ucd/PropList.txt: Added.
2093         * ucd/PropertyAliases.txt: Added.
2094         * ucd/PropertyValueAliases.txt: Added.
2095         * ucd/ScriptExtensions.txt: Added.
2096         * ucd/Scripts.txt: Added.
2097         * ucd/UnicodeData.txt: Added.
2098         * ucd/emoji-data.txt: Added.
2099         * yarr/Yarr.h:
2100         * yarr/YarrInterpreter.cpp:
2101         (JSC::Yarr::Interpreter::testCharacterClass):
2102         * yarr/YarrParser.h:
2103         (JSC::Yarr::Parser::parseEscape):
2104         (JSC::Yarr::Parser::parseTokens):
2105         (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
2106         (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
2107         * yarr/YarrPattern.cpp:
2108         (JSC::Yarr::CharacterClassConstructor::appendInverted):
2109         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
2110         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
2111         (JSC::Yarr::YarrPattern::errorMessage):
2112         (JSC::Yarr::PatternTerm::dump):
2113         * yarr/YarrPattern.h:
2114         (JSC::Yarr::CharacterRange::CharacterRange):
2115         (JSC::Yarr::CharacterClass::CharacterClass):
2116         (JSC::Yarr::YarrPattern::reset):
2117         (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
2118         * yarr/YarrUnicodeProperties.cpp: Added.
2119         (JSC::Yarr::HashTable::entry const):
2120         (JSC::Yarr::unicodeMatchPropertyValue):
2121         (JSC::Yarr::unicodeMatchProperty):
2122         (JSC::Yarr::createUnicodeCharacterClassFor):
2123         * yarr/YarrUnicodeProperties.h: Added.
2124
2125 2017-10-09  Commit Queue  <commit-queue@webkit.org>
2126
2127         Unreviewed, rolling out r223015 and r223025.
2128         https://bugs.webkit.org/show_bug.cgi?id=178093
2129
2130         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
2131         #webkit).
2132
2133         Reverted changesets:
2134
2135         "Enable gigacage on iOS"
2136         https://bugs.webkit.org/show_bug.cgi?id=177586
2137         http://trac.webkit.org/changeset/223015
2138
2139         "Unreviewed, disable Gigacage on ARM64 Linux"
2140         https://bugs.webkit.org/show_bug.cgi?id=177586
2141         http://trac.webkit.org/changeset/223025
2142
2143 2017-10-09  Keith Miller  <keith_miller@apple.com>
2144
2145         Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.
2146
2147         * JavaScriptCore.xcodeproj/project.pbxproj:
2148
2149 2017-10-09  Ryan Haddad  <ryanhaddad@apple.com>
2150
2151         Unreviewed, rolling out r223022.
2152
2153         This change introduced 18 test262 failures.
2154
2155         Reverted changeset:
2156
2157         "`async` should be able to be used as an imported binding
2158         name"
2159         https://bugs.webkit.org/show_bug.cgi?id=176573
2160         http://trac.webkit.org/changeset/223022
2161
2162 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2163
2164         Make the names of the options consistent
2165         https://bugs.webkit.org/show_bug.cgi?id=177933
2166
2167         Reviewed by Saam Barati.
2168
2169         I added an alias so the old spelling still works.
2170         I also fixed a bunch of typos in comments all around the codebase.
2171
2172         * b3/B3LowerToAir.cpp:
2173         * dfg/DFGByteCodeParser.cpp:
2174         (JSC::DFG::ByteCodeParser::parseBlock):
2175         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2176         * dfg/DFGOperations.h:
2177         * dfg/DFGSSAConversionPhase.h:
2178         * dfg/DFGSpeculativeJIT.h:
2179         * ftl/FTLLowerDFGToB3.cpp:
2180         (JSC::FTL::DFG::LowerDFGToB3::lower):
2181         * ftl/FTLOSREntry.cpp:
2182         (JSC::FTL::prepareOSREntry):
2183         * jit/CallFrameShuffler.cpp:
2184         (JSC::CallFrameShuffler::prepareForTailCall):
2185         * parser/Nodes.h:
2186         * parser/Parser.cpp:
2187         (JSC::Parser<LexerType>::parseExportDeclaration):
2188         * runtime/Options.h:
2189
2190 2017-10-09  Oleksandr Skachkov  <gskachkov@gmail.com>
2191
2192         Safari 10 /11 problem with if (!await get(something)).
2193         https://bugs.webkit.org/show_bug.cgi?id=176685
2194
2195         Reviewed by Saam Barati.
2196
2197         Using unary operator before `await` lead to count it as identifier.
2198         According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions
2199         and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator
2200
2201         * parser/Parser.cpp:
2202         (JSC::Parser<LexerType>::parsePrimaryExpression):
2203
2204 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
2205
2206         direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC
2207         https://bugs.webkit.org/show_bug.cgi?id=178051
2208
2209         Reviewed by Saam Barati.
2210         
2211         After I studied the profile of this test, I found two pathologies in our code relating to
2212         prototypes. I think that now that we support poly proto, it's more likely for these pathologies to
2213         happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests
2214         to trigger these pathologies.
2215         
2216         - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns
2217           this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note
2218           that we still have 6 spare bits in cellState, but those are a bit more annoying to get at.
2219         
2220         - WeakGCMap registers itself with GC using a std::function. That means allocating things in the
2221           malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is
2222           a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have
2223           a lot of transition tables. It's good to reduce the amount of memory those require.
2224         
2225         Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while
2226         I was at it. I initially thought that this would have to be part of my solution, but it turned out
2227         not to be. I think it's worth landing anyway since it makes the code a lot more clear.
2228         
2229         This fixes the timeout in that test and probably reduces memory consumption.
2230
2231         * JavaScriptCore.xcodeproj/project.pbxproj:
2232         * dfg/DFGOperations.cpp:
2233         * heap/Heap.cpp:
2234         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
2235         (JSC::Heap::registerWeakGCMap):
2236         (JSC::Heap::unregisterWeakGCMap):
2237         * heap/Heap.h:
2238         * inspector/JSInjectedScriptHostPrototype.cpp:
2239         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2240         * inspector/JSJavaScriptCallFramePrototype.cpp:
2241         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2242         * runtime/ArrayIteratorPrototype.cpp:
2243         (JSC::ArrayIteratorPrototype::finishCreation):
2244         * runtime/ArrayPrototype.cpp:
2245         (JSC::ArrayPrototype::finishCreation):
2246         * runtime/AsyncFromSyncIteratorPrototype.cpp:
2247         (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
2248         * runtime/AsyncFunctionPrototype.cpp:
2249         (JSC::AsyncFunctionPrototype::finishCreation):
2250         * runtime/AsyncGeneratorFunctionPrototype.cpp:
2251         (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
2252         * runtime/AsyncGeneratorPrototype.cpp:
2253         (JSC::AsyncGeneratorPrototype::finishCreation):
2254         * runtime/AsyncIteratorPrototype.cpp:
2255         (JSC::AsyncIteratorPrototype::finishCreation):
2256         * runtime/CommonSlowPaths.cpp:
2257         (JSC::SLOW_PATH_DECL):
2258         * runtime/GeneratorFunctionPrototype.cpp:
2259         (JSC::GeneratorFunctionPrototype::finishCreation):
2260         * runtime/GeneratorPrototype.cpp:
2261         (JSC::GeneratorPrototype::finishCreation):
2262         * runtime/IndexingType.h:
2263         * runtime/IteratorPrototype.cpp:
2264         (JSC::IteratorPrototype::finishCreation):
2265         * runtime/JSCInlines.h:
2266         * runtime/JSCell.h:
2267         * runtime/JSCellInlines.h:
2268         (JSC::JSCell::mayBePrototype const):
2269         (JSC::JSCell::didBecomePrototype):
2270         * runtime/JSObject.cpp:
2271         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
2272         (JSC::JSObject::setPrototypeDirect):
2273         * runtime/JSProxy.cpp:
2274         (JSC::JSProxy::setTarget):
2275         * runtime/MapIteratorPrototype.cpp:
2276         (JSC::MapIteratorPrototype::finishCreation):
2277         * runtime/MapPrototype.cpp:
2278         (JSC::MapPrototype::finishCreation):
2279         * runtime/ObjectPrototype.cpp:
2280         (JSC::ObjectPrototype::finishCreation):
2281         * runtime/PrototypeKey.h: Added.
2282         (JSC::PrototypeKey::PrototypeKey):
2283         (JSC::PrototypeKey::prototype const):
2284         (JSC::PrototypeKey::inlineCapacity const):
2285         (JSC::PrototypeKey::classInfo const):
2286         (JSC::PrototypeKey::globalObject const):
2287         (JSC::PrototypeKey::operator== const):
2288         (JSC::PrototypeKey::operator!= const):
2289         (JSC::PrototypeKey::operator bool const):
2290         (JSC::PrototypeKey::isHashTableDeletedValue const):
2291         (JSC::PrototypeKey::hash const):
2292         (JSC::PrototypeKeyHash::hash):
2293         (JSC::PrototypeKeyHash::equal):
2294         * runtime/PrototypeMap.cpp:
2295         (JSC::PrototypeMap::createEmptyStructure):
2296         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
2297         * runtime/PrototypeMap.h:
2298         (JSC::PrototypeMap::PrototypeMap):
2299         * runtime/PrototypeMapInlines.h: Removed.
2300         * runtime/SetIteratorPrototype.cpp:
2301         (JSC::SetIteratorPrototype::finishCreation):
2302         * runtime/SetPrototype.cpp:
2303         (JSC::SetPrototype::finishCreation):
2304         * runtime/StringIteratorPrototype.cpp:
2305         (JSC::StringIteratorPrototype::finishCreation):
2306         * runtime/WeakGCMap.h:
2307         (JSC::WeakGCMapBase::~WeakGCMapBase):
2308         * runtime/WeakGCMapInlines.h:
2309         (JSC::KeyTraitsArg>::WeakGCMap):
2310         * runtime/WeakMapPrototype.cpp:
2311         (JSC::WeakMapPrototype::finishCreation):
2312         * runtime/WeakSetPrototype.cpp:
2313         (JSC::WeakSetPrototype::finishCreation):
2314
2315 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
2316
2317         Octane/splay can leak memory due to stray pointers on the stack when run from the command line
2318         https://bugs.webkit.org/show_bug.cgi?id=178054
2319
2320         Reviewed by Saam Barati.
2321         
2322         This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In
2323         most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack
2324         height stays relatively constant.
2325
2326         * dfg/DFGOperations.cpp:
2327         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2328         (JSC::DFG::TierUpCheckInjectionPhase::run):
2329         * ftl/FTLOSREntry.cpp:
2330         * heap/Heap.cpp:
2331         (JSC::Heap::runCurrentPhase):
2332         * heap/MarkedAllocatorInlines.h:
2333         (JSC::MarkedAllocator::tryAllocate):
2334         (JSC::MarkedAllocator::allocate):
2335         * heap/Subspace.cpp:
2336         (JSC::Subspace::tryAllocateSlow):
2337         * jit/AssemblyHelpers.h:
2338         (JSC::AssemblyHelpers::sanitizeStackInline):
2339         * jit/ThunkGenerators.cpp:
2340         (JSC::slowPathFor):
2341         * runtime/VM.h:
2342         (JSC::VM::addressOfLastStackTop):
2343
2344 2017-10-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2345
2346         `async` should be able to be used as an imported binding name
2347         https://bugs.webkit.org/show_bug.cgi?id=176573
2348
2349         Reviewed by Darin Adler.
2350
2351         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2352         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2353         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2354         For example, import declaration failed to bind imported binding to the name "async" because
2355         the parser considered ASYNC as keyword.
2356
2357         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
2358         the current performance without using this ASYNC keyword.
2359
2360         * parser/Keywords.table:
2361         * parser/Parser.cpp:
2362         (JSC::Parser<LexerType>::parseStatementListItem):
2363         (JSC::Parser<LexerType>::parseStatement):
2364         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2365         (JSC::Parser<LexerType>::parseClass):
2366         (JSC::Parser<LexerType>::parseExportDeclaration):
2367         (JSC::Parser<LexerType>::parseAssignmentExpression):
2368         (JSC::Parser<LexerType>::parseProperty):
2369         (JSC::Parser<LexerType>::parsePrimaryExpression):
2370         (JSC::Parser<LexerType>::parseMemberExpression):
2371         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2372         * parser/ParserTokens.h:
2373         * runtime/CommonIdentifiers.h:
2374
2375 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2376
2377         Enable gigacage on iOS
2378         https://bugs.webkit.org/show_bug.cgi?id=177586
2379
2380         Reviewed by JF Bastien.
2381
2382         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2383         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2384         have Gigacage. So, this teaches ARM64 how to load from global variables.
2385         
2386         Also, this makes the code handle disabling the gigacage a bit better.
2387
2388         * ftl/FTLLowerDFGToB3.cpp:
2389         (JSC::FTL::DFG::LowerDFGToB3::caged):
2390         * jit/AssemblyHelpers.h:
2391         (JSC::AssemblyHelpers::cage):
2392         (JSC::AssemblyHelpers::cageConditionally):
2393         * offlineasm/arm64.rb:
2394         * offlineasm/asm.rb:
2395         * offlineasm/instructions.rb:
2396
2397 2017-10-06  Michael Saboff  <msaboff@apple.com>
2398
2399         Enable RegExp JIT for match only Unicode RegExp's
2400         https://bugs.webkit.org/show_bug.cgi?id=178033
2401
2402         Reviewed by JF Bastien.
2403
2404         I forgot to turn on JIT'ing for match-only Unicode RegExp's in r221052.  Do it now.
2405
2406         * runtime/RegExp.cpp:
2407         (JSC::RegExp::compileMatchOnly):
2408
2409 2017-10-06  Alex Christensen  <achristensen@webkit.org>
2410
2411         Build fix after r223002.
2412
2413         * dfg/DFGOSRExit.cpp:
2414         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2415         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2416
2417 2017-10-06  Commit Queue  <commit-queue@webkit.org>
2418
2419         Unreviewed, rolling out r222791 and r222873.
2420         https://bugs.webkit.org/show_bug.cgi?id=178031
2421
2422         Caused crashes with workers/wasm LayoutTests (Requested by
2423         ryanhaddad on #webkit).
2424
2425         Reverted changesets:
2426
2427         "WebAssembly: no VM / JS version of everything but Instance"
2428         https://bugs.webkit.org/show_bug.cgi?id=177473
2429         http://trac.webkit.org/changeset/222791
2430
2431         "WebAssembly: address no VM / JS follow-ups"
2432         https://bugs.webkit.org/show_bug.cgi?id=177887
2433         http://trac.webkit.org/changeset/222873
2434
2435 2017-10-06  Robin Morisset  <rmorisset@apple.com>
2436
2437         Avoid integer overflow in DFGStrengthReduction.cpp
2438         https://bugs.webkit.org/show_bug.cgi?id=177944
2439
2440         Reviewed by Saam Barati.
2441
2442         The check that we won't do integer overflow by negating INT32_MIN was itself an integer overflow.
2443         I think that signed integer overflow is undefined behaviour in C, so I replace it by an explicit check that value != INT32_MIN instead.
2444
2445         * dfg/DFGStrengthReductionPhase.cpp:
2446         (JSC::DFG::StrengthReductionPhase::handleNode):
2447
2448 2017-10-05  Keith Miller  <keith_miller@apple.com>
2449
2450         JSC generate unified sources doesn't need to run during installhdrs.
2451         https://bugs.webkit.org/show_bug.cgi?id=177640
2452
2453         Reviewed by Dan Bernstein.
2454
2455         generate unified sources doesn't need to have a xcconfig file
2456         since we don't have any feature defines. Also, remove the plist
2457         because there's no plist for this...
2458
2459         * JavaScriptCore.xcodeproj/project.pbxproj:
2460
2461 2017-10-05  Jer Noble  <jer.noble@apple.com>
2462
2463         [Cocoa] Enable ENABLE_ENCRYPTED_MEDIA build-time setting
2464         https://bugs.webkit.org/show_bug.cgi?id=177261
2465
2466         Reviewed by Eric Carlson.
2467
2468         * Configurations/FeatureDefines.xcconfig:
2469
2470 2017-10-05  Ryan Haddad  <ryanhaddad@apple.com>
2471
2472         Unreviewed, rolling out r222929.
2473
2474         Caused assertion failures during LayoutTests.
2475
2476         Reverted changeset:
2477
2478         "Only add prototypes to the PrototypeMap if they're not
2479         already present"
2480         https://bugs.webkit.org/show_bug.cgi?id=177952
2481         http://trac.webkit.org/changeset/222929
2482
2483 2017-10-05  Carlos Alberto Lopez Perez  <clopez@igalia.com>
2484
2485         Generate a compile error if release is built without compiler optimizations
2486         https://bugs.webkit.org/show_bug.cgi?id=177665
2487
2488         Reviewed by Brian Burg.
2489
2490         Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
2491         this files are compiled with -O0 for build speed reasons after r195639.
2492
2493         * JavaScriptCore.xcodeproj/project.pbxproj:
2494
2495 2017-10-05  Saam Barati  <sbarati@apple.com>
2496
2497         Only add prototypes to the PrototypeMap if they're not already present
2498         https://bugs.webkit.org/show_bug.cgi?id=177952
2499
2500         Reviewed by Michael Saboff and JF Bastien.
2501
2502         With poly proto, we need to call PrototypeMap::add more frequently since we don't
2503         know if the prototype is already in the map or not based solely on Structure.
2504         PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
2505         allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
2506         expensive than just checking if the prototype is in the map prior to adding it. This
2507         patch makes the change to only add the prototype if it's not already in the map. To
2508         do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
2509         This allows us to both only do a single hash table lookup and also to allocate only
2510         a single Weak handle when necessary.
2511
2512         * runtime/PrototypeMapInlines.h:
2513         (JSC::PrototypeMap::addPrototype):
2514         * runtime/WeakGCMap.h:
2515         (JSC::WeakGCMap::add):
2516
2517 2017-10-05  Saam Barati  <sbarati@apple.com>
2518
2519         Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.
2520
2521         * runtime/Options.cpp:
2522         (JSC::recomputeDependentOptions):
2523
2524 2017-10-05  Saam Barati  <sbarati@apple.com>
2525
2526         Make sure all prototypes under poly proto get added into the VM's prototype map
2527         https://bugs.webkit.org/show_bug.cgi?id=177909
2528
2529         Reviewed by Keith Miller.
2530
2531         This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.
2532
2533         * JavaScriptCore.xcodeproj/project.pbxproj:
2534         * bytecode/BytecodeList.json:
2535         * dfg/DFGByteCodeParser.cpp:
2536         (JSC::DFG::ByteCodeParser::parseBlock):
2537         * dfg/DFGOperations.cpp:
2538         * runtime/CommonSlowPaths.cpp:
2539         (JSC::SLOW_PATH_DECL):
2540         * runtime/JSCInlines.h:
2541         * runtime/PrototypeMap.cpp:
2542         (JSC::PrototypeMap::addPrototype): Deleted.
2543         * runtime/PrototypeMap.h:
2544         * runtime/PrototypeMapInlines.h:
2545         (JSC::PrototypeMap::isPrototype const):
2546         (JSC::PrototypeMap::addPrototype):
2547
2548 2017-09-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2549
2550         [JSC] Introduce import.meta
2551         https://bugs.webkit.org/show_bug.cgi?id=177703
2552
2553         Reviewed by Filip Pizlo.
2554
2555         This patch adds stage 3 `import.meta`[1].
2556         We add a new hook function moduleLoaderCreateImportMetaProperties, which creates
2557         import meta properties object to this module. And we set this object as @meta
2558         private variable in module environments. So module code can access this by accessing
2559         @meta private variable.
2560
2561         [1]: https://github.com/tc39/proposal-import-meta
2562
2563         * builtins/BuiltinNames.h:
2564         * builtins/ModuleLoaderPrototype.js:
2565         * bytecompiler/BytecodeGenerator.cpp:
2566         (JSC::BytecodeGenerator::BytecodeGenerator):
2567         * jsc.cpp:
2568         (GlobalObject::moduleLoaderCreateImportMetaProperties):
2569         * parser/Parser.cpp:
2570         (JSC::Parser<LexerType>::parseModuleSourceElements):
2571         (JSC::Parser<LexerType>::parseMemberExpression):
2572         * runtime/JSGlobalObject.cpp:
2573         * runtime/JSGlobalObject.h:
2574         * runtime/JSModuleLoader.cpp:
2575         (JSC::JSModuleLoader::createImportMetaProperties):
2576         * runtime/JSModuleLoader.h:
2577         * runtime/JSModuleRecord.cpp:
2578         (JSC::JSModuleRecord::link):
2579         (JSC::JSModuleRecord::instantiateDeclarations):
2580         * runtime/JSModuleRecord.h:
2581         * runtime/ModuleLoaderPrototype.cpp:
2582         (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
2583
2584 2017-10-04  Saam Barati  <sbarati@apple.com>
2585
2586         Make pertinent AccessCases watch the poly proto watchpoint
2587         https://bugs.webkit.org/show_bug.cgi?id=177765
2588
2589         Reviewed by Keith Miller.
2590
2591         This patch makes it so that stubs that encounter a structure with a
2592         valid poly proto watchpoint will watch the poly proto watchpoint. This
2593         ensures that if the watchpoint is fired, the stub will be cleared
2594         and have a chance to regenerate. In an ideal world, this will lead
2595         to the stub generating better code since it may never encounter the
2596         non-poly proto structure again.
2597         
2598         This patch also fixes a bug in the original poly proto code where
2599         I accidentally had a condition inverted. The bad code caused a
2600         stub that continually cached two structures which are structurally
2601         equivalent but with different prototype objects to always clear itself.
2602         The code should have been written differently. It should have only
2603         cleared if the poly proto watchpoint *was not* fired. The code
2604         accidentally cleared only if stub *was* fired.
2605
2606         * bytecode/AccessCase.cpp:
2607         (JSC::AccessCase::commit):
2608         * bytecode/PolymorphicAccess.cpp:
2609         (JSC::PolymorphicAccess::addCases):
2610         (WTF::printInternal):
2611         * bytecode/PolymorphicAccess.h:
2612         (JSC::AccessGenerationResult::shouldResetStubAndFireWatchpoints const):
2613         (JSC::AccessGenerationResult::addWatchpointToFire):
2614         (JSC::AccessGenerationResult::fireWatchpoints):
2615         (JSC::AccessGenerationResult::shouldResetStub const): Deleted.
2616         * bytecode/StructureStubInfo.cpp:
2617         (JSC::StructureStubInfo::addAccessCase):
2618         (JSC::StructureStubInfo::reset):
2619         * bytecode/Watchpoint.h:
2620         (JSC::InlineWatchpointSet::inflate):
2621         * jit/Repatch.cpp:
2622         (JSC::fireWatchpointsAndClearStubIfNeeded):
2623         (JSC::tryCacheGetByID):
2624         (JSC::repatchGetByID):
2625         (JSC::tryCachePutByID):
2626         (JSC::repatchPutByID):
2627         (JSC::tryCacheIn):
2628         (JSC::repatchIn):
2629         (JSC::tryRepatchIn): Deleted.
2630
2631 2017-10-04  Matt Baker  <mattbaker@apple.com>
2632
2633         Web Inspector: Improve CanvasManager recording events
2634         https://bugs.webkit.org/show_bug.cgi?id=177762
2635
2636         Reviewed by Devin Rousso.
2637
2638         * inspector/protocol/Canvas.json:
2639         Renamed events for clarity and consistency; made recording data optional.
2640
2641 2017-10-04  JF Bastien  <jfbastien@apple.com>
2642
2643         WTF: Update std::expected to match current proposal
2644         https://bugs.webkit.org/show_bug.cgi?id=177881
2645
2646         Reviewed by Mark Lam.
2647
2648         Update API.
2649
2650         * wasm/WasmB3IRGenerator.cpp:
2651         * wasm/WasmModule.cpp:
2652         (JSC::Wasm::makeValidationResult):
2653         * wasm/WasmParser.h:
2654         * wasm/WasmValidate.cpp:
2655         * wasm/generateWasmValidateInlinesHeader.py:
2656         (loadMacro):
2657         (storeMacro):
2658
2659 2017-10-04  JF Bastien  <jfbastien@apple.com>
2660
2661         WebAssembly: address no VM / JS follow-ups
2662         https://bugs.webkit.org/show_bug.cgi?id=177887
2663
2664         Reviewed by Saam Barati.
2665
2666         All minor fixes, no functional changes.
2667
2668         * wasm/WasmB3IRGenerator.cpp:
2669         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2670         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2671         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
2672         (JSC::Wasm::B3IRGenerator::addCall):
2673         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2674         * wasm/WasmContext.cpp:
2675         (JSC::Wasm::Context::store):
2676         * wasm/WasmMemoryMode.h:
2677         * wasm/WasmTable.h:
2678         * wasm/js/JSWebAssemblyInstance.cpp:
2679         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2680         * wasm/js/JSWebAssemblyTable.cpp:
2681         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2682         (JSC::JSWebAssemblyTable::grow):
2683
2684 2017-10-04  Mark Lam  <mark.lam@apple.com>
2685
2686         Add support for using Probe DFG OSR Exit behind a runtime flag.
2687         https://bugs.webkit.org/show_bug.cgi?id=177844
2688         <rdar://problem/34801425>
2689
2690         Reviewed by Saam Barati.
2691
2692         This is based on the code originally posted in https://bugs.webkit.org/show_bug.cgi?id=175144
2693         (in r221774 and r221832) with some optimizations and bug fixes added.  The probe
2694         based DFG OSR Exit is only enabled if Options::useProbeOSRExit() is true.  We're
2695         landing this behind an option switch to make it easier to tune performance using
2696         the probe based OSR exit.
2697
2698         * JavaScriptCore.xcodeproj/project.pbxproj:
2699         * assembler/MacroAssembler.cpp:
2700         (JSC::stdFunctionCallback):
2701         * assembler/MacroAssemblerPrinter.cpp:
2702         (JSC::Printer::printCallback):
2703         * assembler/ProbeContext.cpp:
2704         (JSC::Probe::executeProbe):
2705         (JSC::Probe::flushDirtyStackPages):
2706         * assembler/ProbeContext.h:
2707         (JSC::Probe::Context::Context):
2708         (JSC::Probe::Context::arg):
2709         * assembler/ProbeFrame.h: Added.
2710         (JSC::Probe::Frame::Frame):
2711         (JSC::Probe::Frame::argument):
2712         (JSC::Probe::Frame::operand):
2713         (JSC::Probe::Frame::setArgument):
2714         (JSC::Probe::Frame::setOperand):
2715         (JSC::Probe::Frame::get):
2716         (JSC::Probe::Frame::set):
2717         * assembler/ProbeStack.cpp:
2718         (JSC::Probe::Page::lowWatermarkFromVisitingDirtyChunks):
2719         (JSC::Probe::Stack::Stack):
2720         (JSC::Probe::Stack::lowWatermarkFromVisitingDirtyPages):
2721         * assembler/ProbeStack.h:
2722         (JSC::Probe::Stack::Stack):
2723         (JSC::Probe::Stack::lowWatermark):
2724         (JSC::Probe::Stack::set):
2725         (JSC::Probe::Stack::savedStackPointer const):
2726         (JSC::Probe::Stack::setSavedStackPointer):
2727         (JSC::Probe::Stack::newStackPointer const): Deleted.
2728         (JSC::Probe::Stack::setNewStackPointer): Deleted.
2729         * bytecode/ArrayProfile.h:
2730         (JSC::ArrayProfile::observeArrayMode):
2731         * bytecode/CodeBlock.cpp:
2732         (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
2733         * bytecode/CodeBlock.h:
2734         (JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
2735         * bytecode/ExecutionCounter.h:
2736         (JSC::ExecutionCounter::hasCrossedThreshold const):
2737         (JSC::ExecutionCounter::setNewThresholdForOSRExit):
2738         * bytecode/MethodOfGettingAValueProfile.cpp:
2739         (JSC::MethodOfGettingAValueProfile::reportValue):
2740         * bytecode/MethodOfGettingAValueProfile.h:
2741         * dfg/DFGDriver.cpp:
2742         (JSC::DFG::compileImpl):
2743         * dfg/DFGJITCompiler.cpp:
2744         (JSC::DFG::JITCompiler::linkOSRExits):
2745         (JSC::DFG::JITCompiler::link):
2746         * dfg/DFGOSRExit.cpp:
2747         (JSC::DFG::jsValueFor):
2748         (JSC::DFG::restoreCalleeSavesFor):
2749         (JSC::DFG::saveCalleeSavesFor):
2750         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2751         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2752         (JSC::DFG::saveOrCopyCalleeSavesFor):
2753         (JSC::DFG::createDirectArgumentsDuringExit):
2754         (JSC::DFG::createClonedArgumentsDuringExit):
2755         (JSC::DFG::emitRestoreArguments):
2756         (JSC::DFG::OSRExit::executeOSRExit):
2757         (JSC::DFG::reifyInlinedCallFrames):
2758         (JSC::DFG::adjustAndJumpToTarget):
2759         (JSC::DFG::printOSRExit):
2760         * dfg/DFGOSRExit.h:
2761         (JSC::DFG::OSRExitState::OSRExitState):
2762         * dfg/DFGThunks.cpp:
2763         (JSC::DFG::osrExitThunkGenerator):
2764         * dfg/DFGThunks.h:
2765         * dfg/DFGVariableEventStream.cpp:
2766         (JSC::DFG::tryToSetConstantRecovery):
2767         (JSC::DFG::VariableEventStream::reconstruct const):
2768         (JSC::DFG::VariableEventStream::tryToSetConstantRecovery const): Deleted.
2769         * dfg/DFGVariableEventStream.h:
2770         * profiler/ProfilerOSRExit.h:
2771         (JSC::Profiler::OSRExit::incCount):
2772         * runtime/JSCJSValue.h:
2773         * runtime/JSCJSValueInlines.h:
2774         * runtime/Options.h:
2775
2776 2017-10-04  Ryan Haddad  <ryanhaddad@apple.com>
2777
2778         Unreviewed, rolling out r222840.
2779
2780         This change breaks internal builds.
2781
2782         Reverted changeset:
2783
2784         "Generate a compile error if release is built without compiler
2785         optimizations"
2786         https://bugs.webkit.org/show_bug.cgi?id=177665
2787         http://trac.webkit.org/changeset/222840
2788
2789 2017-10-04  Carlos Alberto Lopez Perez  <clopez@igalia.com>
2790
2791         Generate a compile error if release is built without compiler optimizations
2792         https://bugs.webkit.org/show_bug.cgi?id=177665
2793
2794         Reviewed by Michael Catanzaro.
2795
2796         Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
2797         this files are compiled with -O0 for build speed reasons after r195639.
2798
2799         * JavaScriptCore.xcodeproj/project.pbxproj:
2800
2801 2017-10-03  Jon Davis  <jond@apple.com>
2802
2803         Update WebAssembly to "Supported"
2804         https://bugs.webkit.org/show_bug.cgi?id=177831
2805
2806         Reviewed by Alexey Proskuryakov.
2807         
2808         Cleaned up Async Iteration and Object rest/spread to use "In Development" 
2809         instead of "In development". 
2810
2811         * features.json: 
2812
2813 2017-10-03  Saam Barati  <sbarati@apple.com>
2814
2815         Implement polymorphic prototypes
2816         https://bugs.webkit.org/show_bug.cgi?id=176391
2817
2818         Reviewed by Filip Pizlo.
2819
2820         This patch changes JSC's object model with respect to where the prototype
2821         of an object is stored. Previously, it was always stored as
2822         a constant value inside Structure. So an object's structure used to
2823         always tell you what its prototype is. Anytime an object changed
2824         its prototype, it would do a structure transition. This enables
2825         a large class of optimizations: just by doing a structure check,
2826         we know what the prototype is.
2827         
2828         However, this design falls down when you have many objects that
2829         have the same shape, but only differ in what their prototype value
2830         is. This arises in many JS programs. A simple, and probably common, example
2831         is when the program has a constructor inside of a function:
2832         ```
2833         function foo() {
2834             class C {
2835                 constructor() { this.field1 = 42; ...; this.fieldN = 42; }
2836                 method1() { doStuffWith(this.field); }
2837                 method2() { doStuffWith(this.field); }
2838             }
2839             let c = new C;
2840             do things with c;
2841             }
2842         repeatedly call foo() here.
2843         ```
2844         
2845         Before this patch, in the above program, each time `new C` created an
2846         object, it would create an object with a different structure. The
2847         reason for this is that each time foo is called, there is a new
2848         instance of C.prototype. However, each `new C` that was created
2849         with have identical shape sans its prototype value. This would
2850         cause all ICs that used `c` to quickly give up on any form of caching
2851         because they would see too many structures and give up and permanently
2852         divert control flow to the slow path.
2853         
2854         This patch fixes this issue by expanding the notion of where the prototype
2855         of an object is stored. There are now two notions of where the prototype
2856         is stored. A Structure can now be in two modes:
2857         1. Mono proto mode. This is the same mode as we used to have. It means
2858         the structure itself has a constant prototype value.
2859         2. Poly proto mode. This means the structure knows nothing about the
2860         prototype value itself. Objects with this structure store their prototype
2861         in normal object field storage. The structure will tell you the offset of
2862         this prototype inside the object's storage. As of today, we only reserve
2863         inline slots for the prototype field because poly proto only occurs
2864         for JSFinalObject. However, this will be expanded to support out of line
2865         offsets in a future patch when we extend poly proto to work when we inherit
2866         from builtin types like Map and Array.
2867         
2868         In this initial patch, we do poly proto style inline caching whenever
2869         we see an object that is poly proto or if an object in its prototype lookup
2870         chain is poly proto. Poly proto ICs work by verifying the lookup chain
2871         at runtime. This essentially boils down to performing structure checks
2872         up the prototype chain. In a future patch, we're going to extend object
2873         property condition set to work with objects that don't have poly proto bases.
2874         
2875         Initially, accesses that have poly proto access chains will always turn
2876         into GetById/PutById in the DFG. In a future patch, I'm going to teach
2877         the DFG how to inline certain accesses that have poly proto in the access
2878         chain.
2879         
2880         One of most interesting parts about this patch is how we decide when to go
2881         poly proto. This patch uses a profiling based approach. An IC will inform
2882         a watchpoint that it sees an opportunity when two Structure's are structurally
2883         the same, sans the base object's prototype. This means that two structures
2884         have equivalent shapes all the way up the prototype chain. To support fast
2885         structural comparison, we compute a hash for a structure based on the properties
2886         it has. We compute this hash as we add properties to the structure. This
2887         computation is nearly free since we always add UniquedStringImpl*'s which
2888         already have their hashes computed. To compare structural equivalence, we
2889         just compare hash values all the way up the prototype chain. This means we
2890         can get hash conflicts between two structures, but it's extremely rare. First,
2891         it'll be rare for two structures to have the same hash. Secondly, we only
2892         consider structures originating from the same executable.
2893         
2894         How we set up this poly proto watchpoint is crucial to its design. When we create_this
2895         an object originating from some executable, that executable will create a Box<InlineWatchpointSet>.
2896         Each structure that originates from this executable will get a copy of that
2897         Box<InlineWatchpointSet>. As that structure transitions to new structures,
2898         they too will get a copy of that Box<InilneWatchpointSet>. Therefore, when
2899         invalidating an arbitrary structure's poly proto watchpoint, we will know
2900         the next time we create_this from that executable that it had been
2901         invalidated, and that we should create an object with a poly proto
2902         structure. We also use the pointer value of this Box<InlineWatchpointSet>
2903         to determine if two structures originated from the same executable. This
2904         pruning will severely limit the chances of getting a hash conflict in practice.
2905         
2906         This patch is neutral on my MBP on traditional JS benchmarks like Octane/Kraken/Sunspider.
2907         It may be a 1-2% ARES-6 progression.
2908         
2909         This patch is between neutral and a 9x progression on the various tests
2910         I added. Most of the microbenchmarks are progressed by at least 50%.
2911
2912         * JavaScriptCore.xcodeproj/project.pbxproj:
2913         * Sources.txt:
2914         * builtins/BuiltinNames.cpp:
2915         * builtins/BuiltinNames.h:
2916         (JSC::BuiltinNames::BuiltinNames):
2917         (JSC::BuiltinNames::underscoreProtoPrivateName const):
2918         * bytecode/AccessCase.cpp:
2919         (JSC::AccessCase::AccessCase):
2920         (JSC::AccessCase::create):
2921         (JSC::AccessCase::commit):
2922         (JSC::AccessCase::guardedByStructureCheck const):
2923         (JSC::AccessCase::canReplace const):
2924         (JSC::AccessCase::dump const):
2925         (JSC::AccessCase::visitWeak const):
2926         (JSC::AccessCase::propagateTransitions const):
2927         (JSC::AccessCase::generateWithGuard):
2928         (JSC::AccessCase::generateImpl):
2929         * bytecode/AccessCase.h:
2930         (JSC::AccessCase::usesPolyProto const):
2931         (JSC::AccessCase::AccessCase):
2932         * bytecode/CodeBlock.cpp:
2933         (JSC::CodeBlock::finishCreation):
2934         * bytecode/GetByIdStatus.cpp:
2935         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2936         * bytecode/GetterSetterAccessCase.cpp:
2937         (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
2938         (JSC::GetterSetterAccessCase::create):
2939         * bytecode/GetterSetterAccessCase.h:
2940         * bytecode/InternalFunctionAllocationProfile.h:
2941         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
2942         * bytecode/IntrinsicGetterAccessCase.cpp:
2943         (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
2944         * bytecode/IntrinsicGetterAccessCase.h:
2945         * bytecode/ModuleNamespaceAccessCase.cpp:
2946         (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
2947         * bytecode/ObjectAllocationProfile.cpp: Added.
2948         (JSC::ObjectAllocationProfile::initializeProfile):
2949         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
2950         * bytecode/ObjectAllocationProfile.h:
2951         (JSC::ObjectAllocationProfile::clear):
2952         (JSC::ObjectAllocationProfile::initialize): Deleted.
2953         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
2954         * bytecode/ObjectPropertyConditionSet.cpp:
2955         * bytecode/PolyProtoAccessChain.cpp: Added.
2956         (JSC::PolyProtoAccessChain::create):
2957         (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const):
2958         (JSC::PolyProtoAccessChain::operator== const):
2959         (JSC::PolyProtoAccessChain::dump const):
2960         * bytecode/PolyProtoAccessChain.h: Added.
2961         (JSC::PolyProtoAccessChain::clone):
2962         (JSC::PolyProtoAccessChain:: const):
2963         (JSC::PolyProtoAccessChain::operator!= const):
2964         (JSC::PolyProtoAccessChain::forEach const):
2965         * bytecode/PolymorphicAccess.cpp:
2966         (JSC::PolymorphicAccess::addCases):
2967         (JSC::PolymorphicAccess::regenerate):
2968         (WTF::printInternal):
2969         * bytecode/PolymorphicAccess.h:
2970         (JSC::AccessGenerationResult::shouldResetStub const):
2971         (JSC::AccessGenerationState::AccessGenerationState):
2972         * bytecode/PropertyCondition.cpp:
2973         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
2974         * bytecode/ProxyableAccessCase.cpp:
2975         (JSC::ProxyableAccessCase::ProxyableAccessCase):
2976         (JSC::ProxyableAccessCase::create):
2977         * bytecode/ProxyableAccessCase.h:
2978         * bytecode/PutByIdStatus.cpp:
2979         (JSC::PutByIdStatus::computeForStubInfo):
2980         * bytecode/StructureStubInfo.cpp:
2981         (JSC::StructureStubInfo::addAccessCase):
2982         * dfg/DFGByteCodeParser.cpp:
2983         (JSC::DFG::ByteCodeParser::load):
2984         (JSC::DFG::ByteCodeParser::parseBlock):
2985         * dfg/DFGGraph.cpp:
2986         (JSC::DFG::Graph::canDoFastSpread):
2987         * dfg/DFGOperations.cpp:
2988         * dfg/DFGSpeculativeJIT.cpp:
2989         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2990         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
2991         * dfg/DFGSpeculativeJIT.h:
2992         * dfg/DFGSpeculativeJIT64.cpp:
2993         (JSC::DFG::SpeculativeJIT::compile):
2994         * ftl/FTLLowerDFGToB3.cpp:
2995         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2996         * jit/JITOpcodes.cpp:
2997         (JSC::JIT::emit_op_instanceof):
2998         * jit/JITOpcodes32_64.cpp:
2999         (JSC::JIT::emit_op_instanceof):
3000         * jit/Repatch.cpp:
3001         (JSC::tryCacheGetByID):
3002         (JSC::tryCachePutByID):
3003         (JSC::tryRepatchIn):
3004         * jsc.cpp:
3005         (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
3006         (WTF::DOMJITGetterBaseJSObject::createStructure):
3007         (WTF::DOMJITGetterBaseJSObject::create):
3008         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
3009         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
3010         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
3011         (WTF::DOMJITGetterBaseJSObject::customGetter):
3012         (WTF::DOMJITGetterBaseJSObject::finishCreation):
3013         (GlobalObject::finishCreation):
3014         (functionCreateDOMJITGetterBaseJSObject):
3015         * llint/LLIntSlowPaths.cpp:
3016         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3017         * runtime/ArrayPrototype.cpp:
3018         (JSC::holesMustForwardToPrototype):
3019         (JSC::fastJoin):
3020         (JSC::arrayProtoFuncReverse):
3021         (JSC::moveElements):
3022         * runtime/ClonedArguments.cpp:
3023         (JSC::ClonedArguments::createEmpty):
3024         (JSC::ClonedArguments::createWithInlineFrame):
3025         (JSC::ClonedArguments::createWithMachineFrame):
3026         (JSC::ClonedArguments::createByCopyingFrom):
3027         * runtime/CommonSlowPaths.cpp:
3028         (JSC::SLOW_PATH_DECL):
3029         * runtime/FunctionExecutable.cpp:
3030         (JSC::FunctionExecutable::visitChildren):
3031         * runtime/FunctionExecutable.h:
3032         * runtime/FunctionRareData.cpp:
3033         (JSC::FunctionRareData::initializeObjectAllocationProfile):
3034         * runtime/FunctionRareData.h:
3035         * runtime/InternalFunction.cpp:
3036         (JSC::InternalFunction::createSubclassStructureSlow):
3037         * runtime/JSArray.cpp:
3038         (JSC::JSArray::fastSlice):
3039         (JSC::JSArray::shiftCountWithArrayStorage):
3040         (JSC::JSArray::shiftCountWithAnyIndexingType):
3041         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
3042         * runtime/JSArrayInlines.h:
3043         (JSC::JSArray::canFastCopy):
3044         * runtime/JSCJSValue.cpp:
3045         (JSC::JSValue::dumpInContextAssumingStructure const):
3046         * runtime/JSFunction.cpp:
3047         (JSC::JSFunction::prototypeForConstruction):
3048         (JSC::JSFunction::allocateAndInitializeRareData):
3049         (JSC::JSFunction::initializeRareData):
3050         (JSC::JSFunction::getOwnPropertySlot):
3051         * runtime/JSFunction.h:
3052         * runtime/JSMap.cpp:
3053         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
3054         (JSC::JSMap::canCloneFastAndNonObservable):
3055         * runtime/JSObject.cpp:
3056         (JSC::JSObject::putInlineSlow):
3057         (JSC::JSObject::createInitialIndexedStorage):
3058         (JSC::JSObject::createArrayStorage):
3059         (JSC::JSObject::convertUndecidedToArrayStorage):
3060         (JSC::JSObject::convertInt32ToArrayStorage):
3061         (JSC::JSObject::convertDoubleToArrayStorage):
3062         (JSC::JSObject::convertContiguousToArrayStorage):
3063         (JSC::JSObject::ensureInt32Slow):
3064         (JSC::JSObject::ensureDoubleSlow):
3065         (JSC::JSObject::ensureContiguousSlow):
3066         (JSC::JSObject::ensureArrayStorageSlow):
3067         (JSC::JSObject::setPrototypeDirect):
3068         (JSC::JSObject::ordinaryToPrimitive const):
3069         (JSC::JSObject::putByIndexBeyondVectorLength):
3070         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
3071         (JSC::JSObject::getEnumerableLength):
3072         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
3073         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
3074         (JSC::JSObject::needsSlowPutIndexing const):
3075         (JSC::JSObject::suggestedArrayStorageTransition const):
3076         * runtime/JSObject.h:
3077         (JSC::JSObject::finishCreation):
3078         (JSC::JSObject::getPrototypeDirect const):
3079         (JSC::JSObject::getPropertySlot):
3080         * runtime/JSObjectInlines.h:
3081         (JSC::JSObject::getPropertySlot):
3082         (JSC::JSObject::getNonIndexPropertySlot):
3083         (JSC::JSObject::putInlineForJSObject):
3084         * runtime/JSPropertyNameEnumerator.h:
3085         (JSC::propertyNameEnumerator):
3086         * runtime/JSSet.cpp:
3087         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
3088         (JSC::JSSet::canCloneFastAndNonObservable):
3089         * runtime/LazyClassStructure.h:
3090         (JSC::LazyClassStructure::prototypeConcurrently const): Deleted.
3091         * runtime/Operations.cpp:
3092         (JSC::normalizePrototypeChain):
3093         * runtime/Operations.h:
3094         * runtime/Options.h:
3095         * runtime/PrototypeMap.cpp:
3096         (JSC::PrototypeMap::createEmptyStructure):
3097         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
3098         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
3099         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
3100         * runtime/PrototypeMap.h:
3101         * runtime/Structure.cpp:
3102         (JSC::Structure::Structure):
3103         (JSC::Structure::create):
3104         (JSC::Structure::holesMustForwardToPrototype const):
3105         (JSC::Structure::changePrototypeTransition):
3106         (JSC::Structure::isCheapDuringGC):
3107         (JSC::Structure::toStructureShape):
3108         (JSC::Structure::dump const):
3109         (JSC::Structure::canCachePropertyNameEnumerator const):
3110         (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses const): Deleted.
3111         (JSC::Structure::needsSlowPutIndexing const): Deleted.
3112         (JSC::Structure::suggestedArrayStorageTransition const): Deleted.
3113         (JSC::Structure::prototypeForLookup const): Deleted.
3114         (JSC::Structure::prototypeChainMayInterceptStoreTo): Deleted.
3115         (JSC::Structure::canUseForAllocationsOf): Deleted.
3116         * runtime/Structure.h:
3117         * runtime/StructureChain.h:
3118         * runtime/StructureInlines.h:
3119         (JSC::Structure::create):
3120         (JSC::Structure::storedPrototypeObject const):
3121         (JSC::Structure::storedPrototypeStructure const):
3122         (JSC::Structure::storedPrototype const):
3123         (JSC::prototypeForLookupPrimitiveImpl):
3124         (JSC::Structure::prototypeForLookup const):
3125         (JSC::Structure::prototypeChain const):
3126         (JSC::Structure::isValid const):
3127         (JSC::Structure::add):
3128         (JSC::Structure::setPropertyTable):
3129         (JSC::Structure::shouldConvertToPolyProto):
3130         * runtime/StructureRareData.h:
3131         * runtime/TypeProfilerLog.cpp:
3132         (JSC::TypeProfilerLog::processLogEntries):
3133         * runtime/TypeSet.cpp:
3134         (JSC::TypeSet::addTypeInformation):
3135         * runtime/TypeSet.h:
3136         * runtime/WriteBarrier.h:
3137         (JSC::WriteBarrierBase<Unknown>::isInt32 const):
3138
3139 2017-10-03  JF Bastien  <jfbastien@apple.com>
3140
3141         WebAssembly: no VM / JS version of everything but Instance
3142         https://bugs.webkit.org/show_bug.cgi?id=177473
3143
3144         Reviewed by Filip Pizlo.
3145
3146         This change entails cleaning up and splitting a bunch of code which we had
3147         intertwined between C++ classes which represent JS objects, and pure C++
3148         implementation objects. This specific change goes most of the way towards
3149         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
3150         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
3151         yet). Because of this we still have a few FIXME identifying places that need to
3152         change. A follow-up change will go the rest of the way.
3153
3154         I went about this change in the simplest way possible: grep the
3155         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
3156         sub-directory (which contains the JS implementation of WebAssembly).
3157
3158         None of this change removes the need for a JIT entitlement to be able to use
3159         WebAssembly. We don't have an interpreter, the process therefore still needs to
3160         be allowed to JIT to use these pure-C++ APIs.
3161
3162         Interesting things to note:
3163
3164           - Remove VM from Plan and associated places. It can just live as a capture in
3165             the callback lambda if it's needed.
3166           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
3167             collect. We now instead pass two lambdas at construction time for this
3168             purpose: one to notify of memory pressure, and the other to ask for
3169             syncrhonous memory reclamation. This allows whoever creates the memory to
3170             dictate how to react to both these cases, and for a JS embedding that's to
3171             call the GC (async or sync, respectively).
3172           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
3173             there, with an enum class for failure types.
3174           - Exceeding max on memory growth now returns a range error as per spec. This
3175             is a (very minor) breaking change: it used to throw OOM error. Update the
3176             corresponding test.
3177           - When generating the grow_memory opcode, no need to get the VM. Instead,
3178             reach directly for Wasm::Memory and grow it.
3179           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
3180             ever called from JS (not from grow_memory as before).
3181           - Wasm::Memory now takes a callback for successful growth. This allows JS
3182             wrappers to register themselves when growth succeeds without Wasm::Memory
3183             knowning anything about JS. It'll also allow creating a list of callbacks
3184             for when we add thread support (we'll want to notify many wrappers, all
3185             under a lock).
3186           - Wasm::Memory is now back to being the source of truth about address / size,
3187             used directly by generated code instead of JSWebAssemblyMemory.
3188           - Move wasmToJS from the general WasmBinding header to its own header under
3189             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
3190             and therefore isn't general WebAssembly.
3191           - Make Wasm::Context an actual type (just a struct holding a
3192             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
3193             doesn't add anything to the Context and doesn't change what actually gets
3194             passed around in JIT code (fast TLS or registers) because these changes
3195             potentially impact performance. The entire purpose of this change is to
3196             allow passing Wasm::Context around without having to know about VM. Since VM
3197             contains a Wasm::Context the JS embedding is effectively the same, but with
3198             this setup a non-JS embedding is much better off.
3199           - Move JSWebAssembly into the JS folder.
3200           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
3201           - wasm->JS stubs are now on Wasm::CodeBlock's tail as raw pointers, instead of
3202             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
3203             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
3204             called wasm->JS stub. This move means that the embedder must, after creating
3205             a Wasm::CodeBlock, somehow create the stubs to call back into the
3206             embedder. This isn't adding any indirection to the generated code because
3207             the B3 IR generator now reaches for Wasm::CodeBlock instead of
3208             JSWebAssemblyCodeBlock.
3209           - Move more CodeBlock things. Compilation completion is now marked by its own
3210             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
3211             was causing a deadlock in stack-trace.js because before my changes
3212             JSWebAssemblyCodeBlock did its own completion checking separately from
3213             Wasm::CodeBlock, without getting the lock. Now that everything points to
3214             Wasm::CodeBlock and there's no cached completion marker, the lock was being
3215             acquired in a sanity-check assertion.
3216           - Embedder -> Wasm wrappers are now generated through a function that's passed
3217             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
3218           - WasmMemory doens't need to know about fault handling thunks. Only the IR
3219             generator should know, and should make sure that the exception throwing
3220             thunk is generated if any memory is present (note: with signal handling not
3221             all of them generate an exception check).
3222           - Make exception throwing pluggable: instead of having a hard-coded
3223             JS-specific lambda we now have a regular C++ function being called from JIT
3224             code when a WebAssembly exception is thrown. This allows any embedder to get
3225             called as they wish. For now a process can only have a single of these
3226             functions (i.e. only one embedder per process) because the trap handler is a
3227             singleton. That can be fixed in in #177475.
3228           - Create WasmEmbedder.h where all embedder plugging will live.
3229           - Split up JSWebAssemblyTable into Wasm::Table which is
3230             refcounted. JSWebAssemblyTable now only contains the JS functions in the
3231             table, and Wasm::Table is what's used by the JIT code to lookup where to
3232             call and do the instance check (for context switch). Note that this creates
3233             an extra allocation for all the instances in Wasm::Table, and in exchange
3234             removes an indirection in JIT code because the instance used to be obtained
3235             off of the JS function. Also note that it's the embedder than keeps the
3236             instances alive, not Wasm::Table (which holds a dumb pointer to the
3237             instance), because doing otherwise would cause reference cycles.
3238           - Add WasmInstance. It doesn't do much for now, owns globals.
3239           - JSWebAssembly instance now doesn't just contain the imported functions as
3240             JSObjects, it also has the corresponding import's instance and wasm
3241             entrypoint. This triples the space allocated per instance's imported
3242             function, but there shouldn't be that many imports. This has two upsides: it
3243             creates smaller and faster code, and makes is easier to disassociate
3244             embedder-specific things from embedder-neutral things. The small / faster
3245             win is in two places: B3 IR generator only needs offsetOfImportFunction for
3246             the call opcode (when the called index is an import) to know whether the
3247             import is wasm->wasm or wasm->embedder (this isn't known at compile-time
3248             because it's dependent on the import object), this is now done by seeing if
3249             that import function has an associated target instance (only wasm->wasm
3250             does); the other place is wasmBinding which uses offsetOfImportFunction to
3251             figure out the wasm->wasm target instance, and then gets
3252             WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
3253             call. The disassociation comes because the target instance can be
3254             Wasm::Instance once we change what the Context is, and
3255             WasmEntrypointLoadLocation is already embedder-independent. As a next step I
3256             can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
3257             and leave importFunction in as an opaque pointer which is embedder-specific,
3258             and in JS will remain WriteBarrier<JSObject>.
3259           - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
3260             around instead of VM. This is a first step in allowing entry frames which
3261             aren't stored on VM, but which are instead stored in an embedder-specific
3262             location. That change won't really affect JS except through code churn, but
3263             will allow WebAssembly to use some machinery in a generic manner without
3264             having a VM.
3265
3266         * JavaScriptCore.xcodeproj/project.pbxproj:
3267         * Sources.txt:
3268         * bytecode/PolymorphicAccess.cpp:
3269         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
3270         * debugger/Debugger.cpp:
3271         (JSC::Debugger::stepOutOfFunction):
3272         (JSC::Debugger::returnEvent):