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