Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-23  Dan Bernstein  <mitz@apple.com>
2
3         Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
4         https://bugs.webkit.org/show_bug.cgi?id=145345
5
6         Reviewed by Sam Weinig.
7
8         * Configurations/Base.xcconfig: Also changed to use $(inherited).
9
10 2015-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>
11
12         Introduce UniquedStringImpl and SymbolImpl to separate symbolic strings from AtomicStringImpl
13         https://bugs.webkit.org/show_bug.cgi?id=144848
14
15         Reviewed by Darin Adler.
16
17         Use UniquedStringImpl, SymbolImpl and AtomicStringImpl.
18
19         * API/JSCallbackObject.h:
20         * builtins/BuiltinNames.h:
21         (JSC::BuiltinNames::isPrivateName):
22         * bytecode/BytecodeIntrinsicRegistry.h:
23         * bytecode/CodeBlock.cpp:
24         (JSC::CodeBlock::CodeBlock):
25         * bytecode/ComplexGetStatus.cpp:
26         (JSC::ComplexGetStatus::computeFor):
27         * bytecode/ComplexGetStatus.h:
28         * bytecode/GetByIdStatus.cpp:
29         (JSC::GetByIdStatus::computeFromLLInt):
30         (JSC::GetByIdStatus::computeFor):
31         (JSC::GetByIdStatus::computeForStubInfo):
32         * bytecode/GetByIdStatus.h:
33         * bytecode/Instruction.h:
34         (JSC::Instruction::Instruction):
35         * bytecode/PutByIdStatus.cpp:
36         (JSC::PutByIdStatus::computeFromLLInt):
37         (JSC::PutByIdStatus::computeFor):
38         (JSC::PutByIdStatus::computeForStubInfo):
39         * bytecode/PutByIdStatus.h:
40         * bytecompiler/BytecodeGenerator.cpp:
41         (JSC::BytecodeGenerator::BytecodeGenerator):
42         (JSC::BytecodeGenerator::visibleNameForParameter):
43         (JSC::BytecodeGenerator::hasConstant):
44         (JSC::BytecodeGenerator::addConstant):
45         * bytecompiler/BytecodeGenerator.h:
46         * bytecompiler/NodesCodegen.cpp:
47         (JSC::PropertyListNode::emitBytecode):
48         * dfg/DFGByteCodeParser.cpp:
49         (JSC::DFG::ByteCodeParser::parseBlock):
50         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
51         * dfg/DFGDesiredIdentifiers.cpp:
52         (JSC::DFG::DesiredIdentifiers::addLazily):
53         (JSC::DFG::DesiredIdentifiers::at):
54         (JSC::DFG::DesiredIdentifiers::reallyAdd):
55         * dfg/DFGDesiredIdentifiers.h:
56         (JSC::DFG::DesiredIdentifiers::operator[]):
57         * dfg/DFGFixupPhase.cpp:
58         (JSC::DFG::FixupPhase::fixupNode):
59         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
60         * dfg/DFGSpeculativeJIT.cpp:
61         (JSC::DFG::SpeculativeJIT::compileIn):
62         * dfg/DFGSpeculativeJIT.h:
63         (JSC::DFG::SpeculativeJIT::identifierUID):
64         (JSC::DFG::SpeculativeJIT::callOperation):
65         * ftl/FTLCompile.cpp:
66         (JSC::FTL::mmAllocateDataSection):
67         * ftl/FTLInlineCacheDescriptor.h:
68         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
69         (JSC::FTL::InlineCacheDescriptor::uid):
70         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
71         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
72         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
73         * ftl/FTLIntrinsicRepository.h:
74         * ftl/FTLLowerDFGToLLVM.cpp:
75         (JSC::FTL::LowerDFGToLLVM::compilePutById):
76         (JSC::FTL::LowerDFGToLLVM::compileIn):
77         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
78         (JSC::FTL::LowerDFGToLLVM::getById):
79         * ftl/FTLOperations.cpp:
80         (JSC::FTL::operationMaterializeObjectInOSR):
81         * ftl/FTLSlowPathCall.cpp:
82         (JSC::FTL::callOperation):
83         * ftl/FTLSlowPathCall.h:
84         * jit/JIT.h:
85         * jit/JITInlines.h:
86         (JSC::JIT::callOperation):
87         * jit/JITOperations.cpp:
88         * jit/JITOperations.h:
89         * parser/Nodes.cpp:
90         (JSC::ProgramNode::setClosedVariables):
91         * parser/Nodes.h:
92         (JSC::ScopeNode::captures):
93         (JSC::ScopeNode::setClosedVariables):
94         (JSC::ProgramNode::closedVariables):
95         * parser/Parser.cpp:
96         (JSC::Parser<LexerType>::parseInner):
97         (JSC::Parser<LexerType>::didFinishParsing):
98         (JSC::Parser<LexerType>::parseContinueStatement):
99         * parser/Parser.h:
100         (JSC::Scope::Scope):
101         (JSC::Scope::pushLabel):
102         (JSC::Scope::getLabel):
103         (JSC::Scope::declareCallee):
104         (JSC::Scope::declareVariable):
105         (JSC::Scope::declareParameter):
106         (JSC::Scope::declareBoundParameter):
107         (JSC::Scope::useVariable):
108         (JSC::Scope::copyCapturedVariablesToVector):
109         (JSC::Parser::closedVariables):
110         (JSC::ScopeLabelInfo::ScopeLabelInfo): Deleted.
111         * parser/SourceProviderCacheItem.h:
112         (JSC::SourceProviderCacheItem::usedVariables):
113         (JSC::SourceProviderCacheItem::writtenVariables):
114         (JSC::SourceProviderCacheItem::create):
115         * runtime/CommonIdentifiers.cpp:
116         (JSC::CommonIdentifiers::isPrivateName):
117         * runtime/CommonIdentifiers.h:
118         * runtime/Identifier.h:
119         (JSC::Identifier::impl):
120         (JSC::Identifier::Identifier):
121         (JSC::parseIndex):
122         (JSC::IdentifierRepHash::hash):
123         * runtime/IdentifierInlines.h:
124         (JSC::Identifier::fromUid):
125         * runtime/IntendedStructureChain.cpp:
126         (JSC::IntendedStructureChain::mayInterceptStoreTo):
127         * runtime/IntendedStructureChain.h:
128         * runtime/JSGlobalObject.cpp:
129         (JSC::JSGlobalObject::init):
130         * runtime/Lookup.h:
131         (JSC::HashTable::entry):
132         * runtime/MapData.h:
133         * runtime/ObjectConstructor.cpp:
134         (JSC::objectConstructorGetOwnPropertySymbols):
135         * runtime/PrivateName.h:
136         (JSC::PrivateName::PrivateName):
137         (JSC::PrivateName::uid):
138         * runtime/PropertyMapHashTable.h:
139         * runtime/PropertyName.h:
140         (JSC::PropertyName::PropertyName):
141         (JSC::PropertyName::uid):
142         (JSC::PropertyName::publicName):
143         (JSC::parseIndex):
144         * runtime/PropertyNameArray.h:
145         (JSC::PropertyNameArray::addKnownUnique):
146         (JSC::PropertyNameArray::add):
147         * runtime/Structure.cpp:
148         (JSC::StructureTransitionTable::contains):
149         (JSC::StructureTransitionTable::get):
150         (JSC::StructureTransitionTable::add):
151         (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
152         (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
153         (JSC::Structure::getConcurrently):
154         (JSC::Structure::add):
155         (JSC::Structure::remove):
156         (JSC::Structure::toStructureShape):
157         * runtime/Structure.h:
158         (JSC::PropertyMapEntry::PropertyMapEntry):
159         * runtime/StructureInlines.h:
160         (JSC::Structure::getConcurrently):
161         * runtime/StructureTransitionTable.h:
162         (JSC::StructureTransitionTable::Hash::hash):
163         * runtime/Symbol.cpp:
164         (JSC::Symbol::Symbol):
165         * runtime/Symbol.h:
166         * runtime/SymbolConstructor.cpp:
167         (JSC::symbolConstructorFor):
168         (JSC::symbolConstructorKeyFor):
169         * runtime/SymbolTable.cpp:
170         (JSC::SymbolTable::uniqueIDForVariable):
171         (JSC::SymbolTable::globalTypeSetForVariable):
172         * runtime/SymbolTable.h:
173         * runtime/TypeSet.cpp:
174         (JSC::StructureShape::addProperty):
175         (JSC::StructureShape::propertyHash):
176         * runtime/TypeSet.h:
177
178 2015-05-21  Filip Pizlo  <fpizlo@apple.com>
179
180         Arguments elimination phase mishandles arity check failure in its reduction of LoadVarargs to GetStack/PutStacks
181         https://bugs.webkit.org/show_bug.cgi?id=145298
182
183         Reviewed by Geoffrey Garen.
184
185         * dfg/DFGArgumentsEliminationPhase.cpp: Fix the bug. I restructured the loop to make it more obvious that we're initializing everything that we're supposed to initialize.
186         * dfg/DFGNode.h: Add a comment to clarify something I was confused about while writing this code.
187         * dfg/DFGPutStackSinkingPhase.cpp: Hacking on PutStacks made me think deep thoughts, and I added some FIXMEs.
188         * tests/stress/fold-load-varargs-arity-check-fail-barely.js: Added. This test crashes or fails before this patch.
189         * tests/stress/fold-load-varargs-arity-check-fail.js: Added. This is even more sure to crash or fail.
190         * tests/stress/simplify-varargs-mandatory-minimum-smaller-than-limit.js: Added. Not sure if we had coverage for this case before.
191
192 2015-05-22  Basile Clement  <basile_clement@apple.com>
193
194         Allow DFGClobberize to return non-node constants that must be later created
195         https://bugs.webkit.org/show_bug.cgi?id=145272
196
197         Reviewed by Filip Pizlo.
198
199         This adds a new LazyNode class in DFG that represents either a Node*,
200         or a FrozenValue* with a way to convert it to a Node* provided a block
201         to insert it into. DFGClobberize is converted to use LazyNode instead
202         of Node* when def()'ing values, which allows to now define the array's
203         length as well as the value of its various fields in NewArray and
204         NewArrayBuffer nodes.
205
206         We also introduce a Vector<uint32_t> in DFG::Graph to collect all the
207         values that can be used as index, in order to avoid def()'ing too many
208         values at once for big NewArrayBuffers.
209
210         HeapLocation had to be updated to use a LazyNode as its index to be
211         able to define array values.
212
213         * CMakeLists.txt:
214         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
215         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
216         * JavaScriptCore.xcodeproj/project.pbxproj:
217         * dfg/DFGCSEPhase.cpp:
218         * dfg/DFGClobberize.h:
219         (JSC::DFG::clobberize):
220         (JSC::DFG::DefMethodClobberize::operator()):
221         * dfg/DFGGraph.cpp:
222         (JSC::DFG::Graph::freezeFragile):
223         * dfg/DFGGraph.h:
224         * dfg/DFGHeapLocation.h:
225         (JSC::DFG::HeapLocation::HeapLocation):
226         (JSC::DFG::HeapLocation::index):
227         (JSC::DFG::HeapLocation::hash):
228         * dfg/DFGLazyNode.cpp: Added.
229         (JSC::DFG::LazyNode::dump):
230         * dfg/DFGLazyNode.h: Added.
231         (JSC::DFG::LazyNode::LazyNode):
232         (JSC::DFG::LazyNode::setNode):
233         (JSC::DFG::LazyNode::isHashTableDeletedValue):
234         (JSC::DFG::LazyNode::isNode):
235         (JSC::DFG::LazyNode::op):
236         (JSC::DFG::LazyNode::asNode):
237         (JSC::DFG::LazyNode::asValue):
238         (JSC::DFG::LazyNode::hash):
239         (JSC::DFG::LazyNode::operator==):
240         (JSC::DFG::LazyNode::operator!=):
241         (JSC::DFG::LazyNode::ensureIsNode):
242         (JSC::DFG::LazyNode::operator->):
243         (JSC::DFG::LazyNode::operator*):
244         (JSC::DFG::LazyNode::operator!):
245         (JSC::DFG::LazyNode::operator UnspecifiedBoolType*):
246         (JSC::DFG::LazyNode::setFrozenValue):
247         * dfg/DFGPreciseLocalClobberize.h:
248         (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
249         * dfg/DFGPutStackSinkingPhase.cpp:
250
251 2015-05-22  Andreas Kling  <akling@apple.com>
252
253         [JSC] Speed up new array construction in Array.prototype.splice().
254         <https://webkit.org/b/145303>
255
256         Reviewed by Benjamin Poulain.
257
258         Give splice() a fast path just like slice(), for indexing types where the backing
259         store can be memcpy'd. I generalized JSArray::fastSlice() a little bit so it works
260         for this optimization as well.
261
262         7% progression on Kraken/stanford-crypto-pbkdf2.
263
264         * runtime/JSArray.h:
265         * runtime/JSArray.cpp:
266         (JSC::JSArray::fastSlice): Tweak this to return JSArray*, and don't bother throwing
267         out-of-memory exceptions. Let the caller worry about that.
268
269         * runtime/ArrayPrototype.cpp:
270         (JSC::arrayProtoFuncSlice): Update for fastSlice() changes.
271         (JSC::arrayProtoFuncSplice): If the object we're splicing out of is a bona fide
272         JSArray, use fastSlice() to create the returned array instead of doing a generic
273         get/put loop.
274
275 2015-05-21  Filip Pizlo  <fpizlo@apple.com>
276
277         CPS rethreading should really get rid of GetLocals
278         https://bugs.webkit.org/show_bug.cgi?id=145290
279
280         Reviewed by Benjamin Poulain.
281         
282         CPS rethreading is intended to get rid of redundant GetLocals. CSE can also do it, but
283         the idea is that you should be able to disable CSE and everything would still work. This
284         fixes a bug in CPS rethreading's GetLocal elimination: we should be calling replaceWith
285         rather than setReplacement, since setReplacement still leaves the original node.
286
287         * dfg/DFGCPSRethreadingPhase.cpp:
288         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): Fix the bug.
289         * dfg/DFGFixupPhase.cpp:
290         (JSC::DFG::FixupPhase::fixupNode): Eliminating GetLocals means that they turn into Check. We should handle Checks that have zero inputs.
291         * dfg/DFGValidate.cpp:
292         (JSC::DFG::Validate::validateCPS): Add a validation for what a GetLocal should look like in ThreadedCPS.
293         * tests/stress/get-local-elimination.js: Added.
294         (foo):
295
296 2015-05-21  Saam Barati  <saambarati1@gmail.com>
297
298         Object allocation sinking phase should explicitly create bottom values for CreateActivation sink candidates and CreateActivation should have SymbolTable as a child node
299         https://bugs.webkit.org/show_bug.cgi?id=145192
300
301         Reviewed by Filip Pizlo.
302
303         When we sink CreateActivation and generate MaterializeCreateActivation
304         in the object allocation sinking phase, we now explictly add PutHints for 
305         all variables on the activation setting those variables to their default value 
306         (undefined for Function activations and soon to be JS Empty Value for block scope activations). 
307         This allows us to remove code that fills FTL fast activation allocations with Undefined.
308
309         This patch also adds the constant SymbolTable as an OpInfo of CreateActivation and MaterializeCreateActivation
310         nodes. This is in preparation for ES6 block scoping which will introduce a new 
311         op code that gets lowered to CreateActivation.
312
313         * dfg/DFGByteCodeParser.cpp:
314         (JSC::DFG::ByteCodeParser::parseBlock):
315         * dfg/DFGClobberize.h:
316         (JSC::DFG::clobberize):
317         * dfg/DFGNode.h:
318         (JSC::DFG::Node::hasCellOperand):
319         (JSC::DFG::Node::cellOperand):
320         * dfg/DFGObjectAllocationSinkingPhase.cpp:
321         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
322         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
323         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
324         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
325         * dfg/DFGPromotedHeapLocation.cpp:
326         (WTF::printInternal):
327         * dfg/DFGPromotedHeapLocation.h:
328         * dfg/DFGSpeculativeJIT.cpp:
329         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
330         * ftl/FTLLowerDFGToLLVM.cpp:
331         (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
332         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
333         * ftl/FTLOperations.cpp:
334         (JSC::FTL::operationMaterializeObjectInOSR):
335         * tests/stress/activation-sink-default-value.js: Added.
336         (bar):
337         * tests/stress/activation-sink-osrexit-default-value.js: Added.
338         (foo.set result):
339
340 2015-05-21  Per Arne Vollan  <peavo@outlook.com>
341
342         MSVC internal compiler error when compiling TemplateRegistryKey class.
343         https://bugs.webkit.org/show_bug.cgi?id=145259
344
345         Reviewed by Alex Christensen.
346
347         MSVC is not able to handle the brace initialization of a class member in this case.
348
349         * runtime/TemplateRegistryKey.h:
350
351 2015-05-21  Csaba Osztrogonác  <ossy@webkit.org>
352
353         Fix the !ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) build after r184337
354         https://bugs.webkit.org/show_bug.cgi?id=145248
355
356         Reviewed by Yusuke Suzuki.
357
358         * bytecompiler/BytecodeGenerator.cpp:
359         * bytecompiler/BytecodeGenerator.h:
360         * parser/Parser.cpp:
361         (JSC::Parser<LexerType>::parseMemberExpression):
362
363 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
364
365         Web Inspector: array previews should have a much smaller cap on values
366         https://bugs.webkit.org/show_bug.cgi?id=145195
367
368         Reviewed by Timothy Hatcher.
369
370         * inspector/InjectedScriptSource.js:
371         (InjectedScript.RemoteObject.prototype._generatePreview):
372         Reduce the indexes threshold for previews.
373
374 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
375
376         Web Inspector: Use native Arguments detection instead of using toString
377         https://bugs.webkit.org/show_bug.cgi?id=145235
378
379         Reviewed by Timothy Hatcher.
380
381         * inspector/InjectedScriptSource.js:
382         (InjectedScript.prototype._subtype):
383         Deleted the old string code.
384
385         * inspector/JSInjectedScriptHost.cpp:
386         (Inspector::JSInjectedScriptHost::subtype):
387         Replaced with a stricter, more accurate check.
388
389 2015-05-20  Andreas Kling  <akling@apple.com>
390
391         Remove unused MarkedBlock::m_rememberedSet.
392         <https://webkit.org/b/145224>
393
394         Reviewed by Mark Hahnenberg.
395
396         The MarkedBlock had a copy of the remembered bit for each of its cells,
397         and we were maintaining that bitmap despite no one actually ever consulting it.
398
399         This patch removes MarkedBlock::m_rememberedSet, freeing up 128 bytes in each
400         block and making write barriers a little faster.
401
402         * heap/Heap.cpp:
403         (JSC::Heap::clearRememberedSet):
404         (JSC::Heap::addToRememberedSet):
405         * heap/HeapInlines.h:
406         (JSC::Heap::isRemembered):
407         * heap/MarkedBlock.cpp:
408         (JSC::MarkedBlock::clearRememberedSet): Deleted.
409         (JSC::MarkedBlock::clearMarksWithCollectionType):
410         * heap/MarkedBlock.h:
411         (JSC::MarkedBlock::setRemembered): Deleted.
412         (JSC::MarkedBlock::clearRemembered): Deleted.
413         (JSC::MarkedBlock::atomicClearRemembered): Deleted.
414         (JSC::MarkedBlock::isRemembered): Deleted.
415         * heap/MarkedSpace.h:
416         (JSC::ClearRememberedSet::operator()): Deleted.
417         (JSC::MarkedSpace::clearRememberedSet): Deleted.
418
419 2015-05-20  Andreas Kling  <akling@apple.com>
420
421         Eden collections should extend the IncrementalSweeper work list, not replace it.
422         <https://webkit.org/b/145213>
423         <rdar://problem/21002666>
424
425         Reviewed by Geoffrey Garen.
426
427         After an eden collection, the garbage collector was adding all MarkedBlocks containing
428         new objects to the IncrementalSweeper's work list, to make sure they didn't have to
429         wait until the next full collection before getting swept.
430
431         Or at least, that's what it thought it was doing. It turns out that IncrementalSweeper's
432         internal work list is really just a reference to Heap::m_blockSnapshot. I didn't realize
433         this when writing the post-eden sweep code, and instead made eden collections cancel
434         all pending sweeps and *replace* them with the list of blocks with new objects.
435
436         This made it so that rapidly occurring eden collections could prevent large numbers of
437         heap blocks from ever getting swept. This would manifest as accumulation of MarkedBlocks
438         when a system under heavy load was also allocating short lived objects at a high rate.
439         Things would eventually get cleaned up when there was a lull and a full collection was
440         allowed to run its heap sweep to completion.
441
442         Fix this by moving all management of the block snapshot to Heap. snapshotMarkedSpace()
443         now handles eden collections by merging the list of blocks with new objects into the
444         existing block snapshot.
445
446         * heap/Heap.cpp:
447         (JSC::Heap::snapshotMarkedSpace):
448         (JSC::Heap::notifyIncrementalSweeper):
449         * heap/IncrementalSweeper.cpp:
450         (JSC::IncrementalSweeper::startSweeping):
451         (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Deleted.
452         * heap/IncrementalSweeper.h:
453
454 2015-05-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>
455
456         AudioContext resume/close/suspend should reject promises with a DOM exception in lieu of throwing exceptions
457         https://bugs.webkit.org/show_bug.cgi?id=145064
458
459         Reviewed by Darin Adler.
460
461         Added default message for TypeError.
462
463         * runtime/Error.cpp:
464         (JSC::throwTypeError):
465         * runtime/Error.h:
466
467 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
468
469         No LLInt Test Failure: jsc-layout-tests.yaml/js/script-tests/object-literal-duplicate-properties.js.layout-no-llint
470         https://bugs.webkit.org/show_bug.cgi?id=145219
471
472         Reviewed by Mark Lam.
473
474         * jit/JITOperations.cpp:
475         Throw the error we just got, instead of a stack overflow exception.
476         This matches other error handling for callers of prepareForExecution.
477
478 2015-05-19  Filip Pizlo  <fpizlo@apple.com>
479
480         Add some assertions about the CFG in the loop pre-header creation phase
481         https://bugs.webkit.org/show_bug.cgi?id=145205
482
483         Reviewed by Geoffrey Garen.
484         
485         * dfg/DFGByteCodeParser.cpp:
486         (JSC::DFG::ByteCodeParser::currentNodeOrigin): Add a FIXME.
487         * dfg/DFGLICMPhase.cpp:
488         (JSC::DFG::LICMPhase::run): Add a FIXME.
489         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
490         (JSC::DFG::LoopPreHeaderCreationPhase::run): Add the assertions.
491
492 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
493
494         ES6: Implement Object.setPrototypeOf
495         https://bugs.webkit.org/show_bug.cgi?id=145202
496
497         Reviewed by Darin Adler.
498
499         * runtime/JSGlobalObjectFunctions.h:
500         * runtime/JSGlobalObjectFunctions.cpp:
501         (JSC::globalFuncProtoSetter):
502         (JSC::checkProtoSetterAccessAllowed):
503         Extract a helper to share this code between __proto__ setter and setPrototypeOf.
504
505         * runtime/ObjectConstructor.cpp:
506         (JSC::objectConstructorSetPrototypeOf):
507         Implementation is very similiar to __proto__ setter.
508
509 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
510
511         ES6: Should not allow duplicate basic __proto__ properties in Object Literals
512         https://bugs.webkit.org/show_bug.cgi?id=145138
513
514         Reviewed by Darin Adler.
515
516         Implement ES6 Annex B.3.1, which disallows duplicate basic __proto__
517         properties in object literals. This doesn't affect computed properties,
518         shorthand properties, or getters/setters all of which avoid setting
519         the actual prototype of the object anyway.
520
521         * interpreter/Interpreter.cpp:
522         (JSC::eval):
523         Remove out of date comment. Duplicate property names are allowed
524         now in ES6, they were not in ES5 strict mode.
525
526         * parser/ASTBuilder.h:
527         (JSC::ASTBuilder::getName):
528         (JSC::ASTBuilder::getType):
529         * parser/SyntaxChecker.h:
530         (JSC::SyntaxChecker::getName):
531         Add back getName to get the property name depending on the tree builder.
532         Also tighten up the parameter types.
533
534         * runtime/LiteralParser.cpp:
535         (JSC::LiteralParser<CharType>::parse):
536         In quick JSON literal parsing for eval, we actually need to evaluate
537         the __proto__ property assignment, instead of just building up a list
538         of direct properties. Only do this when not doing a strict JSON parse.
539
540         * parser/Nodes.h:
541         Add "Shorthand" to the list of PropertyNode types to allow it to
542         be distinguished without relying on other information.
543
544         * parser/Parser.h:
545         * parser/Parser.cpp:
546         (JSC::Parser<LexerType>::parseProperty):
547         Add the Shorthand type when parsing a shorthand property.
548
549         (JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
550         (JSC::Parser<LexerType>::parseObjectLiteral):
551         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
552         Check for duplicate __proto__ properties, and throw a SyntaxError
553         if that was the case.
554
555 2015-05-20  Csaba Osztrogonác  <ossy@webkit.org>
556
557         [JSC] Add missing copyrights and licenses for some scripts
558         https://bugs.webkit.org/show_bug.cgi?id=145044
559
560         Reviewed by Darin Adler.
561
562         * build-symbol-table-index.py:
563         * create-llvm-ir-from-source-file.py:
564         * create-symbol-table-index.py:
565
566 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
567
568         Web Inspector: Slightly better node previews in arrays
569         https://bugs.webkit.org/show_bug.cgi?id=145188
570
571         Reviewed by Timothy Hatcher.
572
573         * inspector/InjectedScriptSource.js:
574         (InjectedScript.prototype._nodeDescription):
575         (InjectedScript.prototype._nodePreview):
576         Different stringified representations for a basic object description or in a preview.
577
578         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
579         Use the node preview string representation inside previews.
580
581 2015-05-19  Commit Queue  <commit-queue@webkit.org>
582
583         Unreviewed, rolling out r184613 and r184614.
584         https://bugs.webkit.org/show_bug.cgi?id=145206
585
586         Broke 10 tests :| (Requested by kling on #webkit).
587
588         Reverted changesets:
589
590         "[JSC] Speed up URL encode/decode by using bitmaps instead of
591         strchr()."
592         https://bugs.webkit.org/show_bug.cgi?id=145115
593         http://trac.webkit.org/changeset/184613
594
595         "[JSC] Speed up URL encode/decode by using bitmaps instead of
596         strchr()."
597         https://bugs.webkit.org/show_bug.cgi?id=145115
598         http://trac.webkit.org/changeset/184614
599
600 2015-05-19  Andreas Kling  <akling@apple.com>
601
602         Give StringView a utf8() API.
603         <https://webkit.org/b/145201>
604
605         Reviewed by Anders Carlsson.
606
607         Use JSString::view() in a few places where we couldn't before due to StringView
608         lacking a utf8() API. This is a minor speed-up on Kraken's crypto subtests,
609         which like to call encode() with substring JSStrings.
610
611         * jsc.cpp:
612         (functionPrint):
613         (functionDebug):
614         * runtime/JSGlobalObjectFunctions.cpp:
615         (JSC::encode):
616
617 2015-05-19  Andreas Kling  <akling@apple.com>
618
619         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
620         <https://webkit.org/b/145115>
621
622         Incorporate review feedback from Darin, removing some unnecessary zero checks.
623
624         * runtime/JSGlobalObjectFunctions.cpp:
625         (JSC::encode):
626         (JSC::decode):
627         (JSC::globalFuncEscape):
628
629 2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
630
631         Move AtomicStringImpl table related operations from AtomicString to AtomicStringImpl
632         https://bugs.webkit.org/show_bug.cgi?id=145109
633
634         Reviewed by Darin Adler.
635
636         * bytecode/CodeBlock.cpp:
637         (JSC::CodeBlock::nameForRegister):
638         * runtime/Identifier.cpp:
639         (JSC::Identifier::add):
640         (JSC::Identifier::add8):
641         * runtime/Identifier.h:
642         (JSC::Identifier::add):
643         * runtime/IdentifierInlines.h:
644         (JSC::Identifier::Identifier):
645         (JSC::Identifier::add):
646         * runtime/JSString.cpp:
647         (JSC::JSRopeString::resolveRopeToExistingAtomicString):
648         * runtime/JSString.h:
649         (JSC::JSString::toExistingAtomicString):
650         * runtime/SmallStrings.cpp:
651         (JSC::SmallStringsStorage::SmallStringsStorage):
652         * runtime/TypeSet.cpp:
653         (JSC::StructureShape::propertyHash):
654
655 2015-05-19  Joseph Pecoraro  <pecoraro@apple.com>
656
657         Web Inspector: Improve Preview for NodeList / array like collections
658         https://bugs.webkit.org/show_bug.cgi?id=145177
659
660         Reviewed by Timothy Hatcher.
661
662         * inspector/InjectedScriptSource.js:
663         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
664         For "array" like object previews skip over non-index properties.
665         We are not marking the object as lossless by choice, but we
666         may return to this decision later.
667
668 2015-05-19  Michael Saboff  <msaboff@apple.com>
669
670         REGRESSION(183787): JIT is enabled for all builds
671         https://bugs.webkit.org/show_bug.cgi?id=145179
672
673         Reviewed by Geoffrey Garen.
674
675         Eliminated the setting of ENABLE_JIT, as wtf/Platform.h has appropriate logic to
676         set it depending on OS and CPU type.
677
678         * Configurations/FeatureDefines.xcconfig:
679
680 2015-05-19  Youenn Fablet  <youenn.fablet@crf.canon.fr>
681
682         Rename createIterResultObject as createIteratorResultObject
683         https://bugs.webkit.org/show_bug.cgi?id=145116
684
685         Reviewed by Darin Adler.
686
687         Renamed createIterResultObject as createIteratorResultObject.
688         Made this function exportable for future use by streams API.
689
690         * runtime/IteratorOperations.cpp:
691         (JSC::createIteratorResultObject):
692         * runtime/IteratorOperations.h:
693         * runtime/MapIteratorPrototype.cpp:
694         (JSC::MapIteratorPrototypeFuncNext):
695         * runtime/SetIteratorPrototype.cpp:
696         (JSC::SetIteratorPrototypeFuncNext):
697
698 2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
699
700         Array.prototype methods must use ToLength
701         https://bugs.webkit.org/show_bug.cgi?id=144128
702
703         Reviewed by Oliver Hunt.
704
705         Patch by Jordan Harband  <ljharb@gmail.com> and Yusuke Suzuki <utatane.tea@gmail.com>
706
707         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
708
709         This patch introduces ToLength and ToInteger JS implementation to encourage the DFG/FTL's inlining.
710         These implementations are located in GlobalObject.js.
711         And set to the JSGlobalObject with the private symbols @ToLength and @ToInteger manually.
712
713         * builtins/Array.prototype.js:
714         (every):
715         (forEach):
716         (filter):
717         (map):
718         (some):
719         (fill):
720         (find):
721         (findIndex):
722         (includes):
723         * builtins/ArrayConstructor.js:
724         (from):
725         * builtins/GlobalObject.js: Copied from Source/JavaScriptCore/builtins/StringConstructor.js.
726         (ToInteger):
727         (ToLength):
728         * builtins/StringConstructor.js:
729         (raw):
730         * runtime/JSGlobalObject.cpp:
731         (JSC::JSGlobalObject::init):
732         * runtime/JSGlobalObjectFunctions.h:
733
734 2015-05-19  Mark Lam  <mark.lam@apple.com>
735
736         Fix the build of a universal binary with ARMv7k of JavaScriptCore.
737         https://bugs.webkit.org/show_bug.cgi?id=145143
738
739         Reviewed by Geoffrey Garen.
740
741         The offlineasm works in 3 phases:
742
743         Phase 1:
744            Parse the llint asm files for config options and desired offsets.
745            Let's say the offlineasm discovers C unique options and O unique offsets.
746            The offlineasm will then generate a LLIntDesiredOffsets.h file with
747            C x C build configurations, each with a set of O offsets.
748
749            Each of these build configurations is given a unique configuration index number.
750
751         Phase 2: 
752            Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.
753
754            If we're building a fat binary with 2 configurations: armv7, and armv7k,
755            then the fat binary will contain 2 blobs of offsets, one for each of these
756            build configurations.
757
758         Phase 3:
759            Parse the llint asm files and emit asm code using the offsets that are
760            extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
761            configuration index number.
762
763         In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
764         source.  As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
765         the set of C unique options.
766
767         For armv7k builds, OFFLINE_ASM_ARMv7 is also true.  As a result, for an armv7k
768         target, we will end up building armv7 source.  In general, this is fine except:
769
770         1. armv7k has different alignment requirements from armv7.  Hence, their offset
771            values (in JSCLLIntOffsetsExtractor) will be different.
772
773         2. The offlineasm was never told that it needed to make a different configuration
774            for armv7k builds.  Hence, the armv7k build of LLIntDesiredOffsets.h will
775            build the armv7 configuration, and consequently, the armv7k blob of offsets in
776            JSCLLIntOffsetsExtractor will have the same configuration index number as
777            the armv7 blob of offsets.
778
779         In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
780         looking for the armv7 build's configuration index number, it discovers the
781         armv7k blob which has the same configuration number.  As a result, it
782         erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
783         Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
784         and all round badness.
785
786         The fix is to add a simple "if ARMv7k" statement to the llint asm files.  While
787         the if statement has no body, it does make the offlineasm aware of the need for
788         ARMv7k as a configuration option.  As a result, it will generate an armv7k
789         variant configuration in the LLIntDesiredOffsets.h file with its own unique
790         configuration index number.  With that, the JSCLLIntOffsetsExtractor fat binary
791         will no longer have duplicate configuration index numbers for the armv7 and
792         armv7k blobs of offsets, and the issue is resolved.
793
794         * llint/LLIntOfflineAsmConfig.h:
795         * llint/LowLevelInterpreter.asm:
796
797 2015-05-19  Andreas Kling  <akling@apple.com>
798
799         Give JSString a StringView getter and start using it.
800         <https://webkit.org/b/145131>
801
802         Reviewed by Anders Carlsson.
803
804         When JSString is a substring internally, calling value(ExecState*) on it
805         will reify the baseString/start/length tuple into a new StringImpl.
806
807         For clients that only want to look at the characters of a JSString, but
808         don't actually need a reffable StringImpl, adding a light-weight StringView
809         getter lets them avoid constructing anything.
810
811         This patch adds JSString::view(ExecState*) and uses it in a few places.
812         There are many more opportunities to use this API, but let's do a few things
813         at a time.
814
815         * runtime/FunctionConstructor.cpp:
816         (JSC::constructFunctionSkippingEvalEnabledCheck):
817         * runtime/JSGlobalObjectFunctions.cpp:
818         (JSC::decode):
819         (JSC::parseInt):
820         (JSC::jsToNumber):
821         (JSC::parseFloat):
822         (JSC::globalFuncParseInt):
823         (JSC::globalFuncParseFloat):
824         (JSC::globalFuncEscape):
825         (JSC::globalFuncUnescape):
826         * runtime/JSGlobalObjectFunctions.h:
827         * runtime/JSONObject.cpp:
828         (JSC::JSONProtoFuncParse):
829         * runtime/JSString.cpp:
830         (JSC::JSString::getPrimitiveNumber):
831         (JSC::JSString::toNumber):
832         * runtime/JSString.h:
833         (JSC::JSRopeString::view):
834         (JSC::JSString::view):
835
836 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
837
838         Better optimize 'if' with ternaries conditional tests.
839         https://bugs.webkit.org/show_bug.cgi?id=144136
840
841         Reviewed by Benjamin Poulain.
842         
843         This is the last fix I'll do for this for now. BooleanToNumber(Untyped:) where the input
844         is proved to be either BoolInt32 or Boolean should be optimized to just masking the
845         lowest bit.
846         
847         This is another 37% speed-up on JSRegress/slow-ternaries.
848
849         * dfg/DFGSpeculativeJIT32_64.cpp:
850         (JSC::DFG::SpeculativeJIT::compile):
851         * dfg/DFGSpeculativeJIT64.cpp:
852         (JSC::DFG::SpeculativeJIT::compile):
853         * ftl/FTLLowerDFGToLLVM.cpp:
854         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
855
856 2015-05-18  Benjamin Poulain  <bpoulain@apple.com>
857
858         <rdar://problem/21003555> cloberrize() is wrong for ArithRound because it doesn't account for the arith mode
859         https://bugs.webkit.org/show_bug.cgi?id=145147
860
861         Reviewed by Filip Pizlo.
862
863         Really stupid bug: ArithRound nodes with different rounding modes
864         were not distinguished and CSE would happily unify with a node of
865         a different rounding mode.
866
867         DFG::clobberize() already support additional data but I was not using it.
868
869         * dfg/DFGClobberize.h:
870         (JSC::DFG::clobberize):
871         * tests/stress/math-round-arith-rounding-mode.js: Added.
872         (firstCareAboutZeroSecondDoesNot):
873         (firstDoNotCareAboutZeroSecondDoes):
874         (warmup):
875         (verifyNegativeZeroIsPreserved):
876
877 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
878
879         Add SpecBoolInt32 type that means "I'm an int and I'm either 0 or 1"
880         https://bugs.webkit.org/show_bug.cgi?id=145137
881
882         Reviewed by Benjamin Poulain.
883         
884         It's super useful to know if an integer value could be either zero or one. We have an
885         immediate need for this because of Int32|Boolean uses, where knowing that the Int32 is
886         either 0 or 1 means that there is no actual polymorphism if you just look at the low bit
887         (1 behaves like true, 0 behaves like false, and the low bit of 1|true is 1, and the low
888         bit of 0|false is 0).
889         
890         We do this by splitting the SpecInt32 type into SpecBoolInt32 and SpecNonBoolInt32. This
891         change doesn't have any effect on behavior, yet. But it does give us the ability to
892         predict and prove when values are SpecBoolInt32; it's just we don't leverage this yet.
893         
894         This is perf-neutral.
895
896         * bytecode/SpeculatedType.cpp:
897         (JSC::dumpSpeculation):
898         (JSC::speculationToAbbreviatedString):
899         (JSC::speculationFromValue):
900         * bytecode/SpeculatedType.h:
901         (JSC::isStringOrStringObjectSpeculation):
902         (JSC::isBoolInt32Speculation):
903         (JSC::isInt32Speculation):
904         (JSC::isInt32OrBooleanSpeculation):
905         * dfg/DFGAbstractInterpreterInlines.h:
906         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
907
908 2015-05-18  Michael Catanzaro  <mcatanzaro@igalia.com>
909
910         [CMake] Ignore warnings in system headers
911         https://bugs.webkit.org/show_bug.cgi?id=144747
912
913         Reviewed by Darin Adler.
914
915         Separate include directories into WebKit project includes and system includes. Suppress all
916         warnings from headers in system include directories using the SYSTEM argument to
917         the include_directories command.
918
919         * CMakeLists.txt:
920         * PlatformGTK.cmake:
921
922 2015-05-18  Skachkov Alexandr  <gskachkov@gmail.com>
923
924         [ES6] Arrow function syntax. Feature flag for arrow function
925         https://bugs.webkit.org/show_bug.cgi?id=145108
926
927         Reviewed by Ryosuke Niwa.
928
929         Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function
930
931         * Configurations/FeatureDefines.xcconfig:
932         
933 2015-05-18  Benjamin Poulain  <benjamin@webkit.org>
934
935         [JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
936         https://bugs.webkit.org/show_bug.cgi?id=145092
937
938         Reviewed by Filip Pizlo.
939
940         When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
941         we get the inside loop driving the tierUpCounter and we have very little chance of
942         doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
943         up in the outer loop and OSR Enter there.
944
945         This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.
946
947         To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
948         enter their CheckTierUp regardless of the tier-up counter.
949
950         * bytecode/ExecutionCounter.cpp:
951         (JSC::ExecutionCounter<countingVariant>::setThreshold):
952         This is somewhat unrelated. This assertion is incorrect because it relies on
953         m_counter, which changes on an other thread.
954
955         I have hit it a couple of times with this patch because we are a bit more aggressive
956         on CheckTierUp. What happens is:
957         1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
958            hasCrossedThreshold(), and it is false.
959         2) On the main thread, the hot loops keeps running and the counter becomes large
960            enough to cross the threshold.
961         3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
962            test, setThreshold(), where the assertion is. Since the counter is now large enough,
963            the assertion fails.
964
965         * dfg/DFGAbstractInterpreterInlines.h:
966         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
967         * dfg/DFGClobberize.h:
968         (JSC::DFG::clobberize):
969         * dfg/DFGDoesGC.cpp:
970         (JSC::DFG::doesGC):
971         * dfg/DFGFixupPhase.cpp:
972         (JSC::DFG::FixupPhase::fixupNode):
973
974         * dfg/DFGJITCode.h:
975         I used a uint8_t instead of a boolean to make the code generation clearer
976         in DFGSpeculativeJIT64.
977
978         * dfg/DFGNodeType.h:
979         * dfg/DFGOperations.cpp:
980         * dfg/DFGOperations.h:
981
982         * dfg/DFGPredictionPropagationPhase.cpp:
983         (JSC::DFG::PredictionPropagationPhase::propagate):
984         This is a bit annoying: we have the NaturalLoops analysis that provides us
985         everything we need to know about loops, but the TierUpCheck are conservative
986         and set on LoopHint.
987
988         To make the two work together, we first find all the CheckTierUp that cannot
989         OSR enter and we keep a list of all the natural loops containing them.
990
991         Then we do a second pass over the LoopHints, get their NaturalLoop, and check
992         if it contains a loop that cannot OSR enter.
993
994         * dfg/DFGSafeToExecute.h:
995         (JSC::DFG::safeToExecute):
996         * dfg/DFGSpeculativeJIT32_64.cpp:
997         (JSC::DFG::SpeculativeJIT::compile):
998         * dfg/DFGSpeculativeJIT64.cpp:
999         (JSC::DFG::SpeculativeJIT::compile):
1000         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1001         (JSC::DFG::TierUpCheckInjectionPhase::run):
1002         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
1003
1004 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
1005
1006         Add a Int-or-Boolean speculation to Branch
1007         https://bugs.webkit.org/show_bug.cgi?id=145134
1008
1009         Reviewed by Benjamin Poulain.
1010         
1011         After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
1012         int-or-boolean optimization that we already do everywhere else.
1013
1014         * dfg/DFGFixupPhase.cpp:
1015         (JSC::DFG::FixupPhase::fixupNode):
1016
1017 2015-05-18  Andreas Kling  <akling@apple.com>
1018
1019         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
1020         <https://webkit.org/b/145115>
1021
1022         Reviewed by Anders Carlsson.
1023
1024         We were calling strchr() for every character when doing URL encoding/decoding and it stood out
1025         like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
1026
1027         5.5% progression on Kraken/stanford-crypto-sha256-iterative.
1028
1029         * runtime/JSGlobalObjectFunctions.cpp:
1030         (JSC::makeCharacterBitmap):
1031         (JSC::encode):
1032         (JSC::decode):
1033         (JSC::globalFuncDecodeURI):
1034         (JSC::globalFuncDecodeURIComponent):
1035         (JSC::globalFuncEncodeURI):
1036         (JSC::globalFuncEncodeURIComponent):
1037         (JSC::globalFuncEscape):
1038
1039 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
1040
1041         Do not use fastMallocGoodSize anywhere
1042         https://bugs.webkit.org/show_bug.cgi?id=145103
1043
1044         Reviewed by Michael Saboff.
1045
1046         * assembler/AssemblerBuffer.h:
1047         (JSC::AssemblerData::AssemblerData):
1048         (JSC::AssemblerData::grow):
1049
1050 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
1051
1052         [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
1053         https://bugs.webkit.org/show_bug.cgi?id=145102
1054
1055         Reviewed by Darin Adler.
1056
1057         In general, the array targeted by Array.toString() or Array.join() are pretty
1058         simple. In those simple cases, we spend as much time in StringRecursionChecker
1059         as we do on the actual operation.
1060
1061         The reason for this is the HashSet stringRecursionCheckVisitedObjects used
1062         to detect recursion. We are constantly adding and removing objects which
1063         dirty buckets and force constant rehash.
1064
1065         This patch adds a simple shortcut for those simple case: in addition to the HashSet,
1066         we keep a pointer to the root object of the recursion.
1067         In the vast majority of cases, we no longer touch the HashSet at all.
1068
1069         This patch is a 12% progression on the overall score of ArrayWeighted.
1070
1071         * runtime/StringRecursionChecker.h:
1072         (JSC::StringRecursionChecker::performCheck):
1073         (JSC::StringRecursionChecker::~StringRecursionChecker):
1074         * runtime/VM.h:
1075
1076 2015-05-17  Filip Pizlo  <fpizlo@apple.com>
1077
1078         Insert store barriers late so that IR transformations don't have to worry about them
1079         https://bugs.webkit.org/show_bug.cgi?id=145015
1080
1081         Reviewed by Geoffrey Garen.
1082         
1083         We have had three kinds of bugs with store barriers. For the sake of discussion we say
1084         that a store barrier is needed when we have something like:
1085         
1086             base.field = value
1087         
1088         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
1089           This might happen if we prove value to be a non-cell even though in the FixupPhase it
1090           wasn't predicted non-cell.
1091         
1092         - We sometimes have a barrier in the wrong place after object allocation sinking. We
1093           might sink an allocation to just above the store, but that puts it just after the
1094           StoreBarrier that FixupPhase inserted.
1095         
1096         - We don't remove redundant barriers across basic blocks.
1097         
1098         This comprehensively fixes these issues by doing store barrier insertion late, and
1099         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
1100         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
1101         base is in the current GC epoch (i.e. was the last object that we allocated or had a
1102         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
1103         always been allocated before base). We do conservative things when merging epoch state
1104         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
1105         queries AI to determine what type we've proved about value, and avoids barriers when
1106         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
1107         the likelihood that this AI-based removal is effective.
1108         
1109         Rolling back in after fixing some debug build test failures.
1110
1111         * CMakeLists.txt:
1112         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1113         * JavaScriptCore.xcodeproj/project.pbxproj:
1114         * dfg/DFGBlockMap.h:
1115         (JSC::DFG::BlockMap::at):
1116         * dfg/DFGConstantFoldingPhase.cpp:
1117         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1118         * dfg/DFGEpoch.h:
1119         (JSC::DFG::Epoch::operator<):
1120         (JSC::DFG::Epoch::operator>):
1121         (JSC::DFG::Epoch::operator<=):
1122         (JSC::DFG::Epoch::operator>=):
1123         * dfg/DFGFixupPhase.cpp:
1124         (JSC::DFG::FixupPhase::fixupNode):
1125         (JSC::DFG::FixupPhase::speculateForBarrier):
1126         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
1127         * dfg/DFGPlan.cpp:
1128         (JSC::DFG::Plan::compileInThreadImpl):
1129         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
1130         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
1131         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
1132         (JSC::DFG::performFastStoreBarrierInsertion):
1133         (JSC::DFG::performGlobalStoreBarrierInsertion):
1134         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
1135         * ftl/FTLOperations.cpp:
1136         (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
1137         * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
1138         * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
1139
1140 2015-05-16  Commit Queue  <commit-queue@webkit.org>
1141
1142         Unreviewed, rolling out r184415.
1143         https://bugs.webkit.org/show_bug.cgi?id=145096
1144
1145         Broke several tests (Requested by msaboff on #webkit).
1146
1147         Reverted changeset:
1148
1149         "Insert store barriers late so that IR transformations don't
1150         have to worry about them"
1151         https://bugs.webkit.org/show_bug.cgi?id=145015
1152         http://trac.webkit.org/changeset/184415
1153
1154 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1155
1156         Insert store barriers late so that IR transformations don't have to worry about them
1157         https://bugs.webkit.org/show_bug.cgi?id=145015
1158
1159         Reviewed by Geoffrey Garen.
1160         
1161         We have had three kinds of bugs with store barriers. For the sake of discussion we say
1162         that a store barrier is needed when we have something like:
1163         
1164             base.field = value
1165         
1166         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
1167           This might happen if we prove value to be a non-cell even though in the FixupPhase it
1168           wasn't predicted non-cell.
1169         
1170         - We sometimes have a barrier in the wrong place after object allocation sinking. We
1171           might sink an allocation to just above the store, but that puts it just after the
1172           StoreBarrier that FixupPhase inserted.
1173         
1174         - We don't remove redundant barriers across basic blocks.
1175         
1176         This comprehensively fixes these issues by doing store barrier insertion late, and
1177         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
1178         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
1179         base is in the current GC epoch (i.e. was the last object that we allocated or had a
1180         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
1181         always been allocated before base). We do conservative things when merging epoch state
1182         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
1183         queries AI to determine what type we've proved about value, and avoids barriers when
1184         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
1185         the likelihood that this AI-based removal is effective.
1186
1187         * CMakeLists.txt:
1188         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1189         * JavaScriptCore.xcodeproj/project.pbxproj:
1190         * dfg/DFGBlockMap.h:
1191         (JSC::DFG::BlockMap::at):
1192         * dfg/DFGConstantFoldingPhase.cpp:
1193         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1194         * dfg/DFGEpoch.h:
1195         (JSC::DFG::Epoch::operator<):
1196         (JSC::DFG::Epoch::operator>):
1197         (JSC::DFG::Epoch::operator<=):
1198         (JSC::DFG::Epoch::operator>=):
1199         * dfg/DFGFixupPhase.cpp:
1200         (JSC::DFG::FixupPhase::fixupNode):
1201         (JSC::DFG::FixupPhase::speculateForBarrier):
1202         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
1203         * dfg/DFGPlan.cpp:
1204         (JSC::DFG::Plan::compileInThreadImpl):
1205         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
1206         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
1207         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
1208         (JSC::DFG::performFastStoreBarrierInsertion):
1209         (JSC::DFG::performGlobalStoreBarrierInsertion):
1210         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
1211
1212 2015-05-15  Benjamin Poulain  <bpoulain@apple.com>
1213
1214         [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
1215         https://bugs.webkit.org/show_bug.cgi?id=144976
1216
1217         Reviewed by Michael Saboff.
1218
1219         Failing the conversion on zero is pretty dangerous as we discovered on x86.
1220
1221         This patch does not really impact performance significantly because
1222         r184220 removed the zero checks from Kraken. This patch is just to be
1223         on the safe side for cases not covered by existing benchmarks.
1224
1225         * assembler/MacroAssemblerARM64.h:
1226         (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
1227
1228 2015-05-15  Sungmann Cho  <sungmann.cho@navercorp.com>
1229
1230         Remove unnecessary forward declarations in PropertyNameArray.h.
1231         https://bugs.webkit.org/show_bug.cgi?id=145058
1232
1233         Reviewed by Andreas Kling.
1234
1235         No new tests, no behavior change.
1236
1237         * runtime/PropertyNameArray.h:
1238
1239 2015-05-15  Mark Lam  <mark.lam@apple.com>
1240
1241         JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
1242         https://bugs.webkit.org/show_bug.cgi?id=144622
1243
1244         Reviewed by Geoffrey Garen.
1245
1246         When setting the array to a new length that is shorter, we now check if it is worth
1247         just making a new butterfly instead of clearing out the slots in the old butterfly
1248         that resides beyond the new length.  If so, we will make a new butterfly instead.
1249
1250         There is no perf differences in the benchmark results.  However, this does benefit
1251         the perf of pathological cases where we need to shorten the length of a very large
1252         array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js.  With this
1253         patch, we can expect that test to complete in a short time again.
1254
1255         * runtime/JSArray.cpp:
1256         (JSC::JSArray::setLength):
1257         * runtime/JSObject.cpp:
1258         (JSC::JSObject::reallocateAndShrinkButterfly):
1259         - makes a new butterfly with a new shorter length.
1260         * runtime/JSObject.h:
1261         * tests/mozilla/js1_5/Array/regress-101964.js:
1262         - Undo this test change since this patch will prevent us from spending a lot of time
1263           clearing a large butterfly.
1264
1265 2015-05-15  Basile Clement  <basile_clement@apple.com>
1266
1267         DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
1268         https://bugs.webkit.org/show_bug.cgi?id=145062
1269
1270         Reviewed by Filip Pizlo.
1271
1272         We assert in various places (including NodeOrigin::isSet()) that a
1273         NodeOrigin's semantic and forExit must be either both set, or both
1274         unset.  However, LICM'ing a node with unset NodeOrigin would only set
1275         forExit, and leave semantic unset. This can for instance happen when a
1276         Phi node is constant-folded into a JSConstant, which in turn gets
1277         LICM'd.
1278
1279         This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
1280         addition to its forExit if semantic was previously unset.
1281
1282         It also adds two validators to DFGValidate.cpp:
1283          - In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
1284          - In CPS form, all nodes must have a set NodeOrigin forExit (this is
1285            the CPS counterpart to the SSA validator that checks that all nodes
1286            must have a set NodeOrigin except possibly for a continuous chunk of
1287            nodes at the top of a block)
1288
1289         * dfg/DFGLICMPhase.cpp:
1290         (JSC::DFG::LICMPhase::attemptHoist):
1291         * dfg/DFGValidate.cpp:
1292         (JSC::DFG::Validate::validate):
1293         (JSC::DFG::Validate::validateCPS):
1294
1295 2015-05-15  Filip Pizlo  <fpizlo@apple.com>
1296
1297         Unreviewed, remove an unused declaration.
1298
1299         * dfg/DFGSpeculativeJIT.h:
1300
1301 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1302
1303         Remove unused constant-base and constant-value store barrier code in the DFG
1304         https://bugs.webkit.org/show_bug.cgi?id=145039
1305
1306         Reviewed by Andreas Kling.
1307         
1308         Just killing dead code.
1309
1310         * dfg/DFGSpeculativeJIT.cpp:
1311         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
1312         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
1313         * dfg/DFGSpeculativeJIT.h:
1314         * dfg/DFGSpeculativeJIT32_64.cpp:
1315         (JSC::DFG::SpeculativeJIT::writeBarrier):
1316         * dfg/DFGSpeculativeJIT64.cpp:
1317         (JSC::DFG::SpeculativeJIT::writeBarrier):
1318
1319 2015-05-15  Alexandr Skachkov  <gskachkov@gmail.com>
1320
1321         Fix typo in function name parseFunctionParamters -> parseFunctionParameters
1322         https://bugs.webkit.org/show_bug.cgi?id=145040
1323
1324         Reviewed by Mark Lam.
1325
1326         * parser/Parser.h:
1327         * parser/Parser.cpp:
1328
1329 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1330
1331         Remove StoreBarrierWithNullCheck, nobody ever generates this.
1332         
1333         Rubber stamped by Benjamin Poulain and Michael Saboff.
1334
1335         If we did bring something like this back in the future, we would just use UntypedUse instead
1336         of CellUse to indicate that this is what we want.
1337
1338         * dfg/DFGAbstractInterpreterInlines.h:
1339         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1340         * dfg/DFGClobberize.h:
1341         (JSC::DFG::clobberize):
1342         * dfg/DFGDoesGC.cpp:
1343         (JSC::DFG::doesGC):
1344         * dfg/DFGFixupPhase.cpp:
1345         (JSC::DFG::FixupPhase::fixupNode):
1346         * dfg/DFGNode.h:
1347         (JSC::DFG::Node::isStoreBarrier):
1348         * dfg/DFGNodeType.h:
1349         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1350         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1351         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1352         * dfg/DFGPredictionPropagationPhase.cpp:
1353         (JSC::DFG::PredictionPropagationPhase::propagate):
1354         * dfg/DFGSafeToExecute.h:
1355         (JSC::DFG::safeToExecute):
1356         * dfg/DFGSpeculativeJIT.cpp:
1357         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1358         * dfg/DFGSpeculativeJIT32_64.cpp:
1359         (JSC::DFG::SpeculativeJIT::compile):
1360         * dfg/DFGSpeculativeJIT64.cpp:
1361         (JSC::DFG::SpeculativeJIT::compile):
1362         * ftl/FTLCapabilities.cpp:
1363         (JSC::FTL::canCompile):
1364         * ftl/FTLLowerDFGToLLVM.cpp:
1365         (JSC::FTL::LowerDFGToLLVM::compileNode):
1366         (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.
1367
1368 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1369
1370         PutGlobalVar should reference the global object it's storing into
1371         https://bugs.webkit.org/show_bug.cgi?id=145036
1372
1373         Reviewed by Michael Saboff.
1374         
1375         This makes it easier to reason about store barrier insertion and elimination. This changes
1376         the format of PutGlobalVar so that child1 is the global object and child2 is the value.
1377         Previously it just had child1, and that was the value.
1378
1379         * dfg/DFGByteCodeParser.cpp:
1380         (JSC::DFG::ByteCodeParser::parseBlock):
1381         * dfg/DFGClobberize.h:
1382         (JSC::DFG::clobberize):
1383         * dfg/DFGFixupPhase.cpp:
1384         (JSC::DFG::FixupPhase::fixupNode):
1385         * dfg/DFGSpeculativeJIT32_64.cpp:
1386         (JSC::DFG::SpeculativeJIT::compile):
1387         * dfg/DFGSpeculativeJIT64.cpp:
1388         (JSC::DFG::SpeculativeJIT::compile):
1389         * ftl/FTLLowerDFGToLLVM.cpp:
1390         (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
1391
1392 2015-05-14  Michael Catanzaro  <mcatanzaro@igalia.com>
1393
1394         [CMake] Error out when ruby is too old
1395         https://bugs.webkit.org/show_bug.cgi?id=145014
1396
1397         Reviewed by Martin Robinson.
1398
1399         Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
1400         CMakeLists.txt instead.
1401
1402         * CMakeLists.txt:
1403
1404 2015-05-12  Basile Clement  <basile_clement@apple.com>
1405
1406         Enforce options coherency
1407         https://bugs.webkit.org/show_bug.cgi?id=144921
1408
1409         Reviewed by Mark Lam.
1410
1411         JavaScriptCore should be failing early when the options are set in such
1412         a way that we don't have a meaningful way to execute JavaScript, rather
1413         than failing for obscure reasons at some point during execution.
1414
1415         This patch adds a new function that checks whether the options are set
1416         in a coherent way, and makes JSC::Options::initialize() crash when the
1417         environment enforces incoherent options.
1418         Client applications able to add or change additional options are
1419         responsible to check for coherency again before starting to actually
1420         execute JavaScript, if any additional options have been set. This is
1421         implemented for the jsc executable in this patch.
1422
1423         * jsc.cpp:
1424         (CommandLine::parseArguments):
1425         * runtime/Options.cpp:
1426         (JSC::Options::initialize):
1427         (JSC::Options::ensureOptionsAreCoherent): Added.
1428         * runtime/Options.h:
1429         (JSC::Options::ensureOptionsAreCoherent): Added.
1430
1431 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1432
1433         REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
1434         https://bugs.webkit.org/show_bug.cgi?id=145019
1435
1436         Reviewed by Ryosuke Niwa.
1437
1438         Attempt to fix compile errors in EFL ARM buildbots.
1439         By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
1440         unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
1441
1442         * runtime/JSTemplateRegistryKey.cpp:
1443         * runtime/TemplateRegistry.cpp:
1444
1445 2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>
1446
1447         Small refactoring before implementation of the ES6 arrow function.
1448         https://bugs.webkit.org/show_bug.cgi?id=144954
1449
1450         Reviewed by Ryosuke Niwa.
1451
1452         * parser/Parser.h:
1453         * parser/Parser.cpp:
1454
1455 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1456
1457         REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
1458         https://bugs.webkit.org/show_bug.cgi?id=145013
1459
1460         Reviewed by Filip Pizlo.
1461
1462         Fix the regression introduced by r184337.
1463
1464         1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
1465            JSDestructibleObject::s_info.
1466
1467         2. The first register argument of BytecodeGenerator::emitNode
1468            should be a referenced register if it is a temporary register.
1469
1470         * bytecompiler/NodesCodegen.cpp:
1471         (JSC::TaggedTemplateNode::emitBytecode):
1472         * runtime/JSTemplateRegistryKey.cpp:
1473
1474 2015-05-14  Andreas Kling  <akling@apple.com>
1475
1476         String.prototype.split() should create efficient substrings.
1477         <https://webkit.org/b/144985>
1478         <rdar://problem/20949344>
1479
1480         Reviewed by Geoffrey Garen.
1481
1482         Teach split() how to make substring JSStrings instead of relying on StringImpl's
1483         substring sharing mechanism. The optimization works by deferring the construction
1484         of a StringImpl until the substring's value is actually needed.
1485
1486         This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
1487         Out of ~70000 substrings created by split(), only ~2000 of them get reified.
1488
1489         * runtime/StringPrototype.cpp:
1490         (JSC::jsSubstring):
1491         (JSC::splitStringByOneCharacterImpl):
1492         (JSC::stringProtoFuncSplit):
1493
1494 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1495
1496         Change the status of ES6 tagged templates to Done in features.json
1497         https://bugs.webkit.org/show_bug.cgi?id=145003
1498
1499         Reviewed by Benjamin Poulain.
1500
1501         Now it's implemented in r184337.
1502
1503         * features.json:
1504
1505 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1506
1507         Introduce SymbolType into SpeculativeTypes
1508         https://bugs.webkit.org/show_bug.cgi?id=142651
1509
1510         Reviewed by Filip Pizlo.
1511
1512         Introduce SpecSymbol type into speculative types.
1513         Previously symbol type is categorized into SpecCellOther.
1514         But SpecCellOther is not intended to be used for such cells.
1515
1516         This patch just introduces SpecSymbol.
1517         It represents the type of target value is definitely the symbol type.
1518         It is the part of SpecCell.
1519
1520         In this patch, we do not introduce SymbolUse tracking.
1521         It will be added in the separate patch.
1522
1523         * bytecode/SpeculatedType.cpp:
1524         (JSC::dumpSpeculation):
1525         (JSC::speculationFromStructure):
1526         * bytecode/SpeculatedType.h:
1527         (JSC::isSymbolSpeculation):
1528         * dfg/DFGAbstractInterpreterInlines.h:
1529         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1530         * dfg/DFGAbstractValue.cpp:
1531         (JSC::DFG::AbstractValue::setType):
1532         * dfg/DFGConstantFoldingPhase.cpp:
1533         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1534         * tests/stress/typeof-symbol.js: Added.
1535
1536 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1537
1538         [ES6] Implement tagged templates
1539         https://bugs.webkit.org/show_bug.cgi?id=143183
1540
1541         Reviewed by Oliver Hunt.
1542
1543         This patch implements ES6 tagged templates.
1544         In tagged templates, the function takes the template object.
1545
1546         The template object contains the raw and cooked template strings,
1547         so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
1548         While tagged templates require the both strings, the template literal only requires
1549         the cooked strings. So when tokenizing under the template literal context,
1550         we only builds the cooked strings.
1551
1552         As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
1553         The template objects is cached. And every time we evaluate the same tagged templates,
1554         the same (cached) template objects are used.
1555         Since the spec freezes this template objects completely,
1556         we cannot attach some properties to it.
1557         So we can say that it behaves as if the template objects are the primitive values (like JSString).
1558         Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
1559         As the result, when there is no reference to the template object, we can garbage collect it
1560         because the user has no way to test that the newly created template object does not equal
1561         to the already collected template object.
1562
1563         So, to implement tagged templates, we implement the following components.
1564
1565         1. JSTemplateRegistryKey
1566         It holds the template registry key and it does not exposed to users.
1567         TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
1568         When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
1569         we use this JSTemplateRegistryKey as a key to the map and look up the template object from
1570         TemplateRegistry.
1571         JSTemplateRegistryKey is created at the bytecode compiling time and
1572         stored in the CodeBlock as like as JSString content values.
1573
1574         2. TemplateRegistry
1575         This manages the cached template objects.
1576         It holds the weak map (JSTemplateRegistryKey -> the template object).
1577         The template object is weakly referenced.
1578         So if there is no reference to the template object,
1579         the template object is automatically GC-ed.
1580         When looking up the template object, it searches the cached template object.
1581         If it is found, it is returned to the users.
1582         If there is no cached template objects, it creates the new template object and
1583         stores it with the given template registry key.
1584
1585         * CMakeLists.txt:
1586         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1587         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1588         * JavaScriptCore.xcodeproj/project.pbxproj:
1589         * bytecompiler/BytecodeGenerator.cpp:
1590         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
1591         (JSC::BytecodeGenerator::emitGetTemplateObject):
1592         * bytecompiler/BytecodeGenerator.h:
1593         * bytecompiler/NodesCodegen.cpp:
1594         (JSC::TaggedTemplateNode::emitBytecode):
1595         (JSC::TemplateLiteralNode::emitBytecode): Deleted.
1596         * parser/ASTBuilder.h:
1597         (JSC::ASTBuilder::createTaggedTemplate):
1598         (JSC::ASTBuilder::createTemplateLiteral): Deleted.
1599         * parser/Lexer.cpp:
1600         (JSC::Lexer<T>::setCode):
1601         (JSC::Lexer<T>::parseTemplateLiteral):
1602         (JSC::Lexer<T>::lex):
1603         (JSC::Lexer<T>::scanTrailingTemplateString):
1604         (JSC::Lexer<T>::clear):
1605         * parser/Lexer.h:
1606         (JSC::Lexer<T>::makeEmptyIdentifier):
1607         * parser/NodeConstructors.h:
1608         (JSC::TaggedTemplateNode::TaggedTemplateNode):
1609         (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
1610         * parser/Nodes.h:
1611         (JSC::TemplateLiteralNode::templateStrings):
1612         (JSC::TemplateLiteralNode::templateExpressions):
1613         (JSC::TaggedTemplateNode::templateLiteral):
1614         * parser/Parser.cpp:
1615         (JSC::Parser<LexerType>::parseTemplateString):
1616         (JSC::Parser<LexerType>::parseTemplateLiteral):
1617         (JSC::Parser<LexerType>::parsePrimaryExpression):
1618         (JSC::Parser<LexerType>::parseMemberExpression):
1619         * parser/Parser.h:
1620         * parser/ParserArena.h:
1621         (JSC::IdentifierArena::makeEmptyIdentifier):
1622         * parser/SyntaxChecker.h:
1623         (JSC::SyntaxChecker::createTaggedTemplate):
1624         (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
1625         * runtime/CommonIdentifiers.h:
1626         * runtime/JSGlobalObject.cpp:
1627         (JSC::getTemplateObject):
1628         (JSC::JSGlobalObject::JSGlobalObject):
1629         (JSC::JSGlobalObject::init):
1630         * runtime/JSGlobalObject.h:
1631         (JSC::JSGlobalObject::templateRegistry):
1632         * runtime/JSTemplateRegistryKey.cpp: Added.
1633         (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
1634         (JSC::JSTemplateRegistryKey::create):
1635         (JSC::JSTemplateRegistryKey::destroy):
1636         * runtime/JSTemplateRegistryKey.h: Added.
1637         * runtime/ObjectConstructor.cpp:
1638         (JSC::objectConstructorFreeze):
1639         * runtime/ObjectConstructor.h:
1640         * runtime/TemplateRegistry.cpp: Added.
1641         (JSC::TemplateRegistry::TemplateRegistry):
1642         (JSC::TemplateRegistry::getTemplateObject):
1643         * runtime/TemplateRegistry.h: Added.
1644         * runtime/TemplateRegistryKey.h: Added.
1645         (JSC::TemplateRegistryKey::isDeletedValue):
1646         (JSC::TemplateRegistryKey::isEmptyValue):
1647         (JSC::TemplateRegistryKey::hash):
1648         (JSC::TemplateRegistryKey::rawStrings):
1649         (JSC::TemplateRegistryKey::cookedStrings):
1650         (JSC::TemplateRegistryKey::operator==):
1651         (JSC::TemplateRegistryKey::operator!=):
1652         (JSC::TemplateRegistryKey::Hasher::hash):
1653         (JSC::TemplateRegistryKey::Hasher::equal):
1654         (JSC::TemplateRegistryKey::TemplateRegistryKey):
1655         * runtime/VM.cpp:
1656         (JSC::VM::VM):
1657         * runtime/VM.h:
1658         * tests/stress/tagged-templates-identity.js: Added.
1659         (shouldBe):
1660         * tests/stress/tagged-templates-raw-strings.js: Added.
1661         (shouldBe):
1662         (tag):
1663         (testEval):
1664         * tests/stress/tagged-templates-syntax.js: Added.
1665         (tag):
1666         (testSyntax):
1667         (testSyntaxError):
1668         * tests/stress/tagged-templates-template-object.js: Added.
1669         (shouldBe):
1670         (tag):
1671         * tests/stress/tagged-templates-this.js: Added.
1672         (shouldBe):
1673         (tag):
1674         * tests/stress/tagged-templates.js: Added.
1675         (shouldBe):
1676         (raw):
1677         (cooked):
1678         (Counter):
1679
1680 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
1681
1682         REGRESSION(r180595): same-callee profiling no longer works
1683         https://bugs.webkit.org/show_bug.cgi?id=144787
1684
1685         Reviewed by Filip Pizlo.
1686
1687         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
1688         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
1689         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
1690
1691         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
1692         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
1693         our speculation that the callee is the same. To avoid recompiling the same code for different callee
1694         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
1695         LLint and baseline JIT when multiple callees are observed.
1696
1697         Tests: stress/create-this-with-callee-variants.js
1698
1699         * bytecode/BytecodeList.json: Increased the number of operands to 5.
1700         * bytecode/CodeBlock.cpp:
1701         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
1702         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
1703         * bytecompiler/BytecodeGenerator.cpp:
1704         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
1705         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
1706         operand.
1707         * dfg/DFGByteCodeParser.cpp:
1708         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
1709         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
1710         * jit/JITOpcodes.cpp:
1711         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
1712         as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
1713         (JSC::JIT::emitSlow_op_create_this):
1714         * jit/JITOpcodes32_64.cpp:
1715         (JSC::JIT::emit_op_create_this): Ditto.
1716         (JSC::JIT::emitSlow_op_create_this):
1717         * llint/LowLevelInterpreter32_64.asm:
1718         (_llint_op_create_this): Ditto.
1719         * llint/LowLevelInterpreter64.asm:
1720         (_llint_op_create_this): Ditto.
1721         * runtime/CommonSlowPaths.cpp:
1722         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
1723         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
1724         * runtime/JSCell.h:
1725         (JSC::JSCell::seenMultipleCalleeObjects): Added.
1726         * runtime/WriteBarrier.h:
1727         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
1728         * tests/stress/create-this-with-callee-variants.js: Added.
1729
1730 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1731
1732         Clean up some possible RefPtr to PassRefPtr churn
1733         https://bugs.webkit.org/show_bug.cgi?id=144779
1734
1735         Reviewed by Darin Adler.
1736
1737         * runtime/GenericTypedArrayViewInlines.h:
1738         (JSC::GenericTypedArrayView<Adaptor>::create):
1739         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
1740         * runtime/JSArrayBufferConstructor.cpp:
1741         (JSC::constructArrayBuffer):
1742         * runtime/Structure.cpp:
1743         (JSC::Structure::toStructureShape):
1744         * runtime/TypedArrayBase.h:
1745         (JSC::TypedArrayBase::create):
1746         (JSC::TypedArrayBase::createUninitialized):
1747         * tools/FunctionOverrides.cpp:
1748         (JSC::initializeOverrideInfo):
1749         Release the last use of a RefPtr as it is passed on.
1750
1751 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1752
1753         ES6: Allow duplicate property names
1754         https://bugs.webkit.org/show_bug.cgi?id=142895
1755
1756         Reviewed by Geoffrey Garen.
1757
1758         Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
1759         that will define a single getter or setter property on an object.
1760
1761         The existing `op_put_getter_setter` opcode is still preferred for
1762         putting both a getter and setter at the same time but cannot be used
1763         for putting an individual getter or setter which is needed in
1764         some cases.
1765
1766         Add a new slow path when generating bytecodes for a property list
1767         with computed properties, as computed properties are the only time
1768         the list of properties cannot be determined statically.
1769
1770         * bytecompiler/NodesCodegen.cpp:
1771         (JSC::PropertyListNode::emitBytecode):
1772         - fast path for all constant properties
1773         - slow but paired getter/setter path if there are no computed properties
1774         - slow path, individual put operation for every property, if there are computed properties
1775
1776         * parser/Nodes.h:
1777         Distinguish a Computed property from a Constant property.
1778
1779         * parser/Parser.cpp:
1780         (JSC::Parser<LexerType>::parseProperty):
1781         (JSC::Parser<LexerType>::parsePropertyMethod):
1782         Distingish Computed and Constant properties.
1783
1784         (JSC::Parser<LexerType>::parseObjectLiteral):
1785         When we drop into strict mode it is because we saw a getter
1786         or setter, so be more explicit.
1787
1788         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
1789         Eliminate duplicate property syntax error exception.
1790
1791         * parser/SyntaxChecker.h:
1792         (JSC::SyntaxChecker::getName):
1793         * parser/ASTBuilder.h:
1794         (JSC::ASTBuilder::getName): Deleted.
1795         No longer used.
1796
1797         * runtime/JSObject.h:
1798         (JSC::JSObject::putDirectInternal):
1799         When updating a property. If the Accessor attribute changed
1800         update the Structure.
1801
1802         * runtime/JSObject.cpp:
1803         (JSC::JSObject::putGetter):
1804         (JSC::JSObject::putSetter):
1805         Called by the opcodes, just perform the same operation that
1806         __defineGetter__ or __defineSetter__ would do.
1807
1808         (JSC::JSObject::putDirectNonIndexAccessor):
1809         This transition is now handled in putDirectInternal.
1810
1811         * runtime/Structure.h:
1812         Add needed export.
1813
1814         * bytecode/BytecodeList.json:
1815         * bytecode/BytecodeUseDef.h:
1816         (JSC::computeUsesForBytecodeOffset):
1817         (JSC::computeDefsForBytecodeOffset):
1818         * bytecode/CodeBlock.cpp:
1819         (JSC::CodeBlock::dumpBytecode):
1820         * bytecompiler/BytecodeGenerator.cpp:
1821         (JSC::BytecodeGenerator::emitPutGetterById):
1822         (JSC::BytecodeGenerator::emitPutSetterById):
1823         * bytecompiler/BytecodeGenerator.h:
1824         * jit/JIT.cpp:
1825         (JSC::JIT::privateCompileMainPass):
1826         * jit/JIT.h:
1827         * jit/JITInlines.h:
1828         (JSC::JIT::callOperation):
1829         * jit/JITOperations.cpp:
1830         * jit/JITOperations.h:
1831         * jit/JITPropertyAccess.cpp:
1832         (JSC::JIT::emit_op_put_getter_by_id):
1833         (JSC::JIT::emit_op_put_setter_by_id):
1834         * jit/JITPropertyAccess32_64.cpp:
1835         (JSC::JIT::emit_op_put_getter_by_id):
1836         (JSC::JIT::emit_op_put_setter_by_id):
1837         * llint/LLIntSlowPaths.cpp:
1838         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1839         * llint/LLIntSlowPaths.h:
1840         * llint/LowLevelInterpreter.asm:
1841         New bytecodes. Modelled after existing op_put_getter_setter.
1842
1843 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
1844
1845         Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
1846         https://bugs.webkit.org/show_bug.cgi?id=144856
1847
1848         Reviewed by Benjamin Poulain.
1849         
1850         First I made fixTypeForRepresentation() print out better diagnostics when it dies.
1851         
1852         Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
1853         converts to a representation-changing node, it needs to use one of the UseKinds that such
1854         a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
1855         something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
1856
1857         * dfg/DFGAbstractInterpreter.h:
1858         (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
1859         * dfg/DFGAbstractInterpreterInlines.h:
1860         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1861         * dfg/DFGAbstractValue.cpp:
1862         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
1863         * dfg/DFGAbstractValue.h:
1864         * dfg/DFGInPlaceAbstractState.cpp:
1865         (JSC::DFG::InPlaceAbstractState::initialize):
1866         * dfg/DFGNode.cpp:
1867         (JSC::DFG::Node::convertToIdentityOn):
1868         * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
1869         (foo):
1870
1871 2015-05-13  Commit Queue  <commit-queue@webkit.org>
1872
1873         Unreviewed, rolling out r184313.
1874         https://bugs.webkit.org/show_bug.cgi?id=144974
1875
1876         Introduced an assertion failure in class-syntax-
1877         declaration.js, class-syntax-expression.js, and object-
1878         literal-syntax.js (Requested by rniwa on #webkit).
1879
1880         Reverted changeset:
1881
1882         "Small refactoring before ES6 Arrow function implementation."
1883         https://bugs.webkit.org/show_bug.cgi?id=144954
1884         http://trac.webkit.org/changeset/184313
1885
1886 2015-05-13  Oliver Hunt  <oliver@apple.com>
1887         Ensure that all the smart pointer types in WTF clear their pointer before deref
1888         https://bugs.webkit.org/show_bug.cgi?id=143789
1889
1890         Reviewed by Ryosuke Niwa.
1891
1892         One of the simpler cases of this in JavaScriptCore. There
1893         are other cases where we need to guard the derefs but they
1894         are more complex cases.
1895
1896         * inspector/JSInjectedScriptHost.cpp:
1897         (Inspector::JSInjectedScriptHost::releaseImpl):
1898         * inspector/JSJavaScriptCallFrame.cpp:
1899         (Inspector::JSJavaScriptCallFrame::releaseImpl):
1900
1901 2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>
1902
1903         Small refactoring before ES6 Arrow function implementation.
1904         https://bugs.webkit.org/show_bug.cgi?id=144954
1905
1906         Reviewed by Filip Pizlo.
1907
1908         * parser/Parser.h:
1909         * parser/Parser.cpp:
1910
1911 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
1912
1913         The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
1914         https://bugs.webkit.org/show_bug.cgi?id=144945
1915
1916         Reviewed by Michael Saboff.
1917         
1918         We were making the mistake of using DFG liveness for object allocation sinking decisions.
1919         This is wrong. In fact we almost never want to use DFG liveness directly. The only place
1920         where that makes sense is pruning in DFG AI.
1921         
1922         So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
1923         liveness.
1924         
1925         In the process of doing this, I realized that the DFGForAllKills definition of combined
1926         liveness at block tail was not strictly right; it was using the bytecode liveness at the
1927         block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
1928         I changed DFGForAllKills to work in terms of CombinedLiveness.
1929         
1930         This allows me to unskip the test I added in r184260. I also added a new test that tries to
1931         trigger this bug more directly.
1932
1933         * CMakeLists.txt:
1934         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1935         * JavaScriptCore.xcodeproj/project.pbxproj:
1936         * dfg/DFGArgumentsEliminationPhase.cpp:
1937         * dfg/DFGCombinedLiveness.cpp: Added.
1938         (JSC::DFG::liveNodesAtHead):
1939         (JSC::DFG::CombinedLiveness::CombinedLiveness):
1940         * dfg/DFGCombinedLiveness.h: Added.
1941         (JSC::DFG::CombinedLiveness::CombinedLiveness):
1942         * dfg/DFGForAllKills.h:
1943         (JSC::DFG::forAllKillsInBlock):
1944         (JSC::DFG::forAllLiveNodesAtTail): Deleted.
1945         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1946         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
1947         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
1948         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
1949         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1950         * tests/stress/escape-object-in-diamond-then-exit.js: Added.
1951         * tests/stress/sink-object-past-invalid-check-sneaky.js:
1952
1953 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
1954
1955         I skipped a wrong test in r184270. Fix that.
1956         The failure is tracked by webkit.org/b/144947.
1957
1958         * tests/stress/arith-modulo-node-behaviors.js:
1959         * tests/stress/arith-mul-with-constants.js:
1960
1961 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1962
1963         Avoid always running some debug code in type profiling
1964         https://bugs.webkit.org/show_bug.cgi?id=144775
1965
1966         Reviewed by Daniel Bates.
1967
1968         * runtime/TypeProfilerLog.cpp:
1969         (JSC::TypeProfilerLog::processLogEntries):
1970
1971 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1972
1973         Pass String as reference in more places
1974         https://bugs.webkit.org/show_bug.cgi?id=144769
1975
1976         Reviewed by Daniel Bates.
1977
1978         * debugger/Breakpoint.h:
1979         (JSC::Breakpoint::Breakpoint):
1980         * parser/Parser.h:
1981         (JSC::Parser::setErrorMessage):
1982         (JSC::Parser::updateErrorWithNameAndMessage):
1983         * parser/ParserError.h:
1984         (JSC::ParserError::ParserError):
1985         * runtime/RegExp.cpp:
1986         (JSC::RegExpFunctionalTestCollector::outputOneTest):
1987         * runtime/RegExpObject.cpp:
1988         (JSC::regExpObjectSourceInternal):
1989         * runtime/TypeProfiler.cpp:
1990         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
1991         * runtime/TypeProfilerLog.cpp:
1992         (JSC::TypeProfilerLog::processLogEntries):
1993         * runtime/TypeProfilerLog.h:
1994         * tools/FunctionOverrides.cpp:
1995         (JSC::initializeOverrideInfo):
1996         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
1997         (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
1998
1999         * inspector/scripts/codegen/objc_generator_templates.py:
2000         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2001         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2002         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2003         * inspector/scripts/tests/expected/enum-values.json-result:
2004         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2005         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2006         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2007         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2008         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2009         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2010         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2011         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2012         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2013         Rebaseline tests after updating the generator.
2014
2015 2015-05-13  Michael Saboff  <msaboff@apple.com>
2016
2017         com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
2018         https://bugs.webkit.org/show_bug.cgi?id=144933
2019
2020         Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
2021         help determine the cause for any crash.
2022
2023         Reviewed by Geoffrey Garen.
2024
2025         * bytecode/CodeBlock.cpp:
2026         (JSC::CodeBlock::finalizeUnconditionally):
2027
2028 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
2029
2030         REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
2031         https://bugs.webkit.org/show_bug.cgi?id=144951
2032
2033         Reviewed by Michael Saboff.
2034         
2035         There were two issues here:
2036         
2037         - In r184260 we expected a small number of possible use kinds in Check nodes, and
2038           UntypedUse was not one of them. That seemed like a sensible assumption because we don't
2039           create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
2040           Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
2041           follow the same idiom as everyone else and not create tautological checks.
2042         
2043         - It's clearly not very robust to assume that Checks will not be used tautologically. So,
2044           this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
2045           which catches cases that AI would have already marked as unnecessary. It then also uses
2046           a new helper called alreadyChecked(), which allows us to just ask if the check is
2047           unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
2048
2049         * dfg/DFGArgumentsEliminationPhase.cpp:
2050         * dfg/DFGMayExit.cpp:
2051         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2052         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2053         * dfg/DFGSSAConversionPhase.cpp:
2054         (JSC::DFG::SSAConversionPhase::run):
2055         * dfg/DFGUseKind.h:
2056         (JSC::DFG::alreadyChecked):
2057         * dfg/DFGVarargsForwardingPhase.cpp:
2058
2059 k
2060 2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2061
2062         [ES6] Implement String.raw
2063         https://bugs.webkit.org/show_bug.cgi?id=144330
2064
2065         Reviewed by Filip Pizlo.
2066
2067         Implement String.raw. It is intended to be used with tagged-templates syntax.
2068         To implement ToString abstract operation efficiently,
2069         we introduce @toString bytecode intrinsic. It emits op_to_string directly.
2070
2071         * CMakeLists.txt:
2072         * builtins/StringConstructor.js: Added.
2073         (raw):
2074         * bytecompiler/NodesCodegen.cpp:
2075         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
2076         * runtime/CommonIdentifiers.h:
2077         * runtime/StringConstructor.cpp:
2078         * tests/stress/string-raw.js: Added.
2079         (shouldBe):
2080         (.get shouldBe):
2081         (Counter):
2082
2083 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
2084
2085         Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
2086
2087         * tests/stress/arith-mul-with-constants.js:
2088
2089 2015-05-12  Filip Pizlo  <fpizlo@apple.com>
2090
2091         js/dom/stack-trace.html fails with eager compilation
2092         https://bugs.webkit.org/show_bug.cgi?id=144853
2093
2094         Reviewed by Benjamin Poulain.
2095         
2096         All of our escape analyses were mishandling Check(). They were assuming that this is a
2097         non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
2098         candidate, then we need to do something: if we eliminate or sink @x, then the check no
2099         longer makes any sense since a phantom allocation has no type. This will make us forget
2100         that this operation would have exited. This was causing us to not call a valueOf method in
2101         js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
2102         +o where o had a valueOf method, and o was otherwise sinkable.
2103         
2104         This changes our escape analyses to basically pretend that any Check() that isn't obviously
2105         unnecessary is an escape. We don't have to be super careful here. Most checks will be
2106         completely eliminated by constant-folding. If that doesn't run in time, then the most
2107         common check we will see is CellUse. So, we just recognize some very obvious check kinds
2108         that we know would have passed, and for all of the rest we just assume that it's an escape.
2109         
2110         This was super tricky to test. The obvious way to test it is to use +o like
2111         stack-trace.html, except that doing so relies on the fact that we still haven't implemented
2112         the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
2113         
2114         1) Use +o. These will test what we want it to test for now, but at some point in the future
2115            these tests will just be a good sanity-check that our op_to_number implementation is
2116            right.
2117         
2118         2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
2119            operation always sees integers even though we eventually feed it an object and that
2120            object is a sink candidate.
2121         
2122         3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
2123            value is an int32. This intrinsic is required to be implemented by DFG by
2124            unconditionally speculating that the input is int32. This allows us to write much more
2125            targetted tests of the underlying issue.
2126         
2127         4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
2128            get regression test coverage of this test in eager mode.
2129
2130         * dfg/DFGArgumentsEliminationPhase.cpp:
2131         * dfg/DFGByteCodeParser.cpp:
2132         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2133         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2134         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2135         * dfg/DFGVarargsForwardingPhase.cpp:
2136         * ftl/FTLExitValue.cpp:
2137         (JSC::FTL::ExitValue::dumpInContext):
2138         * ftl/FTLLowerDFGToLLVM.cpp:
2139         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2140         * ftl/FTLOSRExitCompiler.cpp:
2141         (JSC::FTL::compileFTLOSRExit):
2142         * jsc.cpp:
2143         (GlobalObject::finishCreation):
2144         (functionIsInt32):
2145         * runtime/Intrinsic.h:
2146         * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
2147         * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
2148         * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
2149         * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
2150         * tests/stress/sink-arguments-past-invalid-check.js: Added.
2151         * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
2152         * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
2153         * tests/stress/sink-object-past-invalid-check-int32.js: Added.
2154         * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
2155         * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
2156         * tests/stress/sink-object-past-invalid-check.js: Added.
2157
2158 2015-05-12  Benjamin Poulain  <benjamin@webkit.org>
2159
2160         Fix the iteration count of arith-modulo-node-behaviors.js
2161
2162         * tests/stress/arith-modulo-node-behaviors.js:
2163         No need for big numbers for the real testing.
2164
2165 2015-05-12  Mark Lam  <mark.lam@apple.com>
2166
2167         Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
2168         https://bugs.webkit.org/show_bug.cgi?id=144924
2169
2170         Reviewed by Alex Christensen.
2171
2172         The present stack scanning code in the Windows port is expecting that the
2173         GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
2174         then saves and later uses that HANDLE with GetThreadContext() to get the
2175         runtime state of the target thread from the GC thread.  According to
2176         https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
2177         GetCurrentThread() does not provide this unique HANDLE that we expect:
2178
2179             "The function cannot be used by one thread to create a handle that can
2180             be used by other threads to refer to the first thread. The handle is
2181             always interpreted as referring to the thread that is using it. A
2182             thread can create a "real" handle to itself that can be used by other
2183             threads, or inherited by other processes, by specifying the pseudo
2184             handle as the source handle in a call to the DuplicateHandle function."
2185
2186         As a result of this, GetCurrentThread() always returns the same HANDLE value, and
2187         we end up never scanning the stacks of other threads because we wrongly think that
2188         they are all equal (in identity) to the scanning thread.  This, in turn, results
2189         in crashes due to objects that are incorrectly collected.
2190
2191         The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
2192         MachineThreads::Thread class already accurately tracks the period of time when
2193         we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
2194         to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
2195
2196         * heap/MachineStackMarker.cpp:
2197         (JSC::getCurrentPlatformThread):
2198         (JSC::MachineThreads::Thread::Thread):
2199         (JSC::MachineThreads::Thread::~Thread):
2200         (JSC::MachineThreads::Thread::suspend):
2201         (JSC::MachineThreads::Thread::resume):
2202         (JSC::MachineThreads::Thread::getRegisters):
2203
2204 2015-05-12  Benjamin Poulain  <bpoulain@apple.com>
2205
2206         [JSC] Make the NegZero backward propagated flags of ArithMod stricter
2207         https://bugs.webkit.org/show_bug.cgi?id=144897
2208
2209         Reviewed by Geoffrey Garen.
2210
2211         The NegZero flags of ArithMod were the same as ArithDiv: both children were
2212         marked as needing to handle NegativeZero.
2213
2214         Lucky for us, ArithMod is quite a bit different than ArithDiv.
2215
2216         First, the sign of the result is completely independent from
2217         the sign of the divisor. A zero on the divisor always produces a NaN.
2218         That's great, we can remove the NodeBytecodeNeedsNegZero
2219         from the flags propagated to child2.
2220
2221         Second, the sign of the result is always the same as the sign of
2222         the dividend. A dividend of zero produces a zero of same sign
2223         unless the divisor is zero (in which case the result is NaN).
2224         This is great too: we can just pass the flags we got into
2225         ArithMod.
2226
2227         With those two out of the way, we can make a faster version of ArithRound
2228         for Kraken's oscillator. Since we no longer care about negative zero,
2229         rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
2230         on the benchmark.
2231
2232         Unfortunatelly, most of the time is spent in FTL and the same optimization
2233         does not apply well just yet: rdar://problem/20904149.
2234
2235         * dfg/DFGBackwardsPropagationPhase.cpp:
2236         (JSC::DFG::BackwardsPropagationPhase::propagate):
2237         Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
2238
2239         * dfg/DFGSpeculativeJIT.cpp:
2240         (JSC::DFG::SpeculativeJIT::compileArithRound):
2241         Faster Math.round() when negative zero is not important.
2242
2243         * tests/stress/arith-modulo-node-behaviors.js: Added.
2244         (moduloWithNegativeZeroDividend):
2245         (moduloWithUnusedNegativeZeroDividend):
2246         (moduloWithNegativeZeroDivisor):
2247
2248 2015-05-12  Mark Lam  <mark.lam@apple.com>
2249
2250         Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
2251         https://bugs.webkit.org/show_bug.cgi?id=144925
2252
2253         Reviewed by Michael Saboff.
2254
2255         Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
2256         operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
2257         can apply better OO encapsulation and convert all these functions into methods of the
2258         MachineThreads::Thread struct.
2259
2260         This will also make it easier to reason about the fix for
2261         https://bugs.webkit.org/show_bug.cgi?id=144924 later.
2262
2263         * heap/MachineStackMarker.cpp:
2264         (JSC::getCurrentPlatformThread):
2265         (JSC::MachineThreads::Thread::createForCurrentThread):
2266         (JSC::MachineThreads::Thread::operator!=):
2267         (JSC::MachineThreads::Thread::operator==):
2268         (JSC::MachineThreads::addCurrentThread):
2269         (JSC::MachineThreads::removeThreadIfFound):
2270         (JSC::MachineThreads::Thread::suspend):
2271         (JSC::MachineThreads::Thread::resume):
2272         (JSC::MachineThreads::Thread::getRegisters):
2273         (JSC::MachineThreads::Thread::Registers::stackPointer):
2274         (JSC::MachineThreads::Thread::freeRegisters):
2275         (JSC::MachineThreads::Thread::captureStack):
2276         (JSC::MachineThreads::tryCopyOtherThreadStack):
2277         (JSC::MachineThreads::tryCopyOtherThreadStacks):
2278         (JSC::equalThread): Deleted.
2279         (JSC::suspendThread): Deleted.
2280         (JSC::resumeThread): Deleted.
2281         (JSC::getPlatformThreadRegisters): Deleted.
2282         (JSC::otherThreadStackPointer): Deleted.
2283         (JSC::freePlatformThreadRegisters): Deleted.
2284         (JSC::otherThreadStack): Deleted.
2285
2286 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
2287
2288         Array.slice should have a fast path like Array.splice
2289         https://bugs.webkit.org/show_bug.cgi?id=144901
2290
2291         Reviewed by Geoffrey Garen.
2292
2293         Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
2294         In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
2295
2296         * runtime/ArrayPrototype.cpp:
2297         (JSC::arrayProtoFuncSlice):
2298         * runtime/JSArray.cpp:
2299         (JSC::JSArray::fastSlice): Added.
2300         * runtime/JSArray.h:
2301
2302 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
2303
2304         OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
2305         https://bugs.webkit.org/show_bug.cgi?id=143078
2306
2307         Reviewed by Andreas Kling.
2308         
2309         In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
2310         pruning is actually necessary. Well, not quite: we just need to prune out keys from the
2311         heap availability map where the base node doesn't dominate the point where we are asking
2312         for availability. If we don't do this, then eventually the IR gets corrupt because we'll
2313         insert PutHints that reference the base node in places where the base node doesn't
2314         dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
2315         liveness. This is the strongest possible pruning we can do, and it should be sound. We
2316         shouldn't have a node available for a virtual register if that register is live and the
2317         node doesn't dominate.
2318         
2319         Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
2320         abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
2321
2322         * dfg/DFGAvailabilityMap.cpp:
2323         (JSC::DFG::AvailabilityMap::pruneHeap):
2324         (JSC::DFG::AvailabilityMap::pruneByLiveness):
2325         (JSC::DFG::AvailabilityMap::prune): Deleted.
2326         * dfg/DFGAvailabilityMap.h:
2327         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2328         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
2329         * ftl/FTLLowerDFGToLLVM.cpp:
2330         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2331         * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
2332         * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
2333
2334 2015-05-12  Gabor Loki  <loki@webkit.org>
2335
2336         Workaround for Cortex-A53 erratum 843419
2337         https://bugs.webkit.org/show_bug.cgi?id=144680
2338
2339         Reviewed by Michael Saboff.
2340
2341         This patch is about to give simple workaround for Cortex-A53 erratum 843419.
2342         It inserts nops after ADRP instruction to avoid wrong address accesses.
2343
2344         * assembler/ARM64Assembler.h:
2345         (JSC::ARM64Assembler::adrp):
2346         (JSC::ARM64Assembler::nopCortexA53Fix843419):
2347
2348 2015-05-11  Commit Queue  <commit-queue@webkit.org>
2349
2350         Unreviewed, rolling out r184009.
2351         https://bugs.webkit.org/show_bug.cgi?id=144900
2352
2353         Caused crashes on inspector tests (Requested by ap on
2354         #webkit).
2355
2356         Reverted changeset:
2357
2358         "MapDataImpl::add() shouldn't do the same hash lookup twice."
2359         https://bugs.webkit.org/show_bug.cgi?id=144759
2360         http://trac.webkit.org/changeset/184009
2361
2362 2015-05-11  Commit Queue  <commit-queue@webkit.org>
2363
2364         Unreviewed, rolling out r184123.
2365         https://bugs.webkit.org/show_bug.cgi?id=144899
2366
2367         Seems to have introduced flaky crashes in many JS tests
2368         (Requested by rniwa on #webkit).
2369
2370         Reverted changeset:
2371
2372         "REGRESSION(r180595): same-callee profiling no longer works"
2373         https://bugs.webkit.org/show_bug.cgi?id=144787
2374         http://trac.webkit.org/changeset/184123
2375
2376 2015-05-11  Brent Fulgham  <bfulgham@apple.com>
2377
2378         [Win] Move Windows build target to Windows 7 (or newer)
2379         https://bugs.webkit.org/show_bug.cgi?id=144890
2380         <rdar://problem/20707307>
2381
2382         Reviewed by Anders Carlsson.
2383
2384         Update linked SDK and minimal Windows level to be compatible with
2385         Windows 7 or newer.
2386
2387         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2388         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2389         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
2390         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
2391         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
2392         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
2393         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
2394         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
2395         * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
2396         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
2397         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
2398         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
2399         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
2400         * config.h:
2401
2402 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
2403
2404         CPS rethreading phase's flush detector flushes way too many SetLocals
2405         https://bugs.webkit.org/show_bug.cgi?id=144819
2406
2407         Reviewed by Geoffrey Garen.
2408         
2409         After probably unrelated changes, this eventually caused some arguments elimination to stop
2410         working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
2411         a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
2412         meant to only affect the SetLocal itself.
2413         
2414         This is a speed-up on Octane/earley.
2415
2416         * dfg/DFGCPSRethreadingPhase.cpp:
2417         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2418
2419 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
2420
2421         gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
2422         https://bugs.webkit.org/show_bug.cgi?id=144854
2423
2424         Reviewed by Oliver Hunt.
2425         
2426         This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
2427         It used to be that Construct required less code, but that's not the case for now.
2428
2429         * ftl/FTLInlineCacheSize.cpp:
2430         (JSC::FTL::sizeOfCallForwardVarargs):
2431         (JSC::FTL::sizeOfConstructVarargs):
2432         (JSC::FTL::sizeOfConstructForwardVarargs):
2433
2434 2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>
2435
2436         REGRESSION(r180595): same-callee profiling no longer works
2437         https://bugs.webkit.org/show_bug.cgi?id=144787
2438
2439         Reviewed by Michael Saboff.
2440
2441         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
2442         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
2443         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
2444
2445         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
2446         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
2447         our speculation that the callee is the same. To avoid recompiling the same code for different callee
2448         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
2449         LLint and baseline JIT when multiple callees are observed.
2450
2451         Tests: stress/create-this-with-callee-variants.js
2452
2453         * bytecode/BytecodeList.json: Increased the number of operands to 5.
2454         * bytecode/BytecodeUseDef.h:
2455         (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
2456         operands.
2457         * bytecode/CodeBlock.cpp:
2458         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
2459         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
2460         * bytecompiler/BytecodeGenerator.cpp:
2461         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
2462         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
2463         operand.
2464         * dfg/DFGByteCodeParser.cpp:
2465         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
2466         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
2467         * jit/JITOpcodes.cpp:
2468         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
2469         as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
2470         (JSC::JIT::emitSlow_op_create_this):
2471         * jit/JITOpcodes32_64.cpp:
2472         (JSC::JIT::emit_op_create_this): Ditto.
2473         (JSC::JIT::emitSlow_op_create_this):
2474         * llint/LowLevelInterpreter32_64.asm:
2475         (_llint_op_create_this): Ditto.
2476         * llint/LowLevelInterpreter64.asm:
2477         (_llint_op_create_this): Ditto.
2478         * runtime/CommonSlowPaths.cpp:
2479         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
2480         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
2481         * runtime/JSCell.h:
2482         (JSC::JSCell::seenMultipleCalleeObjects): Added.
2483         * runtime/WriteBarrier.h:
2484         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
2485         * tests/stress/create-this-with-callee-variants.js: Added.
2486
2487 2015-05-11  Andreas Kling  <akling@apple.com>
2488
2489         PropertyNameArray should use a Vector when there are few entries.
2490         <https://webkit.org/b/144874>
2491
2492         Reviewed by Geoffrey Garen.
2493
2494         Bring back an optimization that was lost in the for-in refactoring.
2495         PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
2496         enough (20) entries to justify converting to a HashSet for contains().
2497
2498         Also inlined the code while we're here, since it has so few clients and
2499         the call overhead adds up.
2500
2501         ~5% progression on Kraken/json-stringify-tinderbox.
2502
2503         * runtime/PropertyNameArray.cpp: Removed.
2504         * runtime/PropertyNameArray.h:
2505         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
2506         (JSC::PropertyNameArray::add):
2507         (JSC::PropertyNameArray::addKnownUnique):
2508
2509 2015-05-11  Matt Baker  <mattbaker@apple.com>
2510
2511         Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
2512         https://bugs.webkit.org/show_bug.cgi?id=144808
2513
2514         Reviewed by Darin Adler.
2515
2516         Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
2517         The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
2518
2519         * profiler/Profile.cpp:
2520         (JSC::Profile::create):
2521         (JSC::Profile::Profile):
2522         * profiler/Profile.h:
2523         * profiler/ProfileGenerator.cpp:
2524         (JSC::ProfileGenerator::ProfileGenerator):
2525         (JSC::AddParentForConsoleStartFunctor::operator()):
2526
2527 2015-05-11  Basile Clement  <basile_clement@apple.com>
2528
2529         Unreviewed, remove unintended change.
2530
2531         * dfg/DFGAbstractInterpreterInlines.h:
2532         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2533
2534 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
2535
2536         Make it easy to enable eager/non-concurrent JIT compilation
2537         https://bugs.webkit.org/show_bug.cgi?id=144877
2538
2539         Reviewed by Michael Saboff.
2540
2541         * runtime/Options.cpp:
2542         (JSC::recomputeDependentOptions):
2543         * runtime/Options.h:
2544
2545 2015-05-10  Filip Pizlo  <fpizlo@apple.com>
2546
2547         We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
2548         https://bugs.webkit.org/show_bug.cgi?id=144851
2549
2550         Reviewed by Michael Saboff.
2551         
2552         LoadVarargs loads arguments from some object and puts them on the stack. The region of
2553         stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
2554         shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
2555         something that uses more stack than the LoadVarargs wanted to.
2556         
2557         This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
2558         promoter. This is an important promotion rule for performance, and in cases where we are
2559         compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
2560         the phantom arguments array that this phase sees. The LoadVarargs limit is based on
2561         profiling and the phantom arguments array is a proof; in most cases the profiling is more
2562         conservative.
2563         
2564         But, you could write some crazy code where the statically obvious arguments array value is
2565         bigger than what the profiling would have told you. When this happens, this promotion
2566         effectively removes a bounds check. This either results in us clobbering a bunch of stack,
2567         or it means that we never initialize a region of the stack that a later operation will read
2568         (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
2569         unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
2570         the original LoadVarargs limit).
2571         
2572         * dfg/DFGArgumentsEliminationPhase.cpp:
2573         * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
2574         (foo):
2575         (bar):
2576         (baz):
2577         * tests/stress/load-varargs-elimination-bounds-check.js: Added.
2578         (foo):
2579         (bar):
2580         (baz):
2581
2582 2015-05-11  Andreas Kling  <akling@apple.com>
2583
2584         JSON.stringify shouldn't use generic get() to access Array.length
2585         <https://webkit.org/b/144847>
2586
2587         Reviewed by Geoffrey Garen.
2588
2589         If the value being serialized is a JSArray object, we can downcast and call its
2590         length() directly instead of doing a generic property lookup.
2591
2592         0.5% progression on Kraken/json-stringify-tinderbox.
2593
2594         * runtime/JSONObject.cpp:
2595         (JSC::Stringifier::Holder::appendNextProperty):
2596
2597 2015-05-10  Andreas Kling  <akling@apple.com>
2598
2599         Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
2600
2601         Follow up to r184050 suggested by Darin.
2602
2603         * runtime/PropertyNameArray.h:
2604
2605 2015-05-10  Andreas Kling  <akling@apple.com>
2606
2607         Remove unused things from PropertyNameArray.
2608         <https://webkit.org/b/144834>
2609
2610         Reviewed by Filip Pizlo.
2611
2612         PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
2613         was refactored and optimized last year. Then more refactoring happened and this class
2614         doesn't need to ring and toot anymore.
2615
2616         The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
2617         actually using it for anything and we were just wasting time creating these.
2618
2619         Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
2620
2621         * runtime/JSObject.cpp:
2622         (JSC::JSObject::getPropertyNames):
2623         * runtime/JSPropertyNameEnumerator.cpp:
2624         (JSC::JSPropertyNameEnumerator::create):
2625         (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
2626         * runtime/JSPropertyNameEnumerator.h:
2627         * runtime/PropertyNameArray.cpp:
2628         (JSC::PropertyNameArray::add):
2629         (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
2630         * runtime/PropertyNameArray.h:
2631         (JSC::PropertyNameArray::PropertyNameArray):
2632         (JSC::PropertyNameArray::add):
2633         (JSC::PropertyNameArray::addKnownUnique):
2634         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
2635         (JSC::RefCountedIdentifierSet::contains): Deleted.
2636         (JSC::RefCountedIdentifierSet::size): Deleted.
2637         (JSC::RefCountedIdentifierSet::add): Deleted.
2638         (JSC::PropertyNameArray::identifierSet): Deleted.
2639         (JSC::PropertyNameArray::numCacheableSlots): Deleted.
2640         (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
2641         (JSC::PropertyNameArray::setBaseObject): Deleted.
2642         (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
2643
2644 2015-05-09  Yoav Weiss  <yoav@yoav.ws>
2645
2646         Remove the PICTURE_SIZES build flag
2647         https://bugs.webkit.org/show_bug.cgi?id=144679
2648
2649         Reviewed by Benjamin Poulain.
2650
2651         Removed the PICTURE_SIZES build time flag.
2652
2653         * Configurations/FeatureDefines.xcconfig:
2654
2655 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
2656
2657         Extend the SaneChain optimization to Contiguous arrays
2658         https://bugs.webkit.org/show_bug.cgi?id=144664
2659
2660         Reviewed by Mark Lam.
2661         
2662         Previously if you loaded from a hole, you'd either have to take slow path for the array
2663         load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
2664         gathered the necessary profiling yet). But that's unnecessary if we know that the
2665         prototype chain is sane - i.e. has no indexed properties. Then we can just return
2666         Undefined for the hole.
2667         
2668         Making this change requires setting more watchpoints on the array prototype chain. But
2669         that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
2670         itself up lazily. This means that this increased the number of recompilations we'd get
2671         due to the array prototype chain being built up.
2672         
2673         So, this change also removes the laziness and static tables from ArrayPrototype.
2674         
2675         But to make that change, I also had to add a helper for eagerly building up a prototype
2676         that has builtin functions.
2677
2678         * CMakeLists.txt:
2679         * DerivedSources.make:
2680         * dfg/DFGArrayMode.h:
2681         * dfg/DFGFixupPhase.cpp:
2682         (JSC::DFG::FixupPhase::fixupNode):
2683         * dfg/DFGSpeculativeJIT32_64.cpp:
2684         (JSC::DFG::SpeculativeJIT::compile):
2685         * dfg/DFGSpeculativeJIT64.cpp:
2686         (JSC::DFG::SpeculativeJIT::compile):
2687         * ftl/FTLLowerDFGToLLVM.cpp:
2688         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2689         * runtime/ArrayPrototype.cpp:
2690         (JSC::ArrayPrototype::finishCreation):
2691         (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
2692         * runtime/ArrayPrototype.h:
2693         * runtime/JSObject.h:
2694
2695 2015-05-08  Michael Saboff  <msaboff@apple.com>
2696
2697         Creating a large MarkedBlock sometimes results in more than one cell in the block
2698         https://bugs.webkit.org/show_bug.cgi?id=144815
2699
2700         Reviewed by Mark Lam.
2701
2702         Large MarkedBlocks should have one and only one cell.  Changed the calculation of
2703         m_endAtom for large blocks to use the location of the first cell + 1.  This
2704         assures that large blocks only have one cell.
2705
2706         * heap/MarkedBlock.cpp:
2707         (JSC::MarkedBlock::MarkedBlock):
2708
2709 2015-05-08  Oliver Hunt  <oliver@apple.com>
2710
2711         MapDataImpl::add() shouldn't do the same hash lookup twice.
2712         https://bugs.webkit.org/show_bug.cgi?id=144759
2713
2714         Reviewed by Gavin Barraclough.
2715
2716         We don't actually need to do a double lookup here, all we need to
2717         do is update the index to point to the correct m_size.
2718
2719         * runtime/MapDataInlines.h:
2720         (JSC::JSIterator>::add):
2721
2722 2015-05-08  Andreas Kling  <akling@apple.com>
2723
2724         Micro-optimize JSON serialization of string primitives.
2725         <https://webkit.org/b/144800>
2726
2727         Reviewed by Sam Weinig.
2728
2729         Don't use the out-of-line JSValue::getString() to grab at string primitives
2730         in serialization. Just check if it's a JSString and then downcast to grab at
2731         the WTF::String inside.
2732
2733         2% progression on Kraken/json-stringify-tinderbox.
2734
2735         * runtime/JSONObject.cpp:
2736         (JSC::Stringifier::appendStringifiedValue):
2737
2738 2015-05-08  Andreas Kling  <akling@apple.com>
2739
2740         Optimize serialization of quoted JSON strings.
2741         <https://webkit.org/b/144754>
2742
2743         Reviewed by Darin Adler.
2744
2745         Optimized the serialization of quoted strings into JSON by moving the logic into
2746         StringBuilder so it can make smarter decisions about buffering.
2747
2748         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
2749
2750         * bytecompiler/NodesCodegen.cpp:
2751         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
2752
2753         * runtime/JSONObject.h:
2754         * runtime/JSONObject.cpp:
2755         (JSC::Stringifier::Holder::appendNextProperty):
2756         (JSC::appendStringToStringBuilder): Deleted.
2757         (JSC::appendQuotedJSONStringToBuilder): Deleted.
2758         (JSC::Stringifier::appendQuotedString): Deleted.
2759         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
2760         to StringBuilder and call that from here.
2761
2762 2015-05-07  Commit Queue  <commit-queue@webkit.org>
2763
2764         Unreviewed, rolling out r183961.
2765         https://bugs.webkit.org/show_bug.cgi?id=144784
2766
2767         Broke js/dom/JSON-stringify.html (Requested by kling on
2768         #webkit).
2769
2770         Reverted changeset:
2771
2772         "Optimize serialization of quoted JSON strings."
2773         https://bugs.webkit.org/show_bug.cgi?id=144754
2774         http://trac.webkit.org/changeset/183961
2775
2776 2015-05-07  Filip Pizlo  <fpizlo@apple.com>
2777
2778         GC has trouble with pathologically large array allocations
2779         https://bugs.webkit.org/show_bug.cgi?id=144609
2780
2781         Reviewed by Geoffrey Garen.
2782
2783         The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
2784         after pinning them), and would skip the accounting. The GC calculates the size of the heap
2785         in tandem with the scan to save time, and that accounting was part of how the GC would
2786         know how big the heap was. The GC would then think that oversize copied blocks use no
2787         memory, and would then mess up its scheduling of the next GC.
2788         
2789         Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
2790         size by summing the size from the last collection and the size by walking the eden heap.
2791         But this breaks when we eagerly delete objects that the last collection touched. We can do
2792         that in one corner case: copied block reallocation. The old block will be deleted from old
2793         space during the realloc and a new block will be allocated in new space. In order for the
2794         GC to know that the size of old space actually shrank, we need a field to tell us how much
2795         such shrinkage could occur. Since this is a very dirty corner case and it only works for
2796         very particular reasons arising from the special properties of copied space (single owner,
2797         and the realloc is used in places where the compiler already knows that it cannot register
2798         allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
2799         devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
2800         
2801         To test this, I needed to add an Option to force a particular RAM size in the GC. This
2802         allows us to write tests that assert that the GC heap size is some value X, without
2803         worrying about machine-to-machine variations due to GC heuristics changing based on RAM
2804         size.
2805
2806         * heap/CopiedSpace.cpp:
2807         (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
2808         (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
2809         * heap/CopiedSpace.h:
2810         (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
2811         * heap/Heap.cpp:
2812         (JSC::Heap::Heap): Allow the user to force the RAM size.
2813         (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
2814         * heap/SlotVisitorInlines.h:
2815         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
2816         * jsc.cpp: Add size measuring hooks to write the largeish test.
2817         (GlobalObject::finishCreation):
2818         (functionGCAndSweep):
2819         (functionFullGC):
2820         (functionEdenGC):
2821         (functionHeapSize):
2822         * runtime/Options.h:
2823         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
2824         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
2825         (foo):
2826         (test):
2827
2828 2015-05-07  Saam Barati  <saambarati1@gmail.com>
2829
2830         Global functions should be initialized as JSFunctions in byte code
2831         https://bugs.webkit.org/show_bug.cgi?id=144178
2832
2833         Reviewed by Geoffrey Garen.
2834
2835         This patch makes the initialization of global functions more explicit by
2836         moving initialization into bytecode. It also prepares JSC for having ES6
2837         style lexical scoping because initializing global functions in bytecode
2838         easily allows global functions to be initialized with the proper scope that
2839         will have access to global lexical variables. Global lexical variables
2840         should be visible to global functions but don't live on the global object.
2841
2842         * bytecode/UnlinkedCodeBlock.cpp:
2843         (JSC::UnlinkedProgramCodeBlock::visitChildren):
2844         * bytecode/UnlinkedCodeBlock.h:
2845         * bytecompiler/BytecodeGenerator.cpp:
2846         (JSC::BytecodeGenerator::generate):
2847         (JSC::BytecodeGenerator::BytecodeGenerator):
2848         * bytecompiler/BytecodeGenerator.h:
2849         * runtime/Executable.cpp:
2850         (JSC::ProgramExecutable::initializeGlobalProperties):
2851         * runtime/JSGlobalObject.cpp:
2852         (JSC::JSGlobalObject::addGlobalVar):
2853         (JSC::JSGlobalObject::addFunction):
2854         * runtime/JSGlobalObject.h:
2855
2856 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
2857
2858         Fix the x86 32bits build
2859
2860         * assembler/X86Assembler.h:
2861
2862 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
2863
2864         [JSC] Add basic DFG/FTL support for Math.round
2865         https://bugs.webkit.org/show_bug.cgi?id=144725
2866
2867         Reviewed by Filip Pizlo.
2868
2869         This patch adds two optimizations targeting Math.round():
2870         -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
2871         -Change the MacroAssembler to be stricter on how we fail to convert a double
2872          to ingeter. Previously, any number valued zero would fail, now we only
2873          fail for -0.
2874
2875         Since ArithRound speculate it produces int32, the MacroAssembler assembler
2876         part became necessary because zero is a pretty common output of Math.round()
2877         and we would OSR exit a lot (and eventually recompile for doubles).
2878
2879         The implementation itself of the inline Math.round() is exactly the same
2880         as the C function that exists for Math.round(). We can very likely do better
2881         but it is a good start known to be valid and inlining alone alread provides
2882         significant speedups.
2883
2884         * assembler/X86Assembler.h:
2885         (JSC::X86Assembler::movmskpd_rr):
2886         * assembler/MacroAssemblerX86Common.h:
2887         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
2888         When we have a zero, get the sign bit out of the double and check if is one.
2889
2890         I'll look into doing the same improvement for ARM.
2891
2892         * bytecode/SpeculatedType.cpp:
2893         (JSC::typeOfDoubleRounding):
2894         (JSC::typeOfDoubleFRound): Deleted.
2895         * bytecode/SpeculatedType.h:
2896         * dfg/DFGAbstractInterpreterInlines.h:
2897         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2898         * dfg/DFGByteCodeParser.cpp:
2899         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2900         * dfg/DFGClobberize.h:
2901         (JSC::DFG::clobberize):
2902         * dfg/DFGDoesGC.cpp:
2903         (JSC::DFG::doesGC):
2904         * dfg/DFGFixupPhase.cpp:
2905         (JSC::DFG::FixupPhase::fixupNode):
2906         * dfg/DFGGraph.h:
2907         (JSC::DFG::Graph::roundShouldSpeculateInt32):
2908         (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
2909         * dfg/DFGNode.h:
2910         (JSC::DFG::Node::arithNodeFlags):
2911         (JSC::DFG::Node::hasHeapPrediction):
2912         (JSC::DFG::Node::hasArithMode):
2913         * dfg/DFGNodeType.h:
2914         * dfg/DFGPredictionPropagationPhase.cpp:
2915         (JSC::DFG::PredictionPropagationPhase::propagate):
2916         * dfg/DFGSafeToExecute.h:
2917         (JSC::DFG::safeToExecute):
2918         * dfg/DFGSpeculativeJIT.cpp:
2919         (JSC::DFG::SpeculativeJIT::compileArithRound):
2920         * dfg/DFGSpeculativeJIT.h:
2921         * dfg/DFGSpeculativeJIT32_64.cpp:
2922         (JSC::DFG::SpeculativeJIT::compile):
2923         * dfg/DFGSpeculativeJIT64.cpp:
2924         (JSC::DFG::SpeculativeJIT::compile):
2925         * ftl/FTLCapabilities.cpp:
2926         (JSC::FTL::canCompile):
2927         * ftl/FTLIntrinsicRepository.h:
2928         * ftl/FTLLowerDFGToLLVM.cpp:
2929         (JSC::FTL::LowerDFGToLLVM::compileNode):
2930         (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
2931         (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
2932         (JSC::FTL::LowerDFGToLLVM::compileArithRound):
2933         * ftl/FTLOutput.h:
2934         (JSC::FTL::Output::ceil64):
2935         * jit/ThunkGenerators.cpp:
2936         * runtime/MathCommon.cpp:
2937         * runtime/MathCommon.h:
2938         * runtime/MathObject.cpp:
2939         (JSC::mathProtoFuncRound):
2940         * tests/stress/math-round-basics.js: Added.
2941         (mathRoundOnIntegers):
2942         (mathRoundOnDoubles):
2943         (mathRoundOnBooleans):
2944         (uselessMathRound):
2945         (mathRoundWithOverflow):
2946         (mathRoundConsumedAsDouble):
2947         (mathRoundDoesNotCareAboutMinusZero):
2948         (mathRoundNoArguments):
2949         (mathRoundTooManyArguments):
2950         (testMathRoundOnConstants):
2951         (mathRoundStructTransition):
2952         (Math.round):
2953
2954 2015-05-07  Saam Barati  <saambarati1@gmail.com>
2955
2956         exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
2957         https://bugs.webkit.org/show_bug.cgi?id=144753
2958
2959         Reviewed by Mark Lam.
2960
2961         This allows the BytecodeGenerator to freely emit startup code that "may"
2962         throw exceptions without worrying that this startup code will trigger
2963         the exceptionFuzz exception. The exceptionFuzz counter will only begin
2964         ticking when the 'enableExceptionFuzz' function is explicitly called in 
2965         the exceptionFuzz tests.
2966
2967         * jsc.cpp:
2968         (GlobalObject::finishCreation):
2969         (functionEnableExceptionFuzz):
2970         * tests/exceptionFuzz/3d-cube.js:
2971         * tests/exceptionFuzz/date-format-xparb.js:
2972         * tests/exceptionFuzz/earley-boyer.js:
2973
2974 2015-05-07  Andreas Kling  <akling@apple.com>
2975
2976         Optimize serialization of quoted JSON strings.
2977         <https://webkit.org/b/144754>
2978
2979         Reviewed by Darin Adler.
2980
2981         Optimized the serialization of quoted strings into JSON by moving the logic into
2982         StringBuilder so it can make smarter decisions about buffering.
2983
2984         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
2985
2986         * bytecompiler/NodesCodegen.cpp:
2987         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
2988
2989         * runtime/JSONObject.h:
2990         * runtime/JSONObject.cpp:
2991         (JSC::Stringifier::Holder::appendNextProperty):
2992         (JSC::appendStringToStringBuilder): Deleted.
2993         (JSC::appendQuotedJSONStringToBuilder): Deleted.
2994         (JSC::Stringifier::appendQuotedString): Deleted.
2995         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
2996         to StringBuilder and call that from here.
2997
2998 2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2999
3000         FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
3001         https://bugs.webkit.org/show_bug.cgi?id=144678
3002
3003         Reviewed by Geoffrey Garen.
3004
3005         Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
3006         But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
3007
3008         function t() { var ok = {null: function () { } }; ok[ok = null](); }
3009         t();  // Should not throw error.
3010
3011         This patch takes care about `subscriptHasAssignment`.
3012         By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
3013         it correctly moves the LHS value to a temporary register.
3014
3015         * bytecompiler/NodesCodegen.cpp:
3016         (JSC::FunctionCallBracketNode::emitBytecode):
3017         * parser/ASTBuilder.h:
3018         (JSC::ASTBuilder::makeFunctionCallNode):
3019         * parser/NodeConstructors.h:
3020         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
3021         * parser/Nodes.h:
3022         * tests/stress/assignment-in-function-call-bracket-node.js: Added.
3023         (shouldBe):
3024         (shouldBe.):
3025
3026 2015-05-07  Basile Clement  <basile_clement@apple.com>
3027
3028         Unreviewed, add missing braces on a single-line if that got expanded in r183939
3029
3030         * ftl/FTLLowerDFGToLLVM.cpp:
3031         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
3032
3033 2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>
3034
3035         Revert "Introducing the Platform Abstraction Layer (PAL)"
3036         https://bugs.webkit.org/show_bug.cgi?id=144751
3037
3038         Unreviewed.
3039
3040         PAL should be a new target inside WebCore, rather than a top-level folder.
3041
3042         * Configurations/FeatureDefines.xcconfig: Updated
3043
3044 2015-05-07  Basile Clement  <basile_clement@apple.com>
3045
3046         Dumping OSR ExitValue should expand materializations only once
3047         https://bugs.webkit.org/show_bug.cgi?id=144694
3048
3049         Reviewed by Filip Pizlo.
3050
3051         Currently, dumping OSR exit values will print the full materialization
3052         information each time it is encountered. We change it to print only a
3053         brief description (only the materialization's address), and print the
3054         whole set of materializations later on.
3055
3056         This makes the dump less confusing (less likely to think that two
3057         instances of the same materialization are different), and will be a
3058         necessary change if/when we support materialization cycles.
3059
3060         * ftl/FTLCompile.cpp:
3061         (JSC::FTL::mmAllocateDataSection):
3062         * ftl/FTLExitValue.cpp:
3063         (JSC::FTL::ExitValue::dumpInContext):
3064         * ftl/FTLLowerDFGToLLVM.cpp:
3065         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
3066
3067 2015-05-07  Andreas Kling  <akling@apple.com>
3068
3069         Worker threads leak WeakBlocks (as seen on leaks bot)
3070         <https://webkit.org/b/144721>
3071         <rdar://problem/20848288>
3072
3073         Reviewed by Darin Adler.
3074
3075         Nuke any remaining empty WeakBlocks when the Heap is being torn down.
3076         Trying to peek into these blocks after the VM is dead would be a bug anyway.
3077
3078         This fixes a ~750 KB leak seen on the leaks bot.
3079
3080         * heap/Heap.cpp:
3081         (JSC::Heap::~Heap):
3082
3083 2015-05-05  Geoffrey Garen  <ggaren@apple.com>
3084
3085         Don't branch when accessing the callee
3086         https://bugs.webkit.org/show_bug.cgi?id=144645
3087
3088         Reviewed by Michael Saboff.
3089
3090         The branch was added in <http://trac.webkit.org/changeset/81040> without
3091         explanation.
3092
3093         kling found it to be a performance problem. See <https://webkit.org/b/144586>.
3094
3095         Our theory of access to Registers is that it's up to the client to access
3096         them in the right way. So, let's do that.
3097
3098         * interpreter/CallFrame.h:
3099         (JSC::ExecState::callee):
3100         (JSC::ExecState::setCallee): Call the field object instead of function
3101         because nothing guarantees that it's a function.
3102         * interpreter/ProtoCallFrame.h:
3103         (JSC::ProtoCallFrame::callee):
3104         (JSC::ProtoCallFrame::setCallee):
3105         * interpreter/Register.h:
3106         * runtime/JSObject.h:
3107         (JSC::Register::object): Just do a cast like our other accessors do.
3108         (JSC::Register::operator=):
3109         (JSC::Register::function): Deleted.
3110         (JSC::Register::withCallee): Deleted.
3111
3112 2015-05-07  Dan Bernstein  <mitz@apple.com>
3113
3114         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
3115         https://bugs.webkit.org/show_bug.cgi?id=144727
3116
3117         Reviewed by Darin Adler.
3118
3119         * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
3120         INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
3121
3122 2015-05-07  Andreas Kling  <akling@apple.com>
3123
3124         Special-case Int32 values in JSON.stringify().
3125         <https://webkit.org/b/144731>
3126
3127         Reviewed by Michael Saboff.
3128
3129         Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
3130         simple integers through the full-blown dtoa() machinery.
3131
3132         ~50% speedup on Kraken/json-stringify-tinderbox.
3133
3134         * runtime/JSONObject.cpp:
3135         (JSC::Stringifier::appendStringifiedValue):
3136
3137 2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>
3138
3139         ToT WebKit crashes while loading ES6 compatibility table
3140         https://bugs.webkit.org/show_bug.cgi?id=144726
3141
3142         Reviewed by Filip Pizlo.
3143
3144         The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
3145
3146         Always build the identifier here as it could be a method name.
3147
3148         * parser/Parser.cpp:
3149         (JSC::Parser<LexerType>::parseClass):
3150
3151 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3152
3153         Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
3154         https://bugs.webkit.org/show_bug.cgi?id=144665
3155
3156         Reviewed by Michael Saboff.
3157         
3158         This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
3159         extending SaneChain to all indexing shapes.
3160
3161         * dfg/DFGFixupPhase.cpp:
3162         (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
3163         (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
3164         * dfg/DFGSpeculativeJIT.cpp:
3165         (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
3166         * dfg/DFGWatchpointCollectionPhase.cpp:
3167         (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
3168         (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
3169         * ftl/FTLLowerDFGToLLVM.cpp:
3170         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
3171
3172 2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>
3173
3174         Introducing the Platform Abstraction Layer (PAL)
3175         https://bugs.webkit.org/show_bug.cgi?id=143358
3176
3177         Reviewed by Simon Fraser.
3178
3179         * Configurations/FeatureDefines.xcconfig: Updated
3180
3181 2015-05-06  Andreas Kling  <akling@apple.com>
3182
3183         Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
3184         <https://webkit.org/b/144676>
3185
3186         Reviewed by Darin Adler.
3187
3188         We were creating a new String for every number JSValue passing through the JSON stringifier.
3189         These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
3190         Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
3191         for the conversion instead.
3192
3193         13% progression on Kraken/json-stringify-tinderbox.
3194
3195         * runtime/JSONObject.cpp:
3196         (JSC::Stringifier::appendStringifiedValue):
3197
3198 2015-05-06  Commit Queue  <commit-queue@webkit.org>
3199
3200         Unreviewed, rolling out r183847.
3201         https://bugs.webkit.org/show_bug.cgi?id=144691
3202
3203         Caused many assertion failures (Requested by ap on #webkit).
3204
3205         Reverted changeset:
3206
3207         "GC has trouble with pathologically large array allocations"
3208         https://bugs.webkit.org/show_bug.cgi?id=144609
3209         http://trac.webkit.org/changeset/183847
3210
3211 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3212
3213         PutGlobalVar shouldn't have an unconditional store barrier
3214         https://bugs.webkit.org/show_bug.cgi?id=133104
3215
3216         Reviewed by Benjamin Poulain.
3217         
3218         We don't need a store barrier on PutGlobalVar if the value being stored can be
3219         speculated to not be a cell.
3220
3221         * dfg/DFGFixupPhase.cpp:
3222         (JSC::DFG::FixupPhase::fixupNode):
3223
3224 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3225
3226         CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
3227         https://bugs.webkit.org/show_bug.cgi?id=144667
3228
3229         Reviewed by Andreas Kling.
3230         
3231         We are now calling this method for oversize blocks. It had an assertion that indirectly
3232         implied that the block is not oversize, because it was claiming that the number of live
3233         bytes should be smaller than the non-oversize-block size.
3234
3235         * heap/CopiedBlockInlines.h:
3236         (JSC::CopiedBlock::reportLiveBytes):
3237
3238 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3239
3240         GC has trouble with pathologically large array allocations
3241         https://bugs.webkit.org/show_bug.cgi?id=144609
3242
3243         Reviewed by Mark Lam.
3244
3245         * heap/Heap.cpp:
3246         (JSC::Heap::updateObjectCounts): Make this code less confusing.
3247         * heap/SlotVisitorInlines.h:
3248         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
3249         * jsc.cpp: Add size measuring hooks to write the largeish test.
3250         (GlobalObject::finishCreation):
3251         (functionGCAndSweep):
3252         (functionFullGC):
3253         (functionEdenGC):
3254         (functionHeapSize):
3255         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
3256         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
3257         (foo):
3258         (test):
3259
3260 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3261
3262         FTL SwitchString slow case creates duplicate switch cases
3263         https://bugs.webkit.org/show_bug.cgi?id=144634
3264
3265         Reviewed by Geoffrey Garen.
3266         
3267         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
3268         added mostly-debug-only asserts to catch such issues earlier.
3269
3270         * bytecode/CallVariant.cpp:
3271         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
3272         * ftl/FTLLowerDFGToLLVM.cpp:
3273         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
3274         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
3275         * jit/BinarySwitch.cpp:
3276         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
3277         * jit/Repatch.cpp:
3278         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
3279         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
3280         (foo):
3281         (cat):
3282
3283 2015-05-05  Basile Clement  <basile_clement@apple.com>
3284
3285         Fix debug builds after r183812
3286         https://bugs.webkit.org/show_bug.cgi?id=144300
3287
3288         Rubber stamped by Andreas Kling and Filip Pizlo.
3289
3290         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
3291         as having materialization data, which was causing an assertion failure when
3292         sinking CreateActivations on debug builds.
3293
3294         * dfg/DFGNode.h:
3295         (JSC::DFG::Node::hasObjectMaterializationData):
3296
3297 2015-05-04  Basile Clement  <basile_clement@apple.com>
3298
3299         Allow CreateActivation sinking
3300         https://bugs.webkit.org/show_bug.cgi?id=144300
3301
3302         Reviewed by Filip Pizlo.
3303
3304         This pursues the work started in
3305         https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
3306         allocations we are able to sink by allowing sinking of CreateActivation
3307         node.
3308
3309         This is achieved by following closely the way NewObject is currently
3310         sunk: we add a new PhantomCreateActivation node to record the initial
3311         position of the CreateActivation node, new ClosureVarPLoc promoted heap
3312         locations to keep track of the variables put in the activation, and a
3313         new MaterializeCreateActivation node to allocate and populate the sunk
3314         activation.
3315
3316         * dfg/DFGAbstractInterpreterInlines.h:
3317         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3318         * dfg/DFGClobberize.h:
3319         (JSC::DFG::clobberize):
3320         * dfg/DFGDoesGC.cpp:
3321         (JSC::DFG::doesGC):
3322         * dfg/DFGFixupPhase.cpp:
3323         (JSC::DFG::FixupPhase::fixupNode):
3324         * dfg/DFGNode.cpp:
3325         (JSC::DFG::Node::convertToPutClosureVarHint):
3326         * dfg/DFGNode.h:
3327         (JSC::DFG::Node::convertToPhantomCreateActivation):
3328         (JSC::DFG::Node::isActivationAllocation):
3329         (JSC::DFG::Node::isPhantomActivationAllocation):
3330         (JSC::DFG::Node::isPhantomAllocation):
3331         * dfg/DFGNodeType.h:
3332         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3333         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
3334         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
3335         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
3336         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
3337         * dfg/DFGPredictionPropagationPhase.cpp:
3338         (JSC::DFG::PredictionPropagationPhase::propagate):
3339         * dfg/DFGPromotedHeapLocation.cpp:
3340         (WTF::printInternal):