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