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