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