Unreviewed, rolling out r241784.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog-2016-09-26
1 2016-09-24  Chris Dumez  <cdumez@apple.com>
2
3         REGRESSION (r206221): [USER] com.apple.WebKit.WebContent.Development at com.apple.JavaScriptCore: vmEntryToJavaScript + 299
4         https://bugs.webkit.org/show_bug.cgi?id=162536
5         <rdar://problem/28415971>
6
7         Reviewed by Gavin Barraclough.
8
9         Drop API on PropertySlot for setting a cacheable custom getter/setter
10         given that this is not supported yet and will lead to crashes if used.
11
12         * runtime/PropertySlot.h:
13         (JSC::PropertySlot::isCacheableCustom):
14         (JSC::PropertySlot::isCacheableCustomAccessor): Deleted.
15         (JSC::PropertySlot::setCacheableCustomGetterSetter): Deleted.
16
17 2016-09-23  Filip Pizlo  <fpizlo@apple.com>
18
19         Need a store-load fence between setting cell state and visiting the object in SlotVisitor
20         https://bugs.webkit.org/show_bug.cgi?id=162354
21
22         Reviewed by Mark Lam.
23         
24         This was meant to be a small change, but then it became bigger as I found small
25         opportunities for improving this code. This adds a store-load fence and is performance-
26         neutral. That's probably partly due to other optimizations that I did to visitChildren().
27         
28         Initially, I found that adding an mfence as a store-load fence was terribly expensive. So,
29         I thought that I needed to buffer up a bunch of objects, set their states, do one mfence,
30         and then visit all of them. This seemed like a win, so I went with it. Unfortunately, this
31         made no sense for two reasons:
32         
33         - I shouldn't use mfence. I should use ortop (lock orl $0, (%rsp)) instead. Ortop is
34           basically free, and it's what WTF now uses for storeLoadFence().
35         
36         - My data saying that buffering up objects was not a slow-down was wrong. That was actually
37           almost as expensive as the mfence.
38         
39         But in order to implement that, I made some other improvements that I think we should stick
40         with:
41         
42         - SlotVisitor::visitChildren() now uses a switch on type. This replaces what used to be
43           some nasty ClassInfo look-ups.
44         
45         - We no longer save the object's old CellState. We would do that so that we would know what
46           state the object had been before we blackened it. But I believe that the more logical
47           solution is to have two kinds of black - one for black-for-the-first-time objects and one
48           for repeat offenders. This is a lot easier to reason about, since you can now just figure
49           this out by looking at the cell directly.
50         
51         The latter change meant rewiring a bunch of barriers. It didn't make them any more
52         expensive.
53         
54         Relanding after fixing a nasty build failure in cloop and elsewhere.
55
56         * JavaScriptCore.xcodeproj/project.pbxproj:
57         * assembler/AbstractMacroAssembler.h:
58         (JSC::isARMv7IDIVSupported): Deleted.
59         (JSC::isARM64): Deleted.
60         (JSC::isX86): Deleted.
61         (JSC::isX86_64): Deleted.
62         (JSC::optimizeForARMv7IDIVSupported): Deleted.
63         (JSC::optimizeForARM64): Deleted.
64         (JSC::optimizeForX86): Deleted.
65         (JSC::optimizeForX86_64): Deleted.
66         * assembler/CPU.h: Added.
67         (JSC::isARMv7IDIVSupported):
68         (JSC::isARM64):
69         (JSC::isX86):
70         (JSC::isX86_64):
71         (JSC::optimizeForARMv7IDIVSupported):
72         (JSC::optimizeForARM64):
73         (JSC::optimizeForX86):
74         (JSC::optimizeForX86_64):
75         * ftl/FTLLowerDFGToB3.cpp:
76         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
77         * heap/CellState.h:
78         (JSC::isBlack):
79         (JSC::blacken):
80         * heap/Heap.cpp:
81         (JSC::Heap::addToRememberedSet):
82         * heap/Heap.h:
83         * heap/HeapInlines.h:
84         (JSC::Heap::writeBarrier):
85         (JSC::Heap::reportExtraMemoryVisited):
86         (JSC::Heap::reportExternalMemoryVisited):
87         * heap/MarkStack.cpp:
88         * heap/MarkStack.h:
89         * heap/SlotVisitor.cpp:
90         (JSC::SlotVisitor::visitChildren):
91         * heap/SlotVisitor.h:
92         * heap/SlotVisitorInlines.h:
93         (JSC::SlotVisitor::reportExtraMemoryVisited):
94         (JSC::SlotVisitor::reportExternalMemoryVisited):
95         * jit/AssemblyHelpers.h:
96         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
97         * llint/LLIntData.cpp:
98         (JSC::LLInt::Data::performAssertions):
99         * llint/LowLevelInterpreter.asm:
100         * llint/LowLevelInterpreter32_64.asm:
101         * llint/LowLevelInterpreter64.asm:
102         * runtime/JSObject.h:
103         (JSC::isJSFinalObject):
104
105 2016-09-23  Caitlin Potter  <caitp@igalia.com>
106
107         [JSC] Implement parsing of Async Functions
108         https://bugs.webkit.org/show_bug.cgi?id=161409
109
110         Reviewed by Yusuke Suzuki.
111
112         Introduces frontend parsing for the async function proposal soon to be
113         ratified in ECMA262 (https://tc39.github.io/ecmascript-asyncawait/).
114
115         * API/JSScriptRef.cpp:
116         (parseScript):
117         * Configurations/FeatureDefines.xcconfig:
118         * builtins/BuiltinExecutables.cpp:
119         (JSC::BuiltinExecutables::createExecutable):
120         * bytecode/EvalCodeCache.h:
121         (JSC::EvalCodeCache::CacheKey::CacheKey):
122         * bytecode/ExecutableInfo.h:
123         (JSC::ExecutableInfo::ExecutableInfo):
124         (JSC::ExecutableInfo::scriptMode):
125         (JSC::ExecutableInfo::commentMode): Deleted.
126         * bytecode/UnlinkedCodeBlock.cpp:
127         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
128         * bytecode/UnlinkedCodeBlock.h:
129         (JSC::UnlinkedCodeBlock::scriptMode):
130         (JSC::UnlinkedCodeBlock::commentMode): Deleted.
131         * bytecode/UnlinkedFunctionExecutable.cpp:
132         (JSC::generateUnlinkedFunctionCodeBlock):
133         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
134         * bytecode/UnlinkedFunctionExecutable.h:
135         * bytecompiler/BytecodeGenerator.cpp:
136         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
137         (JSC::BytecodeGenerator::emitNewMethodDefinition):
138         * bytecompiler/BytecodeGenerator.h:
139         (JSC::BytecodeGenerator::scriptMode):
140         (JSC::BytecodeGenerator::makeFunction):
141         (JSC::BytecodeGenerator::commentMode): Deleted.
142         * bytecompiler/NodesCodegen.cpp:
143         (JSC::AwaitExprNode::emitBytecode):
144         * parser/ASTBuilder.h:
145         (JSC::ASTBuilder::createAwait):
146         (JSC::ASTBuilder::createAsyncFunctionBody):
147         * parser/Keywords.table:
148         * parser/Lexer.cpp:
149         (JSC::Lexer<T>::Lexer):
150         (JSC::Lexer<T>::lex):
151         * parser/Lexer.h:
152         * parser/NodeConstructors.h:
153         (JSC::AwaitExprNode::AwaitExprNode):
154         * parser/Nodes.h:
155         * parser/Parser.cpp:
156         (JSC::Parser<LexerType>::Parser):
157         (JSC::Parser<LexerType>::parseInner):
158         (JSC::Parser<LexerType>::isArrowFunctionParameters):
159         (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
160         (JSC::Parser<LexerType>::parseStatementListItem):
161         (JSC::Parser<LexerType>::parseVariableDeclarationList):
162         (JSC::Parser<LexerType>::parseDestructuringPattern):
163         (JSC::Parser<LexerType>::parseStatement):
164         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
165         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
166         (JSC::Parser<LexerType>::parseFormalParameters):
167         (JSC::stringForFunctionMode):
168         (JSC::Parser<LexerType>::parseFunctionParameters):
169         (JSC::Parser<LexerType>::parseFunctionInfo):
170         (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
171         (JSC::Parser<LexerType>::parseClass):
172         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
173         (JSC::Parser<LexerType>::parseImportClauseItem):
174         (JSC::Parser<LexerType>::parseImportDeclaration):
175         (JSC::Parser<LexerType>::parseExportDeclaration):
176         (JSC::Parser<LexerType>::parseAssignmentExpression):
177         (JSC::Parser<LexerType>::parseProperty): Deleted.
178         (JSC::Parser<LexerType>::parsePropertyMethod): Deleted.
179         (JSC::Parser<LexerType>::parsePrimaryExpression): Deleted.
180         (JSC::Parser<LexerType>::parseMemberExpression): Deleted.
181         (JSC::Parser<LexerType>::parseArrowFunctionExpression): Deleted.
182         (JSC::Parser<LexerType>::parseUnaryExpression): Deleted.
183         (JSC::Parser<LexerType>::printUnexpectedTokenText): Deleted.
184         * parser/Parser.h:
185         (JSC::Scope::Scope):
186         (JSC::Scope::setSourceParseMode):
187         (JSC::Scope::isAsyncFunction):
188         (JSC::Scope::isAsyncFunctionBoundary):
189         (JSC::Scope::setIsAsyncArrowFunction):
190         (JSC::Scope::setIsAsyncFunction):
191         (JSC::Scope::setIsAsyncFunctionBody):
192         (JSC::Scope::setIsAsyncArrowFunctionBody):
193         (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError):
194         (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
195         (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction):
196         (JSC::Parser::forceClassifyExpressionError):
197         (JSC::Parser::declarationTypeToVariableKind):
198         (JSC::Parser::upperScope):
199         (JSC::Parser::pushScope):
200         (JSC::Parser::matchSpecIdentifier):
201         (JSC::Parser::isDisallowedIdentifierAwait):
202         (JSC::Parser::disallowedIdentifierAwaitReason):
203         (JSC::parse):
204         (JSC::Scope::isGeneratorBoundary): Deleted.
205         (JSC::Parser::ExpressionErrorClassifier::indicatesPossiblePattern): Deleted.
206         * parser/ParserModes.h:
207         (JSC::SourceParseModeSet::SourceParseModeSet):
208         (JSC::SourceParseModeSet::contains):
209         (JSC::SourceParseModeSet::mergeSourceParseModes):
210         (JSC::isFunctionParseMode):
211         (JSC::isAsyncFunctionParseMode):
212         (JSC::isAsyncArrowFunctionParseMode):
213         (JSC::isAsyncFunctionWrapperParseMode):
214         (JSC::isAsyncFunctionBodyParseMode):
215         (JSC::isMethodParseMode):
216         (JSC::isModuleParseMode):
217         (JSC::isProgramParseMode):
218         (JSC::constructAbilityForParseMode):
219         * parser/ParserTokens.h:
220         * parser/SourceCodeKey.h:
221         (JSC::SourceCodeFlags::SourceCodeFlags):
222         (JSC::SourceCodeKey::SourceCodeKey):
223         * parser/SyntaxChecker.h:
224         (JSC::SyntaxChecker::createAwait):
225         (JSC::SyntaxChecker::createAsyncFunctionBody):
226         (JSC::SyntaxChecker::createYield): Deleted.
227         (JSC::SyntaxChecker::createFunctionExpr): Deleted.
228         * runtime/CodeCache.cpp:
229         (JSC::CodeCache::getGlobalCodeBlock):
230         (JSC::CodeCache::getProgramCodeBlock):
231         (JSC::CodeCache::getEvalCodeBlock):
232         (JSC::CodeCache::getModuleProgramCodeBlock):
233         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
234         * runtime/CodeCache.h:
235         * runtime/CommonIdentifiers.h:
236         * runtime/Completion.cpp:
237         (JSC::checkSyntax):
238         (JSC::checkModuleSyntax):
239         * runtime/Executable.cpp:
240         (JSC::ProgramExecutable::checkSyntax):
241         * runtime/Executable.h:
242         * runtime/ModuleLoaderPrototype.cpp:
243         (JSC::moduleLoaderPrototypeParseModule):
244
245 2016-09-23  Commit Queue  <commit-queue@webkit.org>
246
247         Unreviewed, rolling out r206314, r206316, and r206319.
248         https://bugs.webkit.org/show_bug.cgi?id=162506
249
250         These changes broke various builds (Requested by ryanhaddad on
251         #webkit).
252
253         Reverted changesets:
254
255         "Need a store-load fence between setting cell state and
256         visiting the object in SlotVisitor"
257         https://bugs.webkit.org/show_bug.cgi?id=162354
258         http://trac.webkit.org/changeset/206314
259
260         "Unreviewed, fix cloop."
261         http://trac.webkit.org/changeset/206316
262
263         "Unreviewed, fix all other builds."
264         http://trac.webkit.org/changeset/206319
265
266 2016-09-23  Filip Pizlo  <fpizlo@apple.com>
267
268         Unreviewed, fix all other builds.
269
270         * assembler/AbstractMacroAssembler.h:
271
272 2016-09-23  Filip Pizlo  <fpizlo@apple.com>
273
274         Unreviewed, fix cloop.
275
276         * assembler/AbstractMacroAssembler.h:
277         * heap/SlotVisitor.cpp:
278
279 2016-09-22  Filip Pizlo  <fpizlo@apple.com>
280
281         Need a store-load fence between setting cell state and visiting the object in SlotVisitor
282         https://bugs.webkit.org/show_bug.cgi?id=162354
283
284         Reviewed by Mark Lam.
285         
286         This was meant to be a small change, but then it became bigger as I found small
287         opportunities for improving this code. This adds a store-load fence and is performance-
288         neutral. That's probably partly due to other optimizations that I did to visitChildren().
289         
290         Initially, I found that adding an mfence as a store-load fence was terribly expensive. So,
291         I thought that I needed to buffer up a bunch of objects, set their states, do one mfence,
292         and then visit all of them. This seemed like a win, so I went with it. Unfortunately, this
293         made no sense for two reasons:
294         
295         - I shouldn't use mfence. I should use ortop (lock orl $0, (%rsp)) instead. Ortop is
296           basically free, and it's what WTF now uses for storeLoadFence().
297         
298         - My data saying that buffering up objects was not a slow-down was wrong. That was actually
299           almost as expensive as the mfence.
300         
301         But in order to implement that, I made some other improvements that I think we should stick
302         with:
303         
304         - SlotVisitor::visitChildren() now uses a switch on type. This replaces what used to be
305           some nasty ClassInfo look-ups.
306         
307         - We no longer save the object's old CellState. We would do that so that we would know what
308           state the object had been before we blackened it. But I believe that the more logical
309           solution is to have two kinds of black - one for black-for-the-first-time objects and one
310           for repeat offenders. This is a lot easier to reason about, since you can now just figure
311           this out by looking at the cell directly.
312         
313         The latter change meant rewiring a bunch of barriers. It didn't make them any more
314         expensive.
315
316         * ftl/FTLLowerDFGToB3.cpp:
317         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
318         * heap/CellState.h:
319         (JSC::blacken):
320         * heap/Heap.cpp:
321         (JSC::Heap::addToRememberedSet):
322         * heap/Heap.h:
323         * heap/HeapInlines.h:
324         (JSC::Heap::writeBarrier):
325         (JSC::Heap::reportExtraMemoryVisited):
326         (JSC::Heap::reportExternalMemoryVisited):
327         * heap/MarkStack.cpp:
328         * heap/MarkStack.h:
329         * heap/SlotVisitor.cpp:
330         (JSC::SlotVisitor::visitChildren):
331         * heap/SlotVisitor.h:
332         * heap/SlotVisitorInlines.h:
333         (JSC::SlotVisitor::reportExtraMemoryVisited):
334         (JSC::SlotVisitor::reportExternalMemoryVisited):
335         * jit/AssemblyHelpers.h:
336         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
337         * llint/LLIntData.cpp:
338         (JSC::LLInt::Data::performAssertions):
339         * llint/LowLevelInterpreter.asm:
340         * llint/LowLevelInterpreter32_64.asm:
341         * llint/LowLevelInterpreter64.asm:
342         * runtime/JSObject.h:
343         (JSC::isJSFinalObject):
344
345 2016-09-23  Csaba Osztrogon√°c  <ossy@webkit.org>
346
347         ARM EABI buildfix after r206289
348         https://bugs.webkit.org/show_bug.cgi?id=162486
349
350         Unreviewed buildfix.
351
352         * jit/CCallHelpers.h:
353         (JSC::CCallHelpers::setupArgumentsWithExecState):
354
355 2016-09-23  Antoine Quint  <graouts@apple.com>
356
357         Add a new runtime flag for work on modern media controls (off by default)
358         https://bugs.webkit.org/show_bug.cgi?id=162420
359         <rdar://problem/27989489>
360
361         Reviewed by Eric Carlson.
362
363         * runtime/CommonIdentifiers.h:
364
365 2016-09-23  Carlos Garcia Campos  <cgarcia@igalia.com>
366
367         REGRESSION(r194387): Crash on github.com in IntlDateTimeFormat::resolvedOptions in C locale
368         https://bugs.webkit.org/show_bug.cgi?id=162139
369
370         Reviewed by Michael Catanzaro.
371
372         The crash happens in unix ports because the resolved locale is empty when system locale is "C". IntlObject
373         considers any language tag with a size < 2 to be an invalid language, so "C" is not a valid language to resolve
374         the locale. We should ensure that WTF::platformUserPreferredLanguages() never returns invalid languages, but
375         that's not enough, because languages can be overriden from the public API, so we need to handle those cases and
376         throw exceptions instead of crashing.
377
378         * runtime/IntlCollator.cpp:
379         (JSC::IntlCollator::initializeCollator): Throw a exception when we fail to resolve the locale.
380         * runtime/IntlDateTimeFormat.cpp:
381         (JSC::IntlDateTimeFormat::initializeDateTimeFormat): Ditto.
382         * runtime/IntlNumberFormat.cpp:
383         (JSC::IntlNumberFormat::initializeNumberFormat): Ditto.
384
385 2016-09-22  Benjamin Poulain  <bpoulain@apple.com>
386
387         [JSC] Use an inline cache to generate op_negate
388         https://bugs.webkit.org/show_bug.cgi?id=162371
389
390         Reviewed by Saam Barati.
391
392         Use an inline cache to reduce the amount of code
393         required to implement op_negate.
394
395         For pure integer negate, the generated asm shrinks
396         from 147 bytes to 125 bytes (14%).
397         For double negate, the generated asm shrinks
398         to 130 bytes (11%).
399         The average size on Sunspider is 100bytes, this is due
400         to the op_negates that are never executed and do not
401         generate much.
402
403         * bytecode/ArithProfile.h:
404         (JSC::ArithProfile::ArithProfile):
405         (JSC::ArithProfile::observeLHS):
406         (JSC::ArithProfile::observeLHSAndRHS):
407         * bytecode/BytecodeList.json:
408         * bytecode/CodeBlock.cpp:
409         (JSC::CodeBlock::addJITNegIC):
410         * bytecode/CodeBlock.h:
411         * bytecompiler/BytecodeGenerator.cpp:
412         (JSC::BytecodeGenerator::emitUnaryOp):
413         * bytecompiler/BytecodeGenerator.h:
414         * bytecompiler/NodesCodegen.cpp:
415         (JSC::UnaryOpNode::emitBytecode):
416         * dfg/DFGSpeculativeJIT.cpp:
417         (JSC::DFG::SpeculativeJIT::compileMathIC):
418         * dfg/DFGSpeculativeJIT.h:
419         * ftl/FTLLowerDFGToB3.cpp:
420         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
421         * jit/CCallHelpers.h:
422         (JSC::CCallHelpers::setupArgumentsWithExecState):
423         * jit/JIT.h:
424         * jit/JITArithmetic.cpp:
425         (JSC::JIT::emit_op_negate):
426         (JSC::JIT::emitSlow_op_negate):
427         (JSC::JIT::emitMathICFast):
428         (JSC::JIT::emitMathICSlow):
429         * jit/JITInlines.h:
430         (JSC::JIT::callOperation):
431         * jit/JITMathIC.h:
432         (JSC::JITMathIC::generateInline):
433         (JSC::canGenerateWithBinaryProfile):
434         (JSC::canGenerateWithUnaryProfile):
435         * jit/JITMathICForwards.h:
436         * jit/JITNegGenerator.cpp:
437         (JSC::JITNegGenerator::generateInline):
438         (JSC::JITNegGenerator::generateFastPath):
439         * jit/JITNegGenerator.h:
440         (JSC::JITNegGenerator::JITNegGenerator):
441         (JSC::JITNegGenerator::arithProfile):
442         (JSC::JITNegGenerator::didEmitFastPath): Deleted.
443         (JSC::JITNegGenerator::endJumpList): Deleted.
444         (JSC::JITNegGenerator::slowPathJumpList): Deleted.
445         * jit/JITOperations.cpp:
446         * jit/JITOperations.h:
447         * llint/LowLevelInterpreter.asm:
448         * llint/LowLevelInterpreter32_64.asm:
449         * llint/LowLevelInterpreter64.asm:
450         * runtime/CommonSlowPaths.cpp:
451         (JSC::updateArithProfileForUnaryArithOp):
452         (JSC::SLOW_PATH_DECL):
453
454 2016-09-22  Mark Lam  <mark.lam@apple.com>
455
456         Removed unused hasErrorInfo().
457         https://bugs.webkit.org/show_bug.cgi?id=162473
458
459         Reviewed by Saam Barati.
460
461         * JavaScriptCore.order:
462         * runtime/Error.cpp:
463         (JSC::hasErrorInfo): Deleted.
464         * runtime/Error.h:
465
466 2016-09-22  Mark Lam  <mark.lam@apple.com>
467
468         Array.prototype.join should do overflow checks on string joins.
469         https://bugs.webkit.org/show_bug.cgi?id=162459
470
471         Reviewed by Saam Barati.
472
473         Change the 2 JSRopeString::create() functions that do joins to be private, and
474         force all clients of it to go through the jsString() utility functions that do
475         overflow checks before creating the ropes.
476
477         * dfg/DFGOperations.cpp:
478         * runtime/ArrayPrototype.cpp:
479         (JSC::slowJoin):
480         * runtime/JSString.h:
481         * runtime/Operations.h:
482         (JSC::jsString):
483
484 2016-09-22  Filip Pizlo  <fpizlo@apple.com>
485
486         Fences on x86 should be a lot cheaper
487         https://bugs.webkit.org/show_bug.cgi?id=162417
488
489         Reviewed by Mark Lam and Geoffrey Garen.
490
491         It turns out that:
492         
493             lock; orl $0, (%rsp)
494         
495         does everything that we wanted from:
496         
497             mfence
498         
499         And it's a lot faster. When I tried mfence for making object visiting concurrent-GC-TSO-
500         friendly, it was a 9% regression on Octane/splay. But when I tried ortop, it was neutral.
501         So, we should use ortop from now on.
502         
503         This part of the change is for the JITs. MacroAssembler::memoryFence() appears to always
504         mean something like an acqrel fence, so it's safe to make this use ortop. Since B3's Fence
505         compiles to Air MemoryFence, which is just MacroAssembler::memoryFence(), this also changes
506         B3 codegen.
507
508         * assembler/MacroAssemblerX86Common.h:
509         (JSC::MacroAssemblerX86Common::memoryFence):
510         * assembler/X86Assembler.h:
511         (JSC::X86Assembler::lock):
512         * b3/testb3.cpp:
513         (JSC::B3::testX86MFence):
514         (JSC::B3::testX86CompilerFence):
515
516 2016-09-22  Joseph Pecoraro  <pecoraro@apple.com>
517
518         test262: Function length should be number of parameters before parameters with default values
519         https://bugs.webkit.org/show_bug.cgi?id=162377
520
521         Reviewed by Saam Barati.
522
523         https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-expectedargumentcount
524
525         > NOTE: The ExpectedArgumentCount of a FormalParameterList is the number of
526         > FormalParameters to the left of either the rest parameter or the first
527         > FormalParameter with an Initializer. A FormalParameter without an
528         > initializer is allowed after the first parameter with an initializer
529         > but such parameters are considered to be optional with undefined as
530         > their default value.
531
532         Alongside the parameterCount value, maintain a separate count,
533         functionLength, which will be the count before seeing a rest parameter
534         or parameter with a default value. This will be the function's length.
535
536         * bytecode/UnlinkedCodeBlock.h:
537         * bytecode/UnlinkedFunctionExecutable.cpp:
538         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
539         * bytecode/UnlinkedFunctionExecutable.h:
540         * parser/ASTBuilder.h:
541         (JSC::ASTBuilder::createFunctionMetadata):
542         * parser/Nodes.cpp:
543         (JSC::FunctionMetadataNode::FunctionMetadataNode):
544         * parser/Nodes.h:
545         * parser/Parser.cpp:
546         (JSC::Parser<LexerType>::isArrowFunctionParameters):
547         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
548         (JSC::Parser<LexerType>::parseFormalParameters):
549         (JSC::Parser<LexerType>::parseFunctionBody):
550         (JSC::Parser<LexerType>::parseFunctionParameters):
551         (JSC::Parser<LexerType>::parseFunctionInfo):
552         * parser/Parser.h:
553         * parser/ParserFunctionInfo.h:
554         * parser/SourceProviderCacheItem.h:
555         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
556         * parser/SyntaxChecker.h:
557         (JSC::SyntaxChecker::createFunctionMetadata):
558         * runtime/Executable.h:
559         * runtime/JSFunction.cpp:
560         (JSC::JSFunction::createBuiltinFunction):
561         (JSC::JSFunction::reifyLength):
562
563 2016-09-22  Joseph Pecoraro  <pecoraro@apple.com>
564
565         Remove a bunch of unnecessary includes
566         https://bugs.webkit.org/show_bug.cgi?id=162376
567
568         Reviewed by Mark Lam.
569
570 2016-09-21  Keith Miller  <keith_miller@apple.com>
571
572         Fix build for future versions of Clang.
573         https://bugs.webkit.org/show_bug.cgi?id=162346
574
575         Reviewed by Filip Pizlo.
576
577         This fixes issues with the WebCore build where inline
578         template-class function definitions are marked as exported. This
579         genereates a weak external symobl that our build does not like.
580
581
582         * runtime/VM.h:
583         (JSC::VM::setGlobalConstRedeclarationShouldThrow):
584
585 2016-09-21  Joseph Pecoraro  <pecoraro@apple.com>
586
587         Inline function only used in one place
588         https://bugs.webkit.org/show_bug.cgi?id=162363
589
590         Reviewed by Saam Barati.
591
592         * bytecompiler/NodesCodegen.cpp:
593         (JSC::ForInNode::emitBytecode):
594         (JSC::ForInNode::emitMultiLoopBytecode):
595         * parser/Nodes.h:
596         No need for the extra function, it adds no clarification.
597
598 2016-09-21  Commit Queue  <commit-queue@webkit.org>
599
600         Unreviewed, rolling out r206222 and r206227.
601         https://bugs.webkit.org/show_bug.cgi?id=162361
602
603         "broke the windows build" (Requested by keith_mi_ on #webkit).
604
605         Reverted changesets:
606
607         "Fix build for future versions of Clang."
608         https://bugs.webkit.org/show_bug.cgi?id=162346
609         http://trac.webkit.org/changeset/206222
610
611         "Attempt to fix windows build after r206222."
612         http://trac.webkit.org/changeset/206227
613
614 2016-09-21  Filip Pizlo  <fpizlo@apple.com>
615
616         Add a Fence opcode to B3
617         https://bugs.webkit.org/show_bug.cgi?id=162343
618
619         Reviewed by Geoffrey Garen.
620         
621         This adds the most basic fence support to B3. Currently, this is optimal on x86 and correct
622         on ARM. It also happens to be sufficient and optimal for what we'll do in the concurrent GC.
623         
624         The idea of Fence is that it can represent any standalone fence instruction by having two
625         additional params: a read range and a write range. If the write range is empty, this is
626         taken to be a store-store fence, which turns into zero code on x86 and a cheaper fence on
627         ARM.
628         
629         It turns out that this is powerful enough to express store-load and store-store fences. For
630         load-store and load-load fences, you wouldn't have wanted to use any code on x86 and you
631         wouldn't have wanted a standalone barrier on ARM. For those cases, you'd want either a
632         fenced load (load acquire) or a dependency. See bug 162349 and bug 162350, respectively.
633         
634         This isn't yet optimized for store-store fences on ARM because we don't have the
635         MacroAssembler support. Also, the support for "dmb ish" is not really what we want (it seems
636         to use a heavier fence). I don't think that this is urgent because of how the concurrent GC
637         will use this facility. I've left that to bug 162342.
638
639         * CMakeLists.txt:
640         * JavaScriptCore.xcodeproj/project.pbxproj:
641         * assembler/MacroAssemblerCodeRef.cpp:
642         (JSC::MacroAssemblerCodeRef::tryToDisassemble):
643         (JSC::MacroAssemblerCodeRef::disassembly):
644         * assembler/MacroAssemblerCodeRef.h:
645         (JSC::MacroAssemblerCodeRef::size): Deleted.
646         (JSC::MacroAssemblerCodeRef::tryToDisassemble): Deleted.
647         * b3/B3Compilation.h:
648         (JSC::B3::Compilation::codeRef):
649         (JSC::B3::Compilation::disassembly):
650         (JSC::B3::Compilation::code): Deleted.
651         * b3/B3Effects.h:
652         * b3/B3FenceValue.cpp: Added.
653         (JSC::B3::FenceValue::~FenceValue):
654         (JSC::B3::FenceValue::cloneImpl):
655         (JSC::B3::FenceValue::FenceValue):
656         * b3/B3FenceValue.h: Added.
657         * b3/B3LowerToAir.cpp:
658         (JSC::B3::Air::LowerToAir::lower):
659         * b3/B3Opcode.cpp:
660         (WTF::printInternal):
661         * b3/B3Opcode.h:
662         * b3/B3Validate.cpp:
663         * b3/B3Value.cpp:
664         (JSC::B3::Value::effects):
665         * b3/air/AirOpcode.opcodes:
666         * b3/testb3.cpp:
667         (JSC::B3::checkUsesInstruction):
668         (JSC::B3::checkDoesNotUseInstruction):
669         (JSC::B3::testX86MFence):
670         (JSC::B3::testX86CompilerFence):
671         (JSC::B3::run):
672
673 2016-09-21  Keith Miller  <keith_miller@apple.com>
674
675         Fix build for future versions of Clang.
676         https://bugs.webkit.org/show_bug.cgi?id=162346
677
678         Reviewed by Filip Pizlo.
679
680         This fixes issues with the WebCore build where inline
681         template-class function definitions are marked as exported. This
682         genereates a weak external symobl that our build does not like.
683
684
685         * runtime/VM.h:
686         (JSC::VM::setGlobalConstRedeclarationShouldThrow):
687
688 2016-09-21  Chris Dumez  <cdumez@apple.com>
689
690         Object.getOwnPropertyDescriptor() does not work correctly cross origin
691         https://bugs.webkit.org/show_bug.cgi?id=162311
692
693         Reviewed by Gavin Barraclough.
694
695         Add a CustomGetterSetter field to PropertySlot that gets populated
696         by getOwnPropertySlot() and use it in getOwnPropertyDescriptor()
697         to properly populate the descriptor. We used to rely on reifying
698         the properties and then call getDirect() in order to get the
699         CustomGetterSetter. However, this hack was insufficient to support
700         the cross-origin case because we need to control more precisely
701         the visibility of the getter and the setter. For example, Location's
702         href property has both a getter and a setter in the same origin
703         case but only has a setter in the cross-origin case.
704
705         In the future, we can extend the use of PropertySlot's
706         customGetterSetter field to the same origin case and get rid of the
707         reification + getDirect() hack in getOwnPropertyDescriptor().
708
709         * runtime/JSObject.cpp:
710         (JSC::JSObject::getOwnPropertyDescriptor):
711         * runtime/PropertySlot.cpp:
712         (JSC::PropertySlot::customAccessorGetter):
713         * runtime/PropertySlot.h:
714
715 2016-09-21  Michael Saboff  <msaboff@apple.com>
716
717         FTL needs to reserve callee stack space in bytes
718         https://bugs.webkit.org/show_bug.cgi?id=162324
719
720         Reviewed by Geoffrey Garen.
721
722         Changed two instances where we call B3::Procedure::requestCallArgAreaSize() with the
723         number of JSValue sized objects of stack space instead of bytes.  The correct units
724         to use is bytes.
725
726         Renamed both the Air and B3 related callArgAreaSize() to callArgAreaSizeInBytes().
727
728         No new tests as this doesn't surface as an issue when arguments are passed on the stack.
729
730         * b3/B3Procedure.cpp:
731         (JSC::B3::Procedure::callArgAreaSizeInBytes):
732         (JSC::B3::Procedure::requestCallArgAreaSizeInBytes):
733         (JSC::B3::Procedure::callArgAreaSize): Deleted.
734         (JSC::B3::Procedure::requestCallArgAreaSize): Deleted.
735         * b3/B3Procedure.h:
736         * b3/air/AirAllocateStack.cpp:
737         (JSC::B3::Air::allocateStack):
738         * b3/air/AirCCallingConvention.cpp:
739         (JSC::B3::Air::computeCCallingConvention):
740         * b3/air/AirCode.h:
741         (JSC::B3::Air::Code::callArgAreaSizeInBytes):
742         (JSC::B3::Air::Code::requestCallArgAreaSizeInBytes):
743         (JSC::B3::Air::Code::callArgAreaSize): Deleted.
744         (JSC::B3::Air::Code::requestCallArgAreaSize): Deleted.
745         * ftl/FTLLowerDFGToB3.cpp:
746         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
747         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
748         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
749
750 2016-09-21  Csaba Osztrogon√°c  <ossy@webkit.org>
751
752         [ARM] Unreviewed buildfix after r206136.
753
754         * assembler/MacroAssembler.h:
755         * assembler/MacroAssemblerARM.h:
756         (JSC::MacroAssemblerARM::branchPtr): Added.
757
758 2016-09-20  Alex Christensen  <achristensen@webkit.org>
759
760         Require WTFMove for String::adopt
761         https://bugs.webkit.org/show_bug.cgi?id=162313
762
763         Reviewed by Yusuke Suzuki.
764
765         * runtime/JSStringBuilder.h:
766         (JSC::JSStringBuilder::build):
767
768 2016-09-20  Joseph Pecoraro  <pecoraro@apple.com>
769
770         REGRESSION(r205692): Minified builds have broken inspector
771         https://bugs.webkit.org/show_bug.cgi?id=162327
772         <rdar://problem/28370137>
773
774         Reviewed by Matt Baker.
775
776         * Scripts/cssmin.py:
777         (cssminify):
778         Converge on the newer cssmin that we mistakenly dropped in r205692.
779         This knows how to handle more cases.
780
781 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
782
783         DFG::StoreBarrierInsertionPhase should assume that any epoch increment may make objects older
784         https://bugs.webkit.org/show_bug.cgi?id=162319
785
786         Reviewed by Saam Barati.
787         
788         The store barrier phase needs to be aware of the fact that an object that is not in the
789         OldBlack state may be concurrently brought into that state. That means that:
790         
791         - We cannot reason about the relative ages of objects. An object is either new, in which
792           case we can store to it without barriers, or it's not in which case it needs a barrier.
793         
794         - After we insert a barrier on an object, the object is no longer new, because now the GC
795           knows about it and the GC may do things to it, like make it OldBlack.
796         
797         This is a perf-neutral change. These optimizations were never particularly profitable.
798
799         * dfg/DFGStoreBarrierInsertionPhase.cpp:
800
801 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
802
803         Rename MarkedSpace::version/MarkedBlock::version to MarkedSpace::markingVersion/MarkedBlock::markingVersion
804         https://bugs.webkit.org/show_bug.cgi?id=162310
805
806         Reviewed by Geoffrey Garen.
807         
808         In bug 162309, which is part of my concurrent GC work, I'll need to introduce a second
809         version-based flip. This one will be for newlyAllocated bits. This will allow me to
810         cheaply preserve per-object live state during marking. MarkedBlock::aboutToMarkSlow() will
811         do this instead of clearMarks():
812         
813             - Walk the mark bits, simultaneously counting the number of set bits and clearing
814               them.
815             - If the count is zero, then we're done.
816             - If the count is equal to the max number of cells in the block, then set the
817               allocated bit for the block.
818             - If the count is something else, create a newlyAllocated vector.
819         
820         The hope is that the last mode is going to be rare, since most blocks are not fragmented
821         at end of GC. Usually, we will fill them in with objects by allocating! But if we do
822         create newlyAllocated bits then we need to have some way of blowing them away later.
823         
824         This is where a second version comes in. We can have a version for newlyAllocated bits,
825         which we increment at the end of marking, at around the same time that we clear all
826         allocated bits.
827         
828         This means that the MarkedBlock will have two different version-based flips, so terms like
829         "flip" and "version" aren't enough.
830         
831         This patch gets rid of the term "flip" entirely. It's a term of art in GCs that refers to
832         the state change at the beginning or end of GC. It refers to the logical state change, not
833         the physical one. It doesn't actually make sense to speak of a block being flipped
834         independently of other blocks. It's true that our implementation of the flip makes some
835         state updates happen lazily, but the block updating itself in some way (like clearing mark
836         bits) isn't the flip - the flip already happened when the version was incremented.
837         
838         We no longer refer to a version without qualifying what kind of version it is. The type is
839         HeapVersion. All of the version members were renamed to markingVersion, to reflect the
840         fact that this version is just used for doing things to marking state. Instead of asking
841         if the block needsFlip(), we ask if areMarksStale().
842         
843         This will let us introduce a second version for newlyAllocated, and will let us speak of
844         the two versions unambiguously.
845
846         * heap/CellContainer.h:
847         * heap/CellContainerInlines.h:
848         (JSC::CellContainer::isMarked):
849         (JSC::CellContainer::isMarkedOrNewlyAllocated):
850         (JSC::CellContainer::aboutToMark):
851         (JSC::CellContainer::areMarksStale):
852         (JSC::CellContainer::needsFlip): Deleted.
853         * heap/ConservativeRoots.cpp:
854         (JSC::ConservativeRoots::genericAddPointer):
855         (JSC::ConservativeRoots::genericAddSpan):
856         * heap/HeapInlines.h:
857         (JSC::Heap::isMarked):
858         (JSC::Heap::isMarkedConcurrently):
859         (JSC::Heap::testAndSetMarked):
860         * heap/HeapUtil.h:
861         (JSC::HeapUtil::findGCObjectPointersForMarking):
862         * heap/MarkedAllocator.cpp:
863         (JSC::MarkedAllocator::isPagedOut):
864         * heap/MarkedBlock.cpp:
865         (JSC::MarkedBlock::MarkedBlock):
866         (JSC::MarkedBlock::Handle::specializedSweep):
867         (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
868         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
869         (JSC::MarkedBlock::aboutToMarkSlow):
870         (JSC::MarkedBlock::clearMarks):
871         (JSC::MarkedBlock::assertMarksNotStale):
872         (JSC::MarkedBlock::areMarksStale):
873         (JSC::MarkedBlock::Handle::areMarksStale):
874         (JSC::MarkedBlock::isMarked):
875         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
876         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
877         (JSC::MarkedBlock::markCount):
878         (JSC::MarkedBlock::Handle::isLive):
879         (JSC::MarkedBlock::Handle::isLiveCell):
880         (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode): Deleted.
881         (JSC::MarkedBlock::assertFlipped): Deleted.
882         (JSC::MarkedBlock::needsFlip): Deleted.
883         (JSC::MarkedBlock::Handle::needsFlip): Deleted.
884         * heap/MarkedBlock.h:
885         (JSC::MarkedBlock::areMarksStale):
886         (JSC::MarkedBlock::aboutToMark):
887         (JSC::MarkedBlock::assertMarksNotStale):
888         (JSC::MarkedBlock::Handle::assertMarksNotStale):
889         (JSC::MarkedBlock::isMarked):
890         (JSC::MarkedBlock::isMarkedConcurrently):
891         (JSC::MarkedBlock::testAndSetMarked):
892         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
893         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
894         (JSC::MarkedBlock::needsFlip): Deleted.
895         (JSC::MarkedBlock::assertFlipped): Deleted.
896         (JSC::MarkedBlock::Handle::assertFlipped): Deleted.
897         * heap/MarkedBlockInlines.h:
898         (JSC::MarkedBlock::Handle::isLive):
899         (JSC::MarkedBlock::Handle::isLiveCell):
900         (JSC::MarkedBlock::resetMarkingVersion):
901         (JSC::MarkedBlock::resetVersion): Deleted.
902         * heap/MarkedSpace.cpp:
903         (JSC::MarkedSpace::beginMarking):
904         * heap/MarkedSpace.h:
905         (JSC::MarkedSpace::markingVersion):
906         (JSC::MarkedSpace::version): Deleted.
907         * heap/SlotVisitor.cpp:
908         (JSC::SlotVisitor::SlotVisitor):
909         (JSC::SlotVisitor::didStartMarking):
910         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
911         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
912         (JSC::SlotVisitor::markAuxiliary):
913         * heap/SlotVisitor.h:
914         (JSC::SlotVisitor::markingVersion):
915         (JSC::SlotVisitor::version): Deleted.
916         * heap/WeakBlock.cpp:
917         (JSC::WeakBlock::specializedVisit):
918         (JSC::WeakBlock::reap):
919
920 2016-09-20  Ryan Haddad  <ryanhaddad@apple.com>
921
922         Rebaseline builtins generator tests after r206155.
923
924         Unreviewed test gardening.
925
926         * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
927
928 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
929
930         Unreviewed, fix cloop build.
931
932         * runtime/VM.h:
933
934 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
935
936         Make MarkedBlock state tracking support overlapped allocation and marking state
937         https://bugs.webkit.org/show_bug.cgi?id=161581
938
939         Reviewed by Geoffrey Garen.
940         
941         Concurrent GCs must allow for mutation and allocation during collection. We already know
942         how to mutate during collection. We have a write barrier for that. Allocation during
943         collection is more involved: the collector modifies the the mark bits, as well as other
944         kinds of MarkedBlock state, in-place during a collection. The allocator uses that same
945         MarkedBlock state to decide which regions of memory are free. This works if the allocator
946         never runs while the collector is running, but if we want to allow them to run at the same
947         time, then we need to have two versions of the state: one version built up by the
948         collector and another consumed by the allocator. We clear the collector state at the
949         beginning of collection, and splat the collector state onto the allocator state after
950         collection.
951         
952         This could be super expensive, but we can make it cheap with some cleverness. The biggest
953         observation is just that most of the state is a handful of bits per block: is the block
954         free-listed? is it completely full? completely empty? in the incremental sweeper's
955         snapshot? is it retired? is it in eden? There is also state inside blocks, like the mark
956         bits, but I have a solid plan there and I'll save it for another patch. Once we view the
957         state of blocks as bits, we can put that state into bitvectors, so that if the collector
958         needs to transform the state of some blocks, it can do it with a single operation over
959         bitvectors. I like to think of this as 32-way parallelizing block operations, since
960         doing one operation on a 32-bit word in one of those bitvectors instantly affects 32
961         blocks.
962         
963         This change converts all previous collections of MarkedBlocks, along with the MarkedBlock
964         state, into 8 bitvectors (live, empty, allocated, canAllocateButNotEmpty, eden, unswept,
965         markingNotEmpty, and markingRetired). The bitvectors separate allocator state (empty,
966         allocated, canAllocateButNotEmpty) from marking state (markingNotEmpty, markingRetired).
967         
968         As a nice side-effect of switching to bitvectors, we get size class rebalancing for free.
969         It used to be that if a MarkedAllocator had an empty block, we would only allow that
970         memory to be reused by a different MarkedAllocator if we did an incremental sweep or a
971         full eager sweep. Now we hunt down all destructorless empty blocks before allocating new
972         MarkedBlocks. It would be relatively easy to also hunt down destructor empty blocks, but
973         the theory is that those might be expensive to sweep, so it might still be better to leave
974         those to the incremental sweeper.
975         
976         This change is perf-neutral all around. I did some tests with two different kinds of
977         allocation strategies - something that is somewhat easier to do now that you can look for
978         blocks that are candidates for allocation by just scanning some bitvectors. I tried two
979         variants:
980         
981         - Allocate out of non-empty blocks first, leaving empty blocks for last in case a
982           different allocator needed them. This is sort of a best-fit strategy. I tried this
983           first, and it can be expressed as:
984           
985           m_allocationCursor = m_canAllocateButNotEmpty.findBit(m_allocationCursor, true)
986         
987         - Allocate out of lower-indexed blocks first, treating empty and canAllocateButNotEmpty
988           blocks equally. This is sort of a first-fit strategy. This is what I ended up settling
989           on, and it can be expressed as:
990           
991           m_allocationCursor = (m_canAllocateButNotEmpty | m_empty).findBit(m_allocationCursor, true)
992         
993         The best-fit strategy meant 1% regressions in LongSpider and Octane overall, and a 11%
994         regression on Octane/earley. First-fit means perf-neutrality. Most great allocators skew
995         towards first-fit because it's empirically better, so this result is not surprising.
996         
997         Overall, the performance of this patch on my machine is as follows, where "neutral" means
998         less than 1% and not statistically significant.
999         
1000         run-jsc-benchmarks:
1001             SunSpider: neutral
1002             LongSpider: 0.6% slower
1003             V8Spider: neutral
1004             Octane: neutral
1005             Kraken: neutral
1006             Microbenchmarks: 0.37% slower
1007             AsmBench: neutral
1008             CompressionBench: maybe 1% faster
1009         
1010         For browser benchmarks, I report the ratio of means (bigger / smaller) along with a T-test
1011         from Mathematica reported as % chance of not [sic] the null hypothesis. Note that we
1012         normally consider anything less than 95% confidence to be inconclusive.
1013         
1014         Browser benchmarks:
1015             PLT3: 0.3% faster with 67% confidence
1016             membuster:
1017                 Snap2FinishedLoadingPost: 0.68% more memory with 50% confidence
1018                 Snap3EndPost: 2.4% more memory with 61% confidence
1019             JetStream: 0.2% slower with 32% confidence
1020             Speedometer: 0.7% faster with 82% confidence
1021         
1022         Additionally, Octane/splay's heap capacity goes down to ~180KB from ~200KB, so about a 10%
1023         progression. This is due to the allocator rebalancing feature.
1024         
1025         Finally, this breaks --useImmortalObjects. It was already broken as far as I can tell. I
1026         filed a bug to reimplement it (bug 162296). Unless someone urgently needs this internal
1027         tool, it's probably best to reimplement it after I'm done refactoring MarkedSpace. 
1028
1029         * JavaScriptCore.xcodeproj/project.pbxproj:
1030         * debugger/Debugger.cpp:
1031         * heap/CellContainer.h:
1032         * heap/CellContainerInlines.h:
1033         (JSC::CellContainer::vm):
1034         (JSC::CellContainer::heap):
1035         (JSC::CellContainer::isMarkedOrNewlyAllocated):
1036         (JSC::CellContainer::aboutToMark):
1037         (JSC::CellContainer::isMarked): Deleted.
1038         (JSC::CellContainer::flipIfNecessary): Deleted.
1039         * heap/ConservativeRoots.cpp:
1040         * heap/Heap.cpp:
1041         (JSC::Heap::beginMarking):
1042         (JSC::Heap::endMarking):
1043         (JSC::Heap::collectAllGarbage):
1044         (JSC::Heap::collectImpl):
1045         (JSC::Heap::snapshotMarkedSpace):
1046         (JSC::Heap::prepareForAllocation):
1047         (JSC::Heap::zombifyDeadObjects):
1048         (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor): Deleted.
1049         (JSC::MarkedBlockSnapshotFunctor::operator()): Deleted.
1050         (JSC::Heap::resetAllocators): Deleted.
1051         * heap/Heap.h:
1052         * heap/HeapInlines.h:
1053         (JSC::Heap::isMarked):
1054         (JSC::Heap::isMarkedConcurrently):
1055         (JSC::Heap::testAndSetMarked):
1056         * heap/HeapStatistics.cpp:
1057         * heap/HeapUtil.h:
1058         (JSC::HeapUtil::findGCObjectPointersForMarking):
1059         (JSC::HeapUtil::isPointerGCObjectJSCell):
1060         * heap/HeapVerifier.cpp:
1061         * heap/IncrementalSweeper.cpp:
1062         (JSC::IncrementalSweeper::IncrementalSweeper):
1063         (JSC::IncrementalSweeper::doSweep):
1064         (JSC::IncrementalSweeper::sweepNextBlock):
1065         (JSC::IncrementalSweeper::startSweeping):
1066         (JSC::IncrementalSweeper::willFinishSweeping):
1067         * heap/IncrementalSweeper.h:
1068         * heap/LargeAllocation.h:
1069         (JSC::LargeAllocation::isMarked):
1070         (JSC::LargeAllocation::isMarkedConcurrently):
1071         (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
1072         (JSC::LargeAllocation::aboutToMark):
1073         (JSC::LargeAllocation::isMarkedDuringWeakVisiting): Deleted.
1074         (JSC::LargeAllocation::flipIfNecessary): Deleted.
1075         (JSC::LargeAllocation::flipIfNecessaryDuringMarking): Deleted.
1076         * heap/MarkedAllocator.cpp:
1077         (JSC::MarkedAllocator::MarkedAllocator):
1078         (JSC::MarkedAllocator::isPagedOut):
1079         (JSC::MarkedAllocator::findEmptyBlock):
1080         (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
1081         (JSC::MarkedAllocator::allocateIn):
1082         (JSC::MarkedAllocator::tryAllocateIn):
1083         (JSC::MarkedAllocator::allocateSlowCaseImpl):
1084         (JSC::MarkedAllocator::tryAllocateBlock):
1085         (JSC::MarkedAllocator::addBlock):
1086         (JSC::MarkedAllocator::removeBlock):
1087         (JSC::MarkedAllocator::stopAllocating):
1088         (JSC::MarkedAllocator::prepareForAllocation):
1089         (JSC::MarkedAllocator::lastChanceToFinalize):
1090         (JSC::MarkedAllocator::resumeAllocating):
1091         (JSC::MarkedAllocator::beginMarkingForFullCollection):
1092         (JSC::MarkedAllocator::endMarking):
1093         (JSC::MarkedAllocator::snapshotForEdenCollection):
1094         (JSC::MarkedAllocator::snapshotForFullCollection):
1095         (JSC::MarkedAllocator::findBlockToSweep):
1096         (JSC::MarkedAllocator::sweep):
1097         (JSC::MarkedAllocator::shrink):
1098         (JSC::MarkedAllocator::assertSnapshotEmpty):
1099         (JSC::MarkedAllocator::dump):
1100         (JSC::MarkedAllocator::dumpBits):
1101         (JSC::MarkedAllocator::retire): Deleted.
1102         (JSC::MarkedAllocator::filterNextBlock): Deleted.
1103         (JSC::MarkedAllocator::setNextBlockToSweep): Deleted.
1104         (JSC::MarkedAllocator::reset): Deleted.
1105         * heap/MarkedAllocator.h:
1106         (JSC::MarkedAllocator::forEachBitVector):
1107         (JSC::MarkedAllocator::forEachBitVectorWithName):
1108         (JSC::MarkedAllocator::nextAllocator):
1109         (JSC::MarkedAllocator::setNextAllocator):
1110         (JSC::MarkedAllocator::forEachBlock):
1111         (JSC::MarkedAllocator::resumeAllocating): Deleted.
1112         * heap/MarkedBlock.cpp:
1113         (JSC::MarkedBlock::tryCreate):
1114         (JSC::MarkedBlock::Handle::Handle):
1115         (JSC::MarkedBlock::Handle::~Handle):
1116         (JSC::MarkedBlock::MarkedBlock):
1117         (JSC::MarkedBlock::Handle::specializedSweep):
1118         (JSC::MarkedBlock::Handle::sweep):
1119         (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
1120         (JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode):
1121         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
1122         (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
1123         (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode):
1124         (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
1125         (JSC::MarkedBlock::Handle::setIsFreeListed):
1126         (JSC::MarkedBlock::Handle::stopAllocating):
1127         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
1128         (JSC::MarkedBlock::Handle::resumeAllocating):
1129         (JSC::MarkedBlock::aboutToMarkSlow):
1130         (JSC::MarkedBlock::clearMarks):
1131         (JSC::MarkedBlock::isMarked):
1132         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
1133         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
1134         (JSC::MarkedBlock::Handle::didConsumeFreeList):
1135         (JSC::MarkedBlock::markCount):
1136         (JSC::MarkedBlock::Handle::isEmpty):
1137         (JSC::MarkedBlock::noteMarkedSlow):
1138         (JSC::MarkedBlock::Handle::removeFromAllocator):
1139         (JSC::MarkedBlock::Handle::didAddToAllocator):
1140         (JSC::MarkedBlock::Handle::didRemoveFromAllocator):
1141         (JSC::MarkedBlock::Handle::isLive):
1142         (JSC::MarkedBlock::Handle::isLiveCell):
1143         (JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode): Deleted.
1144         (JSC::MarkedBlock::flipIfNecessary): Deleted.
1145         (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
1146         (JSC::MarkedBlock::flipIfNecessarySlow): Deleted.
1147         (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow): Deleted.
1148         (JSC::MarkedBlock::Handle::willRemoveBlock): Deleted.
1149         (WTF::printInternal): Deleted.
1150         * heap/MarkedBlock.h:
1151         (JSC::MarkedBlock::Handle::isFreeListed):
1152         (JSC::MarkedBlock::Handle::index):
1153         (JSC::MarkedBlock::aboutToMark):
1154         (JSC::MarkedBlock::isMarked):
1155         (JSC::MarkedBlock::isMarkedConcurrently):
1156         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
1157         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
1158         (JSC::MarkedBlock::Handle::isOnBlocksToSweep): Deleted.
1159         (JSC::MarkedBlock::Handle::setIsOnBlocksToSweep): Deleted.
1160         (JSC::MarkedBlock::Handle::state): Deleted.
1161         (JSC::MarkedBlock::flipIfNecessary): Deleted.
1162         (JSC::MarkedBlock::flipIfNecessaryDuringMarking): Deleted.
1163         (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
1164         (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking): Deleted.
1165         (JSC::MarkedBlock::Handle::flipForEdenCollection): Deleted.
1166         (JSC::MarkedBlock::isMarkedDuringWeakVisiting): Deleted.
1167         (JSC::MarkedBlock::Handle::isLive): Deleted.
1168         (JSC::MarkedBlock::Handle::isLiveCell): Deleted.
1169         (JSC::MarkedBlock::Handle::forEachLiveCell): Deleted.
1170         (JSC::MarkedBlock::Handle::forEachDeadCell): Deleted.
1171         (JSC::MarkedBlock::Handle::needsSweeping): Deleted.
1172         (JSC::MarkedBlock::Handle::isAllocated): Deleted.
1173         (JSC::MarkedBlock::Handle::isMarked): Deleted.
1174         * heap/MarkedBlockInlines.h: Added.
1175         (JSC::MarkedBlock::Handle::isLive):
1176         (JSC::MarkedBlock::Handle::isLiveCell):
1177         (JSC::MarkedBlock::Handle::forEachLiveCell):
1178         (JSC::MarkedBlock::Handle::forEachDeadCell):
1179         (JSC::MarkedBlock::resetVersion):
1180         * heap/MarkedSpace.cpp:
1181         (JSC::MarkedSpace::MarkedSpace):
1182         (JSC::MarkedSpace::allocate):
1183         (JSC::MarkedSpace::tryAllocate):
1184         (JSC::MarkedSpace::sweep):
1185         (JSC::MarkedSpace::prepareForAllocation):
1186         (JSC::MarkedSpace::shrink):
1187         (JSC::MarkedSpace::clearNewlyAllocated):
1188         (JSC::MarkedSpace::beginMarking):
1189         (JSC::MarkedSpace::endMarking):
1190         (JSC::MarkedSpace::didAllocateInBlock):
1191         (JSC::MarkedSpace::findEmptyBlock):
1192         (JSC::MarkedSpace::snapshot):
1193         (JSC::MarkedSpace::assertSnapshotEmpty):
1194         (JSC::MarkedSpace::dumpBits):
1195         (JSC::MarkedSpace::zombifySweep): Deleted.
1196         (JSC::MarkedSpace::resetAllocators): Deleted.
1197         (JSC::VerifyMarked::operator()): Deleted.
1198         (JSC::MarkedSpace::flip): Deleted.
1199         * heap/MarkedSpace.h:
1200         (JSC::MarkedSpace::nextVersion):
1201         (JSC::MarkedSpace::firstAllocator):
1202         (JSC::MarkedSpace::allocatorForEmptyAllocation):
1203         (JSC::MarkedSpace::forEachAllocator):
1204         (JSC::MarkedSpace::blocksWithNewObjects): Deleted.
1205         (JSC::MarkedSpace::setIsMarking): Deleted.
1206         (JSC::MarkedSpace::forEachLiveCell): Deleted.
1207         (JSC::MarkedSpace::forEachDeadCell): Deleted.
1208         * heap/MarkedSpaceInlines.h: Added.
1209         (JSC::MarkedSpace::forEachLiveCell):
1210         (JSC::MarkedSpace::forEachDeadCell):
1211         * heap/SlotVisitor.cpp:
1212         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
1213         (JSC::SlotVisitor::markAuxiliary):
1214         (JSC::SlotVisitor::visitChildren):
1215         * heap/Weak.h:
1216         (WTF::HashTraits<JSC::Weak<T>>::emptyValue):
1217         (WTF::HashTraits<JSC::Weak<T>>::peek):
1218         * heap/WeakBlock.cpp:
1219         (JSC::WeakBlock::specializedVisit):
1220         (JSC::WeakBlock::reap):
1221         * heap/WeakInlines.h:
1222         (WTF::HashTraits<JSC::Weak<T>>::emptyValue): Deleted.
1223         (WTF::HashTraits<JSC::Weak<T>>::peek): Deleted.
1224         * jit/JITThunks.h:
1225         * runtime/JSGlobalObject.cpp:
1226         * runtime/PrototypeMap.h:
1227         * runtime/SamplingProfiler.cpp:
1228         * runtime/WeakGCMap.h:
1229         * tools/JSDollarVMPrototype.cpp:
1230
1231 2016-09-20  Jonathan Bedard  <jbedard@apple.com>
1232
1233         Undefined behavior: Left shift negative number
1234         https://bugs.webkit.org/show_bug.cgi?id=161866
1235
1236         Reviewed by Keith Miller.
1237
1238         Left shifting a negative number is undefined behavior in C/C++, although most implementations do define it. Explicitly clarifying the intended behavior due to shifting negative number in some cases.
1239
1240         * dfg/DFGAbstractHeap.h:
1241         (JSC::DFG::AbstractHeap::encode): Explicitly cast signed integer for left shift.
1242
1243 2016-09-20  Saam Barati  <sbarati@apple.com>
1244
1245         Unreviewed fix for 32-bit DFG x86 implementation of HasOwnProperty.
1246
1247         Fixup phase is always setting ObjectUse on child1() of HasOwnProperty.
1248         However, on x86 32-bit, I omitted a call to speculateObject() on child1().
1249
1250         * dfg/DFGSpeculativeJIT32_64.cpp:
1251         (JSC::DFG::SpeculativeJIT::compile):
1252
1253 2016-09-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1254
1255         [JSC] Add `typeof value === "symbol"` handling to bytecode compiler
1256         https://bugs.webkit.org/show_bug.cgi?id=162253
1257
1258         Reviewed by Sam Weinig.
1259
1260         Add `typeof value === "symbol"` handling to the bytecode compiler.
1261         The effect is tiny, but it keeps consistency since the bytecode compiler
1262         already has the similar optimization for "string" case.
1263
1264         * bytecode/SpeculatedType.cpp:
1265         (JSC::speculationFromJSType):
1266         * bytecompiler/BytecodeGenerator.cpp:
1267         (JSC::BytecodeGenerator::emitEqualityOp):
1268
1269 2016-09-19  Saam Barati  <sbarati@apple.com>
1270
1271         Make HasOwnProperty faster
1272         https://bugs.webkit.org/show_bug.cgi?id=161708
1273
1274         Reviewed by Geoffrey Garen.
1275
1276         This patch adds a cache for HasOwnProperty. The cache holds tuples
1277         of {StructureID, UniquedStringImpl*, boolean} where the boolean indicates
1278         the result of performing hasOwnProperty on an object with StructureID and
1279         UniquedStringImpl*. If the cache contains an item, we can be guaranteed
1280         that it contains the same result as performing hasOwnProperty on an
1281         object O with a given structure and key. To guarantee this, we only add
1282         items into the cache when the Structure of the given item is cacheable.
1283
1284         The caching strategy is simple: when adding new items into the cache,
1285         we will evict any item that was in the location that the new item
1286         is hashed into. We also clear the cache on every GC. This strategy
1287         proves to be successful on speedometer, which sees a cache hit rate
1288         over 90%. This caching strategy is now inlined into the DFG/FTL JITs
1289         by now recognizing hasOwnProperty as an intrinsic with the corresponding
1290         HasOwnProperty node. The goal of the node is to emit inlined code for
1291         the cache lookup to prevent the overhead of the call for the common
1292         case where we get a cache hit.
1293
1294         I'm seeing around a 1% to 1.5% percent improvement on Speedometer on
1295         my machine. Hopefully the perf bots agree with my machine.
1296
1297         This patch also speeds up the microbenchmark I added by 2.5x.
1298
1299         * JavaScriptCore.xcodeproj/project.pbxproj:
1300         * dfg/DFGAbstractInterpreterInlines.h:
1301         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1302         * dfg/DFGByteCodeParser.cpp:
1303         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1304         * dfg/DFGClobberize.h:
1305         (JSC::DFG::clobberize):
1306         * dfg/DFGDoesGC.cpp:
1307         (JSC::DFG::doesGC):
1308         * dfg/DFGFixupPhase.cpp:
1309         (JSC::DFG::FixupPhase::fixupNode):
1310         * dfg/DFGNodeType.h:
1311         * dfg/DFGOperations.cpp:
1312         * dfg/DFGOperations.h:
1313         * dfg/DFGPredictionPropagationPhase.cpp:
1314         * dfg/DFGSafeToExecute.h:
1315         (JSC::DFG::safeToExecute):
1316         * dfg/DFGSpeculativeJIT.h:
1317         (JSC::DFG::SpeculativeJIT::callOperation):
1318         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
1319         * dfg/DFGSpeculativeJIT32_64.cpp:
1320         (JSC::DFG::SpeculativeJIT::compile):
1321         * dfg/DFGSpeculativeJIT64.cpp:
1322         (JSC::DFG::SpeculativeJIT::compile):
1323         * dfg/DFGValidate.cpp:
1324         * ftl/FTLAbstractHeapRepository.h:
1325         * ftl/FTLCapabilities.cpp:
1326         (JSC::FTL::canCompile):
1327         * ftl/FTLLowerDFGToB3.cpp:
1328         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1329         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
1330         * heap/Heap.cpp:
1331         (JSC::Heap::collectImpl):
1332         * jit/JITOperations.h:
1333         * runtime/HasOwnPropertyCache.h: Added.
1334         (JSC::HasOwnPropertyCache::Entry::offsetOfStructureID):
1335         (JSC::HasOwnPropertyCache::Entry::offsetOfImpl):
1336         (JSC::HasOwnPropertyCache::Entry::offsetOfResult):
1337         (JSC::HasOwnPropertyCache::operator delete):
1338         (JSC::HasOwnPropertyCache::create):
1339         (JSC::HasOwnPropertyCache::hash):
1340         (JSC::HasOwnPropertyCache::get):
1341         (JSC::HasOwnPropertyCache::tryAdd):
1342         (JSC::HasOwnPropertyCache::clear):
1343         (JSC::VM::ensureHasOwnPropertyCache):
1344         * runtime/Intrinsic.h:
1345         * runtime/JSObject.h:
1346         * runtime/JSObjectInlines.h:
1347         (JSC::JSObject::hasOwnProperty):
1348         * runtime/ObjectPrototype.cpp:
1349         (JSC::ObjectPrototype::finishCreation):
1350         (JSC::objectProtoFuncHasOwnProperty):
1351         * runtime/Symbol.h:
1352         * runtime/VM.cpp:
1353         * runtime/VM.h:
1354         (JSC::VM::hasOwnPropertyCache):
1355
1356 2016-09-19  Benjamin Poulain  <bpoulain@apple.com>
1357
1358         [JSC] Make the rounding-related nodes support any type
1359         https://bugs.webkit.org/show_bug.cgi?id=161895
1360
1361         Reviewed by Geoffrey Garen.
1362
1363         This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
1364         to support polymorphic input without exiting on entry.
1365
1366         * dfg/DFGAbstractInterpreterInlines.h:
1367         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1368         * dfg/DFGByteCodeParser.cpp:
1369         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1370         The 4 functions ignore any input past the first argument. It is okay
1371         to use the nodes with the first argument and let the Phantoms keep
1372         the remaining arguments live.
1373
1374         * dfg/DFGClobberize.h:
1375         (JSC::DFG::clobberize):
1376         * dfg/DFGFixupPhase.cpp:
1377         (JSC::DFG::FixupPhase::fixupNode):
1378         Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
1379         prevents us from picking a good type if we do not see any double.
1380
1381         * dfg/DFGNodeType.h:
1382         * dfg/DFGOperations.cpp:
1383         * dfg/DFGOperations.h:
1384         * dfg/DFGPredictionPropagationPhase.cpp:
1385         Prediction propagation of those nodes are fully determined
1386         from their flags and results's prediction. They are moved
1387         to the invariant processing.
1388
1389         * dfg/DFGSpeculativeJIT.cpp:
1390         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1391         * ftl/FTLLowerDFGToB3.cpp:
1392         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
1393         (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
1394         (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
1395         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
1396
1397 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1398
1399         Unreviewed, build fix for Win64
1400         https://bugs.webkit.org/show_bug.cgi?id=162132
1401
1402         In Windows 64bit, t3 register in LLInt is not r[a-d]x.
1403         It means that this cannot be used for byte operation.
1404
1405         * llint/LowLevelInterpreter64.asm:
1406
1407 2016-09-19  Daniel Bates  <dabates@apple.com>
1408
1409         Remove ENABLE(TEXT_AUTOSIZING) automatic text size adjustment code
1410         https://bugs.webkit.org/show_bug.cgi?id=162167
1411
1412         Reviewed by Simon Fraser.
1413
1414         * Configurations/FeatureDefines.xcconfig:
1415
1416 2016-09-19  Keith Miller  <keith_miller@apple.com>
1417
1418         Update WASM towards 0xc
1419         https://bugs.webkit.org/show_bug.cgi?id=162067
1420
1421         Reviewed by Geoffrey Garen.
1422
1423         This patch updates some of the core parts of the WASM frontend to the 0xc standard.
1424         First, it changes the section names from strings to bytecodes. It also adds support
1425         for inline block signatures. This is a change from the old version that used to have
1426         each branch indicate the arity. Finally, this patch updates all the tests and deletes
1427         a duplicate test.
1428
1429         * CMakeLists.txt:
1430         * JavaScriptCore.xcodeproj/project.pbxproj:
1431         * testWASM.cpp:
1432         (runWASMTests):
1433         * wasm/WASMB3IRGenerator.cpp:
1434         * wasm/WASMFormat.h:
1435         * wasm/WASMFunctionParser.h:
1436         (JSC::WASM::FunctionParser<Context>::FunctionParser):
1437         (JSC::WASM::FunctionParser<Context>::parseBlock):
1438         (JSC::WASM::FunctionParser<Context>::parseExpression):
1439         * wasm/WASMModuleParser.cpp:
1440         (JSC::WASM::ModuleParser::parse):
1441         * wasm/WASMSections.cpp: Removed.
1442         (JSC::WASM::Sections::lookup): Deleted.
1443         * wasm/WASMSections.h:
1444         (JSC::WASM::Sections::validateOrder):
1445
1446 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1447
1448         [JSC] Use is_cell_with_type for @isRegExpObject, @isMap, and @isSet
1449         https://bugs.webkit.org/show_bug.cgi?id=162142
1450
1451         Reviewed by Michael Saboff.
1452
1453         Use is_cell_with_type for @isRegExpObject, @isMap and @isSet.
1454         Previously, they were implemented as functions and only @isRegExpObject was handled in the DFG and FTL.
1455         The recently added op_is_cell_with_type bytecode and DFG IsCellWithType node allows us to simplify the above checks in all JIT tiers.
1456         Changed these checks to bytecode intrinsics using op_is_cell_with_type.
1457
1458         * builtins/BuiltinNames.h:
1459         * bytecode/BytecodeIntrinsicRegistry.h:
1460         * bytecode/SpeculatedType.cpp:
1461         (JSC::speculationFromJSType):
1462         * bytecompiler/BytecodeGenerator.h:
1463         (JSC::BytecodeGenerator::emitIsRegExpObject):
1464         (JSC::BytecodeGenerator::emitIsMap):
1465         (JSC::BytecodeGenerator::emitIsSet):
1466         (JSC::BytecodeGenerator::emitIsProxyObject): Deleted.
1467         * bytecompiler/NodesCodegen.cpp:
1468         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isRegExpObject):
1469         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isMap):
1470         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isSet):
1471         * dfg/DFGByteCodeParser.cpp:
1472         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1473         * runtime/ECMAScriptSpecInternalFunctions.cpp:
1474         (JSC::esSpecIsRegExpObject): Deleted.
1475         * runtime/ECMAScriptSpecInternalFunctions.h:
1476         * runtime/Intrinsic.h:
1477         * runtime/JSGlobalObject.cpp:
1478         (JSC::JSGlobalObject::init):
1479         * runtime/MapPrototype.cpp:
1480         (JSC::privateFuncIsMap): Deleted.
1481         * runtime/MapPrototype.h:
1482         * runtime/SetPrototype.cpp:
1483         (JSC::privateFuncIsSet): Deleted.
1484         * runtime/SetPrototype.h:
1485
1486 2016-09-19  Brian Burg  <bburg@apple.com>
1487
1488         Web Replay: teach the replay inputs generator to encode and decode OptionSet<T>
1489         https://bugs.webkit.org/show_bug.cgi?id=162107
1490
1491         Reviewed by Anders Carlsson.
1492
1493         Add a new type flag OPTION_SET. This means that the type is a typechecked enum class
1494         declaration, but it's stored in an OptionSet object and can contain multiple
1495         distinct enumeration values like an untyped enum declaration.
1496
1497         Do some cleanup since the generator now supports three different enumerable types:
1498         'enum', 'enum class', and 'OptionSet<T>' where T is an enum class.
1499
1500         Also clean up some sloppy variable names. Using an 'enum_' prefix is really confusing now.
1501
1502         * replay/scripts/CodeGeneratorReplayInputs.py:
1503         (Type.is_enum_declaration):
1504         (Type.is_enum_class_declaration):
1505         (Type.is_option_set):
1506         (Type):
1507         (Type.is_enumerable):
1508         When we want all enumerable types, this property includes all three variants.
1509
1510         (Type.declaration_kind): Forward-declare OptionSet's type parameter as an enum class.
1511         (VectorType.is_enum_declaration): Renamed from is_enum().
1512         (VectorType.is_enum_class_declaration): Renamed from is_enum_class().
1513         (VectorType.is_option_set): Added.
1514         (InputsModel.enumerable_types): Added.
1515         (InputsModel.parse_type_with_framework):
1516         (Generator.generate_header):
1517         (Generator.generate_implementation):
1518         (Generator.generate_includes):
1519         (Generator.generate_type_forward_declarations):
1520         (Generator.generate_enumerable_type_trait_declaration):
1521         (Generator.generate_enum_trait_declaration): Renamed.
1522         (Generator.generate_enum_trait_implementation): Renamed.
1523
1524         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
1525         Add new templates for OptionSet types. Clean up parameter names and simplify the
1526         enumerable type declaration template, which is the same for all enumerable type variants.
1527
1528         * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
1529         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
1530         (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::encodeValue):
1531         (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::decodeValue):
1532         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
1533         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
1534         Rebaseline test results.
1535
1536         * replay/scripts/tests/generate-enum-encoding-helpers.json:
1537         Add a new type for OptionSet<PlatformEvent::Modifier> to capture generated encode/decode methods.
1538
1539 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1540
1541         [JSC][LLInt] Introduce is_cell_with_type
1542         https://bugs.webkit.org/show_bug.cgi?id=162132
1543
1544         Reviewed by Sam Weinig.
1545
1546         In this patch, we introduce is_cell_with_type bytecode. This bytecode can unify the following predicates,
1547         op_is_string, op_is_jsarray, op_is_proxy_object, and op_is_derived_array!
1548         And we now drop DFG node IsString since we can use IsCellWithType instead.
1549         This automatically offers optimization to previous IsString node: dropping cell check by using CellUse edge filter.
1550
1551         Later, we are planning to use this is_cell_with_type to optimize @isRegExpObject, @isSet, and @isMap[1].
1552
1553         The performance results are neutral.
1554
1555         [1]: https://bugs.webkit.org/show_bug.cgi?id=162142
1556
1557         * bytecode/BytecodeList.json:
1558         * bytecode/BytecodeUseDef.h:
1559         (JSC::computeUsesForBytecodeOffset):
1560         (JSC::computeDefsForBytecodeOffset):
1561         * bytecode/CodeBlock.cpp:
1562         (JSC::CodeBlock::dumpBytecode):
1563         * bytecode/SpeculatedType.cpp:
1564         (JSC::speculationFromJSType):
1565         * bytecode/SpeculatedType.h:
1566         * bytecompiler/BytecodeGenerator.cpp:
1567         (JSC::BytecodeGenerator::emitEqualityOp):
1568         (JSC::BytecodeGenerator::emitIsCellWithType):
1569         * bytecompiler/BytecodeGenerator.h:
1570         (JSC::BytecodeGenerator::emitIsJSArray):
1571         (JSC::BytecodeGenerator::emitIsProxyObject):
1572         (JSC::BytecodeGenerator::emitIsDerivedArray):
1573         * dfg/DFGAbstractInterpreterInlines.h:
1574         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1575         * dfg/DFGByteCodeParser.cpp:
1576         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1577         (JSC::DFG::ByteCodeParser::parseBlock):
1578         * dfg/DFGCapabilities.cpp:
1579         (JSC::DFG::capabilityLevel):
1580         * dfg/DFGClobberize.h:
1581         (JSC::DFG::clobberize):
1582         * dfg/DFGDoesGC.cpp:
1583         (JSC::DFG::doesGC):
1584         * dfg/DFGFixupPhase.cpp:
1585         (JSC::DFG::FixupPhase::fixupNode):
1586         (JSC::DFG::FixupPhase::fixupIsCellWithType):
1587         * dfg/DFGNode.h:
1588         (JSC::DFG::Node::speculatedTypeForQuery):
1589         * dfg/DFGNodeType.h:
1590         * dfg/DFGPredictionPropagationPhase.cpp:
1591         * dfg/DFGSafeToExecute.h:
1592         (JSC::DFG::safeToExecute):
1593         * dfg/DFGSpeculativeJIT32_64.cpp:
1594         (JSC::DFG::SpeculativeJIT::compile):
1595         * dfg/DFGSpeculativeJIT64.cpp:
1596         (JSC::DFG::SpeculativeJIT::compile):
1597         * ftl/FTLCapabilities.cpp:
1598         (JSC::FTL::canCompile):
1599         * ftl/FTLLowerDFGToB3.cpp:
1600         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1601         (JSC::FTL::DFG::LowerDFGToB3::compileIsString): Deleted.
1602         * jit/JIT.cpp:
1603         (JSC::JIT::privateCompileMainPass):
1604         * jit/JIT.h:
1605         * jit/JITOpcodes.cpp:
1606         (JSC::JIT::emit_op_is_cell_with_type):
1607         (JSC::JIT::emitIsCellWithType): Deleted.
1608         (JSC::JIT::emit_op_is_string): Deleted.
1609         (JSC::JIT::emit_op_is_jsarray): Deleted.
1610         (JSC::JIT::emit_op_is_proxy_object): Deleted.
1611         (JSC::JIT::emit_op_is_derived_array): Deleted.
1612         * jit/JITOpcodes32_64.cpp:
1613         (JSC::JIT::emit_op_is_cell_with_type):
1614         (JSC::JIT::emitIsCellWithType): Deleted.
1615         (JSC::JIT::emit_op_is_string): Deleted.
1616         (JSC::JIT::emit_op_is_jsarray): Deleted.
1617         (JSC::JIT::emit_op_is_proxy_object): Deleted.
1618         (JSC::JIT::emit_op_is_derived_array): Deleted.
1619         * llint/LLIntData.cpp:
1620         (JSC::LLInt::Data::performAssertions):
1621         * llint/LowLevelInterpreter32_64.asm:
1622         * llint/LowLevelInterpreter64.asm:
1623
1624 2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1625
1626         [JSC] Assert length of LLInt opcodes using isCellWithType is 3
1627         https://bugs.webkit.org/show_bug.cgi?id=162134
1628
1629         Reviewed by Saam Barati.
1630
1631         * llint/LLIntData.cpp:
1632         (JSC::LLInt::Data::performAssertions):
1633
1634 2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1635
1636         [JSC] Do not need to use defineProperty to define methods for object literals
1637         https://bugs.webkit.org/show_bug.cgi?id=162111
1638
1639         Reviewed by Saam Barati.
1640
1641         When we receive the following code,
1642
1643             var object = { method() { } };
1644
1645         currently, we use defineProperty to define "method" function for "object".
1646         This patch replaces it with the ordinary put_by_id_direct / put_by_val_direct
1647         because the following 2 conditions are met.
1648
1649         1. While methods in classes have special attributes ({configurable: true, writable: true, enumerable: false}),
1650            the attributes of methods in object literals is just the same to the other normal properties ({configurable: true, writable: true, enumerable: true}).
1651            This means that we can use the usual put_by_id_direct / put_by_val_direct to define method properties for object literals.
1652
1653         2. Furthermore, all the own properties that can reside in objects created by object literals have {configurable: true}.
1654            So there is no need to check conflict by defineProperty. Always overwriting is OK.
1655
1656                 let name = 'method';
1657                 var object = { get [name]() { }, method() { } };
1658                 // Latter method wins.
1659
1660             On the other hand, in class syntax, conflict check is necessary since "prototype" own property is defined as {configurable: false}.
1661
1662                 class Hello { static prototype() { } }  // Should throw error by defineProperty's check.
1663
1664             This means that conflict check done in defneProperty is not necessary for object literals' properties.
1665
1666         * bytecompiler/NodesCodegen.cpp:
1667         (JSC::PropertyListNode::emitPutConstantProperty):
1668
1669 2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1670
1671         [DFG] Introduce IsCellWithType node and unify IsJSArray, IsRegExpObject and newly added IsProxyObject
1672         https://bugs.webkit.org/show_bug.cgi?id=162000
1673
1674         Reviewed by Filip Pizlo.
1675
1676         Sampling profiler tells that ES6SampleBench/Basic frequently calls Array.isArray(). This function is introduced in
1677         ES5 and it is well-used to distinguish Array from the other objects. Moreover, this function is used in Array.prototype.xxx
1678         methods as @isArray. So it's worth optimizing.
1679
1680         The difference between Array.isArray and @isJSArray is that Array.isArray need to consider about ProxyObject while
1681         @isJSArray builtin intrinsic does not. So in this patch, we leverage the existing @isJSArray to implement Array.isArray.
1682         Array.isArray is written in builtin JS code using @isJSArray and newly added @isProxyObject(). That allow us to inline
1683         Array.isArray() code and the inlined code uses existing DFG nodes well.
1684
1685         Another problem is RuntimeArray and ArrayPrototype. They inherit JSArray and their JSType is ObjectType. But Array.isArray need
1686         to return true for those types. While optimizing type checking in generic way by type display is nice, RuntimeArray and
1687         ArrayPrototype are a bit tricky and it is super rare that these functions are passed to Array.isArray(). So instead of introducing
1688         type display in this patch, we just introduce a new JSType, DerivedArrayType and use it in the above 2 use classes. Since
1689         Array.isArray is specially handled in the spec (while we don't have any Date.isDate() like functions, only Array.isArray
1690         is specified in the spec because we frequently want to distinguish Arrays from other Objects), optimizing Array.isArray specially
1691         by introducing special DerivedArrayType is reasonable.
1692
1693         In LLInt level, we add a new opcode, op_is_proxy_object and op_is_derived_array. This works similar to op_is_jsarray.
1694         And we also perform LLInt code cleanup by introducing a macro isCellWithType.
1695
1696         In baseline, we perform some clean up for op_is_proxy_object etc. Now duplicate code is reduced.
1697
1698         In DFG, we unify IsJSArray, IsRegExpObject, IsProxyObject, and IsDerivedArray into one IsCellWithType node. And we clean up
1699         some AI code related to IsJSArray and IsRegExpObject since SpeculatedType now recognizes ProxyObject. IsJSArray and IsRegExpObject
1700         does not do anything special for proxy objects.
1701
1702         The above change simplify things to create a new IsXXX DFG handling and paves the way for optimizing @isMap & @isSet in DFG.
1703         Furthermore, introducing @isProxyObject() is nice for the first step to optimize ProxyObject handling.
1704
1705         Here is microbenchmark result. We can see stable performance improvement (Even if we use Proxies!).
1706
1707                                                     baseline                  patched
1708
1709             is-array-for-array                   2.5156+-0.0288     ^      2.0668+-0.0285        ^ definitely 1.2171x faster
1710             is-array-for-mixed-case              4.7787+-0.0755     ^      4.4722+-0.0789        ^ definitely 1.0686x faster
1711             is-array-for-non-array-object        2.3596+-0.0368     ^      1.8178+-0.0262        ^ definitely 1.2980x faster
1712             is-array-for-proxy                   4.0469+-0.0437     ^      3.3845+-0.0404        ^ definitely 1.1957x faster
1713
1714         And ES6SampleBench/Basic reports 5.2% perf improvement. And now sampling result in ES6SampleBench/Basic does not pose Array.isArray.
1715
1716             Benchmark             First Iteration        Worst 2%               Steady State
1717             baseline:Basic        28.59 ms +- 1.03 ms    15.08 ms +- 0.28 ms    1656.96 ms +- 18.02 ms
1718             patched:Basic         27.82 ms +- 0.44 ms    14.59 ms +- 0.16 ms    1574.65 ms +- 8.44 ms
1719
1720         * builtins/ArrayConstructor.js:
1721         (isArray):
1722         (from): Deleted.
1723         * builtins/BuiltinNames.h:
1724         * bytecode/BytecodeIntrinsicRegistry.h:
1725         * bytecode/BytecodeList.json:
1726         * bytecode/BytecodeUseDef.h:
1727         (JSC::computeUsesForBytecodeOffset):
1728         (JSC::computeDefsForBytecodeOffset):
1729         * bytecode/CodeBlock.cpp:
1730         (JSC::CodeBlock::dumpBytecode):
1731         * bytecode/SpeculatedType.cpp:
1732         (JSC::dumpSpeculation):
1733         (JSC::speculationFromClassInfo):
1734         (JSC::speculationFromStructure):
1735         * bytecode/SpeculatedType.h:
1736         (JSC::isProxyObjectSpeculation):
1737         (JSC::isDerivedArraySpeculation):
1738         * bytecompiler/BytecodeGenerator.h:
1739         (JSC::BytecodeGenerator::emitIsProxyObject):
1740         (JSC::BytecodeGenerator::emitIsDerivedArray):
1741         (JSC::BytecodeGenerator::emitIsJSArray): Deleted.
1742         * bytecompiler/NodesCodegen.cpp:
1743         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isProxyObject):
1744         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isDerivedArray):
1745         * dfg/DFGAbstractInterpreterInlines.h:
1746         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1747         * dfg/DFGByteCodeParser.cpp:
1748         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1749         (JSC::DFG::ByteCodeParser::parseBlock):
1750         * dfg/DFGCapabilities.cpp:
1751         (JSC::DFG::capabilityLevel):
1752         * dfg/DFGClobberize.h:
1753         (JSC::DFG::clobberize):
1754         * dfg/DFGDoesGC.cpp:
1755         (JSC::DFG::doesGC):
1756         * dfg/DFGFixupPhase.cpp:
1757         (JSC::DFG::FixupPhase::fixupNode):
1758         (JSC::DFG::FixupPhase::fixupIsCellWithType):
1759         * dfg/DFGGraph.cpp:
1760         (JSC::DFG::Graph::dump):
1761         * dfg/DFGNode.h:
1762         (JSC::DFG::Node::hasQueriedType):
1763         (JSC::DFG::Node::queriedType):
1764         (JSC::DFG::Node::hasSpeculatedTypeForQuery):
1765         (JSC::DFG::Node::speculatedTypeForQuery):
1766         (JSC::DFG::Node::shouldSpeculateProxyObject):
1767         (JSC::DFG::Node::shouldSpeculateDerivedArray):
1768         (JSC::DFG::Node::loadVarargsData): Deleted.
1769         (JSC::DFG::Node::shouldSpeculateArray): Deleted.
1770         * dfg/DFGNodeType.h:
1771         * dfg/DFGPredictionPropagationPhase.cpp:
1772         * dfg/DFGSafeToExecute.h:
1773         (JSC::DFG::SafeToExecuteEdge::operator()):
1774         (JSC::DFG::safeToExecute):
1775         * dfg/DFGSpeculativeJIT.cpp:
1776         (JSC::DFG::SpeculativeJIT::compileIsCellWithType):
1777         (JSC::DFG::SpeculativeJIT::speculateProxyObject):
1778         (JSC::DFG::SpeculativeJIT::speculateDerivedArray):
1779         (JSC::DFG::SpeculativeJIT::speculate):
1780         (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
1781         (JSC::DFG::SpeculativeJIT::compileIsRegExpObject): Deleted.
1782         * dfg/DFGSpeculativeJIT.h:
1783         * dfg/DFGSpeculativeJIT32_64.cpp:
1784         (JSC::DFG::SpeculativeJIT::compile):
1785         * dfg/DFGSpeculativeJIT64.cpp:
1786         (JSC::DFG::SpeculativeJIT::compile):
1787         * dfg/DFGUseKind.cpp:
1788         (WTF::printInternal):
1789         * dfg/DFGUseKind.h:
1790         (JSC::DFG::typeFilterFor):
1791         (JSC::DFG::isCell):
1792         * ftl/FTLCapabilities.cpp:
1793         (JSC::FTL::canCompile):
1794         * ftl/FTLLowerDFGToB3.cpp:
1795         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1796         (JSC::FTL::DFG::LowerDFGToB3::compileIsCellWithType):
1797         (JSC::FTL::DFG::LowerDFGToB3::speculate):
1798         (JSC::FTL::DFG::LowerDFGToB3::isCellWithType):
1799         (JSC::FTL::DFG::LowerDFGToB3::speculateProxyObject):
1800         (JSC::FTL::DFG::LowerDFGToB3::speculateDerivedArray):
1801         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
1802         (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): Deleted.
1803         (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
1804         (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject): Deleted.
1805         * jit/JIT.cpp:
1806         (JSC::JIT::privateCompileMainPass):
1807         * jit/JIT.h:
1808         * jit/JITOpcodes.cpp:
1809         (JSC::JIT::emitIsCellWithType):
1810         (JSC::JIT::emit_op_is_string):
1811         (JSC::JIT::emit_op_is_jsarray):
1812         (JSC::JIT::emit_op_is_proxy_object):
1813         (JSC::JIT::emit_op_is_derived_array):
1814         * jit/JITOpcodes32_64.cpp:
1815         (JSC::JIT::emitIsCellWithType):
1816         (JSC::JIT::emit_op_is_string):
1817         (JSC::JIT::emit_op_is_jsarray):
1818         (JSC::JIT::emit_op_is_proxy_object):
1819         (JSC::JIT::emit_op_is_derived_array):
1820         * jsc.cpp:
1821         (WTF::RuntimeArray::createStructure):
1822         * llint/LLIntData.cpp:
1823         (JSC::LLInt::Data::performAssertions):
1824         * llint/LowLevelInterpreter.asm:
1825         * llint/LowLevelInterpreter32_64.asm:
1826         * llint/LowLevelInterpreter64.asm:
1827         * runtime/ArrayConstructor.cpp:
1828         (JSC::ArrayConstructor::finishCreation):
1829         (JSC::isArraySlowInline):
1830         (JSC::isArraySlow):
1831         (JSC::arrayConstructorPrivateFuncIsArraySlow):
1832         (JSC::arrayConstructorIsArray): Deleted.
1833         * runtime/ArrayConstructor.h:
1834         (JSC::isArray):
1835         * runtime/ArrayPrototype.h:
1836         (JSC::ArrayPrototype::createStructure):
1837         * runtime/JSArray.h:
1838         (JSC::JSArray::finishCreation):
1839         * runtime/JSGlobalObject.cpp:
1840         (JSC::JSGlobalObject::init):
1841         * runtime/JSType.h:
1842
1843 2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1844
1845         [DFG] Introduce ArrayUse
1846         https://bugs.webkit.org/show_bug.cgi?id=162063
1847
1848         Reviewed by Keith Miller.
1849
1850         ArrayUse is particularly useful: for IsJSArray.
1851         We can drop IsJSArray in fixup phase by setting ArrayUse edge filter.
1852
1853         Since @isJSArray user is limited (Array.prototype.concat), the effect of this patch is small.
1854         But later, I'll update {@isArray, Array.isArray} to use @isJSArray[1]. In that patch, we are planning
1855         to implement more aggressive optimization like, setting CellUse edge filter to avoid cell check in
1856         SpeculativeJIT::compileIsJSArray.
1857
1858         In the benchmark using Array.prototype.concat, we can see perf improvement since we can drop IsJSArray in fixup phase.
1859
1860                                                      baseline                  patched
1861
1862             lazy-array-species-watchpoints       25.0911+-0.0516     ^     24.7687+-0.0767        ^ definitely 1.0130x faster
1863
1864         [1]: https://bugs.webkit.org/show_bug.cgi?id=162000
1865
1866         * dfg/DFGFixupPhase.cpp:
1867         (JSC::DFG::FixupPhase::fixupNode):
1868         * dfg/DFGSafeToExecute.h:
1869         (JSC::DFG::SafeToExecuteEdge::operator()):
1870         * dfg/DFGSpeculativeJIT.cpp:
1871         (JSC::DFG::SpeculativeJIT::speculateArray):
1872         (JSC::DFG::SpeculativeJIT::speculate):
1873         * dfg/DFGSpeculativeJIT.h:
1874         * dfg/DFGUseKind.cpp:
1875         (WTF::printInternal):
1876         * dfg/DFGUseKind.h:
1877         (JSC::DFG::typeFilterFor):
1878         (JSC::DFG::isCell):
1879         * ftl/FTLCapabilities.cpp:
1880         (JSC::FTL::canCompile):
1881         * ftl/FTLLowerDFGToB3.cpp:
1882         (JSC::FTL::DFG::LowerDFGToB3::speculate):
1883         (JSC::FTL::DFG::LowerDFGToB3::speculateArray):
1884         (JSC::FTL::DFG::LowerDFGToB3::speculateObject): Deleted.
1885
1886 2016-09-16  Joseph Pecoraro  <pecoraro@apple.com>
1887
1888         test262: Various Constructors length properties should be configurable
1889         https://bugs.webkit.org/show_bug.cgi?id=161998
1890
1891         Reviewed by Saam Barati.
1892
1893         https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
1894         Unless otherwise specified, the length property of a built-in Function
1895         object has the attributes:
1896         { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
1897
1898         * runtime/ErrorConstructor.cpp:
1899         (JSC::ErrorConstructor::finishCreation):
1900         * runtime/JSPromiseConstructor.cpp:
1901         (JSC::JSPromiseConstructor::finishCreation):
1902         * runtime/MapConstructor.cpp:
1903         (JSC::MapConstructor::finishCreation):
1904         * runtime/NativeErrorConstructor.cpp:
1905         (JSC::NativeErrorConstructor::finishCreation):
1906         * runtime/ProxyConstructor.cpp:
1907         (JSC::ProxyConstructor::finishCreation):
1908         * runtime/SetConstructor.cpp:
1909         (JSC::SetConstructor::finishCreation):
1910         * runtime/WeakMapConstructor.cpp:
1911         (JSC::WeakMapConstructor::finishCreation):
1912         * runtime/WeakSetConstructor.cpp:
1913         (JSC::WeakSetConstructor::finishCreation):
1914
1915 2016-09-16  Youenn Fablet  <youenn@apple.com>
1916
1917         Custom promise-returning functions should not throw if callee has not the expected type
1918         https://bugs.webkit.org/show_bug.cgi?id=162011
1919
1920         Reviewed by Sam Weinig.
1921
1922         * JavaScriptCore.xcodeproj/project.pbxproj: Making JSPromiseConstructor.h private
1923
1924 2016-09-15  Filip Pizlo  <fpizlo@apple.com>
1925
1926         REGRESSION (r205462): Lot of leaks
1927         https://bugs.webkit.org/show_bug.cgi?id=161946
1928
1929         Reviewed by Saam Barati.
1930         
1931         We were forgetting to delete LargeAllocations on VM exit!
1932
1933         * heap/MarkedSpace.cpp:
1934         (JSC::MarkedSpace::~MarkedSpace):
1935
1936 2016-09-15  Keith Miller  <keith_miller@apple.com>
1937
1938
1939         Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
1940         https://bugs.webkit.org/show_bug.cgi?id=161985
1941
1942         Reviewed by Alex Christensen.
1943
1944         I started a true fix for this in
1945         https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
1946         for this issue is not sustainable. Since the scope of this issue
1947         is just limited to the static const ClassInfo member it is
1948         simpler to just pragma out this warning. This works because
1949         COMDAT will, AFAIK, pick the actual specialization.  If, in the
1950         future, we want to expose these classes to WebCore we will need to
1951         do what we do for JSGenericTypedArrayViews and create a custom
1952         info() function with a switch.
1953
1954         This patch also fixes a bunch of weak external symbols due to one of:
1955         1) out of line template member definitions functions not being marked inline.
1956         2) inline member functions definitions being marked as exported.
1957         3) missing header file includes for forward function declarations.
1958
1959         * API/JSCallbackObject.h:
1960         * b3/B3ValueInlines.h:
1961         (JSC::B3::Value::as):
1962         * runtime/HashMapImpl.cpp:
1963         (JSC::getHashMapBucketKeyClassInfo):
1964         (JSC::getHashMapBucketKeyValueClassInfo):
1965         (JSC::getHashMapImplKeyClassInfo):
1966         (JSC::getHashMapImplKeyValueClassInfo):
1967         * runtime/HashMapImpl.h:
1968         (JSC::HashMapBucket::info):
1969         (JSC::HashMapImpl::info):
1970         * runtime/JSCJSValue.h:
1971         (JSC::toUInt32): Deleted.
1972         * runtime/JSGenericTypedArrayView.h:
1973         (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
1974         * runtime/JSGenericTypedArrayViewConstructor.h:
1975         * runtime/JSGenericTypedArrayViewPrototype.h:
1976         * runtime/MathCommon.h:
1977         (JSC::toUInt32):
1978         * runtime/TypedArrayAdaptors.h:
1979         * runtime/VM.h:
1980         (JSC::VM::watchdog):
1981         (JSC::VM::heapProfiler):
1982         (JSC::VM::samplingProfiler):
1983
1984 2016-09-14  Filip Pizlo  <fpizlo@apple.com>
1985
1986         There is no good reason for WeakBlock to care about newly allocated objects
1987         https://bugs.webkit.org/show_bug.cgi?id=162006
1988
1989         Reviewed by Geoffrey Garen.
1990
1991         WeakBlock scans itself in two modes:
1992
1993         visit: if a Weak in the block belongs to an unmarked object, ask the Weak to consider whether
1994             it should do things.
1995         
1996         reap: if a Weak in a block belongs to an unmarked object, delete the Weak.
1997
1998         Except that "unmarked" has a peculiar meaning: WeakBlock defines it as
1999         !markedOrNewlyAllocated. So, a newly allocated object will never be consulted about anything. 
2000         That sounds scary until you realize that newlyAllocated must have been cleared before we even
2001         got here.
2002
2003         So, we were paying the price of checking newlyAllocated for no reason. This switches the code
2004         to using isMarked(). I don't know why the code previously checked newlyAllocated, but I do
2005         trust my reasoning.
2006
2007         * heap/LargeAllocation.h:
2008         (JSC::LargeAllocation::isMarkedDuringWeakVisiting):
2009         (JSC::LargeAllocation::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
2010         * heap/MarkedBlock.h:
2011         (JSC::MarkedBlock::isMarkedDuringWeakVisiting):
2012         (JSC::MarkedBlock::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
2013         * heap/WeakBlock.cpp:
2014         (JSC::WeakBlock::specializedVisit):
2015         (JSC::WeakBlock::reap):
2016
2017 2016-09-15  Commit Queue  <commit-queue@webkit.org>
2018
2019         Unreviewed, rolling out r205931.
2020         https://bugs.webkit.org/show_bug.cgi?id=162021
2021
2022         Tests for this change fail on 32-bit JSC bots (Requested by
2023         ryanhaddad on #webkit).
2024
2025         Reverted changeset:
2026
2027         "[JSC] Make the rounding-related nodes support any type"
2028         https://bugs.webkit.org/show_bug.cgi?id=161895
2029         http://trac.webkit.org/changeset/205931
2030
2031 2016-09-15  Joseph Pecoraro  <pecoraro@apple.com>
2032
2033         test262: Should be a SyntaxError for duplicate parameter names in function with default parameters
2034         https://bugs.webkit.org/show_bug.cgi?id=162013
2035
2036         Reviewed by Saam Barati.
2037
2038         https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-early-errors
2039         It is a Syntax Error if IsSimpleParameterList of FormalParameterList is
2040         false and BoundNames of FormalParameterList contains any duplicate elements.
2041
2042         Non-simple parameter lists include rest parameters, destructuring,
2043         and default parameters.
2044
2045         * parser/Parser.cpp:
2046         (JSC::Parser<LexerType>::parseFormalParameters):
2047         Previously, we were not failing if there were default parameters
2048         early in the parameter list that were not yet identified as duplicates
2049         and simple parameters later were duplicates. Now, we fail if there
2050         are default parameters anywhere in the parameter list with a duplicate.
2051
2052 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
2053
2054         ASSERT_NOT_REACHED when using spread inside an array literal with Function.prototype.apply
2055         https://bugs.webkit.org/show_bug.cgi?id=162003
2056
2057         Reviewed by Saam Barati.
2058
2059         * bytecompiler/NodesCodegen.cpp:
2060         (JSC::ArrayNode::isSimpleArray):
2061         Don't treat an Array that has a spread expression inside it as simple.
2062         This avoids a fast path for f.apply(x, simpleArray) that was not handling
2063         spread expressions within arrays, and instead taking a path that can
2064         handle the spreading.
2065
2066 2016-09-14  Commit Queue  <commit-queue@webkit.org>
2067
2068         Unreviewed, rolling out r205933 and r205936.
2069         https://bugs.webkit.org/show_bug.cgi?id=162002
2070
2071         broke the build (Requested by keith_miller on #webkit).
2072
2073         Reverted changesets:
2074
2075         "Pragma out undefined-var-template warnings in JSC for
2076         JSObjects that are templatized"
2077         https://bugs.webkit.org/show_bug.cgi?id=161985
2078         http://trac.webkit.org/changeset/205933
2079
2080         "Unreviewed, fix the Windows build."
2081         http://trac.webkit.org/changeset/205936
2082
2083 2016-09-14  Chris Dumez  <cdumez@apple.com>
2084
2085         REGRESSION (r205670): ASSERTION FAILED: methodTable(vm)->toThis(this, exec, NotStrictMode) == this
2086         https://bugs.webkit.org/show_bug.cgi?id=161982
2087
2088         Reviewed by Saam Barati.
2089
2090         Update JSProxy::setPrototype() to return false unconditionally instead
2091         of forwarding the call to its target. We used to forward to the target
2092         and then the JSDOMWindow's [[SetPrototypeOf]] would return false.
2093         However, the JSC tests use a different GlobalObject and forwarding
2094         the setPrototypeOf() call to the GlobalObject lead to hitting an
2095         assertion. This patch aligns the behavior of the GlobalObject used by
2096         the JSC tests with JSDOMWindow.
2097
2098         * runtime/JSProxy.cpp:
2099         (JSC::JSProxy::setPrototype):
2100
2101 2016-09-14  Michael Saboff  <msaboff@apple.com>
2102
2103         YARR doesn't check for invalid flags for literal regular expressions
2104         https://bugs.webkit.org/show_bug.cgi?id=161995
2105
2106         Reviewed by Mark Lam.
2107
2108         Added a new error and a check that the flags are valid when we create a
2109         literal regular expression.
2110
2111         * runtime/RegExp.cpp:
2112         (JSC::RegExp::finishCreation):
2113         * yarr/YarrPattern.cpp:
2114         (JSC::Yarr::YarrPattern::errorMessage):
2115         (JSC::Yarr::YarrPattern::compile):
2116         * yarr/YarrPattern.h:
2117
2118 2016-09-14  Keith Miller  <keith_miller@apple.com>
2119
2120         Unreviewed, fix the Windows build.
2121
2122         * runtime/HashMapImpl.cpp:
2123
2124 2016-09-14  Keith Miller  <keith_miller@apple.com>
2125
2126         Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
2127         https://bugs.webkit.org/show_bug.cgi?id=161985
2128
2129         Reviewed by Geoffrey Garen.
2130
2131         I started a true fix for this in
2132         https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
2133         for this issue is not sustainable. Since the scope of this issue
2134         is just limited to the static const ClassInfo member it is
2135         simpler to just pragma out this warning. This works because
2136         COMDAT will, AFAIK, pick the actual specialization.  If, in the
2137         future, we want to expose these classes to WebCore we will need to
2138         do what we do for JSGenericTypedArrayViews and create a custom
2139         info() function with a switch.
2140
2141         This patch also fixes a bunch of weak external symbols due to one of:
2142         1) out of line template member definitions functions not being marked inline.
2143         2) inline member functions definitions being marked as exported.
2144         3) missing header file includes for forward function declarations.
2145
2146         * API/JSCallbackObject.h:
2147         * b3/B3ValueInlines.h:
2148         (JSC::B3::Value::as):
2149         * runtime/HashMapImpl.h:
2150         * runtime/JSCJSValue.h:
2151         (JSC::toUInt32): Deleted.
2152         * runtime/JSGenericTypedArrayView.h:
2153         (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
2154         * runtime/JSGenericTypedArrayViewConstructor.h:
2155         * runtime/JSGenericTypedArrayViewPrototype.h:
2156         * runtime/MathCommon.h:
2157         (JSC::toUInt32):
2158         * runtime/TypedArrayAdaptors.h:
2159         * runtime/VM.h:
2160         (JSC::VM::watchdog):
2161         (JSC::VM::heapProfiler):
2162         (JSC::VM::samplingProfiler):
2163
2164 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
2165
2166         test262: TypedArray constructors length should be 3 and configurable
2167         https://bugs.webkit.org/show_bug.cgi?id=161955
2168
2169         Reviewed by Mark Lam.
2170
2171         https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
2172         Unless otherwise specified, the length property of a built-in Function
2173         object has the attributes:
2174         { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
2175
2176         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2177         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
2178
2179 2016-09-14  Benjamin Poulain  <bpoulain@apple.com>
2180
2181         [JSC] Make the rounding-related nodes support any type
2182         https://bugs.webkit.org/show_bug.cgi?id=161895
2183
2184         Reviewed by Geoffrey Garen.
2185
2186         This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
2187         to support polymorphic input without exiting on entry.
2188
2189         * dfg/DFGAbstractInterpreterInlines.h:
2190         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2191         * dfg/DFGByteCodeParser.cpp:
2192         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2193         The 4 functions ignore any input past the first argument. It is okay
2194         to use the nodes with the first argument and let the Phantoms keep
2195         the remaining arguments live.
2196
2197         * dfg/DFGClobberize.h:
2198         (JSC::DFG::clobberize):
2199         * dfg/DFGFixupPhase.cpp:
2200         (JSC::DFG::FixupPhase::fixupNode):
2201         Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
2202         prevents us from picking a good type if we do not see any double.
2203
2204         * dfg/DFGNodeType.h:
2205         * dfg/DFGOperations.cpp:
2206         * dfg/DFGOperations.h:
2207         * dfg/DFGPredictionPropagationPhase.cpp:
2208         Prediction propagation of those nodes are fully determined
2209         from their flags and results's prediction. They are moved
2210         to the invariant processing.
2211
2212         * dfg/DFGSpeculativeJIT.cpp:
2213         (JSC::DFG::SpeculativeJIT::compileArithRounding):
2214         * ftl/FTLLowerDFGToB3.cpp:
2215         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
2216         (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
2217         (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
2218         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
2219
2220 2016-09-14  Filip Pizlo  <fpizlo@apple.com>
2221
2222         Remove Heap::setMarked()
2223
2224         Rubber stamped by Keith Miller.
2225         
2226         Nobody uses this function.
2227
2228         * heap/Heap.h:
2229         * heap/HeapInlines.h:
2230         (JSC::Heap::setMarked): Deleted.
2231         * heap/LargeAllocation.h:
2232         (JSC::LargeAllocation::testAndSetMarked):
2233         (JSC::LargeAllocation::setMarked): Deleted.
2234         * heap/MarkedBlock.h:
2235
2236 2016-09-14  Mark Lam  <mark.lam@apple.com>
2237
2238         Use Options::validateExceptionChecks() instead of VM::m_verifyExceptionEvents.
2239         https://bugs.webkit.org/show_bug.cgi?id=161975
2240
2241         Reviewed by Keith Miller.
2242
2243         This makes it less burdensome (no longer needs a rebuild to enable checks) to do
2244         incremental work towards enabling checks all the time.
2245
2246         * runtime/Options.h:
2247         * runtime/VM.cpp:
2248         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
2249         * runtime/VM.h:
2250
2251 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
2252
2253         TaggedTemplateString function calls should emit tail position calls
2254         https://bugs.webkit.org/show_bug.cgi?id=161948
2255
2256         Reviewed by Yusuke Suzuki.
2257
2258         * bytecompiler/NodesCodegen.cpp:
2259         (JSC::TaggedTemplateNode::emitBytecode):
2260         The tagged template string function call can be a tail call:
2261         https://tc39.github.io/ecma262/#sec-tagged-templates-runtime-semantics-evaluation
2262
2263 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
2264
2265         test262: Array.prototype.slice should always set length
2266         https://bugs.webkit.org/show_bug.cgi?id=161953
2267
2268         Reviewed by Mark Lam.
2269
2270         * runtime/ArrayPrototype.cpp:
2271         (JSC::arrayProtoFuncSplice):
2272
2273 2016-09-13  Michael Saboff  <msaboff@apple.com>
2274
2275         Promises aren't resolved properly when making a ObjC API callback
2276         https://bugs.webkit.org/show_bug.cgi?id=161929
2277
2278         Reviewed by Geoffrey Garen.
2279
2280         When we go to call out to an Objective C function registered via the API,
2281         we first drop all JSC locks to make the call.  As part of dropping the locks,
2282         we drain the microtask queue that is used among other things for handling deferred
2283         promise resolution.  The DropAllLocks scope class that drops the locks while in
2284         scope, resets the current thread's AtomicStringTable to the default table.  This
2285         is wrong for two reasons, first it happens before we drain the microtask queue and
2286         second it isn't needed as JSLock::willReleaseLock() restores the current thread's
2287         AtomicStringTable to the table before the lock was acquired.
2288
2289         In fact, the manipulation of the current thread's AtomicStringTable is already 
2290         properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock().
2291         Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor
2292         and destructor should be removed.
2293
2294         * API/tests/testapi.mm:
2295         (testObjectiveCAPIMain): Added a new test.
2296         * runtime/JSLock.cpp:
2297         (JSC::JSLock::DropAllLocks::DropAllLocks):
2298         (JSC::JSLock::DropAllLocks::~DropAllLocks):
2299
2300 2016-09-13  Filip Pizlo  <fpizlo@apple.com>
2301
2302         Remove Heap::isLive()
2303         https://bugs.webkit.org/show_bug.cgi?id=161933
2304
2305         Reviewed by Mark Lam.
2306         
2307         Before I put any more effort into maintaining this weird function, I decided to check how it
2308         was used. It turns out it's not.
2309
2310         * heap/Heap.h:
2311         * heap/HeapInlines.h:
2312         (JSC::Heap::isLive): Deleted.
2313
2314 2016-09-13  Mark Lam  <mark.lam@apple.com>
2315
2316         DFG NewArrayBuffer node should watch for "have a bad time" state change.
2317         https://bugs.webkit.org/show_bug.cgi?id=161927
2318         <rdar://problem/27995222>
2319
2320         Reviewed by Geoffrey Garen.
2321
2322         * dfg/DFGFixupPhase.cpp:
2323         (JSC::DFG::FixupPhase::fixupNode):
2324
2325 2016-09-13  JF Bastien  <jfbastien@apple.com>
2326
2327         Support jsc shell builtin `read`
2328         https://bugs.webkit.org/show_bug.cgi?id=161662
2329
2330         Reviewed by Keith Miller.
2331
2332         The jsc shell currently supports a `readFile` method which returns
2333         a string. SpiderMonkey's js shell and V8's d8 shell both support
2334         similar file-to-string functions, as well as a
2335         binary-file-to-Uint8Array function. jsc should support a similar
2336         binary file method to simplify testing, including testing of
2337         WebAssembly blobs.
2338
2339         Emscripten's shell.js (which is also used for some WebAssembly
2340         things) has a polyfill [1] for a builtin called `read`. jsc should
2341         therefore have a builtin with the same name if we want things to
2342         "Just Work".
2343
2344           [1]: https://github.com/kripken/emscripten/blob/5f0918409a1407dd168f57cfa34b109cd1770a8a/src/shell.js#L138
2345
2346         * jsc.cpp:
2347         (GlobalObject::finishCreation): add `read`, make `readFile` take up to 2 arguments.
2348         (functionReadFile): support binary files, as per SpiderMonkey.
2349         * runtime/Error.h:
2350         (JSC::throwVMError): convenience function, I'll add more uses in a follow-up
2351         * runtime/JSTypedArrays.cpp:
2352         (JSC::createUint8TypedArray): JS private export of JSUint8Array::create.
2353         * runtime/JSTypedArrays.h: expose private export.
2354
2355 2016-09-12  Skachkov Oleksandr  <gskachkov@gmail.com>
2356
2357         ES6: Classes: Should be allowed to create a static method with name "arguments"
2358         https://bugs.webkit.org/show_bug.cgi?id=152985
2359
2360         Reviewed by Keith Miller.
2361
2362         Current patch covered 16.2 Forbidden Extensions - first topic 
2363         (https://tc39.github.io/ecma262/#sec-forbidden-extensions) ECMAScript Functions 
2364         should not have own properties named "caller" or "arguments".
2365         Also added possibility to declare static methods and getters with 
2366         name 'arguments' and 'caller' for classes. i.e.:
2367         class A { static arguments() { return 'value'; } }
2368         A.arguments() === 'value';
2369         To implement this patch 'caller' and 'arguments' were put to the FunctionPrototype
2370         object. Also was changed approach to init throwTypeErrorArgumentsCalleeAndCallerGetterSetter
2371         property from Lazy to common because it necessary to use execState during init of the accessors 
2372         properties.
2373
2374         * runtime/Executable.h:
2375         * runtime/FunctionPrototype.cpp:
2376         (JSC::FunctionPrototype::initRestrictedProperties):
2377         (JSC::FunctionPrototype::addFunctionProperties): Deleted.
2378         * runtime/FunctionPrototype.h:
2379         * runtime/JSFunction.cpp:
2380         (JSC::JSFunction::getOwnPropertySlot):
2381         (JSC::JSFunction::getOwnNonIndexPropertyNames):
2382         (JSC::JSFunction::put):
2383         (JSC::JSFunction::deleteProperty):
2384         (JSC::JSFunction::defineOwnProperty):
2385         * runtime/JSGlobalObject.cpp:
2386         (JSC::JSGlobalObject::init):
2387         (JSC::JSGlobalObject::visitChildren):
2388         * runtime/JSGlobalObject.h:
2389         (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):
2390
2391 2016-09-12  Filip Pizlo  <fpizlo@apple.com>
2392
2393         MarkedBlock should be able to use flipIfNecessary() as the "I'm not empty" trigger
2394         https://bugs.webkit.org/show_bug.cgi?id=161869
2395
2396         Reviewed by Saam Barati.
2397         
2398         In bug 161581, I'm going to use flipIfNecessary() during marking to trigger the "I'm not
2399         empty" hook, which will set a bit in the markingNotEmpty bitvector.
2400         
2401         For this to work, we need to ensure that nobody else uses flipIfNecessary() during marking.
2402         If anyone else does it but they aren't marking new objects, then this prevents
2403         flipIfNecessary() from triggering when the first object is marked, which means we won't
2404         always detect when a block became non-empty.
2405         
2406         I addressed this by adding a isMarking flag, and asserting in flipIfNecessary() that the flag
2407         isn't set. flipIfNecessaryDuringMarking() is used only on the marking path, so that code
2408         knows that it can trigger something like noteMarked(). The only places that were using
2409         flipIfNecessary() should have been using needsFlip() anyway.
2410
2411         * heap/CellContainer.h:
2412         * heap/CellContainerInlines.h:
2413         (JSC::CellContainer::needsFlip):
2414         * heap/Heap.cpp:
2415         (JSC::Heap::markRoots):
2416         (JSC::Heap::beginMarking):
2417         (JSC::Heap::endMarking):
2418         (JSC::Heap::clearLivenessData): Deleted.
2419         (JSC::Heap::converge): Deleted.
2420         (JSC::Heap::resetVisitors): Deleted.
2421         * heap/Heap.h:
2422         * heap/HeapInlines.h:
2423         (JSC::Heap::testAndSetMarked):
2424         * heap/LargeAllocation.h:
2425         (JSC::LargeAllocation::flipIfNecessaryDuringMarking):
2426         (JSC::LargeAllocation::flipIfNecessaryConcurrently): Deleted.
2427         * heap/MarkedBlock.cpp:
2428         (JSC::MarkedBlock::flipIfNecessarySlow):
2429         (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow):
2430         (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow): Deleted.
2431         * heap/MarkedBlock.h:
2432         (JSC::MarkedBlock::flipIfNecessaryDuringMarking):
2433         (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking):
2434         (JSC::MarkedBlock::flipIfNecessaryConcurrently): Deleted.
2435         (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently): Deleted.
2436         * heap/MarkedSpace.h:
2437         (JSC::MarkedSpace::isMarking):
2438         (JSC::MarkedSpace::setIsMarking):
2439         (JSC::MarkedSpace::largeAllocationsForThisCollectionSize): Deleted.
2440         * heap/SlotVisitor.cpp:
2441         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
2442         * heap/WeakBlock.cpp:
2443         (JSC::WeakBlock::visit):
2444
2445 2016-09-12  Saam Barati  <sbarati@apple.com>
2446
2447         HashMapImpl should take into account m_deleteCount in its load factor and it should be able to rehash the table to be smaller
2448         https://bugs.webkit.org/show_bug.cgi?id=161640
2449
2450         Reviewed by Geoffrey Garen.
2451
2452         HashMapImpl now takes into account m_deleteCount in its load factor.
2453         It now knows how to rehash to either decrease its capacity, stay at
2454         the same capacity, or increase its capacity. The reason we can sometimes
2455         stay at the same capacity is that we can reduce the load factor enough
2456         by rehashing that growing isn't warranted. The reason for this is that
2457         anytime we rehash, we remove all deleted sentinels from the buffer.
2458         Therefore, staying at the same same capacity, when there are deleted entries,
2459         can still reduce the load factor because it removes all deleted sentinels.
2460
2461         * runtime/HashMapImpl.h:
2462         (JSC::HashMapBuffer::create):
2463         (JSC::HashMapBuffer::reset):
2464         (JSC::HashMapImpl::HashMapImpl):
2465         (JSC::HashMapImpl::add):
2466         (JSC::HashMapImpl::remove):
2467         (JSC::HashMapImpl::size):
2468         (JSC::HashMapImpl::clear):
2469         (JSC::HashMapImpl::approximateSize):
2470         (JSC::HashMapImpl::shouldRehashAfterAdd):
2471         (JSC::HashMapImpl::shouldShrink):
2472         (JSC::HashMapImpl::rehash):
2473         (JSC::HashMapImpl::checkConsistency):
2474         (JSC::HashMapImpl::makeAndSetNewBuffer):
2475         (JSC::HashMapImpl::assertBufferIsEmpty):
2476
2477 2016-09-12  Benjamin Poulain  <bpoulain@apple.com>
2478
2479         [JSC] Use GetArrayLength for JSArray.length even when the array type is undecided
2480         https://bugs.webkit.org/show_bug.cgi?id=161671
2481
2482         Reviewed by Geoffrey Garen.
2483
2484         UndecidedShape is a type with storage. When we allocate an uninitialized JSArray,
2485         it gets a butterfly with its length.
2486         When we were querying that length, we were generating a generic GetById with inline cache.
2487
2488         This patch adds the missing bits to treat Undecided like the other types with storage.
2489
2490         * dfg/DFGArrayMode.cpp:
2491         (JSC::DFG::canBecomeGetArrayLength):
2492         (JSC::DFG::ArrayMode::refine):
2493         * dfg/DFGArrayMode.h:
2494         (JSC::DFG::ArrayMode::usesButterfly):
2495         (JSC::DFG::ArrayMode::lengthNeedsStorage):
2496         * dfg/DFGClobberize.h:
2497         (JSC::DFG::clobberize):
2498         * dfg/DFGFixupPhase.cpp:
2499         (JSC::DFG::FixupPhase::checkArray):
2500         * dfg/DFGSpeculativeJIT.cpp:
2501         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2502         * ftl/FTLCapabilities.cpp:
2503         (JSC::FTL::canCompile):
2504         * ftl/FTLLowerDFGToB3.cpp:
2505         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
2506
2507 2016-09-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2508
2509         [DFG][FTL] Add ArithTan
2510         https://bugs.webkit.org/show_bug.cgi?id=161857
2511
2512         Reviewed by Filip Pizlo.
2513
2514         While ArithSin and ArithCos are supported, ArithTan is not supported yet.
2515         And we also find that Math.tan is included in MotionMark's Multiply benchmark.
2516
2517         This patch adds ArithTan support in DFG and FTL. And it also cleans up the
2518         existing ArithSin, ArithCos, and ArithLog compilations by unifying them.
2519         The microbenchmark shows the 9% perf improvement.
2520
2521             tan    322.4819+-0.3766     ^    295.8700+-0.3094        ^ definitely 1.0899x faster
2522
2523         * dfg/DFGAbstractInterpreterInlines.h:
2524         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2525         * dfg/DFGByteCodeParser.cpp:
2526         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2527         * dfg/DFGClobberize.h:
2528         (JSC::DFG::clobberize):
2529         * dfg/DFGDoesGC.cpp:
2530         (JSC::DFG::doesGC):
2531         * dfg/DFGFixupPhase.cpp:
2532         (JSC::DFG::FixupPhase::fixupNode):
2533         * dfg/DFGNodeType.h:
2534         * dfg/DFGOperations.cpp:
2535         * dfg/DFGOperations.h:
2536         * dfg/DFGPredictionPropagationPhase.cpp:
2537         * dfg/DFGSafeToExecute.h:
2538         (JSC::DFG::safeToExecute):
2539         * dfg/DFGSpeculativeJIT.cpp:
2540         (JSC::DFG::SpeculativeJIT::compileArithDoubleUnaryOp):
2541         (JSC::DFG::SpeculativeJIT::compileArithCos):
2542         (JSC::DFG::SpeculativeJIT::compileArithTan):
2543         (JSC::DFG::SpeculativeJIT::compileArithSin):
2544         (JSC::DFG::SpeculativeJIT::compileArithLog):
2545         * dfg/DFGSpeculativeJIT.h:
2546         * dfg/DFGSpeculativeJIT32_64.cpp:
2547         (JSC::DFG::SpeculativeJIT::compile):
2548         * dfg/DFGSpeculativeJIT64.cpp:
2549         (JSC::DFG::SpeculativeJIT::compile):
2550         * ftl/FTLCapabilities.cpp:
2551         (JSC::FTL::canCompile):
2552         * ftl/FTLLowerDFGToB3.cpp:
2553         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2554         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan):
2555         * ftl/FTLOutput.cpp:
2556         (JSC::FTL::Output::doubleTan):
2557         * ftl/FTLOutput.h:
2558         * runtime/Intrinsic.h:
2559         * runtime/MathObject.cpp:
2560         (JSC::MathObject::finishCreation):
2561
2562 2016-09-12  Saam Barati  <sbarati@apple.com>
2563
2564         MapHash should do constant folding when it has a constant argument and its legal to hash that value
2565         https://bugs.webkit.org/show_bug.cgi?id=161639
2566
2567         Reviewed by Filip Pizlo.
2568
2569         We now constant fold the MapHash node. We're careful to not resolve
2570         ropes from the compiler thread, and to only hash strings if they're
2571         not too large. The microbenchmark I added runs about 12% faster with
2572         this patch.
2573
2574         * dfg/DFGAbstractInterpreterInlines.h:
2575         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2576         * runtime/HashMapImpl.h:
2577         (JSC::wangsInt64Hash):
2578         (JSC::jsMapHash):
2579         (JSC::concurrentJSMapHash):
2580
2581 2016-09-11  Filip Pizlo  <fpizlo@apple.com>
2582
2583         DFG::forAllKilledOperands() could use a faster bitvector scan in the same-inline-stack fast path
2584         https://bugs.webkit.org/show_bug.cgi?id=161849
2585
2586         Reviewed by Saam Barati.
2587         
2588         This is a fairly obvious change. This turns a loop that would query each bit individually
2589         into a loop that will process a word at a time. I would expect a very tiny progression in
2590         DFG compile times.
2591         
2592         This also gave me an opportunity to test and fix the new FastBitVector functionality.
2593
2594         * dfg/DFGForAllKills.h:
2595         (JSC::DFG::forAllKilledOperands):
2596
2597 2016-09-11  Filip Pizlo  <fpizlo@apple.com>
2598
2599         FastBitVector should have efficient and easy-to-use vector-vector operations
2600         https://bugs.webkit.org/show_bug.cgi?id=161847
2601
2602         Reviewed by Saam Barati.
2603         
2604         Adapt existing users of FastBitVector to the new API.
2605
2606         * bytecode/BytecodeLivenessAnalysis.cpp:
2607         (JSC::BytecodeLivenessAnalysis::computeKills):
2608         (JSC::BytecodeLivenessAnalysis::dumpResults):
2609         * bytecode/BytecodeLivenessAnalysisInlines.h:
2610         (JSC::operandThatIsNotAlwaysLiveIsLive):
2611         (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
2612         (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint):
2613         * bytecode/CodeBlock.cpp:
2614         (JSC::CodeBlock::validate):
2615         * dfg/DFGByteCodeParser.cpp:
2616         (JSC::DFG::ByteCodeParser::flushForTerminal):
2617         * dfg/DFGForAllKills.h:
2618         (JSC::DFG::forAllKilledOperands):
2619         * dfg/DFGGraph.h:
2620         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2621         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2622         (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException):
2623         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
2624         * dfg/DFGNaturalLoops.cpp:
2625         (JSC::DFG::NaturalLoops::NaturalLoops):
2626         * dfg/DFGPlan.cpp:
2627         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
2628
2629 2016-09-10  Chris Dumez  <cdumez@apple.com>
2630
2631         parseHTMLInteger() should take a StringView in parameter
2632         https://bugs.webkit.org/show_bug.cgi?id=161669
2633
2634         Reviewed by Ryosuke Niwa.
2635
2636         * runtime/DateConversion.cpp:
2637         (JSC::formatDateTime):
2638         Explicitly construct a String from the const WCHAR* on Windows because
2639         it is ambiguous otherwise now that there is a StringBuilder::append()
2640         overload taking an AtomicString in.
2641
2642 2016-09-08  Keith Miller  <keith_miller@apple.com>
2643
2644         WASM should support if-then-else
2645         https://bugs.webkit.org/show_bug.cgi?id=161778
2646
2647         Reviewed by Michael Saboff.
2648
2649         This patch makes some major changes to the way that the WASM
2650         function parser works. First, the control stack has been moved
2651         from the parser's context to the parser itself. This simplifies
2652         the way that the parser works and allows us to make the decoder
2653         iterative rather than recursive. Since the control stack has been
2654         moved to the parser, any context operation that refers to some
2655         block now receives that block by reference.
2656
2657         For any if block, regardless of whether or not it is an
2658         if-then-else or not, we will allocate both the entire control flow
2659         diamond. This is not a major issue in the if-then case since B3
2660         will immediately cleanup these blocks. In order to support if-then
2661         and if-then-else we needed to be able to distinguish what the type
2662         of the top block on the control stack is. This will be necessary
2663         when validating the else opcode in the future. In the B3 IR
2664         generator we decide to the type of the block strictly by the
2665         shape.
2666
2667         Currently, if blocks don't handle passed and returned stack values
2668         correctly. I plan to fix this when I add support for the block
2669         signatures. See: https://github.com/WebAssembly/design/pull/765
2670
2671         * testWASM.cpp:
2672         (runWASMTests):
2673         * wasm/WASMB3IRGenerator.cpp:
2674         (dumpProcedure):
2675         (JSC::WASM::parseAndCompile):
2676         * wasm/WASMB3IRGenerator.h:
2677         * wasm/WASMFunctionParser.h:
2678         (JSC::WASM::FunctionParser<Context>::parseBlock):
2679         (JSC::WASM::FunctionParser<Context>::parseExpression):
2680         (JSC::WASM::FunctionParser<Context>::parseUnreachableExpression):
2681         * wasm/WASMOps.h:
2682
2683 2016-09-09  Filip Pizlo  <fpizlo@apple.com>
2684
2685         jsc.cpp should call initializeMainThread() to make sure that GC thread assertions work
2686         https://bugs.webkit.org/show_bug.cgi?id=161801
2687
2688         Reviewed by Keith Miller.
2689         
2690         The GC has debug assertions that certain things don't happen on GC threads. Those assertions
2691         are no-ops unless initializeGCThreads() is called, and I think the most canonical way to do
2692         that is to call initializeMainThread().
2693
2694         * jsc.cpp:
2695         (jscmain):
2696
2697 2016-09-09  Saam Barati  <sbarati@apple.com>
2698
2699         Make hasOwnProperty ALWAYS_INLINE
2700         https://bugs.webkit.org/show_bug.cgi?id=161775
2701
2702         Reviewed by Ryosuke Niwa.
2703
2704         Speedometer spends around 2.5% of its time in hasOwnProperty.
2705         Let's reduce the overhead of calling that function by marking
2706         it as inline. Also, it's likely that the function will call into
2707         JSObject::getOwnPropertySlot. I added a check to see if that's
2708         the function we're calling, if it is, we do a direct call instead
2709         of an indirect call.
2710
2711         * runtime/JSObject.cpp:
2712         (JSC::JSObject::hasOwnProperty): Deleted.
2713         * runtime/JSObjectInlines.h:
2714         (JSC::JSObject::hasOwnProperty):
2715
2716 2016-09-09  Filip Pizlo  <fpizlo@apple.com>
2717
2718         HashMapImpl needs to m_buffer.clear() in its constructor
2719         https://bugs.webkit.org/show_bug.cgi?id=161796
2720
2721         Reviewed by Keith Miller.
2722         
2723         This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize
2724         itself. That seemed like a good idea because maybe sometimes the user knows better how to
2725         initialize it. But, it's not worth it if it's a constant source of bugs.
2726         
2727         So, I'm fixing it for good by making AuxiliaryBarrier::AuxiliaryBarrier() initialize its
2728         m_value.
2729
2730         * runtime/AuxiliaryBarrier.h:
2731         (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
2732         * runtime/DirectArguments.cpp:
2733         (JSC::DirectArguments::DirectArguments):
2734
2735 2016-09-09  Youenn Fablet  <youenn@apple.com>
2736
2737         ASSERTION FAILED: promise.inherits(JSPromise::info())
2738         https://bugs.webkit.org/show_bug.cgi?id=161632
2739         <rdar://problem/28184743>
2740
2741         Reviewed by Mark Lam.
2742
2743         * runtime/JSPromiseDeferred.cpp:
2744         (JSC::JSPromiseDeferred::create): Returning null if promise object is not created.
2745
2746 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2747
2748         Heap::isMarked() shouldn't pay the price of concurrent lazy flipping
2749         https://bugs.webkit.org/show_bug.cgi?id=161760
2750
2751         Reviewed by Mark Lam.
2752         
2753         To fix a race condition in marking, I made Heap::isMarked() and Heap::isLive() atomic by
2754         using flipIfNecessaryConcurrently() instead of flipIfNecessary().
2755         
2756         This introduces three unnecessary overheads:
2757         
2758         - isLive() is not called by marking, so that change was not necessary.
2759         
2760         - isMarked() gets calls many times outside of marking, so it shouldn't always do the
2761           concurrent thing. This adds isMarkedConcurrently() for use in marking, and reverts
2762           isMarked().
2763         
2764         - isMarked() and isMarkedConcurrently() don't actually have to do the lazy flip. They can
2765           return false if the flip is necessary.
2766         
2767         I added a bunch of debug assertions to make sure that isLive() and isMarked() are not called
2768         during marking.
2769         
2770         If we needed to, we could remove most of the calls to isMarkedConcurrently(). As a kind of
2771         optimization, CodeBlock does an initial fixpoint iteration during marking, and so all of the
2772         code called from CodeBlock's fixpoint iterator needs to use isMarkedConcurrently(). But we
2773         could probably arrange for CodeBlock only do fixpoint iterating during the weak reference
2774         thing.
2775
2776         * bytecode/CodeBlock.cpp:
2777         (JSC::CodeBlock::visitWeakly):
2778         (JSC::CodeBlock::shouldJettisonDueToOldAge):
2779         (JSC::shouldMarkTransition):
2780         (JSC::CodeBlock::propagateTransitions):
2781         (JSC::CodeBlock::determineLiveness):
2782         * bytecode/PolymorphicAccess.cpp:
2783         (JSC::AccessCase::propagateTransitions):
2784         * heap/Heap.h:
2785         * heap/HeapInlines.h:
2786         (JSC::Heap::isLive):
2787         (JSC::Heap::isMarked):
2788         (JSC::Heap::isMarkedConcurrently):
2789         * heap/MarkedBlock.cpp:
2790         (JSC::MarkedBlock::flipIfNecessarySlow):
2791         (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
2792         (JSC::MarkedBlock::needsFlip):
2793         * heap/MarkedBlock.h:
2794         (JSC::MarkedBlock::needsFlip):
2795         (JSC::MarkedBlock::flipIfNecessary):
2796         (JSC::MarkedBlock::flipIfNecessaryConcurrently):
2797         * heap/SlotVisitor.cpp:
2798         (JSC::SlotVisitor::appendToMarkStack):
2799         (JSC::SlotVisitor::markAuxiliary):
2800         (JSC::SlotVisitor::visitChildren):
2801         * runtime/Structure.cpp:
2802         (JSC::Structure::isCheapDuringGC):
2803         (JSC::Structure::markIfCheap):
2804
2805 2016-09-08  Saam Barati  <sbarati@apple.com>
2806
2807         We should inline operationConvertJSValueToBoolean into JIT code
2808         https://bugs.webkit.org/show_bug.cgi?id=161729
2809
2810         Reviewed by Filip Pizlo.
2811
2812         This patch introduces an AssemblyHelpers emitter function
2813         that replaces operationConvertJSValueToBoolean. This operation
2814         was showing up when I was doing performance analysis for the
2815         speedometer benchmark. I saw that it was spending about 1% of
2816         its time in this function. Hopefully this patch can help us speedup
2817         up speedometer by a little bit.
2818
2819         * dfg/DFGSpeculativeJIT32_64.cpp:
2820         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2821         (JSC::DFG::SpeculativeJIT::emitBranch):
2822         * dfg/DFGSpeculativeJIT64.cpp:
2823         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2824         (JSC::DFG::SpeculativeJIT::emitBranch):
2825         * jit/AssemblyHelpers.cpp:
2826         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
2827         * jit/AssemblyHelpers.h:
2828         (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted.
2829         * jit/JIT.cpp:
2830         (JSC::JIT::privateCompileSlowCases):
2831         * jit/JIT.h:
2832         * jit/JITOpcodes.cpp:
2833         (JSC::JIT::emit_op_jfalse):
2834         (JSC::JIT::emit_op_jtrue):
2835         (JSC::JIT::emitSlow_op_jfalse): Deleted.
2836         (JSC::JIT::emitSlow_op_jtrue): Deleted.
2837         * jit/JITOpcodes32_64.cpp:
2838         (JSC::JIT::emit_op_jfalse):
2839         (JSC::JIT::emit_op_jtrue):
2840         (JSC::JIT::emitSlow_op_jfalse): Deleted.
2841         (JSC::JIT::emitSlow_op_jtrue): Deleted.
2842         * jit/JITOperations.cpp:
2843         * jit/JITOperations.h:
2844
2845 2016-09-08  Chris Dumez  <cdumez@apple.com>
2846
2847         Align proto getter / setter behavior with other browsers
2848         https://bugs.webkit.org/show_bug.cgi?id=161455
2849
2850         Reviewed by Saam Barati.
2851
2852         Drop allowsAccessFrom from the methodTable and delegate cross-origin
2853         checking to the DOM bindings for [[SetPrototypeOf]] / [[GetPrototypeOf]].
2854         This is more consistent with other operations (e.g. [[GetOwnProperty]]).
2855
2856         * jsc.cpp:
2857         * runtime/JSGlobalObject.cpp:
2858         * runtime/JSGlobalObject.h:
2859         * runtime/JSGlobalObjectFunctions.cpp:
2860         (JSC::globalFuncProtoGetter):
2861         (JSC::globalFuncProtoSetter):
2862         (JSC::globalFuncBuiltinLog): Deleted.
2863         * runtime/JSGlobalObjectFunctions.h:
2864         * runtime/JSObject.cpp:
2865         (JSC::JSObject::setPrototypeWithCycleCheck):
2866         Remove check added in r197648. This check was added to match
2867         the latest EcmaScript spec:
2868         - https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof (step 8)
2869         This check allowed for [[Prototype]] chain cycles if the prototype
2870         chain includes objects that do not use the ordinary object definitions
2871         for [[GetPrototypeOf]] and [[SetPrototypeOf]].
2872         The issue is that the rest of our code base does not properly handle
2873         such cycles and we can end up in infinite loops. This became obvious
2874         because this patch updates Window / Location so that they no longer
2875         use the default [[GetPrototypeOf]] / [[SetPrototypeOf]]. If I do not
2876         remove this check, I get an infinite loop in
2877         Structure::anyObjectInChainMayInterceptIndexedAccesses(), which is
2878         called from JSObject::setPrototypeDirect(), when running the following
2879         layout test:
2880         - html/browsers/history/the-location-interface/allow_prototype_cycle_through_location.sub.html
2881         I filed https://bugs.webkit.org/show_bug.cgi?id=161534 to track this
2882         issue.
2883
2884         * runtime/JSObject.h:
2885         (JSC::JSObject::getArrayLength): Deleted.
2886         * runtime/JSProxy.cpp:
2887         (JSC::JSProxy::setPrototype):
2888         (JSC::JSProxy::getPrototype):
2889         * runtime/JSProxy.h:
2890         * runtime/ObjectConstructor.cpp:
2891         (JSC::objectConstructorGetPrototypeOf):
2892         (JSC::objectConstructorSetPrototypeOf):
2893         (JSC::objectConstructorGetOwnPropertyDescriptor): Deleted.
2894         (JSC::objectConstructorGetOwnPropertyDescriptors): Deleted.
2895         * runtime/ObjectConstructor.h:
2896         * runtime/ReflectObject.cpp:
2897         (JSC::reflectObjectGetPrototypeOf):
2898         (JSC::reflectObjectSetPrototypeOf):
2899
2900 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2901
2902         Remove CopiedSpace and use MarkedSpace instead
2903         https://bugs.webkit.org/show_bug.cgi?id=159658
2904
2905         Reviewed by Keith Miller.
2906         
2907         This removes the final client of CopiedSpace, the overrides array of DirectArguments. That
2908         is a simple change.
2909         
2910         Then this stubs out some remaining internal debugging code that referenced CopiedSpace in
2911         JSDollarVM and HeapVerifier. I filed FIXMEs to restore that debugging functionality.
2912         
2913         The rest of this patch is deleting CopiedSpace.
2914
2915         * API/JSObjectRef.cpp:
2916         * CMakeLists.txt:
2917         * JavaScriptCore.xcodeproj/project.pbxproj:
2918         * dfg/DFGOperations.cpp:
2919         * heap/ConservativeRoots.cpp:
2920         (JSC::ConservativeRoots::genericAddPointer):
2921         * heap/CopiedAllocator.h: Removed.
2922         * heap/CopiedBlock.cpp: Removed.
2923         * heap/CopiedBlock.h: Removed.
2924         * heap/CopiedBlockInlines.h: Removed.
2925         * heap/CopiedSpace.cpp: Removed.
2926         * heap/CopiedSpace.h: Removed.
2927         * heap/CopiedSpaceInlines.h: Removed.
2928         * heap/CopyBarrier.h: Removed.
2929         * heap/CopyToken.h: Removed.
2930         * heap/CopyVisitor.cpp: Removed.
2931         * heap/CopyVisitor.h: Removed.
2932         * heap/CopyVisitorInlines.h: Removed.
2933         * heap/CopyWorkList.h: Removed.
2934         * heap/Heap.cpp:
2935         (JSC::Heap::Heap):
2936         (JSC::Heap::isPagedOut):
2937         (JSC::Heap::updateObjectCounts):
2938         (JSC::Heap::size):
2939         (JSC::Heap::capacity):
2940         (JSC::Heap::collectImpl):
2941         (JSC::Heap::stopAllocation):
2942         (JSC::Heap::updateAllocationLimits):
2943         (JSC::Heap::copyBackingStores): Deleted.
2944         (JSC::Heap::threadBytesCopied): Deleted.
2945         * heap/Heap.h:
2946         (JSC::Heap::objectSpace):
2947         (JSC::Heap::allocatorForAuxiliaryData):
2948         (JSC::Heap::storageSpace): Deleted.
2949         (JSC::Heap::storageAllocator): Deleted.
2950         * heap/HeapCellInlines.h:
2951         * heap/HeapInlines.h:
2952         (JSC::Heap::tryAllocateStorage): Deleted.
2953         (JSC::Heap::tryReallocateStorage): Deleted.
2954         * heap/HeapVerifier.cpp:
2955         (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
2956         (JSC::HeapVerifier::reportObject):
2957         (JSC::getButterflyDetails): Deleted.
2958         * heap/SlotVisitor.cpp:
2959         (JSC::SlotVisitor::copyLater): Deleted.
2960         * heap/SlotVisitor.h:
2961         * jit/AssemblyHelpers.h:
2962         * jit/JITOpcodes.cpp:
2963         * jsc.cpp:
2964         * runtime/ArrayConstructor.cpp:
2965         * runtime/ArrayPrototype.cpp:
2966         * runtime/Butterfly.h:
2967         * runtime/ButterflyInlines.h:
2968         (JSC::Butterfly::createUninitializedDuringCollection): Deleted.
2969         * runtime/ClassInfo.h:
2970         * runtime/DirectArguments.cpp:
2971         (JSC::DirectArguments::visitChildren):
2972         (JSC::DirectArguments::overrideThings):
2973         (JSC::DirectArguments::copyBackingStore): Deleted.
2974         * runtime/DirectArguments.h:
2975         * runtime/JSArray.cpp:
2976         * runtime/JSCell.cpp:
2977         (JSC::JSCell::copyBackingStore): Deleted.
2978         * runtime/JSCell.h:
2979         * runtime/JSLexicalEnvironment.h:
2980         * runtime/JSObject.cpp:
2981         * runtime/JSTypedArrays.cpp:
2982         * runtime/LiteralParser.cpp:
2983         * runtime/ObjectConstructor.cpp:
2984         * runtime/RegExpObject.cpp:
2985         * runtime/StringPrototype.cpp:
2986         * runtime/WeakMapData.cpp:
2987         * tools/JSDollarVMPrototype.cpp:
2988         (JSC::JSDollarVMPrototype::isInStorageSpace):
2989
2990 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2991
2992         Heap version should be 32-bit
2993         https://bugs.webkit.org/show_bug.cgi?id=161751
2994
2995         Reviewed by Mark Lam.
2996         
2997         32-bit devices are probably getting hurt by the 64-bit version number. The reason why I made
2998         it 64-bit initially is so that I wouldn't have to worry about wrap-around. But wrap-around is
2999         easy to handle.
3000
3001         * heap/CellContainer.h:
3002         * heap/CellContainerInlines.h:
3003         (JSC::CellContainer::flipIfNecessary):
3004         * heap/ConservativeRoots.cpp:
3005         (JSC::ConservativeRoots::genericAddPointer):
3006         (JSC::ConservativeRoots::genericAddSpan):
3007         * heap/ConservativeRoots.h:
3008         * heap/Heap.h:
3009         * heap/HeapInlines.h:
3010         (JSC::Heap::testAndSetMarked):
3011         * heap/HeapUtil.h:
3012         (JSC::HeapUtil::findGCObjectPointersForMarking):
3013         * heap/MarkedBlock.cpp:
3014         (JSC::MarkedBlock::MarkedBlock):
3015         * heap/MarkedBlock.h:
3016         (JSC::MarkedBlock::flipIfNecessary):
3017         (JSC::MarkedBlock::flipIfNecessaryConcurrently):
3018         (JSC::MarkedBlock::Handle::flipIfNecessary):
3019         (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
3020         * heap/MarkedSpace.cpp:
3021         (JSC::MarkedSpace::flip):
3022         * heap/MarkedSpace.h:
3023         (JSC::MarkedSpace::version):
3024         * heap/SlotVisitor.cpp:
3025         (JSC::SlotVisitor::SlotVisitor):
3026         * heap/SlotVisitor.h:
3027
3028 2016-09-08  Mark Lam  <mark.lam@apple.com>
3029
3030         Add support for a ternary sub32 emitter for ARM64 and 32-bit ARM.
3031         https://bugs.webkit.org/show_bug.cgi?id=161724
3032
3033         Reviewed by Filip Pizlo.
3034
3035         ARM architectures support ternary sub instructions.  We should make use of them
3036         in emitAllocateWithNonNullAllocator().
3037
3038         * assembler/MacroAssemblerARM.h:
3039         (JSC::MacroAssemblerARM::sub32):
3040         * assembler/MacroAssemblerARM64.h:
3041         (JSC::MacroAssemblerARM64::sub32):
3042         * assembler/MacroAssemblerARMv7.h:
3043         (JSC::MacroAssemblerARMv7::sub32):
3044         * assembler/MacroAssemblerSH4.h:
3045         (JSC::MacroAssemblerSH4::sub32):
3046         * assembler/MacroAssemblerX86Common.h:
3047         (JSC::MacroAssemblerX86Common::sub32):
3048         * b3/air/AirOpcode.opcodes:
3049         * b3/testb3.cpp:
3050         (JSC::B3::testTernarySubInstructionSelection):
3051         (JSC::B3::run):
3052         * jit/AssemblyHelpers.h:
3053         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
3054
3055 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
3056
3057         Move JSMap/JSSet over to Auxiliary MarkedSpace
3058         https://bugs.webkit.org/show_bug.cgi?id=161744
3059
3060         Reviewed by Saam Barati.
3061         
3062         This moves the buffer out of CopiedSpace and into Auxiliary MarkedSpace.
3063         
3064         Also removes MapData.h/MapDataInlines.h since they are not used anywhere, but they still
3065         speak of CopiedSpace.
3066         
3067         This is a purely mechanical change.
3068
3069         * JavaScriptCore.xcodeproj/project.pbxproj:
3070         * heap/CopyToken.h:
3071         * runtime/HashMapImpl.cpp:
3072         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
3073         (JSC::HashMapImpl<HashMapBucket>::copyBackingStore): Deleted.
3074         * runtime/HashMapImpl.h:
3075         (JSC::HashMapBuffer::create):
3076         * runtime/JSMapIterator.cpp:
3077         * runtime/JSMapIterator.h:
3078         * runtime/JSSetIterator.cpp:
3079         * runtime/JSSetIterator.h:
3080         * runtime/MapBase.cpp:
3081         * runtime/MapData.h: Removed.
3082         * runtime/MapDataInlines.h: Removed.
3083         * runtime/MapPrototype.cpp:
3084         * runtime/SetConstructor.cpp:
3085         * runtime/SetPrototype.cpp:
3086         * runtime/VM.cpp:
3087
3088 2016-09-06  Filip Pizlo  <fpizlo@apple.com>
3089
3090         Typed arrays should use MarkedSpace instead of CopiedSpace
3091         https://bugs.webkit.org/show_bug.cgi?id=161100
3092
3093         Reviewed by Geoffrey Garen.
3094         
3095         This moves typed array backing stores out of CopiedSpace and into Auxiliary MarkedSpace.
3096         
3097         This is a purely mechanical change since Auxiliary MarkedSpace already knows how to do
3098         everything that typed arrays want.
3099
3100         * dfg/DFGOperations.cpp:
3101         (JSC::DFG::newTypedArrayWithSize):
3102         * dfg/DFGOperations.h:
3103         (JSC::DFG::operationNewTypedArrayWithSizeForType):
3104         * dfg/DFGSpeculativeJIT.cpp:
3105         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
3106         * dfg/DFGSpeculativeJIT.h:
3107         (JSC::DFG::SpeculativeJIT::callOperation):
3108         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): Deleted.
3109         * ftl/FTLLowerDFGToB3.cpp:
3110         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
3111         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
3112         (JSC::FTL::DFG::LowerDFGToB3::splatWords):
3113         (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd): Deleted.
3114         (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorage): Deleted.
3115         * heap/CopyToken.h:
3116         * heap/SlotVisitor.cpp:
3117         (JSC::SlotVisitor::markAuxiliary):
3118         * jit/JITOperations.h:
3119         * runtime/JSArrayBufferView.cpp:
3120         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
3121         (JSC::JSArrayBufferView::JSArrayBufferView):
3122         * runtime/JSArrayBufferView.h:
3123         * runtime/JSGenericTypedArrayView.h:
3124         * runtime/JSGenericTypedArrayViewInlines.h:
3125         (JSC::JSGenericTypedArrayView<Adaptor>::createWithFastVector):
3126         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
3127         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
3128         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore): Deleted.
3129
3130 2016-09-08  Per Arne Vollan  <pvollan@apple.com>
3131
3132         [Win64] Compile fixes.
3133         https://bugs.webkit.org/show_bug.cgi?id=161682
3134
3135         Reviewed by Brent Fulgham.
3136
3137         * dfg/DFGSpeculativeJIT64.cpp:
3138         (JSC::DFG::SpeculativeJIT::emitCall):
3139         * jit/JITCall.cpp:
3140         (JSC::JIT::compileOpCall):
3141         * runtime/ArrayConventions.cpp:
3142         (JSC::clearArrayMemset):
3143
3144 2016-09-08  Per Arne Vollan  <pvollan@apple.com>
3145
3146         [Win] Exception fuzz tests fail
3147         https://bugs.webkit.org/show_bug.cgi?id=140928
3148
3149         Reviewed by Mark Lam.
3150
3151         Flush stdout when throwing the exception to make sure the output comes before output in the exception handler.
3152         The tests depend on the output to stdout being written in the correct order.
3153
3154         * runtime/ExceptionFuzz.cpp:
3155         (JSC::doExceptionFuzzing):
3156
3157 2016-09-07  Simon Fraser  <simon.fraser@apple.com>
3158
3159         Enable the <meter> element on iOS
3160         https://bugs.webkit.org/show_bug.cgi?id=161714
3161         rdar://problem/8978410
3162
3163         Reviewed by Tim Horton.
3164
3165         Define ENABLE_METER_ELEMENT unconditionally now.
3166
3167         * Configurations/FeatureDefines.xcconfig:
3168
3169 2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>
3170
3171         Modernize Debugger to use nullptr
3172         https://bugs.webkit.org/show_bug.cgi?id=161718
3173
3174         Reviewed by Mark Lam.
3175
3176         * debugger/Debugger.cpp:
3177         (JSC::Debugger::Debugger):
3178         (JSC::Debugger::~Debugger):
3179         (JSC::Debugger::detach):
3180         (JSC::Debugger::stepOutOfFunction):
3181         (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
3182         * debugger/Debugger.h:
3183
3184 2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>
3185
3186         Web Inspector: Remove always false case in Debugger
3187         https://bugs.webkit.org/show_bug.cgi?id=161717
3188
3189         Reviewed by Brian Burg.
3190
3191         * debugger/Debugger.cpp:
3192         (JSC::Debugger::didExecuteProgram):
3193         We would have earlier returned a few statements ago if this case was true.
3194         And we would have crashed in the previous statement if this case was true.
3195
3196 2016-09-07  Yusuke Suzuki  <utatane.tea@gmail.com>
3197
3198         Unreviewed, build fix after r205569
3199
3200         Tweak CMakeLists.txt
3201
3202         * CMakeLists.txt:
3203
3204 2016-09-07  Mark Lam  <mark.lam@apple.com>
3205
3206         Add CatchScope and force all exception checks to be via ThrowScope or CatchScope.
3207         https://bugs.webkit.org/show_bug.cgi?id=161498
3208
3209         Reviewed by Geoffrey Garen.
3210
3211         This patch refactors the ThrowScope class, and introduces a base ExceptionScope
3212         that ThrowScope extends.  A CatchScope which extends the ExceptionScope is also
3213         introduced.
3214
3215         ENABLE(THROW_SCOPE_VERIFICATION) is now renamed to ENABLE(EXCEPTION_SCOPE_VERIFICATION)
3216         which is a more suitable name now.
3217
3218         Note: exception scope verification is still disabled by default.  There are still
3219         many places that need to be fixed up or re-expressed in a way that is friendly
3220         to the verification.  I'll address those in subsequent patches.
3221
3222         After this patch, the code will statically enforce that:
322