WebAssembly JS API: check and test in-call / out-call values
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-01-03  JF Bastien  <jfbastien@apple.com>
2
3         WebAssembly JS API: check and test in-call / out-call values
4         https://bugs.webkit.org/show_bug.cgi?id=164876
5         <rdar://problem/29844107>
6
7         Reviewed by Saam Barati.
8
9         * wasm/WasmBinding.cpp:
10         (JSC::Wasm::wasmToJs): fix the wasm -> JS call coercions for f32 /
11         f64 which the assotiated tests inadvertently tripped on: the
12         previous code wasn't correctly performing JSValue boxing for
13         "double" values. This change is slightly involved because it
14         requires two scratch registers to materialize the
15         `DoubleEncodeOffset` value. This change therefore reorganizes the
16         code to first generate traps, then handle all integers (freeing
17         all GPRs), and then all the floating-point values.
18         * wasm/js/WebAssemblyFunction.cpp:
19         (JSC::callWebAssemblyFunction): Implement the defined semantics
20         for mismatched arities when JS calls wasm:
21         https://github.com/WebAssembly/design/blob/master/JS.md#exported-function-exotic-objects
22           - i32 is 0, f32 / f64 are NaN.
23           - wasm functions which return "void" are "undefined" in JS.
24
25 2017-01-03  Per Arne Vollan  <pvollan@apple.com>
26
27         [Win] jsc.exe sometimes never exits.
28         https://bugs.webkit.org/show_bug.cgi?id=158073
29
30         Reviewed by Darin Adler.
31
32         On Windows the thread specific destructor is also called when the main thread is exiting.
33         This may lead to the main thread waiting forever for the machine thread lock when exiting,
34         if the sampling profiler thread was terminated by the system while holding the machine
35         thread lock.
36
37         * heap/MachineStackMarker.cpp:
38         (JSC::MachineThreads::removeThread):
39
40 2017-01-02  Julien Brianceau  <jbriance@cisco.com>
41
42         Remove sh4 specific code from JavaScriptCore
43         https://bugs.webkit.org/show_bug.cgi?id=166640
44
45         Reviewed by Filip Pizlo.
46
47         sh4-specific code does not compile for a while (r189884 at least).
48         As nobody seems to have interest in this architecture anymore, let's
49         remove this dead code and thus ease the burden for JSC maintainers.
50
51         * CMakeLists.txt:
52         * JavaScriptCore.xcodeproj/project.pbxproj:
53         * assembler/AbstractMacroAssembler.h:
54         (JSC::AbstractMacroAssembler::Jump::Jump):
55         (JSC::AbstractMacroAssembler::Jump::link):
56         * assembler/MacroAssembler.h:
57         * assembler/MacroAssemblerSH4.h: Removed.
58         * assembler/MaxFrameExtentForSlowPathCall.h:
59         * assembler/SH4Assembler.h: Removed.
60         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
61         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
62         * dfg/DFGSpeculativeJIT.h:
63         (JSC::DFG::SpeculativeJIT::callOperation):
64         * jit/AssemblyHelpers.h:
65         (JSC::AssemblyHelpers::debugCall):
66         * jit/CCallHelpers.h:
67         (JSC::CCallHelpers::setupArgumentsWithExecState):
68         (JSC::CCallHelpers::prepareForTailCallSlow):
69         * jit/CallFrameShuffler.cpp:
70         (JSC::CallFrameShuffler::prepareForTailCall):
71         * jit/ExecutableAllocator.h:
72         * jit/FPRInfo.h:
73         * jit/GPRInfo.h:
74         * jit/JITInlines.h:
75         (JSC::JIT::callOperation):
76         * jit/JITOpcodes32_64.cpp:
77         (JSC::JIT::privateCompileCTINativeCall):
78         * jit/JITOperations.cpp:
79         * jit/RegisterSet.cpp:
80         (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
81         (JSC::RegisterSet::dfgCalleeSaveRegisters):
82         * jit/ThunkGenerators.cpp:
83         (JSC::nativeForGenerator):
84         * llint/LLIntData.cpp:
85         (JSC::LLInt::Data::performAssertions):
86         * llint/LLIntOfflineAsmConfig.h:
87         * llint/LowLevelInterpreter.asm:
88         * llint/LowLevelInterpreter32_64.asm:
89         * offlineasm/backends.rb:
90         * offlineasm/instructions.rb:
91         * offlineasm/sh4.rb: Removed.
92         * yarr/YarrJIT.cpp:
93         (JSC::Yarr::YarrGenerator::generateEnter):
94         (JSC::Yarr::YarrGenerator::generateReturn):
95
96 2017-01-02  JF Bastien  <jfbastien@apple.com>
97
98         WebAssembly: handle and optimize wasm export → wasm import calls
99         https://bugs.webkit.org/show_bug.cgi?id=165282
100
101         Reviewed by Saam Barati.
102
103           - Add a new JSType for WebAssemblyFunction, and use it when creating its
104             structure. This will is used to quickly detect from wasm whether the import
105             call is to another wasm module, or whether it's to JS.
106           - Generate two stubs from the import stub generator: one for wasm->JS and one
107             for wasm -> wasm. This is done at Module time. Which is called will only be
108             known at Instance time, once we've received the import object. We want to
109             avoid codegen at Instance time, so having both around is great.
110           - Restore the WebAssembly global state (VM top Instance, and pinned registers)
111             after call / call_indirect, and in the JS->wasm entry stub.
112           - Pinned registers are now a global thing, not per-Memory, because the wasm ->
113             wasm stubs are generated at Module time where we don't really have enough
114             information to do the right thing (doing so would generate too much code).
115
116         * CMakeLists.txt:
117         * JavaScriptCore.xcodeproj/project.pbxproj:
118         * runtime/JSType.h: add WebAssemblyFunctionType as a JSType
119         * wasm/WasmB3IRGenerator.cpp: significantly rework how calls which
120         could be external work, and how we save / restore global state:
121         VM's top Instance, and pinned registers
122         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
123         (JSC::Wasm::getMemoryBaseAndSize):
124         (JSC::Wasm::restoreWebAssemblyGlobalState):
125         (JSC::Wasm::createJSToWasmWrapper):
126         (JSC::Wasm::parseAndCompile):
127         * wasm/WasmB3IRGenerator.h:
128         * wasm/WasmBinding.cpp:
129         (JSC::Wasm::materializeImportJSCell):
130         (JSC::Wasm::wasmToJS):
131         (JSC::Wasm::wasmToWasm): the main goal of this patch was adding this function
132         (JSC::Wasm::exitStubGenerator):
133         * wasm/WasmBinding.h:
134         * wasm/WasmFormat.h: Get rid of much of the function index space:
135         we already have all of its information elsewhere, and as-is it
136         provides no extra efficiency.
137         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
138         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
139         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
140         * wasm/WasmFunctionParser.h:
141         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
142         * wasm/WasmMemory.cpp: Add some logging.
143         (JSC::Wasm::Memory::dump): this was nice when debugging
144         (JSC::Wasm::Memory::makeString):
145         (JSC::Wasm::Memory::Memory):
146         (JSC::Wasm::Memory::~Memory):
147         (JSC::Wasm::Memory::grow):
148         * wasm/WasmMemory.h: don't use extra indirection, it wasn't
149         needed. Reorder some of the fields which are looked up at runtime
150         so they're more cache-friendly.
151         (JSC::Wasm::Memory::Memory):
152         (JSC::Wasm::Memory::mode):
153         (JSC::Wasm::Memory::offsetOfSize):
154         * wasm/WasmMemoryInformation.cpp: Pinned registers are now a
155         global thing for all of JSC, not a per-Memory thing
156         anymore. wasm->wasm calls are more complex otherwise: they have to
157         figure out how to bridge between the caller and callee's
158         special-snowflake pinning.
159         (JSC::Wasm::PinnedRegisterInfo::get):
160         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
161         (JSC::Wasm::MemoryInformation::MemoryInformation):
162         * wasm/WasmMemoryInformation.h:
163         * wasm/WasmModuleParser.cpp:
164         * wasm/WasmModuleParser.h:
165         * wasm/WasmPageCount.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
166         (JSC::Wasm::PageCount::dump): nice for debugging
167         * wasm/WasmPageCount.h:
168         * wasm/WasmPlan.cpp:
169         (JSC::Wasm::Plan::parseAndValidateModule):
170         (JSC::Wasm::Plan::run):
171         * wasm/WasmPlan.h:
172         (JSC::Wasm::Plan::takeWasmExitStubs):
173         * wasm/WasmSignature.cpp:
174         (JSC::Wasm::Signature::toString):
175         (JSC::Wasm::Signature::dump):
176         * wasm/WasmSignature.h:
177         * wasm/WasmValidate.cpp:
178         (JSC::Wasm::validateFunction):
179         * wasm/WasmValidate.h:
180         * wasm/js/JSWebAssemblyInstance.h:
181         (JSC::JSWebAssemblyInstance::offsetOfTable):
182         (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
183         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
184         * wasm/js/JSWebAssemblyMemory.cpp:
185         (JSC::JSWebAssemblyMemory::create):
186         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
187         (JSC::JSWebAssemblyMemory::buffer):
188         (JSC::JSWebAssemblyMemory::grow):
189         * wasm/js/JSWebAssemblyMemory.h:
190         (JSC::JSWebAssemblyMemory::memory):
191         (JSC::JSWebAssemblyMemory::offsetOfMemory):
192         (JSC::JSWebAssemblyMemory::offsetOfSize):
193         * wasm/js/JSWebAssemblyModule.cpp:
194         (JSC::JSWebAssemblyModule::create):
195         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
196         * wasm/js/JSWebAssemblyModule.h:
197         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
198         (JSC::JSWebAssemblyModule::functionImportCount):
199         * wasm/js/WebAssemblyFunction.cpp:
200         (JSC::callWebAssemblyFunction):
201         (JSC::WebAssemblyFunction::create):
202         (JSC::WebAssemblyFunction::createStructure):
203         (JSC::WebAssemblyFunction::WebAssemblyFunction):
204         (JSC::WebAssemblyFunction::finishCreation):
205         * wasm/js/WebAssemblyFunction.h:
206         (JSC::WebAssemblyFunction::wasmEntrypoint):
207         (JSC::WebAssemblyFunction::offsetOfInstance):
208         (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode):
209         * wasm/js/WebAssemblyInstanceConstructor.cpp:
210         (JSC::constructJSWebAssemblyInstance): always start with a dummy
211         memory, so wasm->wasm calls don't need to null-check
212         * wasm/js/WebAssemblyMemoryConstructor.cpp:
213         (JSC::constructJSWebAssemblyMemory):
214         * wasm/js/WebAssemblyModuleConstructor.cpp:
215         (JSC::WebAssemblyModuleConstructor::createModule):
216         * wasm/js/WebAssemblyModuleRecord.cpp:
217         (JSC::WebAssemblyModuleRecord::link):
218         (JSC::WebAssemblyModuleRecord::evaluate):
219         * wasm/js/WebAssemblyModuleRecord.h:
220
221 2017-01-02  Saam Barati  <sbarati@apple.com>
222
223         WebAssembly: Some loads don't take into account the offset
224         https://bugs.webkit.org/show_bug.cgi?id=166616
225         <rdar://problem/29841541>
226
227         Reviewed by Keith Miller.
228
229         * wasm/WasmB3IRGenerator.cpp:
230         (JSC::Wasm::B3IRGenerator::emitLoadOp):
231
232 2017-01-01  Jeff Miller  <jeffm@apple.com>
233
234         Update user-visible copyright strings to include 2017
235         https://bugs.webkit.org/show_bug.cgi?id=166278
236
237         Reviewed by Dan Bernstein.
238
239         * Info.plist:
240
241 2016-12-28  Saam Barati  <sbarati@apple.com>
242
243         WebAssembly: Don't allow duplicate export names
244         https://bugs.webkit.org/show_bug.cgi?id=166490
245         <rdar://problem/29815000>
246
247         Reviewed by Keith Miller.
248
249         * wasm/WasmModuleParser.cpp:
250
251 2016-12-28  Saam Barati  <sbarati@apple.com>
252
253         Unreviewed. Fix jsc.cpp build error.
254
255         * jsc.cpp:
256         (functionTestWasmModuleFunctions):
257
258 2016-12-28  Saam Barati  <sbarati@apple.com>
259
260         WebAssembly: Implement grow_memory and current_memory
261         https://bugs.webkit.org/show_bug.cgi?id=166448
262         <rdar://problem/29803676>
263
264         Reviewed by Keith Miller.
265
266         This patch implements grow_memory, current_memory, and WebAssembly.prototype.grow.
267         See relevant spec texts here:
268         
269         https://github.com/WebAssembly/design/blob/master/Semantics.md#linear-memory-accesses
270         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymemoryprototypegrow
271         
272         I also fix a couple miscellaneous bugs:
273         
274         1. Data section now understands full init_exprs. 
275         2. parseVarUint1 no longer has a bug where we allow values larger than 1 if
276         their bottom 8 bits are zero.
277         
278         Since the JS API can now grow memory, we need to make calling an import
279         and call_indirect refresh the base memory register and the size registers.
280
281         * jsc.cpp:
282         (functionTestWasmModuleFunctions):
283         * runtime/Options.h:
284         * runtime/VM.h:
285         * wasm/WasmB3IRGenerator.cpp:
286         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
287         (JSC::Wasm::reloadPinnedRegisters):
288         (JSC::Wasm::B3IRGenerator::emitReloadPinnedRegisters):
289         (JSC::Wasm::createJSToWasmWrapper):
290         (JSC::Wasm::parseAndCompile):
291         * wasm/WasmFormat.cpp:
292         (JSC::Wasm::Segment::create):
293         * wasm/WasmFormat.h:
294         (JSC::Wasm::I32InitExpr::I32InitExpr):
295         (JSC::Wasm::I32InitExpr::globalImport):
296         (JSC::Wasm::I32InitExpr::constValue):
297         (JSC::Wasm::I32InitExpr::isConst):
298         (JSC::Wasm::I32InitExpr::isGlobalImport):
299         (JSC::Wasm::I32InitExpr::globalImportIndex):
300         (JSC::Wasm::Segment::byte):
301         (JSC::Wasm::ModuleInformation::importFunctionCount):
302         (JSC::Wasm::ModuleInformation::hasMemory):
303         * wasm/WasmFunctionParser.h:
304         * wasm/WasmMemory.cpp:
305         (JSC::Wasm::Memory::Memory):
306         (JSC::Wasm::Memory::grow):
307         * wasm/WasmMemory.h:
308         (JSC::Wasm::Memory::size):
309         (JSC::Wasm::Memory::sizeInPages):
310         (JSC::Wasm::Memory::offsetOfMemory):
311         (JSC::Wasm::Memory::isValid): Deleted.
312         (JSC::Wasm::Memory::grow): Deleted.
313         * wasm/WasmModuleParser.cpp:
314         (JSC::Wasm::makeI32InitExpr):
315         * wasm/WasmModuleParser.h:
316         * wasm/WasmPageCount.h:
317         (JSC::Wasm::PageCount::bytes):
318         (JSC::Wasm::PageCount::pageCount):
319         (JSC::Wasm::PageCount::fromBytes):
320         (JSC::Wasm::PageCount::operator+):
321         * wasm/WasmParser.h:
322         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
323         * wasm/WasmValidate.cpp:
324         * wasm/js/JSWebAssemblyInstance.h:
325         (JSC::JSWebAssemblyInstance::offsetOfMemory):
326         * wasm/js/JSWebAssemblyMemory.cpp:
327         (JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory):
328         (JSC::JSWebAssemblyMemory::grow):
329         * wasm/js/JSWebAssemblyMemory.h:
330         (JSC::JSWebAssemblyMemory::offsetOfMemory):
331         * wasm/js/JSWebAssemblyModule.h:
332         (JSC::JSWebAssemblyModule::functionImportCount):
333         (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
334         (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
335         (JSC::JSWebAssemblyModule::importCount): Deleted.
336         * wasm/js/WebAssemblyFunction.cpp:
337         (JSC::callWebAssemblyFunction):
338         * wasm/js/WebAssemblyInstanceConstructor.cpp:
339         (JSC::constructJSWebAssemblyInstance):
340         * wasm/js/WebAssemblyMemoryConstructor.cpp:
341         (JSC::constructJSWebAssemblyMemory):
342         * wasm/js/WebAssemblyMemoryPrototype.cpp:
343         (JSC::getMemory):
344         (JSC::webAssemblyMemoryProtoFuncBuffer):
345         (JSC::webAssemblyMemoryProtoFuncGrow):
346         * wasm/js/WebAssemblyModuleRecord.cpp:
347         (JSC::WebAssemblyModuleRecord::link):
348         (JSC::dataSegmentFail):
349         (JSC::WebAssemblyModuleRecord::evaluate):
350         * wasm/wasm.json:
351
352 2016-12-26  Yusuke Suzuki  <utatane.tea@gmail.com>
353
354         Use variadic templates in JSC Parser to clean up
355         https://bugs.webkit.org/show_bug.cgi?id=166482
356
357         Reviewed by Saam Barati.
358
359         * parser/Parser.cpp:
360         (JSC::Parser<LexerType>::logError):
361         * parser/Parser.h:
362
363 2016-12-25  Yusuke Suzuki  <utatane.tea@gmail.com>
364
365         Propagate the source origin as much as possible
366         https://bugs.webkit.org/show_bug.cgi?id=166348
367
368         Reviewed by Darin Adler.
369
370         This patch introduces CallFrame::callerSourceOrigin, SourceOrigin class
371         and SourceProvider::m_sourceOrigin. CallFrame::callerSourceOrigin returns
372         an appropriate SourceOrigin if possible. If we cannot find the appropriate
373         one, we just return null SourceOrigin.
374
375         This paves the way for implementing the module dynamic-import[1].
376         When the import operator is evaluated, it will resolve the module
377         specifier with this propagated source origin of the caller function.
378
379         To support import operator inside the dynamic code generation
380         functions (like `eval`, `new Function`, indirect call to `eval`),
381         we need to propagate the caller's source origin to the generated
382         source code.
383
384         We do not use sourceURL for that purpose. This is because we
385         would like to keep sourceURL for `eval` / `new Function` null.
386         This sourceURL will be used for the stack dump for errors with line/column
387         numbers. Dumping the caller's sourceURL with line/column numbers are
388         meaningless. So we would like to keep it null while we would like
389         to propagate SourceOrigin for dynamic imports.
390
391         [1]: https://github.com/tc39/proposal-dynamic-import
392
393         * API/JSBase.cpp:
394         (JSEvaluateScript):
395         (JSCheckScriptSyntax):
396         * API/JSObjectRef.cpp:
397         (JSObjectMakeFunction):
398         * API/JSScriptRef.cpp:
399         (OpaqueJSScript::create):
400         (OpaqueJSScript::vm):
401         (OpaqueJSScript::OpaqueJSScript):
402         (parseScript):
403         * JavaScriptCore.xcodeproj/project.pbxproj:
404         * Scripts/builtins/builtins_templates.py:
405         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
406         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
407         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
408         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
409         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
410         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
411         * builtins/BuiltinExecutables.cpp:
412         (JSC::BuiltinExecutables::BuiltinExecutables):
413         (JSC::BuiltinExecutables::createDefaultConstructor):
414         * debugger/DebuggerCallFrame.cpp:
415         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
416         * inspector/InjectedScriptManager.cpp:
417         (Inspector::InjectedScriptManager::createInjectedScript):
418         * inspector/JSInjectedScriptHost.cpp:
419         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
420         * inspector/agents/InspectorRuntimeAgent.cpp:
421         (Inspector::InspectorRuntimeAgent::parse):
422         * interpreter/CallFrame.cpp:
423         (JSC::CallFrame::callerSourceOrigin):
424         * interpreter/CallFrame.h:
425         * interpreter/Interpreter.cpp:
426         (JSC::eval):
427         * jsc.cpp:
428         (jscSource):
429         (GlobalObject::finishCreation):
430         (extractDirectoryName):
431         (currentWorkingDirectory):
432         (GlobalObject::moduleLoaderResolve):
433         (functionRunString):
434         (functionLoadString):
435         (functionCallerSourceOrigin):
436         (functionCreateBuiltin):
437         (functionCheckModuleSyntax):
438         (runInteractive):
439         * parser/SourceCode.h:
440         (JSC::makeSource):
441         * parser/SourceProvider.cpp:
442         (JSC::SourceProvider::SourceProvider):
443         * parser/SourceProvider.h:
444         (JSC::SourceProvider::sourceOrigin):
445         (JSC::StringSourceProvider::create):
446         (JSC::StringSourceProvider::StringSourceProvider):
447         (JSC::WebAssemblySourceProvider::create):
448         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
449         * runtime/FunctionConstructor.cpp:
450         (JSC::constructFunction):
451         (JSC::constructFunctionSkippingEvalEnabledCheck):
452         * runtime/FunctionConstructor.h:
453         * runtime/JSGlobalObjectFunctions.cpp:
454         (JSC::globalFuncEval):
455         * runtime/ModuleLoaderPrototype.cpp:
456         (JSC::moduleLoaderPrototypeParseModule):
457         * runtime/ScriptExecutable.h:
458         (JSC::ScriptExecutable::sourceOrigin):
459         * runtime/SourceOrigin.h: Added.
460         (JSC::SourceOrigin::SourceOrigin):
461         (JSC::SourceOrigin::string):
462         (JSC::SourceOrigin::isNull):
463         * tools/FunctionOverrides.cpp:
464         (JSC::initializeOverrideInfo):
465
466 2016-12-24  Caio Lima  <ticaiolima@gmail.com>
467
468         [test262] Fixing mapped arguments object property test case
469         https://bugs.webkit.org/show_bug.cgi?id=159398
470
471         Reviewed by Saam Barati.
472
473         This patch changes GenericArguments' override mechanism to
474         implement corret behavior on ECMAScript test262 suite test cases of
475         mapped arguments object with non-configurable and non-writable
476         property. Also it is ensuring that arguments[i]
477         cannot be deleted when argument "i" is {configurable: false}.
478         
479         The previous implementation is against to the specification for 2 reasons:
480
481         1. Every argument in arguments object are {writable: true} by default
482            (http://www.ecma-international.org/ecma-262/7.0/index.html#sec-createunmappedargumentsobject).
483            It means that we have to stop mapping a defined property index
484            if the new property descriptor contains writable (i.e writable is
485            present) and its value is false (also check
486            https://tc39.github.io/ecma262/#sec-arguments-exotic-objects-defineownproperty-p-desc).
487            Previous implementation considers {writable: false} if writable is
488            not present.
489
490         2. When a property is overriden, "delete" operation is always returning true. However
491            delete operations should follow the specification.
492
493         We created an auxilary boolean array named m_modifiedArgumentsDescriptor
494         to store which arguments[i] descriptor was changed from its default
495         property descriptor. This modification was necessary because m_overrides
496         was responsible to keep this information at the same time
497         of keeping information about arguments mapping. The problem of this apporach was
498         that we needed to call overridesArgument(i) as soon as the ith argument's property
499         descriptor was changed and it stops the argument's mapping as sideffect, producing
500         wrong behavior.
501         To keep tracking arguments mapping status, we renamed DirectArguments::m_overrides to
502         DirectArguments::m_mappedArguments and now we it is responsible to manage if an
503         argument[i] is mapped or not.
504         With these 2 structures, now it is possible to an argument[i] have its property 
505         descriptor modified and don't stop the mapping as soon as it happens. One example
506         of that wrong behavior can be found on arguments-bizarre-behaviour-disable-enumerability
507         test case, that now is fixed by this new mechanism.
508
509         * bytecode/PolymorphicAccess.cpp:
510         (JSC::AccessCase::generateWithGuard):
511         * dfg/DFGSpeculativeJIT.cpp:
512         (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
513         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
514         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
515         * ftl/FTLAbstractHeapRepository.h:
516         * ftl/FTLLowerDFGToB3.cpp:
517         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
518         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
519         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
520         * jit/JITOperations.cpp:
521         (JSC::canAccessArgumentIndexQuickly):
522         * jit/JITPropertyAccess.cpp:
523         (JSC::JIT::emitDirectArgumentsGetByVal):
524         * runtime/DirectArguments.cpp:
525         (JSC::DirectArguments::estimatedSize):
526         (JSC::DirectArguments::visitChildren):
527         (JSC::DirectArguments::overrideThings):
528         (JSC::DirectArguments::overrideThingsIfNecessary):
529         (JSC::DirectArguments::unmapArgument):
530         (JSC::DirectArguments::copyToArguments):
531         (JSC::DirectArguments::overridesSize):
532         (JSC::DirectArguments::overrideArgument): Deleted.
533         * runtime/DirectArguments.h:
534         (JSC::DirectArguments::length):
535         (JSC::DirectArguments::isMappedArgument):
536         (JSC::DirectArguments::isMappedArgumentInDFG):
537         (JSC::DirectArguments::getIndexQuickly):
538         (JSC::DirectArguments::setIndexQuickly):
539         (JSC::DirectArguments::overrodeThings):
540         (JSC::DirectArguments::initModifiedArgumentsDescriptorIfNecessary):
541         (JSC::DirectArguments::setModifiedArgumentDescriptor):
542         (JSC::DirectArguments::isModifiedArgumentDescriptor):
543         (JSC::DirectArguments::offsetOfMappedArguments):
544         (JSC::DirectArguments::offsetOfModifiedArgumentsDescriptor):
545         (JSC::DirectArguments::canAccessIndexQuickly): Deleted.
546         (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
547         (JSC::DirectArguments::offsetOfOverrides): Deleted.
548         * runtime/GenericArguments.h:
549         * runtime/GenericArgumentsInlines.h:
550         (JSC::GenericArguments<Type>::visitChildren):
551         (JSC::GenericArguments<Type>::getOwnPropertySlot):
552         (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
553         (JSC::GenericArguments<Type>::getOwnPropertyNames):
554         (JSC::GenericArguments<Type>::put):
555         (JSC::GenericArguments<Type>::putByIndex):
556         (JSC::GenericArguments<Type>::deleteProperty):
557         (JSC::GenericArguments<Type>::deletePropertyByIndex):
558         (JSC::GenericArguments<Type>::defineOwnProperty):
559         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
560         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptorIfNecessary):
561         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
562         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
563         (JSC::GenericArguments<Type>::copyToArguments):
564         * runtime/ScopedArguments.cpp:
565         (JSC::ScopedArguments::visitChildren):
566         (JSC::ScopedArguments::unmapArgument):
567         (JSC::ScopedArguments::overrideArgument): Deleted.
568         * runtime/ScopedArguments.h:
569         (JSC::ScopedArguments::isMappedArgument):
570         (JSC::ScopedArguments::isMappedArgumentInDFG):
571         (JSC::ScopedArguments::getIndexQuickly):
572         (JSC::ScopedArguments::setIndexQuickly):
573         (JSC::ScopedArguments::initModifiedArgumentsDescriptorIfNecessary):
574         (JSC::ScopedArguments::setModifiedArgumentDescriptor):
575         (JSC::ScopedArguments::isModifiedArgumentDescriptor):
576         (JSC::ScopedArguments::canAccessIndexQuickly): Deleted.
577         (JSC::ScopedArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
578
579 2016-12-23  Mark Lam  <mark.lam@apple.com>
580
581         Using Option::breakOnThrow() shouldn't crash while printing a null CodeBlock.
582         https://bugs.webkit.org/show_bug.cgi?id=166466
583
584         Reviewed by Keith Miller.
585
586         * runtime/VM.cpp:
587         (JSC::VM::throwException):
588
589 2016-12-23  Mark Lam  <mark.lam@apple.com>
590
591         Enhance LLInt tracing to dump the codeBlock signature instead of just a pointer where appropriate.
592         https://bugs.webkit.org/show_bug.cgi?id=166465
593
594         Reviewed by Keith Miller.
595
596         * llint/LLIntSlowPaths.cpp:
597         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
598         (JSC::LLInt::traceFunctionPrologue):
599
600 2016-12-23  Keith Miller  <keith_miller@apple.com>
601
602         WebAssembly: trap on bad division.
603         https://bugs.webkit.org/show_bug.cgi?id=164786
604
605         Reviewed by Mark Lam.
606
607         This patch adds traps for division / modulo by zero and for
608         division by int_min / -1.
609
610         * wasm/WasmB3IRGenerator.cpp:
611         (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
612         * wasm/WasmExceptionType.h:
613         * wasm/WasmPlan.cpp:
614         (JSC::Wasm::Plan::run):
615         * wasm/wasm.json:
616
617 2016-12-23  Mark Lam  <mark.lam@apple.com>
618
619         Fix broken LLINT_SLOW_PATH_TRACING build.
620         https://bugs.webkit.org/show_bug.cgi?id=166463
621
622         Reviewed by Keith Miller.
623
624         * llint/LLIntExceptions.cpp:
625         (JSC::LLInt::returnToThrow):
626         (JSC::LLInt::callToThrow):
627         * runtime/CommonSlowPathsExceptions.cpp:
628         (JSC::CommonSlowPaths::interpreterThrowInCaller):
629
630 2016-12-22  Keith Miller  <keith_miller@apple.com>
631
632         WebAssembly: Make spec-tests/f32.wast.js and spec-tests/f64.wast.js pass
633         https://bugs.webkit.org/show_bug.cgi?id=166447
634
635         Reviewed by Saam Barati.
636
637         We needed to treat -0.0 < 0.0 for floating point min/max. For min,
638         the algorithm works because if a == b then a and b are not NaNs so
639         either they are the same or they are some zero. When we or a and b
640         either we get the same number back or we get -0.0. Similarly for
641         max we use an and and the sign bit gets dropped if one is 0.0 and
642         the other is -0.0, otherwise, we get the same number back.
643
644         * wasm/wasm.json:
645
646 2016-12-22  Saam Barati  <sbarati@apple.com>
647
648         WebAssembly: Make calling Wasm functions that returns or takes an i64 as a parameter an early exception
649         https://bugs.webkit.org/show_bug.cgi?id=166437
650         <rdar://problem/29793949>
651
652         Reviewed by Keith Miller.
653
654         This patch makes it so that we throw an exception before we do
655         anything else if we call a wasm function that either takes an
656         i64 as an argument or returns an i64.
657
658         * wasm/js/WebAssemblyFunction.cpp:
659         (JSC::callWebAssemblyFunction):
660         (JSC::WebAssemblyFunction::WebAssemblyFunction):
661         (JSC::WebAssemblyFunction::call): Deleted.
662         * wasm/js/WebAssemblyFunction.h:
663         (JSC::WebAssemblyFunction::signatureIndex):
664         (JSC::WebAssemblyFunction::jsEntrypoint):
665
666 2016-12-22  Keith Miller  <keith_miller@apple.com>
667
668         Add BitOr for floating points to B3
669         https://bugs.webkit.org/show_bug.cgi?id=166446
670
671         Reviewed by Saam Barati.
672
673         This patch does some slight refactoring to the ARM assembler,
674         which groups all the vector floating point instructions together.
675
676         * assembler/ARM64Assembler.h:
677         (JSC::ARM64Assembler::vand):
678         (JSC::ARM64Assembler::vorr):
679         (JSC::ARM64Assembler::vectorDataProcessingLogical):
680         (JSC::ARM64Assembler::vectorDataProcessing2Source): Deleted.
681         * assembler/MacroAssemblerARM64.h:
682         (JSC::MacroAssemblerARM64::orDouble):
683         (JSC::MacroAssemblerARM64::orFloat):
684         * assembler/MacroAssemblerX86Common.h:
685         (JSC::MacroAssemblerX86Common::orDouble):
686         (JSC::MacroAssemblerX86Common::orFloat):
687         * assembler/X86Assembler.h:
688         (JSC::X86Assembler::orps_rr):
689         * b3/B3ConstDoubleValue.cpp:
690         (JSC::B3::ConstDoubleValue::bitOrConstant):
691         (JSC::B3::ConstDoubleValue::bitXorConstant):
692         * b3/B3ConstDoubleValue.h:
693         * b3/B3ConstFloatValue.cpp:
694         (JSC::B3::ConstFloatValue::bitOrConstant):
695         (JSC::B3::ConstFloatValue::bitXorConstant):
696         * b3/B3ConstFloatValue.h:
697         * b3/B3LowerToAir.cpp:
698         (JSC::B3::Air::LowerToAir::lower):
699         * b3/B3Validate.cpp:
700         * b3/air/AirInstInlines.h:
701         (JSC::B3::Air::Inst::shouldTryAliasingDef):
702         * b3/air/AirOpcode.opcodes:
703         * b3/testb3.cpp:
704         (JSC::B3::bitOrDouble):
705         (JSC::B3::testBitOrArgDouble):
706         (JSC::B3::testBitOrArgsDouble):
707         (JSC::B3::testBitOrArgImmDouble):
708         (JSC::B3::testBitOrImmsDouble):
709         (JSC::B3::bitOrFloat):
710         (JSC::B3::testBitOrArgFloat):
711         (JSC::B3::testBitOrArgsFloat):
712         (JSC::B3::testBitOrArgImmFloat):
713         (JSC::B3::testBitOrImmsFloat):
714         (JSC::B3::testBitOrArgsFloatWithUselessDoubleConversion):
715         (JSC::B3::run):
716
717 2016-12-22  Mark Lam  <mark.lam@apple.com>
718
719         BytecodeGenerator::m_finallyDepth should be unsigned.
720         https://bugs.webkit.org/show_bug.cgi?id=166438
721
722         Reviewed by Saam Barati.
723
724         Also removed FinallyContext::m_finallyDepth because it is not used.
725
726         * bytecompiler/BytecodeGenerator.cpp:
727         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
728         (JSC::BytecodeGenerator::labelScopeDepth):
729         * bytecompiler/BytecodeGenerator.h:
730         (JSC::FinallyContext::FinallyContext):
731         (JSC::FinallyContext::finallyLabel):
732         (JSC::FinallyContext::depth): Deleted.
733
734 2016-12-22  Mark Lam  <mark.lam@apple.com>
735
736         De-duplicate finally blocks.
737         https://bugs.webkit.org/show_bug.cgi?id=160168
738
739         Reviewed by Saam Barati.
740
741         JS execution can arrive at a finally block when there are abrupt completions from
742         its try or catch block.  The abrupt completion types include Break,
743         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
744         (i.e. the case of a try block falling through to the finally block).
745
746         Previously, we enable each of these paths for abrupt completion (except for Throw)
747         to run the finally block code by duplicating the finally block code at each of
748         the sites that trigger those completions.  This patch fixes the implementation so
749         that each of these abrupt completions will set a completionTypeRegister (plus a
750         completionValueRegister for CompletionType::Return) and then jump to the
751         relevant finally blocks, and continue to thread through subsequent outer finally
752         blocks until execution reaches the outermost finally block that the completion
753         type dictates.  We no longer duplicate the finally block code.
754
755         The implementation details:
756         1. We allocate a pair of registers (completionTypeRegister and completionValueRegister)
757            just before entering the outermost try-catch-finally scope.
758
759            On allocating the registers, we initialize the completionTypeRegister to
760            CompletionType::Normal, and set the completionValueRegister to the empty
761            JSValue.
762
763         2. The completionTypeRegister will hold a CompletionType value.  This is how we
764            encode the CompletionType value to be set:
765
766            a. For Normal, Return, and Throw completion types: 
767               - The completionTypeRegister is set to CompletionType::Normal,
768                 CompletionType::Return, and CompletionType::Throw respectively.
769
770            b. For Break and Continue completion types:
771               - The completionTypeRegister is set to a unique jumpID where the jumpID is
772                 computed as:
773
774                 jumpID = CompletionType::NumberOfTypes + bytecodeOffset
775
776                 The bytecodeOffset used here is the bytecodeOffset of the break or continue
777                 statement that triggered this completion.
778
779         3. Each finally block will have 2 entries:
780            a. the catch entry.
781            b. the normal entry.
782
783            The catch entry is recorded in the codeBlock's exception handler table,
784            and can only be jumped to by the VM's exception handling mechanism.
785
786            The normal entry is recorded in a FinallyContext (at bytecode generation time
787            only) and is jumped to when we want enter the finally block due any of the
788            other CompletionTypes.
789
790         4. How each completion type works?
791
792            CompletionType::Normal
793            ======================
794            We normally encounter this when falling through from a try or catch block to
795            the finally block.  
796           
797            For the try block case, since completionTypeRegister is set to Normal by default,
798            there's nothing more that needs to be done.
799
800            For the catch block case, since we entered the catch block with an exception,
801            completionTypeRegister may be set to Throw.  We'll need to set it to Normal
802            before jumping to the finally block's normal entry.
803
804            CompletionType::Break
805            =====================
806            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
807            that we need to service before jumping to the breakTarget.  If we don't, then
808            emit op_jump to the breakTarget as usual.  Otherwise:
809
810            a. we'll register a jumpID and the breakTarget with the FinallyContext for the
811               outermost finally block that we're supposed to run through.
812            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
813               from the innermost to the one for that outermost finally block.
814            c. emit bytecode to set the completionTypeRegister to the jumpID.
815            d. emit bytecode to jump to the normal entry of the innermost finally block.
816
817            Each finally block will take care of cascading to the next outer finally block
818            as needed (see (5) below).
819
820            CompletionType::Continue
821            ========================
822            Since continues and breaks work the same way (i.e. with a jump), we handle this
823            exactly the same way as CompletionType::Break, except that we use the
824            continueTarget instead of the breakTarget.
825
826            CompletionType::Return
827            ======================
828            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
829            at all on the m_controlFlowScopeStack.  If we don't, then emit op_ret as usual.
830            Otherwise:
831
832            a. emit bytecode to set the completionTypeRegister to CompletionType::Return.
833            b. emit bytecode to move the return value into the completionValueRegister.
834            c. emit bytecode to jump to the normal entry of the innermost finally block.
835
836            Each finally block will take care of cascading to the next outer finally block
837            as needed (see (5) below).
838
839            CompletionType::Throw
840            ======================
841            At the catch entry a finally block, we:
842            1. emit an op_catch that stores the caught Exception object in the
843               completionValueRegister.
844            2. emit bytecode to set the completionTypeRegister to CompletionType::Throw.
845            3. Fall through or jump to the finally block's normal entry.
846
847         5. What happens in each finally block?
848            ==================================
849            For details on the finally block's catch entry, see "CompletionType::Throw" in
850            (4) above.
851
852            The finally block's normal entry will:
853            1. restore the scope of the finally block.
854            2. save the completionTypeRegister in a savedCompletionTypeRegister.
855            3. proceed to execute the body of the finally block.
856
857            At the end of the finally block, we will emit bytecode check the
858            savedCompletionTypeRegister for each completion type see emitFinallyCompletion())
859            in the following order:
860           
861            a. Check for CompletionType::Normal
862               ================================
863               If savedCompletionTypeRegister is CompletionType::Normal, jump to the
864               designated normalCompletion label.  We only need this check this finally
865               block also needs to check for Break, Continue, or Return.  If not, the
866               completion type check for CompletionType::Throw below will make this check
867               redundant.
868
869            b. Check for CompletionType::Break and Continue
870               ============================================
871               If the FinallyContext for this block has registered FinallyJumps, we'll
872               check the jumpIDs against the savedCompletionTypeRegister.  If the jumpID
873               matches, jump to the corresponding jumpTarget.
874
875               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
876               greater than the number of registered FinallyJumps, then this means that
877               we have a Break or Continue that needs to be handled by an outer finally
878               block.  In that case, jump to the next outer finally block's normal entry.
879              
880            c. Check for CompletionType::Return
881               ================================
882               If this finally block is not the outermost and the savedCompletionTypeRegister
883               is set to CompletionType::Return, then jump to the next outer finally
884               block's normal entry.
885
886               Otherwise, if this finally block is the outermost and the savedCompletionTypeRegister
887               is set to CompletionType::Return, then execute op_ret and return the value
888               in the completionValueRegister.
889
890            d. CompletionType::Throw
891               =====================
892               If savedCompletionTypeRegister is CompletionType::Throw, then just re-throw the
893               Exception object in the completionValueRegister.
894
895            Detail 1: that we check the savedCompletionTypeRegister (and not the
896            completionTypeRegister).  This is because the finally block may itself contain
897            a try-finally, and this inner try-finally may have trashed the completionTypeRegister.
898            Here's an example:
899
900                try {
901                    return "r1"; // Sets completionTypeRegister to CompletionType::Return;
902                } finally {
903                    // completionTypeRegister is CompletionType::Return here.
904
905                    try {
906                        ... // do stuff.
907                    } finally {
908                        ... // do more stuff.
909                    }
910
911                    // completionTypeRegister may be anything here depending on what
912                    // was executed in the inner try-finally block above.
913
914                    // Hence, finally completion here must be based on a saved copy of the
915                    // completionTypeRegister when we entered this finally block.
916                }
917
918            Detail 2: the finally completion for CompletionType::Throw must always explicitly
919            check if the savedCompletionTypeRegister is CompletionType::Throw before throwing.
920            We cannot imply that it is so from the Throw case being last.  Here's why:
921
922                // completionTypeRegister is CompletionType::Normal here.
923                try {
924                    return "r1"; // Sets completionTypeRegister to CompletionType::Return;
925                } finally {
926                    // completionTypeRegister is CompletionType::Return here.
927
928                    try {
929                        ... // do stuff.  No abrupt completions.
930                    } finally {
931                        // completionTypeRegister is CompletionType::Return here (from the outer try-finally).
932                        // savedCompletionTypeRegister is set to completionTypeRegister (i.e. CompletionType::Return) here.
933
934                        ... // do more stuff.  No abrupt completions.
935
936                        // Unless there's an abrupt completion since entering the outer
937                        // finally block, the savedCompletionTypeRegister will remain set
938                        // to CompletionType::Return.  If we don't explicitly check if the
939                        // savedCompletionTypeRegister is CompletionType::Throw before
940                        // throwing here, we'll end up erroneously throwing "r1".
941                    }
942
943                    ...
944                }
945
946         6. restoreScopeRegister()
947        
948            Since the needed scope objects are always stored in a local, we can restore
949            the scope register by simply moving from that local instead of going through
950            op_get_parent_scope.
951
952         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
953            This makes it easier to keep a pointer to the FinallyContext on that stack,
954            and not have to worry about the vector being realloc'ed due to resizing. 
955
956         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
957         JSC benchmarks.
958
959         Relevant spec references:
960         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
961         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
962
963         * bytecode/HandlerInfo.h:
964         (JSC::HandlerInfoBase::typeName):
965         * bytecompiler/BytecodeGenerator.cpp:
966         (JSC::BytecodeGenerator::generate):
967         (JSC::BytecodeGenerator::BytecodeGenerator):
968         (JSC::BytecodeGenerator::emitReturn):
969         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
970         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
971         (JSC::BytecodeGenerator::allocateAndEmitScope):
972         (JSC::BytecodeGenerator::pushTry):
973         (JSC::BytecodeGenerator::popTry):
974         (JSC::BytecodeGenerator::emitCatch):
975         (JSC::BytecodeGenerator::restoreScopeRegister):
976         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
977         (JSC::BytecodeGenerator::labelScopeDepth):
978         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
979         (JSC::BytecodeGenerator::popLocalControlFlowScope):
980         (JSC::BytecodeGenerator::emitEnumeration):
981         (JSC::BytecodeGenerator::emitIsNumber):
982         (JSC::BytecodeGenerator::emitYield):
983         (JSC::BytecodeGenerator::emitDelegateYield):
984         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
985         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
986         (JSC::BytecodeGenerator::emitFinallyCompletion):
987         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
988         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
989         (JSC::BytecodeGenerator::emitJumpIf):
990         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
991         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
992         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
993         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
994         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
995         * bytecompiler/BytecodeGenerator.h:
996         (JSC::bytecodeOffsetToJumpID):
997         (JSC::FinallyJump::FinallyJump):
998         (JSC::FinallyContext::FinallyContext):
999         (JSC::FinallyContext::outerContext):
1000         (JSC::FinallyContext::finallyLabel):
1001         (JSC::FinallyContext::depth):
1002         (JSC::FinallyContext::numberOfBreaksOrContinues):
1003         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
1004         (JSC::FinallyContext::handlesReturns):
1005         (JSC::FinallyContext::setHandlesReturns):
1006         (JSC::FinallyContext::registerJump):
1007         (JSC::FinallyContext::numberOfJumps):
1008         (JSC::FinallyContext::jumps):
1009         (JSC::ControlFlowScope::ControlFlowScope):
1010         (JSC::ControlFlowScope::isLabelScope):
1011         (JSC::ControlFlowScope::isFinallyScope):
1012         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
1013         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
1014         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
1015         (JSC::BytecodeGenerator::completionTypeRegister):
1016         (JSC::BytecodeGenerator::completionValueRegister):
1017         (JSC::BytecodeGenerator::emitSetCompletionType):
1018         (JSC::BytecodeGenerator::emitSetCompletionValue):
1019         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
1020         * bytecompiler/NodesCodegen.cpp:
1021         (JSC::ContinueNode::emitBytecode):
1022         (JSC::BreakNode::emitBytecode):
1023         (JSC::ReturnNode::emitBytecode):
1024         (JSC::TryNode::emitBytecode):
1025
1026 2016-12-22  Saam Barati  <sbarati@apple.com>
1027
1028         WebAssembly: Make the spec-tests/address.wast.js test pass
1029         https://bugs.webkit.org/show_bug.cgi?id=166429
1030         <rdar://problem/29793220>
1031
1032         Reviewed by Keith Miller.
1033
1034         Right now, provably out of bound loads/stores (given a load/store's constant
1035         offset) are not a validation error. However, we were failing to catch uint32_t
1036         overflows in release builds (we did have a debug assertion). To fix this,
1037         I now detect when uint32_t addition will overflow, and instead of emitting
1038         a normal load/store, I emit code that throws an out of bounds memory exception.
1039
1040         * wasm/WasmB3IRGenerator.cpp:
1041
1042 2016-12-22  Keith Miller  <keith_miller@apple.com>
1043
1044         WebAssembly: The validator should not allow unused stack entries at the end of a block
1045         https://bugs.webkit.org/show_bug.cgi?id=166411
1046
1047         Reviewed by Saam Barati.
1048
1049         This patch also cleans up some of the verbose mode logging.
1050
1051         * wasm/WasmB3IRGenerator.cpp:
1052         (JSC::Wasm::dumpExpressionStack):
1053         (JSC::Wasm::B3IRGenerator::dump):
1054         * wasm/WasmFunctionParser.h:
1055         * wasm/WasmValidate.cpp:
1056         (JSC::Wasm::dumpExpressionStack):
1057         (JSC::Wasm::Validate::dump):
1058
1059 2016-12-22  Saam Barati  <sbarati@apple.com>
1060
1061         WebAssembly: Make the spec-tests/start.wast.js test pass
1062         https://bugs.webkit.org/show_bug.cgi?id=166416
1063         <rdar://problem/29784532>
1064
1065         Reviewed by Yusuke Suzuki.
1066
1067         To make the test run, I had to fix two bugs:
1068         
1069         1. We weren't properly finding the start function. There was code
1070         that would try to find the start function from the list of *exported*
1071         functions. This is wrong; the start function is an index into the
1072         function index space, which is the space for *imports* and *local*
1073         functions. So the code was just wrong in this respect, and I've
1074         fixed it do the right thing. We weren't sure if this was originally
1075         allowed or not in the spec, but it has been decided that it is allowed
1076         and the spec-tests test for it: https://github.com/WebAssembly/design/issues/896
1077         
1078         2. We were emitting a breakpoint for Unreachable. Instead of crashing,
1079         this opcode needs to throw an exception when executing.
1080
1081         * wasm/WasmB3IRGenerator.cpp:
1082         * wasm/WasmExceptionType.h:
1083         * wasm/js/WebAssemblyModuleRecord.cpp:
1084         (JSC::WebAssemblyModuleRecord::link):
1085         (JSC::WebAssemblyModuleRecord::evaluate):
1086         * wasm/js/WebAssemblyModuleRecord.h:
1087
1088 2016-12-21  Keith Miller  <keith_miller@apple.com>
1089
1090         WebAssembly: Fix decode floating point constants in unreachable code
1091         https://bugs.webkit.org/show_bug.cgi?id=166400
1092
1093         Reviewed by Saam Barati.
1094
1095         We decoded these as variable length but they should be fixed length.
1096
1097         * wasm/WasmFunctionParser.h:
1098
1099 2016-12-21  Keith Miller  <keith_miller@apple.com>
1100
1101         WebAssembly: Allow br, br_if, and br_table to act as a return
1102         https://bugs.webkit.org/show_bug.cgi?id=166393
1103
1104         Reviewed by Saam Barati.
1105
1106         This patch allows br, br_if, and br_table to treat branching to
1107         the size of the control stack to act as a return. This change was
1108         made by adding a new block type to the wasm function parser,
1109         TopLevel. Adding this new block eliminates a lot of the special
1110         case code we had in the parser previously. The only special case
1111         we need is when the end opcode is parsed from the top level.  The
1112         B3 IR generator needs to automatically emit a return at that
1113         point.
1114
1115         Also, this patch adds the function number to validation errors
1116         in the function parser. The current error message is not helpful
1117         otherwise.
1118
1119         * wasm/WasmB3IRGenerator.cpp:
1120         (JSC::Wasm::B3IRGenerator::ControlData::dump):
1121         (JSC::Wasm::B3IRGenerator::addTopLevel):
1122         * wasm/WasmFunctionParser.h:
1123         * wasm/WasmPlan.cpp:
1124         (JSC::Wasm::Plan::parseAndValidateModule):
1125         (JSC::Wasm::Plan::run):
1126         * wasm/WasmValidate.cpp:
1127         (JSC::Wasm::Validate::ControlData::dump):
1128         (JSC::Wasm::Validate::Validate):
1129         (JSC::Wasm::Validate::addTopLevel):
1130         (JSC::Wasm::validateFunction):
1131
1132 2016-12-21  JF Bastien  <jfbastien@apple.com>
1133
1134         WebAssembly JS API: cleanup & pass VM around to {Compile/Runtime}Error
1135         https://bugs.webkit.org/show_bug.cgi?id=166295
1136         <rdar://problem/29762017>
1137
1138         Reviewed by Mark Lam.
1139
1140         Rename the create* functions, and pass VM around, as suggested for
1141         LinkError in #165805.
1142
1143         At the same time, use the default source appender when
1144         constructing these error types, which gives a nice map back to the
1145         original source as part of the error message. This is clearer when
1146         using the current frame, so add that as well.
1147
1148         * jit/ThunkGenerators.cpp:
1149         (JSC::throwExceptionFromWasmThunkGenerator):
1150         * wasm/js/JSWebAssemblyCompileError.cpp:
1151         (JSC::JSWebAssemblyCompileError::create):
1152         (JSC::createJSWebAssemblyCompileError):
1153         (JSC::createWebAssemblyCompileError): Deleted.
1154         * wasm/js/JSWebAssemblyCompileError.h:
1155         (JSC::JSWebAssemblyCompileError::create):
1156         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1157         (JSC::JSWebAssemblyRuntimeError::create):
1158         * wasm/js/JSWebAssemblyRuntimeError.h:
1159         (JSC::JSWebAssemblyRuntimeError::create):
1160         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1161         (JSC::constructJSWebAssemblyCompileError):
1162         * wasm/js/WebAssemblyModuleConstructor.cpp:
1163         (JSC::WebAssemblyModuleConstructor::createModule):
1164         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1165         (JSC::constructJSWebAssemblyRuntimeError):
1166
1167 2016-12-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1168
1169         [ES6] Fix modules document in features.json
1170         https://bugs.webkit.org/show_bug.cgi?id=166313
1171
1172         Reviewed by Saam Barati.
1173
1174         * features.json:
1175
1176 2016-12-20  Taras Tsugrii  <ttsugrii@fb.com>
1177
1178         Fix undefined behavior caused by macro expansion producing 'defined'
1179         https://bugs.webkit.org/show_bug.cgi?id=166047
1180
1181         Reviewed by Darin Adler.
1182
1183         * API/JSBase.h:
1184
1185 2016-12-20  Keith Miller  <keith_miller@apple.com>
1186
1187         Add support for global
1188         https://bugs.webkit.org/show_bug.cgi?id=165171
1189
1190         Reviewed by Filip Pizlo.
1191
1192         This patch adds spport for the global property on the global object.
1193         The global property spec is in stage three and is quite simple.
1194         For reference: http://tc39.github.io/proposal-global/
1195
1196         * runtime/JSGlobalObject.cpp:
1197
1198 2016-12-20  Saam Barati  <sbarati@apple.com>
1199
1200         WebAssembly: We should compile wasm functions in parallel
1201         https://bugs.webkit.org/show_bug.cgi?id=165993
1202
1203         Reviewed by Keith Miller.
1204
1205         This patch adds a very simple parallel compiler for Wasm code.
1206         This patch speeds up compiling the Unity headless benchmark by
1207         slightly more than 4x on my MBP. To make this safe, I perform
1208         all linking on the main thread. I also had to change some code
1209         inside Wasmb3IRGenerator to be thread safe.
1210
1211         * b3/air/AirCustom.h:
1212         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1213         * b3/air/AirGenerationContext.h:
1214         * wasm/WasmB3IRGenerator.cpp:
1215         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1216         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
1217         (JSC::Wasm::createJSToWasmWrapper):
1218         (JSC::Wasm::parseAndCompile):
1219         * wasm/WasmB3IRGenerator.h:
1220         * wasm/WasmCallingConvention.h:
1221         (JSC::Wasm::CallingConvention::setupFrameInPrologue):
1222         * wasm/WasmPlan.cpp:
1223         (JSC::Wasm::Plan::parseAndValidateModule):
1224         (JSC::Wasm::Plan::run):
1225         * wasm/WasmPlan.h:
1226
1227 2016-12-20  Brent Fulgham  <bfulgham@apple.com>
1228
1229         Address some style problems found by static analysis
1230         https://bugs.webkit.org/show_bug.cgi?id=165975
1231
1232         Reviewed by Alex Christensen.
1233
1234         Correct the const-correctness of functions that are implemented using stricter
1235         const declarations.
1236
1237         * inspector/agents/InspectorDebuggerAgent.h:
1238         * inspector/agents/InspectorHeapAgent.cpp:
1239         * inspector/agents/InspectorHeapAgent.h:
1240         * inspector/agents/InspectorRuntimeAgent.h:
1241         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1242         * inspector/agents/InspectorScriptProfilerAgent.h:
1243         * inspector/scripts/codegen/cpp_generator.py:
1244         (cpp_type_for_unchecked_formal_in_parameter): Update to match const declarations of
1245         implementation files.
1246         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1247         Rebaselined results for "const Ptr* const" syntax.
1248
1249 2016-12-20  JF Bastien  <jfbastien@apple.com>
1250
1251         WebAssembly: construct 32-bit encodedJSValue properly
1252         https://bugs.webkit.org/show_bug.cgi?id=166199
1253
1254         Reviewed by Mark Lam.
1255
1256         Constructing an encodedJSValue using `{ }` yields the wrong value
1257         on 32-bit platforms. WebAssembly doesn't currently target 32-bit
1258         platforms, but we may as well get it right.
1259
1260         * wasm/JSWebAssembly.cpp:
1261         (JSC::webAssemblyCompileFunc):
1262         (JSC::webAssemblyValidateFunc):
1263         * wasm/js/JSWebAssemblyHelpers.h:
1264         (JSC::toNonWrappingUint32):
1265         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1266         (JSC::constructJSWebAssemblyCompileError):
1267         * wasm/js/WebAssemblyFunction.cpp:
1268         (JSC::callWebAssemblyFunction):
1269         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1270         (JSC::constructJSWebAssemblyInstance):
1271         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1272         (JSC::constructJSWebAssemblyMemory):
1273         * wasm/js/WebAssemblyModuleConstructor.cpp:
1274         (JSC::constructJSWebAssemblyModule):
1275         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1276         (JSC::constructJSWebAssemblyRuntimeError):
1277         * wasm/js/WebAssemblyTableConstructor.cpp:
1278         (JSC::constructJSWebAssemblyTable):
1279         * wasm/js/WebAssemblyTablePrototype.cpp:
1280         (JSC::webAssemblyTableProtoFuncLength):
1281         (JSC::webAssemblyTableProtoFuncGrow):
1282         (JSC::webAssemblyTableProtoFuncGet):
1283         (JSC::webAssemblyTableProtoFuncSet):
1284
1285 2016-12-20  Dean Jackson  <dino@apple.com>
1286
1287         Remove INDIE_UI
1288         https://bugs.webkit.org/show_bug.cgi?id=165881
1289         <rdar://problem/29672532>
1290
1291         Reviewed by Simon Fraser.
1292
1293         The Indie UI work has been discontinued.
1294
1295         * Configurations/FeatureDefines.xcconfig:
1296
1297 2016-12-20  JF Bastien  <jfbastien@apple.com>
1298
1299         WebAssembly API: implement WebAssembly.LinkError
1300         https://bugs.webkit.org/show_bug.cgi?id=165805
1301         <rdar://problem/29747874>
1302
1303         Reviewed by Mark Lam.
1304
1305         As described here: https://github.com/WebAssembly/design/pull/901
1306         Some TypeError and RangeError are now converted to WebAssembly.LinkError.
1307
1308         * CMakeLists.txt: add files
1309         * DerivedSources.make: add autoget .lut.h files
1310         * JavaScriptCore.xcodeproj/project.pbxproj: add files
1311         * builtins/BuiltinNames.h: new name LinkError
1312         * runtime/JSGlobalObject.h: auto-register LinkError using existing macro magic
1313         * wasm/JSWebAssembly.h: make the new includes available
1314         * wasm/js/JSWebAssemblyLinkError.cpp: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.cpp.
1315         (JSC::JSWebAssemblyLinkError::create):
1316         (JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError):
1317         (JSC::createWebAssemblyLinkError):
1318         * wasm/js/JSWebAssemblyLinkError.h: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.h.
1319         (JSC::JSWebAssemblyLinkError::create):
1320         * wasm/js/WebAssemblyInstanceConstructor.cpp: update as per spec change
1321         (JSC::constructJSWebAssemblyInstance):
1322         * wasm/js/WebAssemblyLinkErrorConstructor.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.cpp.
1323         (JSC::constructJSWebAssemblyLinkError):
1324         (JSC::callJSWebAssemblyLinkError):
1325         (JSC::WebAssemblyLinkErrorConstructor::create):
1326         (JSC::WebAssemblyLinkErrorConstructor::createStructure):
1327         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
1328         (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
1329         (JSC::WebAssemblyLinkErrorConstructor::getConstructData):
1330         (JSC::WebAssemblyLinkErrorConstructor::getCallData):
1331         * wasm/js/WebAssemblyLinkErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.h.
1332         * wasm/js/WebAssemblyLinkErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.cpp.
1333         (JSC::WebAssemblyLinkErrorPrototype::create):
1334         (JSC::WebAssemblyLinkErrorPrototype::createStructure):
1335         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1336         (JSC::WebAssemblyLinkErrorPrototype::WebAssemblyLinkErrorPrototype):
1337         * wasm/js/WebAssemblyLinkErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.h.
1338         * wasm/js/WebAssemblyModuleRecord.cpp: update as per spec change
1339         (JSC::dataSegmentFail):
1340         (JSC::WebAssemblyModuleRecord::evaluate):
1341
1342 2016-12-20  JF Bastien  <jfbastien@apple.com>
1343
1344         WebAssembly: unique function signatures
1345         https://bugs.webkit.org/show_bug.cgi?id=165957
1346         <rdar://problem/29735737>
1347
1348         Reviewed by Saam Barati.
1349
1350         Signatures in a Module's Type section can be duplicated, we
1351         therefore need to unique them so that call_indirect only needs to
1352         do a single integer compare to check that a callee's Signature is
1353         the same as the Signature declared at the call site. Without
1354         uniquing we'd either trap when duplicate Signatures are used, or
1355         we'd need to do multiple comparisons. This patch makes that narrow
1356         usecase function correctly.
1357
1358         There's further complication when calling from wasm to
1359         wasm, in which case the Signatures must also match. Such
1360         cross-instance calls will be improved in bug #165282, but this
1361         patch sets the groundwork for it:
1362
1363         - Signatures are now owned by SignatureInformation which lives on
1364           VM, and is shared by all Modules.
1365         - When parsing a Module, a Signature is created for every Type
1366           entry, and then uniqued by SignatureInformation's adopt
1367           method. Duplicate Signatures are dropped and the previous
1368           SignatureIndex is returned, new Signatures are adopted and a new
1369           SignatureIndex is created.
1370         - The SignatureIndex values are monotonic. 0 is used to represent
1371           invalid indices, which trap. This can only occur through Table.
1372         - SignatureInformation is used while generating code to map a
1373           SignatureIndex back to the Signature* when return / argument
1374           information is needed. This is a simple lookup into a Vector. It
1375           isn't used at runtime.
1376         - These Signatures live forever on VM because the bookkeeping
1377           likely isn't worth it. We may want to empty things out if all
1378           Modules die, this is tracked in bug #166037.
1379         - We can further improve things by bit-packing SignatureIndex with
1380           Code*, which is tracked by bug #165511.
1381
1382         * CMakeLists.txt:
1383         * JavaScriptCore.xcodeproj/project.pbxproj:
1384         * runtime/VM.h: wasm signatures are uniqued here, but aren't accessed frequently (only during parsing) so indirection is fine
1385         * wasm/WasmB3IRGenerator.cpp: use SignatureIndex instead of Signature* when appropriate, and when still using Signature* do so with its new API
1386         (JSC::Wasm::createJSToWasmWrapper):
1387         (JSC::Wasm::parseAndCompile):
1388         * wasm/WasmBinding.cpp:
1389         (JSC::Wasm::importStubGenerator): use SignatureIndex
1390         * wasm/WasmBinding.h:
1391         * wasm/WasmCallingConvention.h:
1392         (JSC::Wasm::CallingConvention::loadArguments):
1393         * wasm/WasmFormat.cpp: drive-by move of alloc/free functions to the implementation file, allows the .h file to drop an FastMalloc.h
1394         (JSC::Wasm::Segment::create):
1395         (JSC::Wasm::Segment::destroy):
1396         (JSC::Wasm::Segment::createPtr):
1397         * wasm/WasmFormat.h: move Signature to its own file
1398         (JSC::Wasm::CallableFunction::CallableFunction):
1399         * wasm/WasmFunctionParser.h:
1400         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
1401         * wasm/WasmModuleParser.cpp:
1402         * wasm/WasmModuleParser.h:
1403         (JSC::Wasm::ModuleParser::ModuleParser):
1404         * wasm/WasmParser.h:
1405         (JSC::Wasm::Parser<SuccessType>::Parser):
1406         * wasm/WasmPlan.cpp:
1407         (JSC::Wasm::Plan::parseAndValidateModule):
1408         (JSC::Wasm::Plan::run):
1409         * wasm/WasmSignature.cpp: Added.
1410         (JSC::Wasm::Signature::dump):
1411         (JSC::Wasm::Signature::hash):
1412         (JSC::Wasm::Signature::create):
1413         (JSC::Wasm::Signature::createInvalid):
1414         (JSC::Wasm::Signature::destroy):
1415         (JSC::Wasm::SignatureInformation::~SignatureInformation):
1416         (JSC::Wasm::SignatureInformation::adopt):
1417         (JSC::Wasm::SignatureInformation::get):
1418         * wasm/WasmSignature.h: Added.
1419         (JSC::Wasm::Signature::Signature):
1420         (JSC::Wasm::Signature::storage):
1421         (JSC::Wasm::Signature::allocatedSize):
1422         (JSC::Wasm::Signature::returnType):
1423         (JSC::Wasm::Signature::returnCount):
1424         (JSC::Wasm::Signature::argumentCount):
1425         (JSC::Wasm::Signature::argument):
1426         (JSC::Wasm::Signature::operator==):
1427         (JSC::Wasm::SignatureHash::empty):
1428         (JSC::Wasm::SignatureHash::deleted):
1429         (JSC::Wasm::SignatureHash::SignatureHash):
1430         (JSC::Wasm::SignatureHash::operator==):
1431         (JSC::Wasm::SignatureHash::equal):
1432         (JSC::Wasm::SignatureHash::hash):
1433         (JSC::Wasm::SignatureHash::isHashTableDeletedValue):
1434         * wasm/WasmValidate.cpp:
1435         (JSC::Wasm::validateFunction):
1436         * wasm/WasmValidate.h:
1437         * wasm/js/JSWebAssemblyInstance.cpp:
1438         (JSC::JSWebAssemblyInstance::create):
1439         * wasm/js/JSWebAssemblyModule.h:
1440         (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
1441         * wasm/js/JSWebAssemblyTable.cpp:
1442         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1443         (JSC::JSWebAssemblyTable::clearFunction):
1444         (JSC::JSWebAssemblyTable::setFunction):
1445         * wasm/js/WebAssemblyFunction.cpp:
1446         (JSC::callWebAssemblyFunction):
1447         (JSC::WebAssemblyFunction::call):
1448         (JSC::WebAssemblyFunction::create):
1449         (JSC::WebAssemblyFunction::WebAssemblyFunction):
1450         (JSC::WebAssemblyFunction::finishCreation):
1451         * wasm/js/WebAssemblyFunction.h:
1452         (JSC::WebAssemblyFunction::signatureIndex):
1453         * wasm/js/WebAssemblyModuleRecord.cpp:
1454         (JSC::WebAssemblyModuleRecord::link):
1455         (JSC::WebAssemblyModuleRecord::evaluate):
1456
1457 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
1458
1459         Modernize for loops in JSC
1460         https://bugs.webkit.org/show_bug.cgi?id=166060
1461
1462         Reviewed by Yusuke Suzuki.
1463
1464         * API/JSCallbackObject.h:
1465         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
1466         * bytecode/CodeBlock.cpp:
1467         (JSC::CodeBlock::dumpBytecode):
1468         (JSC::CodeBlock::propagateTransitions):
1469         (JSC::CodeBlock::stronglyVisitStrongReferences):
1470         (JSC::CodeBlock::stronglyVisitWeakReferences):
1471         (JSC::CodeBlock::jettison):
1472         (JSC::CodeBlock::getArrayProfile):
1473         (JSC::CodeBlock::tallyFrequentExitSites):
1474         (JSC::CodeBlock::nameForRegister):
1475         * bytecompiler/BytecodeGenerator.cpp:
1476         (JSC::BytecodeGenerator::generate):
1477         (JSC::BytecodeGenerator::BytecodeGenerator):
1478         * bytecompiler/NodesCodegen.cpp:
1479         (JSC::ObjectPatternNode::bindValue):
1480         * debugger/Debugger.cpp:
1481         (JSC::Debugger::applyBreakpoints):
1482         * dfg/DFGCPSRethreadingPhase.cpp:
1483         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1484         * dfg/DFGClobberSet.cpp:
1485         (JSC::DFG::ClobberSet::setOf):
1486         * dfg/DFGDesiredIdentifiers.cpp:
1487         (JSC::DFG::DesiredIdentifiers::reallyAdd):
1488         * dfg/DFGGraph.cpp:
1489         (JSC::DFG::Graph::visitChildren):
1490         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1491         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1492         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1493         * dfg/DFGJITCompiler.cpp:
1494         (JSC::DFG::JITCompiler::link):
1495         * dfg/DFGLICMPhase.cpp:
1496         (JSC::DFG::LICMPhase::run):
1497         * dfg/DFGMaximalFlushInsertionPhase.cpp:
1498         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
1499         * dfg/DFGPutStackSinkingPhase.cpp:
1500         * dfg/DFGSpeculativeJIT.cpp:
1501         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1502         (JSC::DFG::SpeculativeJIT::linkBranches):
1503         * dfg/DFGStructureRegistrationPhase.cpp:
1504         (JSC::DFG::StructureRegistrationPhase::run):
1505         * dfg/DFGTypeCheckHoistingPhase.cpp:
1506         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1507         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1508         * dfg/DFGValidate.cpp:
1509         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
1510         (JSC::DFG::VirtualRegisterAllocationPhase::run):
1511         * heap/HeapVerifier.cpp:
1512         (JSC::trimDeadObjectsFromList):
1513         (JSC::HeapVerifier::trimDeadObjects):
1514         * heap/LiveObjectList.cpp:
1515         (JSC::LiveObjectList::findObject):
1516         * heap/MarkedAllocator.cpp:
1517         (JSC::MarkedAllocator::isPagedOut):
1518         * inspector/ScriptCallStack.cpp:
1519         (Inspector::ScriptCallStack::firstNonNativeCallFrame):
1520         * jit/JIT.cpp:
1521         (JSC::JIT::link):
1522         * parser/VariableEnvironment.cpp:
1523         (JSC::VariableEnvironment::markAllVariablesAsCaptured):
1524         (JSC::VariableEnvironment::hasCapturedVariables):
1525         * runtime/FunctionHasExecutedCache.cpp:
1526         (JSC::FunctionHasExecutedCache::hasExecutedAtOffset):
1527         (JSC::FunctionHasExecutedCache::getFunctionRanges):
1528         * runtime/JSPropertyNameEnumerator.cpp:
1529         (JSC::JSPropertyNameEnumerator::visitChildren):
1530         * runtime/TypeProfiler.cpp:
1531         (JSC::TypeProfiler::findLocation):
1532         * runtime/TypeSet.cpp:
1533         (JSC::TypeSet::addTypeInformation):
1534         (JSC::TypeSet::dumpTypes):
1535         * runtime/VM.cpp:
1536         (JSC::VM::gatherConservativeRoots):
1537         * runtime/WeakMapData.cpp:
1538         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
1539         (JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
1540         * tools/ProfileTreeNode.h:
1541         (JSC::ProfileTreeNode::dumpInternal):
1542         * yarr/YarrInterpreter.cpp:
1543         (JSC::Yarr::ByteCompiler::emitDisjunction):
1544
1545 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
1546
1547         __cpuid() requires <intrin.h> to be included
1548         https://bugs.webkit.org/show_bug.cgi?id=166051
1549
1550         Reviewed by Yusuke Suzuki.
1551
1552         * assembler/MacroAssemblerX86Common.h:
1553
1554 2016-12-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1555
1556         [ES6] Enable ES6 Modules
1557         https://bugs.webkit.org/show_bug.cgi?id=165849
1558
1559         Reviewed by Geoffrey Garen.
1560
1561         * features.json:
1562
1563 2016-12-19  Mark Lam  <mark.lam@apple.com>
1564
1565         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 2: Rollout r209952.
1566         https://bugs.webkit.org/show_bug.cgi?id=166049
1567
1568         Not reviewed.
1569
1570         * bytecode/HandlerInfo.h:
1571         (JSC::HandlerInfoBase::typeName):
1572         * bytecompiler/BytecodeGenerator.cpp:
1573         (JSC::BytecodeGenerator::generate):
1574         (JSC::BytecodeGenerator::BytecodeGenerator):
1575         (JSC::BytecodeGenerator::emitReturn):
1576         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1577         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
1578         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
1579         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
1580         (JSC::BytecodeGenerator::emitComplexPopScopes):
1581         (JSC::BytecodeGenerator::emitPopScopes):
1582         (JSC::BytecodeGenerator::pushTry):
1583         (JSC::BytecodeGenerator::popTryAndEmitCatch):
1584         (JSC::BytecodeGenerator::labelScopeDepth):
1585         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
1586         (JSC::BytecodeGenerator::popLocalControlFlowScope):
1587         (JSC::BytecodeGenerator::emitEnumeration):
1588         (JSC::BytecodeGenerator::emitYield):
1589         (JSC::BytecodeGenerator::emitDelegateYield):
1590         (JSC::BytecodeGenerator::popTry): Deleted.
1591         (JSC::BytecodeGenerator::emitCatch): Deleted.
1592         (JSC::BytecodeGenerator::restoreScopeRegister): Deleted.
1593         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex): Deleted.
1594         (JSC::BytecodeGenerator::emitIsNumber): Deleted.
1595         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded): Deleted.
1596         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded): Deleted.
1597         (JSC::BytecodeGenerator::emitFinallyCompletion): Deleted.
1598         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
1599         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
1600         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
1601         * bytecompiler/BytecodeGenerator.h:
1602         (JSC::BytecodeGenerator::isInFinallyBlock):
1603         (JSC::FinallyJump::FinallyJump): Deleted.
1604         (JSC::FinallyContext::FinallyContext): Deleted.
1605         (JSC::FinallyContext::outerContext): Deleted.
1606         (JSC::FinallyContext::finallyLabel): Deleted.
1607         (JSC::FinallyContext::depth): Deleted.
1608         (JSC::FinallyContext::numberOfBreaksOrContinues): Deleted.
1609         (JSC::FinallyContext::incNumberOfBreaksOrContinues): Deleted.
1610         (JSC::FinallyContext::handlesReturns): Deleted.
1611         (JSC::FinallyContext::setHandlesReturns): Deleted.
1612         (JSC::FinallyContext::registerJump): Deleted.
1613         (JSC::FinallyContext::numberOfJumps): Deleted.
1614         (JSC::FinallyContext::jumps): Deleted.
1615         (JSC::ControlFlowScope::ControlFlowScope): Deleted.
1616         (JSC::ControlFlowScope::isLabelScope): Deleted.
1617         (JSC::ControlFlowScope::isFinallyScope): Deleted.
1618         (JSC::BytecodeGenerator::currentLexicalScopeIndex): Deleted.
1619         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
1620         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
1621         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
1622         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
1623         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
1624         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
1625         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
1626         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
1627         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
1628         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
1629         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
1630         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
1631         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
1632         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
1633         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
1634         * bytecompiler/NodesCodegen.cpp:
1635         (JSC::ContinueNode::emitBytecode):
1636         (JSC::BreakNode::emitBytecode):
1637         (JSC::ReturnNode::emitBytecode):
1638         (JSC::TryNode::emitBytecode):
1639
1640 2016-12-19  Mark Lam  <mark.lam@apple.com>
1641
1642         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 1: Rollout r209974.
1643         https://bugs.webkit.org/show_bug.cgi?id=166049
1644
1645         Not reviewed.
1646
1647         * bytecompiler/BytecodeGenerator.cpp:
1648         (JSC::BytecodeGenerator::emitEnumeration):
1649         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1650         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1651         (JSC::BytecodeGenerator::emitFinallyCompletion):
1652         (JSC::BytecodeGenerator::allocateFinallyRegisters):
1653         (JSC::BytecodeGenerator::releaseFinallyRegisters):
1654         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
1655         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
1656         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
1657         (JSC::BytecodeGenerator::emitJumpIfCompletionType): Deleted.
1658         * bytecompiler/BytecodeGenerator.h:
1659         (JSC::FinallyJump::FinallyJump):
1660         (JSC::FinallyContext::registerJump):
1661         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
1662         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
1663         (JSC::BytecodeGenerator::finallyActionRegister):
1664         (JSC::BytecodeGenerator::finallyReturnValueRegister):
1665         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
1666         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
1667         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
1668         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
1669         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
1670         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
1671         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
1672         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
1673         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
1674         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
1675         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
1676         (JSC::bytecodeOffsetToJumpID): Deleted.
1677         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
1678         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
1679         (JSC::BytecodeGenerator::completionTypeRegister): Deleted.
1680         (JSC::BytecodeGenerator::completionValueRegister): Deleted.
1681         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
1682         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
1683         * bytecompiler/NodesCodegen.cpp:
1684         (JSC::TryNode::emitBytecode):
1685
1686 2016-12-19  Joseph Pecoraro  <pecoraro@apple.com>
1687
1688         Web Inspector: Assertion seen in InspectorDebuggerAgent::refAsyncCallData with Inspector open
1689         https://bugs.webkit.org/show_bug.cgi?id=166034
1690         <rdar://problem/29554366>
1691
1692         Reviewed by Brian Burg.
1693
1694         * inspector/agents/InspectorDebuggerAgent.cpp:
1695         (Inspector::InspectorDebuggerAgent::refAsyncCallData):
1696         Remove assertion. This assert can happen if the currently executing callback
1697         was just explicitly cancelled by script. Existing code already handles if
1698         no async data was found for the given identifier.
1699
1700 2016-12-18  Saam Barati  <sbarati@apple.com>
1701
1702         WebAssembly: Implement the WebAssembly.compile and WebAssembly.validate
1703         https://bugs.webkit.org/show_bug.cgi?id=165936
1704
1705         Reviewed by Mark Lam.
1706
1707         The APIs are documented here:
1708         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile
1709         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyvalidate
1710
1711         * wasm/JSWebAssembly.cpp:
1712         (JSC::webAssemblyCompileFunc):
1713         (JSC::webAssemblyValidateFunc):
1714         (JSC::JSWebAssembly::finishCreation):
1715         * wasm/WasmPlan.cpp:
1716         (JSC::Wasm::Plan::parseAndValidateModule):
1717         (JSC::Wasm::Plan::run):
1718         * wasm/WasmPlan.h:
1719         * wasm/js/JSWebAssemblyHelpers.h:
1720         (JSC::getWasmBufferFromValue):
1721         * wasm/js/WebAssemblyModuleConstructor.cpp:
1722         (JSC::constructJSWebAssemblyModule):
1723         (JSC::callJSWebAssemblyModule):
1724         (JSC::WebAssemblyModuleConstructor::createModule):
1725         * wasm/js/WebAssemblyModuleConstructor.h:
1726
1727 2016-12-18  Mark Lam  <mark.lam@apple.com>
1728
1729         Rename finallyActionRegister to completionTypeRegister and only store int JSValues in it.
1730         https://bugs.webkit.org/show_bug.cgi?id=165979
1731
1732         Reviewed by Saam Barati.
1733
1734         This patch makes it so that we only store int JSValues in the finallyActionRegister
1735         thereby making type prediction on this register more successful for JITs.  In so
1736         doing, we are able to get some additional benefits:
1737
1738         1. Renamed the following:
1739            FinallyRegistersScope => CompletionRecordScope
1740            finallyActionRegister => completionTypeRegister
1741            finallyReturnValueRegister => completionValueRegister
1742
1743            These new names are more in line with the ES spec, which describes these
1744            values as the completion record and its type and value properties.
1745            https://tc39.github.io/ecma262/#sec-completion-record-specification-type
1746
1747         2. We now think of the Break and Continue jumpIDs as encodings of CompletionType
1748            (in our implementation of completion type).  As a result, we only need one of
1749            each of the emitter methods for getting, setting, and compare-and-jump on the
1750            completion type.  The code using these methods also reads much clearer now.  
1751
1752         3. Finally blocks' op_catch should now always pop the caught Exception object into
1753            the completionValueRegister instead of the completionTypeRegister (formerly
1754            finallyActionRegister). 
1755
1756         Also removed the restoreScopeRegister() call in the IteratorClose catch block
1757         because that is an implementation specific synthesized catch block, and we
1758         can guarantee that it never needs to resolve any symbols from the scope.  Hence,
1759         there is no need to restore the scope register.
1760
1761         * bytecompiler/BytecodeGenerator.cpp:
1762         (JSC::BytecodeGenerator::emitEnumeration):
1763         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1764         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1765         (JSC::BytecodeGenerator::emitFinallyCompletion):
1766         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
1767         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
1768         (JSC::BytecodeGenerator::emitJumpIfCompletionType):
1769         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
1770         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
1771         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
1772         * bytecompiler/BytecodeGenerator.h:
1773         (JSC::bytecodeOffsetToJumpID):
1774         (JSC::FinallyJump::FinallyJump):
1775         (JSC::FinallyContext::registerJump):
1776         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
1777         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
1778         (JSC::BytecodeGenerator::completionTypeRegister):
1779         (JSC::BytecodeGenerator::completionValueRegister):
1780         (JSC::BytecodeGenerator::emitSetCompletionType):
1781         (JSC::BytecodeGenerator::emitSetCompletionValue):
1782         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
1783         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
1784         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
1785         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
1786         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
1787         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
1788         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
1789         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
1790         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
1791         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
1792         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
1793         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
1794         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
1795         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
1796         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
1797         * bytecompiler/NodesCodegen.cpp:
1798         (JSC::TryNode::emitBytecode):
1799
1800 2016-12-17  Saam Barati  <sbarati@apple.com>
1801
1802         WebAssembly: WasmB3IRGenerator uses WarmAny as a ValueRep but expects the incoming value to be a register
1803         https://bugs.webkit.org/show_bug.cgi?id=165989
1804
1805         Reviewed by Mark Lam.
1806
1807         The input should be constrained to a register to match what
1808         the patchpoint code expects.
1809
1810         * wasm/WasmB3IRGenerator.cpp:
1811
1812 2016-12-17  Saam Barati  <sbarati@apple.com>
1813
1814         WebAssembly: Change a RELEASE_ASSERT_NOT_REACHED to a jit.breakpoint() for now to allow us to run some wasm benchmarks
1815         https://bugs.webkit.org/show_bug.cgi?id=165990
1816
1817         Reviewed by Mark Lam.
1818
1819         * wasm/WasmBinding.cpp:
1820         (JSC::Wasm::importStubGenerator):
1821
1822 2016-12-16  Joseph Pecoraro  <pecoraro@apple.com>
1823
1824         JSContext Inspector: Avoid some possible exceptions inspecting a JSContext
1825         https://bugs.webkit.org/show_bug.cgi?id=165986
1826         <rdar://problem/29551379>
1827
1828         Reviewed by Matt Baker.
1829
1830         * inspector/InjectedScriptSource.js:
1831         (InjectedScript.prototype.processProperties):
1832         Prefer String.prototype.endsWith now that it is available.
1833
1834         (InjectedScript.prototype._describe):
1835         Prefer Function.prototype.toString for converting functions to String.
1836         Previously we were doing String(f) which would to Symbol.toPrimitive
1837         conversion which seems unnecessary here.
1838
1839 2016-12-16  Michael Catanzaro  <mcatanzaro@igalia.com>
1840
1841         Unreviewed, fix GCC 6 build failure after r209952
1842
1843         Return false, not nullptr, in function returning bool.
1844
1845         * bytecompiler/BytecodeGenerator.cpp:
1846         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1847
1848 2016-12-16  Saam Barati  <sbarati@apple.com>
1849
1850         WebAssembly: We still have some incorrect parsing productions inside unreachable code
1851         https://bugs.webkit.org/show_bug.cgi?id=165981
1852
1853         Reviewed by Keith Miller.
1854
1855         This hardens our parsing for CallIndirect and Loop/Block/If to be exactly like their reachable variant.
1856         
1857         It also fixes a more nefarious bug in which we were decoding an extra varuint32
1858         for Br/BrIf inside unreachable code.
1859
1860         * wasm/WasmFunctionParser.h:
1861
1862 2016-12-16  Filip Pizlo  <fpizlo@apple.com>
1863
1864         CellState should have members with accurate names
1865         https://bugs.webkit.org/show_bug.cgi?id=165969
1866
1867         Reviewed by Mark Lam.
1868         
1869         This once again renames the members in CellState. I wanted to convey the following
1870         pieces of information in the names:
1871         
1872         - What does the state mean for Generational GC?
1873         - What does the state mean for Concurrent GC?
1874         - Does the state guarantee what it means, or is there some contingency?
1875         
1876         The names I came up with are:
1877         
1878         PossiblyOldOrBlack: An object in this state may be old, or may be black, depending on
1879             other things. If the mark bit is set then the object is either black or being
1880             blackened as we speak. It's going to survive the GC, so it will be old, but may be
1881             new now. In between GCs, objects in this state are definitely old. If the mark bit
1882             is not set, then the object is actually old and white.
1883         
1884         DefinitelyNewAndWhite: The object was just allocated so it is white (not marked) and
1885             new.
1886         
1887         DefinitelyGrey: The object is definitely grey - it will be rescanned in the future. It
1888             may be new or old depending on other things.
1889
1890         * heap/CellState.h:
1891         * heap/Heap.cpp:
1892         (JSC::Heap::addToRememberedSet):
1893         (JSC::Heap::writeBarrierSlowPath):
1894         * heap/SlotVisitor.cpp:
1895         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
1896         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
1897         (JSC::SlotVisitor::appendToMarkStack):
1898         (JSC::SlotVisitor::visitChildren):
1899         * runtime/JSCellInlines.h:
1900         (JSC::JSCell::JSCell):
1901         * runtime/StructureIDBlob.h:
1902         (JSC::StructureIDBlob::StructureIDBlob):
1903
1904 2016-12-16  Saam Barati  <sbarati@apple.com>
1905
1906         B3::DoubleToFloatReduction will accidentally convince itself it converted a Phi from Double to Float and then convert uses of that Phi into a use of FloatToDouble(@Phi)
1907         https://bugs.webkit.org/show_bug.cgi?id=165946
1908
1909         Reviewed by Keith Miller.
1910
1911         This was happening because the phase will convert some Phi nodes
1912         from Double to Float. However, one place that did this conversion
1913         forgot to first check if the Phi was already a Float. If it's already
1914         a Float, a later part of the phase will be buggy if the phase claims that it has
1915         converted it from Double->Float. The reason is that at the end of the
1916         phase, we'll look for all uses of former Double Phi nodes and make them
1917         be a use of ConvertFloatToDouble on the Phi, instead of a use of the Phi itself.
1918         This is clearly wrong if the Phi were Float to begin with (and
1919         therefore, the uses were Float uses to begin with).
1920
1921         * b3/B3ReduceDoubleToFloat.cpp:
1922         * b3/testb3.cpp:
1923         (JSC::B3::testReduceFloatToDoubleValidates):
1924         (JSC::B3::run):
1925
1926 2016-12-16  Mark Lam  <mark.lam@apple.com>
1927
1928         De-duplicate finally blocks.
1929         https://bugs.webkit.org/show_bug.cgi?id=160168
1930
1931         Reviewed by Keith Miller.
1932
1933         JS execution can arrive at a finally block when there are abrupt completions from
1934         its try or catch block.  The abrupt completion types include Break,
1935         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
1936         (i.e. the case of a try block falling through to the finally block).
1937
1938         Previously, we enable each of these paths for abrupt completion (except for Throw)
1939         to run the finally block code by duplicating the finally block code at each of
1940         the sites that trigger those completions.  This patch fixes the implementation so
1941         that each of these abrupt completions will set a finallyActionRegister (plus a
1942         finallyReturnValueRegister for CompletionType::Return) and then jump to the
1943         relevant finally blocks, and continue to thread through subsequent outer finally
1944         blocks until execution reaches the outermost finally block that the completion
1945         type dictates.  We no longer duplicate the finally block code.
1946
1947         The implementation details:
1948         1. We allocate a pair of finallyActionRegister and finallyReturnValueRegister
1949            just before entering the outermost try-catch-finally scope.
1950
1951            On allocating the registers, we set them to the empty JSValue.  This serves
1952            to set the completion type to CompletionType::Normal (see (2) below).
1953
1954         2. The finallyActionRegister serves 2 purpose:
1955            a. indicates the CompletionType that triggered entry into the finally block.
1956
1957               This is how we encode the completion type in the finallyActionRegister:
1958               1. CompletionType::Normal
1959                  - finallyActionRegister is set to the empty JSValue.
1960               2. CompletionType::Break
1961                  - finallyActionRegister is set to the int jumpID for the site of the break statement.
1962               3. CompletionType::Continue
1963                  - finallyActionRegister is set to the int jumpID for the site of the continue statement.
1964               4. CompletionType::Return
1965                  - finallyActionRegister is set to CompletionType::Return as an int JSValue.
1966                  - finallyReturnValueRegister is set to the value to be returned. 
1967               5. CompletionType::Throw
1968                  - finallyActionRegister is set to the exception object that was caught by the finally block.
1969
1970               Hence, if the finallyActionRegister can either be:
1971               1. empty i.e. we're handling CompletionType::Normal.
1972               2. an int JSValue i.e. we're handling CompletionType::Break, Continue, or Return.
1973               3. an object i.e. we're handling CompletionType::Throw.
1974
1975            b. stores the exception caught in the finally block if we're handing
1976               CompletionType::Throw.
1977
1978         3. Each finally block will have 2 entries:
1979            a. the entry via throw.
1980            b. the normal entry.
1981
1982            The entry via throw is recorded in the codeBlock's exception table, and can
1983            only be jumped to by the VM's exception handling mechanism.
1984
1985            The normal entry is recorded in a FinallyContext (at bytecode generation time
1986            only) and is jumped to when we want enter the finally block due any of the
1987            other CompletionTypes.
1988
1989         4. CompletionType::Normal
1990            ======================
1991            We encounter this when falling through from a try or catch block to the finally block.  
1992            
1993            For the try block case, since finallyActionRegister is set to Normal by default,
1994            there's nothing more that needs to be done.
1995
1996            For the catch block case, since we entered the catch block with an exception,
1997            finallyActionRegister may be set to Throw.  We'll need to set it to Normal
1998            before jumping to the finally block's normal entry.
1999
2000            CompletionType::Break
2001            =====================
2002            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
2003            that we need to service before jumping to the breakTarget.  If we do, then:
2004            a. we'll register a jumpID along with the breakTarget with the outermost FinallyContext.
2005            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
2006               from the innermost to the outermost.
2007            c. instead of emitting bytecode to jump to the breakTarget, we:
2008               1. emit bytecode to set finallyActionRegister to the jumpID.
2009               b. emit bytecode to jump to the normal entry of the innermost finally block.
2010
2011            Each finally block will take care of cascading to the next outer finally block
2012            as needed (see (5) below).
2013
2014            CompletionType::Continue
2015            ========================
2016            Since continues and breaks work the same way (i.e. with a jump), we handle this
2017            exactly the same way as CompletionType::Break, except that we use the
2018            continueTarget instead of the breakTarget.
2019
2020            CompletionType::Return
2021            ======================
2022            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
2023            at all on the m_controlFlowScopeStack.
2024
2025            If so, then instead of emitting op_ret, we:
2026               1. emit bytecode to set finallyActionRegister to the CompletionType::Return.
2027               1. emit bytecode to move the return value into finallyReturnValueRegister.
2028               2. emit bytecode to jump to the normal entry of the innermost finally block.
2029
2030            Each finally block will take care of cascading to the next outer finally block
2031            as needed (see (5) below).
2032
2033            CompletionType::Throw
2034            ======================
2035            The op_catch of a finally block will always store the caught exception object
2036            in the finallyActionRegister.  This means we're handling CompletionType::Throw
2037            (see (2) above).
2038
2039         5. What happens in each finally block?
2040            ==================================
2041            Only the finally block's entry via throw will have an op_catch that catches the
2042            pending exception (and stores it in the finallyActionRegister).  This throw
2043            entry then falls through to the normal entry.
2044
2045            The finally block's normal entry will restore the scope of the finally block
2046            and proceed to execute its code.
2047
2048            At the end of the finally block (see emitFinallyCompletion()), the finally
2049            block will check the finallyActionRegister for each completion type in the
2050            following order:
2051            
2052            a. CompletionType::Normal: jump to the code after the finally block as
2053               designated by a normalCompletion label.
2054
2055            b. CompletionType::Break and Continue:
2056               If the FinallyContext for this block has registered FinallyJumps, we'll
2057               check for the jumpIDs against the finallyActionRegister.  If the jumpID
2058               matches, jump to the corresponding jumpTarget.
2059
2060               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
2061               greater than the number of registered FinallyJumps, then this means that
2062               we have a Break or Continue that needs to be handled by an outer finally
2063               block.  In that case, jump to the outer finally block's normal entry.
2064               
2065            c. CompletionType::Return:
2066               If this finally block is not the outermost and finallyActionRegister contains
2067               CompletionType::Return, then jump to the outer finally block's normal entry.
2068
2069               Otherwise, if this finally block is the outermost and finallyActionRegister
2070               contains CompletionType::Return, then execute op_ret and return the value
2071               in finallyReturnValueRegister.
2072
2073            d. CompletionType::Throw:
2074               If we're not handling any of the above cases, then just throw the
2075               finallyActionRegister which contains the exception to re-throw.
2076
2077         6. restoreScopeRegister()
2078         
2079            Since the needed scope objects are always stored in a local, we can restore
2080            the scope register by simply moving from that local instead of going through
2081            op_get_parent_scope.
2082
2083         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
2084            This makes it easier to keep a pointer to the FinallyContext on that stack,
2085            and not have to worry about the vector being realloc'ed due to resizing. 
2086
2087         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
2088         JSC benchmarks.
2089
2090         Relevant spec references:
2091         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
2092         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
2093
2094         * bytecode/HandlerInfo.h:
2095         (JSC::HandlerInfoBase::typeName):
2096         * bytecompiler/BytecodeGenerator.cpp:
2097         (JSC::BytecodeGenerator::generate):
2098         (JSC::BytecodeGenerator::BytecodeGenerator):
2099         (JSC::BytecodeGenerator::emitReturn):
2100         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2101         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
2102         (JSC::BytecodeGenerator::allocateAndEmitScope):
2103         (JSC::BytecodeGenerator::pushTry):
2104         (JSC::BytecodeGenerator::popTry):
2105         (JSC::BytecodeGenerator::emitCatch):
2106         (JSC::BytecodeGenerator::restoreScopeRegister):
2107         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
2108         (JSC::BytecodeGenerator::labelScopeDepth):
2109         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
2110         (JSC::BytecodeGenerator::popLocalControlFlowScope):
2111         (JSC::BytecodeGenerator::emitEnumeration):
2112         (JSC::BytecodeGenerator::emitIsNumber):
2113         (JSC::BytecodeGenerator::emitYield):
2114         (JSC::BytecodeGenerator::emitDelegateYield):
2115         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
2116         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
2117         (JSC::BytecodeGenerator::emitFinallyCompletion):
2118         (JSC::BytecodeGenerator::allocateFinallyRegisters):
2119         (JSC::BytecodeGenerator::releaseFinallyRegisters):
2120         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
2121         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
2122         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
2123         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
2124         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
2125         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
2126         * bytecompiler/BytecodeGenerator.h:
2127         (JSC::FinallyJump::FinallyJump):
2128         (JSC::FinallyContext::FinallyContext):
2129         (JSC::FinallyContext::outerContext):
2130         (JSC::FinallyContext::finallyLabel):
2131         (JSC::FinallyContext::depth):
2132         (JSC::FinallyContext::numberOfBreaksOrContinues):
2133         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
2134         (JSC::FinallyContext::handlesReturns):
2135         (JSC::FinallyContext::setHandlesReturns):
2136         (JSC::FinallyContext::registerJump):
2137         (JSC::FinallyContext::numberOfJumps):
2138         (JSC::FinallyContext::jumps):
2139         (JSC::ControlFlowScope::ControlFlowScope):
2140         (JSC::ControlFlowScope::isLabelScope):
2141         (JSC::ControlFlowScope::isFinallyScope):
2142         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
2143         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
2144         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
2145         (JSC::BytecodeGenerator::finallyActionRegister):
2146         (JSC::BytecodeGenerator::finallyReturnValueRegister):
2147         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
2148         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
2149         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
2150         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
2151         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
2152         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
2153         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
2154         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
2155         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
2156         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
2157         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
2158         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
2159         * bytecompiler/NodesCodegen.cpp:
2160         (JSC::ContinueNode::emitBytecode):
2161         (JSC::BreakNode::emitBytecode):
2162         (JSC::ReturnNode::emitBytecode):
2163         (JSC::TryNode::emitBytecode):
2164
2165 2016-12-16  Keith Miller  <keith_miller@apple.com>
2166
2167         Add missing cases to parseUnreachableExpression and cleanup FunctionParser
2168         https://bugs.webkit.org/show_bug.cgi?id=165966
2169
2170         Reviewed by Saam Barati.
2171
2172         This patch adds a number of missing cases to the Wasm FunctionParser's unreachable
2173         code decoder. It also, removes unneeded OpType namespaces where they were not
2174         needed and has the unary / binary macros cover all the cases rather than
2175         just the simple cases.
2176
2177         * wasm/WasmFunctionParser.h:
2178
2179 2016-12-16  Mark Lam  <mark.lam@apple.com>
2180
2181         Add predecessor info to dumps from JSC_dumpBytecodeLivenessResults=true.
2182         https://bugs.webkit.org/show_bug.cgi?id=165958
2183
2184         Reviewed by Saam Barati.
2185
2186         Also:
2187         1. refactored the code to use a common lambda function to dump FastBitVectors.
2188         2. list successors by their block index instead of pointers.
2189
2190         * bytecode/BytecodeLivenessAnalysis.cpp:
2191         (JSC::BytecodeLivenessAnalysis::dumpResults):
2192
2193 2016-12-16  Saam Barati  <sbarati@apple.com>
2194
2195         WebAssembly: WasmB3IRGenerator should throw exceptions instead of crash
2196         https://bugs.webkit.org/show_bug.cgi?id=165834
2197
2198         Reviewed by Keith Miller.
2199
2200         This patch generalizes how we throw exceptions in the Wasm::B3IRGenerator.
2201         There are still places where we need to throw exceptions and we don't, but
2202         this patch removes most of those places inside the IR generator. There are
2203         still a few places we need to throw exceptions inside the IR generator, like
2204         div/mod by 0. Those will be done in a separate patch. Also, there are
2205         still some stubs we need to throw exceptions from; those will also be
2206         done in a separate patch.
2207
2208         All exceptions thrown from Wasm share a common stub. The ABI for the stub
2209         is to move the Wasm::ExceptionType into argGPR1 and jump to the stub.
2210         The stub will then throw an exception with an error message tailored
2211         to the particular Wasm::ExceptionType failure.
2212
2213         This patch also refactors B3::Compilation. Before, B3::Compilation(VM, Procedure)
2214         constructor would compile a B3 function. This patch makes B3::Compilation a simple 
2215         tuple that keeps the necessary bits of B3 function alive in order to be runnable.
2216         There is a new function that actually does the compilation for you. It is:
2217         Compilation B3::compile(VM&, Procedure&)
2218         The reason for this change is that I'm now using B3::Compilation(CodeRef, OpaqueByproducts)
2219         constructor in Wasm code. It is weird to have a class both have a
2220         constructor that instantiates the tuple, and another that performs the
2221         compilation and then instantiates the tuple. It's more straight
2222         forward if Compilation's job wasn't to actually do the compilation
2223         but just to hold the necessary bits to keep a compiled B3 alive.
2224
2225         * CMakeLists.txt:
2226         * JavaScriptCore.xcodeproj/project.pbxproj:
2227         * b3/B3Compilation.cpp:
2228         (JSC::B3::Compilation::Compilation):
2229         * b3/B3Compilation.h:
2230         * b3/B3Compile.cpp: Added.
2231         (JSC::B3::compile):
2232         * b3/B3Compile.h: Added.
2233         * b3/testb3.cpp:
2234         (JSC::B3::compile):
2235         * jit/ThunkGenerators.cpp:
2236         (JSC::throwExceptionFromWasmThunkGenerator):
2237         * jit/ThunkGenerators.h:
2238         * wasm/WasmB3IRGenerator.cpp:
2239         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2240         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
2241         (JSC::Wasm::createJSToWasmWrapper):
2242         (JSC::Wasm::parseAndCompile):
2243         * wasm/WasmExceptionType.h: Added.
2244         (JSC::Wasm::errorMessageForExceptionType):
2245
2246 2016-12-16  Keith Miller  <keith_miller@apple.com>
2247
2248         i64.eqz should use an Int64 zero
2249         https://bugs.webkit.org/show_bug.cgi?id=165942
2250
2251         Reviewed by Mark Lam.
2252
2253         This patch fixes i64.eqz, which was using an Int32 zero
2254         for the comparison previously. This patch also, adds
2255         printing opcodes names in verbose mode.
2256
2257         * wasm/WasmFunctionParser.h:
2258         * wasm/generateWasmOpsHeader.py:
2259         * wasm/wasm.json:
2260
2261 2016-12-15  Darin Adler  <darin@apple.com>
2262
2263         Use asString instead of toWTFString, toString, or getString when we already checked isString
2264         https://bugs.webkit.org/show_bug.cgi?id=165895
2265
2266         Reviewed by Yusuke Suzuki.
2267
2268         Once we have called isString, we should always use asString and value rather than using
2269         functions that have to deal with non-JSString objects. This leads to slightly fewer branches,
2270         slightly less reference count churn, since the string is stored right inside the JSString,
2271         and obviates the need for exception handling.
2272
2273         * bindings/ScriptValue.cpp:
2274         (Inspector::jsToInspectorValue): Use asString/value instead of getString.
2275         * dfg/DFGOperations.cpp:
2276         (JSC::DFG::operationMapHash): Call jsMapHash with its new arguments.
2277         * inspector/JSInjectedScriptHost.cpp:
2278         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Use asString/value instead
2279         of toWTFString.
2280         * inspector/JSJavaScriptCallFrame.cpp:
2281         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Ditto.
2282         * inspector/agents/InspectorHeapAgent.cpp:
2283         (Inspector::InspectorHeapAgent::getPreview): Use asString/tryGetValue, instead of the
2284         peculiar getString(nullptr) that was here before.
2285         * jsc.cpp:
2286         (functionGetGetterSetter): Use asString/toIdentifier instead of the much less efficient
2287         toWTFString/Identifier::fromString.
2288         (functionIsRope): Use asString instead of jsCast<JSString*>; same thing, but we should
2289         prefer the asString function, since it exists.
2290         (functionFindTypeForExpression): Use asString/value instead of getString.
2291         (functionHasBasicBlockExecuted): Ditto.
2292         (functionBasicBlockExecutionCount): Ditto.
2293         (functionCreateBuiltin): Use asString/value instead of toWTFString and removed
2294         unneeded RETURN_IF_EXCEPTION.
2295         (valueWithTypeOfWasmValue): Use asString instead of jsCast<String*>.
2296         (box): Ditto.
2297         * runtime/DateConstructor.cpp:
2298         (JSC::constructDate): Use asString/values instead of getString.
2299         * runtime/ExceptionHelpers.cpp:
2300         (JSC::errorDescriptionForValue): Tweaked formatting.
2301
2302         * runtime/HashMapImpl.h:
2303         (JSC::jsMapHash): Changed this function to use asString/value.
2304
2305         * runtime/JSCJSValue.cpp:
2306         (JSC::JSValue::dumpInContextAssumingStructure): Use asString instead of
2307         jsCast<JSString*>.
2308         (JSC::JSValue::dumpForBacktrace): Ditto.
2309         * runtime/JSCJSValueInlines.h:
2310         (JSC::toPreferredPrimitiveType): Ditto.
2311
2312         * runtime/JSGlobalObjectFunctions.cpp:
2313         (JSC::globalFuncEval): Use asString/value instead of toWTFString.
2314
2315         * runtime/JSString.cpp:
2316         (JSC::JSString::destroy): Streamlined by removing local variable.
2317         (JSC::JSString::estimatedSize): Use asString instead of jsCast<JSString*>.
2318         (JSC::JSString::visitChildren): Ditto.
2319         (JSC::JSString::toThis): Ditto.
2320         * runtime/JSString.h:
2321         (JSC::JSValue::toString): Ditto.
2322         (JSC::JSValue::toStringOrNull): Ditto.
2323         * runtime/NumberPrototype.cpp:
2324         (JSC::numberProtoFuncValueOf): Ditto.
2325         * runtime/ObjectPrototype.cpp:
2326         (JSC::objectProtoFuncToString): Ditto.
2327         * runtime/StringPrototype.cpp:
2328         (JSC::stringProtoFuncRepeatCharacter): Ditto.
2329         (JSC::stringProtoFuncSubstr): Ditto.
2330         (JSC::builtinStringSubstrInternal): Simplified assertion by removing local variable.
2331
2332 2016-12-15  Keith Miller  <keith_miller@apple.com>
2333
2334         Fix validation of non-void if blocks with no else
2335         https://bugs.webkit.org/show_bug.cgi?id=165938
2336
2337         Reviewed by Saam Barati.
2338
2339         We should not have been allowing non-void if-blocks that don't
2340         have an else. Since this causes a value to be placed on the
2341         stack that only appears under some control flow and not another.
2342
2343         * wasm/WasmValidate.cpp:
2344
2345 2016-12-15  Filip Pizlo  <fpizlo@apple.com>
2346
2347         Get rid of HeapRootVisitor and make SlotVisitor less painful to use
2348         https://bugs.webkit.org/show_bug.cgi?id=165911
2349
2350         Reviewed by Geoffrey Garen.
2351         
2352         Previously we had two ways of adding a raw pointer to the GC's mark stack:
2353         
2354         - SlotVisitor::appendUnbarrieredXYZ() methods
2355         - HeapRootVisitor::visit() methods
2356         
2357         HeapRootVisitor existed only to prevent you from calling its non-WriteBarrier<> methods
2358         unless you had permission. But SlotVisitor would let you do it anyway, because that was
2359         a lot more practical.
2360         
2361         I think that we should just have one way to do it. This removes HeapRootVisitor. It
2362         also renames appendUnbarrieredXYZ to appendUnbarriered, and it removes the use of extra
2363         indirection (so you now pass const WriteBarrier<>& instead of WriteBarrier<>*).
2364
2365         * API/JSCallbackObject.h:
2366         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
2367         * JavaScriptCore.xcodeproj/project.pbxproj:
2368         * Scripts/builtins/builtins_templates.py:
2369         * bytecode/CodeBlock.cpp:
2370         (JSC::CodeBlock::visitWeakly):
2371         (JSC::CodeBlock::visitChildren):
2372         (JSC::CodeBlock::propagateTransitions):
2373         (JSC::CodeBlock::determineLiveness):
2374         (JSC::CodeBlock::visitOSRExitTargets):
2375         (JSC::CodeBlock::stronglyVisitStrongReferences):
2376         (JSC::CodeBlock::stronglyVisitWeakReferences):
2377         * bytecode/DirectEvalCodeCache.cpp:
2378         (JSC::DirectEvalCodeCache::visitAggregate):
2379         * bytecode/InternalFunctionAllocationProfile.h:
2380         (JSC::InternalFunctionAllocationProfile::visitAggregate):
2381         * bytecode/ObjectAllocationProfile.h:
2382         (JSC::ObjectAllocationProfile::visitAggregate):
2383         * bytecode/PolymorphicAccess.cpp:
2384         (JSC::AccessCase::propagateTransitions):
2385         * bytecode/UnlinkedCodeBlock.cpp:
2386         (JSC::UnlinkedCodeBlock::visitChildren):
2387         * bytecode/UnlinkedFunctionExecutable.cpp:
2388         (JSC::UnlinkedFunctionExecutable::visitChildren):
2389         * debugger/DebuggerScope.cpp:
2390         (JSC::DebuggerScope::visitChildren):
2391         * dfg/DFGDesiredTransitions.cpp:
2392         (JSC::DFG::DesiredTransition::visitChildren):
2393         * dfg/DFGDesiredWeakReferences.cpp:
2394         (JSC::DFG::DesiredWeakReferences::visitChildren):
2395         * dfg/DFGGraph.cpp:
2396         (JSC::DFG::Graph::visitChildren):
2397         * dfg/DFGPlan.cpp:
2398         (JSC::DFG::Plan::markCodeBlocks):
2399         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2400         * heap/HandleSet.cpp:
2401         (JSC::HandleSet::visitStrongHandles):
2402         * heap/HandleSet.h:
2403         * heap/HandleStack.cpp:
2404         (JSC::HandleStack::visit):
2405         * heap/HandleStack.h:
2406         * heap/Heap.cpp:
2407         (JSC::Heap::markToFixpoint):
2408         * heap/Heap.h:
2409         * heap/HeapRootVisitor.h: Removed.
2410         * heap/LargeAllocation.cpp:
2411         (JSC::LargeAllocation::visitWeakSet):
2412         * heap/LargeAllocation.h:
2413         * heap/MarkedBlock.h:
2414         (JSC::MarkedBlock::Handle::visitWeakSet):
2415         * heap/MarkedSpace.cpp:
2416         (JSC::MarkedSpace::visitWeakSets):
2417         * heap/MarkedSpace.h:
2418         * heap/SlotVisitor.cpp:
2419         (JSC::SlotVisitor::appendUnbarriered):
2420         * heap/SlotVisitor.h:
2421         * heap/SlotVisitorInlines.h:
2422         (JSC::SlotVisitor::appendUnbarriered):
2423         (JSC::SlotVisitor::append):
2424         (JSC::SlotVisitor::appendHidden):
2425         (JSC::SlotVisitor::appendValues):
2426         (JSC::SlotVisitor::appendValuesHidden):
2427         (JSC::SlotVisitor::appendUnbarrieredPointer): Deleted.
2428         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer): Deleted.
2429         (JSC::SlotVisitor::appendUnbarrieredValue): Deleted.
2430         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Deleted.
2431         (JSC::SlotVisitor::appendUnbarrieredWeak): Deleted.
2432         * heap/WeakBlock.cpp:
2433         (JSC::WeakBlock::specializedVisit):
2434         (JSC::WeakBlock::visit):
2435         * heap/WeakBlock.h:
2436         * heap/WeakSet.h:
2437         (JSC::WeakSet::visit):
2438         * interpreter/ShadowChicken.cpp:
2439         (JSC::ShadowChicken::visitChildren):
2440         * jit/GCAwareJITStubRoutine.cpp:
2441         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
2442         * jit/PolymorphicCallStubRoutine.cpp:
2443         (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
2444         * jsc.cpp:
2445         (WTF::Element::visitChildren):
2446         (WTF::ImpureGetter::visitChildren):
2447         (WTF::SimpleObject::visitChildren):
2448         * runtime/AbstractModuleRecord.cpp:
2449         (JSC::AbstractModuleRecord::visitChildren):
2450         * runtime/ArgList.cpp:
2451         (JSC::MarkedArgumentBuffer::markLists):
2452         * runtime/ArgList.h:
2453         * runtime/ClonedArguments.cpp:
2454         (JSC::ClonedArguments::visitChildren):
2455         * runtime/DirectArguments.cpp:
2456         (JSC::DirectArguments::visitChildren):
2457         * runtime/EvalExecutable.cpp:
2458         (JSC::EvalExecutable::visitChildren):
2459         * runtime/Exception.cpp:
2460         (JSC::Exception::visitChildren):
2461         * runtime/FunctionExecutable.cpp:
2462         (JSC::FunctionExecutable::visitChildren):
2463         * runtime/FunctionRareData.cpp:
2464         (JSC::FunctionRareData::visitChildren):
2465         * runtime/GetterSetter.cpp:
2466         (JSC::GetterSetter::visitChildren):
2467         * runtime/HashMapImpl.cpp:
2468         (JSC::HashMapBucket<Data>::visitChildren):
2469         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
2470         * runtime/InferredTypeTable.cpp:
2471         (JSC::InferredTypeTable::visitChildren):
2472         * runtime/InternalFunction.cpp:
2473         (JSC::InternalFunction::visitChildren):
2474         * runtime/IntlCollator.cpp:
2475         (JSC::IntlCollator::visitChildren):
2476         * runtime/IntlCollatorConstructor.cpp:
2477         (JSC::IntlCollatorConstructor::visitChildren):
2478         * runtime/IntlDateTimeFormat.cpp:
2479         (JSC::IntlDateTimeFormat::visitChildren):
2480         * runtime/IntlDateTimeFormatConstructor.cpp:
2481         (JSC::IntlDateTimeFormatConstructor::visitChildren):
2482         * runtime/IntlNumberFormat.cpp:
2483         (JSC::IntlNumberFormat::visitChildren):
2484         * runtime/IntlNumberFormatConstructor.cpp:
2485         (JSC::IntlNumberFormatConstructor::visitChildren):
2486         * runtime/JSBoundFunction.cpp:
2487         (JSC::JSBoundFunction::visitChildren):
2488         * runtime/JSCallee.cpp:
2489         (JSC::JSCallee::visitChildren):
2490         * runtime/JSCellInlines.h:
2491         (JSC::JSCell::visitChildren):
2492         * runtime/JSCustomGetterSetterFunction.cpp:
2493         (JSC::JSCustomGetterSetterFunction::visitChildren):
2494         * runtime/JSFunction.cpp:
2495         (JSC::JSFunction::visitChildren):
2496         * runtime/JSGlobalObject.cpp:
2497         (JSC::JSGlobalObject::visitChildren):
2498         * runtime/JSMapIterator.cpp:
2499         (JSC::JSMapIterator::visitChildren):
2500         * runtime/JSModuleEnvironment.cpp:
2501         (JSC::JSModuleEnvironment::visitChildren):
2502         * runtime/JSModuleNamespaceObject.cpp:
2503         (JSC::JSModuleNamespaceObject::visitChildren):
2504         * runtime/JSModuleRecord.cpp:
2505         (JSC::JSModuleRecord::visitChildren):
2506         * runtime/JSNativeStdFunction.cpp:
2507         (JSC::JSNativeStdFunction::visitChildren):
2508         * runtime/JSObject.cpp:
2509         (JSC::JSObject::visitButterflyImpl):
2510         * runtime/JSPromiseDeferred.cpp:
2511         (JSC::JSPromiseDeferred::visitChildren):
2512         * runtime/JSPropertyNameEnumerator.cpp:
2513         (JSC::JSPropertyNameEnumerator::visitChildren):
2514         * runtime/JSPropertyNameIterator.cpp:
2515         (JSC::JSPropertyNameIterator::visitChildren):
2516         * runtime/JSProxy.cpp:
2517         (JSC::JSProxy::visitChildren):
2518         * runtime/JSScope.cpp:
2519         (JSC::JSScope::visitChildren):
2520         * runtime/JSSegmentedVariableObject.cpp:
2521         (JSC::JSSegmentedVariableObject::visitChildren):
2522         * runtime/JSSetIterator.cpp:
2523         (JSC::JSSetIterator::visitChildren):
2524         * runtime/JSString.cpp:
2525         (JSC::JSRopeString::visitFibers):
2526         * runtime/JSSymbolTableObject.cpp:
2527         (JSC::JSSymbolTableObject::visitChildren):
2528         * runtime/JSWeakMap.cpp:
2529         (JSC::JSWeakMap::visitChildren):
2530         * runtime/JSWeakSet.cpp:
2531         (JSC::JSWeakSet::visitChildren):
2532         * runtime/JSWithScope.cpp:
2533         (JSC::JSWithScope::visitChildren):
2534         * runtime/JSWrapperObject.cpp:
2535         (JSC::JSWrapperObject::visitChildren):
2536         * runtime/LazyClassStructure.cpp:
2537         (JSC::LazyClassStructure::visit):
2538         * runtime/LazyPropertyInlines.h:
2539         (JSC::ElementType>::visit):
2540         * runtime/MapBase.cpp:
2541         (JSC::MapBase<HashMapBucketType>::visitChildren):
2542         * runtime/ModuleProgramExecutable.cpp:
2543         (JSC::ModuleProgramExecutable::visitChildren):
2544         * runtime/NativeErrorConstructor.cpp:
2545         (JSC::NativeErrorConstructor::visitChildren):
2546         * runtime/ProgramExecutable.cpp:
2547         (JSC::ProgramExecutable::visitChildren):
2548         * runtime/ProxyObject.cpp:
2549         (JSC::ProxyObject::visitChildren):
2550         * runtime/ProxyRevoke.cpp:
2551         (JSC::ProxyRevoke::visitChildren):
2552         * runtime/RegExpCachedResult.cpp:
2553         (JSC::RegExpCachedResult::visitChildren):
2554         * runtime/RegExpObject.cpp:
2555         (JSC::RegExpObject::visitChildren):
2556         * runtime/RegExpPrototype.cpp:
2557         (JSC::RegExpPrototype::visitChildren):
2558         * runtime/SamplingProfiler.cpp:
2559         (JSC::SamplingProfiler::visit):
2560         * runtime/ScopedArguments.cpp:
2561         (JSC::ScopedArguments::visitChildren):
2562         * runtime/SmallStrings.cpp:
2563         (JSC::SmallStrings::visitStrongReferences):
2564         * runtime/SparseArrayValueMap.cpp:
2565         (JSC::SparseArrayValueMap::visitChildren):
2566         * runtime/Structure.cpp:
2567         (JSC::Structure::visitChildren):
2568         (JSC::Structure::markIfCheap):
2569         * runtime/StructureChain.cpp:
2570         (JSC::StructureChain::visitChildren):
2571         * runtime/StructureRareData.cpp:
2572         (JSC::StructureRareData::visitChildren):
2573         * runtime/SymbolTable.cpp:
2574         (JSC::SymbolTable::visitChildren):
2575         * runtime/TypeProfilerLog.cpp:
2576         (JSC::TypeProfilerLog::visit):
2577         * runtime/WeakMapData.cpp:
2578         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
2579         * wasm/js/JSWebAssemblyInstance.cpp:
2580         (JSC::JSWebAssemblyInstance::visitChildren):
2581         * wasm/js/JSWebAssemblyMemory.cpp:
2582         (JSC::JSWebAssemblyMemory::visitChildren):
2583         * wasm/js/JSWebAssemblyModule.cpp:
2584         (JSC::JSWebAssemblyModule::visitChildren):
2585         * wasm/js/JSWebAssemblyTable.cpp:
2586         (JSC::JSWebAssemblyTable::visitChildren):
2587         * wasm/js/WebAssemblyFunction.cpp:
2588         (JSC::WebAssemblyFunction::visitChildren):
2589         * wasm/js/WebAssemblyModuleRecord.cpp:
2590         (JSC::WebAssemblyModuleRecord::visitChildren):
2591
2592 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
2593
2594         Sort Xcode project files
2595         https://bugs.webkit.org/show_bug.cgi?id=165937
2596
2597         Reviewed by Simon Fraser.
2598
2599         * JavaScriptCore.xcodeproj/project.pbxproj:
2600
2601 2016-12-15  Keith Miller  <keith_miller@apple.com>
2602
2603         Wasm should not create empty unlinked callsites
2604         https://bugs.webkit.org/show_bug.cgi?id=165933
2605
2606         Reviewed by Mark Lam.
2607
2608         Wasm would create holes in the unlinked callsite vector if B3 was able to
2609         eliminate the callsite.
2610
2611         * wasm/WasmB3IRGenerator.cpp:
2612         (JSC::Wasm::B3IRGenerator::addCall):
2613
2614 2016-12-15  JF Bastien  <jfbastien@apple.com>
2615
2616         WebAssembly: improve compilation error messages
2617         https://bugs.webkit.org/show_bug.cgi?id=163919
2618
2619         Reviewed by Saam Barati.
2620
2621         The error handling messages were underwhelming because most
2622         locations merely returned `false` on failure. This patch uses
2623         std::expected to denote that failure isn't expected. Doing this
2624         makes it almost impossible to mess up the code: either a function
2625         returns a result (or a partial result for internal helpers) or an
2626         error. We're not synchronizing the error string with the m_failed
2627         bool anymore, and the caller will abort if they try to get a
2628         result but the outcome was an error.
2629
2630         This also shortens the code significantly using macros, while also
2631         judiciously preventing inlining of error handling code and biasing
2632         towards success using UNLIKELY. This means that the generated code
2633         should be more efficient (no string formatting on success, and
2634         regalloc can avoid these unlikely paths).
2635
2636         The patch adds a few missing checks as well, especially related to
2637         count limits and memory allocation failure.
2638
2639         As a follow-up I'd like to improve WTF::makeString further, so it
2640         does coercions to string and understands ADL as I did in this
2641         patch.
2642
2643         * wasm/WasmB3IRGenerator.cpp:
2644         (JSC::Wasm::B3IRGenerator::fail):
2645         (JSC::Wasm::parseAndCompile):
2646         * wasm/WasmB3IRGenerator.h:
2647         * wasm/WasmFormat.h:
2648         (JSC::Wasm::isValidExternalKind):
2649         (JSC::Wasm::makeString):
2650         * wasm/WasmFunctionParser.h:
2651         * wasm/WasmModuleParser.cpp:
2652         * wasm/WasmModuleParser.h:
2653         * wasm/WasmParser.h:
2654         (JSC::Wasm::FailureHelper::makeString):
2655         (JSC::Wasm::Parser::fail):
2656         (JSC::Wasm::Parser<SuccessType>::Parser):
2657         (JSC::Wasm::Parser<SuccessType>::consumeCharacter):
2658         (JSC::Wasm::Parser<SuccessType>::consumeString):
2659         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2660         (JSC::Wasm::Parser<SuccessType>::parseVarUInt32):
2661         (JSC::Wasm::Parser<SuccessType>::parseVarUInt64):
2662         (JSC::Wasm::Parser<SuccessType>::parseVarInt32):
2663         (JSC::Wasm::Parser<SuccessType>::parseVarInt64):
2664         (JSC::Wasm::Parser<SuccessType>::parseUInt32):
2665         (JSC::Wasm::Parser<SuccessType>::parseUInt64):
2666         (JSC::Wasm::Parser<SuccessType>::parseUInt8):
2667         (JSC::Wasm::Parser<SuccessType>::parseInt7):
2668         (JSC::Wasm::Parser<SuccessType>::parseUInt7):
2669         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
2670         (JSC::Wasm::Parser<SuccessType>::parseResultType):
2671         (JSC::Wasm::Parser<SuccessType>::parseValueType):
2672         (JSC::Wasm::Parser<SuccessType>::parseExternalKind):
2673         * wasm/WasmPlan.cpp:
2674         (JSC::Wasm::Plan::run):
2675         * wasm/WasmSections.h:
2676         (JSC::Wasm::isValidSection):
2677         (JSC::Wasm::validateOrder):
2678         (JSC::Wasm::makeString):
2679         * wasm/WasmValidate.cpp:
2680         (JSC::Wasm::Validate::fail):
2681         (JSC::Wasm::Validate::addUnreachable):
2682         (JSC::Wasm::validateFunction):
2683         * wasm/WasmValidate.h:
2684         * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
2685         * wasm/generateWasmOpsHeader.py:
2686         * wasm/generateWasmValidateInlinesHeader.py:
2687         (loadMacro):
2688         (storeMacro):
2689         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2690         (JSC::constructJSWebAssemblyInstance):
2691         * wasm/js/WebAssemblyModuleRecord.cpp:
2692         (JSC::WebAssemblyModuleRecord::link):
2693
2694 2016-12-15  JF Bastien  <jfbastien@apple.com>
2695
2696         WebAssembly API: improve data section errors, initialize after Element
2697         https://bugs.webkit.org/show_bug.cgi?id=165733
2698
2699         Reviewed by Keith Miller.
2700
2701         * wasm/WasmModuleParser.cpp:
2702         (JSC::Wasm::ModuleParser::parseData): Data section without Memory section or import is a validation error
2703         * wasm/js/WebAssemblyModuleRecord.cpp:
2704         (JSC::dataSegmentFail):
2705         (JSC::WebAssemblyModuleRecord::evaluate): tighten checks (though the spec isn't fully baked), and move after Element initialization
2706
2707 2016-12-15  Keith Miller  <keith_miller@apple.com>
2708
2709         Turn on WebAssembly by default
2710         https://bugs.webkit.org/show_bug.cgi?id=165918
2711
2712         Reviewed by Saam Barati.
2713
2714         * runtime/Options.h:
2715
2716 2016-12-15  Konstantin Tokarev  <annulen@yandex.ru>
2717
2718         Added missing override and final specifiers
2719         https://bugs.webkit.org/show_bug.cgi?id=165903
2720
2721         Reviewed by Darin Adler.
2722
2723         * bytecompiler/BytecodeGenerator.h:
2724         * jsc.cpp:
2725         * parser/Nodes.h:
2726
2727 2016-12-15  Chris Dumez  <cdumez@apple.com>
2728
2729         Harden JSObject::getOwnPropertyDescriptor()
2730         https://bugs.webkit.org/show_bug.cgi?id=165908
2731
2732         Reviewed by Geoffrey Garen.
2733
2734         * runtime/JSObject.cpp:
2735         (JSC::JSObject::getOwnPropertyDescriptor):
2736
2737 2016-12-15  Keith Miller  <keith_miller@apple.com>
2738
2739         Fix 64-bit shift family Wasm opcodes
2740         https://bugs.webkit.org/show_bug.cgi?id=165902
2741
2742         Reviewed by Geoffrey Garen.
2743
2744         The Int64 versions of the shift family B3 opcodes take an Int32
2745         for the shift value. Wasm, however, takes an i64, so we need to
2746         Trunc the shift value. Also, this fixes a bug where shr_u mapped
2747         to signed shift and shr_s mapped to the unsigned shift.
2748
2749         * wasm/wasm.json:
2750
2751 2016-12-14  Keith Miller  <keith_miller@apple.com>
2752
2753         Wasm should decode constants correctly
2754         https://bugs.webkit.org/show_bug.cgi?id=165886
2755
2756         Reviewed by Saam Barati.
2757
2758         This patch fixes how we decode the constant part of i32, i64, f32,
2759         and f64.const opcodes.
2760
2761         * wasm/WasmFunctionParser.h:
2762         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2763         * wasm/wasm.json:
2764
2765 2016-12-14  Saam Barati  <sbarati@apple.com>
2766
2767         WebAssembly: Add various low hanging fruit that will allow us to run the LLVM torture tests in Wasm
2768         https://bugs.webkit.org/show_bug.cgi?id=165883
2769
2770         Reviewed by Keith Miller.
2771
2772         This patch implements some low hanging fruit:
2773         - Exporting Table
2774         - Exporting Memory
2775         - Load16 with zero extension to both 32 and 64 bit values.
2776         - Fixes Unreachable to emit code that will prevent B3 from having a validation error.
2777
2778         * wasm/WasmB3IRGenerator.cpp:
2779         (JSC::Wasm::B3IRGenerator::addUnreachable):
2780         (JSC::Wasm::sizeOfLoadOp):
2781         (JSC::Wasm::B3IRGenerator::emitLoadOp):
2782         * wasm/WasmFunctionParser.h:
2783         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2784         * wasm/WasmModuleParser.cpp:
2785         (JSC::Wasm::ModuleParser::parseExport):
2786         * wasm/WasmValidate.cpp:
2787         (JSC::Wasm::Validate::addUnreachable):
2788         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2789         (JSC::constructJSWebAssemblyInstance):
2790         * wasm/js/WebAssemblyModuleRecord.cpp:
2791         (JSC::WebAssemblyModuleRecord::finishCreation):
2792         (JSC::WebAssemblyModuleRecord::link):
2793
2794 2016-12-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2795
2796         Update ModuleLoader code by using the latest builtin primitives
2797         https://bugs.webkit.org/show_bug.cgi?id=165851
2798
2799         Reviewed by Sam Weinig.
2800
2801         Update the module loader code,
2802
2803         1. Use @globalPrivate for the utilities, instead of setting them as the member of ModuleLoader.
2804         2. Use @putByValDirect instead of @push. @push is user-observable since it uses Set() operation
2805            and it can be observed by defining indexed setters in Array.prototype.
2806
2807         * builtins/ModuleLoaderPrototype.js:
2808         (ensureRegistered):
2809         (fulfillFetch):
2810         (commitInstantiated):
2811         (requestFetch):
2812         (requestSatisfy):
2813         (setStateToMax): Deleted.
2814         (newRegistryEntry): Deleted.
2815         * runtime/ModuleLoaderPrototype.cpp:
2816
2817 2016-12-14  Michael Saboff  <msaboff@apple.com>
2818
2819         The stress GC bot crashes in JavaScriptCore beneath ShadowChicken::update and Inspector::jsToInspectorValue
2820         https://bugs.webkit.org/show_bug.cgi?id=165871
2821
2822         Reviewed by Mark Lam.
2823
2824         This fixes two issues with the VM watch dog timer firing in a worker.
2825
2826         The first issue has to do with bytecode ordering.  Prior to this change, the first few opcodes
2827         generated when the watch dog is enabled are:
2828                 op_enter
2829                 op_watchdog
2830                 op_get_scope
2831         When the watchdog fires, the function will get an exception at op_watchdog.  In processing that exception,
2832         we'll try to update the ShadowChicken shadow stack.  That update assumes that if there is a scope 
2833         VirtualRegister allocated, then the slot contains a valid JSScope.  With the current bytecode ordering,
2834         this is not true at op_watchdog as op_enter will put JSUndefined in the scope slot.  It isn't until the
2835         op_get_scope gets processed that we'll have a valid scope in the slot.  The fix for this issue is to 
2836         ensure that op_get_scope happens before the op_watchdog.
2837
2838         The second issue is that ScriptFunctionCall::call() will not tell its caller that a terminated
2839         execution exception happened.  Instead call() returns an empty JSValue.  InjectedScript::wrapCallFrames()
2840         wasn't checking for an empty JSValue, but was passing it to another function.  Added a short circuit
2841         return when call returns an empty JSValue.
2842
2843         Added <https://bugs.webkit.org/show_bug.cgi?id=165875> to fix other callers of ScriptFunctionCall::call()
2844         to check for an empty JSValue return value.
2845         Also tracked with <rdar://problem/29671015>.
2846
2847         * bytecompiler/BytecodeGenerator.cpp:
2848         (JSC::BytecodeGenerator::BytecodeGenerator):
2849         (JSC::BytecodeGenerator::emitEnter):
2850         * inspector/InjectedScript.cpp:
2851         (Inspector::InjectedScript::wrapCallFrames):
2852
2853 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2854
2855         DirectTailCall implementation needs to tell the shuffler what to put into the ArgumentCount explicitly
2856         https://bugs.webkit.org/show_bug.cgi?id=165882
2857
2858         Reviewed by Mark Lam.
2859         
2860         The CallFrameShuffler was assuming that the ArgumentCount that it should store into the
2861         callee frame is simply the size of the args vector.
2862         
2863         That's not true for DirectTailCall, which will pad the args vector with undefined if we
2864         are optimizing an arity mismatch. We need to pass the ArgumentCount explicitly in this
2865         case.
2866
2867         * dfg/DFGSpeculativeJIT32_64.cpp:
2868         (JSC::DFG::SpeculativeJIT::emitCall):
2869         * dfg/DFGSpeculativeJIT64.cpp:
2870         (JSC::DFG::SpeculativeJIT::emitCall):
2871         * ftl/FTLLowerDFGToB3.cpp:
2872         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
2873         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
2874         * jit/CallFrameShuffleData.h:
2875         * jit/CallFrameShuffler.cpp:
2876         (JSC::CallFrameShuffler::CallFrameShuffler):
2877         (JSC::CallFrameShuffler::prepareAny):
2878         * jit/CallFrameShuffler.h:
2879         (JSC::CallFrameShuffler::snapshot):
2880         * jit/JITCall.cpp:
2881         (JSC::JIT::compileOpCall):
2882
2883 2016-12-14  Keith Miller  <keith_miller@apple.com>
2884
2885         WebAssembly JS API: implement Global
2886         https://bugs.webkit.org/show_bug.cgi?id=164133
2887
2888         Reviewed by Saam Barati.
2889
2890         This patch adds support for globals. It handles imports, exports
2891         and internal globals. In the MVP only internal globals are allowed
2892         to be mutable. This means we can store a C-array of 64-bit slots
2893         off the instance holding them. When globals are exported to JS
2894         they are done so as numbers. This means that i64 globals cannot be
2895         imported or exported.
2896
2897         * wasm/WasmB3IRGenerator.cpp:
2898         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2899         (JSC::Wasm::B3IRGenerator::getGlobal):
2900         (JSC::Wasm::B3IRGenerator::setGlobal):
2901         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2902         (JSC::Wasm::parseAndCompile):
2903         * wasm/WasmFormat.h:
2904         * wasm/WasmFunctionParser.h:
2905         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2906         * wasm/WasmModuleParser.cpp:
2907         (JSC::Wasm::ModuleParser::parseImport):
2908         (JSC::Wasm::ModuleParser::parseGlobal):
2909         (JSC::Wasm::ModuleParser::parseExport):
2910         (JSC::Wasm::ModuleParser::parseElement):
2911         (JSC::Wasm::ModuleParser::parseInitExpr):
2912         (JSC::Wasm::ModuleParser::parseGlobalType):
2913         (JSC::Wasm::ModuleParser::parseData):
2914         * wasm/WasmModuleParser.h:
2915         * wasm/WasmParser.h:
2916         (JSC::Wasm::Parser::parseVarInt32):
2917         (JSC::Wasm::Parser::parseVarInt64):
2918         (JSC::Wasm::Parser::parseUInt64):
2919         * wasm/WasmValidate.cpp:
2920         (JSC::Wasm::Validate::hasMemory):
2921         (JSC::Wasm::Validate::Validate):
2922         (JSC::Wasm::Validate::getGlobal):
2923         (JSC::Wasm::Validate::setGlobal):
2924         (JSC::Wasm::validateFunction):
2925         * wasm/generateWasmOpsHeader.py:
2926         * wasm/js/JSWebAssemblyInstance.cpp:
2927         (JSC::JSWebAssemblyInstance::create):
2928         (JSC::JSWebAssemblyInstance::finishCreation):
2929         (JSC::JSWebAssemblyInstance::visitChildren):
2930         * wasm/js/JSWebAssemblyInstance.h:
2931         (JSC::JSWebAssemblyInstance::loadI32Global):
2932         (JSC::JSWebAssemblyInstance::loadI64Global):
2933         (JSC::JSWebAssemblyInstance::loadF32Global):
2934         (JSC::JSWebAssemblyInstance::loadF64Global):
2935         (JSC::JSWebAssemblyInstance::setGlobal):
2936         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2937         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2938         (JSC::constructJSWebAssemblyInstance):
2939         * wasm/js/WebAssemblyModuleRecord.cpp:
2940         (JSC::WebAssemblyModuleRecord::finishCreation):
2941         (JSC::WebAssemblyModuleRecord::link):
2942
2943 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2944
2945         Unreviewed, re-enable concurrent GC on ARM64 now that the most likely culprit of the memory
2946         regressions is fixed. Lets see what the bots think!
2947
2948         * runtime/Options.cpp:
2949         (JSC::recomputeDependentOptions):
2950
2951 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2952
2953         Devices with fewer cores should use a more aggressive GC schedule by default
2954         https://bugs.webkit.org/show_bug.cgi?id=165859
2955
2956         Reviewed by Mark Lam.
2957
2958         * heap/Heap.cpp:
2959         (JSC::Heap::markToFixpoint): Log when we have an unexpected delay in wake-up.
2960         * heap/SlotVisitor.cpp:
2961         (JSC::SlotVisitor::drainInParallelPassively): Don't drain passively if there aren't many cores.
2962         * runtime/Options.cpp:
2963         (JSC::overrideDefaults): Change the heuristics if we have fewer cores.
2964         (JSC::Options::initialize):
2965         * runtime/Options.h:
2966
2967 2016-12-14  Mark Lam  <mark.lam@apple.com>
2968
2969         BytecodeBasicBlock::computeImpl() should not keep iterating blocks if all jump targets have already been found.
2970         https://bugs.webkit.org/show_bug.cgi?id=165820
2971
2972         Reviewed by Saam Barati.
2973
2974         Currently, if an opcode is a branch type opcode, BytecodeBasicBlock::computeImpl()
2975         will iterate over all basic blocks looking for the block containing the jump
2976         target, and it will continue to do this even when all the jump targets have been
2977         found.  This is wasted work, and all the more so given that most branch type
2978         opcodes only have a single jump target.
2979
2980         * bytecode/BytecodeBasicBlock.cpp:
2981         (JSC::BytecodeBasicBlock::computeImpl):
2982
2983 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
2984
2985         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
2986         https://bugs.webkit.org/show_bug.cgi?id=165741
2987
2988         Unreviewed, re-landing this with fix (revert erroneous change to Options).
2989
2990         * CMakeLists.txt:
2991         * JavaScriptCore.xcodeproj/project.pbxproj:
2992         * heap/CellContainer.cpp: Added.
2993         (JSC::CellContainer::isNewlyAllocated):
2994         * heap/CellContainer.h:
2995         * heap/MarkedAllocator.cpp:
2996         (JSC::MarkedAllocator::addBlock):
2997         (JSC::MarkedAllocator::removeBlock):
2998         (JSC::MarkedAllocator::dumpBits):
2999         * heap/MarkedAllocator.h:
3000         (JSC::MarkedAllocator::forEachBitVector):
3001         (JSC::MarkedAllocator::forEachBitVectorWithName):
3002         * heap/MarkedBlock.cpp:
3003         (JSC::MarkedBlock::tryCreate):
3004         (JSC::MarkedBlock::Handle::~Handle):
3005         (JSC::MarkedBlock::MarkedBlock):
3006         (JSC::MarkedBlock::Handle::specializedSweep):
3007         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
3008         (JSC::MarkedBlock::Handle::stopAllocating):
3009         (JSC::MarkedBlock::Handle::resumeAllocating):
3010         (JSC::MarkedBlock::aboutToMarkSlow):
3011         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3012         (JSC::MarkedBlock::Handle::dumpState):
3013         * heap/MarkedBlock.h:
3014         (JSC::MarkedBlock::markingVersion):
3015         (JSC::MarkedBlock::isMarkedRaw):
3016         (JSC::MarkedBlock::isMarked):
3017         * heap/MarkedBlockInlines.h:
3018         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
3019         * heap/SlotVisitor.cpp:
3020         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3021         * runtime/StructureIDTable.h:
3022         (JSC::StructureIDTable::size):
3023         (JSC::StructureIDTable::get):
3024
3025 2016-12-14  Chris Dumez  <cdumez@apple.com>
3026
3027         Unreviewed, rolling out r209766.
3028
3029         Regressed Dromaeo JSLib by ~50%
3030
3031         Reverted changeset:
3032
3033         "Make opaque root scanning truly constraint-based"
3034         https://bugs.webkit.org/show_bug.cgi?id=165760
3035         http://trac.webkit.org/changeset/209766
3036
3037 2016-12-14  Commit Queue  <commit-queue@webkit.org>
3038
3039         Unreviewed, rolling out r209795.
3040         https://bugs.webkit.org/show_bug.cgi?id=165853
3041
3042         rolled out the wrong revision (Requested by pizlo on #webkit).
3043
3044         Reverted changeset:
3045
3046         "MarkedBlock::marksConveyLivenessDuringMarking should take
3047         into account collection scope"
3048         https://bugs.webkit.org/show_bug.cgi?id=165741
3049         http://trac.webkit.org/changeset/209795
3050
3051 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
3052
3053         Unreviewed, disable concurrent GC on ARM while we investigate a memory use regression.
3054
3055         * runtime/Options.cpp:
3056         (JSC::recomputeDependentOptions):
3057
3058 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3059
3060         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
3061         https://bugs.webkit.org/show_bug.cgi?id=165795
3062
3063         Reviewed by Saam Barati.
3064
3065         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
3066         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
3067         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
3068         allocations.
3069
3070         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
3071
3072         * API/JSValueRef.cpp:
3073         (JSValueToStringCopy):
3074         * bindings/ScriptValue.cpp:
3075         (Deprecated::ScriptValue::toString):
3076         * inspector/JSGlobalObjectInspectorController.cpp:
3077         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3078         * inspector/JSInjectedScriptHost.cpp:
3079         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3080         * inspector/JSJavaScriptCallFrame.cpp:
3081         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3082         * inspector/ScriptCallStackFactory.cpp:
3083         (Inspector::extractSourceInformationFromException):
3084         * runtime/ConsoleObject.cpp:
3085         (JSC::valueToStringWithUndefinedOrNullCheck):
3086         (JSC::valueOrDefaultLabelString):
3087         * runtime/DateConstructor.cpp:
3088         (JSC::dateParse):
3089         * runtime/DatePrototype.cpp:
3090         (JSC::formatLocaleDate):
3091         * runtime/ErrorInstance.cpp:
3092         (JSC::ErrorInstance::sanitizedToString):
3093         * runtime/ErrorPrototype.cpp:
3094         (JSC::errorProtoFuncToString):
3095         * runtime/InspectorInstrumentationObject.cpp:
3096         (JSC::inspectorInstrumentationObjectLog):
3097         * runtime/JSGlobalObjectFunctions.cpp:
3098         (JSC::globalFuncEval):
3099         * runtime/JSModuleLoader.cpp:
3100         (JSC::JSModuleLoader::fetch):
3101         * runtime/ModuleLoaderPrototype.cpp:
3102         (JSC::moduleLoaderPrototypeParseModule):
3103         * runtime/RegExpConstructor.cpp:
3104         (JSC::regExpCreate):
3105         * runtime/RegExpPrototype.cpp:
3106         (JSC::regExpProtoFuncCompile):
3107         (JSC::regExpProtoFuncToString):
3108         * runtime/StringPrototype.cpp:
3109         (JSC::replaceUsingRegExpSearch):
3110         (JSC::replaceUsingStringSearch):
3111         (JSC::stringProtoFuncSlice):
3112         (JSC::stringProtoFuncSplitFast):
3113         (JSC::stringProtoFuncSubstr):
3114         (JSC::stringProtoFuncLocaleCompare):
3115         (JSC::stringProtoFuncBig):
3116         (JSC::stringProtoFuncSmall):
3117         (JSC::stringProtoFuncBlink):
3118         (JSC::stringProtoFuncBold):
3119         (JSC::stringProtoFuncFixed):
3120         (JSC::stringProtoFuncItalics):
3121         (JSC::stringProtoFuncStrike):
3122         (JSC::stringProtoFuncSub):
3123         (JSC::stringProtoFuncSup):
3124         (JSC::stringProtoFuncFontcolor):
3125         (JSC::stringProtoFuncFontsize):
3126         (JSC::stringProtoFuncAnchor):
3127         (JSC::stringProtoFuncLink):
3128         (JSC::trimString):
3129         (JSC::stringProtoFuncStartsWith):
3130         (JSC::stringProtoFuncEndsWith):
3131         (JSC::stringProtoFuncIncludes):
3132         (JSC::builtinStringIncludesInternal):
3133         (JSC::stringProtoFuncNormalize):
3134         * tools/JSDollarVMPrototype.cpp:
3135         (JSC::functionPrint):
3136         * wasm/js/JSWebAssemblyCompileError.h:
3137         (JSC::JSWebAssemblyCompileError::create):
3138         * wasm/js/JSWebAssemblyRuntimeError.h:
3139         (JSC::JSWebAssemblyRuntimeError::create):
3140
3141 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
3142
3143         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
3144         https://bugs.webkit.org/show_bug.cgi?id=165741
3145
3146         Unreviewed rollout due to performance regression.
3147
3148         * CMakeLists.txt:
3149         * JavaScriptCore.xcodeproj/project.pbxproj:
3150         * heap/CellContainer.cpp: Removed.
3151         * heap/CellContainer.h:
3152         * heap/MarkedAllocator.cpp:
3153         (JSC::MarkedAllocator::addBlock):
3154         (JSC::MarkedAllocator::removeBlock):
3155         (JSC::MarkedAllocator::dumpBits):
3156         * heap/MarkedAllocator.h:
3157         (JSC::MarkedAllocator::forEachBitVector):
3158         (JSC::MarkedAllocator::forEachBitVectorWithName):
3159         * heap/MarkedBlock.cpp:
3160         (JSC::MarkedBlock::tryCreate):
3161         (JSC::MarkedBlock::Handle::~Handle):
3162         (JSC::MarkedBlock::MarkedBlock):
3163         (JSC::MarkedBlock::Handle::specializedSweep):
3164         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
3165         (JSC::MarkedBlock::Handle::stopAllocating):
3166         (JSC::MarkedBlock::Handle::resumeAllocating):
3167         (JSC::MarkedBlock::aboutToMarkSlow):
3168         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3169         (JSC::MarkedBlock::Handle::dumpState): Deleted.
3170         * heap/MarkedBlock.h:
3171         (JSC::MarkedBlock::isMarked):
3172         (JSC::MarkedBlock::markingVersion): Deleted.
3173         (JSC::MarkedBlock::isMarkedRaw): Deleted.
3174         * heap/MarkedBlockInlines.h:
3175         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
3176         * heap/SlotVisitor.cpp:
3177         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3178         * runtime/Options.h:
3179         * runtime/StructureIDTable.h:
3180         (JSC::StructureIDTable::get):
3181         (JSC::StructureIDTable::size): Deleted.
3182
3183 2016-12-13  Commit Queue  <commit-queue@webkit.org>
3184
3185         Unreviewed, rolling out r209792.
3186         https://bugs.webkit.org/show_bug.cgi?id=165841
3187
3188         Cause build failures (Requested by yusukesuzuki on #webkit).
3189
3190         Reverted changeset:
3191
3192         "Use JSValue::toWTFString instead of calling toString(exec)
3193         and value(exec)"
3194         https://bugs.webkit.org/show_bug.cgi?id=165795
3195         http://trac.webkit.org/changeset/209792
3196
3197 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3198
3199         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
3200         https://bugs.webkit.org/show_bug.cgi?id=165795
3201
3202         Reviewed by Saam Barati.
3203
3204         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
3205         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
3206         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
3207         allocations.
3208
3209         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
3210
3211         * API/JSValueRef.cpp:
3212         (JSValueToStringCopy):
3213         * bindings/ScriptValue.cpp:
3214         (Deprecated::ScriptValue::toString):
3215         * inspector/JSGlobalObjectInspectorController.cpp:
3216         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3217         * inspector/JSInjectedScriptHost.cpp:
3218         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3219         * inspector/JSJavaScriptCallFrame.cpp:
3220         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3221         * inspector/ScriptCallStackFactory.cpp:
3222         (Inspector::extractSourceInformationFromException):
3223         * runtime/ConsoleObject.cpp:
3224         (JSC::valueToStringWithUndefinedOrNullCheck):
3225         (JSC::valueOrDefaultLabelString):
3226         * runtime/DateConstructor.cpp:
3227         (JSC::dateParse):
3228         * runtime/DatePrototype.cpp:
3229         (JSC::formatLocaleDate):
3230         * runtime/ErrorInstance.cpp:
3231         (JSC::ErrorInstance::sanitizedToString):
3232         * runtime/ErrorPrototype.cpp:
3233         (JSC::errorProtoFuncToString):
3234         * runtime/InspectorInstrumentationObject.cpp:
3235         (JSC::inspectorInstrumentationObjectLog):
3236         * runtime/JSCJSValue.cpp:
3237         (JSC::JSValue::toWTFStringSlowCase):
3238         * runtime/JSGlobalObjectFunctions.cpp:
3239         (JSC::globalFuncEval):
3240         * runtime/JSModuleLoader.cpp:
3241         (JSC::JSModuleLoader::fetch):
3242         * runtime/ModuleLoaderPrototype.cpp:
3243         (JSC::moduleLoaderPrototypeParseModule):
3244         * runtime/RegExpConstructor.cpp:
3245         (JSC::regExpCreate):
3246         * runtime/RegExpPrototype.cpp:
3247         (JSC::regExpProtoFuncCompile):
3248         (JSC::regExpProtoFuncToString):
3249         * runtime/StringPrototype.cpp:
3250         (JSC::replaceUsingRegExpSearch):
3251         (JSC::replaceUsingStringSearch):
3252         (JSC::stringProtoFuncSlice):
3253         (JSC::stringProtoFuncSplitFast):
3254         (JSC::stringProtoFuncSubstr):
3255         (JSC::stringProtoFuncLocaleCompare):
3256         (JSC::stringProtoFuncBig):
3257         (JSC::stringProtoFuncSmall):
3258         (JSC::stringProtoFuncBlink):
3259         (JSC::stringProtoFuncBold):
3260         (JSC::stringProtoFuncFixed):
3261         (JSC::stringProtoFuncItalics):
3262         (JSC::stringProtoFuncStrike):
3263         (JSC::stringProtoFuncSub):
3264         (JSC::stringProtoFuncSup):
3265         (JSC::stringProtoFuncFontcolor):
3266         (JSC::stringProtoFuncFontsize):
3267         (JSC::stringProtoFuncAnchor):
3268         (JSC::stringProtoFuncLink):
3269         (JSC::trimString):
3270         (JSC::stringProtoFuncStartsWith):
3271         (JSC::stringProtoFuncEndsWith):
3272         (JSC::stringProtoFuncIncludes):
3273         (JSC::builtinStringIncludesInternal):
3274         (JSC::stringProtoFuncNormalize):
3275         * tools/JSDollarVMPrototype.cpp:
3276         (JSC::functionPrint):
3277         * wasm/js/JSWebAssemblyCompileError.h:
3278         (JSC::JSWebAssemblyCompileError::create):
3279         * wasm/js/JSWebAssemblyRuntimeError.h:
3280         (JSC::JSWebAssemblyRuntimeError::create):
3281
3282 2016-12-13  Saam Barati  <sbarati@apple.com>
3283
3284         WebAssembly: implement the elements section
3285         https://bugs.webkit.org/show_bug.cgi?id=165715
3286
3287         Reviewed by Keith Miller.
3288
3289         This is a straight forward implementation of the Element
3290         section in the Wasm spec:
3291         https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#element-section
3292         
3293         There are a few ambiguities I encountered when implementing this, so I've
3294         filed bugs against the Wasm design repo, and corresponding bugzilla bugs
3295         for us to address after they've been discussed by the various Wasm folks:
3296         - https://bugs.webkit.org/show_bug.cgi?id=165827
3297         - https://bugs.webkit.org/show_bug.cgi?id=165826
3298         - https://bugs.webkit.org/show_bug.cgi?id=165825
3299
3300         * wasm/WasmFormat.h:
3301         * wasm/WasmModuleParser.cpp:
3302         (JSC::Wasm::ModuleParser::parseElement):
3303         (JSC::Wasm::ModuleParser::parseInitExpr):
3304         (JSC::Wasm::ModuleParser::parseData):
3305         * wasm/WasmModuleParser.h:
3306         * wasm/js/WebAssemblyModuleRecord.cpp:
3307         (JSC::WebAssemblyModuleRecord::evaluate):
3308
3309 2016-12-13  Chris Dumez  <cdumez@apple.com>
3310