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