3bcc7ec2c332ab7ae651508dfb301f3673a22731
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-05-31  Mark Lam  <mark.lam@apple.com>
2
3         Remove overrides of visitChildren() that do not add any functionality.
4         https://bugs.webkit.org/show_bug.cgi?id=172789
5         <rdar://problem/32500865>
6
7         Reviewed by Andreas Kling.
8
9         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
10         (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
11         * bytecode/UnlinkedModuleProgramCodeBlock.h:
12         * bytecode/UnlinkedProgramCodeBlock.cpp:
13         (JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
14         * bytecode/UnlinkedProgramCodeBlock.h:
15         * wasm/js/WebAssemblyFunction.cpp:
16         (JSC::WebAssemblyFunction::visitChildren): Deleted.
17         * wasm/js/WebAssemblyFunction.h:
18         * wasm/js/WebAssemblyInstanceConstructor.cpp:
19         (JSC::WebAssemblyInstanceConstructor::visitChildren): Deleted.
20         * wasm/js/WebAssemblyInstanceConstructor.h:
21         * wasm/js/WebAssemblyMemoryConstructor.cpp:
22         (JSC::WebAssemblyMemoryConstructor::visitChildren): Deleted.
23         * wasm/js/WebAssemblyMemoryConstructor.h:
24         * wasm/js/WebAssemblyModuleConstructor.cpp:
25         (JSC::WebAssemblyModuleConstructor::visitChildren): Deleted.
26         * wasm/js/WebAssemblyModuleConstructor.h:
27         * wasm/js/WebAssemblyTableConstructor.cpp:
28         (JSC::WebAssemblyTableConstructor::visitChildren): Deleted.
29         * wasm/js/WebAssemblyTableConstructor.h:
30
31 2017-05-31  Commit Queue  <commit-queue@webkit.org>
32
33         Unreviewed, rolling out r217611 and r217631.
34         https://bugs.webkit.org/show_bug.cgi?id=172785
35
36         "caused wasm-hashset-many.html to become flaky." (Requested by
37         keith_miller on #webkit).
38
39         Reverted changesets:
40
41         "Reland r216808, underlying lldb bug has been fixed."
42         https://bugs.webkit.org/show_bug.cgi?id=172759
43         http://trac.webkit.org/changeset/217611
44
45         "Use dispatch queues for mach exceptions"
46         https://bugs.webkit.org/show_bug.cgi?id=172775
47         http://trac.webkit.org/changeset/217631
48
49 2017-05-31  Oleksandr Skachkov  <gskachkov@gmail.com>
50
51         Rolling out: Prevent async methods named 'function'
52         https://bugs.webkit.org/show_bug.cgi?id=172776
53
54         Reviewed by Mark Lam.
55
56         Rolling out https://bugs.webkit.org/show_bug.cgi?id=172660 r217578, 
57         https://bugs.webkit.org/show_bug.cgi?id=172598  r217478
58         PR to spec was closed, so changes need to roll out. See
59         https://github.com/tc39/ecma262/pull/884#issuecomment-305212494 
60
61         * parser/Parser.cpp:
62         (JSC::Parser<LexerType>::parseClass):
63         (JSC::Parser<LexerType>::parsePropertyMethod):
64
65 2017-05-31  Andy Estes  <aestes@apple.com>
66
67         Rename ENABLE_APPLE_PAY_DELEGATE to ENABLE_APPLE_PAY_SESSION_V3 and bump the supported version number
68         https://bugs.webkit.org/show_bug.cgi?id=172366
69
70         Reviewed by Daniel Bates.
71
72         * Configurations/FeatureDefines.xcconfig:
73
74 2017-05-31  Keith Miller  <keith_miller@apple.com>
75
76         Reland r216808, underlying lldb bug has been fixed.
77         https://bugs.webkit.org/show_bug.cgi?id=172759
78
79
80         Unreviewed, relanding old patch. See: rdar://problem/31183352
81
82         * API/tests/ExecutionTimeLimitTest.cpp:
83         (dispatchTermitateCallback):
84         (testExecutionTimeLimit):
85         * runtime/JSLock.cpp:
86         (JSC::JSLock::didAcquireLock):
87         * runtime/Options.cpp:
88         (JSC::overrideDefaults):
89         (JSC::Options::initialize):
90         * runtime/Options.h:
91         * runtime/VMTraps.cpp:
92         (JSC::SignalContext::SignalContext):
93         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
94         (JSC::installSignalHandler):
95         (JSC::VMTraps::SignalSender::send):
96         * tools/SigillCrashAnalyzer.cpp:
97         (JSC::SignalContext::SignalContext):
98         (JSC::SignalContext::dump):
99         (JSC::installCrashHandler):
100         * wasm/WasmBBQPlan.cpp:
101         (JSC::Wasm::BBQPlan::compileFunctions):
102         * wasm/WasmFaultSignalHandler.cpp:
103         (JSC::Wasm::trapHandler):
104         (JSC::Wasm::enableFastMemory):
105         * wasm/WasmMachineThreads.cpp:
106         (JSC::Wasm::resetInstructionCacheOnAllThreads):
107
108 2017-05-31  Keith Miller  <keith_miller@apple.com>
109
110         Fix leak in PromiseDeferredTimer
111         https://bugs.webkit.org/show_bug.cgi?id=172755
112
113         Reviewed by JF Bastien.
114
115         We were not properly freeing the list of dependencies if we were already tracking the promise before.
116         This is because addPendingPromise takes the list of dependencies as an rvalue-reference. In the case
117         where we were already tracking the promise we append the provided dependency list to the existing list.
118         Since we never bound or rvalue-ref to a non-temporary value we never destructed the Vector, leaking its
119         contents.
120
121         * runtime/PromiseDeferredTimer.cpp:
122         (JSC::PromiseDeferredTimer::addPendingPromise):
123
124 2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>
125
126         Prevent async methods named 'function' in Object literal
127         https://bugs.webkit.org/show_bug.cgi?id=172660
128
129         Reviewed by Saam Barati.
130
131         Prevent async method named 'function' in object.
132         https://github.com/tc39/ecma262/pull/884
133
134         * parser/Parser.cpp:
135         (JSC::Parser<LexerType>::parsePropertyMethod):
136
137 2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>
138
139         ASSERTION FAILED: generator.isConstructor() || generator.derivedContextType() == DerivedContextType::DerivedConstructorContext
140         https://bugs.webkit.org/show_bug.cgi?id=171274
141
142         Reviewed by Saam Barati.
143
144         Current patch allow to use async arrow function within constructor,
145         and allow to access to `this`. Current patch force load 'this' from 
146         virtual scope each time as we access to `this` in async arrow function
147         within constructor it is neccessary because async function can be 
148         suspended and `superCall` can be called and async function resumed. 
149    
150         * bytecompiler/BytecodeGenerator.cpp:
151         (JSC::BytecodeGenerator::emitPutGeneratorFields):
152         (JSC::BytecodeGenerator::ensureThis):
153         * bytecompiler/BytecodeGenerator.h:
154         (JSC::BytecodeGenerator::makeFunction):
155
156 2017-05-30  Ali Juma  <ajuma@chromium.org>
157
158         [CredentialManagement] Incorporate IDL updates from latest spec
159         https://bugs.webkit.org/show_bug.cgi?id=172011
160
161         Reviewed by Daniel Bates.
162
163         * runtime/CommonIdentifiers.h:
164
165 2017-05-30  Alex Christensen  <achristensen@webkit.org>
166
167         Update libwebrtc configuration
168         https://bugs.webkit.org/show_bug.cgi?id=172727
169
170         Reviewed by Geoffrey Garen.
171
172         * Configurations/FeatureDefines.xcconfig:
173
174 2017-05-28  Dan Bernstein  <mitz@apple.com>
175
176         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
177         https://bugs.webkit.org/show_bug.cgi?id=172691
178
179         Reviewed by Tim Horton.
180
181         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
182         * JavaScriptCore.xcodeproj/project.pbxproj: Added ParseInt.h to the JavaScriptCore target.
183
184 2017-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
185
186         [JSC] Provide better type information of toLength and tighten bytecode
187         https://bugs.webkit.org/show_bug.cgi?id=172690
188
189         Reviewed by Sam Weinig.
190
191         In this patch, we carefully leverage operator + in order to
192
193         1. tighten bytecode
194
195         operator+ emits to_number bytecode. What this bytecode does is the same
196         to @Number() call. It is more efficient, and it is smaller bytecode
197         than @Number() call (load global variable @Number, set up arguments, and
198         call it).
199
200         2. offer better type prediction data
201
202         Now, we have code like
203
204             length > 0 ? (length < @MAX_SAFE_INTEGER ? length : @MAX_SAFE_INTEGER) : 0
205
206         This is not good because DFG prediction propagation phase predicts as Double
207         since @MAX_SAFE_INTEGER is double. But actually it rarely becomes Double.
208         Usually, the result becomes Int32. This patch leverages to_number in a bit
209         interesting way: to_number has value profiling to offer better type prediction.
210         This value profiling can offer a chance to change the prediction to Int32 efficiently.
211         It is a bit tricky. But it is worth doing to speed up our builtin functions,
212         which should leverage all the JSC's tricky things to be optimized.
213
214         Related microbenchmarks show performance improvement.
215
216                                                   baseline                  patched
217
218             array-prototype-forEach           50.2348+-2.2331           49.7568+-2.3507
219             array-prototype-map               51.0574+-1.8166           47.9531+-2.1653          might be 1.0647x faster
220             array-prototype-some              52.3926+-1.8882     ^     48.3632+-2.0852        ^ definitely 1.0833x faster
221             array-prototype-every             52.7394+-2.0712           50.2896+-2.1480          might be 1.0487x faster
222             array-prototype-reduce            54.9994+-2.3638           51.8716+-2.6253          might be 1.0603x faster
223             array-prototype-reduceRight      209.7594+-9.2594     ^     51.5867+-2.5745        ^ definitely 4.0662x faster
224
225
226         * builtins/GlobalOperations.js:
227         (globalPrivate.toInteger):
228         (globalPrivate.toLength):
229
230 2017-05-28  Sam Weinig  <sam@webkit.org>
231
232         [WebIDL] @@iterator should only be accessed once when disambiguating a union type
233         https://bugs.webkit.org/show_bug.cgi?id=172684
234
235         Reviewed by Yusuke Suzuki.
236
237         * runtime/IteratorOperations.cpp:
238         (JSC::iteratorMethod):
239         (JSC::iteratorForIterable):
240         * runtime/IteratorOperations.h:
241         (JSC::forEachInIterable):
242         Add additional iterator helpers to allow union + sequence conversion code
243         to check for iterability by getting the iterator method, and iterate using
244         that method later on.
245
246 2017-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
247
248         Unreviewed, build fix for Windows
249         https://bugs.webkit.org/show_bug.cgi?id=172413
250
251         Optimized jsDynamicCast for JSMap and JSSet will be handled in [1].
252
253         [1]: https://bugs.webkit.org/show_bug.cgi?id=172685
254
255         * runtime/JSMap.h:
256         (JSC::isJSMap):
257         (JSC::jsDynamicCast): Deleted.
258         (JSC::>): Deleted.
259         * runtime/JSSet.h:
260         (JSC::isJSSet):
261         (JSC::jsDynamicCast): Deleted.
262         (JSC::>): Deleted.
263         * runtime/MapConstructor.cpp:
264         (JSC::constructMap):
265         * runtime/SetConstructor.cpp:
266         (JSC::constructSet):
267
268 2017-05-28  Mark Lam  <mark.lam@apple.com>
269
270         Implement a faster Interpreter::getOpcodeID().
271         https://bugs.webkit.org/show_bug.cgi?id=172669
272
273         Reviewed by Saam Barati.
274
275         We can implement Interpreter::getOpcodeID() without a hash table lookup by always
276         embedding the OpcodeID in the 32-bit word just before the start of the LLInt
277         handler code that executes each opcode.  getOpcodeID() can therefore just read
278         the 32-bits before the opcode address to get its OpcodeID.
279
280         This is currently only enabled for CPU(X86), CPU(X86_64), CPU(ARM64),
281         CPU(ARM_THUMB2), and only for OS(DARWIN).  It'll probably just work for linux as
282         well, but I'll let the Linux folks turn that on after they have verified that it
283         works on linux too.
284
285         I'll also take this opportunity to clean up how we initialize the opcodeIDTable:
286         1. we only need to initialize it once per process, not once per VM / interpreter
287            instance.
288         2. we can initialize it in the Interpreter constructor instead of requiring a
289            separate call to an initialize() function.
290
291         On debug builds, the Interpreter constructor will also verify that getOpcodeID()
292         is working correctly for each opcode when USE(LLINT_EMBEDDED_OPCODE_ID).
293
294         * bytecode/BytecodeList.json:
295         * generate-bytecode-files:
296         * interpreter/Interpreter.cpp:
297         (JSC::Interpreter::Interpreter):
298         (JSC::Interpreter::opcodeIDTable):
299         (JSC::Interpreter::initialize): Deleted.
300         * interpreter/Interpreter.h:
301         (JSC::Interpreter::getOpcode):
302         (JSC::Interpreter::getOpcodeID):
303         * llint/LowLevelInterpreter.cpp:
304         * runtime/VM.cpp:
305         (JSC::VM::VM):
306
307 2017-05-27  Yusuke Suzuki  <utatane.tea@gmail.com>
308
309         [JSC] Map and Set constructors should have fast path for cloning
310         https://bugs.webkit.org/show_bug.cgi?id=172413
311
312         Reviewed by Saam Barati.
313
314         In this patch, we add a fast path for cloning in Set and Map constructors.
315
316         In ARES-6 Air, we have code like `new Set(set)` to clone the given set.
317         At that time, our generic path just iterates the given set object and add
318         it to the newly created one. It is quite slow because we need to follow
319         the iterator protocol inside C++ and we need to call set.add() repeatedly
320         while the given set guarantees the elements are unique.
321
322         This patch implements clone() function to JSMap and JSSet. Cloning JSMap
323         and JSSet are done really fast without invoking any observable JS functions.
324         To check whether we can use this clone() function in Set and Map constructors,
325         we set several watchpoints.
326
327         In the case of Set,
328
329         1. Set.prototype[Symbol.iterator] is not changed.
330         2. SetIterator.prototype.next is not changed.
331         3. Set.prototype.add is not changed.
332         4. The given Set does not have [Symbol.iterator] function in its instance.
333         5. The given Set's [[Prototype]] is Set.prototype.
334         6. Newly created set's [[Prototype]] is Set.prototype.
335
336         If the above requirements are met, cloning the given Set is not observable to users.
337         Thus we can take a fast path.
338
339         Currently, we do not integrate this optimization into DFG and FTL.
340         And we do not optimize other iterables. For example, we can optimize Set
341         constructor taking Int32 Array. And we should optimize generic iterator cases too.
342         They are planned as part of a separate bug[1].
343
344         This change improves ARES-6 Air by 5.3% in steady state.
345
346         Baseline:
347             Running... Air ( 1  to go)
348             firstIteration:     76.41 +- 15.60 ms
349             averageWorstCase:   40.63 +- 7.54 ms
350             steadyState:        9.13 +- 0.51 ms
351
352
353         Patched:
354             Running... Air ( 1  to go)
355             firstIteration:     75.00 +- 22.54 ms
356             averageWorstCase:   39.18 +- 8.45 ms
357             steadyState:        8.67 +- 0.28 ms
358
359         [1]: https://bugs.webkit.org/show_bug.cgi?id=172419
360
361         * CMakeLists.txt:
362         * JavaScriptCore.xcodeproj/project.pbxproj:
363         * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Removed.
364         * runtime/HashMapImpl.h:
365         (JSC::HashMapBucket::extractValue):
366         (JSC::HashMapImpl::finishCreation):
367         (JSC::HashMapImpl::add):
368         (JSC::HashMapImpl::setUpHeadAndTail):
369         (JSC::HashMapImpl::addNormalizedNonExistingForCloning):
370         (JSC::HashMapImpl::addNormalizedInternal):
371         * runtime/InternalFunction.cpp:
372         (JSC::InternalFunction::createSubclassStructureSlow):
373         (JSC::InternalFunction::createSubclassStructure): Deleted.
374         * runtime/InternalFunction.h:
375         (JSC::InternalFunction::createSubclassStructure):
376         * runtime/JSGlobalObject.cpp:
377         (JSC::JSGlobalObject::JSGlobalObject):
378         (JSC::JSGlobalObject::init):
379         (JSC::JSGlobalObject::visitChildren):
380         * runtime/JSGlobalObject.h:
381         (JSC::JSGlobalObject::mapIteratorProtocolWatchpoint):
382         (JSC::JSGlobalObject::setIteratorProtocolWatchpoint):
383         (JSC::JSGlobalObject::mapSetWatchpoint):
384         (JSC::JSGlobalObject::setAddWatchpoint):
385         (JSC::JSGlobalObject::mapPrototype):
386         (JSC::JSGlobalObject::jsSetPrototype):
387         (JSC::JSGlobalObject::setStructure):
388         * runtime/JSGlobalObjectInlines.h:
389         (JSC::JSGlobalObject::isMapPrototypeIteratorProtocolFastAndNonObservable):
390         (JSC::JSGlobalObject::isSetPrototypeIteratorProtocolFastAndNonObservable):
391         (JSC::JSGlobalObject::isMapPrototypeSetFastAndNonObservable):
392         (JSC::JSGlobalObject::isSetPrototypeAddFastAndNonObservable):
393         * runtime/JSMap.cpp:
394         (JSC::JSMap::clone):
395         (JSC::JSMap::canCloneFastAndNonObservable):
396         * runtime/JSMap.h:
397         (JSC::jsDynamicCast):
398         (JSC::>):
399         (JSC::JSMap::createStructure): Deleted.
400         (JSC::JSMap::create): Deleted.
401         (JSC::JSMap::set): Deleted.
402         (JSC::JSMap::JSMap): Deleted.
403         * runtime/JSSet.cpp:
404         (JSC::JSSet::clone):
405         (JSC::JSSet::canCloneFastAndNonObservable):
406         * runtime/JSSet.h:
407         (JSC::jsDynamicCast):
408         (JSC::>):
409         (JSC::JSSet::createStructure): Deleted.
410         (JSC::JSSet::create): Deleted.
411         (JSC::JSSet::JSSet): Deleted.
412         * runtime/MapConstructor.cpp:
413         (JSC::constructMap):
414         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorAdaptiveWatchpoint.h.
415         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint):
416         * runtime/SetConstructor.cpp:
417         (JSC::constructSet):
418
419 2017-05-27  Yusuke Suzuki  <utatane.tea@gmail.com>
420
421         [DOMJIT] Move DOMJIT patchpoint infrastructure out of domjit
422         https://bugs.webkit.org/show_bug.cgi?id=172260
423
424         Reviewed by Filip Pizlo.
425
426         DOMJIT::Patchpoint is now used for generalized CheckSubClass. And it becomes mature enough
427         to be used as a general-purpose injectable compiler over all the JIT tiers.
428
429         We extract DOMJIT::Patchpoint to jit/ and rename it JSC::Snippet.
430
431         * CMakeLists.txt:
432         * JavaScriptCore.xcodeproj/project.pbxproj:
433         * bytecode/AccessCaseSnippetParams.cpp: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.cpp.
434         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
435         (JSC::AccessCaseSnippetParams::emitSlowPathCalls):
436         * bytecode/AccessCaseSnippetParams.h: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.h.
437         (JSC::AccessCaseSnippetParams::AccessCaseSnippetParams):
438         * bytecode/GetterSetterAccessCase.cpp:
439         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
440         * dfg/DFGAbstractInterpreterInlines.h:
441         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
442         * dfg/DFGByteCodeParser.cpp:
443         (JSC::DFG::blessCallDOMGetter):
444         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
445         * dfg/DFGClobberize.h:
446         (JSC::DFG::clobberize):
447         * dfg/DFGFixupPhase.cpp:
448         (JSC::DFG::FixupPhase::fixupNode):
449         * dfg/DFGGraph.h:
450         * dfg/DFGNode.h:
451         * dfg/DFGSnippetParams.cpp: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.cpp.
452         * dfg/DFGSnippetParams.h: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
453         (JSC::DFG::SnippetParams::SnippetParams):
454         * dfg/DFGSpeculativeJIT.cpp:
455         (JSC::DFG::allocateTemporaryRegistersForSnippet):
456         (JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
457         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
458         (JSC::DFG::allocateTemporaryRegistersForPatchpoint): Deleted.
459         * domjit/DOMJITCallDOMGetterSnippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMGetterPatchpoint.h.
460         (JSC::DOMJIT::CallDOMGetterSnippet::create):
461         * domjit/DOMJITGetterSetter.h:
462         * domjit/DOMJITSignature.h:
463         * domjit/DOMJITValue.h: Removed.
464         * ftl/FTLLowerDFGToB3.cpp:
465         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
466         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
467         * ftl/FTLSnippetParams.cpp: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp.
468         * ftl/FTLSnippetParams.h: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
469         (JSC::FTL::SnippetParams::SnippetParams):
470         * jit/Snippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpoint.h.
471         (JSC::Snippet::create):
472         (JSC::Snippet::setGenerator):
473         (JSC::Snippet::generator):
474         * jit/SnippetParams.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
475         (JSC::SnippetParams::~SnippetParams):
476         (JSC::SnippetParams::Value::Value):
477         (JSC::SnippetParams::Value::isGPR):
478         (JSC::SnippetParams::Value::isFPR):
479         (JSC::SnippetParams::Value::isJSValueRegs):
480         (JSC::SnippetParams::Value::gpr):
481         (JSC::SnippetParams::Value::fpr):
482         (JSC::SnippetParams::Value::jsValueRegs):
483         (JSC::SnippetParams::Value::reg):
484         (JSC::SnippetParams::Value::value):
485         (JSC::SnippetParams::SnippetParams):
486         * jit/SnippetReg.h: Renamed from Source/JavaScriptCore/domjit/DOMJITReg.h.
487         (JSC::SnippetReg::SnippetReg):
488         * jit/SnippetSlowPathCalls.h: Renamed from Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h.
489         * jsc.cpp:
490         (WTF::DOMJITNode::checkSubClassSnippet):
491         (WTF::DOMJITFunctionObject::checkSubClassSnippet):
492         (WTF::DOMJITNode::checkSubClassPatchpoint): Deleted.
493         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): Deleted.
494         * runtime/ClassInfo.h:
495
496 2017-05-26  Keith Miller  <keith_miller@apple.com>
497
498         REEGRESSION(r217459): testapi fails in JSExportTest's wrapperForNSObjectisObject().
499         https://bugs.webkit.org/show_bug.cgi?id=172654
500
501         Reviewed by Mark Lam.
502
503         The test's intent is to assert that an exception has not been
504         thrown (as indicated by the message string), but the test was
505         erroneously checking for ! the right condition. This is now fixed.
506
507         * API/tests/JSExportTests.mm:
508         (wrapperForNSObjectisObject):
509
510 2017-05-26  Joseph Pecoraro  <pecoraro@apple.com>
511
512         JSContext Inspector: Improve the reliability of automatically pausing in auto-attach
513         https://bugs.webkit.org/show_bug.cgi?id=172664
514         <rdar://problem/32362933>
515
516         Reviewed by Matt Baker.
517
518         Automatically pause on connection was triggering a pause before the
519         frontend may have initialized. Often during frontend initialization
520         the frontend may perform an action that clears the pause state requested
521         by the developer. This change defers the pause until after the frontend
522         has initialized, right before returning to the application's code.
523
524         * inspector/remote/RemoteControllableTarget.h:
525         * inspector/remote/RemoteInspectionTarget.h:
526         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
527         (Inspector::RemoteConnectionToTarget::setup):
528         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
529         (Inspector::RemoteConnectionToTarget::setup):
530         * runtime/JSGlobalObjectDebuggable.cpp:
531         (JSC::JSGlobalObjectDebuggable::connect):
532         (JSC::JSGlobalObjectDebuggable::pause): Deleted.
533         * runtime/JSGlobalObjectDebuggable.h:
534         Pass an immediatelyPause boolean on to the controller. Remove
535         the current path that invokes a pause before initialization.
536
537         * inspector/JSGlobalObjectInspectorController.h:
538         * inspector/JSGlobalObjectInspectorController.cpp:
539         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
540         (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
541         Manage should immediately pause state.
542
543         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
544         (Inspector::JSGlobalObjectInspectorController::pause): Deleted.
545         When initialized, trigger a pause if requested.
546
547 2017-05-26  Mark Lam  <mark.lam@apple.com>
548
549         Temporarily commenting out a JSExportTest test until webkit.org/b/172654 is fixed.
550         https://bugs.webkit.org/show_bug.cgi?id=172655
551
552         Reviewed by Saam Barati.
553
554         * API/tests/JSExportTests.mm:
555         (wrapperForNSObjectisObject):
556
557 2017-05-26  Mark Lam  <mark.lam@apple.com>
558
559         REGRESSION(216914): testCFStrings encounters an invalid ExecState callee pointer.
560         https://bugs.webkit.org/show_bug.cgi?id=172651
561
562         Reviewed by Saam Barati.
563
564         This is because the assertion utility functions used in testCFStrings() expects
565         to get the JSGlobalContextRef from the global context variable.  However,
566         testCFStrings() creates its own JSGlobalContextRef but does not set the global
567         context variable to it.
568
569         The fix is to make testCFStrings() initialize the global context variable properly.
570
571         * API/tests/testapi.c:
572         (testCFStrings):
573
574 2017-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
575
576         Give ModuleProgram the same treatment that we did for ProgramCode in bug#167725
577         https://bugs.webkit.org/show_bug.cgi?id=167805
578
579         Reviewed by Saam Barati.
580
581         Since ModuleProgramExecutable is executed only once, we can skip compiling
582         code unreachable from the current program count. This can skip massive
583         initialization code.
584
585         We already do this for global code in bug#167725. This patch extends it to
586         module code.
587
588         * interpreter/Interpreter.cpp:
589         (JSC::Interpreter::executeModuleProgram):
590         * interpreter/Interpreter.h:
591         * jit/JIT.cpp:
592         (JSC::JIT::privateCompileMainPass):
593         * runtime/JSModuleRecord.cpp:
594         (JSC::JSModuleRecord::evaluate):
595         * runtime/JSModuleRecord.h:
596         (JSC::JSModuleRecord::moduleProgramExecutable): Deleted.
597
598 2017-05-26  Oleksandr Skachkov  <gskachkov@gmail.com>
599
600         Prevent async methods named 'function'
601         https://bugs.webkit.org/show_bug.cgi?id=172598
602
603         Reviewed by Mark Lam.
604
605         Prevent async method named 'function' in class.
606         Link to change in ecma262 specification
607         https://github.com/tc39/ecma262/pull/884
608
609         * parser/Parser.cpp:
610         (JSC::Parser<LexerType>::parseClass):
611
612 2017-05-25  Yusuke Suzuki  <utatane.tea@gmail.com>
613
614         Unreviewed, build fix for GCC
615
616         std::tuple does not have implicit constructor.
617         Thus, we cannot use implicit construction with initializer brace.
618         We should specify the name like `GetInst { }`.
619
620         * bytecompiler/BytecodeGenerator.h:
621         (JSC::StructureForInContext::addGetInst):
622
623 2017-05-25  Keith Miller  <keith_miller@apple.com>
624
625         Cleanup tests after r217240
626         https://bugs.webkit.org/show_bug.cgi?id=172466
627
628         Reviewed by Mark Lam.
629
630         I forgot to make my test an actual test. Also, remove second call runJSExportTests()
631
632         * API/tests/JSExportTests.mm:
633         (wrapperForNSObjectisObject):
634         * API/tests/testapi.mm:
635         (testObjectiveCAPIMain):
636
637 2017-05-25  Michael Saboff  <msaboff@apple.com>
638
639         The default setting of Option::criticalGCMemoryThreshold is too high for iOS
640         https://bugs.webkit.org/show_bug.cgi?id=172617
641
642         Reviewed by Mark Lam.
643
644         Reducing criticalGCMemoryThreshold to 0.80 eliminated jetsam on iOS devices
645         when tested running JetStream.
646
647         * runtime/Options.h:
648
649 2017-05-25  Saam Barati  <sbarati@apple.com>
650
651         Our for-in optimization in the bytecode generator does its static analysis incorrectly
652         https://bugs.webkit.org/show_bug.cgi?id=172532
653         <rdar://problem/32369452>
654
655         Reviewed by Mark Lam.
656
657         Our static analysis for when a for-in induction variable
658         is written to tried to its analysis as we generate
659         bytecode. This has issues, since it does not account for
660         the dynamic execution path of the program. Let's consider
661         a program where our old analysis worked:
662         
663         ```
664         for (let p in o) {
665             o[p]; // We can transform this into a fast get_direct_pname
666             p = 20;
667             o[p]; // We cannot transform this since p has been changed.
668         }
669         ```
670         
671         However, our static analysis did not account for loops, which exist
672         in JavaScript. e.g, it would incorrectly compile this program as:
673         ```
674         for (let p in o) {
675             for (let i = 0; i < 20; ++i) {
676                 o[p]; // It transforms this to use get_direct_pname even though p will be over-written if we get here from the inner loop back edge!
677                 p = 20;
678                 o[p]; // We correctly do not transform this.
679             } 
680         }
681         ```
682         
683         Because of this flaw, I've made the optimization more conservative.
684         We now optimistically emit code for the optimized access. However,
685         if a for-in context is *ever* invalidated, before we pop it off
686         the stack, we rewrite the program's optimized accesses to no longer
687         be optimized. To do this, each context keeps track of its optimized
688         accesses.
689         
690         This patch also adds a new bytecode, op_nop, which is just a no-op.
691         It was helpful to add this because reverting get_direct_pname to get_by_val
692         will leave us with an extra instruction word because get_direct_pname is
693         has a length of 7 where get_by_val has a length of 6. This leaves us with
694         an extra slot that we fill with an op_nop.
695
696         * bytecode/BytecodeDumper.cpp:
697         (JSC::BytecodeDumper<Block>::dumpBytecode):
698         * bytecode/BytecodeList.json:
699         * bytecode/BytecodeUseDef.h:
700         (JSC::computeUsesForBytecodeOffset):
701         (JSC::computeDefsForBytecodeOffset):
702         * bytecompiler/BytecodeGenerator.cpp:
703         (JSC::BytecodeGenerator::emitGetByVal):
704         (JSC::BytecodeGenerator::popIndexedForInScope):
705         (JSC::BytecodeGenerator::popStructureForInScope):
706         (JSC::BytecodeGenerator::invalidateForInContextForLocal):
707         (JSC::StructureForInContext::pop):
708         (JSC::IndexedForInContext::pop):
709         * bytecompiler/BytecodeGenerator.h:
710         (JSC::StructureForInContext::addGetInst):
711         (JSC::IndexedForInContext::addGetInst):
712         * dfg/DFGByteCodeParser.cpp:
713         (JSC::DFG::ByteCodeParser::parseBlock):
714         * dfg/DFGCapabilities.cpp:
715         (JSC::DFG::capabilityLevel):
716         * jit/JIT.cpp:
717         (JSC::JIT::privateCompileMainPass):
718         * jit/JIT.h:
719         * jit/JITOpcodes.cpp:
720         (JSC::JIT::emit_op_nop):
721         * llint/LowLevelInterpreter.asm:
722
723 2017-05-25  Mark Lam  <mark.lam@apple.com>
724
725         ObjectToStringAdaptiveInferredPropertyValueWatchpoint should not reinstall itself nor handleFire if it's dying shortly.
726         https://bugs.webkit.org/show_bug.cgi?id=172548
727         <rdar://problem/31458393>
728
729         Reviewed by Filip Pizlo.
730
731         Consider the following scenario:
732
733         1. A ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1, watches for
734            structure transitions, e.g. structure S2 transitioning to structure S3.
735            In this case, O1 would be installed in S2's watchpoint set.
736         2. When the structure transition happens, structure S2 will fire watchpoint O1.
737         3. O1's handler will normally re-install itself in the watchpoint set of the new
738            "transitioned to" structure S3.
739         4. "Installation" here requires writing into the StructureRareData SD3 of the new
740            structure S3.  If SD3 does not exist yet, the installation process will trigger
741            the allocation of StructureRareData SD3.
742         5. It is possible that the Structure S1, and StructureRareData SD1 that owns the
743            ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1 is no longer reachable
744            by the GC, and therefore will be collected soon.
745         6. The allocation of SD3 in (4) may trigger the sweeping of the StructureRareData
746            SD1.  This, in turn, triggers the deletion of the
747            ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1.
748
749         After O1 is deleted in (6) and SD3 is allocated in (4), execution continues in
750         AdaptiveInferredPropertyValueWatchpointBase::fire() where O1 gets installed in
751         structure S3's watchpoint set.  This is obviously incorrect because O1 is already
752         deleted.  The result is that badness happens later when S3's watchpoint set fires
753         its watchpoints and accesses the deleted O1.
754
755         The fix is to enhance AdaptiveInferredPropertyValueWatchpointBase::fire() to
756         check if "this" is still valid before proceeding to re-install itself or to
757         invoke its handleFire() method.
758
759         ObjectToStringAdaptiveInferredPropertyValueWatchpoint (which extends
760         AdaptiveInferredPropertyValueWatchpointBase) will override its isValid() method,
761         and return false its owner StructureRareData is no longer reachable by the GC.
762         This ensures that it won't be deleted while it's installed to any watchpoint set.
763
764         Additional considerations and notes:
765         1. In the above, I talked about the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
766            being installed in watchpoint sets.  What actually happens is that
767            ObjectToStringAdaptiveInferredPropertyValueWatchpoint has 2 members
768            (m_structureWatchpoint and m_propertyWatchpoint) which may be installed in
769            watchpoint sets.  The ObjectToStringAdaptiveInferredPropertyValueWatchpoint is
770            not itself a Watchpoint object.
771
772            But for brevity, in the above, I refer to the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
773            instead of its Watchpoint members.  The description of the issue is still
774            accurate given the life-cycle of the Watchpoint members are embedded in the
775            enclosing ObjectToStringAdaptiveInferredPropertyValueWatchpoint object, and
776            hence, they share the same life-cycle.
777
778         2. The top of AdaptiveInferredPropertyValueWatchpointBase::fire() removes its
779            m_structureWatchpoint and m_propertyWatchpoint if they have been added to any
780            watchpoint sets.  This is safe to do even if the owner StructureRareData is no
781            longer reachable by the GC.
782
783            This is because the only way we can get to AdaptiveInferredPropertyValueWatchpointBase::fire()
784            is if its Watchpoint members are still installed in some watchpoint set that
785            fired.  This means that the AdaptiveInferredPropertyValueWatchpointBase
786            instance has not been deleted yet, because its destructor will automatically
787            remove the Watchpoint members from any watchpoint sets.
788
789         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
790         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
791         (JSC::AdaptiveInferredPropertyValueWatchpointBase::isValid):
792         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
793         * heap/FreeList.cpp:
794         (JSC::FreeList::contains):
795         * heap/FreeList.h:
796         * heap/HeapCell.h:
797         * heap/HeapCellInlines.h:
798         (JSC::HeapCell::isLive):
799         * heap/MarkedAllocator.h:
800         (JSC::MarkedAllocator::isFreeListedCell):
801         * heap/MarkedBlock.h:
802         * heap/MarkedBlockInlines.h:
803         (JSC::MarkedBlock::Handle::isFreeListedCell):
804         * runtime/StructureRareData.cpp:
805         (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid):
806
807 2017-05-23  Saam Barati  <sbarati@apple.com>
808
809         We should not mmap zero bytes for a memory in Wasm
810         https://bugs.webkit.org/show_bug.cgi?id=172528
811         <rdar://problem/32257076>
812
813         Reviewed by Mark Lam.
814
815         This patch fixes a bug where we would call into mmap with zero bytes
816         when creating a slow WasmMemory with zero initial page size. This fix
817         is simple: if we don't have any initial bytes, we just call the constructor
818         in WasmMemory that's meant to handle this case.
819
820         * wasm/WasmMemory.cpp:
821         (JSC::Wasm::Memory::create):
822
823 2017-05-23  Brian Burg  <bburg@apple.com>
824
825         REGRESSION(r217051): Automation sessions fail to complete bootstrap
826         https://bugs.webkit.org/show_bug.cgi?id=172513
827         <rdar://problem/32338354>
828
829         Reviewed by Joseph Pecoraro.
830
831         The changes to be more strict about typechecking messages were too strict.
832
833         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
834         (Inspector::RemoteInspector::receivedSetupMessage):
835         WIRAutomatically is an optional key in the setup message. In the relay, this key gets copied
836         into an NSDictionary as NSNull if the key isn't present in a forwarded command.
837         We need to revert NSNull values to nil, since it's valid to call [nil boolValue] but not
838         [[NSNull null] boolValue]. We also need to allow for nil in the typecheck for this key.
839
840 2017-05-23  Myles C. Maxfield  <mmaxfield@apple.com>
841
842         Remove dead ENABLE(FONT_LOAD_EVENTS) code
843         https://bugs.webkit.org/show_bug.cgi?id=172517
844
845         Rubber-stamped by Simon Fraser.
846
847         * Configurations/FeatureDefines.xcconfig:
848
849 2017-05-23  Saam Barati  <sbarati@apple.com>
850
851         CFGSimplificationPhase should not merge a block with itself
852         https://bugs.webkit.org/show_bug.cgi?id=172508
853         <rdar://problem/28424006>
854
855         Reviewed by Keith Miller.
856
857         CFGSimplificationPhase can run into or create IR that ends up with a
858         block that has a Jump to itself, and no other predecessors. It should
859         gracefully handle such IR. Before this patch, it would not. The only criteria
860         for merging 'block' with 'targetBlock' used to be that 'targetBlock.predecessors.size() == 1'.
861         The code is written in such a way that if we merge a block with itself, we
862         will infinite loop until we run out of memory.
863         
864         Merging a block with itself does not make sense for a few reasons. First,
865         we're joining the contents of two blocks. What is the definition of joining
866         a block with itself? I suppose we could simply unroll this self loop
867         one level, but that would not be wise because this self loop is by definition
868         unreachable unless it's the root block in the graph (which I think is
869         invalid IR since we'd never generate bytecode that would do this).
870         
871         This patch employs an easy fix: we can't merge a block with itself.
872
873         * dfg/DFGCFGSimplificationPhase.cpp:
874         (JSC::DFG::CFGSimplificationPhase::canMergeBlocks):
875         (JSC::DFG::CFGSimplificationPhase::run):
876         (JSC::DFG::CFGSimplificationPhase::convertToJump):
877         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
878
879 2017-05-22  Brian Burg  <bburg@apple.com>
880
881         Web Inspector: webkit reload policy should match default behavior
882         https://bugs.webkit.org/show_bug.cgi?id=171385
883         <rdar://problem/31871515>
884
885         Reviewed by Joseph Pecoraro.
886
887         Add a new option to Page.reload that allows the test harness
888         to reload its test page using the old reload behavior.
889
890         The new behavior of revalidating expired cached subresources only
891         is the current default, since only the test harness needs the old behavior.
892
893         * inspector/protocol/Page.json:
894
895 2017-05-22  Keith Miller  <keith_miller@apple.com>
896
897         [Cocoa] An exported Objective C class’s prototype and constructor don't persist across JSContext deallocation
898         https://bugs.webkit.org/show_bug.cgi?id=167708
899
900         Reviewed by Geoffrey Garen.
901
902         This patch moves the Objective C wrapper map to the global object. In order to make this work the JSWrapperMap
903         class no longer holds a reference to the JSContext. Instead, the context must be provided when getting a wrapper.
904
905         Also, this patch fixes a "bug" where we would observe changes to the Object property on the global object when
906         creating a wrapper for NSObject.
907
908         * API/APICast.h:
909         (toJSGlobalObject):
910         * API/JSContext.mm:
911         (-[JSContext ensureWrapperMap]):
912         (-[JSContext initWithVirtualMachine:]):
913         (-[JSContext dealloc]):
914         (-[JSContext wrapperMap]):
915         (-[JSContext initWithGlobalContextRef:]):
916         (-[JSContext wrapperForObjCObject:]):
917         (-[JSContext wrapperForJSObject:]):
918         * API/JSWrapperMap.h:
919         * API/JSWrapperMap.mm:
920         (-[JSObjCClassInfo initForClass:]):
921         (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
922         (-[JSObjCClassInfo wrapperForObject:inContext:]):
923         (-[JSObjCClassInfo constructorInContext:]):
924         (-[JSObjCClassInfo prototypeInContext:]):
925         (-[JSWrapperMap initWithGlobalContextRef:]):
926         (-[JSWrapperMap classInfoForClass:]):
927         (-[JSWrapperMap jsWrapperForObject:inContext:]):
928         (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
929         (-[JSObjCClassInfo initWithContext:forClass:]): Deleted.
930         (-[JSObjCClassInfo allocateConstructorAndPrototype]): Deleted.
931         (-[JSObjCClassInfo wrapperForObject:]): Deleted.
932         (-[JSObjCClassInfo constructor]): Deleted.
933         (-[JSObjCClassInfo prototype]): Deleted.
934         (-[JSWrapperMap initWithContext:]): Deleted.
935         (-[JSWrapperMap jsWrapperForObject:]): Deleted.
936         (-[JSWrapperMap objcWrapperForJSValueRef:]): Deleted.
937         * API/tests/JSExportTests.mm:
938         (wrapperLifetimeIsTiedToGlobalObject):
939         (runJSExportTests):
940         * API/tests/testapi.mm:
941         * runtime/JSGlobalObject.h:
942         (JSC::JSGlobalObject::wrapperMap):
943         (JSC::JSGlobalObject::setWrapperMap):
944
945 2017-05-22  Filip Pizlo  <fpizlo@apple.com>
946
947         FTL stack overflow handling should not assume that B3 never selects callee-saves in the prologue
948         https://bugs.webkit.org/show_bug.cgi?id=172455
949
950         Reviewed by Mark Lam.
951         
952         The FTL needs to run B3's callee-save register restoration before it runs the exception
953         handler's callee-save register restoration.  This exposes B3's callee-save register
954         algorithm in AssemblyHelpers so that the FTL can call it.
955
956         * b3/air/AirGenerate.cpp:
957         (JSC::B3::Air::generate):
958         * ftl/FTLLowerDFGToB3.cpp:
959         (JSC::FTL::DFG::LowerDFGToB3::lower): Fix the bug.
960         * heap/Subspace.cpp: Added some debugging support.
961         (JSC::Subspace::allocate):
962         (JSC::Subspace::tryAllocate):
963         (JSC::Subspace::didAllocate):
964         * heap/Subspace.h:
965         * jit/AssemblyHelpers.h:
966         (JSC::AssemblyHelpers::addressFor):
967         (JSC::AssemblyHelpers::emitSave):
968         (JSC::AssemblyHelpers::emitRestore):
969
970 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
971
972         [FTL] Support GetByVal with ArrayStorage and SlowPutArrayStorage
973         https://bugs.webkit.org/show_bug.cgi?id=172216
974
975         Reviewed by Saam Barati.
976
977         This patch adds GetByVal support for ArrayStorage and SlowPutArrayStorage.
978         To lower CheckInBounds in FTL, we add a new GetVectorLength op. It only accepts
979         ArrayStorage and SlowPutArrayStorage, then it produces vector length.
980         CheckInBounds uses this vector length to perform bound checking for ArrayStorage
981         and SlowPutArrayStorage.
982
983         * dfg/DFGAbstractInterpreterInlines.h:
984         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
985         * dfg/DFGArrayMode.cpp:
986         (JSC::DFG::permitsBoundsCheckLowering):
987         * dfg/DFGClobberize.h:
988         (JSC::DFG::clobberize):
989         * dfg/DFGDoesGC.cpp:
990         (JSC::DFG::doesGC):
991         * dfg/DFGFixupPhase.cpp:
992         (JSC::DFG::FixupPhase::fixupNode):
993         * dfg/DFGHeapLocation.cpp:
994         (WTF::printInternal):
995         * dfg/DFGHeapLocation.h:
996         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
997         * dfg/DFGNode.h:
998         (JSC::DFG::Node::hasArrayMode):
999         * dfg/DFGNodeType.h:
1000         * dfg/DFGPredictionPropagationPhase.cpp:
1001         * dfg/DFGSSALoweringPhase.cpp:
1002         (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
1003         * dfg/DFGSafeToExecute.h:
1004         (JSC::DFG::safeToExecute):
1005         * dfg/DFGSpeculativeJIT32_64.cpp:
1006         (JSC::DFG::SpeculativeJIT::compile):
1007         * dfg/DFGSpeculativeJIT64.cpp:
1008         (JSC::DFG::SpeculativeJIT::compile):
1009         * ftl/FTLAbstractHeapRepository.h:
1010         (JSC::FTL::AbstractHeapRepository::forIndexingType):
1011         (JSC::FTL::AbstractHeapRepository::forArrayType):
1012         * ftl/FTLCapabilities.cpp:
1013         (JSC::FTL::canCompile):
1014         * ftl/FTLLowerDFGToB3.cpp:
1015         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1016         (JSC::FTL::DFG::LowerDFGToB3::compileGetVectorLength):
1017         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1018         * jit/JITPropertyAccess.cpp:
1019         (JSC::JIT::emitArrayStoragePutByVal):
1020         * jit/JITPropertyAccess32_64.cpp:
1021         (JSC::JIT::emitArrayStorageLoad):
1022         (JSC::JIT::emitArrayStoragePutByVal):
1023
1024 2017-05-21  Saam Barati  <sbarati@apple.com>
1025
1026         We incorrectly throw a syntax error when declaring a top level for-loop iteration variable the same as a parameter
1027         https://bugs.webkit.org/show_bug.cgi?id=171041
1028         <rdar://problem/32082516>
1029
1030         Reviewed by Yusuke Suzuki.
1031
1032         We were treating a for-loop variable declaration potentially as a top
1033         level statement, e.g, in a program like this:
1034         ```
1035         function foo() {
1036             for (let variable of expr) { }
1037         }
1038         ```
1039         But we should not be. This had the consequence of making this type of program
1040         throw a syntax error:
1041         ```
1042         function foo(arg) {
1043             for (let arg of expr) { }
1044         }
1045         ```
1046         even though it should not. The fix is simple, we just need to increment the
1047         statement depth before parsing anything inside the for loop.
1048
1049         * parser/Parser.cpp:
1050         (JSC::Parser<LexerType>::parseForStatement):
1051
1052 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1053
1054         [JSC] Make get_by_val & string "499" to number 499
1055         https://bugs.webkit.org/show_bug.cgi?id=172225
1056
1057         Reviewed by Saam Barati.
1058
1059         Property subscript will be converted by ToString. So JS code is not aware of
1060         the original type of the subscript value. But our get_by_val can leverage
1061         information if the given subscript is number. Thus, passing number instead of
1062         string can improve the performance of get_by_val in all the tiers.
1063
1064         In this patch, we add BytecodeGenerator::emitNodeForProperty. It attempts to
1065         convert the given value to Int32 index constant if the given value is a string
1066         that can be converted to Int32.
1067
1068         This patch improves SixSpeed map-string.es5 by 9.8x. This accessing form can
1069         appear in some code like accessing the result of JSON.
1070
1071             map-string.es5     1640.6738+-110.9182   ^    167.4121+-23.8328       ^ definitely 9.8002x faster
1072
1073         * bytecompiler/BytecodeGenerator.h:
1074         (JSC::BytecodeGenerator::emitNodeForProperty):
1075         (JSC::BytecodeGenerator::emitNodeForLeftHandSideForProperty):
1076         * bytecompiler/NodesCodegen.cpp:
1077         (JSC::TaggedTemplateNode::emitBytecode):
1078         (JSC::BracketAccessorNode::emitBytecode):
1079         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
1080         (JSC::FunctionCallBracketNode::emitBytecode):
1081         (JSC::PostfixNode::emitBracket):
1082         (JSC::PrefixNode::emitBracket):
1083         (JSC::AssignBracketNode::emitBytecode):
1084         (JSC::ReadModifyBracketNode::emitBytecode):
1085         (JSC::ForInNode::emitLoopHeader):
1086         (JSC::ForOfNode::emitBytecode):
1087         (JSC::ObjectPatternNode::bindValue):
1088         (JSC::AssignmentElementNode::bindValue):
1089
1090 2017-05-21  Saam Barati  <sbarati@apple.com>
1091
1092         We overwrite the callee save space on the stack when throwing stack overflow from wasm
1093         https://bugs.webkit.org/show_bug.cgi?id=172316
1094
1095         Reviewed by Mark Lam.
1096
1097         When throwing a stack overflow exception, the overflow
1098         thunk would do the following:
1099           move fp, sp
1100           populate argument registers
1101           call C code
1102         
1103         However, the C function is allowed to clobber our spilled
1104         callee saves that live below fp. The reason I did this move is that
1105         when we jump to this code, we've proven that sp is out of bounds on
1106         the stack. So we're not allowed to just use its value or keep growing
1107         the stack from that point. However, this patch revises this approach
1108         to be the same in spirit, but actually correct. We conservatively assume
1109         the B3 function we're coming from could have saved all callee saves.
1110         So we emit code like this now:
1111           add -maxNumCalleeSaveSpace, fp, sp
1112           populate argument registers
1113           call C code
1114         
1115         This ensures our callee saves will not be overwritten. Note
1116         that fp is still in a valid stack range here, since the thing
1117         calling the wasm code did a stack check. Also note that maxNumCalleeSaveSpace
1118         is less than our redzone size, so it's safe to decrement sp by 
1119         this amount.
1120         
1121         The previously added wasm stack overflow test is an instance crash
1122         without this change on arm64. It also appears that this test crashed
1123         on some other x86 devices.
1124
1125         * wasm/WasmThunks.cpp:
1126         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
1127
1128 2017-05-20  Chris Dumez  <cdumez@apple.com>
1129
1130         Drop [NoInterfaceObject] from RTCDTMFSender and RTCStatsReport
1131         https://bugs.webkit.org/show_bug.cgi?id=172418
1132
1133         Reviewed by Youenn Fablet.
1134
1135         Add CommonIdentifiers that are now needed.
1136
1137         * runtime/CommonIdentifiers.h:
1138
1139 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1140
1141         Unreviewed, add scope.release() to propertyIsEnumerable functions.
1142         https://bugs.webkit.org/show_bug.cgi?id=172411
1143
1144         * runtime/JSGlobalObjectFunctions.cpp:
1145         (JSC::globalFuncPropertyIsEnumerable):
1146         * runtime/ObjectPrototype.cpp:
1147         (JSC::objectProtoFuncPropertyIsEnumerable):
1148
1149 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1150
1151         [JSC] Drop MapBase
1152         https://bugs.webkit.org/show_bug.cgi?id=172417
1153
1154         Reviewed by Sam Weinig.
1155
1156         MapBase is a purely additional indirection. JSMap and JSSet can directly inherit HashMapImpl.
1157         Thus MapBase is unnecessary. This patch drops it.
1158         It is good because we can eliminate one indirection when accessing to map implementation.
1159         Moreover, we can drop one unnecessary allocation per Map and Set.
1160
1161         * CMakeLists.txt:
1162         * JavaScriptCore.xcodeproj/project.pbxproj:
1163         * dfg/DFGSpeculativeJIT64.cpp:
1164         (JSC::DFG::SpeculativeJIT::compile):
1165         * ftl/FTLAbstractHeapRepository.h:
1166         * ftl/FTLLowerDFGToB3.cpp:
1167         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
1168         * runtime/HashMapImpl.cpp:
1169         (JSC::HashMapImpl<HashMapBucket>::estimatedSize):
1170         (JSC::getHashMapImplKeyClassInfo): Deleted.
1171         (JSC::getHashMapImplKeyValueClassInfo): Deleted.
1172         * runtime/HashMapImpl.h:
1173         (JSC::HashMapImpl::finishCreation):
1174         (JSC::HashMapImpl::get):
1175         (JSC::HashMapImpl::info): Deleted.
1176         (JSC::HashMapImpl::createStructure): Deleted.
1177         (JSC::HashMapImpl::create): Deleted.
1178         * runtime/JSMap.h:
1179         (JSC::JSMap::set):
1180         (JSC::JSMap::get): Deleted.
1181         * runtime/JSMapIterator.cpp:
1182         (JSC::JSMapIterator::finishCreation):
1183         * runtime/JSSet.h:
1184         (JSC::JSSet::add): Deleted.
1185         * runtime/JSSetIterator.cpp:
1186         (JSC::JSSetIterator::finishCreation):
1187         * runtime/MapBase.cpp: Removed.
1188         * runtime/MapBase.h: Removed.
1189         * runtime/MapPrototype.cpp:
1190         (JSC::mapProtoFuncSize):
1191         * runtime/SetConstructor.cpp:
1192         (JSC::constructSet):
1193         * runtime/SetPrototype.cpp:
1194         (JSC::setProtoFuncSize):
1195         * runtime/VM.cpp:
1196         (JSC::VM::VM):
1197
1198 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1199
1200         [JSC] Speedup Object.assign for slow case by using propertyIsEnumerable
1201         https://bugs.webkit.org/show_bug.cgi?id=172411
1202
1203         Reviewed by Sam Weinig.
1204
1205         We use @Reflect.@getOwnPropertyDescriptor() to check
1206
1207         1. the descriptor exists,
1208         2. and the descriptor.enumrable is true
1209
1210         But Object::propertyIsEnumerable does the completely same thing without
1211         allocating a new object for property descriptor.
1212
1213         In this patch, we add a new private function @propertyIsEnumerable, and
1214         use it in Object.assign implementation. It does not allocate unnecessary
1215         objects. It is good for GC-pressure and performance.
1216
1217         This patch improves SixSpeed object-assign.es6 by 1.7x. While this patch
1218         does not introduce a fast path for objects that do not have accessors,
1219         and it could speed up things further, this patch can speed up the common
1220         slow path cases that is the current implementation of Object.assign.
1221
1222             object-assign.es6     1103.2487+-21.5602    ^    621.8478+-34.9875       ^ definitely 1.7741x faster
1223
1224         * builtins/BuiltinNames.h:
1225         * builtins/ObjectConstructor.js:
1226         (globalPrivate.enumerableOwnProperties):
1227         (assign):
1228         * runtime/JSGlobalObject.cpp:
1229         (JSC::JSGlobalObject::init):
1230         * runtime/JSGlobalObjectFunctions.cpp:
1231         (JSC::globalFuncPropertyIsEnumerable):
1232         * runtime/JSGlobalObjectFunctions.h:
1233
1234 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1235
1236         [JSC] Enable testapi on Mac CMake build
1237         https://bugs.webkit.org/show_bug.cgi?id=172354
1238
1239         Reviewed by Alex Christensen.
1240
1241         This patch makes testapi buildable and runnable for Mac CMake port.
1242
1243         * API/tests/DateTests.mm:
1244         (+[DateTests JSDateToNSDateTest]):
1245         (+[DateTests roundTripThroughJSDateTest]):
1246         This test only works with the en_US locale.
1247
1248         * shell/CMakeLists.txt:
1249         * shell/PlatformMac.cmake:
1250         Some of tests rely on ARC. We enable ARC for those files.
1251
1252         * shell/PlatformWin.cmake:
1253         Clean up.
1254
1255 2017-05-19  Mark Lam  <mark.lam@apple.com>
1256
1257         [Re-landing] DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
1258         https://bugs.webkit.org/show_bug.cgi?id=172383
1259         <rdar://problem/31418651>
1260
1261         Reviewed by Filip Pizlo.
1262
1263         pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
1264         available as a scratch register.  This assumption is wrong if this canTrample
1265         register is used for a silentFill() after an operation that returns a result in
1266         regT0 or regT1.
1267
1268         Turns out the only reason we need the canTrample register is for
1269         SetDoubleConstant.  We can remove the need for this canTrample register by
1270         introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
1271         job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
1272         ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.
1273
1274         Update for re-landing: Changed ARM64 to use scratchRegister() as well.
1275         scratchRegister() is the proper way to get the underlying dataMemoryTempRegister()
1276         as a scratch register.
1277
1278         * assembler/MacroAssembler.h:
1279         (JSC::MacroAssembler::moveDouble):
1280         * dfg/DFGArrayifySlowPathGenerator.h:
1281         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1282         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1283         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1284         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1285         * dfg/DFGSlowPathGenerator.h:
1286         (JSC::DFG::CallSlowPathGenerator::tearDown):
1287         * dfg/DFGSpeculativeJIT.cpp:
1288         (JSC::DFG::SpeculativeJIT::silentFill):
1289         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1290         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1291         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1292         (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
1293         (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
1294         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1295         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1296         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1297         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1298         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1299         * dfg/DFGSpeculativeJIT.h:
1300         (JSC::DFG::SpeculativeJIT::silentFill):
1301         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1302         (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
1303         (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
1304         * dfg/DFGSpeculativeJIT32_64.cpp:
1305         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1306         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1307         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1308         (JSC::DFG::SpeculativeJIT::emitCall):
1309         (JSC::DFG::SpeculativeJIT::compile):
1310         * dfg/DFGSpeculativeJIT64.cpp:
1311         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1312         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1313         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1314         (JSC::DFG::SpeculativeJIT::emitCall):
1315         (JSC::DFG::SpeculativeJIT::compile):
1316         (JSC::DFG::SpeculativeJIT::convertAnyInt):
1317
1318 2017-05-19  Ryan Haddad  <ryanhaddad@apple.com>
1319
1320         Unreviewed, rolling out r217156.
1321
1322         This change broke the iOS build.
1323
1324         Reverted changeset:
1325
1326         "DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring
1327         result registers."
1328         https://bugs.webkit.org/show_bug.cgi?id=172383
1329         http://trac.webkit.org/changeset/217156
1330
1331 2017-05-19  Mark Lam  <mark.lam@apple.com>
1332
1333         Add missing exception check.
1334         https://bugs.webkit.org/show_bug.cgi?id=172346
1335         <rdar://problem/32289640>
1336
1337         Reviewed by Geoffrey Garen.
1338
1339         * runtime/JSObject.cpp:
1340         (JSC::JSObject::hasInstance):
1341
1342 2017-05-19  Mark Lam  <mark.lam@apple.com>
1343
1344         DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
1345         https://bugs.webkit.org/show_bug.cgi?id=172383
1346         <rdar://problem/31418651>
1347
1348         Reviewed by Filip Pizlo.
1349
1350         pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
1351         available as a scratch register.  This assumption is wrong if this canTrample
1352         register is used for a silentFill() after an operation that returns a result in
1353         regT0 or regT1.
1354
1355         Turns out the only reason we need the canTrample register is for
1356         SetDoubleConstant.  We can remove the need for this canTrample register by
1357         introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
1358         job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
1359         ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.
1360
1361         * assembler/MacroAssembler.h:
1362         (JSC::MacroAssembler::moveDouble):
1363         * dfg/DFGArrayifySlowPathGenerator.h:
1364         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1365         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1366         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1367         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1368         * dfg/DFGSlowPathGenerator.h:
1369         (JSC::DFG::CallSlowPathGenerator::tearDown):
1370         * dfg/DFGSpeculativeJIT.cpp:
1371         (JSC::DFG::SpeculativeJIT::silentFill):
1372         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1373         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1374         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1375         (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
1376         (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
1377         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1378         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1379         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1380         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1381         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1382         * dfg/DFGSpeculativeJIT.h:
1383         (JSC::DFG::SpeculativeJIT::silentFill):
1384         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1385         (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
1386         (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
1387         * dfg/DFGSpeculativeJIT32_64.cpp:
1388         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1389         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1390         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1391         (JSC::DFG::SpeculativeJIT::emitCall):
1392         (JSC::DFG::SpeculativeJIT::compile):
1393         * dfg/DFGSpeculativeJIT64.cpp:
1394         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1395         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1396         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1397         (JSC::DFG::SpeculativeJIT::emitCall):
1398         (JSC::DFG::SpeculativeJIT::compile):
1399         (JSC::DFG::SpeculativeJIT::convertAnyInt):
1400
1401 2017-05-19  Filip Pizlo  <fpizlo@apple.com>
1402
1403         Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy
1404         https://bugs.webkit.org/show_bug.cgi?id=172382
1405
1406         Reviewed by Saam Barati.
1407         
1408         This is just a small clean-up - my last patch here created some unnecessary code duplication.
1409
1410         * runtime/ArrayPrototype.cpp:
1411         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1412
1413 2017-05-19  Filip Pizlo  <fpizlo@apple.com>
1414
1415         arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided
1416         https://bugs.webkit.org/show_bug.cgi?id=172369
1417
1418         Reviewed by Mark Lam.
1419
1420         * heap/Subspace.cpp: Reshaped the code a bit to aid debugging.
1421         (JSC::Subspace::allocate):
1422         (JSC::Subspace::tryAllocate):
1423         * runtime/ArrayPrototype.cpp:
1424         (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug!
1425         * runtime/ObjectInitializationScope.cpp: Provide even better feedback.
1426         (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
1427
1428 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
1429
1430         B3::Value::effects() says that having a fence range implies the fence bit, but on x86_64 we lower loadAcq/storeRel to load/store so the store-before-load fence bit orderings won't be honored
1431         https://bugs.webkit.org/show_bug.cgi?id=172306
1432
1433         Reviewed by Michael Saboff.
1434         
1435         This changes B3 to emit xchg and its variants for fenced stores on x86. This ensures that
1436         fenced stores cannot be reordered around other fenced instructions. Previously, B3 emitted
1437         normal store instructions for fenced stores. That's wrong because then you get reorderings
1438         that are possible in TSO but impossible in SC. Fenced instructions are supposed to be SC
1439         with respect for each other.
1440         
1441         This is imprecise. If you really just wanted a store-release, then every X86 store does this.
1442         But, in B3, fenced stores are ARM-style store-release, meaning that they are fenced with
1443         respect to all other fences. If we ever did want to say that something is a store release in
1444         the traditional sense, then we'd want MemoryValue to have a fence flag. Then, having a fence
1445         range without the fence flag would mean the traditional store-release, which lowers to a
1446         normal store on x86. But to my knowledge, that traditional store-release is only useful for
1447         unlocking spinlocks. We don't use spinlocks in JSC. Adaptive locks require CAS for unlock,
1448         and B3 CAS is plenty fast. I think it's OK to have this small imprecision of giving clients
1449         an ARM-style store-release on x86 using xchg.
1450         
1451         The implication of this change is that the FTL no longer violates the SAB memory model.
1452
1453         * assembler/MacroAssemblerX86Common.h:
1454         (JSC::MacroAssemblerX86Common::xchg8):
1455         (JSC::MacroAssemblerX86Common::xchg16):
1456         (JSC::MacroAssemblerX86Common::xchg32):
1457         (JSC::MacroAssemblerX86Common::loadAcq8): Deleted.
1458         (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32): Deleted.
1459         (JSC::MacroAssemblerX86Common::loadAcq16): Deleted.
1460         (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32): Deleted.
1461         (JSC::MacroAssemblerX86Common::loadAcq32): Deleted.
1462         (JSC::MacroAssemblerX86Common::storeRel8): Deleted.
1463         (JSC::MacroAssemblerX86Common::storeRel16): Deleted.
1464         (JSC::MacroAssemblerX86Common::storeRel32): Deleted.
1465         * assembler/MacroAssemblerX86_64.h:
1466         (JSC::MacroAssemblerX86_64::xchg64):
1467         (JSC::MacroAssemblerX86_64::loadAcq64): Deleted.
1468         (JSC::MacroAssemblerX86_64::storeRel64): Deleted.
1469         * b3/B3LowerToAir.cpp:
1470         (JSC::B3::Air::LowerToAir::ArgPromise::inst):
1471         (JSC::B3::Air::LowerToAir::trappingInst):
1472         (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
1473         (JSC::B3::Air::LowerToAir::createStore):
1474         (JSC::B3::Air::LowerToAir::storeOpcode):
1475         (JSC::B3::Air::LowerToAir::appendStore):
1476         (JSC::B3::Air::LowerToAir::append):
1477         (JSC::B3::Air::LowerToAir::appendTrapping):
1478         (JSC::B3::Air::LowerToAir::fillStackmap):
1479         (JSC::B3::Air::LowerToAir::lower):
1480         * b3/air/AirKind.cpp:
1481         (JSC::B3::Air::Kind::dump):
1482         * b3/air/AirKind.h:
1483         (JSC::B3::Air::Kind::Kind):
1484         (JSC::B3::Air::Kind::operator==):
1485         (JSC::B3::Air::Kind::hash):
1486         * b3/air/AirLowerAfterRegAlloc.cpp:
1487         (JSC::B3::Air::lowerAfterRegAlloc):
1488         * b3/air/AirLowerMacros.cpp:
1489         (JSC::B3::Air::lowerMacros):
1490         * b3/air/AirOpcode.opcodes:
1491         * b3/air/AirValidate.cpp:
1492         * b3/air/opcode_generator.rb:
1493         * b3/testb3.cpp:
1494         (JSC::B3::correctSqrt):
1495         (JSC::B3::testSqrtArg):
1496         (JSC::B3::testSqrtImm):
1497         (JSC::B3::testSqrtMem):
1498         (JSC::B3::testSqrtArgWithUselessDoubleConversion):
1499         (JSC::B3::testSqrtArgWithEffectfulDoubleConversion):
1500         (JSC::B3::testStoreRelAddLoadAcq32):
1501         (JSC::B3::testTrappingLoad):
1502         (JSC::B3::testTrappingStore):
1503         (JSC::B3::testTrappingLoadAddStore):
1504         (JSC::B3::testTrappingLoadDCE):
1505
1506 2017-05-19  Don Olmstead  <don.olmstead@am.sony.com>
1507
1508         [JSC] Remove PLATFORM(WIN) references
1509         https://bugs.webkit.org/show_bug.cgi?id=172294
1510
1511         Reviewed by Yusuke Suzuki.
1512
1513         * heap/MachineStackMarker.cpp:
1514         (JSC::MachineThreads::removeThread):
1515         * llint/LLIntOfflineAsmConfig.h:
1516         * runtime/ConfigFile.h:
1517         * runtime/VM.cpp:
1518         (JSC::VM::updateStackLimits):
1519
1520 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1521
1522         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
1523         https://bugs.webkit.org/show_bug.cgi?id=172098
1524
1525         Reviewed by Saam Barati.
1526
1527         In this patch, we generalize CheckDOM to CheckSubClass.
1528         It can accept any ClassInfo and perform ClassInfo check
1529         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
1530         checkSubClassPatchpoint. It can create DOMJIT patchpoint
1531         for that ClassInfo. It it natural that ClassInfo holds the
1532         way to emit DOMJIT::Patchpoint to perform CheckSubClass
1533         rather than having it in each DOMJIT getter / function
1534         signature annotation.
1535
1536         One problem is that it enlarges the size of ClassInfo.
1537         But this is the best place to put this function pointer.
1538         By doing so, we can add a patchpoint for CheckSubClass
1539         in an non-intrusive manner: WebCore can inject patchpoints
1540         without interactive JSC.
1541
1542         We still have a way to reduce the size of ClassInfo if
1543         we move ArrayBuffer related methods out to the other places.
1544
1545         This patch touches many files because we add a new function
1546         pointer to ClassInfo. But they are basically mechanical change.
1547
1548         * API/JSAPIWrapperObject.mm:
1549         * API/JSCallbackConstructor.cpp:
1550         * API/JSCallbackFunction.cpp:
1551         * API/JSCallbackObject.cpp:
1552         * API/ObjCCallbackFunction.mm:
1553         * CMakeLists.txt:
1554         * JavaScriptCore.xcodeproj/project.pbxproj:
1555         * bytecode/CodeBlock.cpp:
1556         * bytecode/DOMJITAccessCasePatchpointParams.h:
1557         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
1558         * bytecode/EvalCodeBlock.cpp:
1559         * bytecode/FunctionCodeBlock.cpp:
1560         * bytecode/GetterSetterAccessCase.cpp:
1561         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
1562         * bytecode/ModuleProgramCodeBlock.cpp:
1563         * bytecode/ProgramCodeBlock.cpp:
1564         * bytecode/UnlinkedCodeBlock.cpp:
1565         * bytecode/UnlinkedEvalCodeBlock.cpp:
1566         * bytecode/UnlinkedFunctionCodeBlock.cpp:
1567         * bytecode/UnlinkedFunctionExecutable.cpp:
1568         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
1569         * bytecode/UnlinkedProgramCodeBlock.cpp:
1570         * debugger/DebuggerScope.cpp:
1571         * dfg/DFGAbstractInterpreterInlines.h:
1572         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1573         * dfg/DFGByteCodeParser.cpp:
1574         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
1575         * dfg/DFGClobberize.h:
1576         (JSC::DFG::clobberize):
1577         * dfg/DFGConstantFoldingPhase.cpp:
1578         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1579         * dfg/DFGDOMJITPatchpointParams.h:
1580         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
1581         * dfg/DFGDoesGC.cpp:
1582         (JSC::DFG::doesGC):
1583         * dfg/DFGFixupPhase.cpp:
1584         (JSC::DFG::FixupPhase::fixupNode):
1585         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
1586         (JSC::DFG::FixupPhase::fixupCheckSubClass):
1587         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
1588         * dfg/DFGGraph.cpp:
1589         (JSC::DFG::Graph::dump):
1590         * dfg/DFGNode.h:
1591         (JSC::DFG::Node::hasClassInfo):
1592         (JSC::DFG::Node::classInfo):
1593         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
1594         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
1595         * dfg/DFGNodeType.h:
1596         * dfg/DFGPredictionPropagationPhase.cpp:
1597         * dfg/DFGSafeToExecute.h:
1598         (JSC::DFG::safeToExecute):
1599         * dfg/DFGSpeculativeJIT.cpp:
1600         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
1601         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
1602         * dfg/DFGSpeculativeJIT.h:
1603         (JSC::DFG::SpeculativeJIT::vm):
1604         * dfg/DFGSpeculativeJIT32_64.cpp:
1605         (JSC::DFG::SpeculativeJIT::compile):
1606         * dfg/DFGSpeculativeJIT64.cpp:
1607         (JSC::DFG::SpeculativeJIT::compile):
1608         * domjit/DOMJITGetterSetter.h:
1609         * domjit/DOMJITPatchpointParams.h:
1610         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
1611         (JSC::DOMJIT::PatchpointParams::vm):
1612         * domjit/DOMJITSignature.h:
1613         (JSC::DOMJIT::Signature::Signature):
1614         (JSC::DOMJIT::Signature::checkDOM): Deleted.
1615         * ftl/FTLAbstractHeapRepository.h:
1616         * ftl/FTLCapabilities.cpp:
1617         (JSC::FTL::canCompile):
1618         * ftl/FTLDOMJITPatchpointParams.h:
1619         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
1620         * ftl/FTLLowerDFGToB3.cpp:
1621         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1622         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
1623         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
1624         * inspector/JSInjectedScriptHost.cpp:
1625         * inspector/JSInjectedScriptHostPrototype.cpp:
1626         * inspector/JSJavaScriptCallFrame.cpp:
1627         * inspector/JSJavaScriptCallFramePrototype.cpp:
1628         * jsc.cpp:
1629         (WTF::DOMJITNode::checkSubClassPatchpoint):
1630         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
1631         (WTF::DOMJITFunctionObject::finishCreation):
1632         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
1633         (WTF::DOMJITCheckSubClassObject::createStructure):
1634         (WTF::DOMJITCheckSubClassObject::create):
1635         (WTF::DOMJITCheckSubClassObject::safeFunction):
1636         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
1637         (WTF::DOMJITCheckSubClassObject::finishCreation):
1638         (GlobalObject::finishCreation):
1639         (functionCreateDOMJITCheckSubClassObject):
1640         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
1641         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
1642         * runtime/AbstractModuleRecord.cpp:
1643         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
1644         * runtime/ArrayConstructor.cpp:
1645         * runtime/ArrayIteratorPrototype.cpp:
1646         * runtime/ArrayPrototype.cpp:
1647         * runtime/AsyncFunctionConstructor.cpp:
1648         * runtime/AsyncFunctionPrototype.cpp:
1649         * runtime/AtomicsObject.cpp:
1650         * runtime/BooleanConstructor.cpp:
1651         * runtime/BooleanObject.cpp:
1652         * runtime/BooleanPrototype.cpp:
1653         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
1654         (JSC::ClassInfo::dump):
1655         * runtime/ClassInfo.h:
1656         (JSC::ClassInfo::offsetOfParentClass):
1657         * runtime/ClonedArguments.cpp:
1658         * runtime/ConsoleObject.cpp:
1659         * runtime/CustomGetterSetter.cpp:
1660         * runtime/DateConstructor.cpp:
1661         * runtime/DateInstance.cpp:
1662         * runtime/DatePrototype.cpp:
1663         * runtime/DirectArguments.cpp:
1664         * runtime/Error.cpp:
1665         * runtime/ErrorConstructor.cpp:
1666         * runtime/ErrorInstance.cpp:
1667         * runtime/ErrorPrototype.cpp:
1668         * runtime/EvalExecutable.cpp:
1669         * runtime/Exception.cpp:
1670         * runtime/ExceptionHelpers.cpp:
1671         * runtime/ExecutableBase.cpp:
1672         * runtime/FunctionConstructor.cpp:
1673         * runtime/FunctionExecutable.cpp:
1674         * runtime/FunctionPrototype.cpp:
1675         * runtime/FunctionRareData.cpp:
1676         * runtime/GeneratorFunctionConstructor.cpp:
1677         * runtime/GeneratorFunctionPrototype.cpp:
1678         * runtime/GeneratorPrototype.cpp:
1679         * runtime/GetterSetter.cpp:
1680         * runtime/HashMapImpl.cpp:
1681         * runtime/HashMapImpl.h:
1682         * runtime/InferredType.cpp:
1683         (JSC::InferredType::create):
1684         * runtime/InferredTypeTable.cpp:
1685         * runtime/InferredValue.cpp:
1686         * runtime/InspectorInstrumentationObject.cpp:
1687         * runtime/InternalFunction.cpp:
1688         * runtime/IntlCollator.cpp:
1689         * runtime/IntlCollatorConstructor.cpp:
1690         * runtime/IntlCollatorPrototype.cpp:
1691         * runtime/IntlDateTimeFormat.cpp:
1692         * runtime/IntlDateTimeFormatConstructor.cpp:
1693         * runtime/IntlDateTimeFormatPrototype.cpp:
1694         * runtime/IntlNumberFormat.cpp:
1695         * runtime/IntlNumberFormatConstructor.cpp:
1696         * runtime/IntlNumberFormatPrototype.cpp:
1697         * runtime/IntlObject.cpp:
1698         * runtime/IteratorPrototype.cpp:
1699         * runtime/JSAPIValueWrapper.cpp:
1700         * runtime/JSArray.cpp:
1701         * runtime/JSArrayBuffer.cpp:
1702         * runtime/JSArrayBufferConstructor.cpp:
1703         * runtime/JSArrayBufferPrototype.cpp:
1704         * runtime/JSArrayBufferView.cpp:
1705         * runtime/JSAsyncFunction.cpp:
1706         * runtime/JSBoundFunction.cpp:
1707         * runtime/JSCallee.cpp:
1708         * runtime/JSCustomGetterSetterFunction.cpp:
1709         * runtime/JSDataView.cpp:
1710         * runtime/JSDataViewPrototype.cpp:
1711         * runtime/JSEnvironmentRecord.cpp:
1712         * runtime/JSFixedArray.cpp:
1713         * runtime/JSFunction.cpp:
1714         * runtime/JSGeneratorFunction.cpp:
1715         * runtime/JSGlobalLexicalEnvironment.cpp:
1716         * runtime/JSGlobalObject.cpp:
1717         * runtime/JSInternalPromise.cpp:
1718         * runtime/JSInternalPromiseConstructor.cpp:
1719         * runtime/JSInternalPromiseDeferred.cpp:
1720         * runtime/JSInternalPromisePrototype.cpp:
1721         * runtime/JSLexicalEnvironment.cpp:
1722         * runtime/JSMap.cpp:
1723         * runtime/JSMapIterator.cpp:
1724         * runtime/JSModuleEnvironment.cpp:
1725         * runtime/JSModuleLoader.cpp:
1726         * runtime/JSModuleNamespaceObject.cpp:
1727         * runtime/JSModuleRecord.cpp:
1728         * runtime/JSNativeStdFunction.cpp:
1729         * runtime/JSONObject.cpp:
1730         * runtime/JSObject.cpp:
1731         * runtime/JSPromise.cpp:
1732         * runtime/JSPromiseConstructor.cpp:
1733         * runtime/JSPromiseDeferred.cpp:
1734         * runtime/JSPromisePrototype.cpp:
1735         * runtime/JSPropertyNameEnumerator.cpp:
1736         * runtime/JSPropertyNameIterator.cpp:
1737         * runtime/JSProxy.cpp:
1738         * runtime/JSScriptFetcher.cpp:
1739         * runtime/JSSet.cpp:
1740         * runtime/JSSetIterator.cpp:
1741         * runtime/JSSourceCode.cpp:
1742         * runtime/JSString.cpp:
1743         * runtime/JSStringIterator.cpp:
1744         * runtime/JSSymbolTableObject.cpp:
1745         * runtime/JSTemplateRegistryKey.cpp:
1746         * runtime/JSTypedArrayConstructors.cpp:
1747         * runtime/JSTypedArrayPrototypes.cpp:
1748         * runtime/JSTypedArrayViewConstructor.cpp:
1749         * runtime/JSTypedArrays.cpp:
1750         * runtime/JSWeakMap.cpp:
1751         * runtime/JSWeakSet.cpp:
1752         * runtime/JSWithScope.cpp:
1753         * runtime/MapConstructor.cpp:
1754         * runtime/MapIteratorPrototype.cpp:
1755         * runtime/MapPrototype.cpp:
1756         * runtime/MathObject.cpp:
1757         * runtime/ModuleLoaderPrototype.cpp:
1758         * runtime/ModuleProgramExecutable.cpp:
1759         * runtime/NativeErrorConstructor.cpp:
1760         * runtime/NativeExecutable.cpp:
1761         * runtime/NativeStdFunctionCell.cpp:
1762         * runtime/NullGetterFunction.cpp:
1763         * runtime/NullSetterFunction.cpp:
1764         * runtime/NumberConstructor.cpp:
1765         * runtime/NumberObject.cpp:
1766         * runtime/NumberPrototype.cpp:
1767         * runtime/ObjectConstructor.cpp:
1768         * runtime/ObjectPrototype.cpp:
1769         * runtime/ProgramExecutable.cpp:
1770         * runtime/PropertyTable.cpp:
1771         * runtime/ProxyConstructor.cpp:
1772         * runtime/ProxyObject.cpp:
1773         * runtime/ProxyRevoke.cpp:
1774         * runtime/ReflectObject.cpp:
1775         * runtime/RegExp.cpp:
1776         * runtime/RegExpConstructor.cpp:
1777         * runtime/RegExpObject.cpp:
1778         * runtime/RegExpPrototype.cpp:
1779         * runtime/ScopedArguments.cpp:
1780         * runtime/ScopedArgumentsTable.cpp:
1781         * runtime/ScriptExecutable.cpp:
1782         * runtime/SetConstructor.cpp:
1783         * runtime/SetIteratorPrototype.cpp:
1784         * runtime/SetPrototype.cpp:
1785         * runtime/SparseArrayValueMap.cpp:
1786         * runtime/StrictEvalActivation.cpp:
1787         * runtime/StringConstructor.cpp:
1788         * runtime/StringIteratorPrototype.cpp:
1789         * runtime/StringObject.cpp:
1790         * runtime/StringPrototype.cpp:
1791         * runtime/Structure.cpp:
1792         * runtime/StructureChain.cpp:
1793         * runtime/StructureRareData.cpp:
1794         * runtime/Symbol.cpp:
1795         * runtime/SymbolConstructor.cpp:
1796         * runtime/SymbolObject.cpp:
1797         * runtime/SymbolPrototype.cpp:
1798         * runtime/SymbolTable.cpp:
1799         * runtime/WeakMapConstructor.cpp:
1800         * runtime/WeakMapData.cpp:
1801         * runtime/WeakMapPrototype.cpp:
1802         * runtime/WeakSetConstructor.cpp:
1803         * runtime/WeakSetPrototype.cpp:
1804         * testRegExp.cpp:
1805         * tools/JSDollarVM.cpp:
1806         * tools/JSDollarVMPrototype.cpp:
1807         * wasm/JSWebAssembly.cpp:
1808         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1809         * wasm/js/JSWebAssemblyCompileError.cpp:
1810         * wasm/js/JSWebAssemblyInstance.cpp:
1811         * wasm/js/JSWebAssemblyLinkError.cpp:
1812         * wasm/js/JSWebAssemblyMemory.cpp:
1813         * wasm/js/JSWebAssemblyModule.cpp:
1814         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1815         * wasm/js/JSWebAssemblyTable.cpp:
1816         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1817         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
1818         * wasm/js/WebAssemblyFunction.cpp:
1819         * wasm/js/WebAssemblyFunctionBase.cpp:
1820         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1821         * wasm/js/WebAssemblyInstancePrototype.cpp:
1822         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
1823         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
1824         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1825         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1826         * wasm/js/WebAssemblyModuleConstructor.cpp:
1827         * wasm/js/WebAssemblyModulePrototype.cpp:
1828         * wasm/js/WebAssemblyModuleRecord.cpp:
1829         * wasm/js/WebAssemblyPrototype.cpp:
1830         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1831         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
1832         * wasm/js/WebAssemblyTableConstructor.cpp:
1833         * wasm/js/WebAssemblyTablePrototype.cpp:
1834         * wasm/js/WebAssemblyToJSCallee.cpp:
1835         * wasm/js/WebAssemblyWrapperFunction.cpp:
1836
1837 2017-05-18  JF Bastien  <jfbastien@apple.com>
1838
1839         WebAssembly: exports is a getter
1840         https://bugs.webkit.org/show_bug.cgi?id=172129
1841
1842         Reviewed by Saam Barati.
1843
1844         As updated here: https://github.com/WebAssembly/design/pull/1062
1845
1846         * wasm/js/JSWebAssemblyInstance.cpp:
1847         (JSC::JSWebAssemblyInstance::finishCreation): don't putDirect here anymore
1848         * wasm/js/JSWebAssemblyInstance.h:
1849         (JSC::JSWebAssemblyInstance::moduleNamespaceObject): add accessor
1850         * wasm/js/WebAssemblyFunctionBase.cpp: squelch causing a warning
1851         * wasm/js/WebAssemblyInstancePrototype.cpp: use LUT
1852         (JSC::getInstance): helper, as in surrounding files
1853         (JSC::webAssemblyInstanceProtoFuncExports): instead of putDirect
1854         * wasm/js/WebAssemblyMemoryPrototype.cpp: pass VM around as for Table
1855         (JSC::getMemory):
1856         (JSC::webAssemblyMemoryProtoFuncGrow):
1857         (JSC::webAssemblyMemoryProtoFuncBuffer):
1858         * wasm/js/WebAssemblyTablePrototype.cpp: static everywhere as with other code
1859         (JSC::webAssemblyTableProtoFuncLength):
1860         (JSC::webAssemblyTableProtoFuncGrow):
1861         (JSC::webAssemblyTableProtoFuncGet):
1862         (JSC::webAssemblyTableProtoFuncSet):
1863
1864 2017-05-18  Saam Barati  <sbarati@apple.com>
1865
1866         Proxy's [[Get]] passes incorrect receiver
1867         https://bugs.webkit.org/show_bug.cgi?id=164849
1868         <rdar://problem/31767058>
1869
1870         Reviewed by Yusuke Suzuki.
1871
1872         * runtime/ProxyObject.cpp:
1873         (JSC::performProxyGet):
1874
1875 2017-05-18  Andy Estes  <aestes@apple.com>
1876
1877         ENABLE(APPLE_PAY_DELEGATE) should be NO on macOS Sierra and earlier
1878         https://bugs.webkit.org/show_bug.cgi?id=172305
1879
1880         Reviewed by Anders Carlsson.
1881
1882         * Configurations/FeatureDefines.xcconfig:
1883
1884 2017-05-18  Saam Barati  <sbarati@apple.com>
1885
1886         We need to destroy worker threads in jsc.cpp
1887         https://bugs.webkit.org/show_bug.cgi?id=170751
1888         <rdar://problem/31800412>
1889
1890         Reviewed by Filip Pizlo.
1891
1892         This patch fixes a bug where a $ agent worker would still
1893         have compilation threads running after the thread the worker
1894         was created on dies. This manifested itself inside DFG AI where
1895         we would notice a string constant is atomic, then the worker
1896         thread would die, destroying its atomic string table, then
1897         we'd notice the same string is no longer atomic, and we'd crash
1898         because we'd fail to see the same speculated type for the same
1899         JSValue.
1900         
1901         This patch makes it so that $ agent workers destroy their VM when
1902         they're done executing. Before a VM gets destroyed, it ensures that
1903         all its compilation threads finish.
1904
1905         * jsc.cpp:
1906         (functionDollarAgentStart):
1907         (runJSC):
1908         (jscmain):
1909
1910 2017-05-18  Michael Saboff  <msaboff@apple.com>
1911
1912         Add FTL whitelist debugging option
1913         https://bugs.webkit.org/show_bug.cgi?id=172321
1914
1915         Reviewed by Saam Barati.
1916
1917         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1918         (JSC::DFG::ensureGlobalFTLWhitelist):
1919         (JSC::DFG::TierUpCheckInjectionPhase::run):
1920         * runtime/Options.h:
1921         * tools/FunctionWhitelist.cpp:
1922         (JSC::FunctionWhitelist::contains):
1923
1924 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
1925
1926         Constructor calls set this too early
1927         https://bugs.webkit.org/show_bug.cgi?id=172302
1928
1929         Reviewed by Saam Barati.
1930         
1931         We were setting this before evaluating the arguments, so this code:
1932         
1933             var x = 42;
1934             new x(x = function() { });
1935         
1936         Would crash because we would pass 42 as this, and create_this would treat it as a cell.
1937         Dereferencing a non-cell is guaranteed to crash.
1938
1939         * bytecompiler/BytecodeGenerator.cpp:
1940         (JSC::BytecodeGenerator::emitConstruct):
1941         * bytecompiler/BytecodeGenerator.h:
1942         * bytecompiler/NodesCodegen.cpp:
1943         (JSC::NewExprNode::emitBytecode):
1944         (JSC::FunctionCallValueNode::emitBytecode):
1945
1946 2017-05-18  Saam Barati  <sbarati@apple.com>
1947
1948         WebAssembly: perform stack checks
1949         https://bugs.webkit.org/show_bug.cgi?id=165546
1950         <rdar://problem/29760307>
1951
1952         Reviewed by Filip Pizlo.
1953
1954         This patch adds stack checks to wasm. It implements it by storing the stack
1955         bounds on the Context.
1956         
1957         Stack checking works as normal, except we do a small optimization for terminal
1958         nodes in the call tree (nodes that don't make any calls). These nodes will
1959         only do a stack check if their frame size is beyond 1024 bytes. Otherwise,
1960         it's assumed the parent that called them did their stack check for them.
1961         This is because all things that make calls make sure to do an extra 1024
1962         bytes whenever doing a stack check.
1963         
1964         We also take into account stack size for potential JS calls when doing
1965         stack checks since our JS stubs don't do this on their own. Each frame
1966         will ensure it does a stack check large enough for any potential JS call
1967         stubs it'll execute.
1968         
1969         Surprisingly, this patch is neutral on WasmBench and TitzerBench.
1970
1971         * llint/LLIntData.cpp:
1972         (JSC::LLInt::Data::performAssertions):
1973         * llint/LowLevelInterpreter.asm:
1974         * runtime/Error.cpp:
1975         (JSC::createRangeError):
1976         (JSC::addErrorInfoAndGetBytecodeOffset):
1977         I fixed a bug here where we assumed that the first frame that has line
1978         and column info would be in our stack trace. This is not correct
1979         since we limit our stack trace size. If everything in our limited
1980         size stack trace is Wasm, then we won't have any frames with line
1981         and column info.
1982         * runtime/Error.h:
1983         * runtime/ExceptionHelpers.cpp:
1984         (JSC::createStackOverflowError):
1985         * runtime/ExceptionHelpers.h:
1986         * runtime/JSGlobalObject.cpp:
1987         (JSC::JSGlobalObject::init):
1988         (JSC::JSGlobalObject::visitChildren):
1989         * runtime/JSGlobalObject.h:
1990         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure):
1991         * runtime/JSType.h:
1992         * runtime/Options.h: I've added a new option that controls
1993         whether or not we use fast TLS for the wasm context.
1994         * runtime/VM.cpp:
1995         (JSC::VM::VM):
1996         * runtime/VM.h:
1997         * wasm/WasmB3IRGenerator.cpp:
1998         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1999         * wasm/WasmBinding.cpp:
2000         (JSC::Wasm::wasmToWasm):
2001         * wasm/WasmContext.cpp:
2002         (JSC::Wasm::loadContext):
2003         (JSC::Wasm::storeContext):
2004         * wasm/WasmContext.h:
2005         (JSC::Wasm::useFastTLSForContext):
2006         * wasm/WasmExceptionType.h:
2007         * wasm/WasmMemoryInformation.h:
2008         (JSC::Wasm::PinnedRegisterInfo::toSave):
2009         * wasm/WasmThunks.cpp:
2010         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2011         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
2012         (JSC::Wasm::Thunks::stub):
2013         * wasm/WasmThunks.h:
2014         * wasm/js/JSWebAssemblyInstance.h:
2015         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit):
2016         (JSC::JSWebAssemblyInstance::cachedStackLimit):
2017         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2018         * wasm/js/JSWebAssemblyModule.cpp:
2019         (JSC::JSWebAssemblyModule::finishCreation):
2020         * wasm/js/WebAssemblyFunction.cpp:
2021         (JSC::callWebAssemblyFunction):
2022         * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object.
2023         This is needed for correctness because we may call into JS,
2024         and then the first JS frame could stack overflow. When it stack
2025         overflows, it rolls back one frame to the wasm->js call stub with
2026         the wasm->js callee. It gets the lexical global object from this
2027         frame, meaning it gets the global object from the callee. Therefore,
2028         we must make it an object since all objects have global objects.
2029         (JSC::WebAssemblyToJSCallee::create):
2030         * wasm/js/WebAssemblyToJSCallee.h:
2031
2032 2017-05-18  Keith Miller  <keith_miller@apple.com>
2033
2034         WebAssembly API: test with neutered inputs
2035         https://bugs.webkit.org/show_bug.cgi?id=163899
2036
2037         Reviewed by JF Bastien.
2038
2039         Add tests to check that we properly throw a type error when
2040         we get a transferred ArrayBuffer. Also, we should make sure
2041         we cannot post message a wasm memory's ArrayBuffer.
2042
2043         * API/JSTypedArray.cpp:
2044         (JSObjectGetArrayBufferBytesPtr):
2045         * runtime/ArrayBuffer.cpp:
2046         (JSC::ArrayBuffer::makeShared):
2047         (JSC::ArrayBuffer::makeWasmMemory):
2048         (JSC::ArrayBuffer::transferTo):
2049         (JSC::ArrayBuffer::neuter):
2050         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
2051         (JSC::errorMesasgeForTransfer):
2052         * runtime/ArrayBuffer.h:
2053         (JSC::ArrayBuffer::isLocked):
2054         (JSC::ArrayBuffer::isWasmMemory):
2055         * wasm/js/JSWebAssemblyMemory.cpp:
2056         (JSC::JSWebAssemblyMemory::buffer):
2057         (JSC::JSWebAssemblyMemory::grow):
2058
2059 2017-05-18  Joseph Pecoraro  <pecoraro@apple.com>
2060
2061         Remote Inspector: Be stricter about checking message types
2062         https://bugs.webkit.org/show_bug.cgi?id=172259
2063         <rdar://problem/32264839>
2064
2065         Reviewed by Brian Burg.
2066
2067         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2068         (Inspector::RemoteInspector::receivedSetupMessage):
2069         (Inspector::RemoteInspector::receivedDataMessage):
2070         (Inspector::RemoteInspector::receivedDidCloseMessage):
2071         (Inspector::RemoteInspector::receivedIndicateMessage):
2072         (Inspector::RemoteInspector::receivedConnectionDiedMessage):
2073         (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage):
2074         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
2075         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2076         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
2077         (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
2078         (Inspector::RemoteInspectorXPCConnection::handleEvent):
2079         (Inspector::RemoteInspectorXPCConnection::sendMessage):
2080         Bail if we don't receive the expected types for message data.
2081
2082 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
2083
2084         DFG inlining should be hardened for the no-result case
2085         https://bugs.webkit.org/show_bug.cgi?id=172290
2086
2087         Reviewed by Saam Barati.
2088         
2089         Previously, if we were inlining a setter call, we might have a bad time because the setter's
2090         result register is the invalid VirtualRegister(), and much of the intrinsic handling code
2091         assumes that the result register is valid.
2092         
2093         This doesn't usually cause problems because people don't usually point a setter at something
2094         that we recognize as an intrinsic.
2095         
2096         * CMakeLists.txt:
2097         * JavaScriptCore.xcodeproj/project.pbxproj:
2098         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment.
2099         * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal.
2100         (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner.
2101         (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug.
2102         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter).
2103         * runtime/Intrinsic.cpp: Added. I needed this to debug.
2104         (JSC::intrinsicName):
2105         (WTF::printInternal):
2106         * runtime/Intrinsic.h:
2107
2108 2017-05-18  Commit Queue  <commit-queue@webkit.org>
2109
2110         Unreviewed, rolling out r217031, r217032, and r217037.
2111         https://bugs.webkit.org/show_bug.cgi?id=172293
2112
2113         cause linking errors in Windows (Requested by yusukesuzuki on
2114         #webkit).
2115
2116         Reverted changesets:
2117
2118         "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass"
2119         https://bugs.webkit.org/show_bug.cgi?id=172098
2120         http://trac.webkit.org/changeset/217031
2121
2122         "Unreviewed, rebaseline for newly added ClassInfo"
2123         https://bugs.webkit.org/show_bug.cgi?id=172098
2124         http://trac.webkit.org/changeset/217032
2125
2126         "Unreviewed, fix debug and non-JIT build"
2127         https://bugs.webkit.org/show_bug.cgi?id=172098
2128         http://trac.webkit.org/changeset/217037
2129
2130 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2131
2132         Unreviewed, fix debug and non-JIT build
2133         https://bugs.webkit.org/show_bug.cgi?id=172098
2134
2135         * jsc.cpp:
2136         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2137
2138 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2139
2140         Unreviewed, rebaseline for newly added ClassInfo
2141         https://bugs.webkit.org/show_bug.cgi?id=172098
2142
2143         * wasm/js/WebAssemblyFunctionBase.cpp:
2144
2145 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2146
2147         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
2148         https://bugs.webkit.org/show_bug.cgi?id=172098
2149
2150         Reviewed by Saam Barati.
2151
2152         In this patch, we generalize CheckDOM to CheckSubClass.
2153         It can accept any ClassInfo and perform ClassInfo check
2154         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
2155         checkSubClassPatchpoint. It can create DOMJIT patchpoint
2156         for that ClassInfo. It it natural that ClassInfo holds the
2157         way to emit DOMJIT::Patchpoint to perform CheckSubClass
2158         rather than having it in each DOMJIT getter / function
2159         signature annotation.
2160
2161         One problem is that it enlarges the size of ClassInfo.
2162         But this is the best place to put this function pointer.
2163         By doing so, we can add a patchpoint for CheckSubClass
2164         in an non-intrusive manner: WebCore can inject patchpoints
2165         without interactive JSC.
2166
2167         We still have a way to reduce the size of ClassInfo if
2168         we move ArrayBuffer related methods out to the other places.
2169
2170         This patch touches many files because we add a new function
2171         pointer to ClassInfo. But they are basically mechanical change.
2172
2173         * API/JSAPIWrapperObject.mm:
2174         * API/JSCallbackConstructor.cpp:
2175         * API/JSCallbackFunction.cpp:
2176         * API/JSCallbackObject.cpp:
2177         * API/ObjCCallbackFunction.mm:
2178         * CMakeLists.txt:
2179         * JavaScriptCore.xcodeproj/project.pbxproj:
2180         * bytecode/CodeBlock.cpp:
2181         * bytecode/DOMJITAccessCasePatchpointParams.h:
2182         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
2183         * bytecode/EvalCodeBlock.cpp:
2184         * bytecode/FunctionCodeBlock.cpp:
2185         * bytecode/GetterSetterAccessCase.cpp:
2186         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
2187         * bytecode/ModuleProgramCodeBlock.cpp:
2188         * bytecode/ProgramCodeBlock.cpp:
2189         * bytecode/UnlinkedCodeBlock.cpp:
2190         * bytecode/UnlinkedEvalCodeBlock.cpp:
2191         * bytecode/UnlinkedFunctionCodeBlock.cpp:
2192         * bytecode/UnlinkedFunctionExecutable.cpp:
2193         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
2194         * bytecode/UnlinkedProgramCodeBlock.cpp:
2195         * debugger/DebuggerScope.cpp:
2196         * dfg/DFGAbstractInterpreterInlines.h:
2197         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2198         * dfg/DFGByteCodeParser.cpp:
2199         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2200         * dfg/DFGClobberize.h:
2201         (JSC::DFG::clobberize):
2202         * dfg/DFGConstantFoldingPhase.cpp:
2203         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2204         * dfg/DFGDOMJITPatchpointParams.h:
2205         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2206         * dfg/DFGDoesGC.cpp:
2207         (JSC::DFG::doesGC):
2208         * dfg/DFGFixupPhase.cpp:
2209         (JSC::DFG::FixupPhase::fixupNode):
2210         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
2211         (JSC::DFG::FixupPhase::fixupCheckSubClass):
2212         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
2213         * dfg/DFGGraph.cpp:
2214         (JSC::DFG::Graph::dump):
2215         * dfg/DFGNode.h:
2216         (JSC::DFG::Node::hasClassInfo):
2217         (JSC::DFG::Node::classInfo):
2218         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
2219         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
2220         * dfg/DFGNodeType.h:
2221         * dfg/DFGPredictionPropagationPhase.cpp:
2222         * dfg/DFGSafeToExecute.h:
2223         (JSC::DFG::safeToExecute):
2224         * dfg/DFGSpeculativeJIT.cpp:
2225         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
2226         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
2227         * dfg/DFGSpeculativeJIT.h:
2228         (JSC::DFG::SpeculativeJIT::vm):
2229         * dfg/DFGSpeculativeJIT32_64.cpp:
2230         (JSC::DFG::SpeculativeJIT::compile):
2231         In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo.
2232         And ClassInfo knows how to perform CheckSubClass efficiently.
2233         If ClassInfo does not have a way to perform CheckSubClass efficiently,
2234         we just perform jsDynamicCast thing in ASM.
2235         * dfg/DFGSpeculativeJIT64.cpp:
2236         (JSC::DFG::SpeculativeJIT::compile):
2237         * domjit/DOMJITGetterSetter.h:
2238         * domjit/DOMJITPatchpointParams.h:
2239         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2240         (JSC::DOMJIT::PatchpointParams::vm):
2241         * domjit/DOMJITSignature.h:
2242         (JSC::DOMJIT::Signature::Signature):
2243         (JSC::DOMJIT::Signature::checkDOM): Deleted.
2244         * ftl/FTLAbstractHeapRepository.h:
2245         * ftl/FTLCapabilities.cpp:
2246         (JSC::FTL::canCompile):
2247         * ftl/FTLDOMJITPatchpointParams.h:
2248         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2249         * ftl/FTLLowerDFGToB3.cpp:
2250         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2251         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
2252         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
2253         * inspector/JSInjectedScriptHost.cpp:
2254         * inspector/JSInjectedScriptHostPrototype.cpp:
2255         * inspector/JSJavaScriptCallFrame.cpp:
2256         * inspector/JSJavaScriptCallFramePrototype.cpp:
2257         * jsc.cpp:
2258         (WTF::DOMJITNode::checkSubClassPatchpoint):
2259         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2260         (WTF::DOMJITFunctionObject::finishCreation):
2261         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
2262         (WTF::DOMJITCheckSubClassObject::createStructure):
2263         (WTF::DOMJITCheckSubClassObject::create):
2264         (WTF::DOMJITCheckSubClassObject::safeFunction):
2265         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
2266         (WTF::DOMJITCheckSubClassObject::finishCreation):
2267         (GlobalObject::finishCreation):
2268         (functionCreateDOMJITCheckSubClassObject):
2269         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
2270         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
2271         * runtime/AbstractModuleRecord.cpp:
2272         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
2273         * runtime/ArrayConstructor.cpp:
2274         * runtime/ArrayIteratorPrototype.cpp:
2275         * runtime/ArrayPrototype.cpp:
2276         * runtime/AsyncFunctionConstructor.cpp:
2277         * runtime/AsyncFunctionPrototype.cpp:
2278         * runtime/AtomicsObject.cpp:
2279         * runtime/BooleanConstructor.cpp:
2280         * runtime/BooleanObject.cpp:
2281         * runtime/BooleanPrototype.cpp:
2282         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
2283         (JSC::ClassInfo::dump):
2284         * runtime/ClassInfo.h:
2285         (JSC::ClassInfo::offsetOfParentClass):
2286         * runtime/ClonedArguments.cpp:
2287         * runtime/ConsoleObject.cpp:
2288         * runtime/CustomGetterSetter.cpp:
2289         * runtime/DateConstructor.cpp:
2290         * runtime/DateInstance.cpp:
2291         * runtime/DatePrototype.cpp:
2292         * runtime/DirectArguments.cpp:
2293         * runtime/Error.cpp:
2294         * runtime/ErrorConstructor.cpp:
2295         * runtime/ErrorInstance.cpp:
2296         * runtime/ErrorPrototype.cpp:
2297         * runtime/EvalExecutable.cpp:
2298         * runtime/Exception.cpp:
2299         * runtime/ExceptionHelpers.cpp:
2300         * runtime/ExecutableBase.cpp:
2301         * runtime/FunctionConstructor.cpp:
2302         * runtime/FunctionExecutable.cpp:
2303         * runtime/FunctionPrototype.cpp:
2304         * runtime/FunctionRareData.cpp:
2305         * runtime/GeneratorFunctionConstructor.cpp:
2306         * runtime/GeneratorFunctionPrototype.cpp:
2307         * runtime/GeneratorPrototype.cpp:
2308         * runtime/GetterSetter.cpp:
2309         * runtime/HashMapImpl.cpp:
2310         * runtime/HashMapImpl.h:
2311         * runtime/InferredType.cpp:
2312         (JSC::InferredType::create):
2313         * runtime/InferredTypeTable.cpp:
2314         * runtime/InferredValue.cpp:
2315         * runtime/InspectorInstrumentationObject.cpp:
2316         * runtime/InternalFunction.cpp:
2317         * runtime/IntlCollator.cpp:
2318         * runtime/IntlCollatorConstructor.cpp:
2319         * runtime/IntlCollatorPrototype.cpp:
2320         * runtime/IntlDateTimeFormat.cpp:
2321         * runtime/IntlDateTimeFormatConstructor.cpp:
2322         * runtime/IntlDateTimeFormatPrototype.cpp:
2323         * runtime/IntlNumberFormat.cpp:
2324         * runtime/IntlNumberFormatConstructor.cpp:
2325         * runtime/IntlNumberFormatPrototype.cpp:
2326         * runtime/IntlObject.cpp:
2327         * runtime/IteratorPrototype.cpp:
2328         * runtime/JSAPIValueWrapper.cpp:
2329         * runtime/JSArray.cpp:
2330         * runtime/JSArrayBuffer.cpp:
2331         * runtime/JSArrayBufferConstructor.cpp:
2332         * runtime/JSArrayBufferPrototype.cpp:
2333         * runtime/JSArrayBufferView.cpp:
2334         * runtime/JSAsyncFunction.cpp:
2335         * runtime/JSBoundFunction.cpp:
2336         * runtime/JSCallee.cpp:
2337         * runtime/JSCustomGetterSetterFunction.cpp:
2338         * runtime/JSDataView.cpp:
2339         * runtime/JSDataViewPrototype.cpp:
2340         * runtime/JSEnvironmentRecord.cpp:
2341         * runtime/JSFixedArray.cpp:
2342         * runtime/JSFunction.cpp:
2343         * runtime/JSGeneratorFunction.cpp:
2344         * runtime/JSGlobalLexicalEnvironment.cpp:
2345         * runtime/JSGlobalObject.cpp:
2346         * runtime/JSInternalPromise.cpp:
2347         * runtime/JSInternalPromiseConstructor.cpp:
2348         * runtime/JSInternalPromiseDeferred.cpp:
2349         * runtime/JSInternalPromisePrototype.cpp:
2350         * runtime/JSLexicalEnvironment.cpp:
2351         * runtime/JSMap.cpp:
2352         * runtime/JSMapIterator.cpp:
2353         * runtime/JSModuleEnvironment.cpp:
2354         * runtime/JSModuleLoader.cpp:
2355         * runtime/JSModuleNamespaceObject.cpp:
2356         * runtime/JSModuleRecord.cpp:
2357         * runtime/JSNativeStdFunction.cpp:
2358         * runtime/JSONObject.cpp:
2359         * runtime/JSObject.cpp:
2360         * runtime/JSPromise.cpp:
2361         * runtime/JSPromiseConstructor.cpp:
2362         * runtime/JSPromiseDeferred.cpp:
2363         * runtime/JSPromisePrototype.cpp:
2364         * runtime/JSPropertyNameEnumerator.cpp:
2365         * runtime/JSPropertyNameIterator.cpp:
2366         * runtime/JSProxy.cpp:
2367         * runtime/JSScriptFetcher.cpp:
2368         * runtime/JSSet.cpp:
2369         * runtime/JSSetIterator.cpp:
2370         * runtime/JSSourceCode.cpp:
2371         * runtime/JSString.cpp:
2372         * runtime/JSStringIterator.cpp:
2373         * runtime/JSSymbolTableObject.cpp:
2374         * runtime/JSTemplateRegistryKey.cpp:
2375         * runtime/JSTypedArrayConstructors.cpp:
2376         * runtime/JSTypedArrayPrototypes.cpp:
2377         * runtime/JSTypedArrayViewConstructor.cpp:
2378         * runtime/JSTypedArrays.cpp:
2379         * runtime/JSWeakMap.cpp:
2380         * runtime/JSWeakSet.cpp:
2381         * runtime/JSWithScope.cpp:
2382         * runtime/MapConstructor.cpp:
2383         * runtime/MapIteratorPrototype.cpp:
2384         * runtime/MapPrototype.cpp:
2385         * runtime/MathObject.cpp:
2386         * runtime/ModuleLoaderPrototype.cpp:
2387         * runtime/ModuleProgramExecutable.cpp:
2388         * runtime/NativeErrorConstructor.cpp:
2389         * runtime/NativeExecutable.cpp:
2390         * runtime/NativeStdFunctionCell.cpp:
2391         * runtime/NullGetterFunction.cpp:
2392         * runtime/NullSetterFunction.cpp:
2393         * runtime/NumberConstructor.cpp:
2394         * runtime/NumberObject.cpp:
2395         * runtime/NumberPrototype.cpp:
2396         * runtime/ObjectConstructor.cpp:
2397         * runtime/ObjectPrototype.cpp:
2398         * runtime/ProgramExecutable.cpp:
2399         * runtime/PropertyTable.cpp:
2400         * runtime/ProxyConstructor.cpp:
2401         * runtime/ProxyObject.cpp:
2402         * runtime/ProxyRevoke.cpp:
2403         * runtime/ReflectObject.cpp:
2404         * runtime/RegExp.cpp:
2405         * runtime/RegExpConstructor.cpp:
2406         * runtime/RegExpObject.cpp:
2407         * runtime/RegExpPrototype.cpp:
2408         * runtime/ScopedArguments.cpp:
2409         * runtime/ScopedArgumentsTable.cpp:
2410         * runtime/ScriptExecutable.cpp:
2411         * runtime/SetConstructor.cpp:
2412         * runtime/SetIteratorPrototype.cpp:
2413         * runtime/SetPrototype.cpp:
2414         * runtime/SparseArrayValueMap.cpp:
2415         * runtime/StrictEvalActivation.cpp:
2416         * runtime/StringConstructor.cpp:
2417         * runtime/StringIteratorPrototype.cpp:
2418         * runtime/StringObject.cpp:
2419         * runtime/StringPrototype.cpp:
2420         * runtime/Structure.cpp:
2421         * runtime/StructureChain.cpp:
2422         * runtime/StructureRareData.cpp:
2423         * runtime/Symbol.cpp:
2424         * runtime/SymbolConstructor.cpp:
2425         * runtime/SymbolObject.cpp:
2426         * runtime/SymbolPrototype.cpp:
2427         * runtime/SymbolTable.cpp:
2428         * runtime/WeakMapConstructor.cpp:
2429         * runtime/WeakMapData.cpp:
2430         * runtime/WeakMapPrototype.cpp:
2431         * runtime/WeakSetConstructor.cpp:
2432         * runtime/WeakSetPrototype.cpp:
2433         * testRegExp.cpp:
2434         * tools/JSDollarVM.cpp:
2435         * tools/JSDollarVMPrototype.cpp:
2436         * wasm/JSWebAssembly.cpp:
2437         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2438         * wasm/js/JSWebAssemblyCompileError.cpp:
2439         * wasm/js/JSWebAssemblyInstance.cpp:
2440         * wasm/js/JSWebAssemblyLinkError.cpp:
2441         * wasm/js/JSWebAssemblyMemory.cpp:
2442         * wasm/js/JSWebAssemblyModule.cpp:
2443         * wasm/js/JSWebAssemblyRuntimeError.cpp:
2444         * wasm/js/JSWebAssemblyTable.cpp:
2445         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2446         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2447         * wasm/js/WebAssemblyFunction.cpp:
2448         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2449         * wasm/js/WebAssemblyInstancePrototype.cpp:
2450         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2451         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2452         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2453         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2454         * wasm/js/WebAssemblyModuleConstructor.cpp:
2455         * wasm/js/WebAssemblyModulePrototype.cpp:
2456         * wasm/js/WebAssemblyModuleRecord.cpp:
2457         * wasm/js/WebAssemblyPrototype.cpp:
2458         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2459         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2460         * wasm/js/WebAssemblyTableConstructor.cpp:
2461         * wasm/js/WebAssemblyTablePrototype.cpp:
2462         * wasm/js/WebAssemblyToJSCallee.cpp:
2463         * wasm/js/WebAssemblyWrapperFunction.cpp:
2464
2465 2017-05-17  Saam Barati  <sbarati@apple.com>
2466
2467         We don't do context switches for Wasm->Wasm call indirect
2468         https://bugs.webkit.org/show_bug.cgi?id=172188
2469         <rdar://problem/32231828>
2470
2471         Reviewed by Keith Miller.
2472
2473         We did not do a context switch when doing an indirect call. 
2474         This is clearly wrong, since the thing we're making an indirect
2475         call to could be from another instance. This patch fixes this
2476         oversight by doing a very simple context switch. I've also opened
2477         a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197
2478         since this patch adds yet another branch to the indirect call path.
2479         I've also added tests that either throw or crash before this change.
2480
2481         * CMakeLists.txt:
2482         * JavaScriptCore.xcodeproj/project.pbxproj:
2483         * wasm/WasmB3IRGenerator.cpp:
2484         * wasm/js/JSWebAssemblyTable.h:
2485         (JSC::JSWebAssemblyTable::offsetOfJSFunctions):
2486         * wasm/js/WebAssemblyFunction.cpp:
2487         (JSC::WebAssemblyFunction::visitChildren):
2488         (JSC::WebAssemblyFunction::finishCreation): Deleted.
2489         * wasm/js/WebAssemblyFunction.h:
2490         (JSC::WebAssemblyFunction::instance): Deleted.
2491         (JSC::WebAssemblyFunction::offsetOfInstance): Deleted.
2492         * wasm/js/WebAssemblyFunctionBase.cpp: Added.
2493         (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
2494         (JSC::WebAssemblyFunctionBase::visitChildren):
2495         (JSC::WebAssemblyFunctionBase::finishCreation):
2496         * wasm/js/WebAssemblyFunctionBase.h: Added.
2497         (JSC::WebAssemblyFunctionBase::instance):
2498         (JSC::WebAssemblyFunctionBase::offsetOfInstance):
2499         * wasm/js/WebAssemblyModuleRecord.cpp:
2500         (JSC::WebAssemblyModuleRecord::link):
2501         (JSC::WebAssemblyModuleRecord::evaluate):
2502         * wasm/js/WebAssemblyWrapperFunction.cpp:
2503         (JSC::WebAssemblyWrapperFunction::create):
2504         (JSC::WebAssemblyWrapperFunction::finishCreation):
2505         (JSC::WebAssemblyWrapperFunction::visitChildren):
2506         * wasm/js/WebAssemblyWrapperFunction.h:
2507
2508 2017-05-17  Filip Pizlo  <fpizlo@apple.com>
2509
2510         JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform
2511         https://bugs.webkit.org/show_bug.cgi?id=172208
2512
2513         Reviewed by Saam Barati.
2514
2515         * dfg/DFGArgumentsEliminationPhase.cpp:
2516
2517 2017-05-17  Don Olmstead  <don.olmstead@am.sony.com>
2518
2519         [Win] Support $vm.getpid()
2520         https://bugs.webkit.org/show_bug.cgi?id=172248
2521
2522         Reviewed by Mark Lam.
2523
2524         * tools/JSDollarVMPrototype.cpp:
2525         (JSC::functionGetPID):
2526         (JSC::JSDollarVMPrototype::finishCreation):
2527
2528 2017-05-17  Michael Saboff  <msaboff@apple.com>
2529
2530         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info
2531         https://bugs.webkit.org/show_bug.cgi?id=172186
2532
2533         Reviewed by Geoffrey Garen.
2534
2535         The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call
2536         the OS to get up to date values.  In overCriticalMemoryThreshold(), we get the current value every
2537         100th call and use a cached value the rest of the time.  When colleciton is done, we start with
2538         a new overCriticalMemoryThreshold value for the next cycle.
2539
2540         The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact
2541         performance and still provides timely memory footprint data.  With additional debug logging, I
2542         determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream.
2543         Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per
2544         GC cycle.  Dividing both of these numbers by 100 seems reasonable.
2545
2546         * heap/Heap.cpp:
2547         (JSC::Heap::overCriticalMemoryThreshold):
2548         (JSC::Heap::updateAllocationLimits):
2549         (JSC::Heap::shouldDoFullCollection):
2550         * heap/Heap.h:
2551
2552 2017-05-17  Saam Barati  <sbarati@apple.com>
2553
2554         PinnedRegisters should be better modeled in IRC/Briggs
2555         https://bugs.webkit.org/show_bug.cgi?id=171955
2556
2557         Reviewed by Filip Pizlo.
2558
2559         This patch fixes a bug in Briggs/IRC with respect to pinned registers.
2560         Pinned registers were not part of the assignable register file in IRC/Briggs,
2561         and this would lead to an asymmetry because they were modeled in the
2562         interference graph. The bug is that we use registerCount() to move various
2563         Tmps between various lists in the different allocators, and if a Tmp
2564         interfered with a pinned register (usually via a Patchpoint's clobbered set),
2565         we'd have an interference edge modeled in the degree for that Tmp, but the registerCount()
2566         would make us think that this particular Tmp is not assignable. This would
2567         lead us to fail to color a colorable graph. Specifically, this happened in
2568         our various patchpoint tests that stress the register allocator by forcing
2569         the entire register file into arguments for the patchpoint and then doing
2570         interesting things with the result, arguments, etc.
2571         
2572         This patch fixes the bug by coming up with an more natural way to model pinned
2573         registers. Pinned registers are now part of the register file. However,
2574         pinned registers are live at every point in the program (this is a defining
2575         property of a pinned register). In practice, this means that the only Tmps 
2576         that can be assigned to pinned registers are ones that are coalescing
2577         candidates. This means the program has some number of defs for a Tmp T like:
2578         MoveType pinnedReg, T
2579         
2580         Note, if any other defs for T happen, like:
2581         Add32, t1, t2, T
2582         T will have an interference edge with pinnedReg, since pinnedReg is live
2583         at every point in the program. Modeling pinned registers this way allows
2584         IRC/Briggs to have no special casing for them. It treats it like any other
2585         precolored Tmp. This allows us to do coalescing, biased coloring, etc, which
2586         could all lead to a Tmp being assigned to a pinned register.
2587         
2588         Interestingly, we used to have special handling for the frame pointer
2589         register, which in many ways, acts like a pinned register, since FP is
2590         always live, and we wanted it to take place in coalescing. The allocator
2591         had a side-table interference graph with FP. Interestingly, we didn't even
2592         handle this properly everywhere since we could rely on a patchpoint never
2593         claiming to clobber FP (this would be illegal). So the code only handled
2594         the pseudo-pinned register properties of FP in various places. This patch
2595         drops this special casing and pins FP since all pinned registers can take
2596         part in coalescing.
2597
2598         * b3/B3PatchpointSpecial.h:
2599         * b3/B3Procedure.cpp:
2600         (JSC::B3::Procedure::mutableGPRs):
2601         (JSC::B3::Procedure::mutableFPRs):
2602         * b3/B3Procedure.h:
2603         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
2604         * b3/air/AirCode.cpp:
2605         (JSC::B3::Air::Code::Code):
2606         (JSC::B3::Air::Code::pinRegister):
2607         (JSC::B3::Air::Code::mutableGPRs):
2608         (JSC::B3::Air::Code::mutableFPRs):
2609         * b3/air/AirCode.h:
2610         (JSC::B3::Air::Code::pinnedRegisters):
2611         * b3/air/AirSpecial.h:
2612         * b3/air/testair.cpp:
2613         * b3/testb3.cpp:
2614         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
2615         (JSC::B3::testSpillDefSmallerThanUse):
2616         (JSC::B3::testLateRegister):
2617         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
2618         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
2619         (JSC::B3::testMoveConstants):
2620
2621 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2622
2623         [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String)
2624         https://bugs.webkit.org/show_bug.cgi?id=172115
2625
2626         Reviewed by Saam Barati.
2627
2628         In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping
2629         empty strings. However, when we are in Fixup phase, we do not have much information about
2630         constant values.
2631
2632         In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured
2633         out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce
2634         MakeRope handling in constant folding phase.
2635
2636         It shows 7.5% performance improvement in ARES-6 Babylon steadyState.
2637
2638             Before:
2639
2640             firstIteration:     50.02 +- 14.56 ms
2641             averageWorstCase:   26.52 +- 4.52 ms
2642             steadyState:        8.15 +- 0.23 ms
2643
2644             After:
2645
2646             firstIteration:     49.08 +- 12.90 ms
2647             averageWorstCase:   25.16 +- 3.82 ms
2648             steadyState:        7.58 +- 0.21 ms
2649
2650         * dfg/DFGAbstractInterpreterInlines.h:
2651         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2652         * dfg/DFGConstantFoldingPhase.cpp:
2653         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2654
2655 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2656
2657         Unreviewed, add Objective C files to CMake Mac port
2658         https://bugs.webkit.org/show_bug.cgi?id=172103
2659
2660         * shell/PlatformMac.cmake: Added.
2661
2662 2017-05-16  JF Bastien  <jfbastien@apple.com>
2663
2664         WebAssembly: enforce size limits
2665         https://bugs.webkit.org/show_bug.cgi?id=165833
2666         <rdar://problem/29760219>
2667
2668         Reviewed by Keith Miller.
2669
2670         Use the same limits as V8.
2671
2672         * JavaScriptCore.xcodeproj/project.pbxproj:
2673         * wasm/WasmLimits.h: Added.
2674         * wasm/WasmModuleParser.cpp:
2675         * wasm/WasmParser.h:
2676         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2677
2678 2017-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2679
2680         [JSC] Build testapi in non Apple ports
2681         https://bugs.webkit.org/show_bug.cgi?id=172103
2682
2683         Reviewed by Filip Pizlo.
2684
2685         This patch makes JSC testapi buildable in non-Apple ports.
2686         We isolate CF related tests in testapi.c. If we do not use
2687         CF, we include JavaScript.h instead of JavaScriptCore.h.
2688
2689         By running the testapi in Linux, we found that contraints
2690         test have a bug: If constraint marker runs after WeakRefs
2691         are destroyed, it accesses destroyed WeakRef. This patch
2692         also fixes it.
2693
2694         * API/tests/CurrentThisInsideBlockGetterTest.h:
2695         * API/tests/CustomGlobalObjectClassTest.c:
2696         * API/tests/ExecutionTimeLimitTest.cpp:
2697         * API/tests/FunctionOverridesTest.cpp:
2698         * API/tests/GlobalContextWithFinalizerTest.cpp:
2699         * API/tests/JSObjectGetProxyTargetTest.cpp:
2700         * API/tests/MultithreadedMultiVMExecutionTest.cpp:
2701         * API/tests/PingPongStackOverflowTest.cpp:
2702         * API/tests/TypedArrayCTest.cpp:
2703         * API/tests/testapi.c:
2704         (assertEqualsAsCharactersPtr):
2705         (markingConstraint):
2706         (testMarkingConstraintsAndHeapFinalizers):
2707         (testCFStrings):
2708         (main):
2709         * shell/CMakeLists.txt:
2710
2711 2017-05-16  JF Bastien  <jfbastien@apple.com>
2712
2713         WebAssembly: report Memory usage to GC
2714         https://bugs.webkit.org/show_bug.cgi?id=170690
2715         <rdar://problem/31965310>
2716
2717         Reviewed by Keith Miller.
2718
2719         * wasm/js/JSWebAssemblyMemory.cpp:
2720         (JSC::JSWebAssemblyMemory::grow):
2721         (JSC::JSWebAssemblyMemory::finishCreation):
2722         (JSC::JSWebAssemblyMemory::visitChildren):
2723
2724 2017-05-16  JF Bastien  <jfbastien@apple.com>
2725
2726         WebAssembly: validate load / store alignment
2727         https://bugs.webkit.org/show_bug.cgi?id=168836
2728         <rdar://problem/31965349>
2729
2730         Reviewed by Keith Miller.
2731
2732         * wasm/WasmFunctionParser.h: check the alignment
2733         * wasm/generateWasm.py: generate the log2 alignment helper
2734         (Wasm):
2735         (isSimple):
2736         (memoryLog2Alignment):
2737         * wasm/generateWasmOpsHeader.py:
2738         (memoryLog2AlignmentGenerator):
2739         * wasm/wasm.json: fix formatting
2740
2741 2017-05-15  Mark Lam  <mark.lam@apple.com>
2742
2743         Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread.
2744         https://bugs.webkit.org/show_bug.cgi?id=172147
2745
2746         Rubber-stamped by Saam Barati.
2747
2748         I rolled out every thing in those 2 patches except for the change to make
2749         CodeBlock::finishCreation() return a bool plus its clients that depend on this.
2750         I made this exception because r214931 relies on this change, and this part of
2751         the change looks correct.
2752
2753         * builtins/BuiltinNames.h:
2754         * builtins/GlobalOperations.js:
2755         (globalPrivate.speciesConstructor):
2756         (globalPrivate.copyDataProperties): Deleted.
2757         * bytecode/CodeBlock.cpp:
2758         (JSC::CodeBlock::finishCreation):
2759         (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted.
2760         * bytecode/CodeBlock.h:
2761         * bytecode/UnlinkedCodeBlock.h:
2762         (JSC::UnlinkedCodeBlock::addBitVector):
2763         (JSC::UnlinkedCodeBlock::constantRegisters):
2764         (JSC::UnlinkedCodeBlock::addSetConstant): Deleted.
2765         (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted.
2766         * bytecompiler/BytecodeGenerator.cpp:
2767         * bytecompiler/BytecodeGenerator.h:
2768         * bytecompiler/NodesCodegen.cpp:
2769         (JSC::PropertyListNode::emitBytecode):
2770         (JSC::ObjectPatternNode::bindValue):
2771         (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted.
2772         * parser/ASTBuilder.h:
2773         (JSC::ASTBuilder::createProperty):
2774         (JSC::ASTBuilder::appendObjectPatternEntry):
2775         (JSC::ASTBuilder::createObjectSpreadExpression): Deleted.
2776         (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted.
2777         (JSC::ASTBuilder::setContainsObjectRestElement): Deleted.
2778         * parser/NodeConstructors.h:
2779         (JSC::PropertyNode::PropertyNode):
2780         (JSC::SpreadExpressionNode::SpreadExpressionNode):
2781         (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted.
2782         * parser/Nodes.h:
2783         (JSC::ObjectPatternNode::appendEntry):
2784         (JSC::ObjectSpreadExpressionNode::expression): Deleted.
2785         (JSC::ObjectPatternNode::setContainsRestElement): Deleted.
2786         * parser/Parser.cpp:
2787         (JSC::Parser<LexerType>::parseDestructuringPattern):
2788         (JSC::Parser<LexerType>::parseProperty):
2789         * parser/SyntaxChecker.h:
2790         (JSC::SyntaxChecker::createSpreadExpression):
2791         (JSC::SyntaxChecker::createProperty):
2792         (JSC::SyntaxChecker::operatorStackPop):
2793         (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted.
2794         * runtime/ObjectConstructor.cpp:
2795         (JSC::ObjectConstructor::finishCreation):
2796         * runtime/SetPrototype.cpp:
2797         (JSC::SetPrototype::finishCreation):
2798
2799 2017-05-15  David Kilzer  <ddkilzer@apple.com>
2800
2801         JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic
2802         <https://webkit.org/b/172134>
2803
2804         Reviewed by Saam Barati.
2805
2806         * runtime/JSEnvironmentRecord.h:
2807         (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return
2808         size_t and use checked arithmetic.
2809         (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change
2810         to use checked arithmetic.
2811
2812 2017-05-15  Mark Lam  <mark.lam@apple.com>
2813
2814         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
2815         https://bugs.webkit.org/show_bug.cgi?id=171775
2816         <rdar://problem/30975761>
2817
2818         Reviewed by Filip Pizlo.
2819
2820         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
2821         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
2822         for our debugging needs.
2823
2824         Also added VM::throwingThread() to track which thread an exception was thrown in.
2825         This may be useful if the client is entering the VM from different threads.
2826
2827         * runtime/ExceptionScope.cpp:
2828         (JSC::ExceptionScope::unexpectedExceptionMessage):
2829         * runtime/ExceptionScope.h:
2830         (JSC::ExceptionScope::exception):
2831         (JSC::ExceptionScope::unexpectedExceptionMessage):
2832         * runtime/Options.h:
2833         - Added the unexpectedExceptionStackTraceLimit option.
2834         * runtime/VM.cpp:
2835         (JSC::VM::throwException):
2836         * runtime/VM.h:
2837         (JSC::VM::throwingThread):
2838         (JSC::VM::clearException):
2839
2840 2017-05-13  David Kilzer  <ddkilzer@apple.com>
2841
2842         Unused lambda capture in JSContextGroupAddMarkingConstraint()
2843         <https://webkit.org/b/172084>
2844
2845         Reviewed by Saam Barati.
2846
2847         Fixes the following warning with newer clang:
2848
2849             Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture]
2850                     [&vm, constraintCallback, userData]
2851                       ^
2852
2853         * API/JSMarkingConstraintPrivate.cpp:
2854         (JSContextGroupAddMarkingConstraint): Remove unused lambda
2855         capture for '&vm'.
2856
2857 2017-05-13  David Kilzer  <ddkilzer@apple.com>
2858
2859         [JSC] config.rb fails when checking some clang versions
2860         <https://webkit.org/b/172082>
2861
2862         Reviewed by Mark Lam.
2863
2864         * offlineasm/config.rb:
2865         - Add support for quad-dotted version of Apple clang (800.0.12.1).
2866         - Add support for checking open source clang version (5.0.0).
2867
2868 2017-05-13  Commit Queue  <commit-queue@webkit.org>
2869
2870         Unreviewed, rolling out r216808.
2871         https://bugs.webkit.org/show_bug.cgi?id=172075
2872
2873         caused lldb to hang when debugging (Requested by smfr on
2874         #webkit).
2875
2876         Reverted changeset:
2877
2878         "Use Mach exceptions instead of signals where possible"
2879         https://bugs.webkit.org/show_bug.cgi?id=171865
2880         http://trac.webkit.org/changeset/216808
2881
2882 2017-05-13  Commit Queue  <commit-queue@webkit.org>
2883
2884         Unreviewed, rolling out r216801.
2885         https://bugs.webkit.org/show_bug.cgi?id=172072
2886
2887         Many memory corruption crashes on worker threads (Requested by
2888         ap on #webkit).
2889
2890         Reverted changeset:
2891
2892         "WorkerRunLoop::Task::performTask() should check
2893         !scriptController->isTerminatingExecution()."
2894         https://bugs.webkit.org/show_bug.cgi?id=171775
2895         http://trac.webkit.org/changeset/216801
2896
2897 2017-05-12  Geoffrey Garen  <ggaren@apple.com>
2898
2899         [JSC] DFG::Node should not have its own allocator
2900         https://bugs.webkit.org/show_bug.cgi?id=160098
2901
2902         Reviewed by Saam Barati.
2903
2904         I just rebased the patch from <http://trac.webkit.org/changeset/203808>.
2905
2906         I ran Octane and JetStream locally on a MacBook Air and I wasn't able to
2907         reproduce a regression. Let's land this again and see what the bots say.
2908
2909         * JavaScriptCore.xcodeproj/project.pbxproj:
2910         * b3/B3SparseCollection.h:
2911         (JSC::B3::SparseCollection::packIndices):
2912         * dfg/DFGAllocator.h: Removed.
2913         * dfg/DFGDriver.cpp:
2914         (JSC::DFG::compileImpl):
2915         * dfg/DFGGraph.cpp:
2916         (JSC::DFG::Graph::Graph):
2917         (JSC::DFG::Graph::~Graph):
2918         (JSC::DFG::Graph::deleteNode):
2919         (JSC::DFG::Graph::packNodeIndices):
2920         (JSC::DFG::Graph::addNodeToMapByIndex): Deleted.
2921         * dfg/DFGGraph.h:
2922         (JSC::DFG::Graph::addNode):
2923         (JSC::DFG::Graph::maxNodeCount):
2924         (JSC::DFG::Graph::nodeAt):
2925         * dfg/DFGLongLivedState.cpp: Removed.
2926         * dfg/DFGLongLivedState.h: Removed.
2927         * dfg/DFGNode.h:
2928         * dfg/DFGNodeAllocator.h:
2929         * dfg/DFGPlan.cpp:
2930         (JSC::DFG::Plan::compileInThread):
2931         (JSC::DFG::Plan::compileInThreadImpl):
2932         * dfg/DFGPlan.h:
2933         * dfg/DFGWorklist.cpp:
2934         * runtime/VM.cpp:
2935         (JSC::VM::VM):
2936         * runtime/VM.h:
2937
2938 2017-05-12  Keith Miller  <keith_miller@apple.com>
2939
2940         Use Mach exceptions instead of signals where possible
2941         https://bugs.webkit.org/show_bug.cgi?id=171865
2942
2943         Reviewed by Mark Lam.
2944
2945         This patch adds some new JSC options. The first is an option that
2946         enables or disables web assembly tier up. The second controls
2947         whether or not we use mach exceptions (where available).
2948
2949         * API/tests/ExecutionTimeLimitTest.cpp:
2950         (dispatchTermitateCallback):
2951         (testExecutionTimeLimit):
2952         * runtime/JSLock.cpp:
2953         (JSC::JSLock::didAcquireLock):
2954         * runtime/Options.cpp:
2955         (JSC::overrideDefaults):
2956         (JSC::Options::initialize):
2957         * runtime/Options.h:
2958         * runtime/VMTraps.cpp:
2959         (JSC::SignalContext::SignalContext):
2960         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
2961         (JSC::installSignalHandler):
2962         (JSC::VMTraps::SignalSender::send):
2963         * tools/SigillCrashAnalyzer.cpp:
2964         (JSC::SignalContext::SignalContext):
2965         (JSC::SignalContext::dump):
2966         (JSC::installCrashHandler):
2967         * wasm/WasmBBQPlan.cpp:
2968         (JSC::Wasm::BBQPlan::compileFunctions):
2969         * wasm/WasmFaultSignalHandler.cpp:
2970         (JSC::Wasm::trapHandler):
2971         (JSC::Wasm::enableFastMemory):
2972         * wasm/WasmMachineThreads.cpp:
2973         (JSC::Wasm::resetInstructionCacheOnAllThreads):
2974
2975 2017-05-12  Mark Lam  <mark.lam@apple.com>
2976
2977         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
2978         https://bugs.webkit.org/show_bug.cgi?id=171775
2979         <rdar://problem/30975761>
2980
2981         Reviewed by Saam Barati.
2982
2983         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
2984         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
2985         for our debugging needs.
2986
2987         Also added VM::throwingThread() to track which thread an exception was thrown in.
2988         This may be useful if the client is entering the VM from different threads.
2989
2990         * runtime/ExceptionScope.cpp:
2991         (JSC::ExceptionScope::unexpectedExceptionMessage):
2992         * runtime/ExceptionScope.h:
2993         (JSC::ExceptionScope::exception):
2994         (JSC::ExceptionScope::unexpectedExceptionMessage):
2995         * runtime/Options.h:
2996         - Added the unexpectedExceptionStackTraceLimit option.
2997         * runtime/VM.cpp:
2998         (JSC::VM::throwException):
2999         * runtime/VM.h:
3000         (JSC::VM::throwingThread):
3001         (JSC::VM::clearException):
3002
3003 2017-05-12  Daniel Bates  <dabates@apple.com>
3004
3005         Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject&
3006         https://bugs.webkit.org/show_bug.cgi?id=172021
3007
3008         Reviewed by Mark Lam.
3009
3010         Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject&
3011         instead of a const JSGlobalObject* as all implementations expect to be passed a non-
3012         const, non-null JSGlobalObject object.
3013
3014         * runtime/JSGlobalObject.cpp:
3015         (JSC::JSGlobalObject::queueMicrotask):
3016         * runtime/JSGlobalObject.h:
3017         * runtime/VM.cpp:
3018         (JSC::VM::queueMicrotask):
3019         * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as
3020         it is only called from JavaScriptCore code.
3021
3022 2017-05-12  Michael Saboff  <msaboff@apple.com>
3023
3024         [iOS] Use memory footprint to dynamically adjust behavior of allocators
3025         https://bugs.webkit.org/show_bug.cgi?id=171944
3026
3027         Reviewed by Filip Pizlo.
3028
3029         This change is iOS only.
3030
3031         Added the ability to react to when memory usage is critical.  This is defined as memory
3032         usage being above the newly added option criticalGCMemoryThreshold.  When we are in this
3033         critical state, all collections are Full and we limit the amount of memory we allocate
3034         between collections to 1/4th the memory above the critical threshold.
3035
3036         Changed the calculation of proportionalHeapSize to be based on process memory footprint
3037         and not how big the heap is.  Also, the values of Options::smallHeapRAMFraction and
3038         Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens
3039         using the more agressive Options::smallHeapGrowthFactor.
3040
3041         * heap/Heap.cpp:
3042         (JSC::Heap::Heap):
3043         (JSC::Heap::overCriticalMemoryThreshold):
3044         (JSC::Heap::shouldDoFullCollection):
3045         (JSC::Heap::collectIfNecessaryOrDefer):
3046         * heap/Heap.h:
3047         * runtime/Options.cpp:
3048         (JSC::overrideDefaults):
3049         (JSC::Options::initialize):
3050         * runtime/Options.h:
3051
3052 2017-05-11  Saam Barati  <sbarati@apple.com>
3053
3054         Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles
3055         https://bugs.webkit.org/show_bug.cgi?id=171962
3056
3057         Reviewed by Filip Pizlo.
3058
3059         The purpose of getting the result width is to get the width of
3060         the result of the arithmetic. It does not care about that the
3061         Check happens to define scratches.
3062
3063         * b3/B3CheckSpecial.cpp:
3064         (JSC::B3::CheckSpecial::forEachArg):
3065         * b3/testb3.cpp:
3066         (JSC::B3::testCheckMul):
3067         (JSC::B3::testCheckMulMemory):
3068         (JSC::B3::testCheckMul64):
3069         (JSC::B3::testCheckMulFold):
3070         (JSC::B3::testCheckMulFoldFail):
3071         (JSC::B3::testCheckMulArgumentAliasing64):
3072         (JSC::B3::testCheckMulArgumentAliasing32):
3073         (JSC::B3::testCheckMul64SShr):
3074
3075 2017-05-11  Saam Barati  <sbarati@apple.com>
3076
3077         isValidForm for SimpleAddr should use ptr() instead of tmp()
3078         https://bugs.webkit.org/show_bug.cgi?id=171992
3079
3080         Reviewed by Filip Pizlo.
3081
3082         Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for
3083         SimpleAddr was using Arg::tmp() instead of ptr() to check
3084         if the address Tmp isGP(). It should be using Arg::ptr() instead
3085         of Arg::tmp() since Arg::ptr() is designed for SimpleAddr.
3086         
3087         This patch also fixes an incorrect assertion in the ARM64
3088         macro assembler. We were asserting various atomic ops were
3089         only over 32/64 bit operations. However, the code was properly handling
3090         8/16/32/64 bit ops. I changed the assertion to reflect what is
3091         actually going on.
3092
3093         * assembler/ARM64Assembler.h:
3094         (JSC::ARM64Assembler::ldar):
3095         (JSC::ARM64Assembler::ldxr):
3096         (JSC::ARM64Assembler::ldaxr):
3097         (JSC::ARM64Assembler::stxr):
3098         (JSC::ARM64Assembler::stlr):
3099         (JSC::ARM64Assembler::stlxr):
3100         * b3/air/opcode_generator.rb:
3101         * b3/testb3.cpp:
3102         (JSC::B3::testLoadAcq42):
3103         (JSC::B3::testStoreRelAddLoadAcq32):
3104         (JSC::B3::testStoreRelAddLoadAcq8):
3105         (JSC::B3::testStoreRelAddFenceLoadAcq8):
3106         (JSC::B3::testStoreRelAddLoadAcq16):
3107         (JSC::B3::testStoreRelAddLoadAcq64):
3108         (JSC::B3::testAtomicWeakCAS):
3109         (JSC::B3::testAtomicStrongCAS):
3110         (JSC::B3::testAtomicXchg):
3111
3112 2017-05-11  Matt Lewis  <jlewis3@apple.com>
3113
3114         Unreviewed, rolling out r216677.
3115
3116         Patch caused layout test crashes.
3117
3118         Reverted changeset:
3119
3120         "WorkerThread::stop() should call
3121         scheduleExecutionTermination() last."
3122         https://bugs.webkit.org/show_bug.cgi?id=171775
3123         http://trac.webkit.org/changeset/216677
3124
3125 2017-05-11  Don Olmstead  <don.olmstead@am.sony.com>
3126
3127         [CMake] Add HAVE check for regex.h
3128         https://bugs.webkit.org/show_bug.cgi?id=171950
3129
3130         Reviewed by Michael Catanzaro.
3131
3132         * runtime/ConfigFile.cpp:
3133         (JSC::ConfigFile::parse):
3134
3135 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
3136
3137         Callers of JSString::unsafeView() should check exceptions
3138         https://bugs.webkit.org/show_bug.cgi?id=171995
3139
3140         Reviewed by Mark Lam.
3141         
3142         unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying
3143         to access the view.
3144
3145         Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with
3146         the rest of JSC.
3147
3148         * dfg/DFGOperations.cpp:
3149         * jsc.cpp:
3150         (printInternal):
3151         (functionDebug):
3152         * runtime/ArrayPrototype.cpp:
3153         (JSC::arrayProtoFuncJoin):
3154         * runtime/FunctionConstructor.cpp:
3155         (JSC::constructFunctionSkippingEvalEnabledCheck):
3156         * runtime/IntlCollatorPrototype.cpp:
3157         (JSC::IntlCollatorFuncCompare):
3158         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3159         (JSC::genericTypedArrayViewProtoFuncJoin):
3160         * runtime/JSGlobalObjectFunctions.cpp:
3161         (JSC::globalFuncParseFloat):
3162         * runtime/JSONObject.cpp:
3163         (JSC::JSONProtoFuncParse):
3164         * runtime/JSString.cpp:
3165         (JSC::JSString::getPrimitiveNumber):
3166         (JSC::JSString::toNumber):
3167         * runtime/JSString.h:
3168         (JSC::JSString::getIndex):
3169         (JSC::JSRopeString::unsafeView):
3170         (JSC::JSRopeString::viewWithUnderlyingString):
3171         (JSC::JSString::unsafeView):
3172         (JSC::JSString::viewWithUnderlyingString):
3173         * runtime/JSStringJoiner.h:
3174         (JSC::JSStringJoiner::appendWithoutSideEffects):
3175         (JSC::JSStringJoiner::append):
3176         * runtime/ParseInt.h:
3177         (JSC::toStringView):
3178         * runtime/StringPrototype.cpp:
3179         (JSC::stringProtoFuncRepeatCharacter):
3180         (JSC::stringProtoFuncCharAt):
3181         (JSC::stringProtoFuncCharCodeAt):
3182         (JSC::stringProtoFuncIndexOf):
3183         (JSC::stringProtoFuncNormalize):
3184
3185 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
3186
3187         Offer SPI to notify clients that GC has happened
3188         https://bugs.webkit.org/show_bug.cgi?id=171980
3189
3190         Reviewed by Geoffrey Garen.
3191         
3192         Sometimes when you're programming with weak references, it's most convenient if the GC tells
3193         you when it finishes. This adds exactly such an API. This API is called at the *flip*: the
3194         moment when the GC knows for sure which objects are dead and has definitely not allocated any
3195         new objects or executed any JS code. The finalization part of the flip, which is where this
3196         callback gets called, runs on the "main" thread - i.e. some thread that is attempting to
3197         execute JS code and holds the JS lock. This will usually run as a side-effect of some
3198         allocation or from the runloop.
3199         
3200         This means, for example, that if you implemented a vector of weak references and registered a
3201         callback to prune the vector of null weak references, then aside from the callback, nobody
3202         would ever see a null weak reference in the vector.
3203
3204         * API/JSHeapFinalizerPrivate.cpp: Added.
3205         (JSContextGroupAddHeapFinalizer):
3206         (JSContextGroupRemoveHeapFinalizer):
3207         * API/JSHeapFinalizerPrivate.h: Added.
3208         * API/tests/testapi.c:
3209         (heapFinalizer):
3210         (testMarkingConstraintsAndHeapFinalizers):
3211         (main):
3212         (testMarkingConstraints): Deleted.
3213         * CMakeLists.txt:
3214         * JavaScriptCore.xcodeproj/project.pbxproj:
3215         * heap/Heap.cpp:
3216         (JSC::Heap::finalize):
3217         (JSC::Heap::addHeapFinalizerCallback):
3218         (JSC::Heap::removeHeapFinalizerCallback):
3219         * heap/Heap.h:
3220         * heap/HeapFinalizerCallback.cpp: Added.
3221         (JSC::HeapFinalizerCallback::dump):
3222         * heap/HeapFinalizerCallback.h: Added.
3223         (JSC::HeapFinalizerCallback::HeapFinalizerCallback):
3224         (JSC::HeapFinalizerCallback::operator==):
3225         (JSC::HeapFinalizerCallback::operator!=):
3226         (JSC::HeapFinalizerCallback::operator bool):
3227         (JSC::HeapFinalizerCallback::run):
3228
3229 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
3230
3231         JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef
3232         https://bugs.webkit.org/show_bug.cgi?id=171979
3233
3234         Reviewed by Mark Lam.
3235         
3236         Functions that don't execute arbitrary JS but just need access to the VM should take a
3237         JSContextGroupRef, not a JSContextRef.
3238
3239         * API/JSWeakPrivate.cpp:
3240         (JSWeakCreate):
3241         (JSWeakRetain):
3242         (JSWeakRelease):
3243         * API/JSWeakPrivate.h:
3244         * API/tests/testapi.c:
3245         (testMarkingConstraints):
3246
3247 2017-05-11  Mark Lam  <mark.lam@apple.com>
3248
3249         WorkerThread::stop() should call scheduleExecutionTermination() last.
3250         https://bugs.webkit.org/show_bug.cgi?id=171775
3251         <rdar://problem/30975761>
3252
3253         Reviewed by Geoffrey Garen.
3254
3255         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3256         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3257         for our debugging needs.
3258
3259         Also added VM::throwingThread() to track which thread an exception was thrown in.
3260         This may be useful if the client is entering the VM from different threads.
3261
3262         * runtime/ExceptionScope.cpp:
3263         (JSC::ExceptionScope::unexpectedExceptionMessage):
3264         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
3265         * runtime/ExceptionScope.h:
3266         (JSC::ExceptionScope::exception):
3267         (JSC::ExceptionScope::unexpectedExceptionMessage):
3268         * runtime/VM.cpp:
3269         (JSC::VM::throwException):
3270         * runtime/VM.h:
3271         (JSC::VM::throwingThread):
3272         (JSC::VM::clearException):
3273
3274 2017-05-11  JF Bastien  <jfbastien@apple.com>
3275
3276         WebAssembly: stop supporting 0xD
3277         https://bugs.webkit.org/show_bug.cgi?id=168788
3278         <rdar://problem/31880922>
3279
3280         Reviewed by Saam Barati.
3281
3282         Only version 1 is supported by other browsers, and there shouldn't
3283         be any 0xD binaries in the wild anymore.
3284
3285         * wasm/WasmModuleParser.cpp:
3286
3287 2017-05-09  Sam Weinig  <sam@webkit.org>
3288
3289         Remove support for legacy Notifications
3290         https://bugs.webkit.org/show_bug.cgi?id=171487
3291
3292         Reviewed by Jon Lee.
3293
3294         * Configurations/FeatureDefines.xcconfig:
3295         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
3296
3297 2017-05-10  Commit Queue  <commit-queue@webkit.org>
3298
3299         Unreviewed, rolling out r216635.
3300         https://bugs.webkit.org/show_bug.cgi?id=171953
3301
3302         "Some worker tests are failing". (Requested by mlam on #webkit).
3303
3304         Reverted changeset:
3305
3306         "WorkerThread::stop() should call
3307         scheduleExecutionTermination() last."
3308         https://bugs.webkit.org/show_bug.cgi?id=171775
3309         http://trac.webkit.org/changeset/216635
3310
3311 2017-05-10  Mark Lam  <mark.lam@apple.com>
3312
3313         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
3314         https://bugs.webkit.org/show_bug.cgi?id=160337
3315         <rdar://problem/27611733>
3316
3317         Not reviewed.
3318
3319         Updated a comment per Geoff's suggestion.
3320
3321         * heap/MachineStackMarker.cpp:
3322         (JSC::MachineThreads::tryCopyOtherThreadStack):
3323
3324 2017-05-10  Mark Lam  <mark.lam@apple.com>
3325
3326         WorkerThread::stop() should call scheduleExecutionTermination() last.
3327         https://bugs.webkit.org/show_bug.cgi?id=171775
3328         <rdar://problem/30975761>
3329
3330         Reviewed by Geoffrey Garen.
3331
3332         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3333         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3334         for our debugging needs.
3335
3336         Also added VM::throwingThread() to track which thread an exception was thrown in.
3337         This may be useful if the client is entering the VM from different threads.
3338
3339         * runtime/ExceptionScope.cpp:
3340         (JSC::ExceptionScope::unexpectedExceptionMessage):
3341         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
3342         * runtime/ExceptionScope.h:
3343         (JSC::ExceptionScope::exception):
3344         (JSC::ExceptionScope::unexpectedExceptionMessage):
3345         * runtime/VM.cpp:
3346         (JSC::VM::throwException):
3347         * runtime/VM.h:
3348         (JSC::VM::throwingThread):
3349         (JSC::VM::clearException):
3350
3351 2017-05-10  Mark Lam  <mark.lam@apple.com>
3352
3353         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
3354         https://bugs.webkit.org/show_bug.cgi?id=160337
3355         <rdar://problem/27611733>
3356
3357         Reviewed by Filip Pizlo and Geoffrey Garen.
3358
3359         This is a workaround for <rdar://problem/27607384>. During thread initialization,
3360         for some target platforms, thread state is momentarily set to 0 before being
3361         filled in with the target thread's real register values. As a result, there's
3362         a race condition that may result in us getting a null stackPointer during a GC scan.
3363         This issue may manifest with workqueue threads where the OS may choose to recycle
3364         a thread for an expired task.
3365
3366         The workaround is simply to indicate that there's nothing to copy and return.
3367         This is correct because we will only ever observe a null pointer during thread
3368         initialization. Hence, by definition, there's nothing there that we need to scan
3369         yet, and therefore, nothing that needs to be copied.
3370
3371         * heap/MachineStackMarker.cpp:
3372         (JSC::MachineThreads::tryCopyOtherThreadStack):
3373
3374 2017-05-10  JF Bastien  <jfbastien@apple.com>
3375
3376         WebAssembly: support name section
3377
3378         https://bugs.webkit.org/show_bug.cgi?id=171263
3379
3380         Reviewed by Keith Miller.
3381
3382         The name section is an optional custom section in the WebAssembly
3383         spec. At least when debugging, developers expect to be able to use
3384         this section to obtain intelligible stack traces, otherwise we
3385         just number the wasm functions which is somewhat painful.
3386
3387         This patch parses this section, dropping its content eagerly on
3388         error, and if there is a name section then backtraces use their
3389         value instead of numbers. Otherwise we stick to numbers as before.
3390
3391         Note that the format of name sections changed in mid-February:
3392           https://github.com/WebAssembly/design/pull/984
3393         And binaryen was only updated in early March:
3394           https://github.com/WebAssembly/binaryen/pull/933
3395
3396         * CMakeLists.txt:
3397         * JavaScriptCore.xcodeproj/project.pbxproj:
3398         * interpreter/Interpreter.cpp:
3399         (JSC::GetStackTraceFunctor::operator()):
3400         * interpreter/StackVisitor.cpp:
3401         (JSC::StackVisitor::readNonInlinedFrame):
3402         (JSC::StackVisitor::Frame::functionName):
3403         * interpreter/StackVisitor.h:
3404         (JSC::StackVisitor::Frame::wasmFunctionIndexOrName):
3405         * runtime/StackFrame.cpp:
3406         (JSC::StackFrame::functionName):
3407         * runtime/StackFrame.h:
3408         (JSC::StackFrame::StackFrame):
3409         (JSC::StackFrame::wasm):
3410         * wasm/WasmBBQPlanInlines.h:
3411         (JSC::Wasm::BBQPlan::initializeCallees):
3412         * wasm/WasmCallee.cpp:
3413         (JSC::Wasm::Callee::Callee):
3414         * wasm/WasmCallee.h:
3415         (JSC::Wasm::Callee::create):
3416         (JSC::Wasm::Callee::indexOrName):
3417         * wasm/WasmFormat.cpp:
3418         (JSC::Wasm::makeString):
3419         * wasm/WasmFormat.h:
3420         (JSC::Wasm::isValidExternalKind):
3421         (JSC::Wasm::isValidNameType):
3422         (JSC::Wasm::NameSection::get):
3423         * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
3424         (JSC::Wasm::IndexOrName::IndexOrName):
3425         (JSC::Wasm::makeString):
3426         * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp.
3427         * wasm/WasmModuleInformation.h:
3428         * wasm/WasmModuleParser.cpp:
3429         * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
3430         * wasm/WasmNameSectionParser.cpp: Added.
3431         * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
3432         (JSC::Wasm::NameSectionParser::NameSectionParser):
3433         * wasm/WasmOMGPlan.cpp:
3434         (JSC::Wasm::OMGPlan::work):
3435         * wasm/WasmParser.h:
3436         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
3437
3438 2017-05-10  Filip Pizlo  <fpizlo@apple.com>
3439
3440         Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname
3441         https://bugs.webkit.org/show_bug.cgi?id=171801
3442
3443         Reviewed by Michael Saboff.
3444         
3445         This was a goofy oversight. The for-in optimization relies on the bytecode generator
3446         to detect when the loop's index variable gets mutated. We forgot to have the hooks for
3447         detecting this in prefix and postfix operations (++i and i++).
3448
3449         * bytecompiler/NodesCodegen.cpp:
3450         (JSC::PostfixNode::emitResolve):
3451         (JSC::PrefixNode::emitResolve):
3452
3453 2017-05-10  Michael Catanzaro  <mcatanzaro@igalia.com>
3454
3455         [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128
3456         https://bugs.webkit.org/show_bug.cgi?id=171273
3457
3458         Reviewed by Carlos Garcia Campos.
3459
3460         * inspector/remote/glib/RemoteInspectorGlib.cpp:
3461         * inspector/remote/glib/RemoteInspectorServer.cpp:
3462
3463 2017-05-10  Adrian Perez de Castro  <aperez@igalia.com>
3464
3465         Remove some last remnants of the EFL port
3466         https://bugs.webkit.org/show_bug.cgi?id=171922
3467
3468         Reviewed by Antonio Gomes.
3469
3470         The EFL port is no more.
3471
3472         * PlatformEfl.cmake: Removed.
3473         * shell/PlatformEfl.cmake: Removed.
3474
3475 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
3476
3477         JSInjectedScriptHost should get a copy of the boundArgs
3478         https://bugs.webkit.org/show_bug.cgi?id=171897
3479
3480         Reviewed by Joseph Pecoraro.
3481         
3482         The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense
3483         for the inspector to get a copy of it.
3484
3485         * inspector/JSInjectedScriptHost.cpp:
3486         (Inspector::JSInjectedScriptHost::getInternalProperties):
3487         * runtime/JSBoundFunction.cpp:
3488         (JSC::JSBoundFunction::boundArgsCopy):
3489         * runtime/JSBoundFunction.h:
3490         (JSC::JSBoundFunction::boundArgs):
3491
3492 2017-05-09  Mark Lam  <mark.lam@apple.com>
3493
3494         Unindent some code in Watchdog::shouldTerminate().
3495         https://bugs.webkit.org/show_bug.cgi?id=171896
3496
3497         Rubber stamped by Keith Miller.
3498
3499         I should have done this before I landed r213107, but I forgot.  Unindenting it now.
3500
3501         * runtime/Watchdog.cpp:
3502         (JSC::Watchdog::shouldTerminate):
3503
3504 2017-05-09  Michael Saboff  <msaboff@apple.com>
3505
3506         Cap the number of FTL compilation threads on iOS to 2
3507         https://bugs.webkit.org/show_bug.cgi?id=171887
3508
3509         Reviewed by Filip Pizlo.
3510
3511         Set an iOS specific max of 2 threads.
3512
3513         * runtime/Options.h:
3514
3515 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
3516
3517         Heap::heap() should behave gracefully for null pointers
3518         https://bugs.webkit.org/show_bug.cgi?id=171888
3519         <rdar://problem/32005315>
3520
3521         Reviewed by Mark Lam.
3522         
3523         Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we
3524         return a null Heap. So, let's do that.
3525         
3526         This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression
3527         with 74% probability. That's a neutral result by our usual 95% standard.
3528
3529         * heap/HeapInlines.h:
3530         (JSC::Heap::heap):
3531
3532 2017-05-09  Yusuke Suzuki  <utatane.tea@gmail.com>
3533
3534         Handle IDLPromise<> properly
3535         https://bugs.webkit.org/show_bug.cgi?id=166752
3536
3537         Reviewed by Youenn Fablet.
3538
3539         Add JSPromise::resolve static function.
3540         This applies `Promise.resolve()` conversion to a given value.
3541
3542         * runtime/JSGlobalObject.cpp:
3543         (JSC::JSGlobalObject::init):
3544         (JSC::JSGlobalObject::visitChildren):
3545         * runtime/JSGlobalObject.h:
3546         (JSC::JSGlobalObject::promiseResolveFunction):
3547         * runtime/JSPromise.cpp:
3548         (JSC::JSPromise::resolve):
3549         * runtime/JSPromise.h:
3550
3551 2017-05-09  Zan Dobersek  <zdobersek@igalia.com>
3552
3553         Upstream the WPE port
3554         https://bugs.webkit.org/show_bug.cgi?id=171110
3555
3556         Reviewed by Alex Christensen.
3557
3558         * PlatformWPE.cmake: Added.
3559         * shell/PlatformWPE.cmake: Added.
3560
3561 2017-05-09  Saam Barati  <sbarati@apple.com>
3562
3563         CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables
3564         https://bugs.webkit.org/show_bug.cgi?id=171707
3565         <rdar://problem/31891649>
3566
3567         Reviewed by Filip Pizlo.
3568
3569         This patch fixes a bug where a Wasm->JS IC call stub would go stale
3570         and point into a CodeBlock no longer owned by any executable. The
3571         problematic scenario is this:
3572
3573         1. We generate the call IC which has a branch on a callee check. This
3574            callee owns the Executable in question. If the branch succeeds, it
3575            will call code belonging to a particular CodeBlock associated with
3576            that Executable.
3577
3578         2. Heap::deleteAllCodeBlocks is called. This leads the Executable to clear
3579            its various CodeBlock references.
3580
3581         3. Wasm has no idea this happened, so now it has stale ICs that point into
3582            code from a CodeBlock no longer belonging to an Executable.
3583
3584         This patch fixes the bug by informing all JSWebAssemblyCodeBlocks to unlink
3585         their CallLinkInfo when Heap::deleteAllCodeBlocks is called.
3586
3587         We track all JSWebAssemblyCodeBlocks by creating a new subspace for them.
3588         This allows us to quickly iterate over the live JSWebAssemblyCodeBlocks in the
3589         heap.
3590
3591         * CMakeLists.txt:
3592         * JavaScriptCore.xcodeproj/project.pbxproj:
3593         * heap/Heap.cpp:
3594         (JSC::Heap::deleteAllCodeBlocks):
3595         * heap/Subspace.h:
3596         * heap/SubspaceInlines.h:
3597         (JSC::Subspace::forEachLiveCell):
3598         * runtime/VM.cpp:
3599         (JSC::VM::VM):
3600         * runtime/VM.h:
3601         * wasm/js/JSWebAssemblyCodeBlock.cpp:
3602         (JSC::JSWebAssemblyCodeBlock::clearJSCallICs):
3603         * wasm/js/JSWebAssemblyCodeBlock.h:
3604         (JSC::JSWebAssemblyCodeBlock::createStructure): Deleted.
3605         (JSC::JSWebAssemblyCodeBlock::functionImportCount): Deleted.
3606         (JSC::JSWebAssemblyCodeBlock::module): Deleted.
3607         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
3608         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): Deleted.
3609         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): Deleted.
3610         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): Deleted.
3611         (JSC::JSWebAssemblyCodeBlock::codeBlock): Deleted.
3612         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): Deleted.
3613         (JSC::JSWebAssemblyCodeBlock::allocationSize): Deleted.
3614         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): Deleted.
3615         * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Added.
3616         (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace):
3617         (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace):
3618         (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
3619         (JSC::JSWebAssemblyCodeBlockSubspace::destroy):
3620         * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Added.
3621
3622 2017-05-08  Saam Barati  <sbarati@apple.com>
3623
3624         testWasmBoundsCheck and testCallFunctionWithHellaArguments is broken in testb3
3625         https://bugs.webkit.org/show_bug.cgi?id=171392
3626         <rdar://problem/31872222>
3627
3628         Reviewed by Keith Miller.
3629
3630         This patch fixes two bugs. The first one is:
3631         Inside testb3, we were using the wrong WasmBoundsCheckValue constructor.
3632         Everything compiled OK because of implicit casting in C. I've changed one
3633         of the constructors to take arguments in a different order so we don't
3634         run into this problem again.
3635         
3636         The second bug was that Air::ShufflePair::inst was assuming that a move
3637         from BigImm to its destination is always valid. This is not the case.
3638         For example, the store, `Move BigImm, Addr` is not allowed. I refactored
3639         the code to be correct by emitting more than one instruction when needeed.
3640         
3641         When testing my changes, I ran ARM64 testb3 both in debug and
3642         release. I ran into many pre-existing failures. I've opened
3643         a new bug to fix those here: https://bugs.webkit.org/show_bug.cgi?id=171826
3644
3645         * b3/B3WasmBoundsCheckValue.cpp:
3646         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
3647         * b3/B3WasmBoundsCheckValue.h:
3648         * b3/air/AirEmitShuffle.cpp:
3649         (JSC::B3::Air::ShufflePair::insts):
3650         (JSC::B3::Air::ShufflePair::inst): Deleted.
3651         * b3/air/AirEmitShuffle.h:
3652         * b3/air/AirLowerMacros.cpp:
3653         (JSC::B3::Air::lowerMacros):
3654         * b3/testb3.cpp:
3655         (JSC::B3::testLoadAcq42):
3656         (JSC::B3::testStoreRelAddLoadAcq32):
3657         (JSC::B3::testStoreRelAddLoadAcq8):
3658         (JSC::B3::testStoreRelAddFenceLoadAcq8):
3659         (JSC::B3::testStoreRelAddLoadAcq16):
3660         (JSC::B3::testStoreRelAddLoadAcq64):
3661         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
3662         (JSC::B3::testCheckMul):
3663         (JSC::B3::testCheckMulMemory):
3664         (JSC::B3::testCheckMul64):
3665         (JSC::B3::testCheckMulFold):
3666         (JSC::B3::testCheckMulFoldFail):
3667         (JSC::B3::testCheckMulArgumentAliasing64):
3668         (JSC::B3::testCheckMulArgumentAliasing32):
3669         (JSC::B3::testCheckMul64SShr):
3670         (JSC::B3::testCallFunctionWithHellaArguments):
3671         (JSC::B3::functionWithHellaArguments2):
3672         (JSC::B3::testCallFunctionWithHellaArguments2):
3673         (JSC::B3::functionWithHellaArguments3):
3674         (JSC::B3::testCallFunctionWithHellaArguments3):
3675         (JSC::B3::testSpillDefSmallerThanUse):
3676         (JSC::B3::testLateRegister):
3677         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
3678         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
3679         (JSC::B3::testMoveConstants):
3680         (JSC::B3::testAtomicWeakCAS):
3681         (JSC::B3::testAtomicStrongCAS):
3682         (JSC::B3::testAtomicXchg):
3683         (JSC::B3::testWasmBoundsCheck):
3684         (JSC::B3::run):
3685         * wasm/WasmB3IRGenerator.cpp:
3686         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
3687
3688 2017-05-08  Filip Pizlo  <fpizlo@apple.com>
3689
3690         Expose a function to get proxy targets
3691         https://bugs.webkit.org/show_bug.cgi?id=171797
3692         <rdar://problem/32027549>
3693
3694         Reviewed by Mark Lam.
3695         
3696         This exposes a new private API function, JSObjectGetProxyTarget(), that gets the target of a
3697         proxy. It works with both ProxyObject and JSProxy, but it's primarily intended for use with
3698         JSProxy.
3699
3700         * API/JSObjectRef.cpp:
3701         (JSObjectGetProxyTarget):
3702         * API/JSObjectRefPrivate.h:
3703         * API/tests/JSObjectGetProxyTargetTest.cpp: Added.
3704         (testJSObjectGetProxyTarget):
3705         * API/tests/JSObjectGetProxyTargetTest.h: Added.
3706         * API/tests/testapi.c:
3707         (main):
3708         * JavaScriptCore.xcodeproj/project.pbxproj:
3709         * runtime/ProxyObject.h:
3710         * shell/PlatformWin.cmake: 
3711
3712 2017-05-08  Mark Lam  <mark.lam@apple.com>
3713
3714         op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well.
3715         https://bugs.webkit.org/show_bug.cgi?id=171786
3716         <rdar://problem/32051023>
3717
3718         Reviewed by Saam Barati.
3719
3720         * bytecode/BytecodeDumper.cpp:
3721         (JSC::BytecodeDumper<Block>::dumpBytecode):
3722         - Fix BytecodeDumper to dump op_throw_static_error correctly.  Previously,
3723           it was expecting op1 to always be a constant.  r206870 changed it to take a
3724           variable string as well.
3725
3726         * bytecode/BytecodeUseDef.h:
3727         (JSC::computeUsesForBytecodeOffset):
3728         - Fix the bug.
3729
3730         * dfg/DFGByteCodeParser.cpp:
3731         (JSC::DFG::ByteCodeParser::parseBlock):
3732         - Move the Phantom of op1 after the ThrowStaticError node, because technically,
3733           the ThrowStaticError represents op_throw_static_error, and op_throw_static_error
3734           uses op1.  In practice, this probably doesn't matter, but let's have the code
3735           accurately communicate the behavior we're expecting.
3736
3737 2017-05-08  JF Bastien  <jfbastien@apple.com>
3738
3739         WebAssembly: don't just emit extended offset adds for patch
3740         https://bugs.webkit.org/show_bug.cgi?id=171799
3741
3742         Reviewed by Mark Lam.
3743
3744         It isn't necessary to restrict.
3745
3746         * b3/air/AirLowerStackArgs.cpp:
3747         (JSC::B3::Air::lowerStackArgs):
3748
3749 2017-05-08  Mark Lam  <mark.lam@apple.com>
3750
3751         Introduce ExceptionScope::assertNoException() and releaseAssertNoException().
3752         https://bugs.webkit.org/show_bug.cgi?id=171776
3753
3754         Reviewed by Keith Miller.
3755
3756         Instead of ASSERT(!scope.exception()), we can now do scope.assertNoException().
3757         Ditto for RELEASE_ASSERT and scope.releaseAssertNoException().  
3758
3759         The advantage of using ExceptionScope::assertNoException() and
3760         releaseAssertNoException() is that if the assertion fails, these utility
3761         functions will print the stack trace for where the unexpected exception is
3762         detected as well as where the unexpected exception was thrown from.  This makes
3763         it much easier to debug the source of unhandled exceptions.
3764
3765         * debugger/Debugger.cpp:
3766         (JSC::Debugger::pauseIfNeeded):
3767         * dfg/DFGOperations.cpp:
3768         * interpreter/Interpreter.cpp:
3769         (JSC::eval):
3770         (JSC::notifyDebuggerOfUnwinding):
3771         (JSC::Interpreter::executeProgram):
3772         (JSC::Interpreter::executeCall):
3773         (JSC::Interpreter::executeConstruct):
3774         (JSC::Interpreter::prepareForRepeatCall):
3775         (JSC::Interpreter::execute):
3776         (JSC::Interpreter::debug):
3777         * interpreter/ShadowChicken.cpp:
3778         (JSC::ShadowChicken::functionsOnStack):
3779         * jsc.cpp:
3780         (GlobalObject::moduleLoaderResolve):
3781         (GlobalObject::moduleLoaderFetch):
3782         (functionGenerateHeapSnapshot):
3783         (functionSamplingProfilerStackTraces):
3784         (box):
3785         (runWithScripts):
3786         * runtime/AbstractModuleRecord.cpp:
3787         (JSC::AbstractModuleRecord::finishCreation):
3788         * runtime/ArrayPrototype.cpp:
3789         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
3790         * runtime/Completion.cpp:
3791         (JSC::rejectPromise):
3792         * runtime/ErrorInstance.cpp:
3793         (JSC::ErrorInstance::sanitizedToString):
3794         * runtime/ExceptionHelpers.cpp:
3795         (JSC::createError):
3796         * runtime/ExceptionScope.cpp:
3797         (JSC::ExceptionScope::unexpectedExceptionMessage):
3798         * runtime/ExceptionScope.h:
3799         (JSC::ExceptionScope::assertNoException):
3800         (JSC::ExceptionScope::releaseAssertNoException):
3801         (JSC::ExceptionScope::unexpectedExceptionMessage):
3802         * runtime/GenericArgumentsInlines.h:
3803         (JSC::GenericArguments<Type>::defineOwnProperty):
3804         * runtime/IntlCollator.cpp:
3805         (JSC::IntlCollator::createCollator):
3806         (JSC::IntlCollator::resolvedOptions):
3807         * runtime/IntlDateTimeFormat.cpp:
3808         (JSC::IntlDateTimeFormat::resolvedOptions):
3809         (JSC::IntlDateTimeFormat::format):
3810         * runtime/IntlNumberFormat.cpp:
3811         (JSC::IntlNumberFormat::createNumberFormat):
3812         (JSC::IntlNumberFormat::resolvedOptions):
3813         * runtime/JSCJSValue.cpp:
3814         (JSC::JSValue::putToPrimitiveByIndex):
3815         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3816         (JSC::genericTypedArrayViewProtoFuncIncludes):
3817         (JSC::genericTypedArrayViewProtoFuncIndexOf):
3818         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
3819         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
3820         * runtime/JSGlobalObject.cpp:
3821         (JSC::JSGlobalObject::init):
3822         * runtime/JSGlobalObjectFunctions.cpp:
3823         (JSC::globalFuncHostPromiseRejectionTracker):
3824         * runtime/JSModuleEnvironment.cpp:
3825         (JSC::JSModuleEnvironment::getOwnPropertySlot):
3826         * runtime/JSModuleLoader.cpp:
3827         (JSC::JSModuleLoader::finishCreation):
3828         * runtime/JSModuleNamespaceObject.cpp:
3829         (JSC::JSModuleNamespaceObject::finishCreation):
3830         * runtime/JSONObject.cpp:
3831         (JSC::Stringifier::toJSON):
3832         * runtime/JSObject.cpp:
3833         (JSC::JSObject::ordinaryToPrimitive):
3834         * runtime/JSPropertyNameEnumerator.h:
3835         (JSC::propertyNameEnumerator):
3836         * runtime/ObjectConstructor.cpp:
3837         (JSC::objectConstructorGetOwnPropertyDescriptors):
3838         (JSC::objectConstructorDefineProperty):
3839         * runtime/ObjectPrototype.cpp:
3840         (JSC::objectProtoFuncHasOwnProperty):
3841         * runtime/ProgramExecutable.cpp:
3842         (JSC::ProgramExecutable::initializeGlobalProperties):
3843         * runtime/ReflectObject.cpp:
3844         (JSC::reflectObjectDefineProperty):
3845         * runtime/SamplingProfiler.cpp:
3846         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
3847         * runtime/StringPrototype.cpp:
3848         (JSC::stringProtoFuncRepeatCharacter):
3849         * runtime/TemplateRegistry.cpp:
3850         (JSC::TemplateRegistry::getTemplateObject):
3851         * runtime/VM.cpp:
3852         (JSC::VM::throwException):
3853         * runtime/VM.h:
3854         (JSC::VM::nativeStackTraceOfLastThrow):
3855         (JSC::VM::clearException):
3856         * wasm/WasmB3IRGenerator.cpp:
3857         * wasm/js/JSWebAssemblyInstance.cpp:
3858         (JSC::JSWebAssemblyInstance::create):
3859
3860 2017-05-06  Bill Ming  <mbbill@gmail.com>
3861
3862         Fix 32bit Windows build by giving correct parameters to MASM
3863         https://bugs.webkit.org/show_bug.cgi?id=170833
3864
3865         Reviewed by Alex Christensen.
3866
3867         * CMakeLists.txt:
3868
3869 2017-05-06  Oleksandr Skachkov  <gskachkov@gmail.com>
3870
3871         [ES6] Arrow function. Issue in access to this after eval('super()') within constructor
3872         https://bugs.webkit.org/show_bug.cgi?id=171543
3873
3874         Reviewed by Saam Barati.
3875
3876         Current patch force to use 'this' within arrow function or eval 
3877         from virtual scope each time, instead of using thisRegister.
3878
3879         * bytecompiler/BytecodeGenerator.cpp:
3880         (JSC::BytecodeGenerator::ensureThis):
3881
3882 2017-05-05  Keith Miller  <keith_miller@apple.com>
3883
3884         Put does not properly consult the prototype chain
3885         https://bugs.webkit.org/show_bug.cgi?id=171754
3886
3887         Reviewed by Saam Barati.
3888
3889         We should do a follow up that cleans up the rest of put. See:
3890         https://bugs.webkit.org/show_bug.cgi?id=171759
3891
3892         * runtime/JSCJSValue.cpp:
3893         (JSC::JSValue::putToPrimitive):
3894         * runtime/JSObject.cpp:
3895         (JSC::JSObject::putInlineSlow):
3896         * runtime/JSObjectInlines.h:
3897         (JSC::JSObject::canPerformFastPutInline):
3898
3899 2017-05-05  JF Bastien  <jfbastien@apple.com>
3900
3901         WebAssembly: Air::Inst::generate crashes on large binary on A64
3902         https://bugs.webkit.org/show_bug.cgi?id=170215
3903
3904         Reviewed by Filip Pizlo.
3905
3906         ARM can't encode all offsets in a single instruction. We usualy
3907         handle this type of detail early, or the macro assembler uses a
3908         scratch register to take care of the large immediate. After
3909         register allocation we assumed that we would never get large
3910         offsets, and asserted this was the case. That was a fine
3911         assumption with JavaScript, but WebAssembly ends up generating
3912         stack frames which are too big to encode.
3913
3914         There are two places that needed to be fixed:
3915             1. AirGenerate
3916             2. AirLowerStackArgs
3917
3918         We now unconditionally pin the dataTempRegister on ARM64, and use
3919         it when immediates don't fit.
3920
3921         Number 1. is easy: we're just incrementing SP, make sure we can
3922         use a scratch register when that happens.
3923
3924         Number 2. is more complex: not all Inst can receive a stack
3925         argument whose base register isn't SP or FP. Specifically,
3926         Patchpoints and Stackmaps get very sad because they just want to
3927         know the offset value, but when we materialize the offset as