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