jsc.cpp is leaking memory allocated by readline in runInteractive
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-10-25  Christopher Reid  <Christopher.Reid@am.sony.com>
2
3         jsc.cpp is leaking memory allocated by readline in runInteractive
4         https://bugs.webkit.org/show_bug.cgi?id=163958
5
6         According to http://web.mit.edu/gnu/doc/html/rlman_2.html,
7         "The line readline returns is allocated with malloc ();
8         you should free () the line when you are done with it."
9         The memory allocated by readline is not being freed when it should.
10
11         Reviewed by Mark Lam.
12
13         * jsc.cpp:
14
15 2016-10-25  Konstantin Tokarev  <annulen@yandex.ru>
16
17         [cmake] Check if jscLib and WebKitGUID targets exist before using them
18         https://bugs.webkit.org/show_bug.cgi?id=163945
19
20         Reviewed by Alex Christensen.
21
22         Currently these targets are used under WIN32 condition, however they
23         are defined in PlatformWin.cmake, causing CMake warnings if port
24         supports WIN32 but does not use PlatformWin.cmake
25
26         * shell/CMakeLists.txt:
27
28 2016-10-25  JF Bastien  <jfbastien@apple.com>
29
30         WebAssembly JS API: implement Module
31
32         This implementation allows us to:
33          - Syncrhonously create a WebAssembly.Module with a typed array.
34          - Creates a compilation plan.
35          - Parse the Module and creates corresponding code.
36          - Throw WebAssembly.CompileError with mildly helpful [*] error messages on
37            failure.
38
39         Consult the API documentation for expected behavior: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymodule-constructor
40
41         For now the implementation discards the generated code.
42
43         The next steps will be:
44          - Expose a Module's exports.
45          - Implement WebAssembly.Instance, which allows instantiating and running a
46            compiled Module.
47          - Beef up the testing infrastructure under JSTests/wasm so that more complex
48            modules can be created and tested (instead of writing the bits by hand).
49
50         This patch also:
51          - Adds assert.instanceof in assert.js.
52          - Refactors Wasm::Parser and friends to accept const uint8_t* as well as a
53            Vector, to avoid copying when invoked synchronously.
54          - Remove useless Structure from some of the wasm constructors: they're already
55            on the JSGlobalObject, visited properly and all.
56          - Fix off-by-one error in parsing: Parser::parseUInt32 failed if the integer
57            was exactly at end of file.
58
59          [*] On error messages while parsing: I filed https://bugs.webkit.org/show_bug.cgi?id=163919
60
61         WebAssembly JS API: implement Module
62         https://bugs.webkit.org/show_bug.cgi?id=163903
63
64         Reviewed by Keith Miller.
65
66         * runtime/ExceptionHelpers.cpp:
67         (JSC::defaultSourceAppender): make this public so that WebAssembly can use it: it generates those fancy (evaluating '...') messages at the end
68         * runtime/ExceptionHelpers.h:
69         * runtime/JSGlobalObject.cpp:
70         (JSC::JSGlobalObject::init): remove the useless Structure from the WebAssembly objects (it's already in this file, no need to hold two references and visit them twice)
71         * testWasm.cpp:
72         (runWasmTests): update API
73         * wasm/WasmB3IRGenerator.cpp:
74         (JSC::Wasm::parseAndCompile): use updated API
75         * wasm/WasmB3IRGenerator.h:
76         * wasm/WasmFunctionParser.h:
77         (JSC::Wasm::FunctionParser<Context>::FunctionParser): use updated API
78         (JSC::Wasm::FunctionParser<Context>::parseExpression): use updated API
79         * wasm/WasmModuleParser.cpp:
80         (JSC::Wasm::ModuleParser::parse): generate error messages
81         * wasm/WasmModuleParser.h:
82         (JSC::Wasm::ModuleParser::ModuleParser):
83         (JSC::Wasm::ModuleParser::failed):
84         (JSC::Wasm::ModuleParser::errorMessage):
85         (JSC::Wasm::ModuleParser::functionInformation):
86         (JSC::Wasm::ModuleParser::memory):
87         * wasm/WasmParser.h: use update non-public API
88         (JSC::Wasm::Parser::parseVarUInt32):
89         (JSC::Wasm::Parser::parseVarUInt64):
90         (JSC::Wasm::Parser::source):
91         (JSC::Wasm::Parser::length):
92         (JSC::Wasm::Parser::Parser):
93         (JSC::Wasm::Parser::consumeCharacter):
94         (JSC::Wasm::Parser::consumeString):
95         (JSC::Wasm::Parser::parseUInt32):
96         (JSC::Wasm::Parser::parseUInt7):
97         * wasm/WasmPlan.cpp:
98         (JSC::Wasm::Plan::Plan):
99         (JSC::Wasm::Plan::~Plan):
100         * wasm/WasmPlan.h:
101         (JSC::Wasm::Plan::failed):
102         (JSC::Wasm::Plan::errorMessage):
103         (JSC::Wasm::Plan::resultSize):
104         (JSC::Wasm::Plan::result):
105         (JSC::Wasm::Plan::memory):
106         * wasm/js/JSWebAssemblyCompileError.cpp:
107         (JSC::createWebAssemblyCompileError): makes it easier to throw a WebAssembly.CompileError from Module
108         * wasm/js/JSWebAssemblyCompileError.h:
109         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
110         (JSC::WebAssemblyCompileErrorConstructor::create):
111         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
112         * wasm/js/WebAssemblyCompileErrorConstructor.h:
113         * wasm/js/WebAssemblyInstanceConstructor.cpp:
114         (JSC::WebAssemblyInstanceConstructor::create):
115         (JSC::WebAssemblyInstanceConstructor::finishCreation):
116         (JSC::WebAssemblyInstanceConstructor::visitChildren):
117         * wasm/js/WebAssemblyInstanceConstructor.h:
118         * wasm/js/WebAssemblyMemoryConstructor.cpp:
119         (JSC::WebAssemblyMemoryConstructor::create):
120         (JSC::WebAssemblyMemoryConstructor::finishCreation):
121         (JSC::WebAssemblyMemoryConstructor::visitChildren):
122         * wasm/js/WebAssemblyMemoryConstructor.h:
123         * wasm/js/WebAssemblyModuleConstructor.cpp:
124         (JSC::constructJSWebAssemblyModule):
125         (JSC::WebAssemblyModuleConstructor::create):
126         (JSC::WebAssemblyModuleConstructor::finishCreation):
127         (JSC::WebAssemblyModuleConstructor::visitChildren):
128         * wasm/js/WebAssemblyModuleConstructor.h:
129         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
130         (JSC::WebAssemblyRuntimeErrorConstructor::create):
131         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
132         * wasm/js/WebAssemblyRuntimeErrorConstructor.h:
133         * wasm/js/WebAssemblyTableConstructor.cpp:
134         (JSC::WebAssemblyTableConstructor::create):
135         (JSC::WebAssemblyTableConstructor::finishCreation):
136         (JSC::WebAssemblyTableConstructor::visitChildren):
137         * wasm/js/WebAssemblyTableConstructor.h:
138
139 2016-10-25  Keith Miller  <keith_miller@apple.com>
140
141         Add trivial Wasm conversion opcodes
142         https://bugs.webkit.org/show_bug.cgi?id=163950
143
144         Reviewed by Filip Pizlo.
145
146         This patch differentiates between Wasm opcodes that are trivially mapped to a B3 opcode and
147         those that are not.  Some of the Wasm opcodes that are currently a non-simple opcode will
148         become simple as we add B3 opcodes for Wasm operations.  The remaining opcodes will need to
149         be added via patchpoints in a later patch.
150
151         * wasm/WasmB3IRGenerator.cpp:
152         * wasm/WasmOps.h:
153         (JSC::Wasm::isSimple):
154
155 2016-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
156
157         Arrow functions with concise bodies cannot return regular expressions
158         https://bugs.webkit.org/show_bug.cgi?id=163162
159
160         Reviewed by Filip Pizlo.
161
162         When we encounter the RegExp in the parser, we first scan it as / or /=.
163         And if / or /= is parsed under the primary expression context, we rescan it
164         as RegExp. However, we did not update the token record information. So the
165         token record still says "I'm / or /=".
166
167         When we parse the string "() => /hello/", the last token becomes "/", which is
168         the first character of the RegExp, instead of "/hello/". Since the arrow
169         function parsing utilizes the end offset of the last token, we accidentally
170         recognize the range of the above arrow function as "() => /".
171
172         In this patch, we update the token when rescanning under the RegExp context.
173         This logic is similar to parsing Tail Template Literal token.
174
175         We also refine the error message for regular expression literals. And since
176         the REGEXP token is now introduced, the other error messages using that token
177         are improved too.
178
179         Currently, unterminated error messages can be seen in Parser.cpp. However,
180         these messages cannot be shown to users if the lexer has m_error. So these
181         code is meaningless. I'll move these tokenizing errors to the lexer in the
182         subsequent patch[1].
183
184         [1]: https://bugs.webkit.org/show_bug.cgi?id=163928
185
186         * parser/Lexer.cpp:
187         (JSC::Lexer<T>::fillTokenInfo):
188         (JSC::Lexer<T>::lex):
189         (JSC::Lexer<T>::scanRegExp):
190         (JSC::Lexer<T>::scanTrailingTemplateString):
191         (JSC::Lexer<T>::skipRegExp): Deleted.
192         * parser/Lexer.h:
193         (JSC::Lexer::getToken):
194         * parser/Parser.cpp:
195         (JSC::Parser<LexerType>::parseAssignmentExpression):
196         * parser/Parser.h:
197         (JSC::Parser::getToken):
198         * parser/ParserTokens.h:
199
200 2016-10-24  Per Arne Vollan  <pvollan@apple.com>
201
202         [Win] CMake build type is not set.
203         https://bugs.webkit.org/show_bug.cgi?id=163917
204
205         Reviewed by Alex Christensen.
206
207         The CMAKE_BUILD_TYPE variable should be set to Debug or Release.
208
209         * JavaScriptCore.vcxproj/JavaScriptCore.proj:
210
211 2016-10-24  Chris Dumez  <cdumez@apple.com>
212
213         Reduce special handling for typed arrays in JSDOMConvert.h
214         https://bugs.webkit.org/show_bug.cgi?id=163907
215
216         Reviewed by Sam Weinig.
217
218         Reduce special handling for typed arrays in JSDOMConvert.h by adding a toWrapped() static
219         function on JSGenericTypedArrayView, similarly to other wrapper types.
220
221         * runtime/JSGenericTypedArrayView.h:
222         (JSC::JSGenericTypedArrayView::typedImpl):
223         (JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
224
225 2016-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
226
227         [DOMJIT][DFG] CallDOM never writes Stack
228         https://bugs.webkit.org/show_bug.cgi?id=163926
229
230         Reviewed by Filip Pizlo and Saam Barati.
231
232         There is no way to write(Stack) in CallDOM.
233         This worst case (the most clobbering case) scenario
234         should be aligned to the one of Call, read(World) and write(Heap).
235
236         * dfg/DFGClobberize.h:
237         (JSC::DFG::clobberize):
238
239 2016-10-23  Yusuke Suzuki  <utatane.tea@gmail.com>
240
241         [DOMJIT] Add a way for DOMJIT::Patchpoint to express effects
242         https://bugs.webkit.org/show_bug.cgi?id=163657
243
244         Reviewed by Saam Barati.
245
246         This patch introduces DOMJIT::Effect. It describes the side effects of
247         the DOMJIT::CallDOMPatchpoint. DOMJIT::CallDOMPatchpoint can use this
248         feature to teach the compilers about the effects. And the compilers
249         will perform CSE based on the reported effects.
250
251         As the same to B3's HeapRange, the effects are represented as a pair of
252         integers. [begin, end) pair will represents the range of the abstract
253         heap. We encode the abstract heap hierarchy into these pairs. Like,
254
255                                 Root: [0, 32)
256                  Child1: [0, 20)             Child2: [20, 32)
257         Child11: [0, 4) Child12: [4, 20)
258
259         This simplifies the representation of the abstract heap. And WebCore
260         just tells pairs of integers and it does not tell any detailed hierarchy.
261         So, DFG and FTL can optimize DOM operations without deep knowledge of
262         the DOM abstract heap hierarchy. For example, WebCore will tell that
263         firstChild will read Node_firstChild abstract heap. But this information
264         is encoded to the pair and DFG does not know the details. But still
265         DFG can understand the abstract heap hierarchy and can query whether the
266         given abstract heap overlaps with some abstract heap.
267
268         The heap range told by the WebCore is represented as DOMJIT::HeapRange.
269         DFG will handle this under the DOMState abstract heap. DOMJIT::HeapRange
270         is stored in DFG::AbstractHeap's Payload. We maintain the hierarchy by
271         DOMJIT::HeapRange in the DOMState abstract heap. We add a necessary
272         handling in DFG's AbstractHeap and ClobberSet.
273
274         And we also introduce DOMStateLoc for HeapLocation. It is combined with
275         DOMState AbstractHeap with DOMJIT::HeapRange. For example, we can
276         represent Node.firstChild as `read(DOMState:Node_firstChild)` and
277         `def(HeapLocation(node, DOMState:Node_firstChild))` thingy. This allows us
278         to perform CSE onto DOM getters that will read some of DOM heap!
279
280         For simplicity, we convert CallDOM from NodeVarArgs to the normal one.
281         CallDOM is now just used for DOMJIT getter. So its children is at most 2.
282         It may have either 1 or 2 children. If the global object is required
283         by CallDOMPatchpoint, it has 2 children. And we changed the order of
284         the children to further simplify the code. Before this change, the order
285         is 1: globalObject 2: base. After this patch, the order becomes 1: base,
286         and 2: globalObject. And the child2 may not exists if the global object
287         is not required. We changed all the existing DOMJIT patchpoint to this
288         form.
289
290         * CMakeLists.txt:
291         * JavaScriptCore.xcodeproj/project.pbxproj:
292         * bytecode/PolymorphicAccess.cpp:
293         (JSC::AccessCase::emitDOMJITGetter):
294         * dfg/DFGAbstractHeap.cpp:
295         (JSC::DFG::AbstractHeap::dump):
296         * dfg/DFGAbstractHeap.h:
297         (JSC::DFG::AbstractHeap::isStrictSubtypeOf):
298         (JSC::DFG::AbstractHeap::overlaps):
299         * dfg/DFGAbstractInterpreterInlines.h:
300         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
301         * dfg/DFGByteCodeParser.cpp:
302         (JSC::DFG::blessCallDOM):
303         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
304         * dfg/DFGClobberSet.cpp:
305         (JSC::DFG::ClobberSet::overlaps):
306         * dfg/DFGClobberSet.h:
307         * dfg/DFGClobberize.h:
308         (JSC::DFG::clobberize):
309         * dfg/DFGDoesGC.cpp:
310         (JSC::DFG::doesGC):
311         * dfg/DFGFixupPhase.cpp:
312         (JSC::DFG::FixupPhase::fixupNode):
313         * dfg/DFGGraph.h:
314         * dfg/DFGHeapLocation.cpp:
315         (WTF::printInternal):
316         * dfg/DFGHeapLocation.h:
317         * dfg/DFGNode.h:
318         (JSC::DFG::Node::hasCallDOMData):
319         (JSC::DFG::Node::callDOMData):
320         (JSC::DFG::Node::hasCallDOMPatchpoint): Deleted.
321         (JSC::DFG::Node::callDOMPatchpoint): Deleted.
322         * dfg/DFGNodeType.h:
323         * dfg/DFGSpeculativeJIT.cpp:
324         (JSC::DFG::SpeculativeJIT::compileCallDOM):
325         * domjit/DOMJITAbstractHeap.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
326         (JSC::DOMJIT::AbstractHeap::compute):
327         (JSC::DOMJIT::AbstractHeap::dump):
328         (JSC::DOMJIT::AbstractHeap::shallowDump):
329         (JSC::DOMJIT::AbstractHeap::deepDump):
330         * domjit/DOMJITAbstractHeap.h: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
331         (JSC::DOMJIT::AbstractHeap::AbstractHeap):
332         (JSC::DOMJIT::AbstractHeap::setParent):
333         (JSC::DOMJIT::AbstractHeap::isRoot):
334         (JSC::DOMJIT::AbstractHeap::isComputed):
335         (JSC::DOMJIT::AbstractHeap::range):
336         * domjit/DOMJITCallDOMPatchpoint.h:
337         * domjit/DOMJITEffect.h: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
338         (JSC::DOMJIT::Effect::forReadWrite):
339         (JSC::DOMJIT::Effect::forPure):
340         (JSC::DOMJIT::Effect::forDef):
341         (JSC::DOMJIT::Effect::mustGenerate):
342         * domjit/DOMJITHeapRange.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
343         (JSC::DOMJIT::HeapRange::dump):
344         * domjit/DOMJITHeapRange.h: Added.
345         (JSC::DOMJIT::HeapRange::HeapRange):
346         (JSC::DOMJIT::HeapRange::fromRaw):
347         (JSC::DOMJIT::HeapRange::begin):
348         (JSC::DOMJIT::HeapRange::end):
349         (JSC::DOMJIT::HeapRange::rawRepresentation):
350         (JSC::DOMJIT::HeapRange::operator bool):
351         (JSC::DOMJIT::HeapRange::operator==):
352         (JSC::DOMJIT::HeapRange::top):
353         (JSC::DOMJIT::HeapRange::none):
354         (JSC::DOMJIT::HeapRange::isStrictSubtypeOf):
355         (JSC::DOMJIT::HeapRange::isSubtypeOf):
356         (JSC::DOMJIT::HeapRange::overlaps):
357         * ftl/FTLLowerDFGToB3.cpp:
358         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
359         * jsc.cpp:
360
361 2016-10-24  Alex Christensen  <achristensen@webkit.org>
362
363         JSONParse should not crash with null Strings
364         https://bugs.webkit.org/show_bug.cgi?id=163918
365         <rdar://problem/28834095>
366
367         Reviewed by Michael Saboff.
368
369         When JSONParse is called with a null String, it calls String::is8bit, which dereferences a null pointer.
370         This is happening with new work in the Fetch API, but callers of JSONParse should not have to check
371         if the String is null.
372
373         * API/tests/JSONParseTest.cpp: Added.
374         (testJSONParse):
375         * API/tests/JSONParseTest.h: Added.
376         * API/tests/testapi.c:
377         (main):
378         Test parsing null Strings.  They should have the same result as parsing empty Strings.
379         * JavaScriptCore.xcodeproj/project.pbxproj:
380         * runtime/JSONObject.cpp:
381         (JSC::JSONParse):
382         Check for null Strings.
383         * shell/PlatformWin.cmake:
384
385 2016-10-24  Devin Rousso  <dcrousso+webkit@gmail.com>
386
387         Web Inspector: Scope chain shouldn't show empty Closure sections
388         https://bugs.webkit.org/show_bug.cgi?id=152348
389
390         Reviewed by Joseph Pecoraro.
391
392         * inspector/InjectedScriptSource.js:
393         (isEmptyObject):
394         (InjectedScript.CallFrameProxy._createScopeJson):
395         If the scope object has no properties, set empty to true.
396
397         * inspector/protocol/Debugger.json:
398         Added empty property to Scope type.
399
400 2016-10-24  Keith Miller  <keith_miller@apple.com>
401
402         Wasm should support floating point operations.
403         https://bugs.webkit.org/show_bug.cgi?id=163770
404
405         Reviewed by Michael Saboff.
406
407         Since we now have a Double => Float Trunc in B3, we can now support calls in Wasm
408         that take floating point arguments. This patch also enables most of the Wasm
409         floating point operations, as the associated B3 opcode has been linked via wasm.json.
410         If there is no direct mapping to a B3 opcode the Wasm is not yet implemented. This
411         patch also fixes a bug in calls where the arguments would be reversed.
412
413         * testWasm.cpp:
414         (cast):
415         (invoke):
416         (boxf):
417         (boxd):
418         (runWasmTests):
419         * wasm/WasmB3IRGenerator.cpp:
420         (JSC::Wasm::createJSWrapper):
421         * wasm/WasmCallingConvention.h:
422         (JSC::Wasm::CallingConvention::loadArguments):
423         (JSC::Wasm::CallingConvention::setupCall):
424         * wasm/WasmFunctionParser.h:
425         (JSC::Wasm::FunctionParser<Context>::parseExpression):
426         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
427         * wasm/WasmOps.h:
428
429 2016-10-24  Mark Lam  <mark.lam@apple.com>
430
431         Dumping of op_negate bytecode is broken.
432         https://bugs.webkit.org/show_bug.cgi?id=163896
433
434         Reviewed by Darin Adler.
435
436         It thinks the bytecode consists of only 3 machine words, when it consists of 4.
437         This is now fixed.
438
439         * bytecode/CodeBlock.cpp:
440         (JSC::CodeBlock::dumpBytecode):
441
442 2016-10-24  Youenn Fablet  <youenn@apple.com>
443
444         Activate WEB_RTC compilation flags for Mac bots
445         https://bugs.webkit.org/show_bug.cgi?id=163886
446
447         Reviewed by Eric Carlson.
448
449         * Configurations/FeatureDefines.xcconfig:
450
451 2016-10-23  Zan Dobersek  <zdobersek@igalia.com>
452
453         Unreviewed. Build fix for Clang and libstdc++ configurations.
454
455         * b3/testb3.cpp:
456         (JSC::B3::testAbsArgWithEffectfulDoubleConversion): Explicitly cast the
457         float-typed return value of fabs(float) to double in order to avoid
458         ambiguous calls to isIdentical().
459         (JSC::B3::testSqrtArgWithEffectfulDoubleConversion): Ditto for sqrt(float).
460
461 2016-10-22  Chris Dumez  <cdumez@apple.com>
462
463         WebGLRenderingContextBase.bufferData() should use a union instead of overloading
464         https://bugs.webkit.org/show_bug.cgi?id=163795
465
466         Reviewed by Darin Adler.
467
468         * runtime/ArrayBufferView.h:
469         (JSC::ArrayBufferView::data):
470         Add a data() method which aliases baseAddress() to align the API with
471         ArrayBuffer and reduce special handling at call sites.
472
473         * runtime/JSArrayBuffer.h:
474         (JSC::toArrayBuffer):
475         (JSC::JSArrayBuffer::toWrapped):
476         Add toWrapped() method similarly with WebCore wrapper types to
477         reduce special handling of JSArrayBuffer type.
478
479         * runtime/JSArrayBufferView.cpp:
480         (JSC::JSArrayBufferView::toWrapped):
481         * runtime/JSArrayBufferView.h:
482         Add toWrapped() method similarly with WebCore wrapper types to
483         reduce special handling of JSArrayBufferView type.
484
485 2016-10-21  Filip Pizlo  <fpizlo@apple.com>
486
487         Slow and big Heap methods should not be inline
488         https://bugs.webkit.org/show_bug.cgi?id=163802
489
490         Reviewed by Keith Miller.
491         
492         JSC often suffers from the inline cargo cult, and Heap is a prime example. This outlines a
493         bunch of Heap methods that are either already very big, or call out-of-line methods, or call
494         very big methods, or are not called often enough for inlining to matter.
495         
496         This simplifies concurrent GC work because I'm so tired of recompiling the world when I touch
497         one of these methods.
498         
499         This looks to be perf-neutral.
500
501         * heap/Heap.cpp:
502         (JSC::Heap::shouldCollect):
503         (JSC::Heap::isCurrentThreadBusy):
504         (JSC::Heap::reportExtraMemoryVisited):
505         (JSC::Heap::reportExternalMemoryVisited):
506         (JSC::Heap::collectIfNecessaryOrDefer):
507         (JSC::Heap::collectAccordingToDeferGCProbability):
508         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
509         (JSC::Heap::registerWeakGCMap):
510         (JSC::Heap::unregisterWeakGCMap):
511         (JSC::Heap::didAllocateBlock):
512         (JSC::Heap::didFreeBlock):
513         * heap/HeapInlines.h:
514         (JSC::Heap::shouldCollect): Deleted.
515         (JSC::Heap::isCurrentThreadBusy): Deleted.
516         (JSC::Heap::reportExtraMemoryVisited): Deleted.
517         (JSC::Heap::reportExternalMemoryVisited): Deleted.
518         (JSC::Heap::collectIfNecessaryOrDefer): Deleted.
519         (JSC::Heap::collectAccordingToDeferGCProbability): Deleted.
520         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded): Deleted.
521         (JSC::Heap::registerWeakGCMap): Deleted.
522         (JSC::Heap::unregisterWeakGCMap): Deleted.
523         (JSC::Heap::didAllocateBlock): Deleted.
524         (JSC::Heap::didFreeBlock): Deleted.
525
526 2016-10-21  Saam Barati  <sbarati@apple.com>
527
528         SpeculativeJIT::compileTryGetById needs to pass in NeedsToSpill along both the cell speculation and untyped speculation path
529         https://bugs.webkit.org/show_bug.cgi?id=163622
530
531         Reviewed by Yusuke Suzuki.
532
533         We were passing in DontSpill in the Untyped:child1() case, which caused us
534         not to spill the base register. This is obviously wrong because the
535         DFG's register allocator expected the base to still be in the register
536         that it allocated for it after the TryGetById node executed.
537
538         * dfg/DFGSpeculativeJIT.cpp:
539         (JSC::DFG::SpeculativeJIT::compileTryGetById):
540
541 2016-10-21  Keith Miller  <keith_miller@apple.com>
542
543         Expand Trunc in B3 to support Double to Float
544         https://bugs.webkit.org/show_bug.cgi?id=163809
545
546         Reviewed by Geoffrey Garen.
547
548         This feature is useful for passing floating point arguments via registers.
549         Currently, ArgumentRegValue returns a the full 64-bit register. Thus, we
550         need a way to indicate to B3 that we only want the low 32-bits.
551
552         * b3/B3Common.h:
553         (JSC::B3::isIdentical):
554         * b3/B3LowerToAir.cpp:
555         (JSC::B3::Air::LowerToAir::lower):
556         * b3/B3Opcode.h:
557         * b3/B3ReduceStrength.cpp:
558         * b3/B3Validate.cpp:
559         * b3/B3Value.cpp:
560         (JSC::B3::Value::typeFor):
561         * b3/testb3.cpp:
562         (JSC::B3::testAddFPRArgsFloat):
563         (JSC::B3::testCeilArgWithEffectfulDoubleConversion):
564         (JSC::B3::testFloorArgWithEffectfulDoubleConversion):
565         (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
566         (JSC::B3::run):
567
568 2016-10-21  Keith Miller  <keith_miller@apple.com>
569
570         Rename WASM to Wasm
571         https://bugs.webkit.org/show_bug.cgi?id=163796
572
573         Rubber stamped by Filip Pizlo.
574
575         * CMakeLists.txt:
576         * Configurations/ToolExecutable.xcconfig:
577         * JavaScriptCore.xcodeproj/project.pbxproj:
578         * llint/LLIntThunks.cpp:
579         (JSC::vmEntryToWasm):
580         (JSC::vmEntryToWASM): Deleted.
581         * llint/LLIntThunks.h:
582         * runtime/Executable.cpp:
583         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
584         * runtime/Executable.h:
585         * shell/CMakeLists.txt:
586         * testWASM.cpp:
587         (runWASMTests): Deleted.
588         * testWasm.cpp: Renamed from Source/JavaScriptCore/testWASM.cpp.
589         (CommandLine::CommandLine):
590         (printUsageStatement):
591         (CommandLine::parseArguments):
592         (runLEBTests):
593         (invoke):
594         (box):
595         (runWasmTests):
596         (main):
597         * wasm/JSWASMModule.cpp:
598         (JSC::JSWASMModule::JSWASMModule): Deleted.
599         (JSC::JSWASMModule::destroy): Deleted.
600         (JSC::JSWASMModule::visitChildren): Deleted.
601         * wasm/JSWASMModule.h:
602         (JSC::JSWASMModule::create): Deleted.
603         (JSC::JSWASMModule::createStructure): Deleted.
604         (JSC::JSWASMModule::i32Constants): Deleted.
605         (JSC::JSWASMModule::f32Constants): Deleted.
606         (JSC::JSWASMModule::f64Constants): Deleted.
607         (JSC::JSWASMModule::signatures): Deleted.
608         (JSC::JSWASMModule::functionImports): Deleted.
609         (JSC::JSWASMModule::functionImportSignatures): Deleted.
610         (JSC::JSWASMModule::globalVariableTypes): Deleted.
611         (JSC::JSWASMModule::functionDeclarations): Deleted.
612         (JSC::JSWASMModule::functionPointerTables): Deleted.
613         (JSC::JSWASMModule::arrayBuffer): Deleted.
614         (JSC::JSWASMModule::functions): Deleted.
615         (JSC::JSWASMModule::functionStartOffsetsInSource): Deleted.
616         (JSC::JSWASMModule::functionStackHeights): Deleted.
617         (JSC::JSWASMModule::globalVariables): Deleted.
618         (JSC::JSWASMModule::importedFunctions): Deleted.
619         * wasm/JSWasmModule.cpp: Renamed from Source/JavaScriptCore/wasm/JSWASMModule.cpp.
620         (JSC::JSWasmModule::JSWasmModule):
621         (JSC::JSWasmModule::destroy):
622         (JSC::JSWasmModule::visitChildren):
623         * wasm/JSWasmModule.h: Renamed from Source/JavaScriptCore/wasm/JSWASMModule.h.
624         (JSC::JSWasmModule::create):
625         (JSC::JSWasmModule::createStructure):
626         (JSC::JSWasmModule::i32Constants):
627         (JSC::JSWasmModule::f32Constants):
628         (JSC::JSWasmModule::f64Constants):
629         (JSC::JSWasmModule::signatures):
630         (JSC::JSWasmModule::functionImports):
631         (JSC::JSWasmModule::functionImportSignatures):
632         (JSC::JSWasmModule::globalVariableTypes):
633         (JSC::JSWasmModule::functionDeclarations):
634         (JSC::JSWasmModule::functionPointerTables):
635         (JSC::JSWasmModule::arrayBuffer):
636         (JSC::JSWasmModule::functions):
637         (JSC::JSWasmModule::functionStartOffsetsInSource):
638         (JSC::JSWasmModule::functionStackHeights):
639         (JSC::JSWasmModule::globalVariables):
640         (JSC::JSWasmModule::importedFunctions):
641         * wasm/WASMB3IRGenerator.cpp:
642         (JSC::WASM::createJSWrapper): Deleted.
643         (JSC::WASM::parseAndCompile): Deleted.
644         * wasm/WASMCallingConvention.cpp:
645         (JSC::WASM::jscCallingConvention): Deleted.
646         (JSC::WASM::wasmCallingConvention): Deleted.
647         * wasm/WASMCallingConvention.h:
648         (JSC::WASM::CallingConvention::CallingConvention): Deleted.
649         (JSC::WASM::CallingConvention::marshallArgumentImpl): Deleted.
650         (JSC::WASM::CallingConvention::marshallArgument): Deleted.
651         (JSC::WASM::CallingConvention::loadArguments): Deleted.
652         (JSC::WASM::CallingConvention::setupCall): Deleted.
653         (JSC::WASM::nextJSCOffset): Deleted.
654         * wasm/WASMFormat.h:
655         (JSC::WASM::toB3Type): Deleted.
656         (JSC::WASM::isValueType): Deleted.
657         * wasm/WASMFunctionParser.h:
658         (JSC::WASM::FunctionParser<Context>::FunctionParser): Deleted.
659         (JSC::WASM::FunctionParser<Context>::parse): Deleted.
660         (JSC::WASM::FunctionParser<Context>::parseBlock): Deleted.
661         (JSC::WASM::FunctionParser<Context>::parseExpression): Deleted.
662         (JSC::WASM::FunctionParser<Context>::parseUnreachableExpression): Deleted.
663         * wasm/WASMMemory.cpp:
664         (JSC::WASM::Memory::Memory): Deleted.
665         * wasm/WASMMemory.h:
666         (JSC::WASM::Memory::~Memory): Deleted.
667         (JSC::WASM::Memory::memory): Deleted.
668         (JSC::WASM::Memory::size): Deleted.
669         (JSC::WASM::Memory::pinnedRegisters): Deleted.
670         (JSC::WASM::Memory::mode): Deleted.
671         (JSC::WASM::Memory::grow): Deleted.
672         (JSC::WASM::Memory::offsetOfSize): Deleted.
673         * wasm/WASMModuleParser.cpp:
674         (JSC::WASM::ModuleParser::parse): Deleted.
675         (JSC::WASM::ModuleParser::parseMemory): Deleted.
676         (JSC::WASM::ModuleParser::parseFunctionTypes): Deleted.
677         (JSC::WASM::ModuleParser::parseFunctionSignatures): Deleted.
678         (JSC::WASM::ModuleParser::parseFunctionDefinitions): Deleted.
679         * wasm/WASMModuleParser.h:
680         (JSC::WASM::ModuleParser::ModuleParser): Deleted.
681         (JSC::WASM::ModuleParser::functionInformation): Deleted.
682         (JSC::WASM::ModuleParser::memory): Deleted.
683         * wasm/WASMOps.h:
684         (JSC::WASM::isValidOpType): Deleted.
685         (JSC::WASM::isControlOp): Deleted.
686         * wasm/WASMParser.h:
687         (JSC::WASM::Parser::parseVarUInt32): Deleted.
688         (JSC::WASM::Parser::parseVarUInt64): Deleted.
689         (JSC::WASM::Parser::Parser): Deleted.
690         (JSC::WASM::Parser::consumeCharacter): Deleted.
691         (JSC::WASM::Parser::consumeString): Deleted.
692         (JSC::WASM::Parser::parseUInt32): Deleted.
693         (JSC::WASM::Parser::parseUInt7): Deleted.
694         (JSC::WASM::Parser::parseVarUInt1): Deleted.
695         (JSC::WASM::Parser::parseValueType): Deleted.
696         * wasm/WASMPlan.cpp:
697         (JSC::WASM::Plan::Plan): Deleted.
698         * wasm/WASMSections.h:
699         (JSC::WASM::Sections::validateOrder): Deleted.
700         * wasm/WasmB3IRGenerator.cpp: Renamed from Source/JavaScriptCore/wasm/WASMB3IRGenerator.cpp.
701         (dumpProcedure):
702         (JSC::Wasm::createJSWrapper):
703         (JSC::Wasm::parseAndCompile):
704         * wasm/WasmB3IRGenerator.h: Renamed from Source/JavaScriptCore/wasm/WASMB3IRGenerator.h.
705         * wasm/WasmCallingConvention.cpp: Renamed from Source/JavaScriptCore/wasm/WASMCallingConvention.cpp.
706         (JSC::Wasm::jscCallingConvention):
707         (JSC::Wasm::wasmCallingConvention):
708         * wasm/WasmCallingConvention.h: Renamed from Source/JavaScriptCore/wasm/WASMCallingConvention.h.
709         (JSC::Wasm::CallingConvention::CallingConvention):
710         (JSC::Wasm::CallingConvention::marshallArgumentImpl):
711         (JSC::Wasm::CallingConvention::marshallArgument):
712         (JSC::Wasm::CallingConvention::loadArguments):
713         (JSC::Wasm::CallingConvention::setupCall):
714         (JSC::Wasm::nextJSCOffset):
715         * wasm/WasmFormat.h: Renamed from Source/JavaScriptCore/wasm/WASMFormat.h.
716         (JSC::Wasm::toB3Type):
717         (JSC::Wasm::isValueType):
718         * wasm/WasmFunctionParser.h: Renamed from Source/JavaScriptCore/wasm/WASMFunctionParser.h.
719         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
720         (JSC::Wasm::FunctionParser<Context>::parse):
721         (JSC::Wasm::FunctionParser<Context>::parseBlock):
722         (JSC::Wasm::FunctionParser<Context>::parseExpression):
723         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
724         * wasm/WasmMemory.cpp: Renamed from Source/JavaScriptCore/wasm/WASMMemory.cpp.
725         (JSC::Wasm::Memory::Memory):
726         * wasm/WasmMemory.h: Renamed from Source/JavaScriptCore/wasm/WASMMemory.h.
727         (JSC::Wasm::Memory::~Memory):
728         (JSC::Wasm::Memory::memory):
729         (JSC::Wasm::Memory::size):
730         (JSC::Wasm::Memory::pinnedRegisters):
731         (JSC::Wasm::Memory::mode):
732         (JSC::Wasm::Memory::grow):
733         (JSC::Wasm::Memory::offsetOfSize):
734         * wasm/WasmModuleParser.cpp: Renamed from Source/JavaScriptCore/wasm/WASMModuleParser.cpp.
735         (JSC::Wasm::ModuleParser::parse):
736         (JSC::Wasm::ModuleParser::parseMemory):
737         (JSC::Wasm::ModuleParser::parseFunctionTypes):
738         (JSC::Wasm::ModuleParser::parseFunctionSignatures):
739         (JSC::Wasm::ModuleParser::parseFunctionDefinitions):
740         * wasm/WasmModuleParser.h: Renamed from Source/JavaScriptCore/wasm/WASMModuleParser.h.
741         (JSC::Wasm::ModuleParser::ModuleParser):
742         (JSC::Wasm::ModuleParser::functionInformation):
743         (JSC::Wasm::ModuleParser::memory):
744         * wasm/WasmOps.h: Renamed from Source/JavaScriptCore/wasm/WASMOps.h.
745         (JSC::Wasm::isValidOpType):
746         (JSC::Wasm::isControlOp):
747         * wasm/WasmParser.h: Renamed from Source/JavaScriptCore/wasm/WASMParser.h.
748         (JSC::Wasm::Parser::parseVarUInt32):
749         (JSC::Wasm::Parser::parseVarUInt64):
750         (JSC::Wasm::Parser::Parser):
751         (JSC::Wasm::Parser::consumeCharacter):
752         (JSC::Wasm::Parser::consumeString):
753         (JSC::Wasm::Parser::parseUInt32):
754         (JSC::Wasm::Parser::parseUInt7):
755         (JSC::Wasm::Parser::parseVarUInt1):
756         (JSC::Wasm::Parser::parseValueType):
757         * wasm/WasmPlan.cpp: Renamed from Source/JavaScriptCore/wasm/WASMPlan.cpp.
758         (JSC::Wasm::Plan::Plan):
759         * wasm/WasmPlan.h: Renamed from Source/JavaScriptCore/wasm/WASMPlan.h.
760         * wasm/WasmSections.h: Renamed from Source/JavaScriptCore/wasm/WASMSections.h.
761         (JSC::Wasm::Sections::validateOrder):
762
763 2016-10-21  Caitlin Potter  <caitp@igalia.com>
764
765         [JSC] don't crash when arguments to `new Function()` produce unexpected AST
766         https://bugs.webkit.org/show_bug.cgi?id=163748
767
768         Reviewed by Mark Lam.
769
770         The ASSERT(statement); and ASSERT(funcDecl); lines are removed, replaced with blocks
771         to report a generic Parser error message. These lines are only possible to be reached
772         if the input string produced an unexpected AST, which previously could be used to crash
773         the process via ASSERT failure.
774
775         The node type assertions are left in the tree, as it should be impossible for a top-level
776         `{` to produce anything other than a Block node. If the node turns out not to be a Block,
777         it indicates that the (C++) caller of this function (E.g in FunctionConstructor.cpp), is
778         doing something incorrect. Similarly, it should be impossible for the `funcDecl` node to
779         be anything other than a function declaration given the conventions of the caller of this
780         function.
781
782         * runtime/CodeCache.cpp:
783         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
784
785 2016-10-20  Keith Miller  <keith_miller@apple.com>
786
787         Add support for WASM calls
788         https://bugs.webkit.org/show_bug.cgi?id=161727
789
790         Reviewed by Filip Pizlo and Michael Saboff.
791
792         Add support for WASM calls. Since most of the work for this was already done when we added
793         WASM Memory, this is mostly just cleanup work.  The main interesting part of this patch is
794         how we link calls to other WASM functions in the same module. Since a WASM callee may not
795         have been compiled by the time the current function has started compilation we don't know
796         what address we need to call to.  For each callsite in the compiling function, WASM
797         remembers the CodeLocationCall and the target function index. Once all WASM functions are
798         compiled, each callsite is linked to the appropriate entrypoint.
799
800         * testWASM.cpp:
801         (runWASMTests):
802         * wasm/WASMB3IRGenerator.cpp:
803         (JSC::WASM::createJSWrapper):
804         (JSC::WASM::parseAndCompile):
805         * wasm/WASMB3IRGenerator.h:
806         * wasm/WASMCallingConvention.cpp:
807         (JSC::WASM::jscCallingConvention):
808         (JSC::WASM::wasmCallingConvention):
809         * wasm/WASMCallingConvention.h:
810         (JSC::WASM::CallingConvention::CallingConvention):
811         (JSC::WASM::CallingConvention::marshallArgumentImpl):
812         (JSC::WASM::CallingConvention::marshallArgument):
813         (JSC::WASM::CallingConvention::loadArguments):
814         (JSC::WASM::CallingConvention::setupCall):
815         (JSC::WASM::CallingConvention::iterate): Deleted.
816         * wasm/WASMFormat.h:
817         * wasm/WASMFunctionParser.h:
818         (JSC::WASM::FunctionParser<Context>::FunctionParser):
819         (JSC::WASM::FunctionParser<Context>::parseBlock):
820         (JSC::WASM::FunctionParser<Context>::parseExpression):
821         * wasm/WASMModuleParser.cpp:
822         (JSC::WASM::ModuleParser::parse):
823         * wasm/WASMOps.h:
824         * wasm/WASMParser.h:
825         (JSC::WASM::Parser::parseVarUInt32):
826         (JSC::WASM::Parser::parseVarUInt64):
827         * wasm/WASMPlan.cpp:
828         (JSC::WASM::Plan::Plan):
829
830 2016-10-21  Wenson Hsieh  <wenson_hsieh@apple.com>
831
832         Implement InputEvent.getTargetRanges() for the input events spec
833         https://bugs.webkit.org/show_bug.cgi?id=162947
834         <rdar://problem/28853079>
835
836         Reviewed by Darin Adler.
837
838         Boilerplate change to add a runtime guard for InputEvents-related IDL interfaces. See WebCore ChangeLog entry
839         for more details.
840
841         * runtime/CommonIdentifiers.h:
842
843 2016-10-20  Zan Dobersek  <zdobersek@igalia.com>
844
845         Fix JSC cast-align compiler warnings on ARMv7
846         https://bugs.webkit.org/show_bug.cgi?id=163744
847
848         Reviewed by Mark Lam.
849
850         Use the reinterpret_cast_ptr workaround in a few places where
851         the cast alignment warning is being thrown by the GCC compiler
852         when compiling for the ARMv7 architecture.
853
854         * heap/Heap.cpp:
855         (JSC::Zombify::visit):
856         * heap/HeapCell.h:
857         (JSC::HeapCell::zap):
858         (JSC::HeapCell::isZapped):
859         * heap/MarkedBlock.cpp:
860         (JSC::MarkedBlock::Handle::specializedSweep):
861
862 2016-10-20  Filip Pizlo  <fpizlo@apple.com>
863
864         The tracking of the coarse-grain Heap state (allocating or not, collector or not, eden vs full) should respect the orthogonality between allocating and collecting
865         https://bugs.webkit.org/show_bug.cgi?id=163738
866
867         Reviewed by Geoffrey Garen.
868         
869         We need to know if we're currently in an allocation slow path, so that code can assert that
870         it's not being used from inside a destructor that runs during a sweep. We need to know if
871         we're currently collecting, because some code behaves differently during collection, and
872         other code wants to assert that it's not being used from inside a visitChildren method that
873         runs during marking. If we are collecting, we need to know if it's an eden collection or a
874         full collection. If we are requesting a collection, we need to know if we're requesting an
875         eden collection, a full collection, or any kind of collection.
876         
877         Prior to this change, you would reason about all of these things using the HeapOperation. It
878         had the following states: NoOperation, Allocation, FullCollection, EdenCollection, and
879         AnyCollection. NoOperation versus Allocation was primarily for asserting that sweep didn't
880         call arbitrary JS. FullCollection versus EdenCollection was about describing generations. We
881         would even use HeapOperation in places where we knew that it could only be either Full or
882         Eden, because we just needed a variable to tell us which generation we were talking about.
883         It was all very confusing.
884         
885         Where it completely breaks down is the fact that a concurrent GC has two logical threads, the
886         mutator and the collector, which can change state independently. The mutator can be
887         allocating. It can also be doing some work to help the GC. That's three states: running,
888         allocating, or helping GC. At the same time, the GC thread could either be running or not,
889         and if it's running, it could be a full collection or an eden collection. Because the mutator
890         and collector can run at the same time, it means that if we used one enum, we would need nine
891         states: every combination of mutator running, allocating, or helping GC, crossed with
892         collector not running, running eden, or running full. So, this change decouples mutator state
893         from collector state and uses two separate fields with two different types.
894         
895         Mutator state is described using MutatorState, which can be either MutatorState::Running,
896         MutatorState::Allocating, or MutatorState::HelpingGC.
897         
898         Collector state is described using Optional<CollectionScope>. CollectionScope describes how
899         big the scope of the collection is, and it can be either CollectionScope::Eden or
900         CollectionScope::Full. If the Optional is Nullopt, it means that we are not collecting. This
901         way, you can treat collectionScope as a boolean (an Optional is true iff it's engaged). You
902         can pass around just a CollectionScope if you know that you must be collecting and you just
903         want to know about the generation. Also, we can use Nullopt in methods that request
904         collection, which those methods take to mean that they can run any kind of collection (the
905         old AnyCollection).
906         
907         Another use of HeapOperation was to answer questions about whether the caller is running as
908         part of the GC or as part of the mutator. Optional<CollectionScope> does not answer this,
909         since code that runs in the mutator while the mutator is not HelpingGC at the same time as
910         the collector is running should run as if it was part of the mutator not as if it was part of
911         the GC. MutatorState is needed to answer this question, but it doesn't tell the whole story
912         since code that runs in the collector thread at the same time as the mutator is running
913         should run as if it was part of the GC not as if it was part of the mutator. So, we need to
914         know if we're on the collector thread or the mutator thread. We already have a WTF facility
915         for this, which answers if a thread is a GC thread. But we already use this to answer a
916         stronger question: are we part of the parallel GC helpers? Some functions in the GC, like
917         mark bit queries, will work fine in a concurrent collector thread so long as there is no
918         parallel marking. So, this change also changes WTF's mayBeGCThread to tell what kind of GC
919         thread we may be: either GCThreadType::Main or GCThreadType::Helper. The parallel GC safety
920         checks look for GCThreadType::Helper. The "should I run as mutator" query can now be answered
921         by checking with mayBeGCThread, which returns Optional<GCThreadType>; if engaged, then run as
922         GC, else run as GC if MutatorState is HelpingGC, else run as mutator.
923         
924         This doesn't change the way that the GC behaves, but it does change how the GC represents a
925         fundamental piece of state. So, it's a big change. It should be perf-neutral (still testing).
926
927         * API/JSBase.cpp:
928         (JSSynchronousEdenCollectForDebugging):
929         * CMakeLists.txt:
930         * JavaScriptCore.xcodeproj/project.pbxproj:
931         * bytecode/CodeBlock.cpp:
932         (JSC::CodeBlock::jettison):
933         * dfg/DFGWorklist.cpp:
934         * ftl/FTLCompile.cpp:
935         (JSC::FTL::compile):
936         * heap/AllocatingScope.h: Added.
937         (JSC::AllocatingScope::AllocatingScope):
938         (JSC::AllocatingScope::~AllocatingScope):
939         * heap/AllocationScope.h: Removed.
940         * heap/CodeBlockSet.cpp:
941         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
942         * heap/CodeBlockSet.h:
943         * heap/CollectionScope.cpp: Added.
944         (JSC::collectionScopeName):
945         (WTF::printInternal):
946         * heap/CollectionScope.h: Added.
947         * heap/EdenGCActivityCallback.cpp:
948         (JSC::EdenGCActivityCallback::doCollection):
949         * heap/FullGCActivityCallback.cpp:
950         (JSC::FullGCActivityCallback::doCollection):
951         * heap/GCTypeMap.h:
952         (JSC::GCTypeMap::operator[]):
953         * heap/Heap.cpp:
954         (JSC::Heap::Heap):
955         (JSC::Heap::lastChanceToFinalize):
956         (JSC::Heap::markRoots):
957         (JSC::Heap::beginMarking):
958         (JSC::Heap::visitSmallStrings):
959         (JSC::Heap::updateObjectCounts):
960         (JSC::Heap::deleteAllCodeBlocks):
961         (JSC::Heap::deleteUnmarkedCompiledCode):
962         (JSC::Heap::collectAllGarbage):
963         (JSC::Heap::collect):
964         (JSC::Heap::collectWithoutAnySweep):
965         (JSC::Heap::collectImpl):
966         (JSC::Heap::willStartCollection):
967         (JSC::Heap::flushWriteBarrierBuffer):
968         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
969         (JSC::Heap::notifyIncrementalSweeper):
970         (JSC::Heap::updateAllocationLimits):
971         (JSC::Heap::didFinishCollection):
972         (JSC::Heap::isValidAllocation):
973         (JSC::Heap::shouldDoFullCollection):
974         * heap/Heap.h:
975         (JSC::Heap::mutatorState):
976         (JSC::Heap::collectionScope):
977         (JSC::Heap::operationInProgress): Deleted.
978         * heap/HeapInlines.h:
979         (JSC::Heap::shouldCollect):
980         (JSC::Heap::isCurrentThreadBusy):
981         (JSC::Heap::isMarked):
982         (JSC::Heap::reportExtraMemoryVisited):
983         (JSC::Heap::reportExternalMemoryVisited):
984         (JSC::Heap::collectAccordingToDeferGCProbability):
985         (JSC::Heap::isBusy): Deleted.
986         (JSC::Heap::isCollecting): Deleted.
987         * heap/HeapObserver.h:
988         * heap/HeapOperation.cpp: Removed.
989         * heap/HeapOperation.h: Removed.
990         * heap/HeapVerifier.cpp:
991         (JSC::HeapVerifier::initializeGCCycle):
992         (JSC::HeapVerifier::reportObject):
993         (JSC::HeapVerifier::collectionTypeName): Deleted.
994         * heap/HeapVerifier.h:
995         (JSC::HeapVerifier::GCCycle::collectionTypeName): Deleted.
996         * heap/HelpingGCScope.h: Added.
997         (JSC::HelpingGCScope::HelpingGCScope):
998         (JSC::HelpingGCScope::~HelpingGCScope):
999         * heap/LargeAllocation.cpp:
1000         (JSC::LargeAllocation::flip):
1001         * heap/MarkedAllocator.cpp:
1002         (JSC::MarkedAllocator::doTestCollectionsIfNeeded):
1003         (JSC::MarkedAllocator::allocateSlowCaseImpl):
1004         * heap/MarkedBlock.h:
1005         * heap/MarkedSpace.cpp:
1006         (JSC::MarkedSpace::prepareForAllocation):
1007         (JSC::MarkedSpace::visitWeakSets):
1008         (JSC::MarkedSpace::reapWeakSets):
1009         (JSC::MarkedSpace::prepareForMarking):
1010         (JSC::MarkedSpace::beginMarking):
1011         (JSC::MarkedSpace::snapshotUnswept):
1012         * heap/MutatorState.cpp: Added.
1013         (WTF::printInternal):
1014         * heap/MutatorState.h: Added.
1015         * heap/SlotVisitor.cpp:
1016         (JSC::SlotVisitor::didStartMarking):
1017         * inspector/agents/InspectorHeapAgent.cpp:
1018         (Inspector::protocolTypeForHeapOperation):
1019         (Inspector::InspectorHeapAgent::didGarbageCollect):
1020         * inspector/agents/InspectorHeapAgent.h:
1021         * interpreter/Interpreter.cpp:
1022         (JSC::Interpreter::execute):
1023         (JSC::Interpreter::executeCall):
1024         (JSC::Interpreter::executeConstruct):
1025         (JSC::Interpreter::prepareForRepeatCall):
1026         * jsc.cpp:
1027         (functionFullGC):
1028         (functionEdenGC):
1029         * runtime/Completion.cpp:
1030         (JSC::evaluate):
1031         (JSC::loadAndEvaluateModule):
1032         (JSC::loadModule):
1033         (JSC::linkAndEvaluateModule):
1034         * runtime/JSLock.cpp:
1035         (JSC::JSLock::DropAllLocks::DropAllLocks):
1036         * runtime/SmallStrings.h:
1037         (JSC::SmallStrings::needsToBeVisited):
1038         * runtime/VM.h:
1039         (JSC::VM::isCollectorBusyOnCurrentThread):
1040         (JSC::VM::isCollectorBusy): Deleted.
1041         * tools/JSDollarVMPrototype.cpp:
1042         (JSC::JSDollarVMPrototype::edenGC):
1043
1044 2016-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1045
1046         [JSC] Drop isEnvironmentRecord type info flag and use JSType information instead
1047         https://bugs.webkit.org/show_bug.cgi?id=163761
1048
1049         Reviewed by Keith Miller.
1050
1051         When we call a function in the following form,
1052
1053             var charAt = String.prototype.charAt;
1054             charAt();  // |this| becomes the global object.
1055
1056         we should see |this| as undefined/null. In StringPrototype.cpp,
1057         we use IsEnvironmentRecord type info flag to check whther the
1058         given |this| is an environment record.
1059         However, type info flag is precious thing and only StringPrototype.cpp
1060         uses IsEnvironmentRecord. In addition to that, JSType should
1061         already knows whether the given object is an environment record.
1062         So IsEnvironmentRecord type info flag should be dropped.
1063
1064         This patch adds a new JSType, StrictEvalActivation. And we add a new
1065         method JSObject::isEnvironmentRecord(). This method uses JSType to
1066         return the result. And we drop IsEnvironmentRecord type info flag.
1067         This patch makes a room for putting one bit flag to the out of line
1068         type info flag. Previously, it is already exhausted.
1069
1070         * llint/LLIntData.cpp:
1071         (JSC::LLInt::Data::performAssertions):
1072         * llint/LowLevelInterpreter.asm:
1073         * runtime/JSObject.h:
1074         (JSC::JSObject::isStrictEvalActivation):
1075         (JSC::JSObject::isEnvironmentRecord):
1076         * runtime/JSSymbolTableObject.h:
1077         * runtime/JSType.h:
1078         * runtime/JSTypeInfo.h:
1079         (JSC::TypeInfo::newImpurePropertyFiresWatchpoints):
1080         (JSC::TypeInfo::isEnvironmentRecord): Deleted.
1081         * runtime/StrictEvalActivation.h:
1082         (JSC::StrictEvalActivation::createStructure):
1083         * runtime/StringPrototype.cpp:
1084         (JSC::checkObjectCoercible):
1085
1086 2016-10-20  JF Bastien  <jfbastien@apple.com>
1087
1088         WebAssembly API: implement exception constructors properly
1089
1090          - Rename WebAssemblyObject to JSWebAssembly for consistency.
1091          - WebAssembly object now has its own prototype: add WebAssemblyPrototype, and
1092            use it to register JSWebAssembly's function properties through auto-generated
1093            .lut.h, instead of manually.
1094          - The error constructors used to throw (e.g. `new WebAssembly.CompileError()`).
1095          - Register WebAssembly's constructors from the global object, and hold a
1096            reference to their structure and prototype so that invoking the constructor
1097            can use the structure directly from the global object.
1098          - Add a prototype base field to global object creation. Previous ones all had
1099            Object's prototype as their base, but WebAssembly's error constructors have
1100            Error as their base.
1101          - Test for the error object's correctness.
1102          - Add missing #if ENABLE(WEBASSEMBLY)
1103
1104         WebAssembly API: implement exception constructors properly
1105         https://bugs.webkit.org/show_bug.cgi?id=163699
1106
1107         Reviewed by Keith Miller.
1108
1109         * CMakeLists.txt: rename WebAssemblyObject -> JSWebAssembly; add a .lut.h file
1110         * DerivedSources.make: new .lut.h file
1111         * JavaScriptCore.xcodeproj/project.pbxproj: ditto
1112         * runtime/JSGlobalObject.cpp: new prototypeBase macro
1113         (JSC::JSGlobalObject::init): register WebAssembly constructors here
1114         (JSC::JSGlobalObject::visitChildren): use the macro to visit
1115         * runtime/JSGlobalObject.h: declare the WebAssembly constructor macro
1116         * wasm/JSWebAssembly.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1117         (JSC::JSWebAssembly::create):
1118         (JSC::JSWebAssembly::createStructure):
1119         (JSC::JSWebAssembly::finishCreation):
1120         (JSC::JSWebAssembly::JSWebAssembly):
1121         * wasm/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1122         * wasm/WebAssemblyObject.cpp: Removed.
1123         * wasm/js/JSWebAssemblyCompileError.cpp:
1124         * wasm/js/JSWebAssemblyCompileError.h:
1125         (JSC::JSWebAssemblyCompileError::create): string convenience
1126         * wasm/js/JSWebAssemblyInstance.cpp:
1127         * wasm/js/JSWebAssemblyInstance.h:
1128         * wasm/js/JSWebAssemblyMemory.cpp:
1129         * wasm/js/JSWebAssemblyMemory.h:
1130         * wasm/js/JSWebAssemblyModule.cpp:
1131         * wasm/js/JSWebAssemblyModule.h:
1132         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1133         * wasm/js/JSWebAssemblyRuntimeError.h:
1134         (JSC::JSWebAssemblyRuntimeError::create): string convenience
1135         * wasm/js/JSWebAssemblyTable.cpp:
1136         * wasm/js/JSWebAssemblyTable.h:
1137         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1138         (JSC::constructJSWebAssemblyCompileError):don't throw, create the object
1139         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):no need for the structure, it's on the global object
1140         * wasm/js/WebAssemblyCompileErrorConstructor.h:
1141         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
1142         * wasm/js/WebAssemblyCompileErrorPrototype.h:
1143         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1144         * wasm/js/WebAssemblyInstanceConstructor.h:
1145         * wasm/js/WebAssemblyInstancePrototype.cpp:
1146         * wasm/js/WebAssemblyInstancePrototype.h:
1147         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1148         * wasm/js/WebAssemblyMemoryConstructor.h:
1149         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1150         * wasm/js/WebAssemblyMemoryPrototype.h:
1151         * wasm/js/WebAssemblyModuleConstructor.cpp:
1152         * wasm/js/WebAssemblyModuleConstructor.h:
1153         * wasm/js/WebAssemblyModulePrototype.cpp:
1154         * wasm/js/WebAssemblyModulePrototype.h:
1155         * wasm/js/WebAssemblyPrototype.cpp: Copied from Source/JavaScriptCore/wasm/js/WebAssemblyCompileErrorPrototype.cpp.
1156         (JSC::webAssemblyFunctionValidate):
1157         (JSC::webAssemblyFunctionCompile):
1158         (JSC::WebAssemblyPrototype::create):
1159         (JSC::WebAssemblyPrototype::createStructure):
1160         (JSC::WebAssemblyPrototype::finishCreation):
1161         (JSC::WebAssemblyPrototype::WebAssemblyPrototype):
1162         * wasm/js/WebAssemblyPrototype.h: Copied from Source/JavaScriptCore/wasm/js/WebAssemblyMemoryPrototype.h.
1163         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1164         (JSC::constructJSWebAssemblyRuntimeError):don't throw, create the object
1165         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):no need for the structure, it's on the global object
1166         * wasm/js/WebAssemblyRuntimeErrorConstructor.h:
1167         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
1168         * wasm/js/WebAssemblyRuntimeErrorPrototype.h:
1169         * wasm/js/WebAssemblyTableConstructor.cpp:
1170         * wasm/js/WebAssemblyTableConstructor.h:
1171         * wasm/js/WebAssemblyTablePrototype.cpp:
1172         * wasm/js/WebAssemblyTablePrototype.h:
1173
1174 2016-10-19  Myles C. Maxfield  <mmaxfield@apple.com>
1175
1176         [macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
1177         https://bugs.webkit.org/show_bug.cgi?id=163374
1178
1179         Reviewed by Darin Adler.
1180
1181         * Configurations/FeatureDefines.xcconfig:
1182
1183 2016-10-20  Caitlin Potter  <caitp@igalia.com>
1184
1185         [JSC] disallow references to `await` in AsyncFunction formal parameters
1186         https://bugs.webkit.org/show_bug.cgi?id=163694
1187
1188         Reviewed by Saam Barati.
1189
1190         * parser/Parser.cpp:
1191         (JSC::Parser<LexerType>::parseAssignmentExpression):
1192
1193 2016-10-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1194
1195         [JSC] Move InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero to out of line type info flags
1196         https://bugs.webkit.org/show_bug.cgi?id=163716
1197
1198         Reviewed by Saam Barati.
1199
1200         We found that all the accesses to the InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero flag is
1201         done through the Structure. There is no user that accesses this flag in the cell inlined member. And JIT
1202         code does not access it directly. That means that we can move this flag from inlined flags to out of line
1203         flags. This patch moves it to the out of line flags. And make one bit empty in inlined flags. Later this
1204         new empty flag will be used by megamorphic DOMJIT implementation.
1205
1206         * runtime/JSTypeInfo.h:
1207         (JSC::TypeInfo::hasStaticPropertyTable):
1208         (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
1209
1210 2016-10-20  Keith Miller  <keith_miller@apple.com>
1211
1212         Invalid assertion in arguments elimination
1213         https://bugs.webkit.org/show_bug.cgi?id=163740
1214         <rdar://problem/27911462>
1215
1216         Reviewed by Michael Saboff.
1217
1218         The DFGFTL's arguments elimination phase incorrectly asserted that a GetFromArguments' first
1219         child would always be a CreateDirectArguments.  While we only create the
1220         op_get_from_arguments bytecode pointing to a create_direct_arguments, its possible for a
1221         number of reasons that a DFG GetFromArguments may not point to a CreateDirectArguments. For
1222         example, if we are OSR entering in some function with direct arguments the
1223         CreateDirectArguments node might become ExtractOSREntryLocals.
1224
1225         * dfg/DFGArgumentsEliminationPhase.cpp:
1226
1227 2016-10-20  Caitlin Potter  <caitp@igalia.com>
1228
1229         [JSC] throw TypeError when constructing dynamically created JSGeneratorFunction
1230         https://bugs.webkit.org/show_bug.cgi?id=163714
1231
1232         Reviewed by Mark Lam.
1233
1234         According to CreateDynamicFunction() (https://tc39.github.io/ecma262/#sec-createdynamicfunction),
1235         non-normal functions are not constructors. Previously, dynamically created functions would always
1236         be constructible, and so it was possible to evaluate `new  (function*() {}.constructor())`,
1237         and have it return an Iterator object.
1238
1239         This change selects a dynamically created function's ConstructAbility based on its parse mode instead.
1240
1241         * runtime/CodeCache.cpp:
1242         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1243
1244 2016-10-19  JF Bastien  <jfbastien@apple.com>
1245
1246         create_hash_table: allow empty tables
1247
1248         The Windows build was broken by because I added empty tables and Windows insists that empty tables are horrible. Put in dummy entries in that case.
1249
1250         create_hash_table: allow empty tables
1251         https://bugs.webkit.org/show_bug.cgi?id=163701
1252
1253         Reviewed by Keith Miller.
1254
1255         * create_hash_table:
1256
1257 2016-10-19  JF Bastien  <jfbastien@apple.com>
1258
1259         JavaScript WebAssembly API: baby steps
1260
1261          - Expand WebAssembly constructors into their own files. This requires a lot of
1262            boilerplate, as well as adding the .lut.h files. All of the
1263            JSWebAssembly*.{h,cpp}, as well as Constructor and Prototype files, are
1264            currently the same between the 4 specified WebAssembly constructors. It'll be
1265            easy to implement individual functions on constructed objects as per the
1266            spec, and have each of these files diverge. The error constructors are also
1267            similar, except that their instance derives from ErrorInstance.
1268          - Use constructor macro when initializing the global object.
1269          - Dramatically improve testing of the WebAssembly API by checking for
1270            properties specified in the spec [*].
1271          - Clean up assert.js' exception testing.
1272          - Fix a copy-paste bug in wasm.json: floating-point const return values were
1273            swapped.
1274
1275         [*] https://github.com/WebAssembly/design/blob/master/JS.md
1276
1277         Implement more of the JavaScript WebAssembly API
1278         https://bugs.webkit.org/show_bug.cgi?id=163571
1279
1280         Reviewed by Keith Miller.
1281
1282         * CMakeLists.txt: add .lut.h generation
1283         * DerivedSources.make: ditto
1284         * JavaScriptCore.xcodeproj/project.pbxproj: add .lut.h generation and all the new files
1285         * runtime/JSGlobalObject.cpp:
1286         (JSC::JSGlobalObject::init): use macro to list all constructors
1287         * wasm/WebAssemblyObject.cpp: unboilerplate, all constructors into their own files
1288         * wasm/WebAssemblyObject.h: ditto
1289         * wasm/js/JSWebAssemblyCompileError.cpp: Added.
1290         (JSC::JSWebAssemblyCompileError::create):
1291         (JSC::JSWebAssemblyCompileError::createStructure):
1292         (JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError):
1293         (JSC::JSWebAssemblyCompileError::finishCreation):
1294         (JSC::JSWebAssemblyCompileError::destroy):
1295         (JSC::JSWebAssemblyCompileError::visitChildren):
1296         * wasm/js/JSWebAssemblyCompileError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1297         * wasm/js/JSWebAssemblyInstance.cpp: Added.
1298         (JSC::JSWebAssemblyInstance::create):
1299         (JSC::JSWebAssemblyInstance::createStructure):
1300         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1301         (JSC::JSWebAssemblyInstance::finishCreation):
1302         (JSC::JSWebAssemblyInstance::destroy):
1303         (JSC::JSWebAssemblyInstance::visitChildren):
1304         * wasm/js/JSWebAssemblyInstance.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1305         * wasm/js/JSWebAssemblyMemory.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1306         (JSC::JSWebAssemblyMemory::create):
1307         (JSC::JSWebAssemblyMemory::createStructure):
1308         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
1309         (JSC::JSWebAssemblyMemory::finishCreation):
1310         (JSC::JSWebAssemblyMemory::destroy):
1311         (JSC::JSWebAssemblyMemory::visitChildren):
1312         * wasm/js/JSWebAssemblyMemory.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1313         * wasm/js/JSWebAssemblyModule.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1314         (JSC::JSWebAssemblyModule::create):
1315         (JSC::JSWebAssemblyModule::createStructure):
1316         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
1317         (JSC::JSWebAssemblyModule::finishCreation):
1318         (JSC::JSWebAssemblyModule::destroy):
1319         (JSC::JSWebAssemblyModule::visitChildren):
1320         * wasm/js/JSWebAssemblyModule.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1321         * wasm/js/JSWebAssemblyRuntimeError.cpp: Added.
1322         (JSC::JSWebAssemblyRuntimeError::create):
1323         (JSC::JSWebAssemblyRuntimeError::createStructure):
1324         (JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError):
1325         (JSC::JSWebAssemblyRuntimeError::finishCreation):
1326         (JSC::JSWebAssemblyRuntimeError::destroy):
1327         (JSC::JSWebAssemblyRuntimeError::visitChildren):
1328         * wasm/js/JSWebAssemblyRuntimeError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1329         * wasm/js/JSWebAssemblyTable.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1330         (JSC::JSWebAssemblyTable::create):
1331         (JSC::JSWebAssemblyTable::createStructure):
1332         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1333         (JSC::JSWebAssemblyTable::finishCreation):
1334         (JSC::JSWebAssemblyTable::destroy):
1335         (JSC::JSWebAssemblyTable::visitChildren):
1336         * wasm/js/JSWebAssemblyTable.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1337         * wasm/js/WebAssemblyCompileErrorConstructor.cpp: Added.
1338         (JSC::constructJSWebAssemblyCompileError):
1339         (JSC::callJSWebAssemblyCompileError):
1340         (JSC::WebAssemblyCompileErrorConstructor::create):
1341         (JSC::WebAssemblyCompileErrorConstructor::createStructure):
1342         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
1343         (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
1344         (JSC::WebAssemblyCompileErrorConstructor::getConstructData):
1345         (JSC::WebAssemblyCompileErrorConstructor::getCallData):
1346         (JSC::WebAssemblyCompileErrorConstructor::visitChildren):
1347         * wasm/js/WebAssemblyCompileErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1348         (JSC::WebAssemblyCompileErrorConstructor::CompileErrorStructure):
1349         * wasm/js/WebAssemblyCompileErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1350         (JSC::WebAssemblyCompileErrorPrototype::create):
1351         (JSC::WebAssemblyCompileErrorPrototype::createStructure):
1352         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
1353         (JSC::WebAssemblyCompileErrorPrototype::WebAssemblyCompileErrorPrototype):
1354         * wasm/js/WebAssemblyCompileErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1355         * wasm/js/WebAssemblyInstanceConstructor.cpp: Added.
1356         (JSC::constructJSWebAssemblyInstance):
1357         (JSC::callJSWebAssemblyInstance):
1358         (JSC::WebAssemblyInstanceConstructor::create):
1359         (JSC::WebAssemblyInstanceConstructor::createStructure):
1360         (JSC::WebAssemblyInstanceConstructor::finishCreation):
1361         (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
1362         (JSC::WebAssemblyInstanceConstructor::getConstructData):
1363         (JSC::WebAssemblyInstanceConstructor::getCallData):
1364         (JSC::WebAssemblyInstanceConstructor::visitChildren):
1365         * wasm/js/WebAssemblyInstanceConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1366         (JSC::WebAssemblyInstanceConstructor::InstanceStructure):
1367         * wasm/js/WebAssemblyInstancePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1368         (JSC::WebAssemblyInstancePrototype::create):
1369         (JSC::WebAssemblyInstancePrototype::createStructure):
1370         (JSC::WebAssemblyInstancePrototype::finishCreation):
1371         (JSC::WebAssemblyInstancePrototype::WebAssemblyInstancePrototype):
1372         * wasm/js/WebAssemblyInstancePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1373         * wasm/js/WebAssemblyMemoryConstructor.cpp: Added.
1374         (JSC::constructJSWebAssemblyMemory):
1375         (JSC::callJSWebAssemblyMemory):
1376         (JSC::WebAssemblyMemoryConstructor::create):
1377         (JSC::WebAssemblyMemoryConstructor::createStructure):
1378         (JSC::WebAssemblyMemoryConstructor::finishCreation):
1379         (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
1380         (JSC::WebAssemblyMemoryConstructor::getConstructData):
1381         (JSC::WebAssemblyMemoryConstructor::getCallData):
1382         (JSC::WebAssemblyMemoryConstructor::visitChildren):
1383         * wasm/js/WebAssemblyMemoryConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1384         (JSC::WebAssemblyMemoryConstructor::MemoryStructure):
1385         * wasm/js/WebAssemblyMemoryPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1386         (JSC::WebAssemblyMemoryPrototype::create):
1387         (JSC::WebAssemblyMemoryPrototype::createStructure):
1388         (JSC::WebAssemblyMemoryPrototype::finishCreation):
1389         (JSC::WebAssemblyMemoryPrototype::WebAssemblyMemoryPrototype):
1390         * wasm/js/WebAssemblyMemoryPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1391         * wasm/js/WebAssemblyModuleConstructor.cpp: Added.
1392         (JSC::constructJSWebAssemblyModule):
1393         (JSC::callJSWebAssemblyModule):
1394         (JSC::WebAssemblyModuleConstructor::create):
1395         (JSC::WebAssemblyModuleConstructor::createStructure):
1396         (JSC::WebAssemblyModuleConstructor::finishCreation):
1397         (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
1398         (JSC::WebAssemblyModuleConstructor::getConstructData):
1399         (JSC::WebAssemblyModuleConstructor::getCallData):
1400         (JSC::WebAssemblyModuleConstructor::visitChildren):
1401         * wasm/js/WebAssemblyModuleConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1402         (JSC::WebAssemblyModuleConstructor::ModuleStructure):
1403         * wasm/js/WebAssemblyModulePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1404         (JSC::WebAssemblyModulePrototype::create):
1405         (JSC::WebAssemblyModulePrototype::createStructure):
1406         (JSC::WebAssemblyModulePrototype::finishCreation):
1407         (JSC::WebAssemblyModulePrototype::WebAssemblyModulePrototype):
1408         * wasm/js/WebAssemblyModulePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1409         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: Added.
1410         (JSC::constructJSWebAssemblyRuntimeError):
1411         (JSC::callJSWebAssemblyRuntimeError):
1412         (JSC::WebAssemblyRuntimeErrorConstructor::create):
1413         (JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
1414         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
1415         (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
1416         (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData):
1417         (JSC::WebAssemblyRuntimeErrorConstructor::getCallData):
1418         (JSC::WebAssemblyRuntimeErrorConstructor::visitChildren):
1419         * wasm/js/WebAssemblyRuntimeErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1420         (JSC::WebAssemblyRuntimeErrorConstructor::RuntimeErrorStructure):
1421         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1422         (JSC::WebAssemblyRuntimeErrorPrototype::create):
1423         (JSC::WebAssemblyRuntimeErrorPrototype::createStructure):
1424         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
1425         (JSC::WebAssemblyRuntimeErrorPrototype::WebAssemblyRuntimeErrorPrototype):
1426         * wasm/js/WebAssemblyRuntimeErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1427         * wasm/js/WebAssemblyTableConstructor.cpp: Added.
1428         (JSC::constructJSWebAssemblyTable):
1429         (JSC::callJSWebAssemblyTable):
1430         (JSC::WebAssemblyTableConstructor::create):
1431         (JSC::WebAssemblyTableConstructor::createStructure):
1432         (JSC::WebAssemblyTableConstructor::finishCreation):
1433         (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
1434         (JSC::WebAssemblyTableConstructor::getConstructData):
1435         (JSC::WebAssemblyTableConstructor::getCallData):
1436         (JSC::WebAssemblyTableConstructor::visitChildren):
1437         * wasm/js/WebAssemblyTableConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1438         (JSC::WebAssemblyTableConstructor::TableStructure):
1439         * wasm/js/WebAssemblyTablePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1440         (JSC::WebAssemblyTablePrototype::create):
1441         (JSC::WebAssemblyTablePrototype::createStructure):
1442         (JSC::WebAssemblyTablePrototype::finishCreation):
1443         (JSC::WebAssemblyTablePrototype::WebAssemblyTablePrototype):
1444         * wasm/js/WebAssemblyTablePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
1445
1446 2016-10-19  Caitlin Potter  <caitp@igalia.com>
1447
1448         [JSC] forbid "use strict" directive in generator functions with non-simple parameters
1449         https://bugs.webkit.org/show_bug.cgi?id=163683
1450
1451         Reviewed by Geoffrey Garen.
1452
1453         Because generator functions and async functions both have an implicit
1454         inner function whose arguments are inherited from its parent, "use strict"
1455         directives within these functions did not yield a SyntaxError.
1456
1457         Now, the correct syntax error is reported, fixing several test262 failures
1458         for generators and async functions.
1459
1460         * parser/Parser.cpp:
1461         (JSC::Parser<LexerType>::parseFunctionInfo):
1462
1463 2016-10-19  Ryan Haddad  <ryanhaddad@apple.com>
1464
1465         Unreviewed, rolling out r207557.
1466
1467         This change caused animations/font-variations tests to time
1468         out on pre-Sierra Macs.
1469
1470         Reverted changeset:
1471
1472         "[macOS] [iOS] Disable variation fonts on macOS El Capitan and
1473         iOS 9"
1474         https://bugs.webkit.org/show_bug.cgi?id=163374
1475         http://trac.webkit.org/changeset/207557
1476
1477 2016-10-19  Filip Pizlo  <fpizlo@apple.com>
1478
1479         Baseline JIT should use AutomaticThread
1480         https://bugs.webkit.org/show_bug.cgi?id=163686
1481
1482         Reviewed by Geoffrey Garen.
1483         
1484         Change the JITWorklist to use AutomaticThread, so that the Baseline JIT's concurrent
1485         compiler thread shuts down automatically after inactivity.
1486         
1487         With this change, all of JSC's threads shut down automatically. If you run splay for a few
1488         seconds (which fires up all threads - compiler and GC) and then go to sleep for a second,
1489         you'll see that the only threads left are the main thread and the bmalloc thread.
1490
1491         * jit/JITWorklist.cpp:
1492         (JSC::JITWorklist::Thread::Thread):
1493         (JSC::JITWorklist::JITWorklist):
1494         (JSC::JITWorklist::completeAllForVM):
1495         (JSC::JITWorklist::poll):
1496         (JSC::JITWorklist::compileLater):
1497         (JSC::JITWorklist::compileNow):
1498         (JSC::JITWorklist::finalizePlans):
1499         (JSC::JITWorklist::runThread): Deleted.
1500         * jit/JITWorklist.h:
1501
1502 2016-10-19  Myles C. Maxfield  <mmaxfield@apple.com>
1503
1504         [macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
1505         https://bugs.webkit.org/show_bug.cgi?id=163374
1506
1507         Reviewed by Darin Adler.
1508
1509         * Configurations/FeatureDefines.xcconfig:
1510
1511 2016-10-19  Aaron Chu  <aaron_chu@apple.com>
1512
1513         Web Inspector: AXI: expose computed tree node and heading level
1514         https://bugs.webkit.org/show_bug.cgi?id=130825
1515         <rdar://problem/16442349>
1516
1517         Reviewed by Joseph Pecoraro.
1518
1519         Exposing two new accessibility properties: Heading Level and Hierarchical Level.
1520
1521         * inspector/protocol/DOM.json:
1522
1523 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
1524
1525         DFG worklist should use AutomaticThread
1526         https://bugs.webkit.org/show_bug.cgi?id=163615
1527
1528         Reviewed by Mark Lam.
1529         
1530         AutomaticThread is a new feature in WTF that allows you to easily create worker threads that
1531         shut down automatically. This changes DFG::Worklist to use AutomaticThread, so that its
1532         threads shut down automatically, too. This has the potential to save a lot of memory.
1533         
1534         This required some improvements to AutomaticThread: Worklist likes to be able to keep state
1535         around for the whole lifetime of a thread, and so it likes knowing when threads are born and
1536         when they die. I added virtual methods for that. Also, Worklist uses notifyOne() so I added
1537         that, too.
1538         
1539         This looks to be perf-neutral.
1540
1541         * dfg/DFGThreadData.cpp:
1542         (JSC::DFG::ThreadData::ThreadData):
1543         * dfg/DFGThreadData.h:
1544         * dfg/DFGWorklist.cpp:
1545         (JSC::DFG::Worklist::ThreadBody::ThreadBody):
1546         (JSC::DFG::Worklist::Worklist):
1547         (JSC::DFG::Worklist::~Worklist):
1548         (JSC::DFG::Worklist::finishCreation):
1549         (JSC::DFG::Worklist::isActiveForVM):
1550         (JSC::DFG::Worklist::enqueue):
1551         (JSC::DFG::Worklist::compilationState):
1552         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
1553         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
1554         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
1555         (JSC::DFG::Worklist::rememberCodeBlocks):
1556         (JSC::DFG::Worklist::visitWeakReferences):
1557         (JSC::DFG::Worklist::removeDeadPlans):
1558         (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
1559         (JSC::DFG::Worklist::queueLength):
1560         (JSC::DFG::Worklist::dump):
1561         (JSC::DFG::Worklist::runThread): Deleted.
1562         (JSC::DFG::Worklist::threadFunction): Deleted.
1563         * dfg/DFGWorklist.h:
1564
1565 2016-10-19  Dan Bernstein  <mitz@apple.com>
1566
1567         [Xcode] JavaScriptCore fails to build when CLANG_WARN_DOCUMENTATION_COMMENTS is enabled
1568         https://bugs.webkit.org/show_bug.cgi?id=163642
1569
1570         Reviewed by Darin Adler.
1571
1572         * API/JSClassRef.cpp: Removed a bad headerdoc comment inside an implementation file.
1573         * API/JSContext.h: Changed @methodgroup to @functiongroup, because the compiler requires the
1574           former to be followed by a method (and we have a property), but not the latter. Changed
1575           a couple of instances of “method” to “@method”. Removed empty @param entries.
1576         * API/JSContextRefInternal.h: Named a parameter referenced in a @param entry.
1577         * API/JSContextRefPrivate.h: Ditto.
1578         * API/JSManagedValue.h: Removed empty @param entries.
1579         * API/JSObjectRef.h: Corrected parameter name in @param entry.
1580         * API/JSTypedArray.h: Ditto.
1581         * API/JSValue.h: Removed empty @param entries, changed @methodgroup to @functiongroup, and
1582           changed @method to @property where appropriate. Removed empty @param entries.
1583         * API/JSValueRef.h: Named a parameter referenced in a @param entry.
1584         * API/JSWeakObjectMapRefPrivate.h: Ditto.
1585         * Configurations/Base.xcconfig: Enabled CLANG_WARN_DOCUMENTATION_COMMENTS. Made the compiler
1586           treat the icu headers as system headers, to stop it from emitting warnings about headers
1587           we don’t want to change.
1588         * Configurations/ToolExecutable.xcconfig: Made the compiler treat the icu headers as system
1589           headers.
1590
1591 2016-10-19  Csaba Osztrogonác  <ossy@webkit.org>
1592
1593         Unreviewed ARM buildfix after r207475.
1594
1595         * assembler/ARMAssembler.h:
1596         (JSC::ARMAssembler::relinkJumpToNop):
1597
1598 2016-10-18  Mark Lam  <mark.lam@apple.com>
1599
1600         Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
1601         https://bugs.webkit.org/show_bug.cgi?id=154377
1602         <rdar://problem/27330808>
1603
1604         Reviewed by Filip Pizlo and Saam Barati.
1605
1606         In a scenario where we cache the __proto__ accessors in global variables, and
1607         later explicitly invoke those accessors as functions, the spec for Function Calls
1608         (see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
1609         ref value is of type Reference, and base of ref is an Environment Record.  Then,
1610         it follows that the thisValue should be set to refEnv.WithBaseObject()
1611         (see section 4.b.ii of 12.3.4.1 at
1612         https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).
1613
1614         refEnv in this case is the environment record that the cached accessors were
1615         found in i.e. the global object.  The WithBaseObject() of the global object is
1616         undefined (see details about WithBaseObject at
1617         https://tc39.github.io/ecma262/#sec-environment-records).
1618
1619         Hence, the __proto__ accessors should see a thisValue of undefined, and throw
1620         TypeErrors.  See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
1621         https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
1622         https://tc39.github.io/ecma262/#sec-toobject, and
1623         https://tc39.github.io/ecma262/#sec-requireobjectcoercible.
1624
1625         In JSC's implementation, the callee needs to do a ToThis operation on the
1626         incoming "this" argument in order to get the specified thisValue.  The
1627         implementations of the __proto__ accessors were not doing this correctly.  This
1628         has now been fixed.
1629
1630         * runtime/JSGlobalObjectFunctions.cpp:
1631         (JSC::globalFuncProtoGetter):
1632         (JSC::globalFuncProtoSetter):
1633
1634 2016-10-18  Sam Weinig  <sam@webkit.org>
1635
1636         Replace std::experimental::variant with WTF::Variant (or similar)
1637         https://bugs.webkit.org/show_bug.cgi?id=163626
1638
1639         Reviewed by Chris Dumez.
1640
1641         Rename std::experimental::variant, Variant. Move helpers get/holds_alternative/etc.
1642         into the WTF namespace.
1643
1644         * domjit/DOMJITReg.h:
1645         (JSC::DOMJIT::Reg::gpr):
1646         (JSC::DOMJIT::Reg::fpr):
1647         (JSC::DOMJIT::Reg::jsValueRegs):
1648
1649 2016-10-18  Keith Miller  <keith_miller@apple.com>
1650
1651         GetByVal to GetById conversion in the DFG is incorrect for getters with control flow
1652         https://bugs.webkit.org/show_bug.cgi?id=163629
1653
1654         Reviewed by Yusuke Suzuki.
1655
1656         This patch fixes a bug in the DFG when attempt to convert a
1657         GetByVal into a GetById. While converting the GetByVal, during
1658         handleGetById in the Bytecode parser, we would mistakenly use the
1659         opcode length of op_get_by_id rather than op_get_by_val. This causes
1660         the new basic block we create to point to the wrong offset. In the
1661         added test this will cause us to infinite loop.
1662
1663         * dfg/DFGByteCodeParser.cpp:
1664         (JSC::DFG::ByteCodeParser::handleGetById):
1665         (JSC::DFG::ByteCodeParser::parseBlock):
1666
1667 2016-10-18  Dean Jackson  <dino@apple.com>
1668
1669         Remove CSS_SHAPES feature definition. This should always be on.
1670         https://bugs.webkit.org/show_bug.cgi?id=163628
1671         <rdar://problem/28834613>
1672         Reviewed by Tim Horton.
1673
1674         * Configurations/FeatureDefines.xcconfig:
1675
1676 2016-10-18  Michael Saboff  <msaboff@apple.com>
1677
1678         Add JSC option to show time spent in each optimization phase
1679         https://bugs.webkit.org/show_bug.cgi?id=163617
1680
1681         Reviewed by Saam Barati.
1682
1683         Added reportDFGPhaseTimes option.  This outputs one line per phase similar to
1684             Phase CPS rethreading took 0.2661 ms
1685
1686         One line is output for each phase run.
1687
1688         * dfg/DFGPhase.h:
1689         (JSC::DFG::runAndLog):
1690         * dfg/DFGPlan.cpp:
1691         (JSC::DFG::Plan::compileInThread):
1692         * runtime/Options.cpp:
1693         (JSC::recomputeDependentOptions):
1694         * runtime/Options.h:
1695
1696 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
1697
1698         WTF should make it easier to create threads that die automatically after inactivity
1699         https://bugs.webkit.org/show_bug.cgi?id=163576
1700
1701         Reviewed by Andreas Kling.
1702         
1703         Added a sleepSeconds() function, which made it easier for me to test this change.
1704         
1705         The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
1706         shut down automatically after 1 second of inactivity. Maybe this will save some memory.
1707
1708         * jsc.cpp:
1709         (GlobalObject::finishCreation):
1710         (functionSleepSeconds):
1711
1712 2016-10-18  Keith Miller  <keith_miller@apple.com>
1713
1714         Cleanup Wasm memory.
1715         https://bugs.webkit.org/show_bug.cgi?id=163601
1716
1717         Reviewed by Saam Barati.
1718
1719         There were a couple of issues with the original Wasm memory patch.
1720         This is a follow-up patch to fix those issues.
1721
1722         * wasm/WASMMemory.cpp:
1723         (JSC::WASM::Memory::Memory):
1724         * wasm/WASMMemory.h:
1725
1726 2016-10-15  Filip Pizlo  <fpizlo@apple.com>
1727
1728         DFG and FTL should be able to use DirectCall ICs when they proved the callee or its executable
1729         https://bugs.webkit.org/show_bug.cgi?id=163371
1730
1731         Reviewed by Geoffrey Garen and Saam Barati.
1732         
1733         This adds a new kind of call inline cache for when the DFG can prove what the callee
1734         executable is. In those cases, we can skip some of the things that the traditional call IC
1735         would do:
1736         
1737         - No need to check who the callee is.
1738         - No need to do arity checks.
1739         
1740         This case isn't as simple as just emitting a call instruction since the callee may not be
1741         compiled at the time that the caller is compiled. So, we need lazy resolution. Also, the
1742         callee may be jettisoned independently of the caller, so we need to be able to revert the
1743         call to an unlinked state. This means that we need almost all of the things that
1744         CallLinkInfo has. CallLinkInfo already knows about different kinds of calls. This patch
1745         teaches it about new "Direct" call types.
1746         
1747         The direct non-tail call IC looks like this:
1748         
1749                 set up arguments
1750             FastPath:
1751                 call _SlowPath
1752                 lea -FrameSize(%rbp), %rsp
1753             
1754             SlowPath:
1755                 pop
1756                 call operationLinkDirectCall
1757                 check exception
1758                 jmp FastPath
1759         
1760         The job of operationLinkDirectCall is to link the fast path's call entrypoint of the callee.
1761         This means that in steady state, a call is just that: a call. There are no extra branches or
1762         checks.
1763         
1764         The direct tail call IC is a bit more complicated because the act of setting up arguments
1765         destroys our frame, which would prevent us from being able to throw an exception if we
1766         failed to compile the callee. So, direct tail call ICs look like this:
1767         
1768                 jmp _SlowPath
1769             FastPath:
1770                 set up arguments
1771                 jmp 0 // patch to jump to callee
1772             
1773             SlowPath:
1774                 silent spill
1775                 call operationLinkDirectCall
1776                 silent fill
1777                 check exception
1778                 jmp FastPath
1779         
1780         The jmp to the slow path is patched to be a fall-through jmp when we link the call.
1781         
1782         Direct calls mean less code at call sites, fewer checks on the steady state call fast path,
1783         and no need for arity fixup. This looks like a slight speed-up (~0.8%) on both Octane and
1784         AsmBench.
1785
1786         * assembler/ARM64Assembler.h:
1787         (JSC::ARM64Assembler::relinkJumpToNop):
1788         * assembler/ARMv7Assembler.h:
1789         (JSC::ARMv7Assembler::relinkJumpToNop):
1790         (JSC::ARMv7Assembler::relinkJump): Deleted.
1791         * assembler/AbstractMacroAssembler.h:
1792         (JSC::AbstractMacroAssembler::repatchJumpToNop):
1793         (JSC::AbstractMacroAssembler::repatchJump): Deleted.
1794         * assembler/X86Assembler.h:
1795         (JSC::X86Assembler::relinkJumpToNop):
1796         * bytecode/CallLinkInfo.cpp:
1797         (JSC::CallLinkInfo::CallLinkInfo):
1798         (JSC::CallLinkInfo::callReturnLocation):
1799         (JSC::CallLinkInfo::patchableJump):
1800         (JSC::CallLinkInfo::hotPathBegin):
1801         (JSC::CallLinkInfo::slowPathStart):
1802         (JSC::CallLinkInfo::setCallee):
1803         (JSC::CallLinkInfo::clearCallee):
1804         (JSC::CallLinkInfo::callee):
1805         (JSC::CallLinkInfo::setCodeBlock):
1806         (JSC::CallLinkInfo::clearCodeBlock):
1807         (JSC::CallLinkInfo::codeBlock):
1808         (JSC::CallLinkInfo::setLastSeenCallee):
1809         (JSC::CallLinkInfo::clearLastSeenCallee):
1810         (JSC::CallLinkInfo::lastSeenCallee):
1811         (JSC::CallLinkInfo::haveLastSeenCallee):
1812         (JSC::CallLinkInfo::setExecutableDuringCompilation):
1813         (JSC::CallLinkInfo::executable):
1814         (JSC::CallLinkInfo::setMaxNumArguments):
1815         (JSC::CallLinkInfo::visitWeak):
1816         * bytecode/CallLinkInfo.h:
1817         (JSC::CallLinkInfo::specializationKindFor):
1818         (JSC::CallLinkInfo::callModeFor):
1819         (JSC::CallLinkInfo::isDirect):
1820         (JSC::CallLinkInfo::nearCallMode):
1821         (JSC::CallLinkInfo::isLinked):
1822         (JSC::CallLinkInfo::setCallLocations):
1823         (JSC::CallLinkInfo::addressOfMaxNumArguments):
1824         (JSC::CallLinkInfo::maxNumArguments):
1825         (JSC::CallLinkInfo::isTailCall): Deleted.
1826         (JSC::CallLinkInfo::setUpCallFromFTL): Deleted.
1827         (JSC::CallLinkInfo::callReturnLocation): Deleted.
1828         (JSC::CallLinkInfo::hotPathBegin): Deleted.
1829         (JSC::CallLinkInfo::callee): Deleted.
1830         (JSC::CallLinkInfo::setLastSeenCallee): Deleted.
1831         (JSC::CallLinkInfo::clearLastSeenCallee): Deleted.
1832         (JSC::CallLinkInfo::lastSeenCallee): Deleted.
1833         (JSC::CallLinkInfo::haveLastSeenCallee): Deleted.
1834         * bytecode/CallLinkStatus.cpp:
1835         (JSC::CallLinkStatus::computeDFGStatuses):
1836         * bytecode/PolymorphicAccess.cpp:
1837         (JSC::AccessCase::generateImpl):
1838         * bytecode/UnlinkedFunctionExecutable.h:
1839         * bytecode/ValueRecovery.h:
1840         (JSC::ValueRecovery::forEachReg):
1841         * dfg/DFGAbstractInterpreterInlines.h:
1842         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1843         * dfg/DFGBasicBlock.h:
1844         (JSC::DFG::BasicBlock::findTerminal):
1845         * dfg/DFGByteCodeParser.cpp:
1846         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
1847         (JSC::DFG::ByteCodeParser::handleCall):
1848         * dfg/DFGClobberize.h:
1849         (JSC::DFG::clobberize):
1850         * dfg/DFGDoesGC.cpp:
1851         (JSC::DFG::doesGC):
1852         * dfg/DFGFixupPhase.cpp:
1853         (JSC::DFG::FixupPhase::fixupNode):
1854         * dfg/DFGGraph.cpp:
1855         (JSC::DFG::Graph::parameterSlotsForArgCount):
1856         * dfg/DFGGraph.h:
1857         * dfg/DFGInPlaceAbstractState.cpp:
1858         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
1859         * dfg/DFGJITCompiler.cpp:
1860         (JSC::DFG::JITCompiler::link):
1861         * dfg/DFGJITCompiler.h:
1862         (JSC::DFG::JITCompiler::addJSDirectCall):
1863         (JSC::DFG::JITCompiler::addJSDirectTailCall):
1864         (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
1865         (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
1866         (JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord):
1867         (JSC::DFG::JITCompiler::currentJSCallIndex): Deleted.
1868         * dfg/DFGNode.cpp:
1869         (JSC::DFG::Node::convertToDirectCall):
1870         * dfg/DFGNode.h:
1871         (JSC::DFG::Node::isTerminal):
1872         (JSC::DFG::Node::hasHeapPrediction):
1873         (JSC::DFG::Node::hasCellOperand):
1874         * dfg/DFGNodeType.h:
1875         * dfg/DFGPredictionPropagationPhase.cpp:
1876         * dfg/DFGSafeToExecute.h:
1877         (JSC::DFG::safeToExecute):
1878         * dfg/DFGSpeculativeJIT.h:
1879         (JSC::DFG::SpeculativeJIT::callOperation):
1880         * dfg/DFGSpeculativeJIT64.cpp:
1881         (JSC::DFG::SpeculativeJIT::emitCall):
1882         (JSC::DFG::SpeculativeJIT::compile):
1883         * dfg/DFGStrengthReductionPhase.cpp:
1884         (JSC::DFG::StrengthReductionPhase::handleNode):
1885         * ftl/FTLCapabilities.cpp:
1886         (JSC::FTL::canCompile):
1887         * ftl/FTLLowerDFGToB3.cpp:
1888         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1889         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
1890         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
1891         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
1892         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
1893         * interpreter/Interpreter.cpp:
1894         (JSC::Interpreter::execute):
1895         (JSC::Interpreter::executeCall):
1896         (JSC::Interpreter::executeConstruct):
1897         (JSC::Interpreter::prepareForRepeatCall):
1898         * jit/JIT.cpp:
1899         (JSC::JIT::link):
1900         * jit/JITCall.cpp:
1901         (JSC::JIT::compileSetupVarargsFrame):
1902         * jit/JITCall32_64.cpp:
1903         (JSC::JIT::compileSetupVarargsFrame):
1904         * jit/JITOperations.cpp:
1905         * jit/JITOperations.h:
1906         * jit/Repatch.cpp:
1907         (JSC::linkDirectFor):
1908         (JSC::revertCall):
1909         * jit/Repatch.h:
1910         * llint/LLIntSlowPaths.cpp:
1911         (JSC::LLInt::setUpCall):
1912         * runtime/Executable.cpp:
1913         (JSC::ScriptExecutable::prepareForExecutionImpl):
1914         * runtime/Executable.h:
1915         (JSC::ScriptExecutable::prepareForExecution):
1916         * runtime/Options.h:
1917
1918 2016-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1919
1920         [DOMJIT] Not emit exception case if it is not necessary
1921         https://bugs.webkit.org/show_bug.cgi?id=163589
1922
1923         Reviewed by Sam Weinig.
1924
1925         We should not emit exception case if we do not use the slow path calls.
1926         For example, nodeType accessor does not use the slow path calls.
1927
1928         * bytecode/PolymorphicAccess.cpp:
1929         (JSC::AccessCase::emitDOMJITGetter):
1930
1931 2016-10-18  Caitlin Potter  <caitp@igalia.com>
1932
1933         [JSC] ES6 Method functions should not have prototype
1934         https://bugs.webkit.org/show_bug.cgi?id=162530
1935
1936         Reviewed by Saam Barati.
1937
1938         ECMA-262 only adds "prototype" properties to specific syntactic function forms.
1939         Specific items which do not contain "prototype" include (most) built-in functions (such as Math.pow),
1940         MethodDefinitions which are not either class "constructor" methods or GeneratorMethods, AsyncFunctions,
1941         and ArrowFunctions.
1942         
1943         For details, see the following spec text, and the difference between GeneratorMethod evaluation and
1944         the evaluation of other MethodDefinition forms.
1945         
1946         - https://tc39.github.io/ecma262/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation
1947         - https://tc39.github.io/ecma262/#sec-arrow-function-definitions-runtime-semantics-evaluation
1948         - https://tc39.github.io/ecmascript-asyncawait/#async-function-instances
1949         - https://tc39.github.io/ecma262/#sec-generator-function-definitions-runtime-semantics-propertydefinitionevaluation
1950         
1951
1952         * runtime/Executable.h:
1953         * runtime/JSFunction.cpp:
1954         (JSC::JSFunction::callerGetter):
1955         (JSC::JSFunction::getOwnPropertySlot):
1956         (JSC::JSFunction::deleteProperty):
1957
1958         * bytecompiler/BytecodeGenerator.h:
1959         (JSC::BytecodeGenerator::makeFunction):
1960         * runtime/Executable.h:
1961         * runtime/JSFunction.cpp:
1962         (JSC::JSFunction::getOwnPropertySlot):
1963         (JSC::JSFunction::getOwnNonIndexPropertyNames):
1964         (JSC::JSFunction::put):
1965         (JSC::JSFunction::deleteProperty):
1966         (JSC::JSFunction::defineOwnProperty):
1967         * runtime/JSGlobalObjectFunctions.cpp:
1968         (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
1969
1970 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1971
1972         [DOMJIT] Use NativeCallFrameTracer for operations used for DOMJIT slow calls
1973         https://bugs.webkit.org/show_bug.cgi?id=163586
1974
1975         Reviewed by Saam Barati.
1976
1977         C functions called from the DOMJIT slow path calls should use NativeCallFrameTracer.
1978         This fixes the debug assertion caused in r207427.
1979
1980         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
1981         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
1982         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
1983         * bytecode/DOMJITAccessCasePatchpointParams.h:
1984         * bytecode/PolymorphicAccess.cpp:
1985         (JSC::AccessCase::emitDOMJITGetter):
1986         * jsc.cpp:
1987         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall):
1988         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
1989
1990 2016-10-17  Keith Miller  <keith_miller@apple.com>
1991
1992         Add support for WASM Memory.
1993         https://bugs.webkit.org/show_bug.cgi?id=161710
1994
1995         Reviewed by Geoffrey Garen.
1996
1997         This patch add initial support for WASM memory operations. First,
1998         it adds the concept of a WASM Module memory management object.
1999         This object currently mmaps a 32-bit address space for WASM use,
2000         although it marks all the memory outside the current breakpoint as
2001         PROT_NONE. For now, we do a range check on each store and load. In
2002         the future, we should change this to be an signal handler that
2003         checks what module the program trapped in.
2004
2005         Additionally, this patch changes the way that our temporary tests
2006         call into WASM code. There is now a true "thunk" that relocates
2007         arguments and calls into WASM. This thunk does not tail call
2008         because we use pinned values to memory base-pointer and
2009         size. We use the new B3 pinned register api to pin the values.
2010
2011         * CMakeLists.txt:
2012         * Configurations/ToolExecutable.xcconfig:
2013         * JavaScriptCore.xcodeproj/project.pbxproj:
2014         * testWASM.cpp:
2015         (runWASMTests):
2016         (main):
2017         * wasm/WASMB3IRGenerator.cpp:
2018         (JSC::WASM::createJSWrapper):
2019         (JSC::WASM::parseAndCompile):
2020         * wasm/WASMB3IRGenerator.h:
2021         * wasm/WASMCallingConvention.h:
2022         (JSC::WASM::CallingConvention::iterate):
2023         (JSC::WASM::CallingConvention::setupCall):
2024         (JSC::WASM::nextJSCOffset):
2025         * wasm/WASMFormat.h:
2026         * wasm/WASMFunctionParser.h:
2027         (JSC::WASM::FunctionParser<Context>::parseExpression):
2028         * wasm/WASMMemory.cpp: Copied from Source/JavaScriptCore/wasm/WASMPlan.cpp.
2029         (JSC::WASM::Memory::Memory):
2030         * wasm/WASMMemory.h: Copied from Source/JavaScriptCore/wasm/WASMModuleParser.h.
2031         (JSC::WASM::Memory::~Memory):
2032         (JSC::WASM::Memory::memory):
2033         (JSC::WASM::Memory::size):
2034         (JSC::WASM::Memory::pinnedRegisters):
2035         (JSC::WASM::Memory::mode):
2036         (JSC::WASM::Memory::growMemory):
2037         (JSC::WASM::Memory::offsetOfSize):
2038         * wasm/WASMModuleParser.cpp:
2039         (JSC::WASM::ModuleParser::parse):
2040         (JSC::WASM::ModuleParser::parseMemory):
2041         * wasm/WASMModuleParser.h:
2042         (JSC::WASM::ModuleParser::functionInformation):
2043         (JSC::WASM::ModuleParser::memory):
2044         * wasm/WASMOps.h:
2045         * wasm/WASMPlan.cpp:
2046         (JSC::WASM::Plan::Plan):
2047         * wasm/WASMPlan.h:
2048         * wasm/WASMSections.h:
2049
2050 2016-10-17  Joseph Pecoraro  <pecoraro@apple.com>
2051
2052         Web Inspector: Add toggles for debugger pauses at console.assert failures
2053         https://bugs.webkit.org/show_bug.cgi?id=139542
2054         <rdar://problem/19281600>
2055
2056         Reviewed by Timothy Hatcher.
2057
2058         * inspector/agents/InspectorDebuggerAgent.h:
2059         * inspector/agents/InspectorDebuggerAgent.cpp:
2060         (Inspector::InspectorDebuggerAgent::disable):
2061         (Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
2062         Toggle pause on assertions state. Default is disabled,
2063         and disable it when frontends disconnect.
2064
2065         (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
2066         Instead of using the PauseOnAllExceptions state, use this
2067         new state specific to assertions.
2068
2069         * inspector/protocol/Debugger.json:
2070         New protocol method to toggle pausing on assertions.
2071
2072 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2073
2074         [DOMJIT][JSC] Add Option::useDOMJIT
2075         https://bugs.webkit.org/show_bug.cgi?id=163457
2076
2077         Reviewed by Saam Barati.
2078
2079         Add an option to switch the DOMJIT optimization.
2080
2081         * bytecode/PolymorphicAccess.cpp:
2082         (JSC::AccessCase::generateImpl):
2083         * dfg/DFGByteCodeParser.cpp:
2084         (JSC::DFG::ByteCodeParser::handleGetById):
2085         * runtime/Options.cpp:
2086         (JSC::recomputeDependentOptions):
2087         * runtime/Options.h:
2088
2089 2016-10-17  Filip Pizlo  <fpizlo@apple.com>
2090
2091         Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored
2092         https://bugs.webkit.org/show_bug.cgi?id=163548
2093         <rdar://problem/28804381>
2094
2095         Reviewed by Geoffrey Garen.
2096         
2097         Before r207408, IRC had a mode where it would silently assign the first assignable register (so
2098         %rax, %xmm0, etc) to any tmp that was not colorable due to a pathological interference fencepost.
2099         We reason about interference at instruction boundaries. This means that if you have, for example,
2100         an instruction that clobbers all registers late followed by an instruction that has an early def
2101         in the same register file, then the early def will not be colorable because it interferes with
2102         all registers. This already happens in our tests, but IRC silently returns the first assignable
2103         register to such tmps. For some reason the resulting code works OK - probably because this tends
2104         to only be hit by fuzzing, which may not then stress that code enough to shake out the register
2105         corruption. Also, this can only happen for floating point registers, so it's hard to get an
2106         exciting crash. The worst case is that your numbers get all messed up.
2107         
2108         This change fixes the issue:
2109         
2110         - IRC will now crash if it can't color a tmp.
2111         
2112         - IRC doesn't crash on our tests anymore because I added a padInterference() utility that works
2113           around the interference problem by inserting Nops to pad between those instructions where
2114           conflating their early and late actions into one interference fencepost could create an
2115           uncolorable graph.
2116         
2117         See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for a detailed discussion of how the
2118         problem can arise.
2119         
2120         This problem almost made me want to abandon our use of interference at instruction boundaries,
2121         and introduce something more comprehensive, like interference at various stages of an
2122         instruction's execution. The reason why I didn't do this is that this problem only arises in well
2123         confined corner cases: you need an instruction that does a late use or def followed by an
2124         instruction that does an early def. Register clobbers count as defs for this equation.
2125         Fortunately, early defs are rare, and even when they do happen, you still need the previous
2126         instruction to have a late something. Late uses are rare and many instructions don't have defs at
2127         all, which means that it's actually pretty common for an instruction to not have anything late.
2128         This means that the padInterference() strategy is ideal: our algorithms stay simple because they
2129         only have to worry about interference at boundaries, and we rarely insert any Nops in
2130         padInterference() so the IR stays nice and compact. Those Nops get removed by any phase that does
2131         DCE, which includes eliminateDeadCode(), allocateStack(), and reportUsedRegisters(). In practice
2132         allocateStack() kills them.
2133         
2134         This also finally refactors our passing of RegisterSet to pass it by value, since it's small
2135         enough that we're not gaining anything by using references. On x86, RegisterSet ought to be
2136         smaller than a pointer.
2137
2138         * CMakeLists.txt:
2139         * JavaScriptCore.xcodeproj/project.pbxproj:
2140         * b3/B3StackmapSpecial.cpp:
2141         (JSC::B3::StackmapSpecial::extraClobberedRegs):
2142         (JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
2143         * b3/B3StackmapSpecial.h:
2144         * b3/air/AirCCallSpecial.cpp:
2145         (JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
2146         (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
2147         * b3/air/AirCCallSpecial.h:
2148         * b3/air/AirInst.h:
2149         * b3/air/AirInstInlines.h:
2150         (JSC::B3::Air::Inst::extraClobberedRegs):
2151         (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
2152         * b3/air/AirIteratedRegisterCoalescing.cpp:
2153         (JSC::B3::Air::iteratedRegisterCoalescing):
2154         * b3/air/AirPadInterference.cpp: Added.
2155         (JSC::B3::Air::padInterference):
2156         * b3/air/AirPadInterference.h: Added.
2157         * b3/air/AirSpecial.h:
2158         * b3/air/AirSpillEverything.cpp:
2159         (JSC::B3::Air::spillEverything):
2160         * jit/RegisterSet.h:
2161         (JSC::RegisterSet::isEmpty):
2162
2163 2016-10-17  JF Bastien  <jfbastien@apple.com>
2164
2165         WebAssembly JS API: implement basic stub
2166
2167         Implement the global WebAssembly JavaScript object, and its constructor +
2168         function properties as described in:
2169           https://github.com/WebAssembly/design/blob/master/JS.md
2170
2171         These don't do anything at the moment, the parent bug will take care of adding
2172         more functionality and associated tests.
2173
2174         WebAssembly JS API: implement basic stub
2175         https://bugs.webkit.org/show_bug.cgi?id=163404
2176
2177         Reviewed by Keith Miller.
2178
2179         * CMakeLists.txt:
2180         * JavaScriptCore.xcodeproj/project.pbxproj:
2181         * builtins/BuiltinNames.h: register the new WebAssembly object's name and its constructor properties
2182         * jsc.cpp: remove useless include
2183         * runtime/JSGlobalObject.cpp:
2184         (JSC::JSGlobalObject::init): add the WebAssembly global object and its constructor properties, but only if the JSC option enables it
2185         * runtime/Options.h: add the useWebAssembly (alias: enableWebAssembly) option, defaulting to false
2186         * wasm/WebAssemblyObject.cpp: Added.
2187         (JSC::WebAssemblyObject::create): boilerplate
2188         (JSC::WebAssemblyObject::createStructure): boilerplate
2189         (JSC::WebAssemblyObject::finishCreation): boilerplate
2190         (JSC::WebAssemblyObject::WebAssemblyObject): boilerplate
2191         (JSC::wasmObjectFuncvalidate): auto-throws for now
2192         (JSC::wasmObjectFunccompile): auto-throws for now
2193         * wasm/WebAssemblyObject.h: Added.
2194
2195 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2196
2197         Unreviewed, build fix after r207428
2198         https://bugs.webkit.org/show_bug.cgi?id=163223
2199
2200         Previous build fix r207428 broke all the builds.
2201
2202         * bytecode/PolymorphicAccess.h:
2203
2204 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2205
2206         Unreviewed, build fix for GTK and Windows
2207         https://bugs.webkit.org/show_bug.cgi?id=163223
2208
2209         Attempt to fix build failures in GTK port and Windows port.
2210
2211         * bytecode/PolymorphicAccess.cpp:
2212         * bytecode/PolymorphicAccess.h:
2213         (JSC::AccessGenerationState::SpillState::SpillState):
2214
2215 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2216
2217         [DOMJIT] Use DOMJIT::Patchpoint in IC
2218         https://bugs.webkit.org/show_bug.cgi?id=163223
2219
2220         Reviewed by Saam Barati.
2221
2222         This patch uses DOMJIT::Patchpoint to inline DOM accesses even in IC!
2223         It is useful for Baseline JIT cases and GetById cases in DFG and FTL.
2224         In AccessCase, we construct the environment that allows DOMJIT::Patchpoint
2225         to emit code and make DOMJIT accessors inlined in IC.
2226
2227         To allow DOMJIT::Patchpoint to emit code, we create a mechanism to emit calls
2228         required in DOMJIT::Patchpoint. This system is useful when we create the super-
2229         polymorphic support[1] later. And inlining mechanism is useful even after
2230         introducing super-polymorphic support since it can work even after we fire the
2231         watchpoint for super-polymorphic handling.
2232
2233         This patch improves Dromaeo dom-traverse 8% (263.95 runs/s v.s. 244.07 runs/s).
2234
2235         [1]: https://bugs.webkit.org/show_bug.cgi?id=163226
2236
2237         * CMakeLists.txt:
2238         * JavaScriptCore.xcodeproj/project.pbxproj:
2239         * bytecode/DOMJITAccessCasePatchpointParams.cpp: Added.
2240         (JSC::SlowPathCallGeneratorWithArguments::SlowPathCallGeneratorWithArguments):
2241         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
2242         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
2243         * bytecode/DOMJITAccessCasePatchpointParams.h: Copied from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
2244         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
2245         (JSC::DOMJITAccessCasePatchpointParams::SlowPathCallGenerator::~SlowPathCallGenerator):
2246         * bytecode/PolymorphicAccess.cpp:
2247         (JSC::AccessGenerationState::liveRegistersForCall):
2248         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
2249         (JSC::calleeSaveRegisters):
2250         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
2251         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
2252         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
2253         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
2254         (JSC::AccessGenerationState::originalExceptionHandler):
2255         (JSC::AccessCase::generateImpl):
2256         (JSC::AccessCase::emitDOMJITGetter):
2257         (JSC::PolymorphicAccess::regenerate):
2258         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): Deleted.
2259         * bytecode/PolymorphicAccess.h:
2260         (JSC::AccessGenerationState::SpillState::isEmpty):
2261         (JSC::AccessGenerationState::setSpillStateForJSGetterSetter):
2262         (JSC::AccessGenerationState::spillStateForJSGetterSetter):
2263         (JSC::AccessGenerationState::liveRegistersForCall): Deleted.
2264         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation): Deleted.
2265         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): Deleted.
2266         * dfg/DFGDOMJITPatchpointParams.cpp:
2267         * dfg/DFGDOMJITPatchpointParams.h:
2268         * domjit/DOMJITPatchpoint.h:
2269         * domjit/DOMJITPatchpointParams.h:
2270         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
2271         * ftl/FTLDOMJITPatchpointParams.cpp:
2272         * ftl/FTLDOMJITPatchpointParams.h:
2273         * jsc.cpp:
2274         (WTF::DOMJITNode::checkDOMJITNode):
2275         (WTF::DOMJITGetterComplex::DOMJITGetterComplex):
2276         (WTF::DOMJITGetterComplex::createStructure):
2277         (WTF::DOMJITGetterComplex::create):
2278         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
2279         (WTF::DOMJITGetterComplex::domJITNodeGetterSetter):
2280         (WTF::DOMJITGetterComplex::finishCreation):
2281         (WTF::DOMJITGetterComplex::functionEnableException):
2282         (WTF::DOMJITGetterComplex::customGetter):
2283         (GlobalObject::finishCreation):
2284         (functionCreateDOMJITGetterComplexObject):
2285
2286 2016-10-17  Saam Barati  <sbarati@apple.com>
2287
2288         Build fix for HasOwnPropertyCache::Entry caused slowdown by introducing a constructor that doesn't use move semantics for the RefPtr<UniquedStringImpl> parameter
2289         https://bugs.webkit.org/show_bug.cgi?id=163490
2290
2291         Reviewed by Darin Adler.
2292
2293         * runtime/HasOwnPropertyCache.h:
2294         (JSC::HasOwnPropertyCache::Entry::Entry):
2295         (JSC::HasOwnPropertyCache::tryAdd):
2296
2297 2016-10-17  Mark Lam  <mark.lam@apple.com>
2298
2299         Use the reject() helper function for conditionally throwing TypeErrors.
2300         https://bugs.webkit.org/show_bug.cgi?id=163491
2301
2302         Reviewed by Filip Pizlo.
2303
2304         In some places where we may conditionally throw a TypeError (e.g. when in strict
2305         mode), we already use the reject() helper function to conditionally throw the
2306         TypeError.  Doing so makes the code mode compact.  This patch applies this idiom
2307         consistently in all places that throws TypeError where appropriate.
2308
2309         This patch also does the following:
2310         1. Make the reject() helper function take an ASCIILiteral instead of a const char*
2311            because we always pass it a literal string anyway.
2312         2. Change the reject helper() to take a ThrowScope&.  This allows the thrown
2313            error to be attributed to its caller.
2314         3. When an error message string is instantiated repeatedly in more than 1 place,
2315            create a common copy of that literal string in JSObject.cpp (if one doesn't
2316            already exist) and use that common string in all those places.
2317         4. Since I was auditing call sites of throwTypeError() to check if they should be
2318            using the reject() helper instead, I also fixed those up to pass the error
2319            message as an ASCIILiteral where appropriate.
2320         5. In functions that I touched, change the code to not recompute the VM& when it
2321            is already available.
2322
2323         * jit/JITOperations.cpp:
2324         * llint/LLIntSlowPaths.cpp:
2325         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2326         * runtime/ArrayPrototype.cpp:
2327         (JSC::shift):
2328         (JSC::unshift):
2329         (JSC::arrayProtoFuncPop):
2330         (JSC::arrayProtoFuncReverse):
2331         * runtime/CommonSlowPaths.cpp:
2332         (JSC::SLOW_PATH_DECL):
2333         * runtime/GetterSetter.cpp:
2334         (JSC::callSetter):
2335         * runtime/JSArray.cpp:
2336         (JSC::JSArray::defineOwnProperty):
2337         (JSC::JSArray::setLengthWithArrayStorage):
2338         (JSC::JSArray::pop):
2339         * runtime/JSArrayBuffer.cpp:
2340         (JSC::JSArrayBuffer::put):
2341         (JSC::JSArrayBuffer::defineOwnProperty):
2342         * runtime/JSCJSValue.cpp:
2343         (JSC::JSValue::putToPrimitive):
2344         (JSC::JSValue::putToPrimitiveByIndex):
2345         * runtime/JSDataView.cpp:
2346         (JSC::JSDataView::put):
2347         (JSC::JSDataView::defineOwnProperty):
2348         * runtime/JSFunction.cpp:
2349         (JSC::JSFunction::put):
2350         (JSC::JSFunction::defineOwnProperty):
2351         * runtime/JSGenericTypedArrayView.h:
2352         (JSC::JSGenericTypedArrayView::setIndex):
2353         * runtime/JSGenericTypedArrayViewInlines.h:
2354         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
2355         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
2356         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2357         (JSC::speciesConstruct):
2358         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
2359         * runtime/JSModuleNamespaceObject.cpp:
2360         (JSC::JSModuleNamespaceObject::defineOwnProperty):
2361         * runtime/JSObject.cpp:
2362         (JSC::ordinarySetSlow):
2363         (JSC::JSObject::putInlineSlow):
2364         (JSC::JSObject::setPrototypeWithCycleCheck):
2365         (JSC::JSObject::defineOwnIndexedProperty):
2366         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
2367         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
2368         (JSC::validateAndApplyPropertyDescriptor):
2369         * runtime/JSObject.h:
2370         * runtime/JSObjectInlines.h:
2371         (JSC::JSObject::putInline):
2372         * runtime/JSProxy.cpp:
2373         (JSC::JSProxy::setPrototype):
2374         * runtime/JSSymbolTableObject.h:
2375         (JSC::symbolTablePut):
2376         * runtime/Lookup.h:
2377         (JSC::putEntry):
2378         * runtime/RegExpObject.cpp:
2379         (JSC::RegExpObject::defineOwnProperty):
2380         * runtime/RegExpObject.h:
2381         (JSC::RegExpObject::setLastIndex):
2382         * runtime/Reject.h:
2383         (JSC::reject):
2384         * runtime/SparseArrayValueMap.cpp:
2385         (JSC::SparseArrayValueMap::putEntry):
2386         (JSC::SparseArrayValueMap::putDirect):
2387         (JSC::SparseArrayEntry::put):
2388         * runtime/StringObject.cpp:
2389         (JSC::StringObject::put):
2390         (JSC::StringObject::putByIndex):
2391         * runtime/SymbolConstructor.cpp:
2392         (JSC::symbolConstructorKeyFor):
2393
2394 2016-10-16  Filip Pizlo  <fpizlo@apple.com>
2395
2396         Air::IRC needs to place all Tmps on some worklist, even if they have no interference edges
2397         https://bugs.webkit.org/show_bug.cgi?id=163509
2398
2399         Reviewed by Mark Lam.
2400         
2401         The worklist building function in IRC skips temporaries that have no degree. This doesn't appear
2402         to be necessary. This has been there since the original IRC commit. It hasn't caused bugs because
2403         ordinarily, the only way to have a tmp with no degree is to not have any mention of that tmp. But
2404         while working on bug 163371, I hit a crazy corner case where a temporary would have no
2405         interference edges (i.e. no degree). Here's how it happens:
2406         
2407         A spill tmp from a previous iteration of IRC may have no degree: imagine a tmp that is live
2408         everywhere and interferes with everyone, but has one use like:
2409
2410         Move %ourTmp, %someOtherTmp
2411
2412         Where there are no other tmps live.  After spill conversion, this may look like:
2413
2414         Move (ourSpill), %newTmp
2415         Move %newTmp, %someOtherTmp
2416
2417         Of course, we'd rather not get this kind of spill code but it's totally possible because we now
2418         have a bunch of random conditions under which we won't slap the spill address directly into the
2419         Move.
2420
2421         After this happens, assuming that the only thing live was %someOtherTmp, we will have zero degree
2422         for %newTmp because the Move is coalescable and does not contribute to interference.
2423
2424         Then, we might coalesce %someOtherTmp with %newTmp.  Once this happens, if we make the %newTmp be
2425         the master, we're in deep trouble because %newTmp is not on any worklist.
2426         
2427         I don't know how to reproduce this except through the patch in bug 163371. Removing the two lines
2428         of code that skipped no-degree tmps causes no regressions, and resolves the problem I was having.
2429
2430         * b3/air/AirIteratedRegisterCoalescing.cpp:
2431
2432 2016-10-15  Mark Lam  <mark.lam@apple.com>
2433
2434         Add a $vm.getpid() method.
2435         https://bugs.webkit.org/show_bug.cgi?id=163493
2436
2437         Reviewed by Saam Barati.
2438
2439         This is especially useful when we need to know the pid of an instance of jsc in
2440         the foreground that we're trying to attach a debugger to while the JSC tests are
2441         running in the background with a gazillion other jsc processes live at the same
2442         time.
2443
2444         Currently, $vm.getpid() is only supported on non-Windows platforms.
2445         According to https://msdn.microsoft.com/en-us/library/ms235372.aspx, getpid() is
2446         deprecated.  According to https://msdn.microsoft.com/en-us/library/t2y34y40.aspx,
2447         _getpid() cannot be used in applications that execute in the Windows Runtime.
2448
2449         Since this is only a debugging tool and is not a required feature, I'll defer
2450         the Windows implementation of this function till the time when someone actually
2451         needs it.
2452
2453         * tools/JSDollarVMPrototype.cpp:
2454         (JSC::functionGetPID):
2455         (JSC::JSDollarVMPrototype::finishCreation):
2456
2457 2016-10-15  Saam Barati  <sbarati@apple.com>
2458
2459         Assertion failed under operationToLowerCase with a rope with zero length
2460         https://bugs.webkit.org/show_bug.cgi?id=163314
2461
2462         Reviewed by Mark Lam.
2463
2464         There are some ways to get JSC to create empty rope strings. ToLowerCase
2465         inside the DFG/FTL goes to the slow path when the argument is a rope.
2466         operationToLowerCase was calling into a WTF string function that
2467         assumed we are passing it a this value that has non-zero length.
2468         However, we were calling it with a string that did have zero length.
2469         To fix this, we make operationToLowerCase return the empty JSString
2470         if it is going to make a string with zero length.
2471
2472         * dfg/DFGOperations.cpp:
2473         * jsc.cpp:
2474         (GlobalObject::finishCreation):
2475         (functionIsRope):
2476
2477 2016-10-14  Benjamin Poulain  <bpoulain@apple.com>
2478
2479         [JSC] op_negate should with any type
2480         https://bugs.webkit.org/show_bug.cgi?id=162587
2481
2482         Reviewed by Saam Barati.
2483
2484         * dfg/DFGAbstractInterpreterInlines.h:
2485         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2486         ArithNegate is quite simple. If the input is double, the output
2487         is double. The other cases are set from the LLInt slow case.
2488
2489         * dfg/DFGByteCodeParser.cpp:
2490         (JSC::DFG::ByteCodeParser::makeSafe):
2491         * dfg/DFGClobberize.h:
2492         (JSC::DFG::clobberize):
2493         * dfg/DFGFixupPhase.cpp:
2494         (JSC::DFG::FixupPhase::fixupNode):
2495
2496         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2497         Tweak a bit the IntegerRangeOptimizationPhase when simplifying
2498         ArithAbs to ArithNegate.
2499         We should not do the conversion if the target nodes OSR Exits
2500         on different input than the source node.
2501
2502         In particular, Checked ArithNegate exits on zero while
2503         ArithAbs has not problem with it.
2504         Unchecked ArithAbs() do not OSR Exit on INT_MIN, ArithNeg
2505         should not either.
2506
2507         * dfg/DFGPredictionPropagationPhase.cpp:
2508         * dfg/DFGSpeculativeJIT.cpp:
2509         (JSC::DFG::SpeculativeJIT::compileArithNegate):
2510         (JSC::DFG::SpeculativeJIT::compileMathIC):
2511         * dfg/DFGSpeculativeJIT.h:
2512         (JSC::DFG::SpeculativeJIT::callOperation):
2513         * ftl/FTLLowerDFGToB3.cpp:
2514         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
2515         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
2516
2517         * jit/JITNegGenerator.cpp:
2518         (JSC::JITNegGenerator::generateFastPath):
2519         * jit/JITOperations.cpp:
2520         Add result profiling in baseline to have types we can use
2521         in DFG and FTL.
2522
2523 2016-10-14  Keith Miller  <keith_miller@apple.com>
2524
2525         B3 needs a special WasmAddress Opcode
2526         https://bugs.webkit.org/show_bug.cgi?id=163394
2527
2528         Reviewed by Filip Pizlo.
2529
2530         This patch adds support for WasmAddress. WasmAddress will be used by
2531         Wasm to compute the address of a memory operation from the pinned
2532         base pointer. WasmAddress takes an IntPtr so we can avoid emitting
2533         unnecessary Move32s in Air. This could happen in the following case:
2534
2535         @ptr = Trunc(...)
2536         WasmAddress(@ptr, pinnedGPR)
2537         ...
2538         PatchPoint(...) // Do Wasm call
2539         WasmAddress(@ptr, pinnedGPR)
2540         ...
2541
2542         In this case we will not be able to CSE the WasmAddresses since the
2543         call writes to pinnedGPR. Thus if WasmAddress took an Int32 we would need
2544         to emit an extra Move32 at the second WasmAddress to ensure it saw a proper
2545         32-bit value. If Wasm ensures that there there is a leading ZExt32 then
2546         the duplicated moves become unnecessary.
2547
2548         * CMakeLists.txt:
2549         * JavaScriptCore.xcodeproj/project.pbxproj:
2550         * b3/B3LowerToAir.cpp:
2551         (JSC::B3::Air::LowerToAir::effectiveAddr):
2552         (JSC::B3::Air::LowerToAir::lower):
2553         * b3/B3Opcode.cpp:
2554         (WTF::printInternal):
2555         * b3/B3Opcode.h:
2556         * b3/B3Validate.cpp:
2557         * b3/B3Value.cpp:
2558         (JSC::B3::Value::effects):
2559         * b3/B3WasmAddressValue.cpp: Added.
2560         (JSC::B3::WasmAddressValue::~WasmAddressValue):
2561         (JSC::B3::WasmAddressValue::dumpMeta):
2562         (JSC::B3::WasmAddressValue::cloneImpl):
2563         (JSC::B3::WasmAddressValue::WasmAddressValue):
2564         * b3/B3WasmAddressValue.h: Added.
2565         * b3/testb3.cpp:
2566         (JSC::B3::testWasmAddress):
2567         (JSC::B3::run):
2568
2569 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
2570
2571         test262: @isConstructor incorrectly thinks Math.cos is a constructor
2572         https://bugs.webkit.org/show_bug.cgi?id=163437
2573
2574         Reviewed by Saam Barati.
2575
2576         * runtime/JSFunction.cpp:
2577         (JSC::JSFunction::getConstructData):
2578         By default, Host JSFunctions are not constructable. They get
2579         the default callHostFunctionAsConstructor native constructor.
2580         When getting construct data we can return ConstructType::None
2581         in these cases instead of indicating it might be constructable
2582         and later throwing an exception when construction is attempted.
2583
2584 2016-10-14  Ryan Haddad  <ryanhaddad@apple.com>
2585
2586         Unreviewed, rolling out r207322.
2587
2588         This change caused JSC test failures
2589
2590         Reverted changeset:
2591
2592         "Fix Array.prototype.splice ES6 compliance."
2593         https://bugs.webkit.org/show_bug.cgi?id=163372
2594         http://trac.webkit.org/changeset/207322
2595
2596 2016-10-14  Mark Lam  <mark.lam@apple.com>
2597
2598         JSON.parse should not modify frozen objects.
2599         https://bugs.webkit.org/show_bug.cgi?id=163430
2600
2601         Reviewed by Saam Barati.
2602
2603         The ES6 spec for JSON.parse (https://tc39.github.io/ecma262/#sec-json.parse and
2604         https://tc39.github.io/ecma262/#sec-internalizejsonproperty) states that it uses
2605         CreateDataProperty() (https://tc39.github.io/ecma262/#sec-createdataproperty) to
2606         set values returned by a reviver.  The spec for CreateDataPropertyOrThrow states:
2607
2608         "This abstract operation creates a property whose attributes are set to the same
2609         defaults used for properties created by the ECMAScript language assignment
2610         operator. Normally, the property will not already exist. If it does exist and is
2611         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
2612         false."
2613
2614         Note: CreateDataProperty() will not throw a TypeError.
2615
2616         Since the properties of frozen objects are not extensible, not configurable, and
2617         not writeable, JSON.parse should fail to write to any frozen objects.  Similarly,
2618         JSON.parse should fail to delete properties in frozen objects.
2619
2620         In JSON.parse(), we previously write to array elements using the form of
2621         putDirectIndex() that uses mode PutDirectIndexLikePutDirect.  This makes it so
2622         that the write (i.e. put) is always successful.  We've now fixed this to use
2623         PutDirectIndexShouldNotThrow mode instead, which will fail to put the element if
2624         the array is not writeable.
2625
2626         Also changed Walker::walk() to use the version of methodTable() that takes a VM&
2627         since the VM& is already available.
2628
2629         * runtime/JSONObject.cpp:
2630         (JSC::Walker::walk):
2631
2632 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
2633
2634         test262: Failure with RegExp.prototype.compile when pattern is undefined
2635         https://bugs.webkit.org/show_bug.cgi?id=163431
2636
2637         Reviewed by Yusuke Suzuki.
2638
2639         If pattern is undefined let P be the empty String.
2640         https://tc39.github.io/ecma262/#sec-regexpinitialize
2641
2642         * runtime/RegExpPrototype.cpp:
2643         (JSC::regExpProtoFuncCompile):
2644
2645 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
2646
2647         Exception message for expressions with multiple bracket accesses is inconsistent / incorrect
2648         https://bugs.webkit.org/show_bug.cgi?id=163426
2649
2650         Reviewed by Geoffrey Garen.
2651
2652         * bytecompiler/NodesCodegen.cpp:
2653         (JSC::BracketAccessorNode::emitBytecode):
2654         It matters where emitExpressionInfo is called since it gathers
2655         info about where we are in the instruction stream. We need to
2656         emit it before the bytecode that we want to associate the data
2657         with. In this case, before the getById / getByVal.
2658
2659 2016-10-13  Mark Lam  <mark.lam@apple.com>
2660
2661         Fix Array.prototype.splice ES6 compliance.
2662         https://bugs.webkit.org/show_bug.cgi?id=163372
2663
2664         Reviewed by Geoffrey Garen and Yusuke Suzuki.
2665
2666         Our Array.prototype.splice implementation neglected to set length on the result
2667         array (step 12 of https://tc39.github.io/ecma262/#sec-array.prototype.splice) in
2668         a certain code path.  This is now fixed.
2669
2670         I'm deferring the implementation of step 8 till later because it requires more
2671         careful consideration and the fix is of a lesser value (and therefore, of less
2672         urgency).  See https://bugs.webkit.org/show_bug.cgi?id=163417
2673
2674         Also added some needed exception checks and assertions.
2675
2676         * runtime/ArrayPrototype.cpp:
2677         (JSC::arrayProtoFuncSplice):
2678
2679 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
2680
2681         Web Inspector: Stepping highlight for dot/bracket expressions in if statements highlights subset of the expression
2682         https://bugs.webkit.org/show_bug.cgi?id=163378
2683         <rdar://problem/28749376>
2684
2685         Reviewed by Saam Barati.
2686
2687         * parser/Parser.cpp:
2688         (JSC::Parser<LexerType>::parseAssignmentExpression):
2689         Since each expression builds on the previous, always keep the starting
2690         location the first location.
2691
2692 2016-10-13  Per Arne Vollan  <pvollan@apple.com>
2693
2694         [Win64] Compile fix.
2695         https://bugs.webkit.org/show_bug.cgi?id=163384
2696
2697         Reviewed by Brent Fulgham.
2698
2699         Fix use of potentially uninitialized variable.
2700
2701         * dfg/DFGSpeculativeJIT64.cpp:
2702         (JSC::DFG::SpeculativeJIT::compile):
2703
2704 2016-10-12  Chris Dumez  <cdumez@apple.com>
2705
2706         [Web IDL] Drop support for legacy [ConstructorConditional=*]
2707         https://bugs.webkit.org/show_bug.cgi?id=163368
2708
2709         Reviewed by Ryosuke Niwa.
2710
2711         Drop ENABLE_DOM4_EVENTS_CONSTRUCTOR compiler flag.
2712
2713         * Configurations/FeatureDefines.xcconfig:
2714
2715 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2716
2717         Web Inspector: step-into `console.log(o)` should not step through inspector javascript
2718         https://bugs.webkit.org/show_bug.cgi?id=161656
2719         <rdar://problem/28181123>
2720
2721         Reviewed by Timothy Hatcher.
2722
2723         * debugger/Debugger.h:
2724         * debugger/Debugger.cpp:
2725         (JSC::Debugger::pauseIfNeeded):
2726         If the Script is blacklisted skip checking if we need to pause.
2727
2728         (JSC::Debugger::isBlacklisted):
2729         (JSC::Debugger::addToBlacklist):
2730         (JSC::Debugger::clearBlacklist):
2731         Add the ability to add a Script to a blacklist. Currently the blacklist
2732         only prevents pausing in the Script.
2733
2734         * inspector/agents/InspectorDebuggerAgent.cpp:
2735         (Inspector::isWebKitInjectedScript):
2736         (Inspector::InspectorDebuggerAgent::didParseSource):
2737         Always add Internal InjectedScripts to the Debugger's blacklist.
2738
2739         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
2740         Clear blacklists when clearing debugger state.
2741
2742 2016-10-12  Keith Miller  <keith_miller@apple.com>
2743
2744         B3 needs a special WasmBoundsCheck Opcode
2745         https://bugs.webkit.org/show_bug.cgi?id=163246
2746
2747         Reviewed by Filip Pizlo.
2748
2749         This patch adds a new Opcode, WasmBoundsCheck, as well as a B3::Value subclass for it,
2750         WasmBoundsCheckValue. WasmBoundsCheckValue takes three pieces of information. The first is
2751         the Int32 pointer value used to be used by the Load.  Next is the pinned register. The
2752         pinned register must be pinned by calling proc.setPinned() prior to compiling the
2753         Procedure. Lastly, the WasmBoundsCheckValue takes an offset. The WasmBoundsCheckValue is
2754         will then emit code that side-exits if the Int64 sum of the offset and pointer is greater
2755         than or equal to the value in the pinnedRegister. Instead of taking a generator for each
2756         value like Check/Patchpoint, WasmBoundsCheck gets its generator directly off Air::Code. In
2757         Air this patch adds a new Custom opcode, WasmBoundsCheck.
2758
2759         In the future we should add WasmBoundsCheck to CSE so it can eliminate redundant bounds
2760         checks. At the first cut, we can remove any WasmBoundsCheck dominated by another
2761         WasmBoundsCheck with the same pointer and pinnedGPR, and a larger offset.
2762
2763         * CMakeLists.txt:
2764         * JavaScriptCore.xcodeproj/project.pbxproj:
2765         * b3/B3LowerToAir.cpp:
2766         (JSC::B3::Air::LowerToAir::imm):
2767         (JSC::B3::Air::LowerToAir::lower):
2768         * b3/B3Opcode.cpp:
2769         (WTF::printInternal):
2770         * b3/B3Opcode.h:
2771         * b3/B3Procedure.cpp:
2772         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
2773         * b3/B3Procedure.h:
2774         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
2775         * b3/B3Validate.cpp:
2776         * b3/B3Value.cpp:
2777         (JSC::B3::Value::effects):
2778         (JSC::B3::Value::typeFor):
2779         * b3/B3WasmBoundsCheckValue.cpp: Added.
2780         (JSC::B3::WasmBoundsCheckValue::~WasmBoundsCheckValue):
2781         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2782         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
2783         * b3/B3WasmBoundsCheckValue.h: Added.
2784         (JSC::B3::WasmBoundsCheckValue::accepts):
2785         (JSC::B3::WasmBoundsCheckValue::pinnedGPR):
2786         (JSC::B3::WasmBoundsCheckValue::offset):
2787         * b3/air/AirCode.h:
2788         (JSC::B3::Air::Code::setWasmBoundsCheckGenerator):
2789         (JSC::B3::Air::Code::wasmBoundsCheckGenerator):
2790         * b3/air/AirCustom.cpp:
2791         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
2792         * b3/air/AirCustom.h:
2793         (JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
2794         (JSC::B3::Air::WasmBoundsCheckCustom::isValidFormStatic):
2795         (JSC::B3::Air::WasmBoundsCheckCustom::admitsStack):
2796         (JSC::B3::Air::WasmBoundsCheckCustom::isTerminal):
2797         (JSC::B3::Air::WasmBoundsCheckCustom::hasNonArgNonControlEffects):
2798         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
2799         * b3/air/AirOpcode.opcodes:
2800         * b3/testb3.cpp:
2801         (JSC::B3::testWasmBoundsCheck):
2802         (JSC::B3::run):
2803
2804 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
2805
2806         The blackening of CellState is a bad way of tracking if the object is being marked for the first time
2807         https://bugs.webkit.org/show_bug.cgi?id=163343
2808
2809         Reviewed by Mark Lam.
2810         
2811         When I first added the concept of NewGrey/OldGrey, I had the SlotVisitor store the old cell
2812         state in itself, so that it could use it to decide what to do for reportExtraMemoryVisited().
2813         
2814         Then I changed it in a recent commit, because I wanted the freedom to have SlotVisitor visit
2815         multiple objects in tandem. But I never ended up using this capability. Still, I liked the
2816         new way better: instead of the SlotVisitor rembemering the state-before-blackening, we would
2817         make the object's state reflect whether it was black for the first time or not. That seemed
2818         convenient.
2819         
2820         Unfortunately it's wrong. After we blacken the object, a concurrent barrier could instantly
2821         grey it. Then we would forget that we are visiting this object for the first time.
2822         Subsequent visits will think that they are not the first. So, we will fail to do the right
2823         thing in reportExtraMemoryVisited().
2824         
2825         So, this reverts that change. This is a little more than just a revert, though. I've changed
2826         the terminology a bit. For example, I got tired of reading Black and having to remind myself
2827         that it really means that the object has begun being visited, instead of the more strict
2828         meaning that implies that it has already been visited. We want to say that it's Black or
2829         currently being scanned. I'm going to adopt Siebert's term for this: Anthracite [1]. So, our
2830         black CellState is now called AnthraciteOrBlack.
2831         
2832         [1] https://pdfs.semanticscholar.org/7ae4/633265aead1f8835cf7966e179d02c2c8a4b.pdf
2833
2834         * heap/CellState.h:
2835         (JSC::isBlack): Deleted.
2836         (JSC::blacken): Deleted.
2837         * heap/Heap.cpp:
2838         (JSC::Heap::addToRememberedSet):
2839         (JSC::Heap::writeBarrierSlowPath):
2840         * heap/Heap.h:
2841         * heap/HeapInlines.h:
2842         (JSC::Heap::reportExtraMemoryVisited):
2843         (JSC::Heap::reportExternalMemoryVisited):
2844         * heap/SlotVisitor.cpp:
2845         (JSC::SlotVisitor::appendToMarkStack):
2846         (JSC::SlotVisitor::visitChildren):
2847         * heap/SlotVisitor.h:
2848         * heap/SlotVisitorInlines.h:
2849         (JSC::SlotVisitor::reportExtraMemoryVisited):
2850         (JSC::SlotVisitor::reportExternalMemoryVisited):
2851         * llint/LLIntData.cpp:
2852         (JSC::LLInt::Data::performAssertions):
2853         * llint/LowLevelInterpreter.asm:
2854
2855 2016-10-12  Mark Lam  <mark.lam@apple.com>
2856
2857         Rename variables in arrayProtoFuncSplice() to match names in the spec.
2858         https://bugs.webkit.org/show_bug.cgi?id=163354
2859
2860         Reviewed by Saam Barati.
2861
2862         This will make it easier to see whether the code matches the spec or not.
2863         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.splice
2864
2865         * runtime/ArrayPrototype.cpp:
2866         (JSC::arrayProtoFuncSplice):
2867
2868 2016-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2869
2870         [DOMJIT][JSC] Explore the way to embed nodeType into JSC::JSType in WebCore
2871         https://bugs.webkit.org/show_bug.cgi?id=163245
2872
2873         Reviewed by Filip Pizlo.
2874
2875         We reserve the highest bit of JSC::JSType for extensions outside JSC.
2876         JSC does not use JSType bits so many: only 52 types are defined.
2877
2878         And we extend CallDOM patchpoint to claim that it does not require a global object.
2879         This global object is used to generate a DOM wrapper. However, nodeType does not require
2880         it since it just returns integer. In the future, we will extend CallDOM to claim
2881         its result type. And we can decide this `requireGlobalObject` condition automatically
2882         according to the result type.
2883
2884         * JavaScriptCore.xcodeproj/project.pbxproj:
2885         * dfg/DFGByteCodeParser.cpp:
2886         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2887         * dfg/DFGFixupPhase.cpp:
2888         (JSC::DFG::FixupPhase::fixupNode):
2889         * dfg/DFGGraph.h:
2890         * dfg/DFGNode.h:
2891         (JSC::DFG::Node::hasCheckDOMPatchpoint):
2892         (JSC::DFG::Node::checkDOMPatchpoint):
2893         (JSC::DFG::Node::hasCallDOMPatchpoint):
2894         (JSC::DFG::Node::callDOMPatchpoint):
2895         (JSC::DFG::Node::hasDOMJIT): Deleted.
2896         (JSC::DFG::Node::domJIT): Deleted.
2897         * dfg/DFGSpeculativeJIT.cpp:
2898         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2899         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2900         * domjit/DOMJITCallDOMPatchpoint.h: Copied from Source/JavaScriptCore/domjit/DOMJITGetterSetter.h.
2901         (JSC::DOMJIT::CallDOMPatchpoint::create):
2902         * domjit/DOMJITGetterSetter.h:
2903         * domjit/DOMJITPatchpoint.h:
2904         * ftl/FTLLowerDFGToB3.cpp:
2905         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2906         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2907         * jsc.cpp:
2908         * llint/LLIntData.cpp:
2909         (JSC::LLInt::Data::performAssertions):
2910         * llint/LowLevelInterpreter.asm:
2911         * runtime/JSType.h:
2912
2913 2016-10-12  Keith Miller  <keith_miller@apple.com>
2914
2915         Handle non-function, non-undefined comparator in Array.prototype.sort
2916         https://bugs.webkit.org/show_bug.cgi?id=163085
2917
2918         Reviewed by Yusuke Suzuki.
2919
2920         * builtins/ArrayPrototype.js:
2921         (sort.comparatorSort):
2922         (sort.stringSort):
2923         (sort):
2924
2925 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
2926
2927         REGRESSION (r207179): ASSERTION FAILED: node.cell != previousCell
2928         https://bugs.webkit.org/show_bug.cgi?id=163337
2929
2930         Reviewed by Mark Lam.
2931         
2932         It turns out that HeapSnapshot was not down with revisiting. The concurrent GC is going to be
2933         built around the idea that we can revisit objects many times. This means that any action that
2934         should only take place once per object must check the object's state. This fixes the snapshot
2935         code to do this.
2936         
2937         While writing this code, I realized that we're actually doing this check incorrectly, so I
2938         filed bug 163343. That bug requires a race, so we aren't going to see it yet.
2939
2940         * heap/HeapSnapshot.cpp:
2941         (JSC::HeapSnapshot::finalize):
2942         * heap/SlotVisitor.cpp:
2943         (JSC::SlotVisitor::appendToMarkStack):
2944         (JSC::SlotVisitor::visitChildren):
2945
2946 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2947
2948         Web Inspector: Improve support for logging Proxy objects in console
2949         https://bugs.webkit.org/show_bug.cgi?id=163323
2950         <rdar://problem/28432553>
2951
2952         Reviewed by Timothy Hatcher.
2953
2954         This is based off of similiar patches in Blink for Proxy handling.
2955
2956         * bindings/ScriptValue.cpp:
2957         (Deprecated::ScriptValue::isEqual):
2958         Use strict equality. This is the intent, and it prevents the possibility of triggering
2959         primitive conversion on objects in previous ConsoleMessage argument lists.
2960
2961         * inspector/InjectedScriptSource.js:
2962         (InjectedScript.prototype._propertyDescriptors):
2963         Bail if the object is a Proxy.
2964
2965         (InjectedScript.prototype._describe):
2966         Provide a friendlier name, "Proxy" instead of "ProxyObject".
2967         
2968         (InjectedScript.RemoteObject):
2969         When generating a preview for a Proxy object, generate it from the final target
2970         and mark it as lossy so that the object can always be expanded to get the internal
2971         target/handler properties.
2972
2973         * inspector/JSInjectedScriptHost.h:
2974         * inspector/JSInjectedScriptHost.cpp:
2975         (Inspector::JSInjectedScriptHost::subtype):
2976         New subtype for Proxy objects.
2977
2978         (Inspector::JSInjectedScriptHost::proxyTargetValue):
2979         Resolve the final target value for a Proxy.
2980
2981         * inspector/JSInjectedScriptHostPrototype.cpp:
2982         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2983         (Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
2984         Add the new method.
2985
2986         * inspector/ScriptArguments.cpp:
2987         (Inspector::ScriptArguments::getFirstArgumentAsString):
2988         Avoid triggering Proxy traps on a Proxy object when getting a quick
2989         string description for ConsoleMessages.
2990
2991         * inspector/protocol/Runtime.json:
2992         Add new "proxy" subtype.
2993
2994 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2995
2996         Emit DebugHooks uniformly with pause locations instead of having separate pause locations and op_debug emits
2997         https://bugs.webkit.org/show_bug.cgi?id=162809
2998
2999         Reviewed by Geoffrey Garen.
3000
3001         Change how BytecodeGeneration emits debug hooks to be more consistent.
3002         Previously most nodes individually generated their own debug hook
3003         and we asserted that it matched a breakpoint location identified
3004         by the parser. This could get out of sync, or nodes could forget to
3005         emit debug hooks expected by the parser.
3006         
3007         With this change, we always check and emit a debug hook for any
3008         node. The default behavior is for BytecodeGenerator::emitNode
3009         to emit the debug hook when emitting the node itself. This covers
3010         the majority of cases (statements).
3011
3012         There are a few exceptions where we continue to need to customize
3013         emitting debug hooks:
3014
3015             1. Nodes with emitBytecodeInConditionContext
3016                 - non-Expression nodes customize how they emit their children
3017                 - constants conditions may emit nothing, but we had recorded a breakpoint location so emit a debug hook
3018                 - always emit one debug hook in case we recorded a breakpoint location, but avoid emitting multiple
3019                   in nodes which may call up to the ExpressionNode::emitBytecodeInConditionContext base impl.
3020             2. Specialized Debug Hooks
3021                 - such as hooks for Program start/end, debugger statements, etc.
3022             3. Debug Hooks in for..of / for..in that don't correspond to re-emitting nodes
3023                 - such as pausing on the assignment expression inside these loops
3024
3025         The majority of nodes no longer have custom emits.
3026
3027         * bytecompiler/BytecodeGenerator.h:
3028         (JSC::BytecodeGenerator::emitNodeInTailPosition):
3029         (JSC::BytecodeGenerator::emitNodeInConditionContext):
3030         * bytecompiler/BytecodeGenerator.cpp:
3031         (JSC::BytecodeGenerator::emitDebugHook):
3032         (JSC::BytecodeGenerator::emitEnumeration):
3033         By default, when emitting a node check if we should also emit an op_debug for it.
3034         This default DebugHook is WillExecuteStatement, which is a normal pause point.
3035
3036         * bytecompiler/NodesCodegen.cpp:
3037         (JSC::ConstantNode::emitBytecodeInConditionContext):
3038         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
3039         (JSC::BinaryOpNode::emitBytecodeInConditionContext):
3040         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
3041         The parser would have generated a pause location for these conditions
3042         no matter what constant folding and re-writing these nodes may perform.
3043         So, when emitting these nodes in condition context check if they need
3044         emit their own debug hook.
3045
3046         (JSC::EmptyStatementNode::emitBytecode):
3047         (JSC::ExprStatementNode::emitBytecode):
3048         (JSC::DeclarationStatement::emitBytecode):
3049         (JSC::IfElseNode::emitBytecode):
3050         (JSC::DoWhileNode::emitBytecode):
3051         (JSC::WhileNode::emitBytecode):
3052         (JSC::ForNode::emitBytecode):
3053         (JSC::ContinueNode::emitBytecode):
3054         (JSC::BreakNode::emitBytecode):
3055         (JSC::ReturnNode::emitBytecode):
3056         (JSC::WithNode::emitBytecode):
3057         (JSC::SwitchNode::emitBytecode):
3058         (JSC::ThrowNode::emitBytecode):
3059         No longer need to custom emit debug hooks. The default emitNode will handle these.
3060
3061         (JSC::ForInNode::emitBytecode):
3062         Include extra debug hooks the user expects to return back to the assignment
3063         expression in the loop header before starting the body again. The same is done
3064         for for..of with emitEnumeration.
3065
3066         * parser/ASTBuilder.h:
3067         (JSC::ASTBuilder::createExportDefaultDeclaration):
3068         (JSC::ASTBuilder::createExportLocalDeclaration):
3069         These are no longer needed to fake-satisfy assertions. We never wanted to
3070         emit debug hooks for these inner statements because the export statement
3071         will already have the debug hooks.
3072
3073         (JSC::ASTBuilder::createForInLoop):
3074         (JSC::ASTBuilder::createForOfLoop):
3075         Include the correct location where the declaration starts.
3076
3077         (JSC::ASTBuilder::breakpointLocation):
3078         Simplify to a general implementation for Node.
3079
3080         * parser/SyntaxChecker.h:
3081         (JSC::SyntaxChecker::createForInLoop):
3082         (JSC::SyntaxChecker::createForOfLoop):
3083         Ignore the new extra parameter.
3084
3085         * parser/Nodes.h:
3086         (JSC::Node::needsDebugHook):
3087         (JSC::Node::setNeedsDebugHook):
3088         (JSC::ExpressionNode::needsDebugHook): Deleted.
3089         (JSC::ExpressionNode::setNeedsDebugHook): Deleted.
3090         (JSC::StatementNode::isEmptyStatement): Deleted.
3091         (JSC::StatementNode::needsDebugHook): Deleted.
3092         (JSC::StatementNode::setNeedsDebugHook): Deleted.
3093         Move debug hook logic into the base Node class.
3094
3095         (JSC::StatementNode::isDebuggerStatement):
3096         Provide a way to distinguish a debugger statement.
3097
3098         * parser/Parser.cpp:
3099         (JSC::Parser<LexerType>::parseForStatement):
3100         Provide the location before the declaration starts.
3101
3102 2016-10-12  Mark Lam  <mark.lam@apple.com>
3103
3104         Array.prototype.slice should not modify frozen objects.
3105         https://bugs.webkit.org/show_bug.cgi?id=163338
3106
3107         Reviewed by Filip Pizlo.
3108
3109         1. The ES6 spec for Array.prototype.slice
3110            (https://tc39.github.io/ecma262/#sec-array.prototype.slice) states that it uses
3111            the CreateDataPropertyOrThrow()
3112            (https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow) to add items to
3113            the result array.  The spec for CreateDataPropertyOrThrow states:
3114
3115            "This abstract operation creates a property whose attributes are set to the
3116            same defaults used for properties created by the ECMAScript language assignment
3117            operator. Normally, the property will not already exist. If it does exist and
3118            is not configurable or if O is not extensible, [[DefineOwnProperty]] will
3119            return false causing this operation to throw a TypeError exception."
3120
3121         2. Array.prototype.slice also uses a Set function
3122            (https://tc39.github.io/ecma262/#sec-set-o-p-v-throw) to set the "length"
3123            property and passes true for the Throw argument.  Ultimately, it ends up
3124            calling the OrdinarySet function
3125            (https://tc39.github.io/ecma262/#sec-ordinaryset) that will fail if the
3126            property is not writable.  This failure should result in a TypeError being
3127            thrown in Set.
3128
3129            Since the properties of frozen objects are not extensible, not configurable,
3130            and not writeable, Array.prototype.slice should fail to write to the result
3131            array if it is frozen.
3132
3133         If the source array being sliced has 1 or more elements, (1) will take effect
3134         when we try to set the element in the non-writeable result obj.
3135         If the source array being sliced has 0 elements, we will not set any elements and
3136         (1) will not trigger.  Subsequently, (2) will take effect when we will try to
3137         set the length of the result obj.
3138
3139         * runtime/ArrayPrototype.cpp:
3140         (JSC::putLength):
3141         (JSC::setLength):
3142         (JSC::arrayProtoFuncSlice):
3143         (JSC::arrayProtoFuncSplice):
3144
3145 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
3146
3147         Remove JITWriteBarrier.h
3148         https://bugs.webkit.org/show_bug.cgi?id=163334
3149
3150         Reviewed by Mark Lam.
3151         
3152         I guess that the idea of JITWriteBarrier was to make sure that if you slap some heap pointer
3153         bits into machine code, then you better execute a barrier on the code block. But it's a
3154         complicated piece of code, and I can never remember how it quite works. These days it looks
3155         vestigial, particularly since only the CallLinkInfo patchable callee immediate uses it. It's
3156         not really necessary to have something like this, since our convention is that any pointer
3157         stored in machine code must always be shadowed in the GC heap. I think that convention has
3158         won by overwhelming majority, so we should finally remove JITWriteBarrier.
3159         
3160         A practical outcome of this change is that it makes it easier to implement DirectCall ICs,
3161         which will have to store the callee in the CallLinkInfo but not in the machine code.
3162
3163         * JavaScriptCore.xcodeproj/project.pbxproj:
3164         * assembler/AbstractMacroAssembler.h:
3165         * bytecode/CallLinkInfo.cpp:
3166         (JSC::CallLinkInfo::setCallee):
3167         (JSC::CallLinkInfo::clearCallee):
3168         * bytecode/CallLinkInfo.h:
3169         (JSC::CallLinkInfo::setCallee): Deleted.
3170         (JSC::CallLinkInfo::clearCallee): Deleted.
3171         * heap/SlotVisitor.h:
3172         * jit/JITWriteBarrier.h: Removed.
3173
3174 2016-10-12  Csaba Osztrogonác  <ossy@webkit.org>
3175
3176         Unreviewed buildfix for GCC 4.9 after r207186.
3177         https://bugs.webkit.org/show_bug.cgi?id=163255
3178
3179         * runtime/HasOwnPropertyCache.h:
3180         (JSC::HasOwnPropertyCache::Entry::Entry):
3181
3182 2016-10-11  Saam Barati  <sbarati@apple.com>
3183
3184         HasOwnPropertyCache needs to ref the UniquedStringImpls it sees
3185         https://bugs.webkit.org/show_bug.cgi?id=163255
3186
3187         Reviewed by Geoffrey Garen.
3188
3189         The cache needs to be responsible for ensuring that things
3190         in the cache stay alive. Before, it wasn't doing this, and
3191         that was wrong.
3192
3193         * runtime/HasOwnPropertyCache.h:
3194         (JSC::HasOwnPropertyCache::Entry::operator=):
3195         (JSC::HasOwnPropertyCache::operator delete):
3196         (JSC::HasOwnPropertyCache::create):
3197         (JSC::HasOwnPropertyCache::get):
3198         (JSC::HasOwnPropertyCache::tryAdd):
3199         (JSC::HasOwnPropertyCache::clear):
3200         (JSC::HasOwnPropertyCache::zeroBuffer):
3201
3202 2016-10-06  Filip Pizlo  <fpizlo@apple.com>
3203
3204         MarkedBlock should know what objects are live during marking
3205         https://bugs.webkit.org/show_bug.cgi?id=162309
3206
3207         Reviewed by Geoffrey Garen.
3208         
3209         It used to be that we would forget which objects are live the moment we started collection.
3210         That's because the flip at the beginning clears all mark bits.
3211         
3212         But we already have a facility for tracking objects that are live-but-not-marked. It's called
3213         newlyAllocated. So, instead of clearing mark bits, we want to just transfer them to
3214         newlyAllocated. Then we want to clear all newlyAllocated after GC.
3215         
3216         This implements such an approach, along with a versioning optimization for newlyAllocated.
3217         Instead of walking the whole heap to clear newlyAllocated bits at the end of the GC, we bump
3218         the newlyAllocatedVersion, which causes MarkedBlock to treat newlyAllocated as if it was
3219         clear.
3220         
3221         We could have even avoided allocating newlyAllocated in most cases, since empirically most
3222         blocks are either completely empty or completely full. An earlier version of this patch did
3223         this, but it was not better than this patch. In fact, it seemed to actually be worse for PLT
3224         and membuster.
3225         
3226         To validate this change, we now run the conservative scan after the beginMarking flip. And it
3227         totally works!
3228         
3229         This is a huge step towards concurrent GC. It means that we ought to be able to run the
3230         allocator while marking. Since we already separately made it possible to run the barrier
3231         while marking, this means that we're pretty much ready for some serious concurrency action.
3232         
3233         This appears to be perf-neutral and space-neutral.
3234
3235         * JavaScriptCore.xcodeproj/project.pbxproj:
3236         * bytecode/CodeBlock.cpp:
3237         * bytecode/CodeBlock.h:
3238         (JSC::CodeBlockSet::mark): Deleted.
3239         * heap/CodeBlockSet.cpp:
3240         (JSC::CodeBlockSet::writeBarrierCurrentlyExecuting):
3241         (JSC::CodeBlockSet::clearCurrentlyExecuting):
3242         (JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks): Deleted.
3243         * heap/CodeBlockSet.h:
3244         * heap/CodeBlockSetInlines.h: Added.
3245         (JSC::CodeBlockSet::mark):
3246         * heap/ConservativeRoots.cpp:
3247         * heap/Heap.cpp:
3248         (JSC::Heap::markRoots):
3249         (JSC::Heap::beginMarking):
3250         (JSC::Heap::collectImpl):
3251         (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
3252         (JSC::Heap::clearCurrentlyExecutingCodeBlocks):
3253         * heap/Heap.h:
3254         * heap/HeapUtil.h:
3255         (JSC::HeapUtil::findGCObjectPointersForMarking):
3256         * heap/MarkedAllocator.cpp:
3257         (JSC::MarkedAllocator::isPagedOut):
3258         * heap/MarkedBlock.cpp:
3259         (JSC::MarkedBlock::Handle::Handle):
3260         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
3261         (JSC::MarkedBlock::Handle::stopAllocating):
3262         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
3263         (JSC::MarkedBlock::Handle::resumeAllocating):
3264         (JSC::MarkedBlock::aboutToMarkSlow):
3265         (JSC::MarkedBlock::Handle::resetAllocated):
3266         (JSC::MarkedBlock::resetMarks):
3267         (JSC::MarkedBlock::setNeedsDestruction):
3268         (JSC::MarkedBlock::Handle::didAddToAllocator):
3269         (JSC::MarkedBlock::Handle::isLive):
3270         (JSC::MarkedBlock::Handle::isLiveCell):
3271         (JSC::MarkedBlock::clearMarks): Deleted.
3272         * heap/MarkedBlock.h:
3273         (JSC::MarkedBlock::Handle::newlyAllocatedVersion):
3274         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
3275         (JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
3276         * heap/MarkedBlockInlines.h:
3277         (JSC::MarkedBlock::Handle::cellsPerBlock):
3278         (JSC::MarkedBlock::Handle::isLive):
3279         (JSC::MarkedBlock::Handle::isLiveCell):
3280         (JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
3281         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocatedWithSweep):
3282         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
3283         (JSC::MarkedBlock::heap):
3284         (JSC::MarkedBlock::space):
3285         (JSC::MarkedBlock::Handle::space):
3286         (JSC::MarkedBlock::resetMarkingVersion): Deleted.
3287         * heap/MarkedSpace.cpp:
3288         (JSC::MarkedSpace::beginMarking):
3289         (JSC::MarkedSpace::endMarking):
3290         (JSC::MarkedSpace::clearNewlyAllocated): Deleted.