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