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