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