facf91cd2fd467b7bf0a972d075d1309210c1884
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
2
3         __cpuid() requires <intrin.h> to be included
4         https://bugs.webkit.org/show_bug.cgi?id=166051
5
6         Reviewed by Yusuke Suzuki.
7
8         * assembler/MacroAssemblerX86Common.h:
9
10 2016-12-19  Yusuke Suzuki  <utatane.tea@gmail.com>
11
12         [ES6] Enable ES6 Modules
13         https://bugs.webkit.org/show_bug.cgi?id=165849
14
15         Reviewed by Geoffrey Garen.
16
17         * features.json:
18
19 2016-12-19  Mark Lam  <mark.lam@apple.com>
20
21         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 2: Rollout r209952.
22         https://bugs.webkit.org/show_bug.cgi?id=166049
23
24         Not reviewed.
25
26         * bytecode/HandlerInfo.h:
27         (JSC::HandlerInfoBase::typeName):
28         * bytecompiler/BytecodeGenerator.cpp:
29         (JSC::BytecodeGenerator::generate):
30         (JSC::BytecodeGenerator::BytecodeGenerator):
31         (JSC::BytecodeGenerator::emitReturn):
32         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
33         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
34         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
35         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
36         (JSC::BytecodeGenerator::emitComplexPopScopes):
37         (JSC::BytecodeGenerator::emitPopScopes):
38         (JSC::BytecodeGenerator::pushTry):
39         (JSC::BytecodeGenerator::popTryAndEmitCatch):
40         (JSC::BytecodeGenerator::labelScopeDepth):
41         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
42         (JSC::BytecodeGenerator::popLocalControlFlowScope):
43         (JSC::BytecodeGenerator::emitEnumeration):
44         (JSC::BytecodeGenerator::emitYield):
45         (JSC::BytecodeGenerator::emitDelegateYield):
46         (JSC::BytecodeGenerator::popTry): Deleted.
47         (JSC::BytecodeGenerator::emitCatch): Deleted.
48         (JSC::BytecodeGenerator::restoreScopeRegister): Deleted.
49         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex): Deleted.
50         (JSC::BytecodeGenerator::emitIsNumber): Deleted.
51         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded): Deleted.
52         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded): Deleted.
53         (JSC::BytecodeGenerator::emitFinallyCompletion): Deleted.
54         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
55         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
56         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
57         * bytecompiler/BytecodeGenerator.h:
58         (JSC::BytecodeGenerator::isInFinallyBlock):
59         (JSC::FinallyJump::FinallyJump): Deleted.
60         (JSC::FinallyContext::FinallyContext): Deleted.
61         (JSC::FinallyContext::outerContext): Deleted.
62         (JSC::FinallyContext::finallyLabel): Deleted.
63         (JSC::FinallyContext::depth): Deleted.
64         (JSC::FinallyContext::numberOfBreaksOrContinues): Deleted.
65         (JSC::FinallyContext::incNumberOfBreaksOrContinues): Deleted.
66         (JSC::FinallyContext::handlesReturns): Deleted.
67         (JSC::FinallyContext::setHandlesReturns): Deleted.
68         (JSC::FinallyContext::registerJump): Deleted.
69         (JSC::FinallyContext::numberOfJumps): Deleted.
70         (JSC::FinallyContext::jumps): Deleted.
71         (JSC::ControlFlowScope::ControlFlowScope): Deleted.
72         (JSC::ControlFlowScope::isLabelScope): Deleted.
73         (JSC::ControlFlowScope::isFinallyScope): Deleted.
74         (JSC::BytecodeGenerator::currentLexicalScopeIndex): Deleted.
75         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
76         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
77         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
78         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
79         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
80         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
81         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
82         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
83         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
84         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
85         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
86         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
87         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
88         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
89         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
90         * bytecompiler/NodesCodegen.cpp:
91         (JSC::ContinueNode::emitBytecode):
92         (JSC::BreakNode::emitBytecode):
93         (JSC::ReturnNode::emitBytecode):
94         (JSC::TryNode::emitBytecode):
95
96 2016-12-19  Mark Lam  <mark.lam@apple.com>
97
98         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 1: Rollout r209974.
99         https://bugs.webkit.org/show_bug.cgi?id=166049
100
101         Not reviewed.
102
103         * bytecompiler/BytecodeGenerator.cpp:
104         (JSC::BytecodeGenerator::emitEnumeration):
105         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
106         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
107         (JSC::BytecodeGenerator::emitFinallyCompletion):
108         (JSC::BytecodeGenerator::allocateFinallyRegisters):
109         (JSC::BytecodeGenerator::releaseFinallyRegisters):
110         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
111         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
112         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
113         (JSC::BytecodeGenerator::emitJumpIfCompletionType): Deleted.
114         * bytecompiler/BytecodeGenerator.h:
115         (JSC::FinallyJump::FinallyJump):
116         (JSC::FinallyContext::registerJump):
117         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
118         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
119         (JSC::BytecodeGenerator::finallyActionRegister):
120         (JSC::BytecodeGenerator::finallyReturnValueRegister):
121         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
122         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
123         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
124         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
125         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
126         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
127         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
128         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
129         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
130         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
131         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
132         (JSC::bytecodeOffsetToJumpID): Deleted.
133         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
134         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
135         (JSC::BytecodeGenerator::completionTypeRegister): Deleted.
136         (JSC::BytecodeGenerator::completionValueRegister): Deleted.
137         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
138         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
139         * bytecompiler/NodesCodegen.cpp:
140         (JSC::TryNode::emitBytecode):
141
142 2016-12-19  Joseph Pecoraro  <pecoraro@apple.com>
143
144         Web Inspector: Assertion seen in InspectorDebuggerAgent::refAsyncCallData with Inspector open
145         https://bugs.webkit.org/show_bug.cgi?id=166034
146         <rdar://problem/29554366>
147
148         Reviewed by Brian Burg.
149
150         * inspector/agents/InspectorDebuggerAgent.cpp:
151         (Inspector::InspectorDebuggerAgent::refAsyncCallData):
152         Remove assertion. This assert can happen if the currently executing callback
153         was just explicitly cancelled by script. Existing code already handles if
154         no async data was found for the given identifier.
155
156 2016-12-18  Saam Barati  <sbarati@apple.com>
157
158         WebAssembly: Implement the WebAssembly.compile and WebAssembly.validate
159         https://bugs.webkit.org/show_bug.cgi?id=165936
160
161         Reviewed by Mark Lam.
162
163         The APIs are documented here:
164         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile
165         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyvalidate
166
167         * wasm/JSWebAssembly.cpp:
168         (JSC::webAssemblyCompileFunc):
169         (JSC::webAssemblyValidateFunc):
170         (JSC::JSWebAssembly::finishCreation):
171         * wasm/WasmPlan.cpp:
172         (JSC::Wasm::Plan::parseAndValidateModule):
173         (JSC::Wasm::Plan::run):
174         * wasm/WasmPlan.h:
175         * wasm/js/JSWebAssemblyHelpers.h:
176         (JSC::getWasmBufferFromValue):
177         * wasm/js/WebAssemblyModuleConstructor.cpp:
178         (JSC::constructJSWebAssemblyModule):
179         (JSC::callJSWebAssemblyModule):
180         (JSC::WebAssemblyModuleConstructor::createModule):
181         * wasm/js/WebAssemblyModuleConstructor.h:
182
183 2016-12-18  Mark Lam  <mark.lam@apple.com>
184
185         Rename finallyActionRegister to completionTypeRegister and only store int JSValues in it.
186         https://bugs.webkit.org/show_bug.cgi?id=165979
187
188         Reviewed by Saam Barati.
189
190         This patch makes it so that we only store int JSValues in the finallyActionRegister
191         thereby making type prediction on this register more successful for JITs.  In so
192         doing, we are able to get some additional benefits:
193
194         1. Renamed the following:
195            FinallyRegistersScope => CompletionRecordScope
196            finallyActionRegister => completionTypeRegister
197            finallyReturnValueRegister => completionValueRegister
198
199            These new names are more in line with the ES spec, which describes these
200            values as the completion record and its type and value properties.
201            https://tc39.github.io/ecma262/#sec-completion-record-specification-type
202
203         2. We now think of the Break and Continue jumpIDs as encodings of CompletionType
204            (in our implementation of completion type).  As a result, we only need one of
205            each of the emitter methods for getting, setting, and compare-and-jump on the
206            completion type.  The code using these methods also reads much clearer now.  
207
208         3. Finally blocks' op_catch should now always pop the caught Exception object into
209            the completionValueRegister instead of the completionTypeRegister (formerly
210            finallyActionRegister). 
211
212         Also removed the restoreScopeRegister() call in the IteratorClose catch block
213         because that is an implementation specific synthesized catch block, and we
214         can guarantee that it never needs to resolve any symbols from the scope.  Hence,
215         there is no need to restore the scope register.
216
217         * bytecompiler/BytecodeGenerator.cpp:
218         (JSC::BytecodeGenerator::emitEnumeration):
219         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
220         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
221         (JSC::BytecodeGenerator::emitFinallyCompletion):
222         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
223         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
224         (JSC::BytecodeGenerator::emitJumpIfCompletionType):
225         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
226         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
227         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
228         * bytecompiler/BytecodeGenerator.h:
229         (JSC::bytecodeOffsetToJumpID):
230         (JSC::FinallyJump::FinallyJump):
231         (JSC::FinallyContext::registerJump):
232         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
233         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
234         (JSC::BytecodeGenerator::completionTypeRegister):
235         (JSC::BytecodeGenerator::completionValueRegister):
236         (JSC::BytecodeGenerator::emitSetCompletionType):
237         (JSC::BytecodeGenerator::emitSetCompletionValue):
238         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
239         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
240         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
241         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
242         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
243         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
244         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
245         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
246         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
247         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
248         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
249         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
250         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
251         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
252         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
253         * bytecompiler/NodesCodegen.cpp:
254         (JSC::TryNode::emitBytecode):
255
256 2016-12-17  Saam Barati  <sbarati@apple.com>
257
258         WebAssembly: WasmB3IRGenerator uses WarmAny as a ValueRep but expects the incoming value to be a register
259         https://bugs.webkit.org/show_bug.cgi?id=165989
260
261         Reviewed by Mark Lam.
262
263         The input should be constrained to a register to match what
264         the patchpoint code expects.
265
266         * wasm/WasmB3IRGenerator.cpp:
267
268 2016-12-17  Saam Barati  <sbarati@apple.com>
269
270         WebAssembly: Change a RELEASE_ASSERT_NOT_REACHED to a jit.breakpoint() for now to allow us to run some wasm benchmarks
271         https://bugs.webkit.org/show_bug.cgi?id=165990
272
273         Reviewed by Mark Lam.
274
275         * wasm/WasmBinding.cpp:
276         (JSC::Wasm::importStubGenerator):
277
278 2016-12-16  Joseph Pecoraro  <pecoraro@apple.com>
279
280         JSContext Inspector: Avoid some possible exceptions inspecting a JSContext
281         https://bugs.webkit.org/show_bug.cgi?id=165986
282         <rdar://problem/29551379>
283
284         Reviewed by Matt Baker.
285
286         * inspector/InjectedScriptSource.js:
287         (InjectedScript.prototype.processProperties):
288         Prefer String.prototype.endsWith now that it is available.
289
290         (InjectedScript.prototype._describe):
291         Prefer Function.prototype.toString for converting functions to String.
292         Previously we were doing String(f) which would to Symbol.toPrimitive
293         conversion which seems unnecessary here.
294
295 2016-12-16  Michael Catanzaro  <mcatanzaro@igalia.com>
296
297         Unreviewed, fix GCC 6 build failure after r209952
298
299         Return false, not nullptr, in function returning bool.
300
301         * bytecompiler/BytecodeGenerator.cpp:
302         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
303
304 2016-12-16  Saam Barati  <sbarati@apple.com>
305
306         WebAssembly: We still have some incorrect parsing productions inside unreachable code
307         https://bugs.webkit.org/show_bug.cgi?id=165981
308
309         Reviewed by Keith Miller.
310
311         This hardens our parsing for CallIndirect and Loop/Block/If to be exactly like their reachable variant.
312         
313         It also fixes a more nefarious bug in which we were decoding an extra varuint32
314         for Br/BrIf inside unreachable code.
315
316         * wasm/WasmFunctionParser.h:
317
318 2016-12-16  Filip Pizlo  <fpizlo@apple.com>
319
320         CellState should have members with accurate names
321         https://bugs.webkit.org/show_bug.cgi?id=165969
322
323         Reviewed by Mark Lam.
324         
325         This once again renames the members in CellState. I wanted to convey the following
326         pieces of information in the names:
327         
328         - What does the state mean for Generational GC?
329         - What does the state mean for Concurrent GC?
330         - Does the state guarantee what it means, or is there some contingency?
331         
332         The names I came up with are:
333         
334         PossiblyOldOrBlack: An object in this state may be old, or may be black, depending on
335             other things. If the mark bit is set then the object is either black or being
336             blackened as we speak. It's going to survive the GC, so it will be old, but may be
337             new now. In between GCs, objects in this state are definitely old. If the mark bit
338             is not set, then the object is actually old and white.
339         
340         DefinitelyNewAndWhite: The object was just allocated so it is white (not marked) and
341             new.
342         
343         DefinitelyGrey: The object is definitely grey - it will be rescanned in the future. It
344             may be new or old depending on other things.
345
346         * heap/CellState.h:
347         * heap/Heap.cpp:
348         (JSC::Heap::addToRememberedSet):
349         (JSC::Heap::writeBarrierSlowPath):
350         * heap/SlotVisitor.cpp:
351         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
352         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
353         (JSC::SlotVisitor::appendToMarkStack):
354         (JSC::SlotVisitor::visitChildren):
355         * runtime/JSCellInlines.h:
356         (JSC::JSCell::JSCell):
357         * runtime/StructureIDBlob.h:
358         (JSC::StructureIDBlob::StructureIDBlob):
359
360 2016-12-16  Saam Barati  <sbarati@apple.com>
361
362         B3::DoubleToFloatReduction will accidentally convince itself it converted a Phi from Double to Float and then convert uses of that Phi into a use of FloatToDouble(@Phi)
363         https://bugs.webkit.org/show_bug.cgi?id=165946
364
365         Reviewed by Keith Miller.
366
367         This was happening because the phase will convert some Phi nodes
368         from Double to Float. However, one place that did this conversion
369         forgot to first check if the Phi was already a Float. If it's already
370         a Float, a later part of the phase will be buggy if the phase claims that it has
371         converted it from Double->Float. The reason is that at the end of the
372         phase, we'll look for all uses of former Double Phi nodes and make them
373         be a use of ConvertFloatToDouble on the Phi, instead of a use of the Phi itself.
374         This is clearly wrong if the Phi were Float to begin with (and
375         therefore, the uses were Float uses to begin with).
376
377         * b3/B3ReduceDoubleToFloat.cpp:
378         * b3/testb3.cpp:
379         (JSC::B3::testReduceFloatToDoubleValidates):
380         (JSC::B3::run):
381
382 2016-12-16  Mark Lam  <mark.lam@apple.com>
383
384         De-duplicate finally blocks.
385         https://bugs.webkit.org/show_bug.cgi?id=160168
386
387         Reviewed by Keith Miller.
388
389         JS execution can arrive at a finally block when there are abrupt completions from
390         its try or catch block.  The abrupt completion types include Break,
391         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
392         (i.e. the case of a try block falling through to the finally block).
393
394         Previously, we enable each of these paths for abrupt completion (except for Throw)
395         to run the finally block code by duplicating the finally block code at each of
396         the sites that trigger those completions.  This patch fixes the implementation so
397         that each of these abrupt completions will set a finallyActionRegister (plus a
398         finallyReturnValueRegister for CompletionType::Return) and then jump to the
399         relevant finally blocks, and continue to thread through subsequent outer finally
400         blocks until execution reaches the outermost finally block that the completion
401         type dictates.  We no longer duplicate the finally block code.
402
403         The implementation details:
404         1. We allocate a pair of finallyActionRegister and finallyReturnValueRegister
405            just before entering the outermost try-catch-finally scope.
406
407            On allocating the registers, we set them to the empty JSValue.  This serves
408            to set the completion type to CompletionType::Normal (see (2) below).
409
410         2. The finallyActionRegister serves 2 purpose:
411            a. indicates the CompletionType that triggered entry into the finally block.
412
413               This is how we encode the completion type in the finallyActionRegister:
414               1. CompletionType::Normal
415                  - finallyActionRegister is set to the empty JSValue.
416               2. CompletionType::Break
417                  - finallyActionRegister is set to the int jumpID for the site of the break statement.
418               3. CompletionType::Continue
419                  - finallyActionRegister is set to the int jumpID for the site of the continue statement.
420               4. CompletionType::Return
421                  - finallyActionRegister is set to CompletionType::Return as an int JSValue.
422                  - finallyReturnValueRegister is set to the value to be returned. 
423               5. CompletionType::Throw
424                  - finallyActionRegister is set to the exception object that was caught by the finally block.
425
426               Hence, if the finallyActionRegister can either be:
427               1. empty i.e. we're handling CompletionType::Normal.
428               2. an int JSValue i.e. we're handling CompletionType::Break, Continue, or Return.
429               3. an object i.e. we're handling CompletionType::Throw.
430
431            b. stores the exception caught in the finally block if we're handing
432               CompletionType::Throw.
433
434         3. Each finally block will have 2 entries:
435            a. the entry via throw.
436            b. the normal entry.
437
438            The entry via throw is recorded in the codeBlock's exception table, and can
439            only be jumped to by the VM's exception handling mechanism.
440
441            The normal entry is recorded in a FinallyContext (at bytecode generation time
442            only) and is jumped to when we want enter the finally block due any of the
443            other CompletionTypes.
444
445         4. CompletionType::Normal
446            ======================
447            We encounter this when falling through from a try or catch block to the finally block.  
448            
449            For the try block case, since finallyActionRegister is set to Normal by default,
450            there's nothing more that needs to be done.
451
452            For the catch block case, since we entered the catch block with an exception,
453            finallyActionRegister may be set to Throw.  We'll need to set it to Normal
454            before jumping to the finally block's normal entry.
455
456            CompletionType::Break
457            =====================
458            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
459            that we need to service before jumping to the breakTarget.  If we do, then:
460            a. we'll register a jumpID along with the breakTarget with the outermost FinallyContext.
461            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
462               from the innermost to the outermost.
463            c. instead of emitting bytecode to jump to the breakTarget, we:
464               1. emit bytecode to set finallyActionRegister to the jumpID.
465               b. emit bytecode to jump to the normal entry of the innermost finally block.
466
467            Each finally block will take care of cascading to the next outer finally block
468            as needed (see (5) below).
469
470            CompletionType::Continue
471            ========================
472            Since continues and breaks work the same way (i.e. with a jump), we handle this
473            exactly the same way as CompletionType::Break, except that we use the
474            continueTarget instead of the breakTarget.
475
476            CompletionType::Return
477            ======================
478            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
479            at all on the m_controlFlowScopeStack.
480
481            If so, then instead of emitting op_ret, we:
482               1. emit bytecode to set finallyActionRegister to the CompletionType::Return.
483               1. emit bytecode to move the return value into finallyReturnValueRegister.
484               2. emit bytecode to jump to the normal entry of the innermost finally block.
485
486            Each finally block will take care of cascading to the next outer finally block
487            as needed (see (5) below).
488
489            CompletionType::Throw
490            ======================
491            The op_catch of a finally block will always store the caught exception object
492            in the finallyActionRegister.  This means we're handling CompletionType::Throw
493            (see (2) above).
494
495         5. What happens in each finally block?
496            ==================================
497            Only the finally block's entry via throw will have an op_catch that catches the
498            pending exception (and stores it in the finallyActionRegister).  This throw
499            entry then falls through to the normal entry.
500
501            The finally block's normal entry will restore the scope of the finally block
502            and proceed to execute its code.
503
504            At the end of the finally block (see emitFinallyCompletion()), the finally
505            block will check the finallyActionRegister for each completion type in the
506            following order:
507            
508            a. CompletionType::Normal: jump to the code after the finally block as
509               designated by a normalCompletion label.
510
511            b. CompletionType::Break and Continue:
512               If the FinallyContext for this block has registered FinallyJumps, we'll
513               check for the jumpIDs against the finallyActionRegister.  If the jumpID
514               matches, jump to the corresponding jumpTarget.
515
516               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
517               greater than the number of registered FinallyJumps, then this means that
518               we have a Break or Continue that needs to be handled by an outer finally
519               block.  In that case, jump to the outer finally block's normal entry.
520               
521            c. CompletionType::Return:
522               If this finally block is not the outermost and finallyActionRegister contains
523               CompletionType::Return, then jump to the outer finally block's normal entry.
524
525               Otherwise, if this finally block is the outermost and finallyActionRegister
526               contains CompletionType::Return, then execute op_ret and return the value
527               in finallyReturnValueRegister.
528
529            d. CompletionType::Throw:
530               If we're not handling any of the above cases, then just throw the
531               finallyActionRegister which contains the exception to re-throw.
532
533         6. restoreScopeRegister()
534         
535            Since the needed scope objects are always stored in a local, we can restore
536            the scope register by simply moving from that local instead of going through
537            op_get_parent_scope.
538
539         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
540            This makes it easier to keep a pointer to the FinallyContext on that stack,
541            and not have to worry about the vector being realloc'ed due to resizing. 
542
543         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
544         JSC benchmarks.
545
546         Relevant spec references:
547         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
548         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
549
550         * bytecode/HandlerInfo.h:
551         (JSC::HandlerInfoBase::typeName):
552         * bytecompiler/BytecodeGenerator.cpp:
553         (JSC::BytecodeGenerator::generate):
554         (JSC::BytecodeGenerator::BytecodeGenerator):
555         (JSC::BytecodeGenerator::emitReturn):
556         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
557         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
558         (JSC::BytecodeGenerator::allocateAndEmitScope):
559         (JSC::BytecodeGenerator::pushTry):
560         (JSC::BytecodeGenerator::popTry):
561         (JSC::BytecodeGenerator::emitCatch):
562         (JSC::BytecodeGenerator::restoreScopeRegister):
563         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
564         (JSC::BytecodeGenerator::labelScopeDepth):
565         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
566         (JSC::BytecodeGenerator::popLocalControlFlowScope):
567         (JSC::BytecodeGenerator::emitEnumeration):
568         (JSC::BytecodeGenerator::emitIsNumber):
569         (JSC::BytecodeGenerator::emitYield):
570         (JSC::BytecodeGenerator::emitDelegateYield):
571         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
572         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
573         (JSC::BytecodeGenerator::emitFinallyCompletion):
574         (JSC::BytecodeGenerator::allocateFinallyRegisters):
575         (JSC::BytecodeGenerator::releaseFinallyRegisters):
576         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
577         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
578         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
579         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
580         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
581         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
582         * bytecompiler/BytecodeGenerator.h:
583         (JSC::FinallyJump::FinallyJump):
584         (JSC::FinallyContext::FinallyContext):
585         (JSC::FinallyContext::outerContext):
586         (JSC::FinallyContext::finallyLabel):
587         (JSC::FinallyContext::depth):
588         (JSC::FinallyContext::numberOfBreaksOrContinues):
589         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
590         (JSC::FinallyContext::handlesReturns):
591         (JSC::FinallyContext::setHandlesReturns):
592         (JSC::FinallyContext::registerJump):
593         (JSC::FinallyContext::numberOfJumps):
594         (JSC::FinallyContext::jumps):
595         (JSC::ControlFlowScope::ControlFlowScope):
596         (JSC::ControlFlowScope::isLabelScope):
597         (JSC::ControlFlowScope::isFinallyScope):
598         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
599         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
600         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
601         (JSC::BytecodeGenerator::finallyActionRegister):
602         (JSC::BytecodeGenerator::finallyReturnValueRegister):
603         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
604         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
605         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
606         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
607         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
608         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
609         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
610         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
611         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
612         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
613         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
614         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
615         * bytecompiler/NodesCodegen.cpp:
616         (JSC::ContinueNode::emitBytecode):
617         (JSC::BreakNode::emitBytecode):
618         (JSC::ReturnNode::emitBytecode):
619         (JSC::TryNode::emitBytecode):
620
621 2016-12-16  Keith Miller  <keith_miller@apple.com>
622
623         Add missing cases to parseUnreachableExpression and cleanup FunctionParser
624         https://bugs.webkit.org/show_bug.cgi?id=165966
625
626         Reviewed by Saam Barati.
627
628         This patch adds a number of missing cases to the Wasm FunctionParser's unreachable
629         code decoder. It also, removes unneeded OpType namespaces where they were not
630         needed and has the unary / binary macros cover all the cases rather than
631         just the simple cases.
632
633         * wasm/WasmFunctionParser.h:
634
635 2016-12-16  Mark Lam  <mark.lam@apple.com>
636
637         Add predecessor info to dumps from JSC_dumpBytecodeLivenessResults=true.
638         https://bugs.webkit.org/show_bug.cgi?id=165958
639
640         Reviewed by Saam Barati.
641
642         Also:
643         1. refactored the code to use a common lambda function to dump FastBitVectors.
644         2. list successors by their block index instead of pointers.
645
646         * bytecode/BytecodeLivenessAnalysis.cpp:
647         (JSC::BytecodeLivenessAnalysis::dumpResults):
648
649 2016-12-16  Saam Barati  <sbarati@apple.com>
650
651         WebAssembly: WasmB3IRGenerator should throw exceptions instead of crash
652         https://bugs.webkit.org/show_bug.cgi?id=165834
653
654         Reviewed by Keith Miller.
655
656         This patch generalizes how we throw exceptions in the Wasm::B3IRGenerator.
657         There are still places where we need to throw exceptions and we don't, but
658         this patch removes most of those places inside the IR generator. There are
659         still a few places we need to throw exceptions inside the IR generator, like
660         div/mod by 0. Those will be done in a separate patch. Also, there are
661         still some stubs we need to throw exceptions from; those will also be
662         done in a separate patch.
663
664         All exceptions thrown from Wasm share a common stub. The ABI for the stub
665         is to move the Wasm::ExceptionType into argGPR1 and jump to the stub.
666         The stub will then throw an exception with an error message tailored
667         to the particular Wasm::ExceptionType failure.
668
669         This patch also refactors B3::Compilation. Before, B3::Compilation(VM, Procedure)
670         constructor would compile a B3 function. This patch makes B3::Compilation a simple 
671         tuple that keeps the necessary bits of B3 function alive in order to be runnable.
672         There is a new function that actually does the compilation for you. It is:
673         Compilation B3::compile(VM&, Procedure&)
674         The reason for this change is that I'm now using B3::Compilation(CodeRef, OpaqueByproducts)
675         constructor in Wasm code. It is weird to have a class both have a
676         constructor that instantiates the tuple, and another that performs the
677         compilation and then instantiates the tuple. It's more straight
678         forward if Compilation's job wasn't to actually do the compilation
679         but just to hold the necessary bits to keep a compiled B3 alive.
680
681         * CMakeLists.txt:
682         * JavaScriptCore.xcodeproj/project.pbxproj:
683         * b3/B3Compilation.cpp:
684         (JSC::B3::Compilation::Compilation):
685         * b3/B3Compilation.h:
686         * b3/B3Compile.cpp: Added.
687         (JSC::B3::compile):
688         * b3/B3Compile.h: Added.
689         * b3/testb3.cpp:
690         (JSC::B3::compile):
691         * jit/ThunkGenerators.cpp:
692         (JSC::throwExceptionFromWasmThunkGenerator):
693         * jit/ThunkGenerators.h:
694         * wasm/WasmB3IRGenerator.cpp:
695         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
696         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
697         (JSC::Wasm::createJSToWasmWrapper):
698         (JSC::Wasm::parseAndCompile):
699         * wasm/WasmExceptionType.h: Added.
700         (JSC::Wasm::errorMessageForExceptionType):
701
702 2016-12-16  Keith Miller  <keith_miller@apple.com>
703
704         i64.eqz should use an Int64 zero
705         https://bugs.webkit.org/show_bug.cgi?id=165942
706
707         Reviewed by Mark Lam.
708
709         This patch fixes i64.eqz, which was using an Int32 zero
710         for the comparison previously. This patch also, adds
711         printing opcodes names in verbose mode.
712
713         * wasm/WasmFunctionParser.h:
714         * wasm/generateWasmOpsHeader.py:
715         * wasm/wasm.json:
716
717 2016-12-15  Darin Adler  <darin@apple.com>
718
719         Use asString instead of toWTFString, toString, or getString when we already checked isString
720         https://bugs.webkit.org/show_bug.cgi?id=165895
721
722         Reviewed by Yusuke Suzuki.
723
724         Once we have called isString, we should always use asString and value rather than using
725         functions that have to deal with non-JSString objects. This leads to slightly fewer branches,
726         slightly less reference count churn, since the string is stored right inside the JSString,
727         and obviates the need for exception handling.
728
729         * bindings/ScriptValue.cpp:
730         (Inspector::jsToInspectorValue): Use asString/value instead of getString.
731         * dfg/DFGOperations.cpp:
732         (JSC::DFG::operationMapHash): Call jsMapHash with its new arguments.
733         * inspector/JSInjectedScriptHost.cpp:
734         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Use asString/value instead
735         of toWTFString.
736         * inspector/JSJavaScriptCallFrame.cpp:
737         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Ditto.
738         * inspector/agents/InspectorHeapAgent.cpp:
739         (Inspector::InspectorHeapAgent::getPreview): Use asString/tryGetValue, instead of the
740         peculiar getString(nullptr) that was here before.
741         * jsc.cpp:
742         (functionGetGetterSetter): Use asString/toIdentifier instead of the much less efficient
743         toWTFString/Identifier::fromString.
744         (functionIsRope): Use asString instead of jsCast<JSString*>; same thing, but we should
745         prefer the asString function, since it exists.
746         (functionFindTypeForExpression): Use asString/value instead of getString.
747         (functionHasBasicBlockExecuted): Ditto.
748         (functionBasicBlockExecutionCount): Ditto.
749         (functionCreateBuiltin): Use asString/value instead of toWTFString and removed
750         unneeded RETURN_IF_EXCEPTION.
751         (valueWithTypeOfWasmValue): Use asString instead of jsCast<String*>.
752         (box): Ditto.
753         * runtime/DateConstructor.cpp:
754         (JSC::constructDate): Use asString/values instead of getString.
755         * runtime/ExceptionHelpers.cpp:
756         (JSC::errorDescriptionForValue): Tweaked formatting.
757
758         * runtime/HashMapImpl.h:
759         (JSC::jsMapHash): Changed this function to use asString/value.
760
761         * runtime/JSCJSValue.cpp:
762         (JSC::JSValue::dumpInContextAssumingStructure): Use asString instead of
763         jsCast<JSString*>.
764         (JSC::JSValue::dumpForBacktrace): Ditto.
765         * runtime/JSCJSValueInlines.h:
766         (JSC::toPreferredPrimitiveType): Ditto.
767
768         * runtime/JSGlobalObjectFunctions.cpp:
769         (JSC::globalFuncEval): Use asString/value instead of toWTFString.
770
771         * runtime/JSString.cpp:
772         (JSC::JSString::destroy): Streamlined by removing local variable.
773         (JSC::JSString::estimatedSize): Use asString instead of jsCast<JSString*>.
774         (JSC::JSString::visitChildren): Ditto.
775         (JSC::JSString::toThis): Ditto.
776         * runtime/JSString.h:
777         (JSC::JSValue::toString): Ditto.
778         (JSC::JSValue::toStringOrNull): Ditto.
779         * runtime/NumberPrototype.cpp:
780         (JSC::numberProtoFuncValueOf): Ditto.
781         * runtime/ObjectPrototype.cpp:
782         (JSC::objectProtoFuncToString): Ditto.
783         * runtime/StringPrototype.cpp:
784         (JSC::stringProtoFuncRepeatCharacter): Ditto.
785         (JSC::stringProtoFuncSubstr): Ditto.
786         (JSC::builtinStringSubstrInternal): Simplified assertion by removing local variable.
787
788 2016-12-15  Keith Miller  <keith_miller@apple.com>
789
790         Fix validation of non-void if blocks with no else
791         https://bugs.webkit.org/show_bug.cgi?id=165938
792
793         Reviewed by Saam Barati.
794
795         We should not have been allowing non-void if-blocks that don't
796         have an else. Since this causes a value to be placed on the
797         stack that only appears under some control flow and not another.
798
799         * wasm/WasmValidate.cpp:
800
801 2016-12-15  Filip Pizlo  <fpizlo@apple.com>
802
803         Get rid of HeapRootVisitor and make SlotVisitor less painful to use
804         https://bugs.webkit.org/show_bug.cgi?id=165911
805
806         Reviewed by Geoffrey Garen.
807         
808         Previously we had two ways of adding a raw pointer to the GC's mark stack:
809         
810         - SlotVisitor::appendUnbarrieredXYZ() methods
811         - HeapRootVisitor::visit() methods
812         
813         HeapRootVisitor existed only to prevent you from calling its non-WriteBarrier<> methods
814         unless you had permission. But SlotVisitor would let you do it anyway, because that was
815         a lot more practical.
816         
817         I think that we should just have one way to do it. This removes HeapRootVisitor. It
818         also renames appendUnbarrieredXYZ to appendUnbarriered, and it removes the use of extra
819         indirection (so you now pass const WriteBarrier<>& instead of WriteBarrier<>*).
820
821         * API/JSCallbackObject.h:
822         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
823         * JavaScriptCore.xcodeproj/project.pbxproj:
824         * Scripts/builtins/builtins_templates.py:
825         * bytecode/CodeBlock.cpp:
826         (JSC::CodeBlock::visitWeakly):
827         (JSC::CodeBlock::visitChildren):
828         (JSC::CodeBlock::propagateTransitions):
829         (JSC::CodeBlock::determineLiveness):
830         (JSC::CodeBlock::visitOSRExitTargets):
831         (JSC::CodeBlock::stronglyVisitStrongReferences):
832         (JSC::CodeBlock::stronglyVisitWeakReferences):
833         * bytecode/DirectEvalCodeCache.cpp:
834         (JSC::DirectEvalCodeCache::visitAggregate):
835         * bytecode/InternalFunctionAllocationProfile.h:
836         (JSC::InternalFunctionAllocationProfile::visitAggregate):
837         * bytecode/ObjectAllocationProfile.h:
838         (JSC::ObjectAllocationProfile::visitAggregate):
839         * bytecode/PolymorphicAccess.cpp:
840         (JSC::AccessCase::propagateTransitions):
841         * bytecode/UnlinkedCodeBlock.cpp:
842         (JSC::UnlinkedCodeBlock::visitChildren):
843         * bytecode/UnlinkedFunctionExecutable.cpp:
844         (JSC::UnlinkedFunctionExecutable::visitChildren):
845         * debugger/DebuggerScope.cpp:
846         (JSC::DebuggerScope::visitChildren):
847         * dfg/DFGDesiredTransitions.cpp:
848         (JSC::DFG::DesiredTransition::visitChildren):
849         * dfg/DFGDesiredWeakReferences.cpp:
850         (JSC::DFG::DesiredWeakReferences::visitChildren):
851         * dfg/DFGGraph.cpp:
852         (JSC::DFG::Graph::visitChildren):
853         * dfg/DFGPlan.cpp:
854         (JSC::DFG::Plan::markCodeBlocks):
855         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
856         * heap/HandleSet.cpp:
857         (JSC::HandleSet::visitStrongHandles):
858         * heap/HandleSet.h:
859         * heap/HandleStack.cpp:
860         (JSC::HandleStack::visit):
861         * heap/HandleStack.h:
862         * heap/Heap.cpp:
863         (JSC::Heap::markToFixpoint):
864         * heap/Heap.h:
865         * heap/HeapRootVisitor.h: Removed.
866         * heap/LargeAllocation.cpp:
867         (JSC::LargeAllocation::visitWeakSet):
868         * heap/LargeAllocation.h:
869         * heap/MarkedBlock.h:
870         (JSC::MarkedBlock::Handle::visitWeakSet):
871         * heap/MarkedSpace.cpp:
872         (JSC::MarkedSpace::visitWeakSets):
873         * heap/MarkedSpace.h:
874         * heap/SlotVisitor.cpp:
875         (JSC::SlotVisitor::appendUnbarriered):
876         * heap/SlotVisitor.h:
877         * heap/SlotVisitorInlines.h:
878         (JSC::SlotVisitor::appendUnbarriered):
879         (JSC::SlotVisitor::append):
880         (JSC::SlotVisitor::appendHidden):
881         (JSC::SlotVisitor::appendValues):
882         (JSC::SlotVisitor::appendValuesHidden):
883         (JSC::SlotVisitor::appendUnbarrieredPointer): Deleted.
884         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer): Deleted.
885         (JSC::SlotVisitor::appendUnbarrieredValue): Deleted.
886         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Deleted.
887         (JSC::SlotVisitor::appendUnbarrieredWeak): Deleted.
888         * heap/WeakBlock.cpp:
889         (JSC::WeakBlock::specializedVisit):
890         (JSC::WeakBlock::visit):
891         * heap/WeakBlock.h:
892         * heap/WeakSet.h:
893         (JSC::WeakSet::visit):
894         * interpreter/ShadowChicken.cpp:
895         (JSC::ShadowChicken::visitChildren):
896         * jit/GCAwareJITStubRoutine.cpp:
897         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
898         * jit/PolymorphicCallStubRoutine.cpp:
899         (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
900         * jsc.cpp:
901         (WTF::Element::visitChildren):
902         (WTF::ImpureGetter::visitChildren):
903         (WTF::SimpleObject::visitChildren):
904         * runtime/AbstractModuleRecord.cpp:
905         (JSC::AbstractModuleRecord::visitChildren):
906         * runtime/ArgList.cpp:
907         (JSC::MarkedArgumentBuffer::markLists):
908         * runtime/ArgList.h:
909         * runtime/ClonedArguments.cpp:
910         (JSC::ClonedArguments::visitChildren):
911         * runtime/DirectArguments.cpp:
912         (JSC::DirectArguments::visitChildren):
913         * runtime/EvalExecutable.cpp:
914         (JSC::EvalExecutable::visitChildren):
915         * runtime/Exception.cpp:
916         (JSC::Exception::visitChildren):
917         * runtime/FunctionExecutable.cpp:
918         (JSC::FunctionExecutable::visitChildren):
919         * runtime/FunctionRareData.cpp:
920         (JSC::FunctionRareData::visitChildren):
921         * runtime/GetterSetter.cpp:
922         (JSC::GetterSetter::visitChildren):
923         * runtime/HashMapImpl.cpp:
924         (JSC::HashMapBucket<Data>::visitChildren):
925         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
926         * runtime/InferredTypeTable.cpp:
927         (JSC::InferredTypeTable::visitChildren):
928         * runtime/InternalFunction.cpp:
929         (JSC::InternalFunction::visitChildren):
930         * runtime/IntlCollator.cpp:
931         (JSC::IntlCollator::visitChildren):
932         * runtime/IntlCollatorConstructor.cpp:
933         (JSC::IntlCollatorConstructor::visitChildren):
934         * runtime/IntlDateTimeFormat.cpp:
935         (JSC::IntlDateTimeFormat::visitChildren):
936         * runtime/IntlDateTimeFormatConstructor.cpp:
937         (JSC::IntlDateTimeFormatConstructor::visitChildren):
938         * runtime/IntlNumberFormat.cpp:
939         (JSC::IntlNumberFormat::visitChildren):
940         * runtime/IntlNumberFormatConstructor.cpp:
941         (JSC::IntlNumberFormatConstructor::visitChildren):
942         * runtime/JSBoundFunction.cpp:
943         (JSC::JSBoundFunction::visitChildren):
944         * runtime/JSCallee.cpp:
945         (JSC::JSCallee::visitChildren):
946         * runtime/JSCellInlines.h:
947         (JSC::JSCell::visitChildren):
948         * runtime/JSCustomGetterSetterFunction.cpp:
949         (JSC::JSCustomGetterSetterFunction::visitChildren):
950         * runtime/JSFunction.cpp:
951         (JSC::JSFunction::visitChildren):
952         * runtime/JSGlobalObject.cpp:
953         (JSC::JSGlobalObject::visitChildren):
954         * runtime/JSMapIterator.cpp:
955         (JSC::JSMapIterator::visitChildren):
956         * runtime/JSModuleEnvironment.cpp:
957         (JSC::JSModuleEnvironment::visitChildren):
958         * runtime/JSModuleNamespaceObject.cpp:
959         (JSC::JSModuleNamespaceObject::visitChildren):
960         * runtime/JSModuleRecord.cpp:
961         (JSC::JSModuleRecord::visitChildren):
962         * runtime/JSNativeStdFunction.cpp:
963         (JSC::JSNativeStdFunction::visitChildren):
964         * runtime/JSObject.cpp:
965         (JSC::JSObject::visitButterflyImpl):
966         * runtime/JSPromiseDeferred.cpp:
967         (JSC::JSPromiseDeferred::visitChildren):
968         * runtime/JSPropertyNameEnumerator.cpp:
969         (JSC::JSPropertyNameEnumerator::visitChildren):
970         * runtime/JSPropertyNameIterator.cpp:
971         (JSC::JSPropertyNameIterator::visitChildren):
972         * runtime/JSProxy.cpp:
973         (JSC::JSProxy::visitChildren):
974         * runtime/JSScope.cpp:
975         (JSC::JSScope::visitChildren):
976         * runtime/JSSegmentedVariableObject.cpp:
977         (JSC::JSSegmentedVariableObject::visitChildren):
978         * runtime/JSSetIterator.cpp:
979         (JSC::JSSetIterator::visitChildren):
980         * runtime/JSString.cpp:
981         (JSC::JSRopeString::visitFibers):
982         * runtime/JSSymbolTableObject.cpp:
983         (JSC::JSSymbolTableObject::visitChildren):
984         * runtime/JSWeakMap.cpp:
985         (JSC::JSWeakMap::visitChildren):
986         * runtime/JSWeakSet.cpp:
987         (JSC::JSWeakSet::visitChildren):
988         * runtime/JSWithScope.cpp:
989         (JSC::JSWithScope::visitChildren):
990         * runtime/JSWrapperObject.cpp:
991         (JSC::JSWrapperObject::visitChildren):
992         * runtime/LazyClassStructure.cpp:
993         (JSC::LazyClassStructure::visit):
994         * runtime/LazyPropertyInlines.h:
995         (JSC::ElementType>::visit):
996         * runtime/MapBase.cpp:
997         (JSC::MapBase<HashMapBucketType>::visitChildren):
998         * runtime/ModuleProgramExecutable.cpp:
999         (JSC::ModuleProgramExecutable::visitChildren):
1000         * runtime/NativeErrorConstructor.cpp:
1001         (JSC::NativeErrorConstructor::visitChildren):
1002         * runtime/ProgramExecutable.cpp:
1003         (JSC::ProgramExecutable::visitChildren):
1004         * runtime/ProxyObject.cpp:
1005         (JSC::ProxyObject::visitChildren):
1006         * runtime/ProxyRevoke.cpp:
1007         (JSC::ProxyRevoke::visitChildren):
1008         * runtime/RegExpCachedResult.cpp:
1009         (JSC::RegExpCachedResult::visitChildren):
1010         * runtime/RegExpObject.cpp:
1011         (JSC::RegExpObject::visitChildren):
1012         * runtime/RegExpPrototype.cpp:
1013         (JSC::RegExpPrototype::visitChildren):
1014         * runtime/SamplingProfiler.cpp:
1015         (JSC::SamplingProfiler::visit):
1016         * runtime/ScopedArguments.cpp:
1017         (JSC::ScopedArguments::visitChildren):
1018         * runtime/SmallStrings.cpp:
1019         (JSC::SmallStrings::visitStrongReferences):
1020         * runtime/SparseArrayValueMap.cpp:
1021         (JSC::SparseArrayValueMap::visitChildren):
1022         * runtime/Structure.cpp:
1023         (JSC::Structure::visitChildren):
1024         (JSC::Structure::markIfCheap):
1025         * runtime/StructureChain.cpp:
1026         (JSC::StructureChain::visitChildren):
1027         * runtime/StructureRareData.cpp:
1028         (JSC::StructureRareData::visitChildren):
1029         * runtime/SymbolTable.cpp:
1030         (JSC::SymbolTable::visitChildren):
1031         * runtime/TypeProfilerLog.cpp:
1032         (JSC::TypeProfilerLog::visit):
1033         * runtime/WeakMapData.cpp:
1034         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
1035         * wasm/js/JSWebAssemblyInstance.cpp:
1036         (JSC::JSWebAssemblyInstance::visitChildren):
1037         * wasm/js/JSWebAssemblyMemory.cpp:
1038         (JSC::JSWebAssemblyMemory::visitChildren):
1039         * wasm/js/JSWebAssemblyModule.cpp:
1040         (JSC::JSWebAssemblyModule::visitChildren):
1041         * wasm/js/JSWebAssemblyTable.cpp:
1042         (JSC::JSWebAssemblyTable::visitChildren):
1043         * wasm/js/WebAssemblyFunction.cpp:
1044         (JSC::WebAssemblyFunction::visitChildren):
1045         * wasm/js/WebAssemblyModuleRecord.cpp:
1046         (JSC::WebAssemblyModuleRecord::visitChildren):
1047
1048 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
1049
1050         Sort Xcode project files
1051         https://bugs.webkit.org/show_bug.cgi?id=165937
1052
1053         Reviewed by Simon Fraser.
1054
1055         * JavaScriptCore.xcodeproj/project.pbxproj:
1056
1057 2016-12-15  Keith Miller  <keith_miller@apple.com>
1058
1059         Wasm should not create empty unlinked callsites
1060         https://bugs.webkit.org/show_bug.cgi?id=165933
1061
1062         Reviewed by Mark Lam.
1063
1064         Wasm would create holes in the unlinked callsite vector if B3 was able to
1065         eliminate the callsite.
1066
1067         * wasm/WasmB3IRGenerator.cpp:
1068         (JSC::Wasm::B3IRGenerator::addCall):
1069
1070 2016-12-15  JF Bastien  <jfbastien@apple.com>
1071
1072         WebAssembly: improve compilation error messages
1073         https://bugs.webkit.org/show_bug.cgi?id=163919
1074
1075         Reviewed by Saam Barati.
1076
1077         The error handling messages were underwhelming because most
1078         locations merely returned `false` on failure. This patch uses
1079         std::expected to denote that failure isn't expected. Doing this
1080         makes it almost impossible to mess up the code: either a function
1081         returns a result (or a partial result for internal helpers) or an
1082         error. We're not synchronizing the error string with the m_failed
1083         bool anymore, and the caller will abort if they try to get a
1084         result but the outcome was an error.
1085
1086         This also shortens the code significantly using macros, while also
1087         judiciously preventing inlining of error handling code and biasing
1088         towards success using UNLIKELY. This means that the generated code
1089         should be more efficient (no string formatting on success, and
1090         regalloc can avoid these unlikely paths).
1091
1092         The patch adds a few missing checks as well, especially related to
1093         count limits and memory allocation failure.
1094
1095         As a follow-up I'd like to improve WTF::makeString further, so it
1096         does coercions to string and understands ADL as I did in this
1097         patch.
1098
1099         * wasm/WasmB3IRGenerator.cpp:
1100         (JSC::Wasm::B3IRGenerator::fail):
1101         (JSC::Wasm::parseAndCompile):
1102         * wasm/WasmB3IRGenerator.h:
1103         * wasm/WasmFormat.h:
1104         (JSC::Wasm::isValidExternalKind):
1105         (JSC::Wasm::makeString):
1106         * wasm/WasmFunctionParser.h:
1107         * wasm/WasmModuleParser.cpp:
1108         * wasm/WasmModuleParser.h:
1109         * wasm/WasmParser.h:
1110         (JSC::Wasm::FailureHelper::makeString):
1111         (JSC::Wasm::Parser::fail):
1112         (JSC::Wasm::Parser<SuccessType>::Parser):
1113         (JSC::Wasm::Parser<SuccessType>::consumeCharacter):
1114         (JSC::Wasm::Parser<SuccessType>::consumeString):
1115         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
1116         (JSC::Wasm::Parser<SuccessType>::parseVarUInt32):
1117         (JSC::Wasm::Parser<SuccessType>::parseVarUInt64):
1118         (JSC::Wasm::Parser<SuccessType>::parseVarInt32):
1119         (JSC::Wasm::Parser<SuccessType>::parseVarInt64):
1120         (JSC::Wasm::Parser<SuccessType>::parseUInt32):
1121         (JSC::Wasm::Parser<SuccessType>::parseUInt64):
1122         (JSC::Wasm::Parser<SuccessType>::parseUInt8):
1123         (JSC::Wasm::Parser<SuccessType>::parseInt7):
1124         (JSC::Wasm::Parser<SuccessType>::parseUInt7):
1125         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
1126         (JSC::Wasm::Parser<SuccessType>::parseResultType):
1127         (JSC::Wasm::Parser<SuccessType>::parseValueType):
1128         (JSC::Wasm::Parser<SuccessType>::parseExternalKind):
1129         * wasm/WasmPlan.cpp:
1130         (JSC::Wasm::Plan::run):
1131         * wasm/WasmSections.h:
1132         (JSC::Wasm::isValidSection):
1133         (JSC::Wasm::validateOrder):
1134         (JSC::Wasm::makeString):
1135         * wasm/WasmValidate.cpp:
1136         (JSC::Wasm::Validate::fail):
1137         (JSC::Wasm::Validate::addUnreachable):
1138         (JSC::Wasm::validateFunction):
1139         * wasm/WasmValidate.h:
1140         * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
1141         * wasm/generateWasmOpsHeader.py:
1142         * wasm/generateWasmValidateInlinesHeader.py:
1143         (loadMacro):
1144         (storeMacro):
1145         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1146         (JSC::constructJSWebAssemblyInstance):
1147         * wasm/js/WebAssemblyModuleRecord.cpp:
1148         (JSC::WebAssemblyModuleRecord::link):
1149
1150 2016-12-15  JF Bastien  <jfbastien@apple.com>
1151
1152         WebAssembly API: improve data section errors, initialize after Element
1153         https://bugs.webkit.org/show_bug.cgi?id=165733
1154
1155         Reviewed by Keith Miller.
1156
1157         * wasm/WasmModuleParser.cpp:
1158         (JSC::Wasm::ModuleParser::parseData): Data section without Memory section or import is a validation error
1159         * wasm/js/WebAssemblyModuleRecord.cpp:
1160         (JSC::dataSegmentFail):
1161         (JSC::WebAssemblyModuleRecord::evaluate): tighten checks (though the spec isn't fully baked), and move after Element initialization
1162
1163 2016-12-15  Keith Miller  <keith_miller@apple.com>
1164
1165         Turn on WebAssembly by default
1166         https://bugs.webkit.org/show_bug.cgi?id=165918
1167
1168         Reviewed by Saam Barati.
1169
1170         * runtime/Options.h:
1171
1172 2016-12-15  Konstantin Tokarev  <annulen@yandex.ru>
1173
1174         Added missing override and final specifiers
1175         https://bugs.webkit.org/show_bug.cgi?id=165903
1176
1177         Reviewed by Darin Adler.
1178
1179         * bytecompiler/BytecodeGenerator.h:
1180         * jsc.cpp:
1181         * parser/Nodes.h:
1182
1183 2016-12-15  Chris Dumez  <cdumez@apple.com>
1184
1185         Harden JSObject::getOwnPropertyDescriptor()
1186         https://bugs.webkit.org/show_bug.cgi?id=165908
1187
1188         Reviewed by Geoffrey Garen.
1189
1190         * runtime/JSObject.cpp:
1191         (JSC::JSObject::getOwnPropertyDescriptor):
1192
1193 2016-12-15  Keith Miller  <keith_miller@apple.com>
1194
1195         Fix 64-bit shift family Wasm opcodes
1196         https://bugs.webkit.org/show_bug.cgi?id=165902
1197
1198         Reviewed by Geoffrey Garen.
1199
1200         The Int64 versions of the shift family B3 opcodes take an Int32
1201         for the shift value. Wasm, however, takes an i64, so we need to
1202         Trunc the shift value. Also, this fixes a bug where shr_u mapped
1203         to signed shift and shr_s mapped to the unsigned shift.
1204
1205         * wasm/wasm.json:
1206
1207 2016-12-14  Keith Miller  <keith_miller@apple.com>
1208
1209         Wasm should decode constants correctly
1210         https://bugs.webkit.org/show_bug.cgi?id=165886
1211
1212         Reviewed by Saam Barati.
1213
1214         This patch fixes how we decode the constant part of i32, i64, f32,
1215         and f64.const opcodes.
1216
1217         * wasm/WasmFunctionParser.h:
1218         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1219         * wasm/wasm.json:
1220
1221 2016-12-14  Saam Barati  <sbarati@apple.com>
1222
1223         WebAssembly: Add various low hanging fruit that will allow us to run the LLVM torture tests in Wasm
1224         https://bugs.webkit.org/show_bug.cgi?id=165883
1225
1226         Reviewed by Keith Miller.
1227
1228         This patch implements some low hanging fruit:
1229         - Exporting Table
1230         - Exporting Memory
1231         - Load16 with zero extension to both 32 and 64 bit values.
1232         - Fixes Unreachable to emit code that will prevent B3 from having a validation error.
1233
1234         * wasm/WasmB3IRGenerator.cpp:
1235         (JSC::Wasm::B3IRGenerator::addUnreachable):
1236         (JSC::Wasm::sizeOfLoadOp):
1237         (JSC::Wasm::B3IRGenerator::emitLoadOp):
1238         * wasm/WasmFunctionParser.h:
1239         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1240         * wasm/WasmModuleParser.cpp:
1241         (JSC::Wasm::ModuleParser::parseExport):
1242         * wasm/WasmValidate.cpp:
1243         (JSC::Wasm::Validate::addUnreachable):
1244         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1245         (JSC::constructJSWebAssemblyInstance):
1246         * wasm/js/WebAssemblyModuleRecord.cpp:
1247         (JSC::WebAssemblyModuleRecord::finishCreation):
1248         (JSC::WebAssemblyModuleRecord::link):
1249
1250 2016-12-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1251
1252         Update ModuleLoader code by using the latest builtin primitives
1253         https://bugs.webkit.org/show_bug.cgi?id=165851
1254
1255         Reviewed by Sam Weinig.
1256
1257         Update the module loader code,
1258
1259         1. Use @globalPrivate for the utilities, instead of setting them as the member of ModuleLoader.
1260         2. Use @putByValDirect instead of @push. @push is user-observable since it uses Set() operation
1261            and it can be observed by defining indexed setters in Array.prototype.
1262
1263         * builtins/ModuleLoaderPrototype.js:
1264         (ensureRegistered):
1265         (fulfillFetch):
1266         (commitInstantiated):
1267         (requestFetch):
1268         (requestSatisfy):
1269         (setStateToMax): Deleted.
1270         (newRegistryEntry): Deleted.
1271         * runtime/ModuleLoaderPrototype.cpp:
1272
1273 2016-12-14  Michael Saboff  <msaboff@apple.com>
1274
1275         The stress GC bot crashes in JavaScriptCore beneath ShadowChicken::update and Inspector::jsToInspectorValue
1276         https://bugs.webkit.org/show_bug.cgi?id=165871
1277
1278         Reviewed by Mark Lam.
1279
1280         This fixes two issues with the VM watch dog timer firing in a worker.
1281
1282         The first issue has to do with bytecode ordering.  Prior to this change, the first few opcodes
1283         generated when the watch dog is enabled are:
1284                 op_enter
1285                 op_watchdog
1286                 op_get_scope
1287         When the watchdog fires, the function will get an exception at op_watchdog.  In processing that exception,
1288         we'll try to update the ShadowChicken shadow stack.  That update assumes that if there is a scope 
1289         VirtualRegister allocated, then the slot contains a valid JSScope.  With the current bytecode ordering,
1290         this is not true at op_watchdog as op_enter will put JSUndefined in the scope slot.  It isn't until the
1291         op_get_scope gets processed that we'll have a valid scope in the slot.  The fix for this issue is to 
1292         ensure that op_get_scope happens before the op_watchdog.
1293
1294         The second issue is that ScriptFunctionCall::call() will not tell its caller that a terminated
1295         execution exception happened.  Instead call() returns an empty JSValue.  InjectedScript::wrapCallFrames()
1296         wasn't checking for an empty JSValue, but was passing it to another function.  Added a short circuit
1297         return when call returns an empty JSValue.
1298
1299         Added <https://bugs.webkit.org/show_bug.cgi?id=165875> to fix other callers of ScriptFunctionCall::call()
1300         to check for an empty JSValue return value.
1301         Also tracked with <rdar://problem/29671015>.
1302
1303         * bytecompiler/BytecodeGenerator.cpp:
1304         (JSC::BytecodeGenerator::BytecodeGenerator):
1305         (JSC::BytecodeGenerator::emitEnter):
1306         * inspector/InjectedScript.cpp:
1307         (Inspector::InjectedScript::wrapCallFrames):
1308
1309 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
1310
1311         DirectTailCall implementation needs to tell the shuffler what to put into the ArgumentCount explicitly
1312         https://bugs.webkit.org/show_bug.cgi?id=165882
1313
1314         Reviewed by Mark Lam.
1315         
1316         The CallFrameShuffler was assuming that the ArgumentCount that it should store into the
1317         callee frame is simply the size of the args vector.
1318         
1319         That's not true for DirectTailCall, which will pad the args vector with undefined if we
1320         are optimizing an arity mismatch. We need to pass the ArgumentCount explicitly in this
1321         case.
1322
1323         * dfg/DFGSpeculativeJIT32_64.cpp:
1324         (JSC::DFG::SpeculativeJIT::emitCall):
1325         * dfg/DFGSpeculativeJIT64.cpp:
1326         (JSC::DFG::SpeculativeJIT::emitCall):
1327         * ftl/FTLLowerDFGToB3.cpp:
1328         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
1329         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
1330         * jit/CallFrameShuffleData.h:
1331         * jit/CallFrameShuffler.cpp:
1332         (JSC::CallFrameShuffler::CallFrameShuffler):
1333         (JSC::CallFrameShuffler::prepareAny):
1334         * jit/CallFrameShuffler.h:
1335         (JSC::CallFrameShuffler::snapshot):
1336         * jit/JITCall.cpp:
1337         (JSC::JIT::compileOpCall):
1338
1339 2016-12-14  Keith Miller  <keith_miller@apple.com>
1340
1341         WebAssembly JS API: implement Global
1342         https://bugs.webkit.org/show_bug.cgi?id=164133
1343
1344         Reviewed by Saam Barati.
1345
1346         This patch adds support for globals. It handles imports, exports
1347         and internal globals. In the MVP only internal globals are allowed
1348         to be mutable. This means we can store a C-array of 64-bit slots
1349         off the instance holding them. When globals are exported to JS
1350         they are done so as numbers. This means that i64 globals cannot be
1351         imported or exported.
1352
1353         * wasm/WasmB3IRGenerator.cpp:
1354         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1355         (JSC::Wasm::B3IRGenerator::getGlobal):
1356         (JSC::Wasm::B3IRGenerator::setGlobal):
1357         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1358         (JSC::Wasm::parseAndCompile):
1359         * wasm/WasmFormat.h:
1360         * wasm/WasmFunctionParser.h:
1361         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1362         * wasm/WasmModuleParser.cpp:
1363         (JSC::Wasm::ModuleParser::parseImport):
1364         (JSC::Wasm::ModuleParser::parseGlobal):
1365         (JSC::Wasm::ModuleParser::parseExport):
1366         (JSC::Wasm::ModuleParser::parseElement):
1367         (JSC::Wasm::ModuleParser::parseInitExpr):
1368         (JSC::Wasm::ModuleParser::parseGlobalType):
1369         (JSC::Wasm::ModuleParser::parseData):
1370         * wasm/WasmModuleParser.h:
1371         * wasm/WasmParser.h:
1372         (JSC::Wasm::Parser::parseVarInt32):
1373         (JSC::Wasm::Parser::parseVarInt64):
1374         (JSC::Wasm::Parser::parseUInt64):
1375         * wasm/WasmValidate.cpp:
1376         (JSC::Wasm::Validate::hasMemory):
1377         (JSC::Wasm::Validate::Validate):
1378         (JSC::Wasm::Validate::getGlobal):
1379         (JSC::Wasm::Validate::setGlobal):
1380         (JSC::Wasm::validateFunction):
1381         * wasm/generateWasmOpsHeader.py:
1382         * wasm/js/JSWebAssemblyInstance.cpp:
1383         (JSC::JSWebAssemblyInstance::create):
1384         (JSC::JSWebAssemblyInstance::finishCreation):
1385         (JSC::JSWebAssemblyInstance::visitChildren):
1386         * wasm/js/JSWebAssemblyInstance.h:
1387         (JSC::JSWebAssemblyInstance::loadI32Global):
1388         (JSC::JSWebAssemblyInstance::loadI64Global):
1389         (JSC::JSWebAssemblyInstance::loadF32Global):
1390         (JSC::JSWebAssemblyInstance::loadF64Global):
1391         (JSC::JSWebAssemblyInstance::setGlobal):
1392         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
1393         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1394         (JSC::constructJSWebAssemblyInstance):
1395         * wasm/js/WebAssemblyModuleRecord.cpp:
1396         (JSC::WebAssemblyModuleRecord::finishCreation):
1397         (JSC::WebAssemblyModuleRecord::link):
1398
1399 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
1400
1401         Unreviewed, re-enable concurrent GC on ARM64 now that the most likely culprit of the memory
1402         regressions is fixed. Lets see what the bots think!
1403
1404         * runtime/Options.cpp:
1405         (JSC::recomputeDependentOptions):
1406
1407 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
1408
1409         Devices with fewer cores should use a more aggressive GC schedule by default
1410         https://bugs.webkit.org/show_bug.cgi?id=165859
1411
1412         Reviewed by Mark Lam.
1413
1414         * heap/Heap.cpp:
1415         (JSC::Heap::markToFixpoint): Log when we have an unexpected delay in wake-up.
1416         * heap/SlotVisitor.cpp:
1417         (JSC::SlotVisitor::drainInParallelPassively): Don't drain passively if there aren't many cores.
1418         * runtime/Options.cpp:
1419         (JSC::overrideDefaults): Change the heuristics if we have fewer cores.
1420         (JSC::Options::initialize):
1421         * runtime/Options.h:
1422
1423 2016-12-14  Mark Lam  <mark.lam@apple.com>
1424
1425         BytecodeBasicBlock::computeImpl() should not keep iterating blocks if all jump targets have already been found.
1426         https://bugs.webkit.org/show_bug.cgi?id=165820
1427
1428         Reviewed by Saam Barati.
1429
1430         Currently, if an opcode is a branch type opcode, BytecodeBasicBlock::computeImpl()
1431         will iterate over all basic blocks looking for the block containing the jump
1432         target, and it will continue to do this even when all the jump targets have been
1433         found.  This is wasted work, and all the more so given that most branch type
1434         opcodes only have a single jump target.
1435
1436         * bytecode/BytecodeBasicBlock.cpp:
1437         (JSC::BytecodeBasicBlock::computeImpl):
1438
1439 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
1440
1441         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
1442         https://bugs.webkit.org/show_bug.cgi?id=165741
1443
1444         Unreviewed, re-landing this with fix (revert erroneous change to Options).
1445
1446         * CMakeLists.txt:
1447         * JavaScriptCore.xcodeproj/project.pbxproj:
1448         * heap/CellContainer.cpp: Added.
1449         (JSC::CellContainer::isNewlyAllocated):
1450         * heap/CellContainer.h:
1451         * heap/MarkedAllocator.cpp:
1452         (JSC::MarkedAllocator::addBlock):
1453         (JSC::MarkedAllocator::removeBlock):
1454         (JSC::MarkedAllocator::dumpBits):
1455         * heap/MarkedAllocator.h:
1456         (JSC::MarkedAllocator::forEachBitVector):
1457         (JSC::MarkedAllocator::forEachBitVectorWithName):
1458         * heap/MarkedBlock.cpp:
1459         (JSC::MarkedBlock::tryCreate):
1460         (JSC::MarkedBlock::Handle::~Handle):
1461         (JSC::MarkedBlock::MarkedBlock):
1462         (JSC::MarkedBlock::Handle::specializedSweep):
1463         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
1464         (JSC::MarkedBlock::Handle::stopAllocating):
1465         (JSC::MarkedBlock::Handle::resumeAllocating):
1466         (JSC::MarkedBlock::aboutToMarkSlow):
1467         (JSC::MarkedBlock::Handle::didConsumeFreeList):
1468         (JSC::MarkedBlock::Handle::dumpState):
1469         * heap/MarkedBlock.h:
1470         (JSC::MarkedBlock::markingVersion):
1471         (JSC::MarkedBlock::isMarkedRaw):
1472         (JSC::MarkedBlock::isMarked):
1473         * heap/MarkedBlockInlines.h:
1474         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
1475         * heap/SlotVisitor.cpp:
1476         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
1477         * runtime/StructureIDTable.h:
1478         (JSC::StructureIDTable::size):
1479         (JSC::StructureIDTable::get):
1480
1481 2016-12-14  Chris Dumez  <cdumez@apple.com>
1482
1483         Unreviewed, rolling out r209766.
1484
1485         Regressed Dromaeo JSLib by ~50%
1486
1487         Reverted changeset:
1488
1489         "Make opaque root scanning truly constraint-based"
1490         https://bugs.webkit.org/show_bug.cgi?id=165760
1491         http://trac.webkit.org/changeset/209766
1492
1493 2016-12-14  Commit Queue  <commit-queue@webkit.org>
1494
1495         Unreviewed, rolling out r209795.
1496         https://bugs.webkit.org/show_bug.cgi?id=165853
1497
1498         rolled out the wrong revision (Requested by pizlo on #webkit).
1499
1500         Reverted changeset:
1501
1502         "MarkedBlock::marksConveyLivenessDuringMarking should take
1503         into account collection scope"
1504         https://bugs.webkit.org/show_bug.cgi?id=165741
1505         http://trac.webkit.org/changeset/209795
1506
1507 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
1508
1509         Unreviewed, disable concurrent GC on ARM while we investigate a memory use regression.
1510
1511         * runtime/Options.cpp:
1512         (JSC::recomputeDependentOptions):
1513
1514 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1515
1516         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
1517         https://bugs.webkit.org/show_bug.cgi?id=165795
1518
1519         Reviewed by Saam Barati.
1520
1521         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
1522         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
1523         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
1524         allocations.
1525
1526         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
1527
1528         * API/JSValueRef.cpp:
1529         (JSValueToStringCopy):
1530         * bindings/ScriptValue.cpp:
1531         (Deprecated::ScriptValue::toString):
1532         * inspector/JSGlobalObjectInspectorController.cpp:
1533         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
1534         * inspector/JSInjectedScriptHost.cpp:
1535         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
1536         * inspector/JSJavaScriptCallFrame.cpp:
1537         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
1538         * inspector/ScriptCallStackFactory.cpp:
1539         (Inspector::extractSourceInformationFromException):
1540         * runtime/ConsoleObject.cpp:
1541         (JSC::valueToStringWithUndefinedOrNullCheck):
1542         (JSC::valueOrDefaultLabelString):
1543         * runtime/DateConstructor.cpp:
1544         (JSC::dateParse):
1545         * runtime/DatePrototype.cpp:
1546         (JSC::formatLocaleDate):
1547         * runtime/ErrorInstance.cpp:
1548         (JSC::ErrorInstance::sanitizedToString):
1549         * runtime/ErrorPrototype.cpp:
1550         (JSC::errorProtoFuncToString):
1551         * runtime/InspectorInstrumentationObject.cpp:
1552         (JSC::inspectorInstrumentationObjectLog):
1553         * runtime/JSGlobalObjectFunctions.cpp:
1554         (JSC::globalFuncEval):
1555         * runtime/JSModuleLoader.cpp:
1556         (JSC::JSModuleLoader::fetch):
1557         * runtime/ModuleLoaderPrototype.cpp:
1558         (JSC::moduleLoaderPrototypeParseModule):
1559         * runtime/RegExpConstructor.cpp:
1560         (JSC::regExpCreate):
1561         * runtime/RegExpPrototype.cpp:
1562         (JSC::regExpProtoFuncCompile):
1563         (JSC::regExpProtoFuncToString):
1564         * runtime/StringPrototype.cpp:
1565         (JSC::replaceUsingRegExpSearch):
1566         (JSC::replaceUsingStringSearch):
1567         (JSC::stringProtoFuncSlice):
1568         (JSC::stringProtoFuncSplitFast):
1569         (JSC::stringProtoFuncSubstr):
1570         (JSC::stringProtoFuncLocaleCompare):
1571         (JSC::stringProtoFuncBig):
1572         (JSC::stringProtoFuncSmall):
1573         (JSC::stringProtoFuncBlink):
1574         (JSC::stringProtoFuncBold):
1575         (JSC::stringProtoFuncFixed):
1576         (JSC::stringProtoFuncItalics):
1577         (JSC::stringProtoFuncStrike):
1578         (JSC::stringProtoFuncSub):
1579         (JSC::stringProtoFuncSup):
1580         (JSC::stringProtoFuncFontcolor):
1581         (JSC::stringProtoFuncFontsize):
1582         (JSC::stringProtoFuncAnchor):
1583         (JSC::stringProtoFuncLink):
1584         (JSC::trimString):
1585         (JSC::stringProtoFuncStartsWith):
1586         (JSC::stringProtoFuncEndsWith):
1587         (JSC::stringProtoFuncIncludes):
1588         (JSC::builtinStringIncludesInternal):
1589         (JSC::stringProtoFuncNormalize):
1590         * tools/JSDollarVMPrototype.cpp:
1591         (JSC::functionPrint):
1592         * wasm/js/JSWebAssemblyCompileError.h:
1593         (JSC::JSWebAssemblyCompileError::create):
1594         * wasm/js/JSWebAssemblyRuntimeError.h:
1595         (JSC::JSWebAssemblyRuntimeError::create):
1596
1597 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
1598
1599         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
1600         https://bugs.webkit.org/show_bug.cgi?id=165741
1601
1602         Unreviewed rollout due to performance regression.
1603
1604         * CMakeLists.txt:
1605         * JavaScriptCore.xcodeproj/project.pbxproj:
1606         * heap/CellContainer.cpp: Removed.
1607         * heap/CellContainer.h:
1608         * heap/MarkedAllocator.cpp:
1609         (JSC::MarkedAllocator::addBlock):
1610         (JSC::MarkedAllocator::removeBlock):
1611         (JSC::MarkedAllocator::dumpBits):
1612         * heap/MarkedAllocator.h:
1613         (JSC::MarkedAllocator::forEachBitVector):
1614         (JSC::MarkedAllocator::forEachBitVectorWithName):
1615         * heap/MarkedBlock.cpp:
1616         (JSC::MarkedBlock::tryCreate):
1617         (JSC::MarkedBlock::Handle::~Handle):
1618         (JSC::MarkedBlock::MarkedBlock):
1619         (JSC::MarkedBlock::Handle::specializedSweep):
1620         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
1621         (JSC::MarkedBlock::Handle::stopAllocating):
1622         (JSC::MarkedBlock::Handle::resumeAllocating):
1623         (JSC::MarkedBlock::aboutToMarkSlow):
1624         (JSC::MarkedBlock::Handle::didConsumeFreeList):
1625         (JSC::MarkedBlock::Handle::dumpState): Deleted.
1626         * heap/MarkedBlock.h:
1627         (JSC::MarkedBlock::isMarked):
1628         (JSC::MarkedBlock::markingVersion): Deleted.
1629         (JSC::MarkedBlock::isMarkedRaw): Deleted.
1630         * heap/MarkedBlockInlines.h:
1631         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
1632         * heap/SlotVisitor.cpp:
1633         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
1634         * runtime/Options.h:
1635         * runtime/StructureIDTable.h:
1636         (JSC::StructureIDTable::get):
1637         (JSC::StructureIDTable::size): Deleted.
1638
1639 2016-12-13  Commit Queue  <commit-queue@webkit.org>
1640
1641         Unreviewed, rolling out r209792.
1642         https://bugs.webkit.org/show_bug.cgi?id=165841
1643
1644         Cause build failures (Requested by yusukesuzuki on #webkit).
1645
1646         Reverted changeset:
1647
1648         "Use JSValue::toWTFString instead of calling toString(exec)
1649         and value(exec)"
1650         https://bugs.webkit.org/show_bug.cgi?id=165795
1651         http://trac.webkit.org/changeset/209792
1652
1653 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1654
1655         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
1656         https://bugs.webkit.org/show_bug.cgi?id=165795
1657
1658         Reviewed by Saam Barati.
1659
1660         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
1661         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
1662         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
1663         allocations.
1664
1665         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
1666
1667         * API/JSValueRef.cpp:
1668         (JSValueToStringCopy):
1669         * bindings/ScriptValue.cpp:
1670         (Deprecated::ScriptValue::toString):
1671         * inspector/JSGlobalObjectInspectorController.cpp:
1672         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
1673         * inspector/JSInjectedScriptHost.cpp:
1674         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
1675         * inspector/JSJavaScriptCallFrame.cpp:
1676         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
1677         * inspector/ScriptCallStackFactory.cpp:
1678         (Inspector::extractSourceInformationFromException):
1679         * runtime/ConsoleObject.cpp:
1680         (JSC::valueToStringWithUndefinedOrNullCheck):
1681         (JSC::valueOrDefaultLabelString):
1682         * runtime/DateConstructor.cpp:
1683         (JSC::dateParse):
1684         * runtime/DatePrototype.cpp:
1685         (JSC::formatLocaleDate):
1686         * runtime/ErrorInstance.cpp:
1687         (JSC::ErrorInstance::sanitizedToString):
1688         * runtime/ErrorPrototype.cpp:
1689         (JSC::errorProtoFuncToString):
1690         * runtime/InspectorInstrumentationObject.cpp:
1691         (JSC::inspectorInstrumentationObjectLog):
1692         * runtime/JSCJSValue.cpp:
1693         (JSC::JSValue::toWTFStringSlowCase):
1694         * runtime/JSGlobalObjectFunctions.cpp:
1695         (JSC::globalFuncEval):
1696         * runtime/JSModuleLoader.cpp:
1697         (JSC::JSModuleLoader::fetch):
1698         * runtime/ModuleLoaderPrototype.cpp:
1699         (JSC::moduleLoaderPrototypeParseModule):
1700         * runtime/RegExpConstructor.cpp:
1701         (JSC::regExpCreate):
1702         * runtime/RegExpPrototype.cpp:
1703         (JSC::regExpProtoFuncCompile):
1704         (JSC::regExpProtoFuncToString):
1705         * runtime/StringPrototype.cpp:
1706         (JSC::replaceUsingRegExpSearch):
1707         (JSC::replaceUsingStringSearch):
1708         (JSC::stringProtoFuncSlice):
1709         (JSC::stringProtoFuncSplitFast):
1710         (JSC::stringProtoFuncSubstr):
1711         (JSC::stringProtoFuncLocaleCompare):
1712         (JSC::stringProtoFuncBig):
1713         (JSC::stringProtoFuncSmall):
1714         (JSC::stringProtoFuncBlink):
1715         (JSC::stringProtoFuncBold):
1716         (JSC::stringProtoFuncFixed):
1717         (JSC::stringProtoFuncItalics):
1718         (JSC::stringProtoFuncStrike):
1719         (JSC::stringProtoFuncSub):
1720         (JSC::stringProtoFuncSup):
1721         (JSC::stringProtoFuncFontcolor):
1722         (JSC::stringProtoFuncFontsize):
1723         (JSC::stringProtoFuncAnchor):
1724         (JSC::stringProtoFuncLink):
1725         (JSC::trimString):
1726         (JSC::stringProtoFuncStartsWith):
1727         (JSC::stringProtoFuncEndsWith):
1728         (JSC::stringProtoFuncIncludes):
1729         (JSC::builtinStringIncludesInternal):
1730         (JSC::stringProtoFuncNormalize):
1731         * tools/JSDollarVMPrototype.cpp:
1732         (JSC::functionPrint):
1733         * wasm/js/JSWebAssemblyCompileError.h:
1734         (JSC::JSWebAssemblyCompileError::create):
1735         * wasm/js/JSWebAssemblyRuntimeError.h:
1736         (JSC::JSWebAssemblyRuntimeError::create):
1737
1738 2016-12-13  Saam Barati  <sbarati@apple.com>
1739
1740         WebAssembly: implement the elements section
1741         https://bugs.webkit.org/show_bug.cgi?id=165715
1742
1743         Reviewed by Keith Miller.
1744
1745         This is a straight forward implementation of the Element
1746         section in the Wasm spec:
1747         https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#element-section
1748         
1749         There are a few ambiguities I encountered when implementing this, so I've
1750         filed bugs against the Wasm design repo, and corresponding bugzilla bugs
1751         for us to address after they've been discussed by the various Wasm folks:
1752         - https://bugs.webkit.org/show_bug.cgi?id=165827
1753         - https://bugs.webkit.org/show_bug.cgi?id=165826
1754         - https://bugs.webkit.org/show_bug.cgi?id=165825
1755
1756         * wasm/WasmFormat.h:
1757         * wasm/WasmModuleParser.cpp:
1758         (JSC::Wasm::ModuleParser::parseElement):
1759         (JSC::Wasm::ModuleParser::parseInitExpr):
1760         (JSC::Wasm::ModuleParser::parseData):
1761         * wasm/WasmModuleParser.h:
1762         * wasm/js/WebAssemblyModuleRecord.cpp:
1763         (JSC::WebAssemblyModuleRecord::evaluate):
1764
1765 2016-12-13  Chris Dumez  <cdumez@apple.com>
1766
1767         Unreviewed, rolling out r209544.
1768
1769         Looks like r209489 did not cause the performance regression
1770         after all
1771
1772         Reverted changeset:
1773
1774         "Unreviewed, rolling out r209489."
1775         https://bugs.webkit.org/show_bug.cgi?id=165550
1776         http://trac.webkit.org/changeset/209544
1777
1778 2016-12-13  Saam Barati  <sbarati@apple.com>
1779
1780         WebAssembly: implement the table section and table import
1781         https://bugs.webkit.org/show_bug.cgi?id=165716
1782
1783         Reviewed by Keith Miller.
1784
1785         This patch implements the Table space for wasm:
1786         https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#table-section
1787
1788         It only implements defining and importing a table. The bulk
1789         of this patch is implementing the various wasm Table prototype
1790         methods and the underlying Table object:
1791         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblytable-constructor
1792
1793         This patch also fixes a bug in our implementation with call_indirect.
1794         We initially implemented call_indirect as a way to call functions that
1795         are imported or defined in the module. This was the wrong
1796         interpretation of the spec. Instead, call_indirect can only index into
1797         the table index space.
1798
1799         * JavaScriptCore.xcodeproj/project.pbxproj:
1800         * wasm/WasmB3IRGenerator.cpp:
1801         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1802         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1803         (JSC::Wasm::parseAndCompile):
1804         * wasm/WasmFormat.h:
1805         (JSC::Wasm::TableInformation::TableInformation):
1806         (JSC::Wasm::TableInformation::operator bool):
1807         (JSC::Wasm::TableInformation::isImport):
1808         (JSC::Wasm::TableInformation::initial):
1809         (JSC::Wasm::TableInformation::maximum):
1810         (JSC::Wasm::CallableFunction::CallableFunction):
1811         * wasm/WasmFunctionParser.h:
1812         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1813         * wasm/WasmModuleParser.cpp:
1814         (JSC::Wasm::ModuleParser::parseImport):
1815         (JSC::Wasm::ModuleParser::parseResizableLimits):
1816         (JSC::Wasm::ModuleParser::parseTableHelper):
1817         (JSC::Wasm::ModuleParser::parseTable):
1818         (JSC::Wasm::ModuleParser::parseMemoryHelper):
1819         (JSC::Wasm::ModuleParser::parseExport):
1820         * wasm/WasmModuleParser.h:
1821         * wasm/js/JSWebAssemblyHelpers.h: Added.
1822         (JSC::toNonWrappingUint32):
1823         * wasm/js/JSWebAssemblyInstance.cpp:
1824         (JSC::JSWebAssemblyInstance::visitChildren):
1825         * wasm/js/JSWebAssemblyInstance.h:
1826         (JSC::JSWebAssemblyInstance::table):
1827         (JSC::JSWebAssemblyInstance::setTable):
1828         (JSC::JSWebAssemblyInstance::offsetOfTable):
1829         * wasm/js/JSWebAssemblyTable.cpp:
1830         (JSC::JSWebAssemblyTable::create):
1831         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1832         (JSC::JSWebAssemblyTable::visitChildren):
1833         (JSC::JSWebAssemblyTable::grow):
1834         (JSC::JSWebAssemblyTable::clearFunction):
1835         (JSC::JSWebAssemblyTable::setFunction):
1836         * wasm/js/JSWebAssemblyTable.h:
1837         (JSC::JSWebAssemblyTable::maximum):
1838         (JSC::JSWebAssemblyTable::size):
1839         (JSC::JSWebAssemblyTable::getFunction):
1840         (JSC::JSWebAssemblyTable::offsetOfSize):
1841         (JSC::JSWebAssemblyTable::offsetOfFunctions):
1842         (JSC::JSWebAssemblyTable::isValidSize):
1843         * wasm/js/WebAssemblyFunction.cpp:
1844         (JSC::WebAssemblyFunction::call):
1845         (JSC::WebAssemblyFunction::create):
1846         (JSC::WebAssemblyFunction::visitChildren):
1847         (JSC::WebAssemblyFunction::finishCreation):
1848         * wasm/js/WebAssemblyFunction.h:
1849         (JSC::WebAssemblyFunction::signature):
1850         (JSC::WebAssemblyFunction::wasmEntrypoint):
1851         (JSC::WebAssemblyFunction::webAssemblyCallee): Deleted.
1852         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1853         (JSC::constructJSWebAssemblyInstance):
1854         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1855         (JSC::constructJSWebAssemblyMemory):
1856         * wasm/js/WebAssemblyModuleRecord.cpp:
1857         (JSC::WebAssemblyModuleRecord::finishCreation):
1858         (JSC::WebAssemblyModuleRecord::link):
1859         * wasm/js/WebAssemblyTableConstructor.cpp:
1860         (JSC::constructJSWebAssemblyTable):
1861         * wasm/js/WebAssemblyTablePrototype.cpp:
1862         (JSC::getTable):
1863         (JSC::webAssemblyTableProtoFuncLength):
1864         (JSC::webAssemblyTableProtoFuncGrow):
1865         (JSC::webAssemblyTableProtoFuncGet):
1866         (JSC::webAssemblyTableProtoFuncSet):
1867         (JSC::WebAssemblyTablePrototype::create):
1868         (JSC::WebAssemblyTablePrototype::finishCreation):
1869         * wasm/js/WebAssemblyTablePrototype.h:
1870
1871 2016-12-13  Filip Pizlo  <fpizlo@apple.com>
1872
1873         Add null checks to opaque root APIs.
1874
1875         Rubber stamped by Saam Barati. 
1876
1877         If we got a crash report about null in the opaque root HashSet, we would probably not
1878         celebrate how great it is that we found out about a new race - instead we would probably
1879         be annoyed that null wasn't just silently ignored.
1880
1881         * heap/SlotVisitor.cpp:
1882         (JSC::SlotVisitor::addOpaqueRoot):
1883         (JSC::SlotVisitor::containsOpaqueRoot):
1884         (JSC::SlotVisitor::containsOpaqueRootTriState):
1885
1886 2016-12-13  Filip Pizlo  <fpizlo@apple.com>
1887
1888         Make opaque root scanning truly constraint-based
1889         https://bugs.webkit.org/show_bug.cgi?id=165760
1890
1891         Reviewed by Saam Barati.
1892         
1893         We have bugs when visitChildren() changes its mind about what opaque root to add, since
1894         we don't have barriers on opaque roots. This supposedly once worked for generational GC,
1895         and I started adding more barriers to support concurrent GC. But I think that the real
1896         bug here is that we want the JSObject->OpaqueRoot to be evaluated as a constraint that
1897         participates in the fixpoint. A constraint is different from the normal visiting in that
1898         the GC will not wait for a barrier to rescan the object.
1899         
1900         So, it's now possible for any visitChildren() method to become a constraint by calling
1901         slotVisitor.rescanAsConstraint(). Because opaque roots are constraints, addOpaqueRoot()
1902         does rescanAsConstraint() for you.
1903         
1904         The constraint set is simply a HashSet<JSCell*> that accumulates with every
1905         rescanAsConstraint() call and is only cleared at the start of full GC. This trivially
1906         resolves most classes of GC bugs that would have arisen from opaque roots being changed
1907         in a way that the GC did not anticipate.
1908         
1909         Looks like this is perf-neutral.
1910         
1911         * heap/Heap.cpp:
1912         (JSC::Heap::markToFixpoint):
1913         (JSC::Heap::setMutatorShouldBeFenced):
1914         (JSC::Heap::writeBarrierOpaqueRootSlow): Deleted.
1915         (JSC::Heap::addMutatorShouldBeFencedCache): Deleted.
1916         * heap/Heap.h:
1917         * heap/HeapInlines.h:
1918         (JSC::Heap::writeBarrierOpaqueRoot): Deleted.
1919         * heap/MarkedSpace.cpp:
1920         (JSC::MarkedSpace::visitWeakSets):
1921         * heap/MarkedSpace.h:
1922         * heap/SlotVisitor.cpp:
1923         (JSC::SlotVisitor::visitChildren):
1924         (JSC::SlotVisitor::visitSubsequently):
1925         (JSC::SlotVisitor::drain):
1926         (JSC::SlotVisitor::addOpaqueRoot):
1927         (JSC::SlotVisitor::rescanAsConstraint):
1928         (JSC::SlotVisitor::mergeIfNecessary):
1929         (JSC::SlotVisitor::mergeOpaqueRootsAndConstraints):
1930         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
1931         * heap/SlotVisitor.h:
1932         * heap/SlotVisitorInlines.h:
1933         (JSC::SlotVisitor::reportExtraMemoryVisited):
1934         (JSC::SlotVisitor::reportExternalMemoryVisited):
1935         (JSC::SlotVisitor::didNotRace):
1936         * heap/WeakBlock.cpp:
1937         (JSC::WeakBlock::specializedVisit):
1938         (JSC::WeakBlock::visit):
1939         * heap/WeakBlock.h:
1940         * heap/WeakSet.h:
1941         (JSC::WeakSet::visit):
1942
1943 2016-12-13  Commit Queue  <commit-queue@webkit.org>
1944
1945         Unreviewed, rolling out r209725.
1946         https://bugs.webkit.org/show_bug.cgi?id=165811
1947
1948         "Broke ARMv7 builds" (Requested by msaboff on #webkit).
1949
1950         Reverted changeset:
1951
1952         "REGRESSION(r209653): speedometer crashes making virtual slow
1953         path tailcalls"
1954         https://bugs.webkit.org/show_bug.cgi?id=165748
1955         http://trac.webkit.org/changeset/209725
1956
1957 2016-12-13  Filip Pizlo  <fpizlo@apple.com>
1958
1959         Unreviewed, revert the collectorPermittedIdleRatio back to 0 because of 100MB
1960         regression on membuster. Also, it didn't seem to help perf.
1961
1962         * runtime/Options.h:
1963
1964 2016-12-13  JF Bastien  <jfbastien@apple.com>
1965
1966         [WTF] Turn tryMakeString(), makeString() into variadic templates
1967         https://bugs.webkit.org/show_bug.cgi?id=147142
1968
1969         Reviewed by Mark Lam.
1970
1971         * runtime/JSStringBuilder.h:
1972         (JSC::jsMakeNontrivialString): remove WTF:: prefix, it isn't needed anymore
1973         * runtime/Lookup.cpp:
1974         (JSC::reifyStaticAccessor): remove WTF:: prefix, it isn't needed anymore
1975         * runtime/ObjectPrototype.cpp:
1976         (JSC::objectProtoFuncToString): remove WTF:: prefix, it isn't needed anymore
1977
1978 2016-12-12  Mark Lam  <mark.lam@apple.com>
1979
1980         Rename BytecodeGenerator's ControlFlowContext to ControlFlowScope.
1981         https://bugs.webkit.org/show_bug.cgi?id=165777
1982
1983         Reviewed by Keith Miller.
1984
1985         The existing code sometimes refer to ControlFlowContext (and associated references)
1986         as context, and sometimes as scope.  Let's be consistent and always call it a scope.
1987
1988         Also renamed push/popScopedControlFlowContext() to push/popLocalControlFlowScope()
1989         because these are only used when we inc/dec the m_localScopeDepth.
1990
1991         * bytecompiler/BytecodeGenerator.cpp:
1992         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
1993         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1994         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1995         (JSC::BytecodeGenerator::emitPushWithScope):
1996         (JSC::BytecodeGenerator::emitPopWithScope):
1997         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1998         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
1999         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
2000         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
2001         (JSC::BytecodeGenerator::emitComplexPopScopes):
2002         (JSC::BytecodeGenerator::emitPopScopes):
2003         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
2004         (JSC::BytecodeGenerator::popLocalControlFlowScope):
2005         (JSC::BytecodeGenerator::emitEnumeration):
2006         (JSC::BytecodeGenerator::pushFinallyContext): Deleted.
2007         (JSC::BytecodeGenerator::pushIteratorCloseContext): Deleted.
2008         (JSC::BytecodeGenerator::popFinallyContext): Deleted.
2009         (JSC::BytecodeGenerator::popIteratorCloseContext): Deleted.
2010         (JSC::BytecodeGenerator::pushScopedControlFlowContext): Deleted.
2011         (JSC::BytecodeGenerator::popScopedControlFlowContext): Deleted.
2012         * bytecompiler/BytecodeGenerator.h:
2013         * bytecompiler/NodesCodegen.cpp:
2014         (JSC::TryNode::emitBytecode):
2015
2016 2016-12-12  Filip Pizlo  <fpizlo@apple.com>
2017
2018         GC scheduler should avoid consecutive pauses
2019         https://bugs.webkit.org/show_bug.cgi?id=165758
2020
2021         Reviewed by Michael Saboff.
2022         
2023         This factors out the scheduler from lambdas in Heap::markToFixpoint to an actual class.
2024         It's called the SpaceTimeScheduler because it is a linear controller that ties the
2025         amount of time you spend on things to the amount of space you are using.
2026         
2027         This patch uses this refactoring to fix a bug where the GC would pause even though we
2028         still had time during a mutator timeslice. This is a 15% improvement on
2029         JetStream/splay-latency. Seems neutral on everything else. However, it's not at all
2030         clear if this is the right policy or not since retreating wavefront can sometimes be so
2031         sensitive to scheduling decisions. For this reason, there is a tunable option that lets
2032         you decide how long the GC will sit idle before the start of its timeslice.
2033         
2034         So, we can revert this policy change in this patch without reverting the patch.
2035
2036         * CMakeLists.txt:
2037         * JavaScriptCore.xcodeproj/project.pbxproj:
2038         * heap/Heap.cpp:
2039         (JSC::Heap::markToFixpoint):
2040         * heap/Heap.h:
2041         * heap/SpaceTimeScheduler.cpp: Added.
2042         (JSC::SpaceTimeScheduler::Decision::targetMutatorUtilization):
2043         (JSC::SpaceTimeScheduler::Decision::targetCollectorUtilization):
2044         (JSC::SpaceTimeScheduler::Decision::elapsedInPeriod):
2045         (JSC::SpaceTimeScheduler::Decision::phase):
2046         (JSC::SpaceTimeScheduler::Decision::shouldBeResumed):
2047         (JSC::SpaceTimeScheduler::Decision::timeToResume):
2048         (JSC::SpaceTimeScheduler::Decision::timeToStop):
2049         (JSC::SpaceTimeScheduler::SpaceTimeScheduler):
2050         (JSC::SpaceTimeScheduler::snapPhase):
2051         (JSC::SpaceTimeScheduler::currentDecision):
2052         * heap/SpaceTimeScheduler.h: Added.
2053         (JSC::SpaceTimeScheduler::Decision::Decision):
2054         (JSC::SpaceTimeScheduler::Decision::operator bool):
2055         * runtime/Options.h:
2056
2057 2016-12-12  Michael Saboff  <msaboff@apple.com>
2058
2059         REGRESSION(r209653): speedometer crashes making virtual slow path tailcalls
2060         https://bugs.webkit.org/show_bug.cgi?id=165748
2061
2062         Reviewed by Filip Pizlo.
2063
2064         The virtual slow path for tailcalls always passes arguments on the stack.
2065         The fix here is to link to the stack argument entrypoint instead of a register
2066         argument entrypoint.
2067
2068         While fixing this bug, I found that we weren't clearing the code origin when
2069         shuffling the call frame for a register argument tailcall.
2070
2071         Also rolling back in r209653, r209654, r209663, and r209673.
2072
2073         * jit/CallFrameShuffler.cpp:
2074         (JSC::CallFrameShuffler::prepareAny):
2075         * jit/ThunkGenerators.cpp:
2076         (JSC::virtualThunkFor):
2077
2078 2016-12-12  Mark Lam  <mark.lam@apple.com>
2079
2080         Rename BytecodeGenerator's m_symbolTableStack to m_lexicalScopeStack.
2081         https://bugs.webkit.org/show_bug.cgi?id=165768
2082
2083         Reviewed by Saam Barati.
2084
2085         The lexical scope in "m_lexicalScopeStack" here refers to a pair of { } in the
2086         source code that bounds the scope of variables.
2087
2088         There are 4 places in the code where we call m_symbolTableStack.append() to
2089         append a new stack entry.  In only 3 of the 4 cases, a symbol table is provided
2090         in the new stack entry.  In all 4 cases, a scope register is provided in the new
2091         stack entry.
2092
2093         Also, 3 of the 4 functions that appends an entry to this stack are named:
2094         1. initializeVarLexicalEnvironment()
2095         2. pushLexicalScopeInternal()
2096         3. emitPushWithScope()
2097
2098         The 4th function is the BytecodeGenerator constructor where it pushes the scope
2099         for a module environment.
2100
2101         Based on these details, m_lexicalScopeStack is a better name for this stack than
2102         m_symbolTableStack.
2103
2104         * bytecompiler/BytecodeGenerator.cpp:
2105         (JSC::BytecodeGenerator::BytecodeGenerator):
2106         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
2107         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
2108         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
2109         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
2110         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
2111         (JSC::BytecodeGenerator::popLexicalScopeInternal):
2112         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
2113         (JSC::BytecodeGenerator::variable):
2114         (JSC::BytecodeGenerator::resolveType):
2115         (JSC::BytecodeGenerator::emitResolveScope):
2116         (JSC::BytecodeGenerator::emitPushWithScope):
2117         (JSC::BytecodeGenerator::emitPopWithScope):
2118         (JSC::BytecodeGenerator::pushFinallyContext):
2119         (JSC::BytecodeGenerator::pushIteratorCloseContext):
2120         (JSC::BytecodeGenerator::emitComplexPopScopes):
2121         (JSC::BytecodeGenerator::popTryAndEmitCatch):
2122         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
2123         * bytecompiler/BytecodeGenerator.h:
2124
2125 2016-12-12  Saam Barati  <sbarati@apple.com>
2126
2127         Unreviewed. Try to fix the cloop build.
2128
2129         * interpreter/StackVisitor.cpp:
2130         (JSC::StackVisitor::Frame::calleeSaveRegisters):
2131         * interpreter/StackVisitor.h:
2132
2133 2016-12-12  Michael Saboff  <msaboff@apple.com>
2134
2135         FTL: Dumping disassembly requires that code origin is set when making polymorphic tail calls.
2136         https://bugs.webkit.org/show_bug.cgi?id=165747
2137
2138         Reviewed by Filip Pizlo.
2139
2140         Setting the code origin needs to be done for both the fast and slow path as we might need
2141         it when linking a polymorphic or virtual call stub.
2142
2143         * ftl/FTLLowerDFGToB3.cpp:
2144         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
2145
2146 2016-12-11  Saam Barati  <sbarati@apple.com>
2147
2148         Unreviewed. Try to fix the linux build.
2149
2150         * runtime/StackFrame.h:
2151
2152 2016-12-11  Saam Barati  <sbarati@apple.com>
2153
2154         We should be able to throw exceptions from Wasm code and when Wasm frames are on the stack
2155         https://bugs.webkit.org/show_bug.cgi?id=165429
2156
2157         Reviewed by Keith Miller.
2158
2159         This patch teaches the stack walking runtime about wasm.
2160         To do this, I taught StackVisitor that a callee is not
2161         always an object.
2162
2163         To be able to unwind callee save registers properly, I've given
2164         JSWebAssemblyCallee a list of RegisterAtOffsetList for the callee
2165         saves that B3 saved in the prologue. Also, because we have two
2166         B3Compilations per wasm function, one for wasm entrypoint, and
2167         one for the JS entrypoint, I needed to create a callee for each
2168         because they each might spill callee save registers.
2169
2170         I also fixed a bug inside the Wasm::Memory constructor where we
2171         were trying to mmap the same number of bytes even after the first
2172         mmap failed. We should start by trying to mmap the maximum bytes,
2173         and if that fails, fall back to the specified initial bytes. However,
2174         the code was just mmapping the maximum twice. I've fixed that and
2175         also added a RELEASE_ASSERT_NOT_REACHED() for when the second mmap
2176         fails along with a FIXME to throw an OOM error.
2177
2178         There was a second bug I fixed where JSModuleRecord was calling
2179         visitWeak on its CallLinkInfos inside ::visitChldren(). It needs
2180         to do this after marking. I changed JSModuleRecord to do what
2181         CodeBlock does and call visitWeak on its CallLinkInfos inside
2182         an UnconditionalFinalizer.
2183
2184         * API/JSContextRef.cpp:
2185         (BacktraceFunctor::operator()):
2186         * inspector/ScriptCallStackFactory.cpp:
2187         (Inspector::createScriptCallStackFromException):
2188         * interpreter/CallFrame.cpp:
2189         (JSC::CallFrame::vmEntryGlobalObject):
2190         * interpreter/CallFrame.h:
2191         (JSC::ExecState::callee):
2192         * interpreter/Interpreter.cpp:
2193         (JSC::GetStackTraceFunctor::operator()):
2194         (JSC::UnwindFunctor::operator()):
2195         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2196         * interpreter/Interpreter.h:
2197         * interpreter/ShadowChicken.cpp:
2198         (JSC::ShadowChicken::update):
2199         * interpreter/StackVisitor.cpp:
2200         (JSC::StackVisitor::StackVisitor):
2201         (JSC::StackVisitor::readFrame):
2202         (JSC::StackVisitor::readNonInlinedFrame):
2203         (JSC::StackVisitor::readInlinedFrame):
2204         (JSC::StackVisitor::Frame::isWasmFrame):
2205         (JSC::StackVisitor::Frame::codeType):
2206         (JSC::StackVisitor::Frame::calleeSaveRegisters):
2207         (JSC::StackVisitor::Frame::functionName):
2208         (JSC::StackVisitor::Frame::sourceURL):
2209         (JSC::StackVisitor::Frame::toString):
2210         (JSC::StackVisitor::Frame::hasLineAndColumnInfo):
2211         (JSC::StackVisitor::Frame::setToEnd):
2212         * interpreter/StackVisitor.h:
2213         (JSC::StackVisitor::Frame::callee):
2214         (JSC::StackVisitor::Frame::isNativeFrame):
2215         (JSC::StackVisitor::Frame::isJSFrame): Deleted.
2216         * jsc.cpp:
2217         (callWasmFunction):
2218         (functionTestWasmModuleFunctions):
2219         * runtime/Error.cpp:
2220         (JSC::addErrorInfoAndGetBytecodeOffset):
2221         * runtime/JSCell.cpp:
2222         (JSC::JSCell::isAnyWasmCallee):
2223         * runtime/JSCell.h:
2224         * runtime/JSFunction.cpp:
2225         (JSC::RetrieveArgumentsFunctor::operator()):
2226         (JSC::RetrieveCallerFunctionFunctor::operator()):
2227         * runtime/StackFrame.cpp:
2228         (JSC::StackFrame::sourceID):
2229         (JSC::StackFrame::sourceURL):
2230         (JSC::StackFrame::functionName):
2231         (JSC::StackFrame::computeLineAndColumn):
2232         (JSC::StackFrame::toString):
2233         * runtime/StackFrame.h:
2234         (JSC::StackFrame::StackFrame):
2235         (JSC::StackFrame::hasLineAndColumnInfo):
2236         (JSC::StackFrame::hasBytecodeOffset):
2237         (JSC::StackFrame::bytecodeOffset):
2238         (JSC::StackFrame::isNative): Deleted.
2239         * runtime/VM.h:
2240         * wasm/WasmB3IRGenerator.cpp:
2241         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2242         (JSC::Wasm::createJSToWasmWrapper):
2243         (JSC::Wasm::parseAndCompile):
2244         * wasm/WasmCallingConvention.h:
2245         (JSC::Wasm::CallingConvention::setupFrameInPrologue):
2246         * wasm/WasmFormat.h:
2247         * wasm/WasmMemory.cpp:
2248         (JSC::Wasm::Memory::Memory):
2249         * wasm/WasmMemory.h:
2250         (JSC::Wasm::Memory::isValid):
2251         * wasm/WasmPlan.cpp:
2252         (JSC::Wasm::Plan::run):
2253         (JSC::Wasm::Plan::initializeCallees):
2254         * wasm/WasmPlan.h:
2255         (JSC::Wasm::Plan::jsToWasmEntryPointForFunction): Deleted.
2256         * wasm/js/JSWebAssemblyCallee.cpp:
2257         (JSC::JSWebAssemblyCallee::finishCreation):
2258         * wasm/js/JSWebAssemblyCallee.h:
2259         (JSC::JSWebAssemblyCallee::create):
2260         (JSC::JSWebAssemblyCallee::entrypoint):
2261         (JSC::JSWebAssemblyCallee::calleeSaveRegisters):
2262         (JSC::JSWebAssemblyCallee::jsToWasmEntryPoint): Deleted.
2263         * wasm/js/JSWebAssemblyModule.cpp:
2264         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
2265         (JSC::JSWebAssemblyModule::visitChildren):
2266         (JSC::JSWebAssemblyModule::UnconditionalFinalizer::finalizeUnconditionally):
2267         * wasm/js/JSWebAssemblyModule.h:
2268         (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
2269         (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
2270         (JSC::JSWebAssemblyModule::setJSEntrypointCallee):
2271         (JSC::JSWebAssemblyModule::setWasmEntrypointCallee):
2272         (JSC::JSWebAssemblyModule::allocationSize):
2273         (JSC::JSWebAssemblyModule::calleeFromFunctionIndexSpace): Deleted.
2274         * wasm/js/JSWebAssemblyRuntimeError.h:
2275         * wasm/js/WebAssemblyFunction.cpp:
2276         (JSC::WebAssemblyFunction::call):
2277         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2278         (JSC::constructJSWebAssemblyInstance):
2279         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2280         (JSC::constructJSWebAssemblyMemory):
2281         * wasm/js/WebAssemblyModuleConstructor.cpp:
2282         (JSC::constructJSWebAssemblyModule):
2283         * wasm/js/WebAssemblyModuleRecord.cpp:
2284         (JSC::WebAssemblyModuleRecord::link):
2285
2286 2016-12-11  Filip Pizlo  <fpizlo@apple.com>
2287
2288         Re-enable concurrent GC.
2289
2290         Rubber stampted by Saam Barati.
2291         
2292         This change actually landed in r209692 by accident.
2293
2294         * runtime/Options.h:
2295
2296 2016-12-10  Filip Pizlo  <fpizlo@apple.com>
2297
2298         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
2299         https://bugs.webkit.org/show_bug.cgi?id=165741
2300
2301         Reviewed by Saam Barati.
2302         
2303         MarkedBlock::marksConveyLivenessDuringMarking thought that the off-by-one marking
2304         version indicated liveness during any collection when it's just during full collection.
2305         One of its users - MarkedBlock::sweep - knew this and had a special case, but the other
2306         one - MarkedBlock::isLive - didn't. So, I moved the special case into
2307         marksConveyLivenessDuringMarking.
2308         
2309         Also, this cleans up some remaining bitvector races.
2310         
2311         To find this bug, I significantly strengthened our assertions.
2312
2313         * CMakeLists.txt:
2314         * JavaScriptCore.xcodeproj/project.pbxproj:
2315         * heap/CellContainer.cpp: Added.
2316         (JSC::CellContainer::isNewlyAllocated):
2317         * heap/CellContainer.h:
2318         * heap/MarkedAllocator.cpp:
2319         (JSC::MarkedAllocator::addBlock):
2320         (JSC::MarkedAllocator::removeBlock):
2321         (JSC::MarkedAllocator::dumpBits):
2322         * heap/MarkedAllocator.h:
2323         (JSC::MarkedAllocator::forEachBitVector):
2324         (JSC::MarkedAllocator::forEachBitVectorWithName):
2325         * heap/MarkedBlock.cpp:
2326         (JSC::MarkedBlock::tryCreate):
2327         (JSC::MarkedBlock::Handle::~Handle):
2328         (JSC::MarkedBlock::MarkedBlock):
2329         (JSC::MarkedBlock::Handle::specializedSweep):
2330         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
2331         (JSC::MarkedBlock::Handle::stopAllocating):
2332         (JSC::MarkedBlock::Handle::resumeAllocating):
2333         (JSC::MarkedBlock::aboutToMarkSlow):
2334         (JSC::MarkedBlock::Handle::didConsumeFreeList):
2335         (JSC::MarkedBlock::Handle::dumpState):
2336         * heap/MarkedBlock.h:
2337         (JSC::MarkedBlock::markingVersion):
2338         (JSC::MarkedBlock::isMarkedRaw):
2339         (JSC::MarkedBlock::isMarked):
2340         * heap/MarkedBlockInlines.h:
2341         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
2342         * heap/SlotVisitor.cpp:
2343         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
2344         * runtime/Options.cpp:
2345         (JSC::recomputeDependentOptions):
2346         * runtime/StructureIDTable.h:
2347         (JSC::StructureIDTable::size):
2348         (JSC::StructureIDTable::get):
2349
2350 2016-12-10  Filip Pizlo  <fpizlo@apple.com>
2351
2352         The DOM should have an advancing wavefront opaque root barrier
2353         https://bugs.webkit.org/show_bug.cgi?id=165712
2354
2355         Reviewed by Yusuke Suzuki.
2356         
2357         This exposes the ability to fire an advancing wavefront barrier on opaque roots. It also
2358         gives clients the ability to maintain their own cache of whether that barrier needs to
2359         be enabled.
2360         
2361         The DOM uses this to enable a very cheap barrier on the DOM. This is neutral on
2362         Speedometer and fixes another concurrent GC crash.
2363
2364         * heap/Heap.cpp:
2365         (JSC::Heap::beginMarking):
2366         (JSC::Heap::endMarking):
2367         (JSC::Heap::writeBarrierOpaqueRootSlow):
2368         (JSC::Heap::addMutatorShouldBeFencedCache):
2369         (JSC::Heap::setMutatorShouldBeFenced):
2370         * heap/Heap.h:
2371         * heap/HeapInlines.h:
2372         (JSC::writeBarrierOpaqueRoot):
2373
2374 2016-12-10  Commit Queue  <commit-queue@webkit.org>
2375
2376         Unreviewed, rolling out r209653, r209654, r209663, and
2377         r209673.
2378         https://bugs.webkit.org/show_bug.cgi?id=165739
2379
2380         speedometer crashes (Requested by pizlo on #webkit).
2381
2382         Reverted changesets:
2383
2384         "JSVALUE64: Pass arguments in platform argument registers when
2385         making JavaScript calls"
2386         https://bugs.webkit.org/show_bug.cgi?id=160355
2387         http://trac.webkit.org/changeset/209653
2388
2389         "Unreviewed build fix for 32 bit builds."
2390         http://trac.webkit.org/changeset/209654
2391
2392         "Unreviewed build fix for the CLOOP after r209653"
2393         http://trac.webkit.org/changeset/209663
2394
2395         "REGRESSION(r209653) Crash in CallFrameShuffler::snapshot()"
2396         https://bugs.webkit.org/show_bug.cgi?id=165728
2397         http://trac.webkit.org/changeset/209673
2398
2399 2016-12-10  Michael Saboff  <msaboff@apple.com>
2400
2401         REGRESSION(r209653) Crash in CallFrameShuffler::snapshot()
2402         https://bugs.webkit.org/show_bug.cgi?id=165728
2403
2404         Reviewed by Filip Pizlo.
2405
2406         It can be the case that a JSValueReg's CachedRecovery is the source for mutliple
2407         GPRs. We only store the CachedRecovery in one slot of m_newRegisters to simplify
2408         the recovery process. This is also done for the case where the recovery source
2409         and destination are the same GPR.
2410
2411         In light of this change, snapshot needs to be taught that one CacheRecovery is
2412         the source for multiple registers.  This is done by using a two step process.
2413         First find all the argument CachedRecovery's and create a vector mapping all of
2414         the target GPRs and the source recovery.  Then use that vector to get the
2415         recovery for each register.
2416
2417         * jit/CallFrameShuffler.h:
2418         (JSC::CallFrameShuffler::snapshot):
2419
2420 2016-12-10  Keith Miller  <keith_miller@apple.com>
2421
2422         Fix indirect_call if the result type is used.
2423         https://bugs.webkit.org/show_bug.cgi?id=165727
2424
2425         Reviewed by Michael Saboff.
2426
2427         The patchpoint for indirect_call assumed that the callee would be
2428         in params[0]. This is not the case, however, if the callee returns
2429         a value.
2430
2431         * wasm/WasmB3IRGenerator.cpp:
2432         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2433
2434 2016-12-10  Konstantin Tokarev  <annulen@yandex.ru>
2435
2436         [cmake] Include WTF, JSC, and WebCore headers automatically to targers using them
2437         https://bugs.webkit.org/show_bug.cgi?id=165686
2438
2439         Reviewed by Michael Catanzaro.
2440
2441         This change reduces duplication of include path lists between modules,
2442         and reduces future need for fixes like r209605 (broken build because of
2443         WebCore header suddenly becoming used in WebKit2).
2444
2445         * CMakeLists.txt:
2446         * PlatformEfl.cmake:
2447         * PlatformGTK.cmake:
2448         * PlatformJSCOnly.cmake:
2449         * PlatformMac.cmake:
2450
2451 2016-12-10  Michael Saboff  <msaboff@apple.com>
2452
2453         Unreviewed build fix for the CLOOP after r209653
2454
2455         * jit/GPRInfo.h:
2456         Provided a definition for NUMBER_OF_JS_FUNCTION_ARGUMENT_REGISTERS when the JIT is disabled.
2457         * jit/JITEntryPoints.h:
2458         Removed #if ENABLE(JIT) protection around contents.
2459
2460 2016-12-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2461
2462         [JSC] Module namespace object behaves like immutable prototype exotic object
2463         https://bugs.webkit.org/show_bug.cgi?id=165598
2464
2465         Reviewed by Mark Lam.
2466
2467         In the latest ECMA262 draft, the module namespace object behaves like immutable prototype exotic object.
2468         https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects-setprototypeof-v
2469
2470         * runtime/JSModuleNamespaceObject.h:
2471
2472 2016-12-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2473
2474         REGRESSION(r208791): Assertion in testb3
2475         https://bugs.webkit.org/show_bug.cgi?id=165651
2476
2477         Reviewed by Saam Barati.
2478
2479         Accidentally we always use edx/rdx for the result of UDiv/UMod.
2480         But it is incorrect. We should use eax/rax for the result of UDiv.
2481
2482         * b3/B3LowerToAir.cpp:
2483         (JSC::B3::Air::LowerToAir::lowerX86UDiv):
2484
2485 2016-12-09  Michael Saboff  <msaboff@apple.com>
2486
2487         Unreviewed build fix for 32 bit builds.
2488
2489         * dfg/DFGMinifiedNode.h:
2490         (JSC::DFG::MinifiedNode::argumentIndex): Added a static_cast<unsigned>().
2491
2492 2016-12-09  Michael Saboff  <msaboff@apple.com>
2493
2494         JSVALUE64: Pass arguments in platform argument registers when making JavaScript calls
2495         https://bugs.webkit.org/show_bug.cgi?id=160355
2496
2497         Reviewed by Filip Pizlo.
2498
2499         This patch implements passing JavaScript function arguments in registers for 64 bit platforms.
2500
2501         The implemented convention follows the ABI conventions for the associated platform.
2502         The first two arguments are the callee and argument count, the rest of the argument registers
2503         contain "this" and following argument until all platform argument registers are exhausted.
2504         Arguments beyond what fit in registers are placed on the stack in the same location as
2505         before this patch.
2506
2507         For X86-64 non-Windows platforms, there are 6 argument registers specified in the related ABI.
2508         ARM64 has had argument registers.  This allows for 4 or 6 parameter values to be placed in
2509         registers on these respective platforms.  This patch doesn't implement passing arguments in
2510         registers for 32 bit platform, since most platforms have at most 4 argument registers
2511         specified and 32 bit platforms use two 32 bit registers/memory locations to store one JSValue.
2512
2513         The call frame on the stack in unchanged in format and the arguments that are passed in
2514         registers use the corresponding call frame location as a spill location. Arguments can
2515         also be passed on the stack. The LLInt, baseline JIT'ed code as well as the initial entry
2516         from C++ code base arguments on the stack. DFG s and FTL generated code pass arguments
2517         via registers. All callees can accept arguments either in registers or on the stack.
2518         The callee is responsible for moving argument to its preferred location.
2519
2520         The multiple entry points to JavaSCript code is now handled via the JITEntryPoints class and
2521         related code.  That class now has entries for StackArgsArityCheckNotRequired,
2522         StackArgsMustCheckArity and for platforms that support registers arguments,
2523         RegisterArgsArityCheckNotRequired, RegisterArgsMustCheckArity as well as and additional
2524         RegisterArgsPossibleExtraArgs entry point when extra registers argument are passed.
2525         This last case is needed to spill those extra arguments to the corresponding call frame
2526         slots.
2527
2528         * JavaScriptCore.xcodeproj/project.pbxproj:
2529         * b3/B3ArgumentRegValue.h:
2530         * b3/B3Validate.cpp:
2531         * bytecode/CallLinkInfo.cpp:
2532         (JSC::CallLinkInfo::CallLinkInfo):
2533         * bytecode/CallLinkInfo.h:
2534         (JSC::CallLinkInfo::setUpCall):
2535         (JSC::CallLinkInfo::argumentsLocation):
2536         (JSC::CallLinkInfo::argumentsInRegisters):
2537         * bytecode/PolymorphicAccess.cpp:
2538         (JSC::AccessCase::generateImpl):
2539         * dfg/DFGAbstractInterpreterInlines.h:
2540         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2541         * dfg/DFGByteCodeParser.cpp:
2542         (JSC::DFG::ByteCodeParser::parseBlock):
2543         * dfg/DFGCPSRethreadingPhase.cpp:
2544         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2545         (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
2546         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2547         * dfg/DFGClobberize.h:
2548         (JSC::DFG::clobberize):
2549         * dfg/DFGCommon.h:
2550         * dfg/DFGDCEPhase.cpp:
2551         (JSC::DFG::DCEPhase::run):
2552         * dfg/DFGDoesGC.cpp:
2553         (JSC::DFG::doesGC):
2554         * dfg/DFGDriver.cpp:
2555         (JSC::DFG::compileImpl):
2556         * dfg/DFGFixupPhase.cpp:
2557         (JSC::DFG::FixupPhase::fixupNode):
2558         * dfg/DFGGenerationInfo.h:
2559         (JSC::DFG::GenerationInfo::initArgumentRegisterValue):
2560         * dfg/DFGGraph.cpp:
2561         (JSC::DFG::Graph::dump):
2562         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2563         * dfg/DFGGraph.h:
2564         (JSC::DFG::Graph::needsFlushedThis):
2565         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
2566         * dfg/DFGInPlaceAbstractState.cpp:
2567         (JSC::DFG::InPlaceAbstractState::initialize):
2568         * dfg/DFGJITCompiler.cpp:
2569         (JSC::DFG::JITCompiler::link):
2570         (JSC::DFG::JITCompiler::compile):
2571         (JSC::DFG::JITCompiler::compileFunction):
2572         (JSC::DFG::JITCompiler::compileEntry): Deleted.
2573         * dfg/DFGJITCompiler.h:
2574         (JSC::DFG::JITCompiler::addJSDirectCall):
2575         (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
2576         (JSC::DFG::JITCompiler::JSDirectCallRecord::hasSlowCall):
2577         * dfg/DFGJITFinalizer.cpp:
2578         (JSC::DFG::JITFinalizer::JITFinalizer):
2579         (JSC::DFG::JITFinalizer::finalize):
2580         (JSC::DFG::JITFinalizer::finalizeFunction):
2581         * dfg/DFGJITFinalizer.h:
2582         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2583         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
2584         * dfg/DFGMaximalFlushInsertionPhase.cpp:
2585         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
2586         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
2587         * dfg/DFGMayExit.cpp:
2588         * dfg/DFGMinifiedNode.cpp:
2589         (JSC::DFG::MinifiedNode::fromNode):
2590         * dfg/DFGMinifiedNode.h:
2591         (JSC::DFG::belongsInMinifiedGraph):
2592         * dfg/DFGNode.cpp:
2593         (JSC::DFG::Node::hasVariableAccessData):
2594         * dfg/DFGNode.h:
2595         (JSC::DFG::Node::accessesStack):
2596         (JSC::DFG::Node::setVariableAccessData):
2597         (JSC::DFG::Node::hasArgumentRegisterIndex):
2598         (JSC::DFG::Node::argumentRegisterIndex):
2599         * dfg/DFGNodeType.h:
2600         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2601         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
2602         * dfg/DFGOSREntrypointCreationPhase.cpp:
2603         (JSC::DFG::OSREntrypointCreationPhase::run):
2604         * dfg/DFGPlan.cpp:
2605         (JSC::DFG::Plan::compileInThreadImpl):
2606         * dfg/DFGPreciseLocalClobberize.h:
2607         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2608         * dfg/DFGPredictionInjectionPhase.cpp:
2609         (JSC::DFG::PredictionInjectionPhase::run):
2610         * dfg/DFGPredictionPropagationPhase.cpp:
2611         * dfg/DFGPutStackSinkingPhase.cpp:
2612         * dfg/DFGRegisterBank.h:
2613         (JSC::DFG::RegisterBank::iterator::unlock):
2614         (JSC::DFG::RegisterBank::unlockAtIndex):
2615         * dfg/DFGSSAConversionPhase.cpp:
2616         (JSC::DFG::SSAConversionPhase::run):
2617         * dfg/DFGSafeToExecute.h:
2618         (JSC::DFG::safeToExecute):
2619         * dfg/DFGSpeculativeJIT.cpp:
2620         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2621         (JSC::DFG::SpeculativeJIT::clearGenerationInfo):
2622         (JSC::DFG::dumpRegisterInfo):
2623         (JSC::DFG::SpeculativeJIT::dump):
2624         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2625         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
2626         (JSC::DFG::SpeculativeJIT::setupArgumentRegistersForEntry):
2627         (JSC::DFG::SpeculativeJIT::compile):
2628         * dfg/DFGSpeculativeJIT.h:
2629         (JSC::DFG::SpeculativeJIT::allocate):
2630         (JSC::DFG::SpeculativeJIT::spill):
2631         (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
2632         (JSC::DFG::JSValueOperand::JSValueOperand):
2633         (JSC::DFG::JSValueOperand::gprUseSpecific):
2634         * dfg/DFGSpeculativeJIT32_64.cpp:
2635         (JSC::DFG::SpeculativeJIT::emitCall):
2636         (JSC::DFG::SpeculativeJIT::compile):
2637         * dfg/DFGSpeculativeJIT64.cpp:
2638         (JSC::DFG::SpeculativeJIT::fillJSValue):
2639         (JSC::DFG::SpeculativeJIT::emitCall):
2640         (JSC::DFG::SpeculativeJIT::compile):
2641         * dfg/DFGStrengthReductionPhase.cpp:
2642         (JSC::DFG::StrengthReductionPhase::handleNode):
2643         * dfg/DFGThunks.cpp:
2644         (JSC::DFG::osrEntryThunkGenerator):
2645         * dfg/DFGVariableEventStream.cpp:
2646         (JSC::DFG::VariableEventStream::reconstruct):
2647         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2648         (JSC::DFG::VirtualRegisterAllocationPhase::allocateRegister):
2649         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2650         * ftl/FTLCapabilities.cpp:
2651         (JSC::FTL::canCompile):
2652         * ftl/FTLJITCode.cpp:
2653         (JSC::FTL::JITCode::~JITCode):
2654         (JSC::FTL::JITCode::initializeEntrypointThunk):
2655         (JSC::FTL::JITCode::setEntryFor):
2656         (JSC::FTL::JITCode::addressForCall):
2657         (JSC::FTL::JITCode::executableAddressAtOffset):
2658         (JSC::FTL::JITCode::initializeAddressForCall): Deleted.
2659         (JSC::FTL::JITCode::initializeArityCheckEntrypoint): Deleted.
2660         * ftl/FTLJITCode.h:
2661         * ftl/FTLJITFinalizer.cpp:
2662         (JSC::FTL::JITFinalizer::finalizeFunction):
2663         * ftl/FTLLink.cpp:
2664         (JSC::FTL::link):
2665         * ftl/FTLLowerDFGToB3.cpp:
2666         (JSC::FTL::DFG::LowerDFGToB3::lower):
2667         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2668         (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentRegister):
2669         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
2670         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
2671         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
2672         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
2673         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
2674         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
2675         * ftl/FTLOSREntry.cpp:
2676         (JSC::FTL::prepareOSREntry):
2677         * ftl/FTLOutput.cpp:
2678         (JSC::FTL::Output::argumentRegister):
2679         (JSC::FTL::Output::argumentRegisterInt32):
2680         * ftl/FTLOutput.h:
2681         * interpreter/ShadowChicken.cpp:
2682         (JSC::ShadowChicken::update):
2683         * jit/AssemblyHelpers.cpp:
2684         (JSC::AssemblyHelpers::emitDumbVirtualCall):
2685         * jit/AssemblyHelpers.h:
2686         (JSC::AssemblyHelpers::spillArgumentRegistersToFrameBeforePrologue):
2687         (JSC::AssemblyHelpers::spillArgumentRegistersToFrame):
2688         (JSC::AssemblyHelpers::fillArgumentRegistersFromFrameBeforePrologue):
2689         (JSC::AssemblyHelpers::emitPutArgumentToCallFrameBeforePrologue):
2690         (JSC::AssemblyHelpers::emitPutArgumentToCallFrame):
2691         (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderBeforePrologue):
2692         (JSC::AssemblyHelpers::emitGetFromCallFrameArgumentBeforePrologue):
2693         (JSC::AssemblyHelpers::emitGetPayloadFromCallFrameHeaderBeforePrologue):
2694         (JSC::AssemblyHelpers::incrementCounter):
2695         * jit/CachedRecovery.cpp:
2696         (JSC::CachedRecovery::addTargetJSValueRegs):
2697         * jit/CachedRecovery.h:
2698         (JSC::CachedRecovery::gprTargets):
2699         (JSC::CachedRecovery::setWantedFPR):
2700         (JSC::CachedRecovery::wantedJSValueRegs):
2701         (JSC::CachedRecovery::setWantedJSValueRegs): Deleted.
2702         * jit/CallFrameShuffleData.h:
2703         * jit/CallFrameShuffler.cpp:
2704         (JSC::CallFrameShuffler::CallFrameShuffler):
2705         (JSC::CallFrameShuffler::dump):
2706         (JSC::CallFrameShuffler::tryWrites):
2707         (JSC::CallFrameShuffler::prepareAny):
2708         * jit/CallFrameShuffler.h:
2709         (JSC::CallFrameShuffler::snapshot):
2710         (JSC::CallFrameShuffler::addNew):
2711         (JSC::CallFrameShuffler::initDangerFrontier):
2712         (JSC::CallFrameShuffler::updateDangerFrontier):
2713         (JSC::CallFrameShuffler::findDangerFrontierFrom):
2714         * jit/CallFrameShuffler64.cpp:
2715         (JSC::CallFrameShuffler::emitDisplace):
2716         * jit/GPRInfo.h:
2717         (JSC::JSValueRegs::operator==):
2718         (JSC::JSValueRegs::operator!=):
2719         (JSC::GPRInfo::toArgumentIndex):
2720         (JSC::argumentRegisterFor):
2721         (JSC::argumentRegisterForCallee):
2722         (JSC::argumentRegisterForArgumentCount):
2723         (JSC::argumentRegisterIndexForJSFunctionArgument):
2724         (JSC::jsFunctionArgumentForArgumentRegister):
2725         (JSC::argumentRegisterForFunctionArgument):
2726         (JSC::numberOfRegisterArgumentsFor):
2727         * jit/JIT.cpp:
2728         (JSC::JIT::compileWithoutLinking):
2729         (JSC::JIT::link):
2730         (JSC::JIT::compileCTINativeCall): Deleted.
2731         * jit/JIT.h:
2732         (JSC::JIT::compileNativeCallEntryPoints):
2733         * jit/JITCall.cpp:
2734         (JSC::JIT::compileSetupVarargsFrame):
2735         (JSC::JIT::compileCallEval):
2736         (JSC::JIT::compileCallEvalSlowCase):
2737         (JSC::JIT::compileOpCall):
2738         (JSC::JIT::compileOpCallSlowCase):
2739         * jit/JITCall32_64.cpp:
2740         (JSC::JIT::compileCallEvalSlowCase):
2741         (JSC::JIT::compileOpCall):
2742         (JSC::JIT::compileOpCallSlowCase):
2743         * jit/JITCode.cpp:
2744         (JSC::JITCode::execute):
2745         (JSC::DirectJITCode::DirectJITCode):
2746         (JSC::DirectJITCode::initializeEntryPoints):
2747         (JSC::DirectJITCode::addressForCall):
2748         (JSC::NativeJITCode::addressForCall):
2749         (JSC::DirectJITCode::initializeCodeRef): Deleted.
2750         * jit/JITCode.h:
2751         (JSC::JITCode::executableAddress): Deleted.
2752         * jit/JITEntryPoints.h: Added.
2753         (JSC::JITEntryPoints::JITEntryPoints):
2754         (JSC::JITEntryPoints::entryFor):
2755         (JSC::JITEntryPoints::setEntryFor):
2756         (JSC::JITEntryPoints::offsetOfEntryFor):
2757         (JSC::JITEntryPoints::registerEntryTypeForArgumentCount):
2758         (JSC::JITEntryPoints::registerEntryTypeForArgumentType):
2759         (JSC::JITEntryPoints::clearEntries):
2760         (JSC::JITEntryPoints::operator=):
2761         (JSC::JITEntryPointsWithRef::JITEntryPointsWithRef):
2762         (JSC::JITEntryPointsWithRef::codeRef):
2763         (JSC::argumentsLocationFor):
2764         (JSC::registerEntryPointTypeFor):
2765         (JSC::entryPointTypeFor):
2766         (JSC::thunkEntryPointTypeFor):
2767         (JSC::JITJSCallThunkEntryPointsWithRef::JITJSCallThunkEntryPointsWithRef):
2768         (JSC::JITJSCallThunkEntryPointsWithRef::entryFor):
2769         (JSC::JITJSCallThunkEntryPointsWithRef::setEntryFor):
2770         (JSC::JITJSCallThunkEntryPointsWithRef::offsetOfEntryFor):
2771         (JSC::JITJSCallThunkEntryPointsWithRef::clearEntries):
2772         (JSC::JITJSCallThunkEntryPointsWithRef::codeRef):
2773         (JSC::JITJSCallThunkEntryPointsWithRef::operator=):
2774         * jit/JITOpcodes.cpp:
2775         (JSC::JIT::privateCompileJITEntryNativeCall):
2776         (JSC::JIT::privateCompileCTINativeCall): Deleted.
2777         * jit/JITOpcodes32_64.cpp:
2778         (JSC::JIT::privateCompileJITEntryNativeCall):
2779         (JSC::JIT::privateCompileCTINativeCall): Deleted.
2780         * jit/JITOperations.cpp:
2781         * jit/JITThunks.cpp:
2782         (JSC::JITThunks::jitEntryNativeCall):
2783         (JSC::JITThunks::jitEntryNativeConstruct):
2784         (JSC::JITThunks::jitEntryStub):
2785         (JSC::JITThunks::jitCallThunkEntryStub):
2786         (JSC::JITThunks::hostFunctionStub):
2787         (JSC::JITThunks::ctiNativeCall): Deleted.
2788         (JSC::JITThunks::ctiNativeConstruct): Deleted.
2789         * jit/JITThunks.h:
2790         * jit/JSInterfaceJIT.h:
2791         (JSC::JSInterfaceJIT::emitJumpIfNotInt32):
2792         (JSC::JSInterfaceJIT::emitLoadInt32):
2793         * jit/RegisterSet.cpp:
2794         (JSC::RegisterSet::argumentRegisters):
2795         * jit/RegisterSet.h:
2796         * jit/Repatch.cpp:
2797         (JSC::linkSlowFor):
2798         (JSC::revertCall):
2799         (JSC::unlinkFor):
2800         (JSC::linkVirtualFor):
2801         (JSC::linkPolymorphicCall):
2802         * jit/SpecializedThunkJIT.h:
2803         (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
2804         (JSC::SpecializedThunkJIT::checkJSStringArgument):
2805         (JSC::SpecializedThunkJIT::linkFailureHere):
2806         (JSC::SpecializedThunkJIT::finalize):
2807         * jit/ThunkGenerator.h:
2808         * jit/ThunkGenerators.cpp:
2809         (JSC::createRegisterArgumentsSpillEntry):
2810         (JSC::slowPathFor):
2811         (JSC::linkCallThunkGenerator):
2812         (JSC::linkDirectCallThunkGenerator):
2813         (JSC::linkPolymorphicCallThunkGenerator):
2814         (JSC::virtualThunkFor):
2815         (JSC::nativeForGenerator):
2816         (JSC::nativeCallGenerator):
2817         (JSC::nativeTailCallGenerator):
2818         (JSC::nativeTailCallWithoutSavedTagsGenerator):
2819         (JSC::nativeConstructGenerator):
2820         (JSC::stringCharLoadRegCall):
2821         (JSC::charCodeAtThunkGenerator):
2822         (JSC::charAtThunkGenerator):
2823         (JSC::fromCharCodeThunkGenerator):
2824         (JSC::clz32ThunkGenerator):
2825         (JSC::sqrtThunkGenerator):
2826         (JSC::floorThunkGenerator):
2827         (JSC::ceilThunkGenerator):
2828         (JSC::truncThunkGenerator):
2829         (JSC::roundThunkGenerator):
2830         (JSC::expThunkGenerator):
2831         (JSC::logThunkGenerator):
2832         (JSC::absThunkGenerator):
2833         (JSC::imulThunkGenerator):
2834         (JSC::randomThunkGenerator):
2835         (JSC::boundThisNoArgsFunctionCallGenerator):
2836         * jit/ThunkGenerators.h:
2837         * jsc.cpp:
2838         (jscmain):
2839         * llint/LLIntEntrypoint.cpp:
2840         (JSC::LLInt::setFunctionEntrypoint):
2841         (JSC::LLInt::setEvalEntrypoint):
2842         (JSC::LLInt::setProgramEntrypoint):
2843         (JSC::LLInt::setModuleProgramEntrypoint):
2844         * llint/LLIntSlowPaths.cpp:
2845         (JSC::LLInt::entryOSR):
2846         (JSC::LLInt::setUpCall):
2847         * llint/LLIntThunks.cpp:
2848         (JSC::LLInt::generateThunkWithJumpTo):
2849         (JSC::LLInt::functionForRegisterCallEntryThunkGenerator):
2850         (JSC::LLInt::functionForStackCallEntryThunkGenerator):
2851         (JSC::LLInt::functionForRegisterConstructEntryThunkGenerator):
2852         (JSC::LLInt::functionForStackConstructEntryThunkGenerator):
2853         (JSC::LLInt::functionForRegisterCallArityCheckThunkGenerator):
2854         (JSC::LLInt::functionForStackCallArityCheckThunkGenerator):
2855         (JSC::LLInt::functionForRegisterConstructArityCheckThunkGenerator):
2856         (JSC::LLInt::functionForStackConstructArityCheckThunkGenerator):
2857         (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
2858         (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
2859         (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
2860         (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
2861         * llint/LLIntThunks.h:
2862         * runtime/ArityCheckMode.h:
2863         * runtime/ExecutableBase.cpp:
2864         (JSC::ExecutableBase::clearCode):
2865         * runtime/ExecutableBase.h:
2866         (JSC::ExecutableBase::entrypointFor):
2867         (JSC::ExecutableBase::offsetOfEntryFor):
2868         (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
2869         * runtime/JSBoundFunction.cpp:
2870         (JSC::boundThisNoArgsFunctionCall):
2871         * runtime/NativeExecutable.cpp:
2872         (JSC::NativeExecutable::finishCreation):
2873         * runtime/ScriptExecutable.cpp:
2874         (JSC::ScriptExecutable::installCode):
2875         * runtime/VM.cpp:
2876         (JSC::VM::VM):
2877         (JSC::thunkGeneratorForIntrinsic):
2878         (JSC::VM::clearCounters):
2879         (JSC::VM::dumpCounters):
2880         * runtime/VM.h:
2881         (JSC::VM::getJITEntryStub):
2882         (JSC::VM::getJITCallThunkEntryStub):
2883         (JSC::VM::addressOfCounter):
2884         (JSC::VM::counterFor):
2885         * wasm/WasmBinding.cpp:
2886         (JSC::Wasm::importStubGenerator):
2887
2888 2016-12-09  Keith Miller  <keith_miller@apple.com>
2889
2890         Wasm should support call_indirect
2891         https://bugs.webkit.org/show_bug.cgi?id=165718
2892
2893         Reviewed by Filip Pizlo.
2894
2895         This patch adds support for call_indirect. The basic framework for
2896         an indirect call is that the module holds a buffer containing a
2897         stub for each function in the index space. Whenever a function
2898         needs to do an indirect call it gets a index into that table. In
2899         order to ensure call_indirect is calling a valid function the
2900         functionIndexSpace also needs a pointer to a canonicalized
2901         signature. When making an indirect call, we first check the index
2902         is in range, then check the signature matches the value we were given.
2903
2904         This patch also differentiates between FunctionIndexSpaces and
2905         ImmutableFunctionIndexSpaces. Since we don't know the size of the
2906         FunctionIndexSpace when we start parsing we need to be able to
2907         resize the IndexSpace. However, once we have finished parsing all
2908         the sections we want to prevent an relocation of the function
2909         index space pointer.
2910
2911         * wasm/WasmB3IRGenerator.cpp:
2912         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2913         (JSC::Wasm::B3IRGenerator::addCall):
2914         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2915         (JSC::Wasm::createJSToWasmWrapper):
2916         (JSC::Wasm::parseAndCompile):
2917         * wasm/WasmB3IRGenerator.h:
2918         * wasm/WasmCallingConvention.h:
2919         (JSC::Wasm::CallingConvention::setupCall):
2920         * wasm/WasmFormat.h:
2921         * wasm/WasmFunctionParser.h:
2922         (JSC::Wasm::FunctionParser::setErrorMessage):
2923         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
2924         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2925         * wasm/WasmPlan.cpp:
2926         (JSC::Wasm::Plan::run):
2927         * wasm/WasmPlan.h:
2928         (JSC::Wasm::Plan::takeFunctionIndexSpace):
2929         * wasm/WasmValidate.cpp:
2930         (JSC::Wasm::Validate::addCallIndirect):
2931         (JSC::Wasm::validateFunction):
2932         * wasm/WasmValidate.h:
2933         * wasm/js/JSWebAssemblyModule.cpp:
2934         (JSC::JSWebAssemblyModule::create):
2935         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
2936         * wasm/js/JSWebAssemblyModule.h:
2937         (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
2938         (JSC::JSWebAssemblyModule::offsetOfFunctionIndexSpace):
2939
2940 2016-12-09  JF Bastien  <jfbastien@apple.com>
2941
2942         WebAssembly: implement data section
2943         https://bugs.webkit.org/show_bug.cgi?id=165696
2944
2945         Reviewed by Keith Miller.
2946
2947         As specified in https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#data-section
2948         Note that some of the interesting corner cases are ill-defined by the spec: https://github.com/WebAssembly/design/issues/897
2949
2950         * wasm/WasmFormat.h: segments are what represent sections of memory to initialize (similar to ELF's non-zero intializer data / rodata)
2951         (JSC::Wasm::Segment::make):
2952         (JSC::Wasm::Segment::destroy):
2953         (JSC::Wasm::Segment::byte):
2954         (JSC::Wasm::Segment::makePtr):
2955         * wasm/WasmModuleParser.cpp: parse the data section, and prevent a few overflows if a user passes in UINT_MAX (the loops would overflow)
2956         (JSC::Wasm::ModuleParser::parseType):
2957         (JSC::Wasm::ModuleParser::parseImport):
2958         (JSC::Wasm::ModuleParser::parseFunction):
2959         (JSC::Wasm::ModuleParser::parseExport):
2960         (JSC::Wasm::ModuleParser::parseCode):
2961         (JSC::Wasm::ModuleParser::parseData):
2962         * wasm/js/WebAssemblyModuleRecord.cpp:
2963         (JSC::WebAssemblyModuleRecord::evaluate): the only sensible time to initialize the data section is after linking, but before calling start, I test for this but the spec isn't clear it's correct yet
2964
2965 2016-12-09  Karim H  <karim@karhm.com>
2966
2967         It is okay to turn undefined into null because we are producing values for a
2968         JSON representation (InspectorValue) and JSON has a `null` value and no
2969         `undefined` value.
2970         https://bugs.webkit.org/show_bug.cgi?id=165506
2971
2972         Reviewed by Darin Adler.
2973
2974         * bindings/ScriptValue.cpp:
2975         (Inspector::jsToInspectorValue):
2976
2977 2016-12-09  Filip Pizlo  <fpizlo@apple.com>
2978
2979         REGRESSION (r209554-209571): stress/poly-setter-combo crashing
2980         https://bugs.webkit.org/show_bug.cgi?id=165669
2981
2982         Reviewed by Geoffrey Garen.
2983         
2984         We now rely on objects being zero-filled in a bunch of places, not just concurrent GC.
2985         So, we need 32-bit to do it too.
2986
2987         * dfg/DFGSpeculativeJIT32_64.cpp:
2988         (JSC::DFG::SpeculativeJIT::compile):
2989         * jit/JITOpcodes32_64.cpp:
2990         (JSC::JIT::emit_op_new_object):
2991
2992 2016-12-09  Eric Carlson  <eric.carlson@apple.com>
2993
2994         Annotate MediaStream and WebRTC idl with EnabledAtRuntime flag
2995         https://bugs.webkit.org/show_bug.cgi?id=165251
2996
2997         Reviewed by Dean Jackson.
2998
2999         Based on a patch by Dr Alex Gouaillard <agouaillard@gmail.com>
3000
3001         * runtime/CommonIdentifiers.h: Add WebRTC and MediaStream identifiers.
3002
3003 2016-12-09  JF Bastien  <jfbastien@apple.com>
3004
3005         WebAssembly JS API: implement start function
3006         https://bugs.webkit.org/show_bug.cgi?id=165150
3007
3008         Reviewed by Saam Barati.
3009
3010         * wasm/WasmFormat.h: pass the start function around
3011         * wasm/WasmModuleParser.cpp:
3012         (JSC::Wasm::ModuleParser::parseTable): mark unreachable code
3013         (JSC::Wasm::ModuleParser::parseGlobal): mark unreachable code
3014         (JSC::Wasm::ModuleParser::parseStart): mark unreachable code
3015         (JSC::Wasm::ModuleParser::parseElement): mark unreachable code
3016         (JSC::Wasm::ModuleParser::parseData): mark unreachable code
3017         * wasm/js/WebAssemblyFunction.cpp:
3018         (JSC::callWebAssemblyFunction): NFC: call the new function below
3019         (JSC::WebAssemblyFunction::call): separate this out so that the start function can use it
3020         * wasm/js/WebAssemblyFunction.h:
3021         * wasm/js/WebAssemblyModuleRecord.cpp:
3022         (JSC::WebAssemblyModuleRecord::visitChildren): visit the start function
3023         (JSC::WebAssemblyModuleRecord::link): handle start function
3024         (JSC::WebAssemblyModuleRecord::evaluate): call the start function, if present
3025         * wasm/js/WebAssemblyModuleRecord.h:
3026
3027 2016-12-09  Filip Pizlo  <fpizlo@apple.com>
3028
3029         GC might be forced to look at a nuked object due to ordering of AllocatePropertyStorage, MaterializeNewObject, and PutStructure
3030         https://bugs.webkit.org/show_bug.cgi?id=165672
3031
3032         Reviewed by Geoffrey Garen.
3033         
3034         We need to make sure that the shady stuff in a property put happens after the
3035         PutByOffset, since the PutByOffset is the place where we materialize. More generally, we
3036         should strive to not have any fenceposts between Nodes where a GC would be illegal.
3037         
3038         This gets us most of the way there by separating NukeStructureAndSetButterfly from
3039         [Re]AllocatePropertyStorage. A transitioning put will now look something like:
3040         
3041             GetButterfly
3042             ReallocatePropertyStorage
3043             PutByOffset
3044             NukeStructureAndSetButterfly
3045             PutStructure
3046         
3047         Previously the structure would get nuked by ReallocatePropertyStorage, so if we placed
3048         an object materialization just after it (before the PutByOffset) then any GC that
3049         completed at that safepoint would encounter an unresolved visit race due to seeing a
3050         nuked structure. We cannot have nuked structures at safepoints, and this change makes
3051         sure that we don't - at least until someone tries to sink to the PutStructure. We will
3052         eventually have to create a combined SetStructureAndButterfly node, but we don't need it
3053         yet.
3054         
3055         This also fixes a goof where the DFG's AllocatePropertyStorage was nulling the structure
3056         instead of nuking it. This could easily have caused many crashes in GC.
3057         
3058         * dfg/DFGAbstractInterpreterInlines.h:
3059         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3060         * dfg/DFGByteCodeParser.cpp:
3061         (JSC::DFG::ByteCodeParser::handlePutById):
3062         * dfg/DFGClobberize.h:
3063         (JSC::DFG::clobberize):
3064         * dfg/DFGClobbersExitState.cpp:
3065         (JSC::DFG::clobbersExitState):
3066         * dfg/DFGConstantFoldingPhase.cpp:
3067         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
3068         * dfg/DFGDoesGC.cpp:
3069         (JSC::DFG::doesGC):
3070         * dfg/DFGFixupPhase.cpp:
3071         (JSC::DFG::FixupPhase::fixupNode):
3072         * dfg/DFGMayExit.cpp:
3073         * dfg/DFGNodeType.h:
3074         * dfg/DFGOperations.cpp:
3075         * dfg/DFGOperations.h:
3076         * dfg/DFGPredictionPropagationPhase.cpp:
3077         * dfg/DFGSafeToExecute.h:
3078         (JSC::DFG::safeToExecute):
3079         * dfg/DFGSpeculativeJIT.cpp:
3080         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
3081         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
3082         (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
3083         * dfg/DFGSpeculativeJIT.h:
3084         * dfg/DFGSpeculativeJIT32_64.cpp:
3085         (JSC::DFG::SpeculativeJIT::compile):
3086         * dfg/DFGSpeculativeJIT64.cpp:
3087         (JSC::DFG::SpeculativeJIT::compile):
3088         * dfg/DFGStoreBarrierInsertionPhase.cpp:
3089         * dfg/DFGTypeCheckHoistingPhase.cpp:
3090         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
3091         * ftl/FTLCapabilities.cpp:
3092         (JSC::FTL::canCompile):
3093         * ftl/FTLLowerDFGToB3.cpp:
3094         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3095         (JSC::FTL::DFG::LowerDFGToB3::compileNukeStructureAndSetButterfly):
3096         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
3097         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
3098         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
3099         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
3100         * runtime/Options.cpp:
3101         (JSC::recomputeDependentOptions):
3102         * runtime/Options.h: Fix a bug - make it possible to turn on concurrent GC optionally again.
3103
3104 2016-12-09  Chris Dumez  <cdumez@apple.com>
3105
3106         Inline JSCell::toObject()
3107         https://bugs.webkit.org/show_bug.cgi?id=165679
3108
3109         Reviewed by Geoffrey Garen.
3110
3111         Inline JSCell::toObject() as it shows on Speedometer profiles.
3112
3113         * runtime/JSCell.cpp:
3114         (JSC::JSCell::toObjectSlow):
3115         (JSC::JSCell::toObject): Deleted.
3116         * runtime/JSCell.h:
3117         * runtime/JSCellInlines.h:
3118         (JSC::JSCell::toObject):
3119
3120 2016-12-09  Geoffrey Garen  <ggaren@apple.com>
3121
3122         Deploy OrdinalNumber in JSC::SourceCode
3123         https://bugs.webkit.org/show_bug.cgi?id=165687
3124
3125         Reviewed by Michael Saboff.
3126
3127         We have a lot of confusion between 1-based and 0-based counting in line
3128         and column numbers. Let's use OrdinalNumber to clear up the confusion.
3129
3130         * bytecode/UnlinkedFunctionExecutable.cpp:
3131         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3132         (JSC::UnlinkedFunctionExecutable::link):
3133         * bytecompiler/BytecodeGenerator.h:
3134         (JSC::BytecodeGenerator::emitExpressionInfo):
3135         * inspector/JSInjectedScriptHost.cpp:
3136         (Inspector::JSInjectedScriptHost::functionDetails):
3137         * parser/Lexer.cpp:
3138         (JSC::Lexer<T>::setCode):
3139         * parser/Parser.cpp:
3140         (JSC::Parser<LexerType>::Parser):
3141         * parser/Parser.h:
3142         (JSC::Parser<LexerType>::parse):
3143         * parser/SourceCode.h:
3144         (JSC::SourceCode::SourceCode):
3145         (JSC::SourceCode::firstLine):
3146         (JSC::SourceCode::startColumn):
3147         * runtime/CodeCache.cpp:
3148         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
3149         * runtime/ScriptExecutable.h:
3150         (JSC::ScriptExecutable::firstLine):
3151         (JSC::ScriptExecutable::startColumn):
3152         * tools/CodeProfile.h:
3153         (JSC::CodeProfile::CodeProfile):
3154
3155 2016-12-09  Saam Barati  <sbarati@apple.com>
3156
3157         WebAssembly JS API: implement importing and defining Memory
3158         https://bugs.webkit.org/show_bug.cgi?id=164134
3159
3160         Reviewed by Keith Miller.
3161
3162         This patch implements the WebAssembly.Memory object. It refactors
3163         the code to now associate a Memory with the instance instead of
3164         the Module.
3165
3166         * CMakeLists.txt:
3167         * JavaScriptCore.xcodeproj/project.pbxproj:
3168         * jsc.cpp:
3169         (functionTestWasmModuleFunctions):
3170         * runtime/VM.h:
3171         * shell/CMakeLists.txt:
3172         * testWasm.cpp: Removed.
3173         This has bitrotted. I'm removing it.
3174
3175         * wasm/WasmB3IRGenerator.cpp:
3176         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3177         (JSC::Wasm::sizeOfLoadOp):
3178         (JSC::Wasm::createJSToWasmWrapper):
3179         (JSC::Wasm::parseAndCompile):
3180         * wasm/WasmB3IRGenerator.h:
3181         * wasm/WasmFormat.cpp:
3182         (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
3183         * wasm/WasmFormat.h:
3184         * wasm/WasmMemory.cpp:
3185         (JSC::Wasm::Memory::Memory):
3186         * wasm/WasmMemory.h:
3187         (JSC::Wasm::Memory::size):
3188         (JSC::Wasm::Memory::initial):
3189         (JSC::Wasm::Memory::maximum):
3190         (JSC::Wasm::Memory::pinnedRegisters): Deleted.
3191         * wasm/WasmMemoryInformation.cpp: Added.
3192         (JSC::Wasm::MemoryInformation::MemoryInformation):
3193         * wasm/WasmMemoryInformation.h: Added.
3194         (JSC::Wasm::MemoryInformation::MemoryInformation):
3195         (JSC::Wasm::MemoryInformation::pinnedRegisters):
3196         (JSC::Wasm::MemoryInformation::initial):
3197         (JSC::Wasm::MemoryInformation::maximum):
3198         (JSC::Wasm::MemoryInformation::isImport):
3199         (JSC::Wasm::MemoryInformation::operator bool):
3200         * wasm/WasmModuleParser.cpp:
3201         (JSC::Wasm::ModuleParser::parseImport):
3202         (JSC::Wasm::ModuleParser::parseMemoryHelper):
3203         (JSC::Wasm::ModuleParser::parseMemory):
3204         (JSC::Wasm::ModuleParser::parseExport):
3205         * wasm/WasmModuleParser.h:
3206         * wasm/WasmPageCount.h: Added. Implement a new way of describing Wasm
3207         pages and then asking for how many bytes a quantity of pages is. This
3208         class also makes it clear when we're talking about bytes or pages.
3209
3210         (JSC::Wasm::PageCount::PageCount):
3211         (JSC::Wasm::PageCount::bytes):
3212         (JSC::Wasm::PageCount::isValid):
3213         (JSC::Wasm::PageCount::max):
3214         (JSC::Wasm::PageCount::operator bool):
3215         (JSC::Wasm::PageCount::operator<):
3216         (JSC::Wasm::PageCount::operator>):
3217         (JSC::Wasm::PageCount::operator>=):
3218         * wasm/WasmPlan.cpp:
3219         (JSC::Wasm::Plan::run):
3220         * wasm/WasmPlan.h:
3221         (JSC::Wasm::Plan::memory): Deleted.
3222         * wasm/WasmValidate.cpp:
3223         (JSC::Wasm::Validate::hasMemory):
3224         (JSC::Wasm::Validate::Validate):
3225         (JSC::Wasm::validateFunction):
3226         * wasm/WasmValidate.h:
3227         * wasm/generateWasmValidateInlinesHeader.py:
3228         * wasm/js/JSWebAssemblyInstance.cpp:
3229         (JSC::JSWebAssemblyInstance::visitChildren):
3230         * wasm/js/JSWebAssemblyInstance.h:
3231         (JSC::JSWebAssemblyInstance::memory):
3232         (JSC::JSWebAssemblyInstance::setMemory):
3233         (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
3234         (JSC::JSWebAssemblyInstance::allocationSize):
3235         * wasm/js/JSWebAssemblyMemory.cpp:
3236         (JSC::JSWebAssemblyMemory::create):
3237         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
3238         (JSC::JSWebAssemblyMemory::buffer):
3239         (JSC::JSWebAssemblyMemory::visitChildren):
3240         * wasm/js/JSWebAssemblyMemory.h:
3241         (JSC::JSWebAssemblyMemory::memory):
3242         * wasm/js/WebAssemblyFunction.cpp:
3243         (JSC::callWebAssemblyFunction):
3244         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3245         Handle importing and creating of memory according
3246         to the spec. This also does the needed validation
3247         of making sure the memory defined in the module
3248         is compatible with the imported memory.
3249
3250         (JSC::constructJSWebAssemblyInstance):
3251         * wasm/js/WebAssemblyMemoryConstructor.cpp:
3252         (JSC::constructJSWebAssemblyMemory):
3253         (JSC::callJSWebAssemblyMemory):
3254         * wasm/js/WebAssemblyMemoryPrototype.cpp:
3255         (JSC::webAssemblyMemoryProtoFuncBuffer):
3256         (JSC::WebAssemblyMemoryPrototype::create):
3257         (JSC::WebAssemblyMemoryPrototype::finishCreation):
3258         * wasm/js/WebAssemblyMemoryPrototype.h:
3259         * wasm/js/WebAssemblyModuleRecord.cpp:
3260         (JSC::WebAssemblyModuleRecord::finishCreation):
3261         (JSC::WebAssemblyModuleRecord::link):
3262
3263 2016-12-09  Joseph Pecoraro  <pecoraro@apple.com>
3264
3265         Web Inspector: Some resources fetched via Fetch API do not have data
3266         https://bugs.webkit.org/show_bug.cgi?id=165230
3267         <rdar://problem/29449220>
3268
3269         Reviewed by Alex Christensen.
3270
3271         * inspector/protocol/Page.json:
3272         Add new Fetch Page.ResourceType.
3273
3274 2016-12-09  Geoffrey Garen  <ggaren@apple.com>
3275
3276         TextPosition and OrdinalNumber should be more like idiomatic numbers
3277         https://bugs.webkit.org/show_bug.cgi?id=165678
3278
3279         Reviewed by Filip Pizlo.
3280
3281         Adopt default constructor.
3282
3283         * API/JSBase.cpp:
3284         (JSEvaluateScript):
3285         (JSCheckScriptSyntax):
3286         * API/JSObjectRef.cpp:
3287         (JSObjectMakeFunction):
3288         * API/JSScriptRef.cpp:
3289         (OpaqueJSScript::OpaqueJSScript):
3290         * jsc.cpp:
3291         (functionCheckModuleSyntax):
3292         * parser/SourceCode.h:
3293         (JSC::makeSource):
3294         * parser/SourceProvider.h:
3295         (JSC::StringSourceProvider::create):
3296         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
3297         * runtime/FunctionConstructor.cpp:
3298         (JSC::constructFunction):
3299         * runtime/ModuleLoaderPrototype.cpp:
3300         (JSC::moduleLoaderPrototypeParseModule):
3301
3302 2016-12-09  Filip Pizlo  <fpizlo@apple.com>
3303
3304         Unreviewed, disable concurrent GC for real.
3305
3306         * runtime/Options.cpp:
3307         (JSC::recomputeDependentOptions):
3308
3309 2016-12-09  Filip Pizlo  <fpizlo@apple.com>
3310
3311         Unreviewed, disable concurrent GC while crashes get investigated.
3312
3313         * runtime/Options.cpp:
3314         (JSC::recomputeDependentOptions):
3315
3316 2016-12-09  Filip Pizlo  <fpizlo@apple.com>
3317
3318         JSSegmentedVariableObject should keep its state private
3319
3320         Rubber stamped by Michael Saboff.
3321         
3322         Its state fields were protected for no reason. They really should be private because
3323         you have to know to obey a particular concurrency protocol when accessing them.
3324
3325         * runtime/JSSegmentedVariableObject.h:
3326
3327 2016-12-09  Csaba Osztrogon√°c  <ossy@webkit.org>
3328
3329         Unreviewed ARM buildfix after 209570.
3330
3331         * assembler/MacroAssemblerARM.h:
3332         (JSC::MacroAssemblerARM::or32): Added.
3333
3334 2016-12-08  JF Bastien  <jfbastien@apple.com>
3335
3336         WebAssembly: JSC::link* shouldn't need a CodeBlock
3337         https://bugs.webkit.org/show_bug.cgi?id=165591
3338
3339         Reviewed by Keith Miller.
3340
3341         Allow linking without a CodeBlock, which WebAssembly's wasm -> JS stubs does. This needs to work for polymorphic and virtual calls. This patch adds corresponding tests for this.
3342
3343         * assembler/LinkBuffer.cpp:
3344         (JSC::shouldDumpDisassemblyFor): don't look at the tier option if there isn't a CodeBlock, only look at the global one. This is a WebAssembly function, so the tier information is irrelevant.
3345         * jit/Repatch.cpp:
3346         (JSC::isWebAssemblyToJSCallee): this is used in the link* functions below
3347         (JSC::linkFor):
3348         (JSC::linkVirtualFor):
3349         (JSC::linkPolymorphicCall):
3350         * runtime/Options.h: add an option to change the maximum number of polymorphic calls in stubs from wasm to JS, which will come in handy when we try to tune performance or try merging some of the WebAssembly stubs
3351         * wasm/WasmBinding.cpp:
3352         (JSC::Wasm::importStubGenerator): remove the breakpoint since the code now works
3353         * wasm/js/WebAssemblyToJSCallee.h:
3354
3355 2016-12-08  Filip Pizlo  <fpizlo@apple.com>
3356
3357         MultiPutByOffset should get a barrier if it transitions
3358         https://bugs.webkit.org/show_bug.cgi?id=165646
3359
3360         Reviewed by Keith Miller.
3361         
3362         Previously, if we knew that we were storing a non-cell but we needed to transition, we
3363         would fail to add the barrier but the FTL's lowering expected the barrier to be there.
3364         
3365         Strictly, we need to "consider" the barrier on MultiPutByOffset if the value is
3366         possibly a cell or if the MultiPutByOffset may transition. Then "considering" the
3367         barrier implies checking if the base is possibly old.
3368         
3369         But because the barrier is so cheap anyway, this patch implements something safer: we
3370         just consider the barrier on MultiPutByOffset unconditionally, which opts it out of any
3371         barrier optimizations other than those based on the predicted state of the base. Those
3372         optimizations are already sound - for example they use doesGC() to detect safepoints
3373         and that function correctly predicts when MultiPutByOffset could GC.
3374         
3375         Because the barrier optimizations are only a very small speed-up, I think it's great to
3376         fix bugs by weakening the optimizer without cleverness.
3377
3378         * dfg/DFGFixupPhase.cpp:
3379         * dfg/DFGStoreBarrierInsertionPhase.cpp:
3380         * heap/MarkedBlock.cpp:
3381         (JSC::MarkedBlock::assertValidCell):
3382
3383 2016-12-08  Filip Pizlo  <fpizlo@apple.com>
3384
3385         Enable concurrent GC on ARM64
3386         https://bugs.webkit.org/show_bug.cgi?id=165643
3387
3388         Reviewed by Saam Barati.
3389
3390         It looks stable enough to enable.
3391
3392         * assembler/CPU.h:
3393         (JSC::useGCFences): Deleted.
3394         * bytecode/PolymorphicAccess.cpp:
3395         (JSC::AccessCase::generateImpl):
3396         * dfg/DFGSpeculativeJIT.cpp:
3397         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
3398         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
3399         * ftl/FTLLowerDFGToB3.cpp:
3400         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
3401         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
3402         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
3403         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
3404         * jit/AssemblyHelpers.h:
3405         (JSC::AssemblyHelpers::mutatorFence):
3406         (JSC::AssemblyHelpers::storeButterfly):
3407         (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
3408         (JSC::AssemblyHelpers::emitInitializeInlineStorage):
3409         (JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
3410         * runtime/Options.cpp:
3411         (JSC::recomputeDependentOptions):
3412
3413 2016-12-08  Filip Pizlo  <fpizlo@apple.com>
3414
3415         Disable collectContinuously if not useConcurrentGC
3416
3417         Rubber stamped by Geoffrey Garen.
3418
3419         * runtime/Options.cpp:
3420         (JSC::recomputeDependentOptions):
3421
3422 2016-12-08  Filip Pizlo  <fpizlo@apple.com>
3423
3424         Unreviewed, fix cloop build.
3425
3426         * runtime/JSObject.h:
3427
3428 2016-12-06  Filip Pizlo  <fpizlo@apple.com>
3429
3430         Concurrent GC should be stable enough to land enabled on X86_64
3431         https://bugs.webkit.org/show_bug.cgi?id=164990
3432
3433         Reviewed by Geoffrey Garen.
3434         
3435         This fixes a ton of performance and correctness bugs revealed by getting the concurrent GC to
3436         be stable enough to land enabled.
3437         
3438         I had to redo the JSObject::visitChildren concurrency protocol again. This time I think it's
3439         even more correct than ever!
3440         
3441         This is an enormous win on JetStream/splay-latency and Octane/SplayLatency. It looks to be
3442         mostly neutral on everything else, though Speedometer is showing statistically weak signs of a
3443         slight regression.
3444
3445         * API/JSAPIWrapperObject.mm: Added locking.
3446         (JSC::JSAPIWrapperObject::visitChildren):
3447         * API/JSCallbackObject.h: Added locking.
3448         (JSC::JSCallbackObjectData::visitChildren):
3449         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
3450         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::deletePrivateProperty):
3451         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
3452         * CMakeLists.txt:
3453         * JavaScriptCore.xcodeproj/project.pbxproj:
3454         * bytecode/CodeBlock.cpp:
3455         (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): This had a TOCTOU race on shouldJettisonDueToOldAge.
3456         (JSC::EvalCodeCache::visitAggregate): Moved to EvalCodeCache.cpp.
3457         * bytecode/DirectEvalCodeCache.cpp: Added. Outlined some functions and made them use locks.
3458         (JSC::DirectEvalCodeCache::setSlow):
3459         (JSC::DirectEvalCodeCache::clear):
3460         (JSC::DirectEvalCodeCache::visitAggregate):
3461         * bytecode/DirectEvalCodeCache.h:
3462         (JSC::DirectEvalCodeCache::set):
3463         (JSC::DirectEvalCodeCache::clear): Deleted.
3464         * bytecode/UnlinkedCodeBlock.cpp: Added locking.
3465         (JSC::UnlinkedCodeBlock::visitChildren):
3466         (JSC::UnlinkedCodeBlock::setInstructions):
3467         (JSC::UnlinkedCodeBlock::shrinkToFit):
3468         * bytecode/UnlinkedCodeBlock.h: Added locking.
3469         (JSC::UnlinkedCodeBlock::addRegExp):
3470         (JSC::UnlinkedCodeBlock::addConstant):
3471         (JSC::UnlinkedCodeBlock::addFunctionDecl):
3472         (JSC::UnlinkedCodeBlock::addFunctionExpr):
3473         (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
3474         (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
3475         * debugger/Debugger.cpp: Use the right delete API.
3476         (JSC::Debugger::recompileAllJSFunctions):
3477         * dfg/DFGAbstractInterpreterInlines.h:
3478         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix a pre-existing bug in ToFunction constant folding.
3479         * dfg/DFGClobberize.h: Add support for nuking.
3480         (JSC::DFG::clobberize):
3481         * dfg/DFGClobbersExitState.cpp: Add support for nuking.
3482         (JSC::DFG::clobbersExitState):
3483         * dfg/DFGFixupPhase.cpp: Add support for nuking.
3484         (JSC::DFG::FixupPhase::fixupNode):
3485         (JSC::DFG::FixupPhase::indexForChecks):
3486         (JSC::DFG::FixupPhase::originForCheck):
3487         (JSC::DFG::FixupPhase::speculateForBarrier):
3488         (JSC::DFG::FixupPhase::insertCheck):
3489         (JSC::DFG::FixupPhase::fixupChecksInBlock):
3490         * dfg/DFGSpeculativeJIT.cpp: Add support for nuking.
3491         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
3492         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
3493         * ftl/FTLLowerDFGToB3.cpp: Add support for nuking.
3494         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
3495         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
3496         (JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
3497         (JSC::FTL::DFG::LowerDFGToB3::nukeStructureAndSetButterfly):
3498         (JSC::FTL::DFG::LowerDFGToB3::setButterfly): Deleted.
3499         * heap/CodeBlockSet.cpp: We need to be more careful about the CodeBlockSet workflow during GC, since we will allocate CodeBlocks in eden while collecting.
3500         (JSC::CodeBlockSet::clearMarksForFullCollection):
3501         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
3502         * heap/Heap.cpp: Added code to measure max pauses. Added a better collectContinuously mode.
3503         (JSC::Heap::lastChanceToFinalize): Stop the collectContinuously thread.
3504         (JSC::Heap::harvestWeakReferences): Inline SlotVisitor::harvestWeakReferences.
3505         (JSC::Heap::finalizeUnconditionalFinalizers): Inline SlotVisitor::finalizeUnconditionalReferences.
3506         (JSC::Heap::markToFixpoint): We need to do some MarkedSpace stuff before every conservative scan, rather than just at the start of marking, so we now call prepareForConservativeScan() before each conservative scan. Also call a less-parallel version of drainInParallel when the mutator is running.
3507         (JSC::Heap::collectInThread): Inline Heap::prepareForAllocation().
3508         (JSC::Heap::stopIfNecessarySlow): We need to be more careful about ensuring that we run finalization before and after stopping. Also, we should sanitize stack when stopping the world.
3509         (JSC::Heap::acquireAccessSlow): Add some optional debug prints.
3510         (JSC::Heap::handleNeedFinalize): Assert that we are running this when the world is not stopped.
3511         (JSC::Heap::finalize): Remove the old collectContinuously code.
3512         (JSC::Heap::requestCollection): We don't need to sanitize stack here anymore.
3513         (JSC::Heap::notifyIsSafeToCollect): Start the collectContinuously thread. It will request collection 1 KHz.
3514         (JSC::Heap::prepareForAllocation): Deleted.
3515         (JSC::Heap::preventCollection): Prevent any new concurrent GCs from being initiated.
3516         (JSC::Heap::allowCollection):
3517         (JSC::Heap::forEachSlotVisitor): Allows us to safely iterate slot visitors.
3518         * heap/Heap.h:
3519         * heap/HeapInlines.h:
3520         (JSC::Heap::writeBarrier): If the 'to' cell is not NewWhite then it could be AnthraciteOrBlack. During a full collection, objects may be AnthraciteOrBlack from a previous GC. Turns out, we don't benefit from this optimization so we can just kill it.
3521         * heap/HeapSnapshotBuilder.cpp:
3522         (JSC::HeapSnapshotBuilder::buildSnapshot): This needs to use PreventCollectionScope to ensure snapshot soundness.
3523         * heap/ListableHandler.h:
3524         (JSC::ListableHandler::isOnList): Useful helper.
3525         * heap/LockDuringMarking.h:
3526         (JSC::lockDuringMarking): It's a locker that only locks while we're marking.
3527         * heap/MarkedAllocator.cpp:
3528         (JSC::MarkedAllocator::addBlock): Hold the bitvector lock while resizing.
3529         * heap/MarkedBlock.cpp: Hold the bitvector lock while accessing the bitvectors while the mutator is running.
3530         * heap/MarkedSpace.cpp:
3531         (JSC::MarkedSpace::prepareForConservativeScan): We used to do this in prepareForMarking, but we need to do it before each conservative scan not just before marking.
3532         (JSC::MarkedSpace::prepareForMarking): Remove the logic moved to prepareForConservativeScan.
3533         * heap/MarkedSpace.h:
3534         * heap/PreventCollectionScope.h: Added.
3535         * heap/SlotVisitor.cpp: Refactored drainFromShared so that we can write a similar function called drainInParallelPassively.
3536         (JSC::SlotVisitor::updateMutatorIsStopped): Update whether we can use "fast" scanning.
3537         (JSC::SlotVisitor::mutatorIsStoppedIsUpToDate):
3538         (JSC::SlotVisitor::didReachTermination):
3539         (JSC::SlotVisitor::hasWork):
3540         (JSC::SlotVisitor::drain): This now uses the rightToRun lock to allow the main GC thread to safepoint the workers.
3541         (JSC::SlotVisitor::drainFromShared):
3542         (JSC::SlotVisitor::drainInParallelPassively): This runs marking with one fewer threads than normal. It's useful for when we have resumed the mutator, since then the mutator has a better chance of getting on a core.
3543         (JSC::SlotVisitor::addWeakReferenceHarvester):
3544         (JSC::SlotVisitor::addUnconditionalFinalizer):
3545         (JSC::SlotVisitor::harvestWeakReferences): Deleted.
3546         (JSC::SlotVisitor::finalizeUnconditionalFinalizers): Deleted.
3547         * heap/SlotVisitor.h:
3548         * heap/SlotVisitorInlines.h: Outline stuff.
3549         (JSC::SlotVisitor::addWeakReferenceHarvester): Deleted.
3550         (JSC::SlotVisitor::addUnconditionalFinalizer): Deleted.
3551         * runtime/InferredType.cpp: This needed thread safety.
3552         (JSC::InferredType::visitChildren): This needs to keep its structure finalizer alive until it runs.
3553         (JSC::InferredType::set):
3554         (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
3555         * runtime/InferredType.h:
3556         * runtime/InferredValue.cpp: This needed thread safety.
3557         (JSC::InferredValue::visitChildren):
3558         (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
3559         * runtime/JSArray.cpp:
3560         (JSC::JSArray::unshiftCountSlowCase): Update to use new butterfly API.
3561         (JSC::JSArray::unshiftCountWithArrayStorage): Update to use new butterfly API.
3562         * runtime/JSArrayBufferView.cpp:
3563         (JSC::JSArrayBufferView::visitChildren): Thread safety.
3564         * runtime/JSCell.h:
3565         (JSC::JSCell::setStructureIDDirectly): This is used for nuking the structure.
3566         (JSC::JSCell::InternalLocker::InternalLocker): Deleted. The cell is now the lock.
3567         (JSC::JSCell::InternalLocker::~InternalLocker): Deleted. The cell is now the lock.
3568         * runtime/JSCellInlines.h:
3569         (JSC::JSCell::structure): Clean this up.
3570         (JSC::JSCell::lock): The cell is now the lock.
3571         (JSC::JSCell::tryLock):
3572         (JSC::JSCell::unlock):
3573         (JSC::JSCell::isLocked):
3574         (JSC::JSCell::lockInternalLock): Deleted.
3575         (JSC::JSCell::unlockInternalLock): Deleted.
3576         * runtime/JSFunction.cpp:
3577         (JSC::JSFunction::visitChildren): Thread safety.
3578         * runtime/JSGenericTypedArrayViewInlines.h:
3579         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Thread safety.
3580         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory): Thread safety.
3581         * runtime/JSObject.cpp:
3582         (JSC::JSObject::markAuxiliaryAndVisitOutOfLineProperties): Factor out this "easy" step of butterfly visiting.
3583         (JSC::JSObject::visitButterfly): Make this achieve 100% precision about structure-butterfly relationships. This relies on the mutator "nuking" the structure prior to "locked" structure-butterfly transitions.
3584         (JSC::JSObject::visitChildren): Use the new, nicer API.
3585         (JSC::JSFinalObject::visitChildren): Use the new, nicer API.
3586         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): Use the new butterfly API.
3587         (JSC::JSObject::createInitialUndecided): Use the new butterfly API.
3588         (JSC::JSObject::createInitialInt32): Use the new butterfly API.
3589         (JSC::JSObject::createInitialDouble): Use the new butterfly API.
3590         (JSC::JSObject::createInitialContiguous): Use the new butterfly API.
3591         (JSC::JSObject::createArrayStorage): Use the new butterfly API.
3592         (JSC::JSObject::convertUndecidedToContiguous): Use the new butterfly API.
3593         (JSC::JSObject::convertUndecidedToArrayStorage): Use the new butterfly API.
3594         (JSC::JSObject::convertInt32ToArrayStorage): Use the new butterfly API.
3595         (JSC::JSObject::convertDoubleToContiguous): Use the new butterfly API.
3596         (JSC::JSObject::convertDoubleToArrayStorage): Use the new butterfly API.
3597         (JSC::JSObject::convertContiguousToArrayStorage): Use the new butterfly API.
3598         (JSC::JSObject::increaseVectorLength): Use the new butterfly API.
3599         (JSC::JSObject::shiftButterflyAfterFlattening): Use the new butterfly API.
3600         * runtime/JSObject.h:
3601         (JSC::JSObject::setButterfly): This now does all of the fences. Only use this when you are not also transitioning the structure or the structure's lastOffset.
3602         (JSC::JSObject::nukeStructureAndSetButterfly): Use this when doing locked structure-butterfly transitions.
3603         * runtime/JSObjectInlines.h:
3604         (JSC::JSObject::putDirectWithoutTransition): Use the newly factored out API.
3605         (JSC::JSObject::prepareToPutDirectWithoutTransition): Factor this out!
3606         (JSC::JSObject::putDirectInternal): Use the newly factored out API.
3607         * runtime/JSPropertyNameEnumerator.cpp:
3608         (JSC::JSPropertyNameEnumerator::finishCreation): Locks!
3609         (JSC::JSPropertyNameEnumerator::visitChildren): Locks!
3610         * runtime/JSSegmentedVariableObject.cpp:
3611         (JSC::JSSegmentedVariableObject::visitChildren): Locks!
3612         * runtime/JSString.cpp:
3613         (JSC::JSString::visitChildren): Thread safety.
3614         * runtime/ModuleProgramExecutable.cpp:
3615         (JSC::ModuleProgramExecutable::visitChildren): Thread safety.
3616         * runtime/Options.cpp: For now we disable concurrent GC on not-X86_64.
3617         (JSC::recomputeDependentOptions):
3618         * runtime/Options.h: Change the default max GC parallelism to 8. I don't know why it was still 7.
3619         * runtime/SamplingProfiler.cpp:
3620         (JSC::SamplingProfiler::stackTracesAsJSON): This needs to defer GC before grabbing its lock.
3621         * runtime/SparseArrayValueMap.cpp: This needed thread safety.
3622         (JSC::SparseArrayValueMap::add):
3623         (JSC::SparseArrayValueMap::remove):
3624         (JSC::SparseArrayValueMap::visitChildren):
3625         * runtime/SparseArrayValueMap.h:
3626         * runtime/Structure.cpp: This had a race between addNewPropertyTransition and visitChildren.
3627         (JSC::Structure::Structure):
3628         (JSC::Structure::materializePropertyTable):
3629         (JSC::Structure::addNewPropertyTransition):
3630         (JSC::Structure::flattenDictionaryStructure):
3631         (JSC::Structure::add): Help out with nuking support - the m_offset needs to play along.
3632         (JSC::Structure::visitChildren):
3633         * runtime/Structure.h: Make some useful things public - like the notion of a lastOffset.
3634         * runtime/StructureChain.cpp:
3635         (JSC::StructureChain::visitChildren): Thread safety!
3636         * runtime/StructureChain.h: Thread safety!
3637         * runtime/StructureIDTable.cpp:
3638         (JSC::StructureIDTable::allocateID): Ensure that we don't get nuked IDs.
3639         * runtime/StructureIDTable.h: Add the notion of a nuked ID! It's a bit that the runtime never sees except during specific shady actions like locked structure-butterfly transitions. "Nuking" tells the GC to steer clear and rescan once we fire the barrier.
3640         (JSC::nukedStructureIDBit):
3641         (JSC::nuke):
3642         (JSC::isNuked):
3643         (JSC::decontaminate):
3644         * runtime/StructureInlines.h:
3645         (JSC::Structure::hasIndexingHeader): Better API.
3646         (JSC::Structure::add):
3647         * runtime/VM.cpp: Better GC interaction.
3648         (JSC::VM::ensureWatchdog):
3649         (JSC::VM::deleteAllLinkedCode):
3650         (JSC::VM::deleteAllCode):
3651         * runtime/VM.h:
3652         (JSC::VM::getStructure): Why wasn't this always an API!
3653         * runtime/WebAssemblyExecutable.cpp:
3654         (JSC::WebAssemblyExecutable::visitChildren): Thread safety.
3655
3656 2016-12-08  Filip Pizlo  <fpizlo@apple.com>
3657
3658         Enable SharedArrayBuffer, remove the flag
3659         https://bugs.webkit.org/show_bug.cgi?id=165614
3660
3661         Rubber stamped by Geoffrey Garen.
3662
3663         * runtime/JSGlobalObject.cpp:
3664         (JSC::JSGlobalObject::init):
3665         * runtime/RuntimeFlags.h:
3666
3667 2016-12-08  JF Bastien  <jfbastien@apple.com>
3668
3669         WebAssembly JS API: wire up Instance imports
3670         https://bugs.webkit.org/show_bug.cgi?id=165118
3671
3672         Reviewed by Saam Barati.
3673
3674         Change a bunch of the WebAssembly object model, and pipe the
3675         necessary changes to be able to call JS imports from
3676         WebAssembly. This will make it easier to call_indirect, and
3677         unblock many other missing features.
3678
3679         As a follow-up I need to teach JSC::linkFor to live without a
3680         CodeBlock: wasm doesn't have one and the IC patching is sad. We'll
3681         switch on the callee (or its type?) and then use that as the owner
3682         (because the callee is alive if the instance is alive, ditto
3683         module, and module owns the CallLinkInfo).
3684
3685         * CMakeLists.txt:
3686         * JavaScriptCore.xcodeproj/project.pbxproj:
3687         * interpreter/CallFrame.h:
3688         (JSC::ExecState::callee): give access to the callee as a JSCell
3689         * jit/RegisterSet.cpp: dead code from previous WebAssembly implementation
3690         * jsc.cpp:
3691         (callWasmFunction):
3692         (functionTestWasmModuleFunctions):
3693         * runtime/JSCellInlines.h:
3694         (JSC::ExecState::vm): check callee instead of jsCallee: wasm only has a JSCell and not a JSObject
3695         * runtime/VM.cpp:
3696         (JSC::VM::VM): store the "top" WebAssembly.Instance on entry to WebAssembly (and restore the previous one on exit)
3697         * runtime/VM.h:
3698         * testWasm.cpp:
3699         (runWasmTests):
3700         * wasm/JSWebAssembly.h:
3701         * wasm/WasmB3IRGenerator.cpp:
3702         (JSC::Wasm::B3IRGenerator::B3IRGenerator): pass unlinked calls around to shorten their lifetime: they're ony needed until the Plan is done
3703         (JSC::Wasm::B3IRGenerator::addCall):
3704         (JSC::Wasm::createJSToWasmWrapper):
3705         (JSC::Wasm::parseAndCompile): also pass in the function index space, so that imports can be signature-checked along with internal functions
3706         * wasm/WasmB3IRGenerator.h:
3707         * wasm/WasmBinding.cpp: Added.
3708         (JSC::Wasm::importStubGenerator): stubs from wasm to JS
3709         * wasm/WasmBinding.h: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
3710         * wasm/WasmCallingConvention.h:
3711         (JSC::Wasm::CallingConvention::setupFrameInPrologue):
3712         * wasm/WasmFormat.h: fix the object model
3713         (JSC::Wasm::CallableFunction::CallableFunction):
3714         * wasm/WasmFunctionParser.h: simplify some of the failure condition checks
3715         (JSC::Wasm::FunctionParser<Context>::FunctionParser): need function index space, not just internal functions
3716         (JSC::Wasm::FunctionParser<Context>::parseExpression):
3717         * wasm/WasmModuleParser.cpp: early-create some of the structures which will be needed later
3718         (JSC::Wasm::ModuleParser::parseImport):
3719         (JSC::Wasm::ModuleParser::parseFunction):
3720         (JSC::Wasm::ModuleParser::parseMemory):
3721         (JSC::Wasm::ModuleParser::parseExport):
3722         (JSC::Wasm::ModuleParser::parseCode):
3723         * wasm/WasmModuleParser.h:
3724         (JSC::Wasm::ModuleParser::functionIndexSpace):
3725         (JSC::Wasm::ModuleParser::functionLocations):
3726         * wasm/WasmParser.h:
3727         (JSC::Wasm::Parser::consumeUTF8String):
3728         * wasm/WasmPlan.cpp: pass around the wasm objects at the right time, reducing their lifetime and making it easier to pass them around when needed
3729         (JSC::Wasm::Plan::run):
3730         (JSC::Wasm::Plan::initializeCallees):
3731         * wasm/WasmPlan.h:
3732         (JSC::Wasm::Plan::exports):
3733         (JSC::Wasm::Plan::internalFunctionCount):
3734         (JSC::Wasm::Plan::jsToWasmEntryPointForFunction):
3735         (JSC::Wasm::Plan::takeModuleInformation):
3736         (JSC::Wasm::Plan::takeCallLinkInfos):
3737         (JSC::Wasm::Plan::takeWasmToJSStubs):
3738         (JSC::Wasm::Plan::takeFunctionIndexSpace):
3739         * wasm/WasmValidate.cpp: check function index space instead of only internal functions
3740         (JSC::Wasm::Validate::addCall):
3741         (JSC::Wasm::validateFunction):
3742         * wasm/WasmValidate.h:
3743         * wasm/js/JSWebAssemblyCallee.cpp:
3744         (JSC::JSWebAssemblyCallee::finishCreation):
3745         * wasm/js/JSWebAssemblyCallee.h:
3746         (JSC::JSWebAssemblyCallee::create):
3747         (JSC::JSWebAssemblyCallee::jsToWasmEntryPoint):
3748         * wasm/js/JSWebAssemblyInstance.cpp:
3749         (JSC::JSWebAssemblyInstance::create):
3750         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
3751         (JSC::JSWebAssemblyInstance::visitChildren):
3752         * wasm/js/JSWebAssemblyInstance.h: hold the import functions off the end of the Instance
3753         (JSC::JSWebAssemblyInstance::importFunction):
3754         (JSC::JSWebAssemblyInstance::importFunctions):
3755         (JSC::JSWebAssemblyInstance::setImportFunction):
3756         (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
3757         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
3758         (JSC::JSWebAssemblyInstance::allocationSize):
3759         * wasm/js/JSWebAssemblyModule.cpp:
3760         (JSC::JSWebAssemblyModule::create):
3761         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
3762         (JSC::JSWebAssemblyModule::visitChildren):
3763         * wasm/js/JSWebAssemblyModule.h: hold the link call info, the import function stubs, and the function index space
3764         (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
3765         (JSC::JSWebAssemblyModule::importCount):
3766         (JSC::JSWebAssemblyModule::calleeFromFunctionIndexSpace):
3767         * wasm/js/WebAssemblyFunction.cpp:
3768         (JSC::callWebAssemblyFunction): set top Instance on VM
3769         * wasm/js/WebAssemblyFunction.h:
3770         (JSC::WebAssemblyFunction::instance):
3771         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3772         (JSC::constructJSWebAssemblyInstance): handle function imports
3773         * wasm/js/WebAssemblyModuleConstructor.cpp:
3774         (JSC::constructJSWebAssemblyModule): generate the stubs for import functions
3775         * wasm/js/WebAssemblyModuleRecord.cpp:
3776         (JSC::WebAssemblyModuleRecord::link):
3777         * wasm/js/WebAssemblyToJSCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
3778         (JSC::WebAssemblyToJSCallee::create): dummy JSCell singleton which lives on the VM, and is put as the callee in the import stub's frame to identified it when unwinding
3779         (JSC::WebAssemblyToJSCallee::createStructure):
3780         (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
3781         (JSC::WebAssemblyToJSCallee::finishCreation):
3782         (JSC::WebAssemblyToJSCallee::destroy):
3783         * wasm/js/WebAssemblyToJSCallee.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h.
3784
3785 2016-12-08  Mark Lam  <mark.lam@apple.com>
3786
3787         Enable JSC restricted options by default in the jsc shell.
3788         https://bugs.webkit.org/show_bug.cgi?id=165615
3789
3790         Reviewed by Keith Miller.
3791
3792         The jsc shell is only used for debugging and development testing.  We should
3793         allow it to use restricted options like JSC_useDollarVM even for release builds.
3794
3795         * jsc.cpp:
3796         (jscmain):
3797         * runtime/Options.cpp:
3798         (JSC::Options::enableRestrictedOptions):
3799         (JSC::Options::isAvailable):
3800         (JSC::allowRestrictedOptions): Deleted.
3801         * runtime/Options.h:
3802
3803 2016-12-08  Chris Dumez  <cdumez@apple.com>
3804
3805         Unreviewed, rolling out r209489.
3806
3807         Likely caused large regressions on JetStream, Sunspider and
3808         Speedometer
3809
3810         Reverted changeset:
3811
3812         "Add system trace points for JavaScript VM entry/exit"
3813         https://bugs.webkit.org/show_bug.cgi?id=165550
3814         http://trac.webkit.org/changeset/209489
3815
3816 2016-12-08  Keith Miller  <keith_miller@apple.com>
3817
3818         Move LEB tests to API tests
3819         https://bugs.webkit.org/show_bug.cgi?id=165586
3820
3821         Reviewed by Saam Barati.
3822
3823         Delete old stuff.
3824
3825         * testWasm.cpp:
3826         (printUsageStatement):
3827         (CommandLine::parseArguments):
3828         (main):
3829         (runLEBTests): Deleted.
3830
3831 2016-12-07  JF Bastien  <jfbastien@apple.com>
3832
3833         Cleanup WebAssembly's RETURN_IF_EXCEPTION
3834         https://bugs.webkit.org/show_bug.cgi?id=165595
3835
3836         Reviewed by Filip Pizlo.
3837
3838         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
3839         (JSC::constructJSWebAssemblyCompileError):
3840         * wasm/js/WebAssemblyFunction.cpp:
3841         (JSC::callWebAssemblyFunction):
3842         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
3843         (JSC::constructJSWebAssemblyRuntimeError):
3844
3845 2016-12-07  Geoffrey Garen  <ggaren@apple.com>
3846
3847         Renamed SourceCode members to match their accessor names
3848         https://bugs.webkit.org/show_bug.cgi?id=165573
3849
3850         Reviewed by Keith Miller.
3851
3852         startChar => startOffset
3853         endChar => endOffset
3854
3855         * parser/UnlinkedSourceCode.h:
3856         (JSC::UnlinkedSourceCode::UnlinkedSourceCode):
3857         (JSC::UnlinkedSourceCode::view):
3858         (JSC::UnlinkedSourceCode::startOffset):
3859         (JSC::UnlinkedSourceCode::endOffset):
3860         (JSC::UnlinkedSourceCode::length):
3861
3862 2016-12-07  Keith Miller  <keith_miller@apple.com>
3863
3864         Add more missing trivial wasm ops.
3865         https://bugs.webkit.org/show_bug.cgi?id=165564
3866
3867         Reviewed by Geoffrey Garen.
3868
3869         This patch adds the nop, drop, and tee_local opcodes.