Concurrent GC should be able to run splay in debug mode and earley/raytrace in releas...
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-11-18  Filip Pizlo  <fpizlo@apple.com>
2
3         Concurrent GC should be able to run splay in debug mode and earley/raytrace in release mode with no perf regression
4         https://bugs.webkit.org/show_bug.cgi?id=164282
5
6         Reviewed by Geoffrey Garen and Oliver Hunt.
7         
8         The two three remaining bugs were:
9
10         - Improper ordering inside putDirectWithoutTransition() and friends. We need to make sure
11           that the GC doesn't see the store to Structure::m_offset until we've resized the butterfly.
12           That proved a bit tricky. On the other hand, this means that we could probably remove the
13           requirement that the GC holds the Structure lock in some cases. I haven't removed that lock
14           yet because I still think it might protect some weird cases, and it doesn't seem to cost us
15           anything.
16         
17         - CodeBlock's GC strategy needed to be made thread-safe (visitWeakly, visitChildren, and
18           their friends now hold locks) and incremental-safe (we need to update predictions in the
19           finalizer to make sure we clear anything that was put into a value profile towards the end
20           of GC).
21         
22         - The GC timeslicing scheduler needed to be made a bit more aggressive to deal with
23           generational workloads like earley, raytrace, and CDjs. Once I got those benchmarks to run,
24           I found that they would do many useless iterations of GC because they wouldn't pause long
25           enough after rescanning weak references and roots. I added a bunch of knobs for forcing a
26           pause. In the end, I realized that I could get the desired effect by putting a ceiling on
27           mutator utilization. We want the GC to finish quickly if it is possible to do so, even if
28           the amount of allocation that the mutator had done is low. Having a utilization ceiling
29           seems to accomplish this for benchmarks with trivial heaps (earley and raytrace) as well as
30           huge heaps (like CDjs in its "large" configuration).
31         
32         This preserves splay performance, makes the concurrent GC more stable, and makes the
33         concurrent GC not a perf regression on earley or raytrace. It seems to give us great CDjs
34         performance as well, but this is still hard to tell because we crash a lot in that benchmark.
35
36         * bytecode/CodeBlock.cpp:
37         (JSC::CodeBlock::CodeBlock):
38         (JSC::CodeBlock::visitWeakly):
39         (JSC::CodeBlock::visitChildren):
40         (JSC::CodeBlock::shouldVisitStrongly):
41         (JSC::CodeBlock::shouldJettisonDueToOldAge):
42         (JSC::CodeBlock::propagateTransitions):
43         (JSC::CodeBlock::determineLiveness):
44         (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
45         (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally):
46         (JSC::CodeBlock::visitOSRExitTargets):
47         (JSC::CodeBlock::stronglyVisitStrongReferences):
48         (JSC::CodeBlock::stronglyVisitWeakReferences):
49         * bytecode/CodeBlock.h:
50         (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
51         * heap/CodeBlockSet.cpp:
52         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
53         * heap/Heap.cpp:
54         (JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope):
55         (JSC::Heap::markToFixpoint):
56         (JSC::Heap::beginMarking):
57         (JSC::Heap::addToRememberedSet):
58         (JSC::Heap::collectInThread):
59         * heap/Heap.h:
60         * heap/HeapInlines.h:
61         (JSC::Heap::mutatorFence):
62         * heap/MarkedBlock.cpp:
63         * runtime/JSCellInlines.h:
64         (JSC::JSCell::finishCreation):
65         * runtime/JSObjectInlines.h:
66         (JSC::JSObject::putDirectWithoutTransition):
67         (JSC::JSObject::putDirectInternal):
68         * runtime/Options.h:
69         * runtime/Structure.cpp:
70         (JSC::Structure::add):
71         * runtime/Structure.h:
72         * runtime/StructureInlines.h:
73         (JSC::Structure::add):
74
75 2016-11-18  Joseph Pecoraro  <pecoraro@apple.com>
76
77         Web Inspector: Generator functions should have a displayable name when shown in stack traces
78         https://bugs.webkit.org/show_bug.cgi?id=164844
79         <rdar://problem/29300697>
80
81         Reviewed by Yusuke Suzuki.
82
83         * parser/SyntaxChecker.h:
84         (JSC::SyntaxChecker::createGeneratorFunctionBody):
85         * parser/ASTBuilder.h:
86         (JSC::ASTBuilder::createGeneratorFunctionBody):
87         New way to create a generator function with an inferred name.
88
89         * parser/Parser.cpp:
90         (JSC::Parser<LexerType>::parseInner):
91         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
92         * parser/Parser.h:
93         Pass on the name of the generator wrapper function so we can
94         use it on the inner generator function.
95
96 2016-11-17  Ryosuke Niwa  <rniwa@webkit.org>
97
98         Add an experimental API to find elements across shadow boundaries
99         https://bugs.webkit.org/show_bug.cgi?id=164851
100         <rdar://problem/28220092>
101
102         Reviewed by Sam Weinig.
103
104         * runtime/CommonIdentifiers.h:
105
106 2016-11-17  Yusuke Suzuki  <utatane.tea@gmail.com>
107
108         [JSC] Drop arguments.caller
109         https://bugs.webkit.org/show_bug.cgi?id=164859
110
111         Reviewed by Saam Barati.
112
113         Originally, some JavaScript engine has `arguments.caller` property.
114         But it easily causes some information leaks and it becomes obstacles
115         for secure ECMAScript (SES). In ES5, we make it deprecated in strict
116         mode. To do so, we explicitly set "caller" getter throwing TypeError
117         to arguments in strict mode.
118
119         But now, there is no modern engine which supports `arguments.caller`
120         in sloppy mode. So the original compatibility problem is gone and
121         "caller" getter in the strict mode arguments becomes meaningless.
122
123         ES2017 drops this from the spec. In this patch, we also drop this
124         `arguments.caller` in strict mode support.
125
126         Note that Function#caller is still alive.
127
128         * runtime/ClonedArguments.cpp:
129         (JSC::ClonedArguments::getOwnPropertySlot):
130         (JSC::ClonedArguments::put):
131         (JSC::ClonedArguments::deleteProperty):
132         (JSC::ClonedArguments::defineOwnProperty):
133         (JSC::ClonedArguments::materializeSpecials):
134
135 2016-11-17  Mark Lam  <mark.lam@apple.com>
136
137         Inlining should be disallowed when JSC_alwaysUseShadowChicken=true.
138         https://bugs.webkit.org/show_bug.cgi?id=164893
139         <rdar://problem/29146436>
140
141         Reviewed by Saam Barati.
142
143         * runtime/Options.cpp:
144         (JSC::recomputeDependentOptions):
145
146 2016-11-17  Filip Pizlo  <fpizlo@apple.com>
147
148         Speculatively disable eager object zero-fill on not-x86 to let the bots decide if that's a problem
149         https://bugs.webkit.org/show_bug.cgi?id=164885
150
151         Reviewed by Mark Lam.
152         
153         This adds a useGCFences() function that we use to guard all eager object zero-fill and the
154         related fences. It currently returns true only on x86().
155         
156         The goal here is to get the bots to tell us if this code is responsible for perf issues on
157         any non-x86 platforms. We have a few different paths that we can pursue if this turns out
158         to be the case. Eager zero-fill is merely the easiest way to optimize out some fences, but
159         we could get rid of it and instead teach B3 how to think about fences.
160
161         * assembler/CPU.h:
162         (JSC::useGCFences):
163         * bytecode/PolymorphicAccess.cpp:
164         (JSC::AccessCase::generateImpl):
165         * dfg/DFGSpeculativeJIT.cpp:
166         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
167         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
168         * ftl/FTLLowerDFGToB3.cpp:
169         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
170         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
171         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
172         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
173         (JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
174         (JSC::FTL::DFG::LowerDFGToB3::setButterfly):
175         * jit/AssemblyHelpers.h:
176         (JSC::AssemblyHelpers::mutatorFence):
177         (JSC::AssemblyHelpers::storeButterfly):
178         (JSC::AssemblyHelpers::emitInitializeInlineStorage):
179         (JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
180
181 2016-11-17  Keith Miller  <keith_miller@apple.com>
182
183         Add rotate to Wasm
184         https://bugs.webkit.org/show_bug.cgi?id=164871
185
186         Reviewed by Filip Pizlo.
187
188         Add rotate left and rotate right to Wasm. These directly map to B3 opcodes.
189         This also moves arm specific transformations of rotate left to lower macros
190         after optimization. It's a bad idea to have platform specific canonicalizations
191         in reduce strength since other optimizations may not be aware of it.
192
193         Add a bug to do pure CSE after lower macros after optimization since we want to
194         clean up RotL(value, Neg(Neg(shift))).
195
196         * b3/B3Generate.cpp:
197         (JSC::B3::generateToAir):
198         * b3/B3LowerMacrosAfterOptimizations.cpp:
199         * b3/B3ReduceStrength.cpp:
200         * wasm/wasm.json:
201
202 2016-11-17  Keith Miller  <keith_miller@apple.com>
203
204         Add sqrt to Wasm
205         https://bugs.webkit.org/show_bug.cgi?id=164877
206
207         Reviewed by Mark Lam.
208
209         B3 already has a Sqrt opcode we just need to map Wasm to it.
210
211         * wasm/wasm.json:
212
213 2016-11-17  Keith Miller  <keith_miller@apple.com>
214
215         Add support for rotate in B3 and the relevant assemblers
216         https://bugs.webkit.org/show_bug.cgi?id=164869
217
218         Reviewed by Geoffrey Garen.
219
220         This patch runs RotR and RotL (rotate right and left respectively)
221         through B3 and B3's assemblers. One thing of note is that ARM64 does
222         not support rotate left instead it allows negative right rotations.
223
224         This patch also fixes a theoretical bug in the assembler where
225         on X86 doing someShiftOp(reg, edx) would instead shift the shift
226         amount by the value. Additionally, this patch refactors some
227         of the X86 assembler to use templates when deciding how to format
228         the appropriate shift instruction.
229
230         * assembler/MacroAssemblerARM64.h:
231         (JSC::MacroAssemblerARM64::rotateRight32):
232         (JSC::MacroAssemblerARM64::rotateRight64):
233         * assembler/MacroAssemblerX86Common.h:
234         (JSC::MacroAssemblerX86Common::rotateRight32):
235         (JSC::MacroAssemblerX86Common::rotateLeft32):
236         * assembler/MacroAssemblerX86_64.h:
237         (JSC::MacroAssemblerX86_64::lshift64):
238         (JSC::MacroAssemblerX86_64::rshift64):
239         (JSC::MacroAssemblerX86_64::urshift64):
240         (JSC::MacroAssemblerX86_64::rotateRight64):
241         (JSC::MacroAssemblerX86_64::rotateLeft64):
242         (JSC::MacroAssemblerX86_64::or64):
243         * assembler/X86Assembler.h:
244         (JSC::X86Assembler::xorq_rm):
245         (JSC::X86Assembler::shiftInstruction32):
246         (JSC::X86Assembler::sarl_i8r):
247         (JSC::X86Assembler::shrl_i8r):
248         (JSC::X86Assembler::shll_i8r):
249         (JSC::X86Assembler::rorl_i8r):
250         (JSC::X86Assembler::rorl_CLr):
251         (JSC::X86Assembler::roll_i8r):
252         (JSC::X86Assembler::roll_CLr):
253         (JSC::X86Assembler::shiftInstruction64):
254         (JSC::X86Assembler::sarq_CLr):
255         (JSC::X86Assembler::sarq_i8r):
256         (JSC::X86Assembler::shrq_i8r):
257         (JSC::X86Assembler::shlq_i8r):
258         (JSC::X86Assembler::rorq_i8r):
259         (JSC::X86Assembler::rorq_CLr):
260         (JSC::X86Assembler::rolq_i8r):
261         (JSC::X86Assembler::rolq_CLr):
262         * b3/B3Common.h:
263         (JSC::B3::rotateRight):
264         (JSC::B3::rotateLeft):
265         * b3/B3Const32Value.cpp:
266         (JSC::B3::Const32Value::rotRConstant):
267         (JSC::B3::Const32Value::rotLConstant):
268         * b3/B3Const32Value.h:
269         * b3/B3Const64Value.cpp:
270         (JSC::B3::Const64Value::rotRConstant):
271         (JSC::B3::Const64Value::rotLConstant):
272         * b3/B3Const64Value.h:
273         * b3/B3LowerToAir.cpp:
274         (JSC::B3::Air::LowerToAir::lower):
275         * b3/B3Opcode.cpp:
276         (WTF::printInternal):
277         * b3/B3Opcode.h:
278         * b3/B3ReduceStrength.cpp:
279         * b3/B3Validate.cpp:
280         * b3/B3Value.cpp:
281         (JSC::B3::Value::rotRConstant):
282         (JSC::B3::Value::rotLConstant):
283         (JSC::B3::Value::effects):
284         (JSC::B3::Value::key):
285         (JSC::B3::Value::typeFor):
286         * b3/B3Value.h:
287         * b3/B3ValueKey.cpp:
288         (JSC::B3::ValueKey::materialize):
289         * b3/air/AirInstInlines.h:
290         (JSC::B3::Air::isRotateRight32Valid):
291         (JSC::B3::Air::isRotateLeft32Valid):
292         (JSC::B3::Air::isRotateRight64Valid):
293         (JSC::B3::Air::isRotateLeft64Valid):
294         * b3/air/AirOpcode.opcodes:
295         * b3/testb3.cpp:
296         (JSC::B3::testRotR):
297         (JSC::B3::testRotL):
298         (JSC::B3::testRotRWithImmShift):
299         (JSC::B3::testRotLWithImmShift):
300         (JSC::B3::run):
301
302 2016-11-17  Saam Barati  <sbarati@apple.com>
303
304         Remove async/await compile time flag and enable tests
305         https://bugs.webkit.org/show_bug.cgi?id=164828
306         <rdar://problem/28639334>
307
308         Reviewed by Yusuke Suzuki.
309
310         * Configurations/FeatureDefines.xcconfig:
311         * parser/Parser.cpp:
312         (JSC::Parser<LexerType>::parseStatementListItem):
313         (JSC::Parser<LexerType>::parseStatement):
314         (JSC::Parser<LexerType>::parseClass):
315         (JSC::Parser<LexerType>::parseExportDeclaration):
316         (JSC::Parser<LexerType>::parseAssignmentExpression):
317         (JSC::Parser<LexerType>::parseProperty):
318         (JSC::Parser<LexerType>::parsePrimaryExpression):
319         (JSC::Parser<LexerType>::parseMemberExpression):
320         (JSC::Parser<LexerType>::parseUnaryExpression):
321
322 2016-11-17  Yusuke Suzuki  <utatane.tea@gmail.com>
323
324         [JSC] WTF::TemporaryChange with WTF::SetForScope
325         https://bugs.webkit.org/show_bug.cgi?id=164761
326
327         Reviewed by Saam Barati.
328
329         * bytecompiler/BytecodeGenerator.h:
330         * bytecompiler/SetForScope.h: Removed.
331         * debugger/Debugger.cpp:
332         * inspector/InspectorBackendDispatcher.cpp:
333         (Inspector::BackendDispatcher::dispatch):
334         * inspector/ScriptDebugServer.cpp:
335         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
336         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
337         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
338         (Inspector::ScriptDebugServer::sourceParsed):
339         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
340         * parser/Parser.cpp:
341
342 2016-11-16  Mark Lam  <mark.lam@apple.com>
343
344         ExceptionFuzz needs to placate exception check verification before overwriting a thrown exception.
345         https://bugs.webkit.org/show_bug.cgi?id=164843
346
347         Reviewed by Keith Miller.
348
349         The ThrowScope will check for unchecked simulated exceptions before throwing a
350         new exception.  This ensures that we don't quietly overwrite a pending exception
351         (which should never happen, with the only exception being to rethrow the same
352         exception).  However, ExceptionFuzz works by intentionally throwing its own
353         exception even when one may already exist thereby potentially overwriting an
354         existing exception.  This is ok for ExceptionFuzz testing, but we need to placate
355         the exception check verifier before ExceptionFuzz throws its own exception.
356
357         * runtime/ExceptionFuzz.cpp:
358         (JSC::doExceptionFuzzing):
359
360 2016-11-16  Geoffrey Garen  <ggaren@apple.com>
361
362         UnlinkedCodeBlock should not have a starting line number
363         https://bugs.webkit.org/show_bug.cgi?id=164838
364
365         Reviewed by Mark Lam.
366
367         Here's how the starting line number in UnlinkedCodeBlock used to work:
368
369         (1) Assign the source code starting line number to the parser starting
370         line number.
371
372         (2) Assign (1) to the AST.
373
374         (3) Subtract (1) from (2) and assign to UnlinkedCodeBlock.
375
376         Then, when linking:
377
378         (4) Add (3) to (1).
379
380         This was an awesome no-op.
381
382         Generally, unlinked code is code that is not tied to any particular
383         web page or resource. So, it's inappropriate to think of it having a
384         starting line number.
385
386         * bytecode/UnlinkedCodeBlock.cpp:
387         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
388         * bytecode/UnlinkedCodeBlock.h:
389         (JSC::UnlinkedCodeBlock::recordParse):
390         (JSC::UnlinkedCodeBlock::hasCapturedVariables):
391         (JSC::UnlinkedCodeBlock::firstLine): Deleted.
392         * runtime/CodeCache.cpp:
393         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
394         * runtime/CodeCache.h:
395         (JSC::generateUnlinkedCodeBlock):
396
397 2016-11-16  Yusuke Suzuki  <utatane.tea@gmail.com>
398
399         [ES6][WebCore] Change ES6_MODULES compile time flag to runtime flag
400         https://bugs.webkit.org/show_bug.cgi?id=164827
401
402         Reviewed by Ryosuke Niwa.
403
404         * Configurations/FeatureDefines.xcconfig:
405
406 2016-11-16  Filip Pizlo  <fpizlo@apple.com>
407
408         Unreviewed, roll out r208811. It's not sound.
409
410         * ftl/FTLLowerDFGToB3.cpp:
411         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
412         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
413         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
414         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
415         (JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
416         (JSC::FTL::DFG::LowerDFGToB3::setButterfly):
417         (JSC::FTL::DFG::LowerDFGToB3::splatWordsIfMutatorIsFenced): Deleted.
418
419 2016-11-16  Keith Miller  <keith_miller@apple.com>
420
421         Wasm function parser should use template functions for each binary and unary opcode
422         https://bugs.webkit.org/show_bug.cgi?id=164835
423
424         Reviewed by Mark Lam.
425
426         This patch changes the wasm function parser to call into a template specialization
427         for each binary/unary opcode. This change makes it easier to have custom implementations
428         of various opcodes. It is also, in theory a speedup since it does not require switching
429         on the opcode twice.
430
431         * CMakeLists.txt:
432         * DerivedSources.make:
433         * wasm/WasmB3IRGenerator.cpp:
434         (): Deleted.
435         * wasm/WasmFunctionParser.h:
436         (JSC::Wasm::FunctionParser<Context>::binaryCase):
437         (JSC::Wasm::FunctionParser<Context>::unaryCase):
438         (JSC::Wasm::FunctionParser<Context>::parseExpression):
439         * wasm/WasmValidate.cpp:
440         * wasm/generateWasm.py:
441         (isBinary):
442         (isSimple):
443         * wasm/generateWasmB3IRGeneratorInlinesHeader.py: Added.
444         (generateSimpleCode):
445         * wasm/generateWasmOpsHeader.py:
446         (opcodeMacroizer):
447         * wasm/generateWasmValidateInlinesHeader.py:
448
449 2016-11-16  Mark Lam  <mark.lam@apple.com>
450
451         ExceptionFuzz functions should use its client's ThrowScope.
452         https://bugs.webkit.org/show_bug.cgi?id=164834
453
454         Reviewed by Geoffrey Garen.
455
456         This is because ExceptionFuzz's purpose is to throw exceptions from its client at
457         exception check sites.  Using the client's ThrowScope solves 2 problems:
458
459         1. If ExceptionFuzz instantiates its own ThrowScope, the simulated throw will be
460            mis-attributed to ExceptionFuzz when it should be attributed to its client.
461
462         2. One way exception scope verification works is by having ThrowScopes assert
463            that there are no unchecked simulated exceptions when the ThrowScope is
464            instantiated.  However, ExceptionFuzz necessarily works by inserting
465            doExceptionFuzzingIfEnabled() in between a ThrowScope that simulated a throw
466            and an exception check.  If we declare a ThrowScope in ExceptionFuzz's code,
467            we will be instantiating the ThrowScope between the point where a simulated
468            throw occurs and where the needed exception check can occur.  Hence, having
469            ExceptionFuzz instantiate its own ThrowScope will fail exception scope
470            verification every time.
471
472         Changing ExceptionFuzz to use its client's ThrowScope resolves both problems.
473
474         Also fixed the THROW() macro in CommonSlowPaths.cpp to use the ThrowScope that
475         already exists in every slow path function instead of creating a new one.
476
477         * jit/JITOperations.cpp:
478         * llint/LLIntSlowPaths.cpp:
479         * runtime/CommonSlowPaths.cpp:
480         * runtime/ExceptionFuzz.cpp:
481         (JSC::doExceptionFuzzing):
482         * runtime/ExceptionFuzz.h:
483         (JSC::doExceptionFuzzingIfEnabled):
484
485 2016-11-16  Filip Pizlo  <fpizlo@apple.com>
486
487         Slight Octane regression from concurrent GC's eager object zero-fill
488         https://bugs.webkit.org/show_bug.cgi?id=164823
489
490         Reviewed by Geoffrey Garen.
491         
492         During concurrent GC, we need to eagerly zero-fill objects we allocate prior to
493         executing the end-of-allocation fence. This causes some regressions. This is an attempt
494         to fix those regressions by making them conditional on whether the mutator is fenced.
495         
496         This is a slight speed-up on raytrace and boyer, and hopefully it will fix the
497         regression.
498
499         * ftl/FTLLowerDFGToB3.cpp:
500         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
501         (JSC::FTL::DFG::LowerDFGToB3::splatWordsIfMutatorIsFenced):
502         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
503         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
504         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
505         (JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
506         (JSC::FTL::DFG::LowerDFGToB3::setButterfly):
507
508 2016-11-16  Mark Lam  <mark.lam@apple.com>
509
510         Fix exception scope checking in JSGlobalObject.cpp.
511         https://bugs.webkit.org/show_bug.cgi?id=164831
512
513         Reviewed by Saam Barati.
514
515         * runtime/JSGlobalObject.cpp:
516         (JSC::JSGlobalObject::init):
517         - Use a CatchScope here because we don't ever expect JSGlobalObject initialization
518           to fail with errors.
519         (JSC::JSGlobalObject::put):
520         - Fix exception check requirements.
521
522 2016-11-16  Keith Miller  <keith_miller@apple.com>
523
524         Unreviewed, ARM build fix.
525
526         * b3/B3LowerToAir.cpp:
527         (JSC::B3::Air::LowerToAir::lower):
528         (JSC::B3::Air::LowerToAir::lowerX86Div):
529         (JSC::B3::Air::LowerToAir::lowerX86UDiv):
530
531 2016-11-15  Mark Lam  <mark.lam@apple.com>
532
533         Make JSC test functions more robust.
534         https://bugs.webkit.org/show_bug.cgi?id=164807
535
536         Reviewed by Keith Miller.
537
538         * jsc.cpp:
539         (functionGetHiddenValue):
540         (functionSetHiddenValue):
541
542 2016-11-15  Keith Miller  <keith_miller@apple.com>
543
544         B3 should support UDiv/UMod
545         https://bugs.webkit.org/show_bug.cgi?id=164811
546
547         Reviewed by Filip Pizlo.
548
549         This patch adds support for UDiv and UMod in B3. Many of the magic number
550         cases have been ommited for now since they are unlikely to happen in wasm
551         code. Most wasm code we will see is generated via llvm, which has more
552         robust versions of what we would do anyway. Additionally, this patch
553         links the new opcodes up to the wasm parser.
554
555         * assembler/MacroAssemblerARM64.h:
556         (JSC::MacroAssemblerARM64::uDiv32):
557         (JSC::MacroAssemblerARM64::uDiv64):
558         * assembler/MacroAssemblerX86Common.h:
559         (JSC::MacroAssemblerX86Common::x86UDiv32):
560         * assembler/MacroAssemblerX86_64.h:
561         (JSC::MacroAssemblerX86_64::x86UDiv64):
562         * assembler/X86Assembler.h:
563         (JSC::X86Assembler::divq_r):
564         * b3/B3Common.h:
565         (JSC::B3::chillUDiv):
566         (JSC::B3::chillUMod):
567         * b3/B3Const32Value.cpp:
568         (JSC::B3::Const32Value::uDivConstant):
569         (JSC::B3::Const32Value::uModConstant):
570         * b3/B3Const32Value.h:
571         * b3/B3Const64Value.cpp:
572         (JSC::B3::Const64Value::uDivConstant):
573         (JSC::B3::Const64Value::uModConstant):
574         * b3/B3Const64Value.h:
575         * b3/B3LowerMacros.cpp:
576         * b3/B3LowerToAir.cpp:
577         (JSC::B3::Air::LowerToAir::lower):
578         (JSC::B3::Air::LowerToAir::lowerX86UDiv):
579         * b3/B3Opcode.cpp:
580         (WTF::printInternal):
581         * b3/B3Opcode.h:
582         * b3/B3ReduceStrength.cpp:
583         * b3/B3Validate.cpp:
584         * b3/B3Value.cpp:
585         (JSC::B3::Value::uDivConstant):
586         (JSC::B3::Value::uModConstant):
587         (JSC::B3::Value::effects):
588         (JSC::B3::Value::key):
589         (JSC::B3::Value::typeFor):
590         * b3/B3Value.h:
591         * b3/B3ValueKey.cpp:
592         (JSC::B3::ValueKey::materialize):
593         * b3/air/AirInstInlines.h:
594         (JSC::B3::Air::isX86UDiv32Valid):
595         (JSC::B3::Air::isX86UDiv64Valid):
596         * b3/air/AirOpcode.opcodes:
597         * b3/testb3.cpp:
598         (JSC::B3::testUDivArgsInt32):
599         (JSC::B3::testUDivArgsInt64):
600         (JSC::B3::testUModArgsInt32):
601         (JSC::B3::testUModArgsInt64):
602         (JSC::B3::run):
603         * wasm/wasm.json:
604
605 2016-11-15  Joseph Pecoraro  <pecoraro@apple.com>
606
607         Web Inspector: Preview other CSS @media in browser window (print)
608         https://bugs.webkit.org/show_bug.cgi?id=13530
609         <rdar://problem/5712928>
610
611         Reviewed by Timothy Hatcher.
612
613         * inspector/protocol/Page.json:
614         Update to preferred JSON style.
615
616 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
617
618         Unreviewed, revert renaming useConcurrentJIT to useConcurrentJS.
619
620         * dfg/DFGDriver.cpp:
621         (JSC::DFG::compileImpl):
622         * heap/Heap.cpp:
623         (JSC::Heap::addToRememberedSet):
624         * jit/JITWorklist.cpp:
625         (JSC::JITWorklist::compileLater):
626         (JSC::JITWorklist::compileNow):
627         * runtime/Options.cpp:
628         (JSC::recomputeDependentOptions):
629         * runtime/Options.h:
630         * runtime/WriteBarrierInlines.h:
631         (JSC::WriteBarrierBase<T>::set):
632         (JSC::WriteBarrierBase<Unknown>::set):
633
634 2016-11-15  Geoffrey Garen  <ggaren@apple.com>
635
636         Debugging and other tools should not disable the code cache
637         https://bugs.webkit.org/show_bug.cgi?id=164802
638
639         Reviewed by Mark Lam.
640
641         * bytecode/UnlinkedFunctionExecutable.cpp:
642         (JSC::UnlinkedFunctionExecutable::fromGlobalCode): Updated for interface
643         change.
644
645         * parser/SourceCodeKey.h:
646         (JSC::SourceCodeFlags::SourceCodeFlags):
647         (JSC::SourceCodeFlags::bits):
648         (JSC::SourceCodeKey::SourceCodeKey): Treat debugging and other tools
649         as part of our key so that we can cache code while using tools. Be sure
650         to include these bits in our hash function so you don't get storms of
651         collisions as you open and close the Web Inspector.
652
653         * runtime/CodeCache.cpp:
654         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
655         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): Treat tools as
656         a part of our key instead of as a reason to disable caching.
657
658         * runtime/CodeCache.h:
659
660 2016-11-15  Mark Lam  <mark.lam@apple.com>
661
662         Remove JSString::SafeView and replace its uses with StringViewWithUnderlyingString.
663         https://bugs.webkit.org/show_bug.cgi?id=164777
664
665         Reviewed by Geoffrey Garen.
666
667         JSString::SafeView no longer achieves its intended goal to make it easier to
668         handle strings safely.  Its clients still need to do explicit exception checks in
669         order to be correct.  We'll remove it and replace its uses with
670         StringViewWithUnderlyingString instead which serves to gets the a StringView
671         (which is what we really wanted from SafeView) and keeps the backing String alive
672         while the view is in use.
673
674         Also added some missing exception checks.
675
676         * jsc.cpp:
677         (printInternal):
678         (functionDebug):
679         * runtime/ArrayPrototype.cpp:
680         (JSC::arrayProtoFuncJoin):
681         * runtime/FunctionConstructor.cpp:
682         (JSC::constructFunctionSkippingEvalEnabledCheck):
683         * runtime/IntlCollatorPrototype.cpp:
684         (JSC::IntlCollatorFuncCompare):
685         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
686         (JSC::genericTypedArrayViewProtoFuncJoin):
687         * runtime/JSGlobalObjectFunctions.cpp:
688         (JSC::toStringView):
689         (JSC::globalFuncParseFloat):
690         * runtime/JSONObject.cpp:
691         (JSC::JSONProtoFuncParse):
692         * runtime/JSString.h:
693         (JSC::JSString::SafeView::is8Bit): Deleted.
694         (JSC::JSString::SafeView::length): Deleted.
695         (JSC::JSString::SafeView::SafeView): Deleted.
696         (JSC::JSString::SafeView::get): Deleted.
697         (JSC::JSString::view): Deleted.
698         * runtime/StringPrototype.cpp:
699         (JSC::stringProtoFuncRepeatCharacter):
700         (JSC::stringProtoFuncCharAt):
701         (JSC::stringProtoFuncCharCodeAt):
702         (JSC::stringProtoFuncIndexOf):
703         (JSC::stringProtoFuncNormalize):
704
705 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
706
707         Unreviewed, remove bogus assertion.
708
709         * heap/Heap.cpp:
710         (JSC::Heap::markToFixpoint):
711
712 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
713
714         [mac-wk1 debug] ASSERTION FAILED: thisObject->m_propertyTableUnsafe
715         https://bugs.webkit.org/show_bug.cgi?id=162986
716
717         Reviewed by Saam Barati.
718         
719         This assertion is wrong for concurrent GC anyway, so this removes it.
720
721         * runtime/Structure.cpp:
722         (JSC::Structure::visitChildren):
723
724 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
725
726         Rename CONCURRENT_JIT/ConcurrentJIT to CONCURRENT_JS/ConcurrentJS
727         https://bugs.webkit.org/show_bug.cgi?id=164791
728
729         Reviewed by Geoffrey Garen.
730         
731         Just renaming.
732
733         * JavaScriptCore.xcodeproj/project.pbxproj:
734         * bytecode/ArrayProfile.cpp:
735         (JSC::ArrayProfile::computeUpdatedPrediction):
736         (JSC::ArrayProfile::briefDescription):
737         (JSC::ArrayProfile::briefDescriptionWithoutUpdating):
738         * bytecode/ArrayProfile.h:
739         (JSC::ArrayProfile::observedArrayModes):
740         (JSC::ArrayProfile::mayInterceptIndexedAccesses):
741         (JSC::ArrayProfile::mayStoreToHole):
742         (JSC::ArrayProfile::outOfBounds):
743         (JSC::ArrayProfile::usesOriginalArrayStructures):
744         * bytecode/CallLinkStatus.cpp:
745         (JSC::CallLinkStatus::computeFromLLInt):
746         (JSC::CallLinkStatus::computeFor):
747         (JSC::CallLinkStatus::computeExitSiteData):
748         (JSC::CallLinkStatus::computeFromCallLinkInfo):
749         (JSC::CallLinkStatus::computeDFGStatuses):
750         * bytecode/CallLinkStatus.h:
751         * bytecode/CodeBlock.cpp:
752         (JSC::CodeBlock::dumpValueProfiling):
753         (JSC::CodeBlock::dumpArrayProfiling):
754         (JSC::CodeBlock::finishCreation):
755         (JSC::CodeBlock::setConstantRegisters):
756         (JSC::CodeBlock::getStubInfoMap):
757         (JSC::CodeBlock::getCallLinkInfoMap):
758         (JSC::CodeBlock::getByValInfoMap):
759         (JSC::CodeBlock::addStubInfo):
760         (JSC::CodeBlock::addByValInfo):
761         (JSC::CodeBlock::addCallLinkInfo):
762         (JSC::CodeBlock::resetJITData):
763         (JSC::CodeBlock::shrinkToFit):
764         (JSC::CodeBlock::getArrayProfile):
765         (JSC::CodeBlock::addArrayProfile):
766         (JSC::CodeBlock::getOrAddArrayProfile):
767         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
768         (JSC::CodeBlock::updateAllArrayPredictions):
769         (JSC::CodeBlock::nameForRegister):
770         (JSC::CodeBlock::livenessAnalysisSlow):
771         * bytecode/CodeBlock.h:
772         (JSC::CodeBlock::setJITCode):
773         (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
774         (JSC::CodeBlock::addFrequentExitSite):
775         (JSC::CodeBlock::hasExitSite):
776         (JSC::CodeBlock::livenessAnalysis):
777         * bytecode/DFGExitProfile.cpp:
778         (JSC::DFG::ExitProfile::add):
779         (JSC::DFG::ExitProfile::hasExitSite):
780         (JSC::DFG::QueryableExitProfile::initialize):
781         * bytecode/DFGExitProfile.h:
782         (JSC::DFG::ExitProfile::hasExitSite):
783         * bytecode/GetByIdStatus.cpp:
784         (JSC::GetByIdStatus::hasExitSite):
785         (JSC::GetByIdStatus::computeFor):
786         (JSC::GetByIdStatus::computeForStubInfo):
787         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
788         * bytecode/GetByIdStatus.h:
789         * bytecode/LazyOperandValueProfile.cpp:
790         (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
791         (JSC::CompressedLazyOperandValueProfileHolder::add):
792         (JSC::LazyOperandValueProfileParser::initialize):
793         (JSC::LazyOperandValueProfileParser::prediction):
794         * bytecode/LazyOperandValueProfile.h:
795         * bytecode/MethodOfGettingAValueProfile.cpp:
796         (JSC::MethodOfGettingAValueProfile::emitReportValue):
797         * bytecode/PutByIdStatus.cpp:
798         (JSC::PutByIdStatus::hasExitSite):
799         (JSC::PutByIdStatus::computeFor):
800         (JSC::PutByIdStatus::computeForStubInfo):
801         * bytecode/PutByIdStatus.h:
802         * bytecode/StructureStubClearingWatchpoint.cpp:
803         (JSC::StructureStubClearingWatchpoint::fireInternal):
804         * bytecode/ValueProfile.h:
805         (JSC::ValueProfileBase::briefDescription):
806         (JSC::ValueProfileBase::computeUpdatedPrediction):
807         * dfg/DFGArrayMode.cpp:
808         (JSC::DFG::ArrayMode::fromObserved):
809         * dfg/DFGArrayMode.h:
810         (JSC::DFG::ArrayMode::withSpeculationFromProfile):
811         (JSC::DFG::ArrayMode::withProfile):
812         * dfg/DFGByteCodeParser.cpp:
813         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
814         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
815         (JSC::DFG::ByteCodeParser::getArrayMode):
816         (JSC::DFG::ByteCodeParser::handleInlining):
817         (JSC::DFG::ByteCodeParser::parseBlock):
818         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
819         * dfg/DFGDriver.cpp:
820         (JSC::DFG::compileImpl):
821         * dfg/DFGFixupPhase.cpp:
822         (JSC::DFG::FixupPhase::fixupNode):
823         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
824         * dfg/DFGGraph.cpp:
825         (JSC::DFG::Graph::tryGetConstantClosureVar):
826         * dfg/DFGObjectAllocationSinkingPhase.cpp:
827         * dfg/DFGPredictionInjectionPhase.cpp:
828         (JSC::DFG::PredictionInjectionPhase::run):
829         * ftl/FTLLowerDFGToB3.cpp:
830         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
831         * ftl/FTLOperations.cpp:
832         (JSC::FTL::operationMaterializeObjectInOSR):
833         * heap/Heap.cpp:
834         (JSC::Heap::addToRememberedSet):
835         * jit/JIT.cpp:
836         (JSC::JIT::compileWithoutLinking):
837         * jit/JITInlines.h:
838         (JSC::JIT::chooseArrayMode):
839         * jit/JITOperations.cpp:
840         (JSC::tryGetByValOptimize):
841         * jit/JITPropertyAccess.cpp:
842         (JSC::JIT::privateCompileGetByValWithCachedId):
843         (JSC::JIT::privateCompilePutByValWithCachedId):
844         * jit/JITWorklist.cpp:
845         (JSC::JITWorklist::compileLater):
846         (JSC::JITWorklist::compileNow):
847         * jit/Repatch.cpp:
848         (JSC::repatchGetByID):
849         (JSC::repatchPutByID):
850         * llint/LLIntSlowPaths.cpp:
851         (JSC::LLInt::setupGetByIdPrototypeCache):
852         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
853         (JSC::LLInt::setUpCall):
854         * profiler/ProfilerBytecodeSequence.cpp:
855         (JSC::Profiler::BytecodeSequence::BytecodeSequence):
856         * runtime/CommonSlowPaths.cpp:
857         (JSC::SLOW_PATH_DECL):
858         * runtime/CommonSlowPaths.h:
859         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
860         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
861         * runtime/ConcurrentJITLock.h: Removed.
862         * runtime/ConcurrentJSLock.h: Copied from Source/JavaScriptCore/runtime/ConcurrentJITLock.h.
863         (JSC::ConcurrentJSLockerBase::ConcurrentJSLockerBase):
864         (JSC::ConcurrentJSLockerBase::~ConcurrentJSLockerBase):
865         (JSC::GCSafeConcurrentJSLocker::GCSafeConcurrentJSLocker):
866         (JSC::GCSafeConcurrentJSLocker::~GCSafeConcurrentJSLocker):
867         (JSC::ConcurrentJSLocker::ConcurrentJSLocker):
868         (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase): Deleted.
869         (JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase): Deleted.
870         (JSC::ConcurrentJITLockerBase::unlockEarly): Deleted.
871         (JSC::GCSafeConcurrentJITLocker::GCSafeConcurrentJITLocker): Deleted.
872         (JSC::GCSafeConcurrentJITLocker::~GCSafeConcurrentJITLocker): Deleted.
873         (JSC::ConcurrentJITLocker::ConcurrentJITLocker): Deleted.
874         * runtime/InferredType.cpp:
875         (JSC::InferredType::canWatch):
876         (JSC::InferredType::addWatchpoint):
877         (JSC::InferredType::willStoreValueSlow):
878         (JSC::InferredType::makeTopSlow):
879         (JSC::InferredType::set):
880         (JSC::InferredType::removeStructure):
881         * runtime/InferredType.h:
882         * runtime/InferredTypeTable.cpp:
883         (JSC::InferredTypeTable::visitChildren):
884         (JSC::InferredTypeTable::get):
885         (JSC::InferredTypeTable::willStoreValue):
886         (JSC::InferredTypeTable::makeTop):
887         * runtime/InferredTypeTable.h:
888         * runtime/JSEnvironmentRecord.cpp:
889         (JSC::JSEnvironmentRecord::heapSnapshot):
890         * runtime/JSGlobalObject.cpp:
891         (JSC::JSGlobalObject::addGlobalVar):
892         (JSC::JSGlobalObject::addStaticGlobals):
893         * runtime/JSLexicalEnvironment.cpp:
894         (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
895         * runtime/JSObject.cpp:
896         (JSC::JSObject::deleteProperty):
897         (JSC::JSObject::shiftButterflyAfterFlattening):
898         * runtime/JSObject.h:
899         * runtime/JSObjectInlines.h:
900         (JSC::JSObject::putDirectWithoutTransition):
901         (JSC::JSObject::putDirectInternal):
902         * runtime/JSScope.cpp:
903         (JSC::abstractAccess):
904         (JSC::JSScope::collectClosureVariablesUnderTDZ):
905         * runtime/JSSegmentedVariableObject.cpp:
906         (JSC::JSSegmentedVariableObject::findVariableIndex):
907         (JSC::JSSegmentedVariableObject::addVariables):
908         (JSC::JSSegmentedVariableObject::heapSnapshot):
909         * runtime/JSSegmentedVariableObject.h:
910         * runtime/JSSymbolTableObject.cpp:
911         (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
912         * runtime/JSSymbolTableObject.h:
913         (JSC::symbolTableGet):
914         (JSC::symbolTablePut):
915         * runtime/Options.cpp:
916         (JSC::recomputeDependentOptions):
917         * runtime/Options.h:
918         * runtime/ProgramExecutable.cpp:
919         (JSC::ProgramExecutable::initializeGlobalProperties):
920         * runtime/RegExp.cpp:
921         (JSC::RegExp::compile):
922         (JSC::RegExp::matchConcurrently):
923         (JSC::RegExp::compileMatchOnly):
924         (JSC::RegExp::deleteCode):
925         * runtime/RegExp.h:
926         * runtime/Structure.cpp:
927         (JSC::Structure::materializePropertyTable):
928         (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
929         (JSC::Structure::addNewPropertyTransition):
930         (JSC::Structure::takePropertyTableOrCloneIfPinned):
931         (JSC::Structure::nonPropertyTransition):
932         (JSC::Structure::flattenDictionaryStructure):
933         (JSC::Structure::ensurePropertyReplacementWatchpointSet):
934         (JSC::Structure::add):
935         (JSC::Structure::remove):
936         (JSC::Structure::visitChildren):
937         * runtime/Structure.h:
938         * runtime/StructureInlines.h:
939         (JSC::Structure::propertyReplacementWatchpointSet):
940         (JSC::Structure::add):
941         (JSC::Structure::remove):
942         * runtime/SymbolTable.cpp:
943         (JSC::SymbolTable::visitChildren):
944         (JSC::SymbolTable::localToEntry):
945         (JSC::SymbolTable::entryFor):
946         (JSC::SymbolTable::prepareForTypeProfiling):
947         (JSC::SymbolTable::uniqueIDForVariable):
948         (JSC::SymbolTable::uniqueIDForOffset):
949         (JSC::SymbolTable::globalTypeSetForOffset):
950         (JSC::SymbolTable::globalTypeSetForVariable):
951         * runtime/SymbolTable.h:
952         * runtime/TypeSet.cpp:
953         (JSC::TypeSet::addTypeInformation):
954         (JSC::TypeSet::invalidateCache):
955         * runtime/TypeSet.h:
956         (JSC::TypeSet::structureSet):
957         * runtime/VM.h:
958         * runtime/WriteBarrierInlines.h:
959         (JSC::WriteBarrierBase<T>::set):
960         (JSC::WriteBarrierBase<Unknown>::set):
961         * yarr/YarrInterpreter.cpp:
962         (JSC::Yarr::ByteCompiler::compile):
963         (JSC::Yarr::byteCompile):
964         * yarr/YarrInterpreter.h:
965         (JSC::Yarr::BytecodePattern::BytecodePattern):
966
967 2016-11-15  Joseph Pecoraro  <pecoraro@apple.com>
968
969         Web Inspector: Remove unused and untested Page.setTouchEmulationEnabled command
970         https://bugs.webkit.org/show_bug.cgi?id=164793
971
972         Reviewed by Matt Baker.
973
974         * inspector/protocol/Page.json:
975
976 2016-11-15  Yusuke Suzuki  <utatane.tea@gmail.com>
977
978         Unreviewed, build fix for Windows debug build after r208738
979         https://bugs.webkit.org/show_bug.cgi?id=164727
980
981         This static member variable can be touched outside of the JSC project
982         since inlined MacroAssembler member functions read / write it.
983         So it should be exported.
984
985         * assembler/MacroAssemblerX86Common.h:
986
987 2016-11-15  Joseph Pecoraro  <pecoraro@apple.com>
988
989         Web Inspector: inspector/worker/debugger-pause.html fails on WebKit1
990         https://bugs.webkit.org/show_bug.cgi?id=164787
991
992         Reviewed by Timothy Hatcher.
993
994         * inspector/agents/InspectorDebuggerAgent.cpp:
995         (Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
996         Clear this DebuggerAgent state when we resume.
997
998 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
999
1000         It should be possible to disable concurrent GC timeslicing
1001         https://bugs.webkit.org/show_bug.cgi?id=164788
1002
1003         Reviewed by Saam Barati.
1004         
1005         Collector timeslicing means that the collector will try to pause once every 2ms. This is
1006         great because it throttles the mutator and prevents it from outpacing the collector. But
1007         it reduces some of the efficacy of the collectContinuously=true configuration: while
1008         it's great that collecting continuously means that the collector will also pause more
1009         frequently and so it will test the pausing code, it also means that the collector will
1010         spend less time running concurrently. The primary purpose of collectContinuously is to
1011         maximize the amount of time that the collector is running concurrently to the mutator to
1012         maximize the likelihood that a race will cause a detectable error.
1013         
1014         This adds an option to disable collector timeslicing (useCollectorTimeslicing=false).
1015         The idea is that we will usually use this in conjunction with collectContinuously=true
1016         to find race conditions during marking, but we can also use the two options
1017         independently to focus our testing on other things.
1018
1019         * heap/Heap.cpp:
1020         (JSC::Heap::markToFixpoint):
1021         * heap/SlotVisitor.cpp:
1022         (JSC::SlotVisitor::drainInParallel): We should have added this helper ages ago.
1023         * heap/SlotVisitor.h:
1024         * runtime/Options.h:
1025
1026 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
1027
1028         The concurrent GC should have a timeslicing controller
1029         https://bugs.webkit.org/show_bug.cgi?id=164783
1030
1031         Reviewed by Geoffrey Garen.
1032         
1033         This adds a simple control system for deciding when the collector should let the mutator run
1034         and when it should stop the mutator. We definitely have to stop the mutator during certain
1035         collector phases, but during marking - which takes the most time - we can go either way.
1036         Normally we want to let the mutator run, but if the heap size starts to grow then we have to
1037         stop the mutator just to make sure it doesn't get too far ahead of the collector. That could
1038         lead to memory exhaustion, so it's better to just stop in that case.
1039         
1040         The controller tries to never stop the mutator for longer than short timeslices. It slices on
1041         a 2ms period (configurable via Options). The amount of that period that the collector spends
1042         with the mutator stopped is determined by the fraction of the collector's concurrent headroom
1043         that has been allocated over. The headroom is currently configured at 50% of what was
1044         allocated before the collector started.
1045         
1046         This moves a bunch of parameters into Options so that it's easier to play with different
1047         configurations.
1048         
1049         I tried these different values for the period:
1050         
1051         1ms: 30% worse than 2ms on splay-latency.
1052         2ms: best score on splay-latency: the tick time above the 99.5% percentile is <2ms.
1053         3ms: 40% worse than 2ms on splay-latency.
1054         4ms: 40% worse than 2ms on splay-latency.
1055         
1056         I also tried 100% headroom as an alternate to 50% and found it to be a worse.
1057         
1058         This patch is a 2x improvement on splay-latency with the default parameters and concurrent GC
1059         enabled. Prior to this change, the GC didn't have a good bound on its pause times, which
1060         would cause these problems. Concurrent GC is now 5.6x better on splay-latency than no
1061         concurrent GC.
1062
1063         * heap/Heap.cpp:
1064         (JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope):
1065         (JSC::Heap::markToFixpoint):
1066         (JSC::Heap::collectInThread):
1067         * runtime/Options.h:
1068
1069 2016-11-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1070
1071         Unreviewed, build fix for CLoop after r208738
1072         https://bugs.webkit.org/show_bug.cgi?id=164727
1073
1074         * jsc.cpp:
1075         (WTF::DOMJITFunctionObject::unsafeFunction):
1076         (WTF::DOMJITFunctionObject::finishCreation):
1077
1078 2016-11-15  Mark Lam  <mark.lam@apple.com>
1079
1080         The jsc shell's setImpureGetterDelegate() should ensure that the set value is an ImpureGetter.
1081         https://bugs.webkit.org/show_bug.cgi?id=164781
1082         <rdar://problem/28418590>
1083
1084         Reviewed by Geoffrey Garen and Michael Saboff.
1085
1086         * jsc.cpp:
1087         (functionSetImpureGetterDelegate):
1088
1089 2016-11-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1090
1091         [DOMJIT] Allow using macro assembler scratches in FTL CheckDOM
1092         https://bugs.webkit.org/show_bug.cgi?id=164727
1093
1094         Reviewed by Filip Pizlo.
1095
1096         While CallDOMGetter can use macro assembler scratch registers, we previiously
1097         assumed that CheckDOM code generator does not use macro assembler scratch registers.
1098         It is currently true in x86 environment. But it is not true in the other environments.
1099
1100         We should not limit DOMJIT::Patchpoint's functionality in such a way. We should allow
1101         arbitrary macro assembler operations inside the DOMJIT::Patchpoint. This patch allows
1102         CheckDOM to use macro assembler scratch registers.
1103
1104         * ftl/FTLLowerDFGToB3.cpp:
1105         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
1106         * jsc.cpp:
1107         (WTF::DOMJITFunctionObject::DOMJITFunctionObject):
1108         (WTF::DOMJITFunctionObject::createStructure):
1109         (WTF::DOMJITFunctionObject::create):
1110         (WTF::DOMJITFunctionObject::unsafeFunction):
1111         (WTF::DOMJITFunctionObject::safeFunction):
1112         (WTF::DOMJITFunctionObject::checkDOMJITNode):
1113         (WTF::DOMJITFunctionObject::finishCreation):
1114         (GlobalObject::finishCreation):
1115         (functionCreateDOMJITFunctionObject):
1116
1117 2016-11-14  Geoffrey Garen  <ggaren@apple.com>
1118
1119         CodeCache should stop pretending to cache builtins
1120         https://bugs.webkit.org/show_bug.cgi?id=164750
1121
1122         Reviewed by Saam Barati.
1123
1124         We were passing JSParserBuiltinMode to all CodeCache functions, but the
1125         passed-in value was always NotBuiltin.
1126
1127         Let's stop passing it.
1128
1129         * parser/SourceCodeKey.h:
1130         (JSC::SourceCodeFlags::SourceCodeFlags):
1131         (JSC::SourceCodeKey::SourceCodeKey):
1132         * runtime/CodeCache.cpp:
1133         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
1134         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
1135         (JSC::CodeCache::getUnlinkedGlobalEvalCodeBlock):
1136         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
1137         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
1138         * runtime/CodeCache.h:
1139         (JSC::generateUnlinkedCodeBlock):
1140         * runtime/JSGlobalObject.cpp:
1141         (JSC::JSGlobalObject::createProgramCodeBlock):
1142         (JSC::JSGlobalObject::createLocalEvalCodeBlock):
1143         (JSC::JSGlobalObject::createGlobalEvalCodeBlock):
1144         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
1145
1146 2016-11-15  Filip Pizlo  <fpizlo@apple.com>
1147
1148         REGRESSION (r208711-r208722): ASSERTION FAILED: hasInlineStorage()
1149         https://bugs.webkit.org/show_bug.cgi?id=164775
1150
1151         Reviewed by Mark Lam and Keith Miller.
1152         
1153         We were calling inlineStorage() which asserts that inline storage is not empty. But we
1154         were calling it in a context where it could be empty and that's fine. So, we now call
1155         inlineStorageUnsafe().
1156
1157         * runtime/JSObject.h:
1158         (JSC::JSFinalObject::JSFinalObject):
1159
1160 2016-11-14  Csaba Osztrogon√°c  <ossy@webkit.org>
1161
1162         [ARM] Unreviewed buildfix after r208720.
1163
1164         * assembler/MacroAssemblerARM.h:
1165         (JSC::MacroAssemblerARM::storeFence): Stub function copied from MacroAssemblerARMv7.h.
1166
1167 2016-11-14  Caitlin Potter  <caitp@igalia.com>
1168
1169         [JSC] do not reference AwaitExpression Promises in async function Promise chain
1170         https://bugs.webkit.org/show_bug.cgi?id=164753
1171
1172         Reviewed by Yusuke Suzuki.
1173
1174         Previously, long-running async functions which contained many AwaitExpressions
1175         would allocate and retain references to intermediate Promise objects for each `await`,
1176         resulting in a memory leak.
1177
1178         To mitigate this leak, a reference to the original Promise (and its resolve and reject
1179         functions) associated with the async function are kept, and passed to each call to
1180         @asyncFunctionResume, while intermediate Promises are discarded. This is done by adding
1181         a new Register to the BytecodeGenerator to hold the PromiseCapability object associated
1182         with an async function wrapper. The capability is used to reject the Promise if an
1183         exception is thrown during parameter initialization, and is used to store the resulting
1184         value once the async function has terminated.
1185
1186         * builtins/AsyncFunctionPrototype.js:
1187         (globalPrivate.asyncFunctionResume):
1188         * bytecompiler/BytecodeGenerator.cpp:
1189         (JSC::BytecodeGenerator::BytecodeGenerator):
1190         * bytecompiler/BytecodeGenerator.h:
1191         (JSC::BytecodeGenerator::promiseCapabilityRegister):
1192         * bytecompiler/NodesCodegen.cpp:
1193         (JSC::FunctionNode::emitBytecode):
1194
1195 2016-11-14  Joseph Pecoraro  <pecoraro@apple.com>
1196
1197         Web Inspector: Worker debugging should pause all targets and view call frames in all targets
1198         https://bugs.webkit.org/show_bug.cgi?id=164305
1199         <rdar://problem/29056192>
1200
1201         Reviewed by Timothy Hatcher.
1202
1203         * inspector/InjectedScriptSource.js:
1204         (InjectedScript.prototype._propertyDescriptors):
1205         Accessing __proto__ does a ToThis(...) conversion on the receiver.
1206         In the case of GlobalObjects (such as WorkerGlobalScope when paused)
1207         this would return undefined and throw an exception. We can use
1208         Object.getPrototypeOf to avoid that conversion and possible error.
1209
1210         * inspector/protocol/Debugger.json:
1211         Provide a new way to effectively `resume` + `pause` immediately.
1212         This must be implemented on the backend to correctly synchronize
1213         the resuming and pausing.
1214
1215         * inspector/agents/InspectorDebuggerAgent.h:
1216         * inspector/agents/InspectorDebuggerAgent.cpp:
1217         (Inspector::InspectorDebuggerAgent::continueUntilNextRunLoop):
1218         Treat this as `resume` and `pause`. Resume now, and trigger
1219         a pause if the VM becomes idle and we didn't pause before then
1220         (such as hitting a breakpoint after we resumed).
1221
1222         (Inspector::InspectorDebuggerAgent::pause):
1223         (Inspector::InspectorDebuggerAgent::resume):
1224         (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
1225         (Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
1226         Clean up and correct pause on next statement logic.
1227
1228         (Inspector::InspectorDebuggerAgent::registerIdleHandler):
1229         (Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
1230         (Inspector::InspectorDebuggerAgent::didBecomeIdle):
1231         (Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping): Deleted.
1232         The idle handler may now also trigger a pause in the case
1233         where continueUntilNextRunLoop resumed and wants to pause.
1234
1235         (Inspector::InspectorDebuggerAgent::didPause):
1236         Eliminate the useless didPause. The DOMDebugger was keeping track
1237         of its own state that was worse then the state in DebuggerAgent.
1238
1239 2016-11-14  Filip Pizlo  <fpizlo@apple.com>
1240
1241         Unreviewed, fix cloop.
1242
1243         * runtime/JSCellInlines.h:
1244
1245 2016-11-14  Filip Pizlo  <fpizlo@apple.com>
1246
1247         The GC should be optionally concurrent and disabled by default
1248         https://bugs.webkit.org/show_bug.cgi?id=164454
1249
1250         Reviewed by Geoffrey Garen.
1251         
1252         This started out as a patch to have the GC scan the stack at the end, and then the
1253         outage happened and I decided to pick a more aggresive target: give the GC a concurrent
1254         mode that can be enabled at runtime, and whose only effect is that it turns on the
1255         ResumeTheWorldScope. This gives our GC a really intuitive workflow: by default, the GC
1256         thread is running solo with the world stopped and the parallel markers converged and
1257         waiting. We have a parallel work scope to enable the parallel markers and now we have a
1258         ResumeTheWorldScope that will optionally resume the world and then stop it again.
1259         
1260         It's easy to make a concurrent GC that always instantly crashes. I can't promise that
1261         this one won't do that when you run it. I set a specific goal: I wanted to do >10
1262         concurrent GCs in debug mode with generations, optimizing JITs, and parallel marking
1263         disabled.
1264         
1265         To reach this milestone, I needed to do a bunch of stuff:
1266         
1267         - The mutator needs a separate mark stack for the barrier, since it will mutate this
1268           stack concurrently to the collector's slot visitors.
1269         
1270         - The use of CellState to indicate whether an object is being scanned the first time or
1271           a subsequent time was racy. It fails spectacularly when a barrier is fired at the same
1272           time as visitChildren is running or if the barrier runs at the same time as the GC
1273           marks the same object. So, I split SlotVisitor's mark stacks. It's now the case that
1274           you know why you're being scanned by looking at which stack you came off of.
1275         
1276         - All of root marking must be in the collector fixpoint. I renamed markRoots to
1277           markToFixpoint. They say concurrency is hard, but the collector looks more intuitive
1278           this way. We never gained anything from forcing people to make a choice between
1279           scanning something in the fixpoint versus outside of it. Because root scanning is
1280           cheap, we can afford to do it repeatedly, which means all root scanning can now do
1281           constraint-based marking (like: I'll mark you if that thing is marked).
1282         
1283         - JSObject::visitChildren's scanning of the butterfly raced with property additions,
1284           indexed storage transitions and resizing, and a bunch of miscellaneous dirty butterfly
1285           reshaping functions - like the one that flattens a dictionary and some sneaky
1286           ArrayStorage transformations. Many of these can be fixed by using store-store fences
1287           in the mutator and load-load fences in the collector. I've adopted the rule that the
1288           collector must always see either a butterfly and structure that match or a newer
1289           butterfly with an older structure, where their age is just one transition apart. This
1290           can be achieved with fences. For the cases where it breaks down, I added a lock to
1291           every JSCell. This is a full-fledged WTF lock that we sneak into two available bits in
1292           the indexingType. See the WTF ChangeLog for details.
1293           
1294           The mutator fencing rules are as follows:
1295           
1296           - Store-store fence before and after setting the butterfly.
1297           - Store-store fence before setting structure if you had changed the shape of the
1298             butterfly.
1299           - Store-store fence after initializing all fields in an allocation.
1300         
1301         - A dictionary Structure can change in strange ways while the GC is trying to scan it.
1302           So, JSObject::visitChildren will now grab the object's structure's lock if the
1303           object's structure is a dictionary. Dictionary structures are 1:1 with their object,
1304           so this does not reduce GC parallelism (super unlikely that the GC will simultaneously
1305           scan an object from two threads).
1306         
1307         - The GC can blow away a Structure's property table at any time. As a small consolation,
1308           it's now holding the Structure's lock when it does so. But there was tons of code in
1309           Structure that uses DeferGC to prevent the GC from blowing away the property table.
1310           This doesn't work with concurrent GC, since DeferGC only means that the GC won't run
1311           its safepoint (i.e. stop-the-world code) in the DeferGC region. It will still do
1312           marking and it was the Structure::visitChildren that would delete the table. It turns
1313           out that Structure's reliance on the property table not being deleted was the product
1314           of code rot. We already had functions that would materialize the table on demand. We
1315           were simply making the mistake of saying:
1316           
1317               structure->materializePropertyMap();
1318               ...
1319               structure->propertyTable()->things
1320           
1321           Instead of saying:
1322           
1323               PropertyTable* table = structure->ensurePropertyTable();
1324               ...
1325               table->things
1326           
1327           Switching the code to use the latter idiom allowed me to simplify the code a lot while
1328           fixing the race.
1329         
1330         - The LLInt's get_by_val handling was broken because the indexing shape constants were
1331           wrong. Once I started putting more things into the IndexingType, that started causing
1332           crashes for me. So I fixed LLInt. That turned out to be a lot of work, since that code
1333           had rotted in subtle ways.
1334         
1335         This is a speed-up in SunSpider, probably because of the LLInt fix. This is neutral on
1336         Octane and Kraken. It's a smaller slow-down on LongSpider, but I think we can ignore
1337         that (we don't view LongSpider as an official benchmark). By default, the concurrent GC
1338         is disabled: in all of the places where it would have resumed the world to run marking
1339         concurrently to the mutator, it will just skip the resume step. When you enable
1340         concurrent GC (--useConcurrentGC=true), it can sometimes run Octane/splay to completion.
1341         It seems to perform quite well: on my machine, it improves both splay-throughput and
1342         splay-latency. It's probably unstable for other programs.
1343
1344         * API/JSVirtualMachine.mm:
1345         (-[JSVirtualMachine isOldExternalObject:]):
1346         * assembler/MacroAssemblerARMv7.h:
1347         (JSC::MacroAssemblerARMv7::storeFence):
1348         * bytecode/InlineAccess.cpp:
1349         (JSC::InlineAccess::dumpCacheSizesAndCrash):
1350         (JSC::InlineAccess::generateSelfPropertyAccess):
1351         (JSC::InlineAccess::generateArrayLength):
1352         * bytecode/ObjectAllocationProfile.h:
1353         (JSC::ObjectAllocationProfile::offsetOfInlineCapacity):
1354         (JSC::ObjectAllocationProfile::ObjectAllocationProfile):
1355         (JSC::ObjectAllocationProfile::initialize):
1356         (JSC::ObjectAllocationProfile::inlineCapacity):
1357         (JSC::ObjectAllocationProfile::clear):
1358         * bytecode/PolymorphicAccess.cpp:
1359         (JSC::AccessCase::generateWithGuard):
1360         (JSC::AccessCase::generateImpl):
1361         * dfg/DFGArrayifySlowPathGenerator.h:
1362         * dfg/DFGClobberize.h:
1363         (JSC::DFG::clobberize):
1364         * dfg/DFGOSRExitCompiler32_64.cpp:
1365         (JSC::DFG::OSRExitCompiler::compileExit):
1366         * dfg/DFGOSRExitCompiler64.cpp:
1367         (JSC::DFG::OSRExitCompiler::compileExit):
1368         * dfg/DFGOperations.cpp:
1369         * dfg/DFGPlan.cpp:
1370         (JSC::DFG::Plan::markCodeBlocks):
1371         (JSC::DFG::Plan::rememberCodeBlocks):
1372         * dfg/DFGPlan.h:
1373         * dfg/DFGSpeculativeJIT.cpp:
1374         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
1375         (JSC::DFG::SpeculativeJIT::checkArray):
1376         (JSC::DFG::SpeculativeJIT::arrayify):
1377         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1378         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
1379         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
1380         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
1381         (JSC::DFG::SpeculativeJIT::compileSpread):
1382         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
1383         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
1384         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
1385         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
1386         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1387         * dfg/DFGSpeculativeJIT64.cpp:
1388         (JSC::DFG::SpeculativeJIT::compile):
1389         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
1390         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1391         (JSC::DFG::TierUpCheckInjectionPhase::run):
1392         * dfg/DFGWorklist.cpp:
1393         (JSC::DFG::Worklist::markCodeBlocks):
1394         (JSC::DFG::Worklist::rememberCodeBlocks):
1395         (JSC::DFG::markCodeBlocks):
1396         (JSC::DFG::completeAllPlansForVM):
1397         (JSC::DFG::rememberCodeBlocks):
1398         * dfg/DFGWorklist.h:
1399         * ftl/FTLAbstractHeapRepository.cpp:
1400         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
1401         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
1402         * ftl/FTLAbstractHeapRepository.h:
1403         * ftl/FTLJITCode.cpp:
1404         (JSC::FTL::JITCode::~JITCode):
1405         * ftl/FTLLowerDFGToB3.cpp:
1406         (JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
1407         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
1408         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1409         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
1410         (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
1411         (JSC::FTL::DFG::LowerDFGToB3::compileNewObject):
1412         (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
1413         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
1414         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
1415         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
1416         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
1417         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1418         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
1419         (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
1420         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
1421         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
1422         (JSC::FTL::DFG::LowerDFGToB3::splatWords):
1423         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
1424         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
1425         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
1426         (JSC::FTL::DFG::LowerDFGToB3::isArrayType):
1427         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
1428         (JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
1429         (JSC::FTL::DFG::LowerDFGToB3::setButterfly):
1430         * ftl/FTLOSRExitCompiler.cpp:
1431         (JSC::FTL::compileStub):
1432         * ftl/FTLOutput.cpp:
1433         (JSC::FTL::Output::signExt32ToPtr):
1434         (JSC::FTL::Output::fence):
1435         * ftl/FTLOutput.h:
1436         * heap/CellState.h:
1437         * heap/GCSegmentedArray.h:
1438         * heap/Heap.cpp:
1439         (JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope):
1440         (JSC::Heap::ResumeTheWorldScope::~ResumeTheWorldScope):
1441         (JSC::Heap::Heap):
1442         (JSC::Heap::~Heap):
1443         (JSC::Heap::harvestWeakReferences):
1444         (JSC::Heap::finalizeUnconditionalFinalizers):
1445         (JSC::Heap::completeAllJITPlans):
1446         (JSC::Heap::markToFixpoint):
1447         (JSC::Heap::gatherStackRoots):
1448         (JSC::Heap::beginMarking):
1449         (JSC::Heap::visitConservativeRoots):
1450         (JSC::Heap::visitCompilerWorklistWeakReferences):
1451         (JSC::Heap::updateObjectCounts):
1452         (JSC::Heap::endMarking):
1453         (JSC::Heap::addToRememberedSet):
1454         (JSC::Heap::collectInThread):
1455         (JSC::Heap::stopTheWorld):
1456         (JSC::Heap::resumeTheWorld):
1457         (JSC::Heap::setGCDidJIT):
1458         (JSC::Heap::setNeedFinalize):
1459         (JSC::Heap::setMutatorWaiting):
1460         (JSC::Heap::clearMutatorWaiting):
1461         (JSC::Heap::finalize):
1462         (JSC::Heap::flushWriteBarrierBuffer):
1463         (JSC::Heap::writeBarrierSlowPath):
1464         (JSC::Heap::canCollect):
1465         (JSC::Heap::reportExtraMemoryVisited):
1466         (JSC::Heap::reportExternalMemoryVisited):
1467         (JSC::Heap::notifyIsSafeToCollect):
1468         (JSC::Heap::markRoots): Deleted.
1469         (JSC::Heap::visitExternalRememberedSet): Deleted.
1470         (JSC::Heap::visitSmallStrings): Deleted.
1471         (JSC::Heap::visitProtectedObjects): Deleted.
1472         (JSC::Heap::visitArgumentBuffers): Deleted.
1473         (JSC::Heap::visitException): Deleted.
1474         (JSC::Heap::visitStrongHandles): Deleted.
1475         (JSC::Heap::visitHandleStack): Deleted.
1476         (JSC::Heap::visitSamplingProfiler): Deleted.
1477         (JSC::Heap::visitTypeProfiler): Deleted.
1478         (JSC::Heap::visitShadowChicken): Deleted.
1479         (JSC::Heap::traceCodeBlocksAndJITStubRoutines): Deleted.
1480         (JSC::Heap::visitWeakHandles): Deleted.
1481         (JSC::Heap::flushOldStructureIDTables): Deleted.
1482         (JSC::Heap::stopAllocation): Deleted.
1483         * heap/Heap.h:
1484         (JSC::Heap::collectorSlotVisitor):
1485         (JSC::Heap::mutatorMarkStack):
1486         (JSC::Heap::mutatorShouldBeFenced):
1487         (JSC::Heap::addressOfMutatorShouldBeFenced):
1488         (JSC::Heap::slotVisitor): Deleted.
1489         (JSC::Heap::notifyIsSafeToCollect): Deleted.
1490         (JSC::Heap::barrierShouldBeFenced): Deleted.
1491         (JSC::Heap::addressOfBarrierShouldBeFenced): Deleted.
1492         * heap/MarkStack.cpp:
1493         (JSC::MarkStackArray::transferTo):
1494         * heap/MarkStack.h:
1495         * heap/MarkedAllocator.cpp:
1496         (JSC::MarkedAllocator::tryAllocateIn):
1497         * heap/MarkedBlock.cpp:
1498         (JSC::MarkedBlock::MarkedBlock):
1499         (JSC::MarkedBlock::Handle::specializedSweep):
1500         (JSC::MarkedBlock::Handle::sweep):
1501         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
1502         (JSC::MarkedBlock::Handle::stopAllocating):
1503         (JSC::MarkedBlock::Handle::resumeAllocating):
1504         (JSC::MarkedBlock::aboutToMarkSlow):
1505         (JSC::MarkedBlock::Handle::didConsumeFreeList):
1506         (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor): Deleted.
1507         (JSC::SetNewlyAllocatedFunctor::operator()): Deleted.
1508         * heap/MarkedBlock.h:
1509         * heap/MarkedSpace.cpp:
1510         (JSC::MarkedSpace::resumeAllocating):
1511         * heap/SlotVisitor.cpp:
1512         (JSC::SlotVisitor::SlotVisitor):
1513         (JSC::SlotVisitor::~SlotVisitor):
1514         (JSC::SlotVisitor::reset):
1515         (JSC::SlotVisitor::clearMarkStacks):
1516         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
1517         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
1518         (JSC::SlotVisitor::appendToMarkStack):
1519         (JSC::SlotVisitor::appendToMutatorMarkStack):
1520         (JSC::SlotVisitor::visitChildren):
1521         (JSC::SlotVisitor::donateKnownParallel):
1522         (JSC::SlotVisitor::drain):
1523         (JSC::SlotVisitor::drainFromShared):
1524         (JSC::SlotVisitor::containsOpaqueRoot):
1525         (JSC::SlotVisitor::donateAndDrain):
1526         (JSC::SlotVisitor::mergeOpaqueRoots):
1527         (JSC::SlotVisitor::dump):
1528         (JSC::SlotVisitor::clearMarkStack): Deleted.
1529         (JSC::SlotVisitor::opaqueRootCount): Deleted.
1530         * heap/SlotVisitor.h:
1531         (JSC::SlotVisitor::collectorMarkStack):
1532         (JSC::SlotVisitor::mutatorMarkStack):
1533         (JSC::SlotVisitor::isEmpty):
1534         (JSC::SlotVisitor::bytesVisited):
1535         (JSC::SlotVisitor::markStack): Deleted.
1536         (JSC::SlotVisitor::bytesCopied): Deleted.
1537         * heap/SlotVisitorInlines.h:
1538         (JSC::SlotVisitor::reportExtraMemoryVisited):
1539         (JSC::SlotVisitor::reportExternalMemoryVisited):
1540         * jit/AssemblyHelpers.cpp:
1541         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
1542         * jit/AssemblyHelpers.h:
1543         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
1544         (JSC::AssemblyHelpers::barrierStoreLoadFence):
1545         (JSC::AssemblyHelpers::mutatorFence):
1546         (JSC::AssemblyHelpers::storeButterfly):
1547         (JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded):
1548         (JSC::AssemblyHelpers::emitInitializeInlineStorage):
1549         (JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
1550         (JSC::AssemblyHelpers::jumpIfBarrierStoreLoadFenceNotNeeded): Deleted.
1551         * jit/JITInlines.h:
1552         (JSC::JIT::emitArrayProfilingSiteWithCell):
1553         * jit/JITOperations.cpp:
1554         * jit/JITPropertyAccess.cpp:
1555         (JSC::JIT::emit_op_put_to_scope):
1556         (JSC::JIT::emit_op_put_to_arguments):
1557         * llint/LLIntData.cpp:
1558         (JSC::LLInt::Data::performAssertions):
1559         * llint/LowLevelInterpreter.asm:
1560         * llint/LowLevelInterpreter64.asm:
1561         * runtime/ButterflyInlines.h:
1562         (JSC::Butterfly::create):
1563         (JSC::Butterfly::createOrGrowPropertyStorage):
1564         * runtime/ConcurrentJITLock.h:
1565         (JSC::GCSafeConcurrentJITLocker::NoDefer::NoDefer): Deleted.
1566         * runtime/GenericArgumentsInlines.h:
1567         (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
1568         (JSC::GenericArguments<Type>::putByIndex):
1569         * runtime/IndexingType.h:
1570         * runtime/JSArray.cpp:
1571         (JSC::JSArray::unshiftCountSlowCase):
1572         (JSC::JSArray::unshiftCountWithArrayStorage):
1573         * runtime/JSCell.h:
1574         (JSC::JSCell::InternalLocker::InternalLocker):
1575         (JSC::JSCell::InternalLocker::~InternalLocker):
1576         (JSC::JSCell::atomicCompareExchangeCellStateWeakRelaxed):
1577         (JSC::JSCell::atomicCompareExchangeCellStateStrong):
1578         (JSC::JSCell::indexingTypeAndMiscOffset):
1579         (JSC::JSCell::indexingTypeOffset): Deleted.
1580         * runtime/JSCellInlines.h:
1581         (JSC::JSCell::JSCell):
1582         (JSC::JSCell::finishCreation):
1583         (JSC::JSCell::indexingTypeAndMisc):
1584         (JSC::JSCell::indexingType):
1585         (JSC::JSCell::setStructure):
1586         (JSC::JSCell::callDestructor):
1587         (JSC::JSCell::lockInternalLock):
1588         (JSC::JSCell::unlockInternalLock):
1589         * runtime/JSObject.cpp:
1590         (JSC::JSObject::visitButterfly):
1591         (JSC::JSObject::visitChildren):
1592         (JSC::JSFinalObject::visitChildren):
1593         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
1594         (JSC::JSObject::createInitialUndecided):
1595         (JSC::JSObject::createInitialInt32):
1596         (JSC::JSObject::createInitialDouble):
1597         (JSC::JSObject::createInitialContiguous):
1598         (JSC::JSObject::createArrayStorage):
1599         (JSC::JSObject::convertUndecidedToArrayStorage):
1600         (JSC::JSObject::convertInt32ToArrayStorage):
1601         (JSC::JSObject::convertDoubleToArrayStorage):
1602         (JSC::JSObject::convertContiguousToArrayStorage):
1603         (JSC::JSObject::deleteProperty):
1604         (JSC::JSObject::defineOwnIndexedProperty):
1605         (JSC::JSObject::increaseVectorLength):
1606         (JSC::JSObject::ensureLengthSlow):
1607         (JSC::JSObject::reallocateAndShrinkButterfly):
1608         (JSC::JSObject::allocateMoreOutOfLineStorage):
1609         (JSC::JSObject::shiftButterflyAfterFlattening):
1610         (JSC::JSObject::growOutOfLineStorage): Deleted.
1611         * runtime/JSObject.h:
1612         (JSC::JSFinalObject::JSFinalObject):
1613         (JSC::JSObject::setButterfly):
1614         (JSC::JSObject::getOwnNonIndexPropertySlot):
1615         (JSC::JSObject::fillCustomGetterPropertySlot):
1616         (JSC::JSObject::getOwnPropertySlot):
1617         (JSC::JSObject::getPropertySlot):
1618         (JSC::JSObject::setStructureAndButterfly): Deleted.
1619         (JSC::JSObject::setButterflyWithoutChangingStructure): Deleted.
1620         (JSC::JSObject::putDirectInternal): Deleted.
1621         (JSC::JSObject::putDirectWithoutTransition): Deleted.
1622         * runtime/JSObjectInlines.h:
1623         (JSC::JSObject::getPropertySlot):
1624         (JSC::JSObject::getNonIndexPropertySlot):
1625         (JSC::JSObject::putDirectWithoutTransition):
1626         (JSC::JSObject::putDirectInternal):
1627         * runtime/Options.h:
1628         * runtime/SparseArrayValueMap.h:
1629         * runtime/Structure.cpp:
1630         (JSC::Structure::dumpStatistics):
1631         (JSC::Structure::findStructuresAndMapForMaterialization):
1632         (JSC::Structure::materializePropertyTable):
1633         (JSC::Structure::addNewPropertyTransition):
1634         (JSC::Structure::changePrototypeTransition):
1635         (JSC::Structure::attributeChangeTransition):
1636         (JSC::Structure::toDictionaryTransition):
1637         (JSC::Structure::takePropertyTableOrCloneIfPinned):
1638         (JSC::Structure::nonPropertyTransition):
1639         (JSC::Structure::isSealed):
1640         (JSC::Structure::isFrozen):
1641         (JSC::Structure::flattenDictionaryStructure):
1642         (JSC::Structure::pin):
1643         (JSC::Structure::pinForCaching):
1644         (JSC::Structure::willStoreValueSlow):
1645         (JSC::Structure::copyPropertyTableForPinning):
1646         (JSC::Structure::add):
1647         (JSC::Structure::remove):
1648         (JSC::Structure::getPropertyNamesFromStructure):
1649         (JSC::Structure::visitChildren):
1650         (JSC::Structure::materializePropertyMap): Deleted.
1651         (JSC::Structure::addPropertyWithoutTransition): Deleted.
1652         (JSC::Structure::removePropertyWithoutTransition): Deleted.
1653         (JSC::Structure::copyPropertyTable): Deleted.
1654         (JSC::Structure::createPropertyMap): Deleted.
1655         (JSC::PropertyTable::checkConsistency): Deleted.
1656         (JSC::Structure::checkConsistency): Deleted.
1657         * runtime/Structure.h:
1658         * runtime/StructureIDBlob.h:
1659         (JSC::StructureIDBlob::StructureIDBlob):
1660         (JSC::StructureIDBlob::indexingTypeIncludingHistory):
1661         (JSC::StructureIDBlob::setIndexingTypeIncludingHistory):
1662         (JSC::StructureIDBlob::indexingTypeIncludingHistoryOffset):
1663         (JSC::StructureIDBlob::indexingType): Deleted.
1664         (JSC::StructureIDBlob::setIndexingType): Deleted.
1665         (JSC::StructureIDBlob::indexingTypeOffset): Deleted.
1666         * runtime/StructureInlines.h:
1667         (JSC::Structure::get):
1668         (JSC::Structure::checkOffsetConsistency):
1669         (JSC::Structure::checkConsistency):
1670         (JSC::Structure::add):
1671         (JSC::Structure::remove):
1672         (JSC::Structure::addPropertyWithoutTransition):
1673         (JSC::Structure::removePropertyWithoutTransition):
1674         (JSC::Structure::setPropertyTable):
1675         (JSC::Structure::putWillGrowOutOfLineStorage): Deleted.
1676         (JSC::Structure::propertyTable): Deleted.
1677         (JSC::Structure::suggestedNewOutOfLineStorageCapacity): Deleted.
1678
1679 2016-11-14  Keith Miller  <keith_miller@apple.com>
1680
1681         Add Wasm select
1682         https://bugs.webkit.org/show_bug.cgi?id=164743
1683
1684         Reviewed by Saam Barati.
1685
1686         Also, this patch fixes an issue with the jsc.cpp test harness where negative numbers would be sign extended
1687         when they shouldn't be.
1688
1689         * jsc.cpp:
1690         (box):
1691         * wasm/WasmB3IRGenerator.cpp:
1692         * wasm/WasmFunctionParser.h:
1693         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1694         * wasm/WasmValidate.cpp:
1695         (JSC::Wasm::Validate::addSelect):
1696
1697 2016-11-11  Geoffrey Garen  <ggaren@apple.com>
1698
1699         JSC should distinguish between local and global eval
1700         https://bugs.webkit.org/show_bug.cgi?id=164628
1701
1702         Reviewed by Saam Barati.
1703
1704         Local use of the 'eval' keyword and invocation of the global window.eval
1705         function are distinct operations in JavaScript.
1706
1707         This patch splits out LocalEvalExecutable vs GlobalEvalExecutable in
1708         order to help distinguish these operations in code.
1709
1710         Our code used to do some silly things for lack of distinguishing these
1711         cases. For example, it would double cache local eval in CodeCache and
1712         EvalCodeCache. This made CodeCache seem more complicated than it really
1713         was.
1714
1715         * CMakeLists.txt:
1716         * JavaScriptCore.xcodeproj/project.pbxproj: Added some files.
1717
1718         * bytecode/CodeBlock.h:
1719
1720         * bytecode/EvalCodeCache.h:
1721         (JSC::EvalCodeCache::tryGet):
1722         (JSC::EvalCodeCache::set):
1723         (JSC::EvalCodeCache::getSlow): Deleted. Moved code generation out of
1724         the cache to avoid tight coupling. Now the cache just caches.
1725
1726         * bytecode/UnlinkedEvalCodeBlock.h:
1727         * bytecode/UnlinkedFunctionExecutable.cpp:
1728         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1729         * bytecode/UnlinkedModuleProgramCodeBlock.h:
1730         * bytecode/UnlinkedProgramCodeBlock.h:
1731         * debugger/DebuggerCallFrame.cpp:
1732         (JSC::DebuggerCallFrame::evaluateWithScopeExtension): Updated for interface
1733         changes.
1734
1735         * interpreter/Interpreter.cpp:
1736         (JSC::eval): Moved code generation here so the cache didn't need to build
1737         it in.
1738
1739         * llint/LLIntOffsetsExtractor.cpp:
1740
1741         * runtime/CodeCache.cpp:
1742         (JSC::CodeCache::getUnlinkedGlobalCodeBlock): No need to check for TDZ
1743         variables any more. We only cache global programs, and global variable
1744         access always does TDZ checks.
1745
1746         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
1747         (JSC::CodeCache::getUnlinkedGlobalEvalCodeBlock):
1748         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
1749         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
1750
1751         (JSC::CodeCache::CodeCache): Deleted.
1752         (JSC::CodeCache::~CodeCache): Deleted.
1753         (JSC::CodeCache::getGlobalCodeBlock): Deleted.
1754         (JSC::CodeCache::getProgramCodeBlock): Deleted.
1755         (JSC::CodeCache::getEvalCodeBlock): Deleted.
1756         (JSC::CodeCache::getModuleProgramCodeBlock): Deleted.
1757         (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Deleted.
1758
1759         * runtime/CodeCache.h:
1760         (JSC::CodeCache::clear):
1761         (JSC::generateUnlinkedCodeBlock): Moved unlinked code block creation
1762         out of the CodeCache class and into a stand-alone function because
1763         we need it for local eval, which does not live in CodeCache.
1764
1765         * runtime/EvalExecutable.cpp:
1766         (JSC::EvalExecutable::create): Deleted.
1767         * runtime/EvalExecutable.h:
1768         (): Deleted.
1769         * runtime/GlobalEvalExecutable.cpp: Added.
1770         (JSC::GlobalEvalExecutable::create):
1771         (JSC::GlobalEvalExecutable::GlobalEvalExecutable):
1772         * runtime/GlobalEvalExecutable.h: Added.
1773         * runtime/LocalEvalExecutable.cpp: Added.
1774         (JSC::LocalEvalExecutable::create):
1775         (JSC::LocalEvalExecutable::LocalEvalExecutable):
1776         * runtime/LocalEvalExecutable.h: Added. Split out Local vs Global
1777         EvalExecutable classes to distinguish these operations in code. The key
1778         difference is that LocalEvalExecutable does not live in the CodeCache
1779         and only lives in the EvalCodeCache.
1780
1781         * runtime/JSGlobalObject.cpp:
1782         (JSC::JSGlobalObject::createProgramCodeBlock):
1783         (JSC::JSGlobalObject::createLocalEvalCodeBlock):
1784         (JSC::JSGlobalObject::createGlobalEvalCodeBlock):
1785         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
1786         (JSC::JSGlobalObject::createEvalCodeBlock): Deleted.
1787         * runtime/JSGlobalObject.h:
1788         * runtime/JSGlobalObjectFunctions.cpp:
1789         (JSC::globalFuncEval):
1790
1791         * runtime/JSScope.cpp:
1792         (JSC::JSScope::collectClosureVariablesUnderTDZ):
1793         (JSC::JSScope::collectVariablesUnderTDZ): Deleted. We don't include
1794         global lexical variables in our concept of TDZ scopes anymore. Global
1795         variable access always does TDZ checks unconditionally. So, only closure
1796         scope accesses give specific consideration to TDZ checks.
1797
1798         * runtime/JSScope.h:
1799
1800 2016-11-14  Caitlin Potter  <caitp@igalia.com>
1801
1802         [JSC] Handle new_async_func / new_async_func_exp in DFG / FTL
1803         https://bugs.webkit.org/show_bug.cgi?id=164037
1804
1805         Reviewed by Yusuke Suzuki.
1806
1807         This patch introduces new_async_func / new_async_func_exp into DFG and FTL,
1808         in much the same capacity that https://trac.webkit.org/changeset/194216 added
1809         DFG / FTL support for generators: by adding new DFG nodes (NewAsyncFunction and
1810         PhantomNewAsyncFunction), rather than extending the existing NewFunction node type.
1811
1812         Like NewFunction and PhantomNewFunction, and the Generator variants, allocation of
1813         async wrapper functions may be deferred or eliminated during the allocation sinking
1814         phase.
1815
1816         * dfg/DFGAbstractInterpreterInlines.h:
1817         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1818         * dfg/DFGByteCodeParser.cpp:
1819         (JSC::DFG::ByteCodeParser::parseBlock):
1820         * dfg/DFGCapabilities.cpp:
1821         (JSC::DFG::capabilityLevel):
1822         * dfg/DFGClobberize.h:
1823         (JSC::DFG::clobberize):
1824         * dfg/DFGClobbersExitState.cpp:
1825         (JSC::DFG::clobbersExitState):
1826         * dfg/DFGDoesGC.cpp:
1827         (JSC::DFG::doesGC):
1828         * dfg/DFGFixupPhase.cpp:
1829         (JSC::DFG::FixupPhase::fixupNode):
1830         * dfg/DFGMayExit.cpp:
1831         * dfg/DFGNode.h:
1832         (JSC::DFG::Node::convertToPhantomNewFunction):
1833         (JSC::DFG::Node::convertToPhantomNewAsyncFunction):
1834         (JSC::DFG::Node::hasCellOperand):
1835         (JSC::DFG::Node::isFunctionAllocation):
1836         (JSC::DFG::Node::isPhantomFunctionAllocation):
1837         (JSC::DFG::Node::isPhantomAllocation):
1838         * dfg/DFGNodeType.h:
1839         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1840         * dfg/DFGPredictionPropagationPhase.cpp:
1841         * dfg/DFGSafeToExecute.h:
1842         (JSC::DFG::safeToExecute):
1843         * dfg/DFGSpeculativeJIT.cpp:
1844         (JSC::DFG::SpeculativeJIT::compileNewFunction):
1845         * dfg/DFGSpeculativeJIT32_64.cpp:
1846         (JSC::DFG::SpeculativeJIT::compile):
1847         * dfg/DFGSpeculativeJIT64.cpp:
1848         (JSC::DFG::SpeculativeJIT::compile):
1849         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1850         * dfg/DFGStructureRegistrationPhase.cpp:
1851         (JSC::DFG::StructureRegistrationPhase::run):
1852         * dfg/DFGValidate.cpp:
1853         * ftl/FTLCapabilities.cpp:
1854         (JSC::FTL::canCompile):
1855         * ftl/FTLLowerDFGToB3.cpp:
1856         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1857         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1858         * ftl/FTLOperations.cpp:
1859         (JSC::FTL::operationPopulateObjectInOSR):
1860         (JSC::FTL::operationMaterializeObjectInOSR):
1861         * runtime/JSGlobalObject.cpp:
1862         (JSC::JSGlobalObject::init):
1863         (JSC::JSGlobalObject::visitChildren):
1864         * runtime/JSGlobalObject.h:
1865         (JSC::JSGlobalObject::asyncFunctionPrototype):
1866         (JSC::JSGlobalObject::asyncFunctionStructure):
1867         (JSC::JSGlobalObject::lazyAsyncFunctionStructure): Deleted.
1868         (JSC::JSGlobalObject::asyncFunctionPrototypeConcurrently): Deleted.
1869         (JSC::JSGlobalObject::asyncFunctionStructureConcurrently): Deleted.
1870
1871 2016-11-14  Mark Lam  <mark.lam@apple.com>
1872
1873         Some of JSStringView::SafeView methods are not idiomatically safe for JSString to StringView conversions.
1874         https://bugs.webkit.org/show_bug.cgi?id=164701
1875         <rdar://problem/27462104>
1876
1877         Reviewed by Darin Adler.
1878
1879         The characters8(), characters16(), and operator[] in JSString::SafeView converts
1880         the underlying JSString to a StringView via get(), and then uses the StringView
1881         without first checking if an exception was thrown during the conversion.  This is
1882         unsafe because the conversion may have failed.
1883         
1884         Instead, we should remove these 3 convenience methods, and make the caller
1885         explicitly call get() and do the appropriate exception checks before using the
1886         StringView.
1887
1888         * runtime/JSGlobalObjectFunctions.cpp:
1889         (JSC::toStringView):
1890         (JSC::encode):
1891         (JSC::decode):
1892         (JSC::globalFuncParseInt):
1893         (JSC::globalFuncEscape):
1894         (JSC::globalFuncUnescape):
1895         (JSC::toSafeView): Deleted.
1896         * runtime/JSONObject.cpp:
1897         (JSC::JSONProtoFuncParse):
1898         * runtime/JSString.h:
1899         (JSC::JSString::SafeView::length):
1900         (JSC::JSString::SafeView::characters8): Deleted.
1901         (JSC::JSString::SafeView::characters16): Deleted.
1902         (JSC::JSString::SafeView::operator[]): Deleted.
1903         * runtime/StringPrototype.cpp:
1904         (JSC::stringProtoFuncRepeatCharacter):
1905         (JSC::stringProtoFuncCharAt):
1906         (JSC::stringProtoFuncCharCodeAt):
1907         (JSC::stringProtoFuncNormalize):
1908
1909 2016-11-14  Mark Lam  <mark.lam@apple.com>
1910
1911         RegExpObject::exec/match should handle errors gracefully.
1912         https://bugs.webkit.org/show_bug.cgi?id=155145
1913         <rdar://problem/27435934>
1914
1915         Reviewed by Keith Miller.
1916
1917         1. Added some missing exception checks to RegExpObject::execInline() and
1918            RegExpObject::matchInline().
1919         2. Updated related code to work with ExceptionScope verification requirements.
1920
1921         * dfg/DFGOperations.cpp:
1922         * runtime/RegExpObjectInlines.h:
1923         (JSC::RegExpObject::execInline):
1924         (JSC::RegExpObject::matchInline):
1925         * runtime/RegExpPrototype.cpp:
1926         (JSC::regExpProtoFuncTestFast):
1927         (JSC::regExpProtoFuncExec):
1928         (JSC::regExpProtoFuncMatchFast):
1929
1930 2016-11-13  Mark Lam  <mark.lam@apple.com>
1931
1932         Add debugging facility to limit the max single allocation size.
1933         https://bugs.webkit.org/show_bug.cgi?id=164681
1934
1935         Reviewed by Keith Miller.
1936
1937         Added JSC option to set FastMalloc's maxSingleAllocationSize for testing purposes.
1938         This option is only available on Debug builds.
1939
1940         * runtime/Options.cpp:
1941         (JSC::Options::isAvailable):
1942         (JSC::recomputeDependentOptions):
1943         * runtime/Options.h:
1944
1945 2016-11-12  Joseph Pecoraro  <pecoraro@apple.com>
1946
1947         Follow-up fix to r208639.
1948
1949         Unreviewed fix. This is a straightfoward change where I forgot to
1950         switch from uncheckedArgument() to argument() in once case after
1951         dropping an argumentCount check. All other cases do this properly.
1952         This addresses an ASSERT seen on the bots running tests.
1953
1954         * runtime/JSDataViewPrototype.cpp:
1955         (JSC::setData):
1956
1957 2016-11-11  Joseph Pecoraro  <pecoraro@apple.com>
1958
1959         test262: DataView with explicit undefined byteLength should be the same as it not being present
1960         https://bugs.webkit.org/show_bug.cgi?id=164453
1961
1962         Reviewed by Darin Adler.
1963
1964         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1965         (JSC::constructGenericTypedArrayView):
1966         Handle the special case of DataView construction with an undefined byteLength value.
1967
1968 2016-11-11  Joseph Pecoraro  <pecoraro@apple.com>
1969
1970         test262: DataView get methods should allow for missing offset, set methods should allow for missing value
1971         https://bugs.webkit.org/show_bug.cgi?id=164451
1972
1973         Reviewed by Darin Adler.
1974
1975         * runtime/JSDataViewPrototype.cpp:
1976         (JSC::getData):
1977         Missing offset is still valid and will be coerced to 0.
1978
1979         (JSC::setData):
1980         Missing value is still valid and will be coerced to 0.
1981
1982 2016-11-11  Saam Barati  <sbarati@apple.com>
1983
1984         We should have a more concise way of determining when we're varargs calling a function using rest parameters
1985         https://bugs.webkit.org/show_bug.cgi?id=164258
1986
1987         Reviewed by Yusuke Suzuki.
1988
1989         This patch adds two new bytecodes and DFG nodes for the following code patterns:
1990
1991         ```
1992         foo(a, b, ...c)
1993         let x = [a, b, ...c];
1994         ```
1995
1996         To do this, I've introduced two new bytecode operations (and their
1997         corresponding DFG nodes):
1998
1999         op_spread and op_new_array_with_spread.
2000
2001         op_spread takes a single input and performs the ES6 iteration protocol on it.
2002         It returns the result of doing the spread inside a new class I've
2003         made called JSFixedArray. JSFixedArray is a cell with a single 'size'
2004         field and a buffer of values allocated inline in the cell. Abstracting
2005         the protocol into a single node is good because it will make IR analysis
2006         in the future much simpler. For now, it's also good because it allows
2007         us to create fast paths for array iteration (which is quite common).
2008         This fast path allows us to emit really good code for array iteration
2009         inside the DFG/FTL.
2010
2011         op_new_array_with_spread is a variable argument bytecode that also
2012         has a bit vector associated with it. The bit vector indicates if
2013         any particular argument is to be spread or not. Arguments that
2014         are spread are known to be JSFixedArray because we must emit an
2015         op_spread before op_new_array_with_spread consumes the value.
2016         For example, for this array:
2017         [a, b, ...c, d, ...e]
2018         we will have this bit vector:
2019         [0, 0, 1, 0, 1]
2020
2021         The reason I've chosen this IR is that it will make eliminating
2022         a rest allocation for this type of code much easier:
2023
2024         ```
2025         function foo(...args) {
2026             return bar(a, b, ...args);
2027         }
2028         ```
2029
2030         It will be easier to analyze the IR now that the operations
2031         will be described at a high level.
2032
2033         This patch is an ~8% speedup on ES6SampleBench on my MBP.
2034
2035         * CMakeLists.txt:
2036         * DerivedSources.make:
2037         * JavaScriptCore.xcodeproj/project.pbxproj:
2038         * builtins/IteratorHelpers.js: Added.
2039         (performIteration):
2040         * bytecode/BytecodeList.json:
2041         * bytecode/BytecodeUseDef.h:
2042         (JSC::computeUsesForBytecodeOffset):
2043         (JSC::computeDefsForBytecodeOffset):
2044         * bytecode/CodeBlock.cpp:
2045         (JSC::CodeBlock::dumpBytecode):
2046         * bytecode/ObjectPropertyConditionSet.cpp:
2047         (JSC::generateConditionForSelfEquivalence):
2048         * bytecode/ObjectPropertyConditionSet.h:
2049         * bytecode/TrackedReferences.cpp:
2050         (JSC::TrackedReferences::check):
2051         * bytecode/UnlinkedCodeBlock.h:
2052         (JSC::UnlinkedCodeBlock::bitVectors):
2053         (JSC::UnlinkedCodeBlock::bitVector):
2054         (JSC::UnlinkedCodeBlock::addBitVector):
2055         (JSC::UnlinkedCodeBlock::shrinkToFit):
2056         * bytecompiler/BytecodeGenerator.cpp:
2057         (JSC::BytecodeGenerator::emitNewArrayWithSpread):
2058         * bytecompiler/BytecodeGenerator.h:
2059         * bytecompiler/NodesCodegen.cpp:
2060         (JSC::ArrayNode::emitBytecode):
2061         * dfg/DFGAbstractInterpreterInlines.h:
2062         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2063         * dfg/DFGByteCodeParser.cpp:
2064         (JSC::DFG::ByteCodeParser::addToGraph):
2065         (JSC::DFG::ByteCodeParser::parseBlock):
2066         * dfg/DFGCapabilities.cpp:
2067         (JSC::DFG::capabilityLevel):
2068         * dfg/DFGClobberize.h:
2069         (JSC::DFG::clobberize):
2070         * dfg/DFGDoesGC.cpp:
2071         (JSC::DFG::doesGC):
2072         * dfg/DFGFixupPhase.cpp:
2073         (JSC::DFG::FixupPhase::fixupNode):
2074         (JSC::DFG::FixupPhase::watchHavingABadTime):
2075         * dfg/DFGGraph.h:
2076         (JSC::DFG::Graph::isWatchingArrayIteratorProtocolWatchpoint):
2077         * dfg/DFGNode.h:
2078         (JSC::DFG::Node::bitVector):
2079         * dfg/DFGNodeType.h:
2080         * dfg/DFGOperations.cpp:
2081         * dfg/DFGOperations.h:
2082         * dfg/DFGPredictionPropagationPhase.cpp:
2083         * dfg/DFGSafeToExecute.h:
2084         (JSC::DFG::safeToExecute):
2085         * dfg/DFGSpeculativeJIT.cpp:
2086         (JSC::DFG::SpeculativeJIT::compileSpread):
2087         (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
2088         * dfg/DFGSpeculativeJIT.h:
2089         (JSC::DFG::SpeculativeJIT::callOperation):
2090         * dfg/DFGSpeculativeJIT32_64.cpp:
2091         (JSC::DFG::SpeculativeJIT::compile):
2092         * dfg/DFGSpeculativeJIT64.cpp:
2093         (JSC::DFG::SpeculativeJIT::compile):
2094         * dfg/DFGStructureRegistrationPhase.cpp:
2095         (JSC::DFG::StructureRegistrationPhase::run):
2096         * ftl/FTLAbstractHeapRepository.h:
2097         * ftl/FTLCapabilities.cpp:
2098         (JSC::FTL::canCompile):
2099         * ftl/FTLLowerDFGToB3.cpp:
2100         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2101         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
2102         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
2103         (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
2104         * jit/AssemblyHelpers.h:
2105         (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
2106         (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
2107         * jit/JIT.cpp:
2108         (JSC::JIT::privateCompileMainPass):
2109         * jit/JIT.h:
2110         * jit/JITOpcodes.cpp:
2111         (JSC::JIT::emit_op_new_array_with_spread):
2112         (JSC::JIT::emit_op_spread):
2113         * jit/JITOperations.h:
2114         * llint/LLIntData.cpp:
2115         (JSC::LLInt::Data::performAssertions):
2116         * llint/LLIntSlowPaths.cpp:
2117         * llint/LowLevelInterpreter.asm:
2118         * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Added.
2119         (JSC::ArrayIteratorAdaptiveWatchpoint::ArrayIteratorAdaptiveWatchpoint):
2120         (JSC::ArrayIteratorAdaptiveWatchpoint::handleFire):
2121         * runtime/ArrayIteratorAdaptiveWatchpoint.h: Added.
2122         * runtime/CommonSlowPaths.cpp:
2123         (JSC::SLOW_PATH_DECL):
2124         * runtime/CommonSlowPaths.h:
2125         * runtime/IteratorOperations.h:
2126         (JSC::forEachInIterable):
2127         * runtime/JSCInlines.h:
2128         * runtime/JSFixedArray.cpp: Added.
2129         (JSC::JSFixedArray::visitChildren):
2130         * runtime/JSFixedArray.h: Added.
2131         (JSC::JSFixedArray::createStructure):
2132         (JSC::JSFixedArray::createFromArray):
2133         (JSC::JSFixedArray::get):
2134         (JSC::JSFixedArray::buffer):
2135         (JSC::JSFixedArray::size):
2136         (JSC::JSFixedArray::offsetOfSize):
2137         (JSC::JSFixedArray::offsetOfData):
2138         (JSC::JSFixedArray::create):
2139         (JSC::JSFixedArray::JSFixedArray):
2140         (JSC::JSFixedArray::allocationSize):
2141         * runtime/JSGlobalObject.cpp:
2142         (JSC::JSGlobalObject::JSGlobalObject):
2143         (JSC::JSGlobalObject::init):
2144         (JSC::JSGlobalObject::visitChildren):
2145         (JSC::JSGlobalObject::objectPrototypeIsSane): Deleted.
2146         (JSC::JSGlobalObject::arrayPrototypeChainIsSane): Deleted.
2147         (JSC::JSGlobalObject::stringPrototypeChainIsSane): Deleted.
2148         * runtime/JSGlobalObject.h:
2149         (JSC::JSGlobalObject::arrayIteratorProtocolWatchpoint):
2150         (JSC::JSGlobalObject::iteratorProtocolFunction):
2151         * runtime/JSGlobalObjectInlines.h: Added.
2152         (JSC::JSGlobalObject::objectPrototypeIsSane):
2153         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
2154         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
2155         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable):
2156         * runtime/JSType.h:
2157         * runtime/VM.cpp:
2158         (JSC::VM::VM):
2159         * runtime/VM.h:
2160
2161 2016-11-11  Keith Miller  <keith_miller@apple.com>
2162
2163         Move Wasm tests to JS
2164         https://bugs.webkit.org/show_bug.cgi?id=164611
2165
2166         Reviewed by Geoffrey Garen.
2167
2168         This patch translates most of the tests from testWasm.cpp to the JS testing api. Most of the
2169         ommited tests were earliest tests, which tested trivial things, like adding two
2170         constants. Some tests are ommited for other reasons, however. These are:
2171
2172         1) Tests using I64 since the testing api does not yet know how to handle 64-bit numbers.  2)
2173         Tests that would validate the memory of the module once wasm was done with it since that's
2174         not really possible in JS.
2175
2176         In order to make such a translation easier this patch also adds some features to the JS
2177         testing api:
2178
2179         1) Blocks can now be done lexically by adding a lambda as the last argument of the block
2180         opcode. For example one can do:
2181             ...
2182             .Block("i32", b => b.I32Const(1) )
2183
2184         and the nested lambda will automatically have an end attached.
2185
2186         2) The JS testing api can now handle inline signature types.
2187
2188         3) Relocate some code to make it easier to follow and prevent 44 space indentation.
2189
2190         4) Rename varuint/varint to varuint32/varint32, this lets them be directly called from the
2191         wasm.json without being remapped.
2192
2193         5) Add support for Memory and Function sections to the Builder.
2194
2195         6) Add support for local variables.
2196
2197         On the JSC side, we needed to expose a new function to validate the compiled wasm code
2198         behaves the way we expect. At least until the JS Wasm API is finished. The new validation
2199         function, testWasmModuleFunctions, takes an array buffer containing the wasm binary, the
2200         number of functions in the blob and tests for each of those functions.
2201
2202         * jsc.cpp:
2203         (GlobalObject::finishCreation):
2204         (box):
2205         (callWasmFunction):
2206         (functionTestWasmModuleFunctions):
2207         * testWasm.cpp:
2208         (checkPlan):
2209         (runWasmTests):
2210         * wasm/WasmB3IRGenerator.cpp:
2211         (JSC::Wasm::parseAndCompile):
2212         * wasm/WasmFunctionParser.h:
2213         (JSC::Wasm::FunctionParser<Context>::parse):
2214         (JSC::Wasm::FunctionParser<Context>::parseBody):
2215         (JSC::Wasm::FunctionParser<Context>::parseBlock): Deleted.
2216         * wasm/WasmModuleParser.cpp:
2217         (JSC::Wasm::ModuleParser::parseMemory):
2218         (JSC::Wasm::ModuleParser::parseExport):
2219         * wasm/WasmPlan.cpp:
2220         (JSC::Wasm::Plan::Plan):
2221         (JSC::Wasm::Plan::run):
2222         * wasm/WasmPlan.h:
2223         * wasm/js/WebAssemblyModuleConstructor.cpp:
2224         (JSC::constructJSWebAssemblyModule):
2225
2226 2016-11-11  Saam Barati  <sbarati@apple.com>
2227
2228         Unreviewed try to fix windows build after https://bugs.webkit.org/show_bug.cgi?id=164650
2229
2230         * dfg/DFGByteCodeParser.cpp:
2231         (JSC::DFG::ByteCodeParser::parseBlock):
2232
2233 2016-11-11  Saam Barati  <sbarati@apple.com>
2234
2235         We recursively grab a lock in the DFGBytecodeParser causing us to deadlock
2236         https://bugs.webkit.org/show_bug.cgi?id=164650
2237
2238         Reviewed by Geoffrey Garen.
2239
2240         Some code was incorrectly holding a lock when recursively calling
2241         back into the bytecode parser's via inlining a put_by_val as a put_by_id.
2242         This can cause a deadlock if the inlinee CodeBlock is something we're
2243         already holding a lock for. I've changed the range of the lock holder
2244         to be as narrow as possible.
2245
2246         * dfg/DFGByteCodeParser.cpp:
2247         (JSC::DFG::ByteCodeParser::parseBlock):
2248
2249 2016-11-11  Chris Dumez  <cdumez@apple.com>
2250
2251         Unreviewed, rolling out r208584.
2252
2253         Seems to have regressed Speedometer by 1% on Mac
2254
2255         Reverted changeset:
2256
2257         "We should have a more concise way of determining when we're
2258         varargs calling a function using rest parameters"
2259         https://bugs.webkit.org/show_bug.cgi?id=164258
2260         http://trac.webkit.org/changeset/208584
2261
2262 2016-11-11  Chris Dumez  <cdumez@apple.com>
2263
2264         Unreviewed, rolling out r208117 and r208160.
2265
2266         Regressed Speedometer by >1.5%
2267
2268         Reverted changesets:
2269
2270         "We should have a way of profiling when a get_by_id is pure
2271         and to emit a PureGetById in the DFG/FTL"
2272         https://bugs.webkit.org/show_bug.cgi?id=163305
2273         http://trac.webkit.org/changeset/208117
2274
2275         "Debug JSC test microbenchmarks/pure-get-by-id-cse-2.js timing
2276         out"
2277         https://bugs.webkit.org/show_bug.cgi?id=164227
2278         http://trac.webkit.org/changeset/208160
2279
2280 2016-11-11  Saam Barati  <sbarati@apple.com>
2281
2282         We should have a more concise way of determining when we're varargs calling a function using rest parameters
2283         https://bugs.webkit.org/show_bug.cgi?id=164258
2284
2285         Reviewed by Yusuke Suzuki.
2286
2287         This patch adds two new bytecodes and DFG nodes for the following code patterns:
2288
2289         ```
2290         foo(a, b, ...c)
2291         let x = [a, b, ...c];
2292         ```
2293
2294         To do this, I've introduced two new bytecode operations (and their
2295         corresponding DFG nodes):
2296
2297         op_spread and op_new_array_with_spread.
2298
2299         op_spread takes a single input and performs the ES6 iteration protocol on it.
2300         It returns the result of doing the spread inside a new class I've
2301         made called JSFixedArray. JSFixedArray is a cell with a single 'size'
2302         field and a buffer of values allocated inline in the cell. Abstracting
2303         the protocol into a single node is good because it will make IR analysis
2304         in the future much simpler. For now, it's also good because it allows
2305         us to create fast paths for array iteration (which is quite common).
2306         This fast path allows us to emit really good code for array iteration
2307         inside the DFG/FTL.
2308
2309         op_new_array_with_spread is a variable argument bytecode that also
2310         has a bit vector associated with it. The bit vector indicates if
2311         any particular argument is to be spread or not. Arguments that
2312         are spread are known to be JSFixedArray because we must emit an
2313         op_spread before op_new_array_with_spread consumes the value.
2314         For example, for this array:
2315         [a, b, ...c, d, ...e]
2316         we will have this bit vector:
2317         [0, 0, 1, 0, 1]
2318
2319         The reason I've chosen this IR is that it will make eliminating
2320         a rest allocation for this type of code much easier:
2321
2322         ```
2323         function foo(...args) {
2324             return bar(a, b, ...args);
2325         }
2326         ```
2327
2328         It will be easier to analyze the IR now that the operations
2329         will be described at a high level.
2330
2331         This patch is an ~8% speedup on ES6SampleBench on my MBP.
2332
2333         * CMakeLists.txt:
2334         * DerivedSources.make:
2335         * JavaScriptCore.xcodeproj/project.pbxproj:
2336         * builtins/IteratorHelpers.js: Added.
2337         (performIteration):
2338         * bytecode/BytecodeList.json:
2339         * bytecode/BytecodeUseDef.h:
2340         (JSC::computeUsesForBytecodeOffset):
2341         (JSC::computeDefsForBytecodeOffset):
2342         * bytecode/CodeBlock.cpp:
2343         (JSC::CodeBlock::dumpBytecode):
2344         * bytecode/ObjectPropertyConditionSet.cpp:
2345         (JSC::generateConditionForSelfEquivalence):
2346         * bytecode/ObjectPropertyConditionSet.h:
2347         * bytecode/TrackedReferences.cpp:
2348         (JSC::TrackedReferences::check):
2349         * bytecode/UnlinkedCodeBlock.h:
2350         (JSC::UnlinkedCodeBlock::bitVectors):
2351         (JSC::UnlinkedCodeBlock::bitVector):
2352         (JSC::UnlinkedCodeBlock::addBitVector):
2353         (JSC::UnlinkedCodeBlock::shrinkToFit):
2354         * bytecompiler/BytecodeGenerator.cpp:
2355         (JSC::BytecodeGenerator::emitNewArrayWithSpread):
2356         * bytecompiler/BytecodeGenerator.h:
2357         * bytecompiler/NodesCodegen.cpp:
2358         (JSC::ArrayNode::emitBytecode):
2359         * dfg/DFGAbstractInterpreterInlines.h:
2360         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2361         * dfg/DFGByteCodeParser.cpp:
2362         (JSC::DFG::ByteCodeParser::addToGraph):
2363         (JSC::DFG::ByteCodeParser::parseBlock):
2364         * dfg/DFGCapabilities.cpp:
2365         (JSC::DFG::capabilityLevel):
2366         * dfg/DFGClobberize.h:
2367         (JSC::DFG::clobberize):
2368         * dfg/DFGDoesGC.cpp:
2369         (JSC::DFG::doesGC):
2370         * dfg/DFGFixupPhase.cpp:
2371         (JSC::DFG::FixupPhase::fixupNode):
2372         (JSC::DFG::FixupPhase::watchHavingABadTime):
2373         * dfg/DFGGraph.h:
2374         (JSC::DFG::Graph::isWatchingArrayIteratorProtocolWatchpoint):
2375         * dfg/DFGNode.h:
2376         (JSC::DFG::Node::bitVector):
2377         * dfg/DFGNodeType.h:
2378         * dfg/DFGOperations.cpp:
2379         * dfg/DFGOperations.h:
2380         * dfg/DFGPredictionPropagationPhase.cpp:
2381         * dfg/DFGSafeToExecute.h:
2382         (JSC::DFG::safeToExecute):
2383         * dfg/DFGSpeculativeJIT.cpp:
2384         (JSC::DFG::SpeculativeJIT::compileSpread):
2385         (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
2386         * dfg/DFGSpeculativeJIT.h:
2387         (JSC::DFG::SpeculativeJIT::callOperation):
2388         * dfg/DFGSpeculativeJIT32_64.cpp:
2389         (JSC::DFG::SpeculativeJIT::compile):
2390         * dfg/DFGSpeculativeJIT64.cpp:
2391         (JSC::DFG::SpeculativeJIT::compile):
2392         * dfg/DFGStructureRegistrationPhase.cpp:
2393         (JSC::DFG::StructureRegistrationPhase::run):
2394         * ftl/FTLAbstractHeapRepository.h:
2395         * ftl/FTLCapabilities.cpp:
2396         (JSC::FTL::canCompile):
2397         * ftl/FTLLowerDFGToB3.cpp:
2398         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2399         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
2400         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
2401         (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
2402         * jit/AssemblyHelpers.h:
2403         (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
2404         (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
2405         * jit/JIT.cpp:
2406         (JSC::JIT::privateCompileMainPass):
2407         * jit/JIT.h:
2408         * jit/JITOpcodes.cpp:
2409         (JSC::JIT::emit_op_new_array_with_spread):
2410         (JSC::JIT::emit_op_spread):
2411         * jit/JITOperations.h:
2412         * llint/LLIntData.cpp:
2413         (JSC::LLInt::Data::performAssertions):
2414         * llint/LLIntSlowPaths.cpp:
2415         * llint/LowLevelInterpreter.asm:
2416         * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Added.
2417         (JSC::ArrayIteratorAdaptiveWatchpoint::ArrayIteratorAdaptiveWatchpoint):
2418         (JSC::ArrayIteratorAdaptiveWatchpoint::handleFire):
2419         * runtime/ArrayIteratorAdaptiveWatchpoint.h: Added.
2420         * runtime/CommonSlowPaths.cpp:
2421         (JSC::SLOW_PATH_DECL):
2422         * runtime/CommonSlowPaths.h:
2423         * runtime/IteratorOperations.h:
2424         (JSC::forEachInIterable):
2425         * runtime/JSCInlines.h:
2426         * runtime/JSFixedArray.cpp: Added.
2427         (JSC::JSFixedArray::visitChildren):
2428         * runtime/JSFixedArray.h: Added.
2429         (JSC::JSFixedArray::createStructure):
2430         (JSC::JSFixedArray::createFromArray):
2431         (JSC::JSFixedArray::get):
2432         (JSC::JSFixedArray::buffer):
2433         (JSC::JSFixedArray::size):
2434         (JSC::JSFixedArray::offsetOfSize):
2435         (JSC::JSFixedArray::offsetOfData):
2436         (JSC::JSFixedArray::create):
2437         (JSC::JSFixedArray::JSFixedArray):
2438         (JSC::JSFixedArray::allocationSize):
2439         * runtime/JSGlobalObject.cpp:
2440         (JSC::JSGlobalObject::JSGlobalObject):
2441         (JSC::JSGlobalObject::init):
2442         (JSC::JSGlobalObject::visitChildren):
2443         (JSC::JSGlobalObject::objectPrototypeIsSane): Deleted.
2444         (JSC::JSGlobalObject::arrayPrototypeChainIsSane): Deleted.
2445         (JSC::JSGlobalObject::stringPrototypeChainIsSane): Deleted.
2446         * runtime/JSGlobalObject.h:
2447         (JSC::JSGlobalObject::arrayIteratorProtocolWatchpoint):
2448         (JSC::JSGlobalObject::iteratorProtocolFunction):
2449         * runtime/JSGlobalObjectInlines.h: Added.
2450         (JSC::JSGlobalObject::objectPrototypeIsSane):
2451         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
2452         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
2453         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable):
2454         * runtime/JSType.h:
2455         * runtime/VM.cpp:
2456         (JSC::VM::VM):
2457         * runtime/VM.h:
2458
2459 2016-11-10  JF Bastien  <jfbastien@apple.com>
2460
2461         ASSERTION FAILED: length > offset encountered with wasm.yaml/wasm/js-api/test_Module.js.default-wasm
2462         https://bugs.webkit.org/show_bug.cgi?id=164597
2463
2464         Reviewed by Keith Miller.
2465
2466         * wasm/WasmParser.h:
2467         (JSC::Wasm::Parser::parseVarUInt32): move closer to other parsers
2468         (JSC::Wasm::Parser::parseVarUInt64): move closer to other parsers
2469
2470 2016-11-10  Joseph Pecoraro  <pecoraro@apple.com>
2471
2472         test262: DataView / TypedArray methods should throw RangeErrors for negative numbers (ToIndex)
2473         https://bugs.webkit.org/show_bug.cgi?id=164450
2474
2475         Reviewed by Darin Adler.
2476
2477         * runtime/JSCJSValue.h:
2478         * runtime/JSCJSValueInlines.h:
2479         (JSC::JSValue::toIndex):
2480         Introduce a method for toIndex, which is used by DataView and TypedArrays
2481         to convert an argument to a number with the possibility of throwing
2482         RangeErrors for negative values. We also throw RangeErrors for large
2483         values, because wherever this is used we expect an unsigned.
2484
2485         * runtime/JSArrayBufferConstructor.cpp:
2486         (JSC::constructArrayBuffer):
2487         * runtime/JSDataViewPrototype.cpp:
2488         (JSC::getData):
2489         (JSC::setData):
2490         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2491         (JSC::constructGenericTypedArrayViewWithArguments):
2492         (JSC::constructGenericTypedArrayView):
2493         Use toIndex instead of toUint32 where required.
2494
2495 2016-11-10  Mark Lam  <mark.lam@apple.com>
2496
2497         A few bits of minor code clean up.
2498         https://bugs.webkit.org/show_bug.cgi?id=164523
2499
2500         Reviewed by Yusuke Suzuki.
2501
2502         * interpreter/StackVisitor.cpp:
2503         (JSC::StackVisitor::Frame::dump):
2504         - Insert a space to make the dump more legible.
2505
2506         * runtime/Options.h:
2507         - Fixed some typos.
2508
2509         * runtime/StringPrototype.cpp:
2510         (JSC::stringProtoFuncReplaceUsingRegExp):
2511         (JSC::stringProtoFuncReplaceUsingStringSearch):
2512         - Use the VM& that is already available.
2513
2514 2016-11-10  Mark Lam  <mark.lam@apple.com>
2515
2516         Graph::methodOfGettingAValueProfileFor() should be returning the profile for the operand node.
2517         https://bugs.webkit.org/show_bug.cgi?id=164600
2518         <rdar://problem/28828676>
2519
2520         Reviewed by Filip Pizlo.
2521
2522         Currently, Graph::methodOfGettingAValueProfileFor() assumes that the operand DFG
2523         node that it is provided with always has a different origin than the node that is
2524         using that operand.  For example, in a DFG graph that looks like this:
2525
2526             a: ...
2527             b: ArithAdd(@a, ...)
2528
2529         ... when emitting speculation checks on @a for the ArithAdd node at @b,
2530         Graph::methodOfGettingAValueProfileFor() is passed @a, and expects @a's to
2531         originate from a different bytecode than @b.  The intent here is to get the
2532         profile for @a so that the OSR exit ramp for @b can update @a's profile with the
2533         observed result type from @a so that future type prediction on incoming args for
2534         the ArithAdd node can take this into consideration.
2535
2536         However, op_negate can be compiled into the following series of nodes:
2537
2538             a: ...
2539             b: BooleanToNumber(@a)
2540             c: DoubleRep(@b)
2541             d: ArithNegate(@c)
2542
2543         All 3 nodes @b, @c, and @d maps to the same op_negate bytecode i.e. they have the
2544         same origin.  When the speculativeJIT emits a speculationCheck for DoubleRep, it
2545         calls Graph::methodOfGettingAValueProfileFor() to get the ArithProfile for the
2546         BooleanToNumber node.  But because all 3 nodes have the same origin,
2547         Graph::methodOfGettingAValueProfileFor() erroneously returns the ArithProfile for
2548         the op_negate.  Subsequently, the OSR exit ramp will modify the ArithProfile of
2549         the op_negate and corrupt its profile.  Instead, what the OSR exit ramp should be
2550         doing is update the ArithProfile of op_negate's operand i.e. BooleanToNumber's
2551         operand @a in this case.
2552
2553         The fix is to always pass the current node we're generating code for (in addition
2554         to the operand node) to Graph::methodOfGettingAValueProfileFor().  This way, we
2555         know the profile is valid if and only if the current node and its operand node
2556         does not have the same origin.
2557
2558         In this patch, we also fixed the following:
2559         1. Teach Graph::methodOfGettingAValueProfileFor() to get the profile for
2560            BooleanToNumber's operand if the operand node it is given is BooleanToNumber.
2561         2. Change JITCompiler::appendExceptionHandlingOSRExit() to explicitly pass an
2562            empty MethodOfGettingAValueProfile().  It was implicitly doing this before.
2563         3. Change SpeculativeJIT::emitInvalidationPoint() to pass an empty
2564            MethodOfGettingAValueProfile().  It has no child node.  Hence, it doesn't
2565            make sense to call Graph::methodOfGettingAValueProfileFor() for a child node
2566            that does not exist.
2567
2568         * dfg/DFGGraph.cpp:
2569         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2570         * dfg/DFGGraph.h:
2571         * dfg/DFGJITCompiler.cpp:
2572         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
2573         * dfg/DFGSpeculativeJIT.cpp:
2574         (JSC::DFG::SpeculativeJIT::speculationCheck):
2575         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
2576         * ftl/FTLLowerDFGToB3.cpp:
2577         (JSC::FTL::DFG::LowerDFGToB3::appendOSRExitDescriptor):
2578
2579 2016-11-10  Aaron Chu  <aaron_chu@apple.com>
2580
2581         Web Inspector: AXI: clarify button roles (e.g. toggle or popup button)
2582         https://bugs.webkit.org/show_bug.cgi?id=130726
2583         <rdar://problem/16420420>
2584
2585         Reviewed by Brian Burg.
2586
2587         Add the isPopupButton flag to the AccessibilityProperties type.
2588
2589         * inspector/protocol/DOM.json:
2590
2591 2016-11-10  Csaba Osztrogon√°c  <ossy@webkit.org>
2592
2593         [ARM] Unreviewed buildfix after r208450.
2594
2595         * assembler/MacroAssemblerARM.h:
2596         (JSC::MacroAssemblerARM::load8SignedExtendTo32): Added.
2597
2598 2016-11-08  Yusuke Suzuki  <utatane.tea@gmail.com>
2599
2600         [JSC] Avoid cloned arguments allocation in ArrayPrototype methods
2601         https://bugs.webkit.org/show_bug.cgi?id=164502
2602
2603         Reviewed by Saam Barati.
2604
2605         In many builtin functions, we use `arguments` to just get optional parameters.
2606         While FTL argument elimination can drop `arguments` allocations, it leaves
2607         the allocations in LLInt, Baseline, and DFG. And we found that DFG compiled
2608         Array#map is heavily used in ES6SampleBench/Basic. And it always creates
2609         a meaningless ClonedArguments.
2610
2611         Using ES6 default parameter here is not a solution. It increases the number
2612         of parameters of the CodeBlock (not `function.length`). And the optional
2613         parameters in Array.prototype.xxx methods are not typically passed. For
2614         example, we typically do not pass `thisArg` to `Array.prototype.map` function.
2615         In this case, the arity check frequently fails. It requires the additional C
2616         call to fixup arguments and it becomes pure overhead.
2617
2618         To solve this problem, this patch introduces a new bytecode intrinsic @argument().
2619         This offers the way to retrieve the argument value without increasing the
2620         arity of the function. And if the argument is not passed (out of bounds), it
2621         just returns `undefined`. The semantics of this intrinsic is the same to the C++
2622         ExecState::argument(). This operation does not require `arguments` object. And we
2623         can drop the `argument` references even in lower 3 tiers.
2624
2625         We implement op_get_argument for this intrinsic. And later this will be converted
2626         to DFG GetArgument node. All the tiers handles this feature.
2627
2628         This patch improves ES6SampleBench/Basic 13.8% in steady state. And in summary,
2629         it improves 4.5%.
2630
2631         In the future, we can improve the implementation of the default parameters.
2632         Currently, the default parameter always increases the arity of the function. So
2633         if you do not pass the argument, the arity check fails. But since it is the default
2634         parameter, it is likely that we don't pass the argument. Using op_get_argument to
2635         implement the default parameter can decrease the case in which the arity check
2636         frequently fails. And it can change the builtin implementation to use the ES6
2637         default parameters instead of using the special @argument() intrinsic in the future.
2638         And at that case, the user code also receives the benefit.
2639
2640         ES6SampleBench/Basic.
2641             Baseline:
2642                 Running... Basic ( 1  to go)
2643                 firstIteration:     39.38 ms +- 4.48 ms
2644                 averageWorstCase:   20.79 ms +- 0.96 ms
2645                 steadyState:        1959.22 ms +- 65.55 ms
2646
2647             Patched:
2648                 Running... Basic ( 1  to go)
2649                 firstIteration:     37.85 ms +- 4.09 ms
2650                 averageWorstCase:   18.60 ms +- 0.76 ms
2651                 steadyState:        1721.89 ms +- 57.58 ms
2652
2653         All summary.
2654             Baseline:
2655                 summary:            164.34 ms +- 5.01 ms
2656             Patched:
2657                 summary:            157.26 ms +- 5.96 ms
2658
2659         * builtins/ArrayConstructor.js:
2660         * builtins/ArrayPrototype.js:
2661         (reduce):
2662         (reduceRight):
2663         (every):
2664         (forEach):
2665         (filter):
2666         (map):
2667         (some):
2668         (fill):
2669         (find):
2670         (findIndex):
2671         (includes):
2672         (copyWithin):
2673         * builtins/DatePrototype.js:
2674         (toLocaleString):
2675         (toLocaleDateString):
2676         (toLocaleTimeString):
2677         * builtins/MapPrototype.js:
2678         (forEach):
2679         * builtins/NumberPrototype.js:
2680         (toLocaleString):
2681         * builtins/SetPrototype.js:
2682         (forEach):
2683         * builtins/StringPrototype.js:
2684         (padStart):
2685         (padEnd):
2686         (localeCompare):
2687         * builtins/TypedArrayConstructor.js:
2688         * builtins/TypedArrayPrototype.js:
2689         (every):
2690         (fill):
2691         (find):
2692         (findIndex):
2693         (forEach):
2694         (some):
2695         (reduce):
2696         (reduceRight):
2697         (map):
2698         (filter):
2699         * bytecode/BytecodeIntrinsicRegistry.h:
2700         * bytecode/BytecodeList.json:
2701         * bytecode/BytecodeUseDef.h:
2702         (JSC::computeUsesForBytecodeOffset):
2703         (JSC::computeDefsForBytecodeOffset):
2704         * bytecode/CodeBlock.cpp:
2705         (JSC::CodeBlock::dumpBytecode):
2706         (JSC::CodeBlock::finishCreation):
2707         * bytecompiler/BytecodeGenerator.cpp:
2708         (JSC::BytecodeGenerator::emitGetArgument):
2709         * bytecompiler/BytecodeGenerator.h:
2710         * bytecompiler/NodesCodegen.cpp:
2711         (JSC::BytecodeIntrinsicNode::emit_intrinsic_argument):
2712         * dfg/DFGAbstractInterpreterInlines.h:
2713         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2714         * dfg/DFGByteCodeParser.cpp:
2715         (JSC::DFG::ByteCodeParser::parseBlock):
2716         * dfg/DFGCapabilities.cpp:
2717         (JSC::DFG::capabilityLevel):
2718         * dfg/DFGClobberize.h:
2719         (JSC::DFG::clobberize):
2720         * dfg/DFGDoesGC.cpp:
2721         (JSC::DFG::doesGC):
2722         * dfg/DFGFixupPhase.cpp:
2723         (JSC::DFG::FixupPhase::fixupNode):
2724         * dfg/DFGNode.h:
2725         (JSC::DFG::Node::hasHeapPrediction):
2726         (JSC::DFG::Node::hasArgumentIndex):
2727         (JSC::DFG::Node::argumentIndex):
2728         * dfg/DFGNodeType.h:
2729         * dfg/DFGPreciseLocalClobberize.h:
2730         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2731         * dfg/DFGPredictionPropagationPhase.cpp:
2732         * dfg/DFGSafeToExecute.h:
2733         (JSC::DFG::safeToExecute):
2734         * dfg/DFGSpeculativeJIT.cpp:
2735         (JSC::DFG::SpeculativeJIT::compileGetArgument):
2736         * dfg/DFGSpeculativeJIT.h:
2737         * dfg/DFGSpeculativeJIT32_64.cpp:
2738         (JSC::DFG::SpeculativeJIT::compile):
2739         * dfg/DFGSpeculativeJIT64.cpp:
2740         (JSC::DFG::SpeculativeJIT::compile):
2741         * ftl/FTLCapabilities.cpp:
2742         (JSC::FTL::canCompile):
2743         * ftl/FTLLowerDFGToB3.cpp:
2744         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2745         (JSC::FTL::DFG::LowerDFGToB3::compileGetArgument):
2746         * jit/JIT.cpp:
2747         (JSC::JIT::privateCompileMainPass):
2748         * jit/JIT.h:
2749         * jit/JITOpcodes.cpp:
2750         (JSC::JIT::emit_op_get_argument):
2751         * jit/JITOpcodes32_64.cpp:
2752         (JSC::JIT::emit_op_get_argument):
2753         * llint/LowLevelInterpreter32_64.asm:
2754         * llint/LowLevelInterpreter64.asm:
2755
2756 2016-11-08  Joseph Pecoraro  <pecoraro@apple.com>
2757
2758         Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
2759         https://bugs.webkit.org/show_bug.cgi?id=161951
2760         <rdar://problem/28295767>
2761
2762         Reviewed by Brian Burg.
2763
2764         This removes an ambiguity in the protocol when stepping through
2765         JavaScript. Previously, when paused and issuing a Debugger.step*
2766         command the frontend would always receive a Debugger.resumed event and
2767         then, maybe, a Debugger.paused event indicating we paused again (after
2768         stepping). However, this ambiguity means that the frontend needs to
2769         wait for a short period of time to determine if we really resumed
2770         or not. And even still that decision may be incorrect if the step
2771         takes a sufficiently long period of time.
2772
2773         The new approach removes this ambiguity. Now, in response to a
2774         Debugger.step* command the backend MUST send a single Debugger.paused
2775         event or Debugger.resumed event. Now the frontend knows that the
2776         next Debugger event it receives after issuing the step command is
2777         the result (stepped and paused, or stepped and resumed).
2778
2779         To make resuming consistent in all cases, a Debugger.resume command
2780         will always respond with a Debugger.resumed event.
2781
2782         Finally, Debugger.continueToLocation is treated like a "big step"
2783         in cases where we can resolve the location. If we can't resolve the
2784         location it is treated as a resume, maintaining the old behavior.
2785
2786         * inspector/agents/InspectorDebuggerAgent.h:
2787         * inspector/agents/InspectorDebuggerAgent.cpp:
2788         (Inspector::InspectorDebuggerAgent::stepOver):
2789         (Inspector::InspectorDebuggerAgent::stepInto):
2790         (Inspector::InspectorDebuggerAgent::stepOut):
2791         (Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
2792         (Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
2793         When stepping register a VM exit observer so that we can issue
2794         a Debugger.resumed event if the step caused us to exit the VM.
2795
2796         (Inspector::InspectorDebuggerAgent::resume):
2797         Set a flag to issue a Debugger.resumed event once we break out
2798         of the nested run loop.
2799
2800         (Inspector::InspectorDebuggerAgent::didPause):
2801         We are issuing Debugger.paused so clear the state to indicate that
2802         we no longer need to issue Debugger.resumed event, we have paused.
2803
2804         (Inspector::InspectorDebuggerAgent::didContinue):
2805         Only issue the Debugger.resumed event if needed (explicitly asked
2806         to resume).
2807
2808         (Inspector::InspectorDebuggerAgent::continueToLocation):
2809         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
2810         All places that do continueProgram should be audited. In error cases,
2811         if we are paused and continue we should remember to send Debugger.resumed.
2812
2813         * inspector/protocol/Debugger.json:
2814         Clarify in the protocol description the contract of these methods.
2815
2816 2016-11-09  Joseph Pecoraro  <pecoraro@apple.com>
2817
2818         Web Inspector: Associate Worker Resources with the Worker and not the Page
2819         https://bugs.webkit.org/show_bug.cgi?id=164342
2820         <rdar://problem/29075775>
2821
2822         Reviewed by Timothy Hatcher.
2823
2824         * inspector/protocol/Network.json:
2825         * inspector/protocol/Page.json:
2826         Associate Resource data with a target.
2827
2828 2016-11-09  Keith Miller  <keith_miller@apple.com>
2829
2830         jsc CLI should work with the remote inspector
2831         https://bugs.webkit.org/show_bug.cgi?id=164569
2832
2833         Reviewed by Joseph Pecoraro.
2834
2835         This patch enables using the remote inspector on the jsc CLI.
2836         In order to use the remote inspector, jsc users need to pass an option.
2837
2838         * jsc.cpp:
2839         (CommandLine::parseArguments):
2840         (runJSC):
2841
2842 2016-11-09  Saam Barati  <sbarati@apple.com>
2843
2844         Math.min()/Math.max() with no arguments is lowered incorrectly in the BytecodeParser
2845         https://bugs.webkit.org/show_bug.cgi?id=164464
2846         <rdar://problem/29131452>
2847
2848         Reviewed by Darin Adler.
2849
2850         We were incorrectly matching this pattern inside the bytecode parser
2851         to return NaN. Instead, we must return:
2852           Infinity for Math.min()
2853          -Infinity for Math.max()
2854
2855         * dfg/DFGByteCodeParser.cpp:
2856         (JSC::DFG::ByteCodeParser::handleMinMax):
2857
2858 2016-11-09  Saam Barati  <sbarati@apple.com>
2859
2860         TypeProfiler and running GC collection on another thread don't play nicely with each other
2861         https://bugs.webkit.org/show_bug.cgi?id=164441
2862         <rdar://problem/29132174>
2863
2864         Reviewed by Geoffrey Garen.
2865
2866         This fix here is simple: we now treat the type profiler log as a GC root.
2867         GC will make sure that we mark any values/structures that are in the log.
2868         It's easy to reason about the correctness of this, and it also solves
2869         the problem that we were clearing the log on the GC thread. Clearing the
2870         log on the GC thread was a problem because when we clear the log, we may
2871         allocate, which we're not allowed to do from the GC thread.
2872
2873         * heap/Heap.cpp:
2874         (JSC::Heap::markRoots):
2875         (JSC::Heap::visitTypeProfiler):
2876         (JSC::Heap::collectInThread):
2877         * heap/Heap.h:
2878         * runtime/TypeProfilerLog.cpp:
2879         (JSC::TypeProfilerLog::processLogEntries):
2880         (JSC::TypeProfilerLog::visit):
2881         * runtime/TypeProfilerLog.h:
2882
2883 2016-11-09  JF Bastien  <jfbastien@apple.com>
2884
2885         WebAssembly: Silence noisy warning
2886         https://bugs.webkit.org/show_bug.cgi?id=164459
2887
2888         Reviewed by Yusuke Suzuki.
2889
2890         * wasm/WasmPlan.cpp:
2891         (JSC::Wasm::Plan::Plan):
2892
2893 2016-11-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2894
2895         [JSC] The implementation of 8 bit operation in MacroAssembler should care about uint8_t / int8_t
2896         https://bugs.webkit.org/show_bug.cgi?id=164432
2897
2898         Reviewed by Michael Saboff.
2899
2900         Except for X86, our supported MacroAssemblers do not have native 8bit instructions.
2901         It means that all the 8bit instructions are converted to 32bit operations by using
2902         scratch registers. For example, ARM64 branch8 implementation is the following.
2903
2904             Jump branch8(RelationCondition cord, Address left, TrustedImm32 right)
2905             {
2906                 TrustedImm32 right8(static_cast<int8_t>(right.m_value));
2907                 load8(left, getCachedMemoryTempRegisterIDAndInvalidate());
2908                 return branch32(cone, memoryTempRegister, right8);
2909             }
2910
2911         The problem is that we exclusively use zero-extended load instruction (load8). Even
2912         for signed RelationConditions, we do not perform sign extension. It makes signed
2913         operations with negative numbers incorrect! Consider the |left| address holds `-1`
2914         in int8_t form. However load8 will load it as 255 into 32bit register. On the other hand,
2915         |right| will be sign extended. If you pass 0 as |right| and LessThan condition, this
2916         branch8 should jump based on the answer of `-1 < 0`. But the current MacroAssembler
2917         performs `255 < 0` in int32_t context and returns the incorrect result.
2918
2919         We should follow the x86 model. So we should select the appropriate load operation and masking
2920         operation based on the RelationCondition. This patch introduces mask8OnCondition and load8OnCondition.
2921         And we use them in 8bit operations including branch8, branchTest8, compare8, and test8.
2922
2923         We intentionally do not change anything on x86 assembler since it has the native signed 8bit operations.
2924
2925         * JavaScriptCore.xcodeproj/project.pbxproj:
2926         * assembler/AbstractMacroAssembler.h:
2927         * assembler/MacroAssembler.h:
2928         (JSC::MacroAssembler::isSigned):
2929         (JSC::MacroAssembler::isUnsigned):
2930         (JSC::MacroAssembler::branchTest8):
2931         * assembler/MacroAssemblerARM.h:
2932         (JSC::MacroAssemblerARM::branch8):
2933         (JSC::MacroAssemblerARM::branchTest8):
2934         (JSC::MacroAssemblerARM::compare8):
2935         (JSC::MacroAssemblerARM::test8):
2936         * assembler/MacroAssemblerARM64.h:
2937         (JSC::MacroAssemblerARM64::load8SignedExtendTo32):
2938         (JSC::MacroAssemblerARM64::branch8):
2939         (JSC::MacroAssemblerARM64::branchTest8):
2940         (JSC::MacroAssemblerARM64::compare8):
2941         (JSC::MacroAssemblerARM64::test8):
2942         * assembler/MacroAssemblerARMv7.h:
2943         (JSC::MacroAssemblerARMv7::branch8):
2944         (JSC::MacroAssemblerARMv7::branchTest8):
2945         (JSC::MacroAssemblerARMv7::compare8):
2946         (JSC::MacroAssemblerARMv7::test8):
2947         * assembler/MacroAssemblerHelpers.h: Added.
2948         (JSC::MacroAssemblerHelpers::isSigned):
2949         (JSC::MacroAssemblerHelpers::isUnsigned):
2950         (JSC::MacroAssemblerHelpers::mask8OnCondition):
2951         (JSC::MacroAssemblerHelpers::load8OnCondition):
2952         * assembler/MacroAssemblerMIPS.h:
2953         (JSC::MacroAssemblerMIPS::branch8):
2954         (JSC::MacroAssemblerMIPS::compare8):
2955         (JSC::MacroAssemblerMIPS::branchTest8):
2956         (JSC::MacroAssemblerMIPS::test8):
2957         * assembler/MacroAssemblerSH4.h:
2958         (JSC::MacroAssemblerSH4::branchTest8):
2959         (JSC::MacroAssemblerSH4::branch8):
2960         (JSC::MacroAssemblerSH4::compare8):
2961         (JSC::MacroAssemblerSH4::test8):
2962         * assembler/MacroAssemblerX86_64.h:
2963         (JSC::MacroAssemblerX86_64::branch8):
2964
2965 2016-11-08  Geoffrey Garen  <ggaren@apple.com>
2966
2967         REGRESSION: date-format-tofte.js is super slow
2968         https://bugs.webkit.org/show_bug.cgi?id=164499
2969
2970         Reviewed by Sam Weinig.
2971
2972         * bytecode/EvalCodeCache.h:
2973         (JSC::EvalCodeCache::CacheKey::operator==): Use character comparison,
2974         not pointer comparison. (This function was always wrong, but I started
2975         calling it in more places.)
2976
2977 2016-11-08  Saam Barati  <sbarati@apple.com>
2978
2979         REGRESSION: Crashes in StringImpl destructor during GC when clearing the HasOwnPropertyCache
2980         https://bugs.webkit.org/show_bug.cgi?id=164433
2981
2982         Reviewed by Mark Lam.
2983
2984         Clearing the HasOwnPropertyCache will call deref() on the StringImpls
2985         in the cache. We were doing this from the collector thread, which is
2986         not allowed. It must be done from the mutator thread. We now clear the
2987         cache in Heap::finalize() which happens before the mutator begins
2988         executing JS after a collection happens.
2989
2990         * heap/Heap.cpp:
2991         (JSC::Heap::collectInThread):
2992         (JSC::Heap::finalize):
2993
2994 2016-11-05  Konstantin Tokarev  <annulen@yandex.ru>
2995
2996         Fixed compilation of LLInt with MinGW
2997         https://bugs.webkit.org/show_bug.cgi?id=164449
2998
2999         Reviewed by Michael Catanzaro.
3000
3001         MinGW uses LLIntAssembly.h with GNU assembler syntax, just like GCC on
3002         other platforms.
3003
3004         * llint/LowLevelInterpreter.cpp: Include LLIntAssembly.h with
3005         appropriate preamble.
3006
3007 2016-11-04  Filip Pizlo  <fpizlo@apple.com>
3008
3009         WTF::ParkingLot should stop using std::chrono because std::chrono::duration casts are prone to overflows
3010         https://bugs.webkit.org/show_bug.cgi?id=152045
3011
3012         Reviewed by Andy Estes.
3013         
3014         Probably the nicest example of why this patch is a good idea is the change in
3015         AtomicsObject.cpp.
3016
3017         * jit/ICStats.cpp:
3018         (JSC::ICStats::ICStats):
3019         * runtime/AtomicsObject.cpp:
3020         (JSC::atomicsFuncWait):
3021
3022 2016-11-04  JF Bastien  <jfbastien@apple.com>
3023
3024         testWASM should be very sad if no options are provided
3025         https://bugs.webkit.org/show_bug.cgi?id=164444
3026
3027         Reviewed by Saam Barati.
3028
3029         Detect missing or invalid options on the command line.
3030
3031         * testWasm.cpp:
3032         (CommandLine::parseArguments):
3033
3034 2016-11-04  Mark Lam  <mark.lam@apple.com>
3035
3036         Error description code should be able to handle Symbol values.
3037         https://bugs.webkit.org/show_bug.cgi?id=164436
3038         <rdar://problem/29115583>
3039
3040         Reviewed by Filip Pizlo and Saam Barati.
3041
3042         Previously, we try to toString() the Symbol value, resulting in it throwing an
3043         exception in errorDescriptionForValue() which breaks the invariant that
3044         errorDescriptionForValue() should not throw.
3045
3046         We fixed this by making errorDescriptionForValue() aware of the Symbol type, and
3047         not so a toString() on Symbol values.  Also fixed notAFunctionSourceAppender()
3048         to build a nicer message for Symbol values.
3049
3050         * runtime/ExceptionHelpers.cpp:
3051         (JSC::errorDescriptionForValue):
3052         (JSC::notAFunctionSourceAppender):
3053
3054 2016-11-02  Geoffrey Garen  <ggaren@apple.com>
3055
3056         EvalCodeCache should not give up in strict mode and other cases
3057         https://bugs.webkit.org/show_bug.cgi?id=164357
3058
3059         Reviewed by Michael Saboff.
3060
3061         EvalCodeCache gives up in non-trivial cases because generated eval code
3062         can't soundly migrate from, for example, a let scope to a non-let scope.
3063         The number of cases has grown over time.
3064
3065         Instead, let's cache eval code based on the location of the call to
3066         eval(). That way, we never relocate the code, and it's sound to make
3067         normal assumptions about our surrounding scope.
3068
3069         * bytecode/EvalCodeCache.h:
3070         (JSC::EvalCodeCache::CacheKey::CacheKey): Use CallSiteIndex to uniquely
3071         identify the location of our call to eval().
3072
3073         (JSC::EvalCodeCache::CacheKey::hash):
3074         (JSC::EvalCodeCache::CacheKey::operator==):
3075         (JSC::EvalCodeCache::CacheKey::Hash::equal): Use CallSiteIndex instead
3076         of lots of other flags.
3077
3078         (JSC::EvalCodeCache::tryGet): No need to include details that are implied
3079         by our CallSiteIndex.
3080
3081         (JSC::EvalCodeCache::getSlow): No need to skip caching in complex
3082         situations. We promise we'll never relocate the cached code.
3083
3084         (JSC::EvalCodeCache::isCacheableScope): Deleted.
3085         (JSC::EvalCodeCache::isCacheable): Deleted.
3086
3087         * interpreter/Interpreter.cpp:
3088         (JSC::eval): Pass through a CallSiteIndex to uniquely identify this call
3089         to eval().
3090
3091 2016-11-04  Keith Miller  <keith_miller@apple.com>
3092
3093         Add support for Wasm br_table
3094         https://bugs.webkit.org/show_bug.cgi?id=164429
3095
3096         Reviewed by Michael Saboff.
3097
3098         This patch adds support for Wasm br_table. The Wasm br_table
3099         opcode essentially directly maps to B3's switch opcode.
3100
3101         There are also three other minor changes:
3102         1) all non-argument locals should be initialized to zero at function entry.
3103         2) add new setErrorMessage member to WasmFunctionParser.h
3104         3) return does not decode an extra immediate anymore.
3105
3106         * testWasm.cpp:
3107         (runWasmTests):
3108         * wasm/WasmB3IRGenerator.cpp:
3109         * wasm/WasmFunctionParser.h:
3110         (JSC::Wasm::FunctionParser::setErrorMessage):
3111         (JSC::Wasm::FunctionParser<Context>::parseExpression):
3112         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
3113         (JSC::Wasm::FunctionParser<Context>::popExpressionStack):
3114         * wasm/WasmValidate.cpp:
3115         (JSC::Wasm::Validate::checkBranchTarget):
3116         (JSC::Wasm::Validate::addBranch):
3117         (JSC::Wasm::Validate::addSwitch):
3118
3119 2016-11-04  JF Bastien  <jfbastien@apple.com>
3120
3121         WebAssembly JS API: implement more sections
3122         https://bugs.webkit.org/show_bug.cgi?id=164023
3123
3124         Reviewed by Keith Miller.
3125
3126         On the JSC side:
3127
3128          - Put in parser stubs for all WebAssembly sections.
3129          - Parse Import, Export sections.
3130          - Use tryReserveCapacity instead of reserve, and bail out of the parser if it fails. This prevents the parser from bringing everything down when faced with a malicious input.
3131          - Encapsulate all parsed module information into its own structure, making it easier to pass around (from parser to Plan to Module to Instance).
3132          - Create WasmFormat.cpp to hold parsed module information's dtor to avoid including WasmMemory.h needlessly.
3133          - Remove all remainders of polyfill-prototype-1, and update license.
3134          - Add missing WasmOps.h and WasmValidateInlines.h auto-generation for cmake build.
3135
3136         On the Builder.js testing side:
3137
3138          - Implement Type, Import (function only), Export (function only) sections.
3139          - Check section order and uniqueness.
3140          - Optionally auto-generate the Type section from subsequent Export / Import / Code entries.
3141          - Allow re-exporting an import.
3142
3143         * CMakeLists.txt: missing auto-genration
3144         * JavaScriptCore.xcodeproj/project.pbxproj: merge conflict
3145         * testWasm.cpp: update for API changes, no functional change
3146         (checkPlan):
3147         (runWasmTests):
3148         * wasm/WasmFormat.cpp: add a dtor which requires extra headers which I'd rather not include in WasmFormat.h
3149         (JSC::Wasm::ModuleInformation::~ModuleInformation):
3150         * wasm/WasmFormat.h: Add External, Import, Functioninformation, Export, ModuleInformation, CompiledFunction, and remove obsolete stuff which was a holdover from the first implementation (all that code is now gone, so remove its license)
3151         (JSC::Wasm::External::isValid):
3152         * wasm/WasmModuleParser.cpp: simplify some, make names consistent with the WebAssembly section names, check memory allocations so they can fail early
3153         (JSC::Wasm::ModuleParser::parse):
3154         (JSC::Wasm::ModuleParser::parseType):
3155         (JSC::Wasm::ModuleParser::parseImport):
3156         (JSC::Wasm::ModuleParser::parseFunction):
3157         (JSC::Wasm::ModuleParser::parseTable):
3158         (JSC::Wasm::ModuleParser::parseMemory):
3159         (JSC::Wasm::ModuleParser::parseGlobal):
3160         (JSC::Wasm::ModuleParser::parseExport):
3161         (JSC::Wasm::ModuleParser::parseStart):
3162         (JSC::Wasm::ModuleParser::parseElement):
3163         (JSC::Wasm::ModuleParser::parseCode): avoid overflow through function size.
3164         (JSC::Wasm::ModuleParser::parseData):
3165         * wasm/WasmModuleParser.h:
3166         (JSC::Wasm::ModuleParser::moduleInformation):
3167         * wasm/WasmParser.h:
3168         (JSC::Wasm::Parser::consumeUTF8String): add as required by spec
3169         (JSC::Wasm::Parser::parseExternalKind): add as per spec
3170         * wasm/WasmPlan.cpp:
3171         (JSC::Wasm::Plan::Plan): fix some ownership, improve some error messages
3172         * wasm/WasmPlan.h: fix some ownership
3173         (JSC::Wasm::Plan::getModuleInformation):
3174         (JSC::Wasm::Plan::getMemory):
3175         (JSC::Wasm::Plan::compiledFunctionCount):
3176         (JSC::Wasm::Plan::compiledFunction):
3177         (JSC::Wasm::Plan::getCompiledFunctions):
3178         * wasm/WasmSections.h: macroize with description, so that error messages are super pretty. This could be auto-generated.
3179         * wasm/js/JSWebAssemblyModule.cpp:
3180         (JSC::JSWebAssemblyModule::create): take module information
3181         (JSC::JSWebAssemblyModule::JSWebAssemblyModule): ditto
3182         * wasm/js/JSWebAssemblyModule.h:
3183         (JSC::JSWebAssemblyModule::moduleInformation):
3184         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3185         (JSC::constructJSWebAssemblyInstance): check that modules with imports are instantiated with an import object, as per spec. This needs to be tested.
3186         * wasm/js/WebAssemblyMemoryConstructor.cpp:
3187         (JSC::constructJSWebAssemblyMemory):
3188         * wasm/js/WebAssemblyModuleConstructor.cpp:
3189         (JSC::constructJSWebAssemblyModule):
3190         * wasm/js/WebAssemblyTableConstructor.cpp:
3191         (JSC::constructJSWebAssemblyTable):
3192
3193 2016-11-03  Mark Lam  <mark.lam@apple.com>
3194
3195         ClonedArguments need to also support haveABadTime mode.
3196         https://bugs.webkit.org/show_bug.cgi?id=164200
3197         <rdar://problem/27211336>
3198
3199         Reviewed by Geoffrey Garen.
3200
3201         For those who are not familiar with the parlance, "have a bad time" in the VM
3202         means that Object.prototype has been modified in such a way that we can no longer
3203         trivially do indexed property accesses without consulting the Object.prototype.
3204         This defeats JIT indexed put optimizations, and hence, makes the VM "have a
3205         bad time".
3206
3207         Once the VM enters haveABadTime mode, all existing objects are converted to use
3208         slow put storage.  Thereafter, JSArrays are always created with slow put storage.
3209         JSObjects are always created with a blank indexing type.  When a new indexed
3210         property is put into the new object, its indexing type will be converted to the
3211         slow put array indexing type just before we perform the put operation.  This is
3212         how we ensure that the objects will also use slow put storage.
3213
3214         However, ClonedArguments is an object which was previously created unconditionally
3215         to use contiguous storage.  Subsequently, if we try to call Object.preventExtensions()
3216         on that ClonedArguments object, Object.preventExtensions() will:
3217         1. make the ClonedArguments enter dictionary indexing mode, which means it will
3218         2. first ensure that the ClonedArguments is using slow put array storage via
3219            JSObject::ensureArrayStorageSlow().
3220
3221         However, JSObject::ensureArrayStorageSlow() expects that we never see an object
3222         with contiguous storage once we're in haveABadTime mode.  Our ClonedArguments
3223         object did not obey this invariant.
3224
3225         The fix is to make the ClonedArguments factories create objects that use slow put
3226         array storage when in haveABadTime mode.  This means:
3227
3228         1. JSGlobalObject::haveABadTime() now changes m_clonedArgumentsStructure to use
3229            its slow put version.
3230
3231            Also the caching of the slow put version of m_regExpMatchesArrayStructure,
3232            because we only need to create it when we are having a bad time. 
3233
3234         2. The ClonedArguments factories now allocates a butterfly with slow put array
3235            storage if we're in haveABadTime mode.
3236
3237            Also added some assertions in ClonedArguments' factory methods to ensure that
3238            the created object has the slow put indexing type when it needsSlowPutIndexing().
3239
3240         3. DFGFixupPhase now watches the havingABadTimeWatchpoint because ClonedArguments'
3241            structure will change when having a bad time.
3242
3243         4. DFGArgumentEliminationPhase and DFGVarargsForwardingPhase need not be changed
3244            because it is still valid to eliminate the creation of the arguments object
3245            even having a bad time, as long as the arguments object does not escape.
3246
3247         5. The DFGAbstractInterpreterInlines now checks for haveABadTime, and sets the
3248            predicted type to be SpecObject.
3249
3250         Note: this issue does not apply to DirectArguments and ScopedArguments because
3251         they use a blank indexing type (just like JSObject).
3252
3253         * dfg/DFGAbstractInterpreterInlines.h:
3254         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3255         * dfg/DFGArrayMode.cpp:
3256         (JSC::DFG::ArrayMode::dump):
3257         * dfg/DFGFixupPhase.cpp:
3258         (JSC::DFG::FixupPhase::fixupNode):
3259         * runtime/ClonedArguments.cpp:
3260         (JSC::ClonedArguments::createEmpty):
3261         (JSC::ClonedArguments::createWithInlineFrame):
3262         (JSC::ClonedArguments::createWithMachineFrame):
3263         (JSC::ClonedArguments::createByCopyingFrom):
3264         (JSC::ClonedArguments::createStructure):
3265         (JSC::ClonedArguments::createSlowPutStructure):
3266         * runtime/ClonedArguments.h:
3267         * runtime/JSGlobalObject.cpp:
3268         (JSC::JSGlobalObject::init):
3269         (JSC::JSGlobalObject::haveABadTime):
3270         (JSC::JSGlobalObject::visitChildren):
3271         * runtime/JSGlobalObject.h:
3272
3273 2016-11-03  Filip Pizlo  <fpizlo@apple.com>
3274
3275         DFG plays fast and loose with the shadow values of a Phi
3276         https://bugs.webkit.org/show_bug.cgi?id=164309
3277
3278         Reviewed by Saam Barati.
3279         
3280         Oh boy, what an embarrassing mistake! The style of SSA I like to use avoids block/value
3281         tuples as parameters of a Phi, thereby simplifying CFG transformations and making Phi largely
3282         not a special case for most compiler transforms. It does this by introducing another value
3283         called Upsilon, which stores a value into some Phi.
3284         
3285         B3 uses this also. The easiest way to understand what Upsilon/Phi behave like is to look at
3286         the B3->Air lowering. Air is not SSA - it has Tmps that you can assign to and use as many
3287         times as you like. B3 allocates one Tmp per Value, and an extra "phiTmp" for Phis, so that
3288         Phis get two Tmps total. Upsilon stores the value into the phiTmp of the Phi, while Phi moves
3289         the value from its phiTmp to its tmp.
3290         
3291         This is necessary to support scenarios like this:
3292         
3293             a: Phi()
3294             b: Upsilon(@x, ^a)
3295             c: Use(@a)
3296         
3297         Here, we want @c to see @a's value before @b. That's a very basic requirement of SSA: that
3298         the a value (like @a) doesn't change during its lifetime.
3299         
3300         Unfortunately, DFG's liveness analysis, abstract interpreter, and integer range optimization
3301         all failed to correctly model Upsilon/Phi this way. They would assume that it's accurate to
3302         model the Upsilon as storing into the Phi directly.
3303         
3304         Because DFG does flow analysis over SSA, making it correct means enabling it to speak of the
3305         shadow value. This change addresses this problem by introducing the concept of a
3306         NodeFlowProjection. This is a key that lets us speak of both a Node's primary value and its
3307         optional "shadow" value. Liveness, AI, and integer range are now keyed by NodeFlowProjection
3308         rather than Node*. Conceptually this turns out to be a very simple change, but it does touch
3309         a good amount of code.
3310         
3311         This looks to be perf-neutral.
3312
3313         Rolled back in after fixing the debug build.
3314
3315         * CMakeLists.txt:
3316         * JavaScriptCore.xcodeproj/project.pbxproj:
3317         * b3/air/AirLiveness.h:
3318         (JSC::B3::Air::TmpLivenessAdapter::numIndices):
3319         (JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
3320         (JSC::B3::Air::RegLivenessAdapter::numIndices):
3321         (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
3322         (JSC::B3::Air::TmpLivenessAdapter::maxIndex): Deleted.
3323         (JSC::B3::Air::StackSlotLivenessAdapter::maxIndex): Deleted.
3324         (JSC::B3::Air::RegLivenessAdapter::maxIndex): Deleted.
3325         * dfg/DFGAbstractInterpreter.h:
3326         (JSC::DFG::AbstractInterpreter::forNode):
3327         * dfg/DFGAbstractInterpreterInlines.h:
3328         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3329         (JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
3330         (JSC::DFG::AbstractInterpreter<AbstractStateType>::dump):
3331         * dfg/DFGAtTailAbstractState.cpp: