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