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