Optimize WeakBlock's "reap" and "visit" operations.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-04  Andreas Kling  <akling@apple.com>
2
3         Optimize WeakBlock's "reap" and "visit" operations.
4         <https://webkit.org/b/144585>
5
6         Reviewed by Geoffrey Garen.
7
8         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
9         That function was really written with conservative roots marking in mind, and will do a bunch
10         of sanity and bounds checks.
11
12         For weaks, we know that the pointer will have been a valid cell pointer into a block
13         of appropriate cell size, so we can skip a lot of the checks.
14
15         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
16         MarkedBlock::blockFor() for every single cell when iterating.
17
18         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
19         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
20         be pointing to any live cells, and the only operation that will run on the block is sweep().
21
22         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
23         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
24         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
25
26         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
27         what looks like a 1% speedup locally.
28
29         * heap/MarkedBlock.cpp:
30         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
31
32         * heap/MarkedBlock.h:
33         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
34         block's state is known to be either Marked or Retired.
35
36         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
37         would report that all cells are live anyway.
38
39         * heap/WeakBlock.cpp:
40         (JSC::WeakBlock::create):
41         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
42
43         (JSC::WeakBlock::visit):
44         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
45
46         * heap/WeakBlock.h:
47         (JSC::WeakBlock::disconnectMarkedBlock): Added.
48         * heap/WeakSet.cpp:
49         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
50         ownership to Heap until it can die peacefully.
51
52         (JSC::WeakSet::addAllocator):
53         * heap/WeakSet.h:
54         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
55
56 2015-05-04  Basile Clement  <basile_clement@apple.com>
57
58         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
59         https://bugs.webkit.org/show_bug.cgi?id=144587
60
61         Rubber stamped by Filip Pizlo.
62
63         When sinking object allocations, we ensure in
64         determineMaterializationPoints that whenever an allocation is
65         materialized on a path to a block, it is materialized in all such
66         paths. Thus when running the SSA calculator to place Phis in
67         placeMaterializationPoints, we can't encounter a situation where some
68         Upsilons are referring to a materialization while others are referring
69         to the phantom object.
70
71         This replaces the code that was adding a materialization late in
72         placeMaterializationPoints to handle that case by an assertion that it
73         does not happen, which will make
74         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
75
76         * dfg/DFGObjectAllocationSinkingPhase.cpp:
77         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
78
79 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
80
81         Extending undefined in class syntax should throw a TypeError
82         https://bugs.webkit.org/show_bug.cgi?id=144284
83
84         Reviewed by Darin Adler.
85
86         The bug was caused by op_eq_null evaluating to true when compared to undefined.
87         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
88
89         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
90
91         * bytecompiler/NodesCodegen.cpp:
92         (JSC::ClassExprNode::emitBytecode):
93
94 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
95
96         new super should be a syntax error
97         https://bugs.webkit.org/show_bug.cgi?id=144282
98
99         Reviewed by Joseph Pecoraro.
100
101         Disallow "new super" as ES6 spec doesn't allow this.
102
103         * parser/Parser.cpp:
104         (JSC::Parser<LexerType>::parseMemberExpression):
105
106 2015-05-04  Saam Barati  <saambarati1@gmail.com>
107
108         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
109         https://bugs.webkit.org/show_bug.cgi?id=144265
110
111         Reviewed by Geoffrey Garen.
112
113         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
114         for a static function if the parent has that property slot. JSCallbackObject::put 
115         did not maintain this symmetry of also calling ::put on the parent if the parent 
116         has the property. We should ensure that this symmetry exists.
117
118         * API/JSCallbackObjectFunctions.h:
119         (JSC::JSCallbackObject<Parent>::put):
120         * API/tests/testapi.c:
121         * API/tests/testapi.js:
122         (globalStaticFunction2):
123         (this.globalStaticFunction2):
124         (iAmNotAStaticFunction):
125         (this.iAmNotAStaticFunction):
126
127 2015-05-04  Andreas Kling  <akling@apple.com>
128
129         Make ExecState::vm() branchless in release builds.
130         <https://webkit.org/b/144586>
131
132         Reviewed by Geoffrey Garen.
133
134         Avoid null checking the ExecState's callee() before getting the
135         VM from it. The code was already dereferencing it anyway, since we
136         know it's not gonna be null.
137
138         * runtime/JSCellInlines.h:
139         (JSC::ExecState::vm):
140
141 2015-05-04  Basile Clement  <basile_clement@apple.com>
142
143         Object allocation not sinking properly through CheckStructure
144         https://bugs.webkit.org/show_bug.cgi?id=144465
145
146         Reviewed by Filip Pizlo.
147
148         Currently, sinking an allocation through a CheckStructure will
149         completely ignore all structure checking, which is obviously wrong.
150
151         A CheckStructureImmediate node type was present for that purpose, but
152         the CheckStructures were not properly replaced.  This ensures that
153         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
154         sunk through, and that structure checking happens correctly.
155
156         * dfg/DFGNode.h:
157         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
158         (JSC::DFG::Node::hasStructureSet):
159         * dfg/DFGObjectAllocationSinkingPhase.cpp:
160         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
161         * ftl/FTLLowerDFGToLLVM.cpp:
162         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
163         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
164         (JSC::FTL::LowerDFGToLLVM::checkStructure):
165         * tests/stress/sink_checkstructure.js: Added.
166         (foo):
167
168 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
169
170         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
171         https://bugs.webkit.org/show_bug.cgi?id=144476
172
173         Reviewed by Sam Weinig.
174
175         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
176
177         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
178         to my knowledge, the topic of how to optimize it is not covered in any
179         literature about sorting.
180
181         On the slowest jQuery sorting test -- prevAll -- our new
182         Array.prototype.sort, compared to its predecessor, performed 12% fewer
183         comparisons and requireed 10X less overhead per comparison. Yet, it was
184         slower.
185
186         It was slower because it inadvertantly increased the average cost of the
187         comparison function by 2X. jQuery uses compareDocumentPosition to compare
188         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
189         required to traverse backwards from b to a. In prevAll, we encounter the
190         worst case for merge sort of compareDocumentPosition: A long list of DOM
191         nodes in mostly reverse order. In this case, merge sort will sequentially
192         compareDocumentPosition(a, b), where a is not reachable backwards from
193         b, and therefore compareDocumentPosition will traverse the whole sibling
194         list.
195
196         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
197
198         This is a pretty silly thing to do, but it is harmless, and jQuery is
199         popular, so let's do it.
200
201         We do not risk suffering the same problem in reverse when sorting a long
202         list of DOM nodes in forward order. (We still have a 37% speedup on the
203         nextAll benchmark.) The reason is that merge sort performs 2X fewer
204         comparisons when the list is already sorted, so we can worry less about
205         the cost of each comparison.
206
207         A fully principled soultion to this problem would probably do something
208         like Python's timsort, which special-cases ordered ranges to perform
209         only O(n) comparisons. But that would contradict our original
210         goal of just having something simple that works.
211
212         Another option is for elements to keep a compareDocumentPosition cache,
213         like a node list cache, which allows you to determine the absolute
214         position of a node using a hash lookup. I will leave this as an exercise
215         for kling.
216
217         * builtins/Array.prototype.js:
218         (sort.merge): Compare in an order that is favorable to a comparator
219         that calls compareDocumentPosition.
220
221 2015-05-04  Csaba Osztrogon√°c  <ossy@webkit.org>
222
223         [cmake] Fix generate-js-builtins related incremental build issue
224         https://bugs.webkit.org/show_bug.cgi?id=144094
225
226         Reviewed by Michael Saboff.
227
228         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
229         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
230         * DerivedSources.make:
231         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
232         * generate-js-builtins: Accept input files and input directory too.
233
234 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
235
236         Make some static data const
237         https://bugs.webkit.org/show_bug.cgi?id=144552
238
239         Reviewed by Andreas Kling.
240         
241         Turn characterSetInfo into const data.
242
243         * yarr/YarrCanonicalizeUCS2.cpp:
244         * yarr/YarrCanonicalizeUCS2.h:
245
246 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
247
248         TypeOf should be fast
249         https://bugs.webkit.org/show_bug.cgi?id=144396
250
251         Reviewed by Geoffrey Garen.
252         
253         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
254         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
255         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
256         
257         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
258         rely heavily on C++ calls to fulfill their function.
259         
260         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
261         
262         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
263         This means that if the TypeOf is dominated by any type checks, we will automatically prune
264         out cases that are redundant.
265         
266         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
267         code generation is designed to be reusable.
268         
269         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
270         the exotic call trap hook. That hook is now in a deeper slow path than before.
271
272         * CMakeLists.txt:
273         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
274         * JavaScriptCore.xcodeproj/project.pbxproj:
275         * dfg/DFGClobberize.h:
276         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
277         * dfg/DFGFixupPhase.cpp:
278         (JSC::DFG::FixupPhase::fixupNode):
279         * dfg/DFGHeapLocation.cpp:
280         (WTF::printInternal):
281         * dfg/DFGHeapLocation.h:
282         * dfg/DFGOperations.cpp:
283         * dfg/DFGOperations.h:
284         * dfg/DFGSpeculativeJIT.cpp:
285         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
286         (JSC::DFG::SpeculativeJIT::compileIsFunction):
287         (JSC::DFG::SpeculativeJIT::compileTypeOf):
288         * dfg/DFGSpeculativeJIT.h:
289         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
290         (JSC::DFG::SpeculativeJIT::callOperation):
291         * dfg/DFGSpeculativeJIT32_64.cpp:
292         (JSC::DFG::SpeculativeJIT::compile):
293         * dfg/DFGSpeculativeJIT64.cpp:
294         (JSC::DFG::SpeculativeJIT::compile):
295         * ftl/FTLCapabilities.cpp:
296         (JSC::FTL::canCompile):
297         * ftl/FTLIntrinsicRepository.h:
298         * ftl/FTLLowerDFGToLLVM.cpp:
299         (JSC::FTL::LowerDFGToLLVM::compileNode):
300         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
301         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
302         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
303         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
304         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
305         * ftl/FTLSwitchCase.h:
306         (JSC::FTL::SwitchCase::SwitchCase):
307         * jit/AssemblyHelpers.h:
308         (JSC::AssemblyHelpers::branchIfNotEqual):
309         (JSC::AssemblyHelpers::branchIfEqual):
310         (JSC::AssemblyHelpers::branchIfNumber):
311         (JSC::AssemblyHelpers::branchIfNotNumber):
312         (JSC::AssemblyHelpers::branchIfBoolean):
313         (JSC::AssemblyHelpers::branchIfNotBoolean):
314         (JSC::AssemblyHelpers::boxBooleanPayload):
315         (JSC::AssemblyHelpers::boxBoolean):
316         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
317         * jit/JITOperations.h:
318         * runtime/SmallStrings.h:
319         (JSC::SmallStrings::typeString):
320         * runtime/TypeofType.cpp: Added.
321         (WTF::printInternal):
322         * runtime/TypeofType.h: Added.
323         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
324
325 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
326
327         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
328
329         * dfg/DFGLICMPhase.cpp:
330         (JSC::DFG::LICMPhase::attemptHoist):
331
332 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
333
334         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
335         https://bugs.webkit.org/show_bug.cgi?id=144525.
336
337         * dfg/DFGLICMPhase.cpp:
338         (JSC::DFG::LICMPhase::attemptHoist):
339         * dfg/DFGPhantomInsertionPhase.cpp:
340
341 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
342
343         Static property hashtable should only lookup with non-symbol key
344         https://bugs.webkit.org/show_bug.cgi?id=144438
345
346         Reviewed by Darin Adler.
347
348         Static property hashtable compares the Identifier's uid
349         with the normal C string without interning it.
350         So this comparison is performed in their contents.
351         As the result, in this comparison, symbol-ness is not considered.
352
353         So if accidentally the hash collision occur with the symbol and the string
354         and they have the same contents, the hash table entry is looked up incorrectly.
355
356         * runtime/Lookup.h:
357         (JSC::HashTable::entry):
358
359 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
360
361         Class syntax should allow string and numeric identifiers for method names
362         https://bugs.webkit.org/show_bug.cgi?id=144254
363
364         Reviewed by Darin Adler.
365
366         Added the support for string and numeric identifiers in class syntax.
367
368         * parser/Parser.cpp:
369         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
370         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
371         outside a class constructor as it should be.
372         (JSC::Parser<LexerType>::parseFunctionDeclaration):
373         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
374         element to allow numeric and string method names. For both of those method names, parse it here instead
375         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
376         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
377         this function is never used to parse a class method.
378         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
379         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
380         * parser/Parser.h:
381         * parser/SyntaxChecker.h:
382         (JSC::SyntaxChecker::createProperty):
383
384 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
385
386         FTL should use AI more
387         https://bugs.webkit.org/show_bug.cgi?id=144500
388
389         Reviewed by Oliver Hunt.
390         
391         This makes our type check folding even more comprehensive by ensuring that even if the FTL
392         decides to emit some checks, it will still do another query to the abstract interpreter to
393         see if the check is necessary. This helps with cases where we decided early on to speculate
394         one way, but later proved a more specific type of the value in question, and the constant
395         folder didn't catch it.
396         
397         This also makes it more natural to query the abstract interpreter. For example, if you just
398         want the proven type, you can now say provenType(node) or provenType(edge).
399
400         * dfg/DFGArrayMode.cpp:
401         (JSC::DFG::ArrayMode::alreadyChecked):
402         * dfg/DFGArrayMode.h:
403         * ftl/FTLLowerDFGToLLVM.cpp:
404         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
405         (JSC::FTL::LowerDFGToLLVM::compileToThis):
406         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
407         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
408         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
409         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
410         (JSC::FTL::LowerDFGToLLVM::compileGetById):
411         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
412         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
413         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
414         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
415         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
416         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
417         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
418         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
419         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
420         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
421         (JSC::FTL::LowerDFGToLLVM::compileIsString):
422         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
423         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
424         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
425         (JSC::FTL::LowerDFGToLLVM::baseIndex):
426         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
427         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
428         (JSC::FTL::LowerDFGToLLVM::boolify):
429         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
430         (JSC::FTL::LowerDFGToLLVM::lowInt32):
431         (JSC::FTL::LowerDFGToLLVM::lowInt52):
432         (JSC::FTL::LowerDFGToLLVM::lowCell):
433         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
434         (JSC::FTL::LowerDFGToLLVM::lowDouble):
435         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
436         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
437         (JSC::FTL::LowerDFGToLLVM::isNumber):
438         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
439         (JSC::FTL::LowerDFGToLLVM::isNotCell):
440         (JSC::FTL::LowerDFGToLLVM::isCell):
441         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
442         (JSC::FTL::LowerDFGToLLVM::isMisc):
443         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
444         (JSC::FTL::LowerDFGToLLVM::isBoolean):
445         (JSC::FTL::LowerDFGToLLVM::isNotOther):
446         (JSC::FTL::LowerDFGToLLVM::isOther):
447         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
448         (JSC::FTL::LowerDFGToLLVM::isObject):
449         (JSC::FTL::LowerDFGToLLVM::isNotObject):
450         (JSC::FTL::LowerDFGToLLVM::isNotString):
451         (JSC::FTL::LowerDFGToLLVM::isString):
452         (JSC::FTL::LowerDFGToLLVM::isFunction):
453         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
454         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
455         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
456         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
457         (JSC::FTL::LowerDFGToLLVM::abstractValue):
458         (JSC::FTL::LowerDFGToLLVM::provenType):
459         (JSC::FTL::LowerDFGToLLVM::provenValue):
460         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
461
462 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
463
464         USE(...) macro should expect unprefixed variables
465         https://bugs.webkit.org/show_bug.cgi?id=144454
466
467         Reviewed by Daniel Bates.
468
469         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
470
471 2015-05-01  Jordan Harband  <ljharb@gmail.com>
472
473         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
474         https://bugs.webkit.org/show_bug.cgi?id=144314
475
476         Reviewed by Darin Adler.
477
478         Fixing handling of Infinity position args, per
479         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
480         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
481         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
482
483         * runtime/StringPrototype.cpp:
484         (JSC::clampInt32):
485         (JSC::stringProtoFuncStartsWith):
486         (JSC::stringProtoFuncEndsWith):
487         (JSC::stringProtoFuncIncludes):
488
489 2015-05-01  Basile Clement  <basile_clement@apple.com>
490
491         Math.abs() returns negative
492         https://bugs.webkit.org/show_bug.cgi?id=137827
493
494         Reviewed by Michael Saboff.
495
496         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
497         identity function.
498
499         * dfg/DFGAbstractInterpreterInlines.h:
500         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
501         * tests/stress/math-abs-positive.js: Added, was previously failing.
502         (foo):
503
504 2015-05-01  Basile Clement  <basile_clement@apple.com>
505
506         Function allocation sinking shouldn't be performed on singleton functions
507         https://bugs.webkit.org/show_bug.cgi?id=144166
508
509         Reviewed by Geoffrey Garen.
510
511         Function allocations usually are free of any other side effects, but
512         this is not the case for allocations performed while the underlying
513         FunctionExecutable is still a singleton (as this allogation will fire
514         watchpoints invalidating code that depends on it being a singleton).
515         As the object allocation sinking phase assumes object allocation is
516         free of side-effects, sinking these allocations is not correct.
517
518         This also means that when materializing a function allocation on OSR
519         exit, that function's executable will never be a singleton, and we don't have
520         to worry about its watchpoint, allowing us to use
521         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
522         JSFunction::create.
523
524         * dfg/DFGObjectAllocationSinkingPhase.cpp:
525         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
526         * ftl/FTLOperations.cpp:
527         (JSC::FTL::operationMaterializeObjectInOSR):
528
529 2015-04-30  Jon Davis  <jond@apple.com>
530
531         Web Inspector: console should show an icon for console.info() messages
532         https://bugs.webkit.org/show_bug.cgi?id=18530
533
534         Reviewed by Timothy Hatcher.
535
536         * inspector/ConsoleMessage.cpp:
537         (Inspector::messageLevelValue):
538         * inspector/protocol/Console.json:
539         * runtime/ConsoleClient.cpp:
540         (JSC::appendMessagePrefix):
541         * runtime/ConsolePrototype.cpp:
542         (JSC::ConsolePrototype::finishCreation):
543         (JSC::consoleProtoFuncInfo):
544         * runtime/ConsoleTypes.h:
545
546 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
547
548         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
549         https://bugs.webkit.org/show_bug.cgi?id=144462
550
551         Reviewed by Geoffrey Garen and Mark Lam.
552         
553         At some point we started adding representation-agnostic helpers for doing common type tests.
554         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
555         they had overlapping powers, though SpeculativeJIT was a bit better.
556         
557         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
558         better because now all of these helpers can be used in all of the assembly-based JITs, not
559         just the DFG. It also settles on what I find to be a slightly better naming convention.
560         For example where we previously would have said branchIsString, now we say
561         branchIfString. Similarly, branchNotString becomes branchIfNotString.
562
563         * dfg/DFGSpeculativeJIT.cpp:
564         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
565         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
566         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
567         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
568         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
569         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
570         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
571         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
572         (JSC::DFG::SpeculativeJIT::speculateObject):
573         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
574         (JSC::DFG::SpeculativeJIT::speculateString):
575         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
576         (JSC::DFG::SpeculativeJIT::speculateNotCell):
577         (JSC::DFG::SpeculativeJIT::speculateOther):
578         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
579         (JSC::DFG::SpeculativeJIT::emitSwitchString):
580         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
581         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
582         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
583         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
584         * dfg/DFGSpeculativeJIT.h:
585         * dfg/DFGSpeculativeJIT32_64.cpp:
586         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
587         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
588         (JSC::DFG::SpeculativeJIT::emitCall):
589         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
590         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
591         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
592         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
593         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
594         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
595         (JSC::DFG::SpeculativeJIT::compile):
596         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
597         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
598         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
599         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
600         * dfg/DFGSpeculativeJIT64.cpp:
601         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
602         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
603         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
604         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
605         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
606         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
607         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
608         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
609         (JSC::DFG::SpeculativeJIT::compile):
610         (JSC::DFG::SpeculativeJIT::writeBarrier):
611         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
612         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
613         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
614         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
615         * jit/AssemblyHelpers.h:
616         (JSC::AssemblyHelpers::branchIfCell):
617         (JSC::AssemblyHelpers::branchIfOther):
618         (JSC::AssemblyHelpers::branchIfNotOther):
619         (JSC::AssemblyHelpers::branchIfObject):
620         (JSC::AssemblyHelpers::branchIfNotObject):
621         (JSC::AssemblyHelpers::branchIfType):
622         (JSC::AssemblyHelpers::branchIfNotType):
623         (JSC::AssemblyHelpers::branchIfString):
624         (JSC::AssemblyHelpers::branchIfNotString):
625         (JSC::AssemblyHelpers::branchIfSymbol):
626         (JSC::AssemblyHelpers::branchIfNotSymbol):
627         (JSC::AssemblyHelpers::branchIfFunction):
628         (JSC::AssemblyHelpers::branchIfNotFunction):
629         (JSC::AssemblyHelpers::branchIfEmpty):
630         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
631         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
632         * jit/JITPropertyAccess.cpp:
633         (JSC::JIT::emitScopedArgumentsGetByVal):
634
635 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
636
637         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
638         https://bugs.webkit.org/show_bug.cgi?id=144463
639
640         Reviewed by Benjamin Poulain.
641         
642         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
643         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
644         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
645         converting the boolean into an integer. But as part of doing that, it would try to
646         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
647         and it would try to figure out if the addition might overflow. Part of that logic
648         involved checking if the immediate is either a boolean or a sufficiently small integer.
649         But: it would check if it's a sufficiently small integer before checking if it was a
650         boolean, so it would try to call asNumber() on the boolean.
651         
652         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
653         case was previously never hit until I wrote these tests, and so we never knew that
654         calling asNumber() on a boolean was wrong.
655         
656         The fix is super simple: the expression should just check for boolean first.
657         
658         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
659         garbage, and that's OK, since we'd take the boolean case anyway.
660
661         * dfg/DFGGraph.h:
662         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
663
664 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
665
666         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
667
668         * jit/JITOperations.cpp:
669
670 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
671
672         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
673         particular that they cannot change their minds and may be called from compiler threads.
674
675         Rubber stamped by Geoffrey Garen.
676
677         * runtime/JSCell.h:
678
679 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
680
681         DFG Is<Blah> versions of TypeOf should fold based on proven input type
682         https://bugs.webkit.org/show_bug.cgi?id=144409
683
684         Reviewed by Geoffrey Garen.
685         
686         We were missing some obvious folding opportunities here. I don't know how this affects real
687         code, but in general, we like to ensure that our constant folding is comprehensive. So this
688         is more about placating my static analysis OCD than anything else.
689         
690         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
691
692         * dfg/DFGAbstractInterpreterInlines.h:
693         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
694
695 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
696
697         Use the default hash value for Symbolized StringImpl
698         https://bugs.webkit.org/show_bug.cgi?id=144347
699
700         Reviewed by Darin Adler.
701
702         Before this patch, symbolized StringImpl* has a special hash value
703         to avoid the hash collision with the other normal StringImpl*.
704         I guess that it is introduced when private symbols are introduced.
705         However, it prevents using symbolized StringImpl* in the other place
706         For example, using it as WTFString cause a problem because of its special hash value.
707
708         When only using private symbols, they are not exposed to the outside of JSC,
709         so we can handle it carefully. But now, it's extended to symbols.
710         So I think storing a special hash value in StringImpl* causes an error.
711
712         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
713         And to provide significantly different hash value when using it as symbol,
714         store the additional hash value in symbolized StringImpl*. It is used when
715         the hash value is required by IdentifierRepHash.
716
717         * runtime/Identifier.h:
718         (JSC::IdentifierRepHash::hash):
719         * runtime/Lookup.h:
720         (JSC::HashTable::entry):
721         * runtime/PropertyMapHashTable.h:
722         (JSC::PropertyTable::find):
723         (JSC::PropertyTable::get):
724         * runtime/Structure.cpp:
725         (JSC::PropertyTable::checkConsistency):
726
727 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
728
729         [JSC] Remove RageConvert array conversion
730         https://bugs.webkit.org/show_bug.cgi?id=144433
731
732         Reviewed by Filip Pizlo.
733
734         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
735         pretty hard:
736         -The indexing types shows that the array access varies between Int32 and DoubleArray.
737         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
738          An Arrayify node would convert the Int32 to that type.
739         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
740          node would use RageConvert instead of Convert.
741         -The Arrayify for that GetByVal with RageConvert would not convert the array to
742          Contiguous.
743         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
744          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
745          fail systematically and we never get to run the later code.
746
747         Getting rid of RageConvert fixes the problem and does not seems to have any
748         negative side effect on other benchmarks.
749
750         The improvments on Kraken are:
751             -stanford-crypto-aes: definitely 1.0915x faster.
752             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
753             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
754
755         * dfg/DFGAbstractInterpreterInlines.h:
756         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
757         * dfg/DFGArrayMode.cpp:
758         (JSC::DFG::ArrayMode::refine):
759         (JSC::DFG::arrayConversionToString):
760         * dfg/DFGArrayMode.h:
761         * dfg/DFGArrayifySlowPathGenerator.h:
762         * dfg/DFGFixupPhase.cpp:
763         (JSC::DFG::FixupPhase::fixupNode):
764         * dfg/DFGOperations.cpp:
765         * dfg/DFGOperations.h:
766         * dfg/DFGPredictionPropagationPhase.cpp:
767         (JSC::DFG::PredictionPropagationPhase::propagate):
768         * dfg/DFGTypeCheckHoistingPhase.cpp:
769         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
770         * ftl/FTLLowerDFGToLLVM.cpp:
771         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
772         * runtime/JSObject.cpp:
773         (JSC::JSObject::convertDoubleToContiguous):
774         (JSC::JSObject::ensureContiguousSlow):
775         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
776         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
777         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
778         * runtime/JSObject.h:
779         (JSC::JSObject::rageEnsureContiguous): Deleted.
780
781 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
782
783         Gracefully handle missing auto pause key on remote inspector setup
784         https://bugs.webkit.org/show_bug.cgi?id=144411
785
786         Reviewed by Timothy Hatcher.
787
788         * inspector/remote/RemoteInspector.mm:
789         (Inspector::RemoteInspector::receivedSetupMessage):
790
791 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
792
793         NodeList has issues with Symbol and empty string
794         https://bugs.webkit.org/show_bug.cgi?id=144310
795
796         Reviewed by Darin Adler.
797
798         * runtime/PropertyName.h:
799         (JSC::PropertyName::isSymbol):
800         Helper to check if the PropertyName is a string or symbol property.
801
802 2015-04-29  Alex Christensen  <achristensen@webkit.org>
803
804         Fix non-cygwin incremental builds on Windows.
805         https://bugs.webkit.org/show_bug.cgi?id=143264
806
807         Reviewed by Brent Fulgham.
808
809         * generate-js-builtins:
810         Remove stale headers before calling os.rename to replace them.
811
812 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
813
814         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
815         https://bugs.webkit.org/show_bug.cgi?id=144397
816
817         Reviewed by Andreas Kling.
818         
819         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
820         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
821         making a getCallData() call if it isn't necessary.
822
823         * API/JSCallbackObject.h:
824         * runtime/InternalFunction.h:
825         * runtime/JSTypeInfo.h:
826         (JSC::TypeInfo::typeOfShouldCallGetCallData):
827         * runtime/Operations.cpp:
828         (JSC::jsTypeStringForValue):
829         * tests/stress/type-of-functions-and-objects.js: Added.
830         (foo):
831         (bar):
832         (baz):
833         (fuzz):
834         (expect):
835         (test):
836
837 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
838
839         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
840         https://bugs.webkit.org/show_bug.cgi?id=144013
841
842         Reviewed by Mark Lam.
843
844         This patch implements Array.prototype.sort in JavaScript, removing the
845         C++ implementations. It is simpler and less error-prone to express our
846         operations in JavaScript, which provides memory safety, exception safety,
847         and recursion safety.
848
849         The performance result is mixed, but net positive in my opinion. It's
850         difficult to enumerate all the results, since we used to have so many
851         different sorting modes, and there are lots of different data patterns
852         across which you might want to measure sorting. Suffice it to say:
853
854             (*) The benchmarks we track are faster or unchanged.
855
856             (*) Sorting random input using a comparator -- which we think is
857             common -- is 3X faster.
858
859             (*) Sorting random input in a non-array object -- which jQuery does
860             -- is 4X faster.
861
862             (*) Sorting random input in a compact array of integers using a
863             trivial pattern-matchable comparator is 2X *slower*.
864
865         * builtins/Array.prototype.js:
866         (sort.min):
867         (sort.stringComparator):
868         (sort.compactSparse): Special case compaction for sparse arrays because
869         we don't want to hang when sorting new Array(BIG).
870
871         (sort.compact):
872         (sort.merge):
873         (sort.mergeSort): Use merge sort because it's a reasonably efficient
874         stable sort. We have evidence that some sites depend on stable sort,
875         even though the ES6 spec does not mandate it. (See
876         <http://trac.webkit.org/changeset/33967>.)
877
878         This is a textbook implementation of merge sort with three optimizations:
879
880             (1) Use iteration instead of recursion;
881
882             (2) Use array subscripting instead of array copying in order to
883             create logical sub-lists without creating physical sub-lists;
884
885             (3) Swap src and dst at each iteration instead of copying src into
886             dst, and only copy src into the subject array at the end if src is
887             not the subject array.
888
889         (sort.inflate):
890         (sort.comparatorSort):
891         (sort): Sort in JavaScript for the win.
892
893         * builtins/BuiltinExecutables.cpp:
894         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
895         names so we can use helper functions.
896
897         * bytecode/CodeBlock.h:
898         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
899         * bytecode/UnlinkedCodeBlock.cpp:
900         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
901         * bytecode/UnlinkedCodeBlock.h:
902         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
903         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
904         * bytecompiler/BytecodeGenerator.cpp:
905         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
906         * bytecompiler/BytecodeGenerator.h:
907         * bytecompiler/NodesCodegen.cpp:
908         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
909         on pattern matching anymore. This was mainly an optimization to avoid 
910         the overhead of calling from C++ to JS, which we now avoid by
911         sorting in JS.
912
913         * heap/Heap.cpp:
914         (JSC::Heap::markRoots):
915         (JSC::Heap::pushTempSortVector): Deleted.
916         (JSC::Heap::popTempSortVector): Deleted.
917         (JSC::Heap::visitTempSortVectors): Deleted.
918         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
919         in JavaScript using a normal JavaScript array for our temporary storage.
920
921         * parser/Parser.cpp:
922         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
923         helper functions.
924
925         * runtime/ArrayPrototype.cpp:
926         (JSC::isNumericCompareFunction): Deleted.
927         (JSC::attemptFastSort): Deleted.
928         (JSC::performSlowSort): Deleted.
929         (JSC::arrayProtoFuncSort): Deleted.
930
931         * runtime/CommonIdentifiers.h: New strings used by sort.
932
933         * runtime/JSArray.cpp:
934         (JSC::compareNumbersForQSortWithInt32): Deleted.
935         (JSC::compareNumbersForQSortWithDouble): Deleted.
936         (JSC::compareNumbersForQSort): Deleted.
937         (JSC::compareByStringPairForQSort): Deleted.
938         (JSC::JSArray::sortNumericVector): Deleted.
939         (JSC::JSArray::sortNumeric): Deleted.
940         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
941         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
942         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
943         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
944         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
945         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
946         (JSC::JSArray::sortCompactedVector): Deleted.
947         (JSC::JSArray::sort): Deleted.
948         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
949         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
950         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
951         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
952         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
953         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
954         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
955         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
956         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
957         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
958         (JSC::JSArray::sortVector): Deleted.
959         (JSC::JSArray::compactForSorting): Deleted.
960         * runtime/JSArray.h:
961
962         * runtime/JSGlobalObject.cpp:
963         (JSC::JSGlobalObject::init):
964         * runtime/ObjectConstructor.cpp:
965         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
966         by sort.
967
968 2015-04-29  Mark Lam  <mark.lam@apple.com>
969
970         Safari WebKit crash when loading Google Spreadsheet.
971         https://bugs.webkit.org/show_bug.cgi?id=144020
972
973         Reviewed by Filip Pizlo.
974
975         The bug is that the object allocation sinking phase did not account for a case
976         where a property of a sunken object is only initialized on one path and not
977         another.  As a result, on the path where the property is not initialized, we'll
978         encounter an Upsilon with a BottomValue (which is not allowed by definition).
979
980         The fix is to use a JSConstant(undefined) as the bottom value instead (of
981         BottomValue).  If the property is uninitialized, it should still be accessible
982         and have the value undefined.
983
984         * dfg/DFGObjectAllocationSinkingPhase.cpp:
985         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
986         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
987         (foo):
988         (foo2):
989
990 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
991
992         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
993         https://bugs.webkit.org/show_bug.cgi?id=144257
994
995         Reviewed by Darin Adler.
996
997         SHA1 is used to calculate CodeBlockHash.
998         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
999         However, the source code can contain null character.
1000         So when performing `strlen` on the source code's CString, it returns the incorrect length.
1001         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
1002
1003         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
1004         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
1005
1006         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
1007         is not correct. Because
1008
1009         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
1010         2. If CString can contain a null character, this assertion becomes incorrect.
1011
1012         So this patch just drops the assertion.
1013
1014         In the current implementation, we once convert the entire source code to the newly allocated
1015         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
1016         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
1017         We'll implement it in the separate patch[2].
1018
1019         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
1020         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
1021
1022         * tests/stress/eval-script-contains-null-character.js: Added.
1023         (shouldBe):
1024         (test):
1025         * tests/stress/template-literal-line-terminators.js:
1026         * tests/stress/template-literal-syntax.js:
1027         * tests/stress/template-literal.js:
1028
1029 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
1030
1031         Evict IsEnvironmentRecord from inline type flags
1032         https://bugs.webkit.org/show_bug.cgi?id=144398
1033
1034         Reviewed by Mark Lam and Michael Saboff.
1035         
1036         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
1037         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
1038         and evicts it into the out-of-line type flags. This change has no performance implications
1039         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
1040         where we access it at all is in String.prototype.repeat, and there we already load the
1041         structure anyway.
1042
1043         * runtime/JSTypeInfo.h:
1044         (JSC::TypeInfo::implementsHasInstance):
1045         (JSC::TypeInfo::structureIsImmortal):
1046         (JSC::TypeInfo::isEnvironmentRecord):
1047
1048 2015-04-29  Darin Adler  <darin@apple.com>
1049
1050         [ES6] Implement Unicode code point escapes
1051         https://bugs.webkit.org/show_bug.cgi?id=144377
1052
1053         Reviewed by Antti Koivisto.
1054
1055         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
1056         the header. Made it a non-member class so it doesn't need to be part
1057         of a template. Made it use UChar32 instead of int for the value to
1058         make it clearer what goes into this class.
1059         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
1060         old type() function.
1061         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
1062         parseFourDigitUnicodeHex and added support for code point escapes.
1063         (JSC::isLatin1): Added an overload for UChar32.
1064         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
1065         to call it with a UChar, so no need to overload for that type for now.
1066         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
1067         Also added FIXME about a subtle ES6 change that we might want to make later.
1068         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
1069         to call it with a UChar, so no need to overload for that type for now.
1070         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
1071         don't need to repeat the code twice. Added code to handle code point escapes.
1072         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
1073         code in line.
1074         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
1075         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
1076         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
1077         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
1078         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
1079         the code that handles the escapes, since the code point escape code now
1080         consumes characters while parsing rather than peeking ahead. Test case
1081         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
1082         giving a syntax error.
1083
1084         * parser/Lexer.h: Updated for above changes.
1085
1086         * runtime/StringConstructor.cpp:
1087         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
1088         out 0x10FFFF; clearer this way.
1089
1090 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
1091
1092         [CMake] [GTK] Organize and clean up unused CMake variables
1093         https://bugs.webkit.org/show_bug.cgi?id=144364
1094
1095         Reviewed by Gyuyoung Kim.
1096
1097         * PlatformGTK.cmake: Add variables specific to this project.
1098
1099 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1100
1101         TypeOf should return SpecStringIdent and the DFG should know this
1102         https://bugs.webkit.org/show_bug.cgi?id=144376
1103
1104         Reviewed by Andreas Kling.
1105         
1106         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
1107         
1108         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
1109         bad.
1110
1111         * dfg/DFGAbstractInterpreterInlines.h:
1112         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1113         * dfg/DFGAbstractValue.cpp:
1114         (JSC::DFG::AbstractValue::setType):
1115         * dfg/DFGAbstractValue.h:
1116         (JSC::DFG::AbstractValue::setType):
1117         * dfg/DFGInPlaceAbstractState.cpp:
1118         (JSC::DFG::InPlaceAbstractState::initialize):
1119         * dfg/DFGPredictionPropagationPhase.cpp:
1120         (JSC::DFG::PredictionPropagationPhase::propagate):
1121         * runtime/SmallStrings.cpp:
1122         (JSC::SmallStrings::initialize):
1123         * tests/stress/switch-typeof-indirect.js: Added.
1124         (bar):
1125         (foo):
1126         (test):
1127         * tests/stress/switch-typeof-slightly-indirect.js: Added.
1128         (foo):
1129         (test):
1130         * tests/stress/switch-typeof.js: Added.
1131         (foo):
1132         (test):
1133
1134 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1135
1136         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
1137         https://bugs.webkit.org/show_bug.cgi?id=144373
1138
1139         Reviewed by Darin Adler.
1140
1141         Revert r181868 as it caused a failure on live.com. We can try
1142         re-enabling this exception after we make idl attributes configurable,
1143         which may have prevented this particular failure.
1144
1145         * runtime/ObjectPrototype.cpp:
1146         (JSC::objectProtoFuncDefineGetter):
1147         (JSC::objectProtoFuncDefineSetter):
1148
1149 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1150
1151         Deadlock on applications using JSContext on non-main thread
1152         https://bugs.webkit.org/show_bug.cgi?id=144370
1153
1154         Reviewed by Timothy Hatcher.
1155
1156         * inspector/remote/RemoteInspector.mm:
1157         (Inspector::RemoteInspector::singleton):
1158         Prevent a possible deadlock by assuming we can synchronously
1159         run something on the main queue at this time.
1160
1161 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1162
1163         FTL should fully support Switch (it currently lacks the SwitchString variant)
1164         https://bugs.webkit.org/show_bug.cgi?id=144348
1165
1166         Reviewed by Benjamin Poulain.
1167         
1168         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
1169         in LayoutTests/js/regress.
1170
1171         * dfg/DFGCommon.cpp:
1172         (JSC::DFG::stringLessThan):
1173         * dfg/DFGCommon.h:
1174         * dfg/DFGOperations.cpp:
1175         * dfg/DFGOperations.h:
1176         * dfg/DFGSpeculativeJIT.cpp:
1177         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
1178         * dfg/DFGSpeculativeJIT.h:
1179         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
1180         * ftl/FTLCapabilities.cpp:
1181         (JSC::FTL::canCompile):
1182         * ftl/FTLIntrinsicRepository.h:
1183         * ftl/FTLLowerDFGToLLVM.cpp:
1184         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
1185         (JSC::FTL::LowerDFGToLLVM::switchString):
1186         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
1187         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
1188         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
1189         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
1190         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
1191         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
1192         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1193         * ftl/FTLOutput.cpp:
1194         (JSC::FTL::Output::check):
1195         * ftl/FTLOutput.h:
1196         * ftl/FTLWeight.h:
1197         (JSC::FTL::Weight::inverse):
1198         * jit/JITOperations.h:
1199
1200 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1201
1202         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1203         https://bugs.webkit.org/show_bug.cgi?id=144304
1204
1205         Reviewed by Geoffrey Garen.
1206
1207         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1208         ENABLE_LLINT_C_LOOP, disabled by default.
1209         * llint/LLIntSlowPaths.cpp:
1210         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1211
1212 2015-04-28  Commit Queue  <commit-queue@webkit.org>
1213
1214         Unreviewed, rolling out r183514.
1215         https://bugs.webkit.org/show_bug.cgi?id=144359
1216
1217         It broke cloop test bots (Requested by mcatanzaro on #webkit).
1218
1219         Reverted changeset:
1220
1221         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
1222         https://bugs.webkit.org/show_bug.cgi?id=144304
1223         http://trac.webkit.org/changeset/183514
1224
1225 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1226
1227         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1228         https://bugs.webkit.org/show_bug.cgi?id=144304
1229
1230         Reviewed by Geoffrey Garen.
1231
1232         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1233         ENABLE_LLINT_C_LOOP, disabled by default.
1234         * llint/LLIntSlowPaths.cpp:
1235         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1236
1237 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1238
1239         Fix common typo "targetting" => "targeting"
1240         https://bugs.webkit.org/show_bug.cgi?id=144349
1241
1242         Reviewed by Daniel Bates.
1243
1244         * bytecode/ExecutionCounter.h:
1245
1246 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
1247
1248         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
1249         https://bugs.webkit.org/show_bug.cgi?id=144328
1250
1251         Reviewed by Andreas Kling.
1252
1253         Update the status of ES6 features.
1254
1255         * features.json:
1256
1257 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1258
1259         DFG should not use or preserve Phantoms during transformations
1260         https://bugs.webkit.org/show_bug.cgi?id=143736
1261
1262         Reviewed by Geoffrey Garen.
1263         
1264         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
1265         no longer necessary to preserve Phantoms during transformations. They are still useful just
1266         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
1267         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
1268         block, we can be sure that so long as the IR pinpoints the place where the value becomes
1269         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
1270         other block would need the value (either for OSR or for DFG execution), then we don't need any
1271         liveness markers.
1272         
1273         So, this removes any places where we inserted Phantoms just for liveness during transformation
1274         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
1275         Check node only keeps its children so long as those children have checks.
1276         
1277         The fact that we no longer convertToPhantom() means that we have to be more careful when
1278         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
1279         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
1280         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
1281         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
1282         GetLocals.
1283         
1284         The only Phantom-like cruft left over after this patch is:
1285         
1286         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
1287           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
1288           the users of the original local's live range in bytecode. This is essential for supporting our
1289           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
1290         
1291         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
1292           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
1293           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
1294           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
1295           treat GetLocal/SetLocal conservatively, this should all be sound.
1296         
1297         This change should be perf-neutral although it does reduce the total work that the compiler
1298         does.
1299
1300         * CMakeLists.txt:
1301         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1302         * JavaScriptCore.xcodeproj/project.pbxproj:
1303         * dfg/DFGAdjacencyList.h:
1304         (JSC::DFG::AdjacencyList::justChecks):
1305         * dfg/DFGArgumentsEliminationPhase.cpp:
1306         * dfg/DFGBasicBlock.cpp:
1307         (JSC::DFG::BasicBlock::replaceTerminal):
1308         * dfg/DFGBasicBlock.h:
1309         (JSC::DFG::BasicBlock::findTerminal):
1310         * dfg/DFGCFGSimplificationPhase.cpp:
1311         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
1312         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1313         * dfg/DFGCPSRethreadingPhase.cpp:
1314         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
1315         (JSC::DFG::CPSRethreadingPhase::clearVariables):
1316         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
1317         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1318         * dfg/DFGCSEPhase.cpp:
1319         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
1320         (JSC::DFG::CleanUpPhase::CleanUpPhase):
1321         (JSC::DFG::CleanUpPhase::run):
1322         (JSC::DFG::performCleanUp):
1323         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
1324         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
1325         (JSC::DFG::performPhantomRemoval): Deleted.
1326         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
1327         * dfg/DFGConstantFoldingPhase.cpp:
1328         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1329         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
1330         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
1331         * dfg/DFGDCEPhase.cpp:
1332         (JSC::DFG::DCEPhase::run):
1333         (JSC::DFG::DCEPhase::fixupBlock):
1334         (JSC::DFG::DCEPhase::cleanVariables):
1335         * dfg/DFGFixupPhase.cpp:
1336         (JSC::DFG::FixupPhase::fixupBlock):
1337         (JSC::DFG::FixupPhase::fixupNode):
1338         (JSC::DFG::FixupPhase::convertStringAddUse):
1339         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1340         (JSC::DFG::FixupPhase::checkArray):
1341         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1342         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
1343         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
1344         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1345         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1346         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1347         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
1348         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
1349         * dfg/DFGGraph.cpp:
1350         (JSC::DFG::Graph::convertToConstant):
1351         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
1352         * dfg/DFGGraph.h:
1353         * dfg/DFGInsertionSet.h:
1354         (JSC::DFG::InsertionSet::insertCheck):
1355         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1356         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1357         * dfg/DFGLICMPhase.cpp:
1358         (JSC::DFG::LICMPhase::attemptHoist):
1359         * dfg/DFGNode.cpp:
1360         (JSC::DFG::Node::remove):
1361         * dfg/DFGNode.h:
1362         (JSC::DFG::Node::replaceWith):
1363         (JSC::DFG::Node::convertToPhantom): Deleted.
1364         (JSC::DFG::Node::convertToCheck): Deleted.
1365         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
1366         * dfg/DFGNodeFlags.h:
1367         * dfg/DFGNodeType.h:
1368         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1369         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1370         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1371         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
1372         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
1373         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
1374         * dfg/DFGPhantomRemovalPhase.h: Removed.
1375         * dfg/DFGPlan.cpp:
1376         (JSC::DFG::Plan::compileInThreadImpl):
1377         * dfg/DFGPutStackSinkingPhase.cpp:
1378         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
1379         * dfg/DFGResurrectionForValidationPhase.h: Removed.
1380         * dfg/DFGSSAConversionPhase.cpp:
1381         (JSC::DFG::SSAConversionPhase::run):
1382         * dfg/DFGSpeculativeJIT64.cpp:
1383         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1384         * dfg/DFGStoreBarrierElisionPhase.cpp:
1385         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
1386         * dfg/DFGStrengthReductionPhase.cpp:
1387         (JSC::DFG::StrengthReductionPhase::handleNode):
1388         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
1389         * dfg/DFGValidate.cpp:
1390         (JSC::DFG::Validate::validate):
1391         (JSC::DFG::Validate::validateCPS):
1392         (JSC::DFG::Validate::validateSSA):
1393         * dfg/DFGVarargsForwardingPhase.cpp:
1394         * ftl/FTLLink.cpp:
1395         (JSC::FTL::link):
1396         * ftl/FTLLowerDFGToLLVM.cpp:
1397         (JSC::FTL::LowerDFGToLLVM::compileNode):
1398         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
1399         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
1400
1401 2015-04-28  Andreas Kling  <akling@apple.com>
1402
1403         DFG+FTL should generate efficient code for branching on a string's boolean value.
1404         <https://webkit.org/b/144317>
1405
1406         Reviewed by Geoff Garen & Filip Pizlo
1407
1408         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
1409         instead of dropping out to C++ whenever we branch on a string.
1410
1411         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
1412         the DFG JIT gets some new codegen logic in this patch.
1413
1414         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
1415
1416         * dfg/DFGFixupPhase.cpp:
1417         (JSC::DFG::FixupPhase::fixupNode):
1418         * dfg/DFGSpeculativeJIT.cpp:
1419         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1420         * dfg/DFGSpeculativeJIT.h:
1421         * dfg/DFGSpeculativeJIT32_64.cpp:
1422         (JSC::DFG::SpeculativeJIT::emitBranch):
1423         * dfg/DFGSpeculativeJIT64.cpp:
1424         (JSC::DFG::SpeculativeJIT::emitBranch):
1425
1426 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1427
1428         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
1429         https://bugs.webkit.org/show_bug.cgi?id=144340
1430
1431         Reviewed by Michael Saboff and Mark Lam.
1432         
1433         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
1434         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
1435         Basically, we'd keep it alive until the end of the block. This maximized the chances of
1436         there being an interfering operation, which would prevent elimination.
1437         
1438         The fix is to only consider MovHints that have the arguments candidate as a child. We only
1439         care to track the liveness of those bytecode locals that would need an arguments object
1440         recovery on OSR exit.
1441         
1442         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
1443         introduced in http://trac.webkit.org/changeset/183406.
1444
1445         * dfg/DFGVarargsForwardingPhase.cpp:
1446
1447 2015-04-28  Csaba Osztrogon√°c  <ossy@webkit.org>
1448
1449         Remove WinCE cruft from cmake build system
1450         https://bugs.webkit.org/show_bug.cgi?id=144325
1451
1452         Reviewed by Gyuyoung Kim.
1453
1454         * CMakeLists.txt:
1455         * create_jit_stubs: Removed.
1456
1457 2015-04-27  Andreas Kling  <akling@apple.com>
1458
1459         RegExp matches arrays should use contiguous indexing.
1460         <https://webkit.org/b/144286>
1461
1462         Reviewed by Geoffrey Garen.
1463
1464         We had a custom Structure being used for RegExp matches arrays that would
1465         put the arrays into SlowPutArrayStorageShape mode. This was just left
1466         from when matches arrays were custom, lazily initialized objects.
1467
1468         This change removes that Structure and switches the matches arrays to
1469         using the default ContiguousShape Structure. This allows the FTL JIT
1470         to compile the inner loop of the Octane/regexp benchmark.
1471
1472         Also made a version of initializeIndex() [inline] that takes the indexing
1473         type in an argument, allowing createRegExpMatchesArray() to initialize
1474         the entire array without branching on the indexing type for each entry.
1475
1476         ~3% progression on Octane/regexp.
1477
1478         * runtime/JSGlobalObject.cpp:
1479         (JSC::JSGlobalObject::init):
1480         (JSC::JSGlobalObject::visitChildren):
1481         * runtime/JSGlobalObject.h:
1482         (JSC::JSGlobalObject::mapStructure):
1483         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1484         * runtime/JSObject.h:
1485         (JSC::JSObject::initializeIndex):
1486         * runtime/RegExpMatchesArray.cpp:
1487         (JSC::createRegExpMatchesArray):
1488
1489 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1490
1491         FTL failed to initialize arguments.callee on the slow path as well as the fast path
1492         https://bugs.webkit.org/show_bug.cgi?id=144293
1493
1494         Reviewed by Mark Lam.
1495         
1496         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
1497         to initialize the callee on the common path after the fast and slow path.
1498
1499         * ftl/FTLLowerDFGToLLVM.cpp:
1500         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
1501         * tests/stress/arguments-callee-uninitialized.js: Added.
1502         (foo):
1503
1504 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
1505
1506         [JSC] Add support for typed arrays to the Array profiling
1507         https://bugs.webkit.org/show_bug.cgi?id=143913
1508
1509         Reviewed by Filip Pizlo.
1510
1511         This patch adds ArrayModes for every typed arrays. Having that information
1512         let us generate better GetByVal and PutByVal when the type speculation
1513         are not good enough.
1514
1515         A typical case where this is useful is any basic block for which the type
1516         of the object is always more restrictive than the speculation (for example, 
1517         a basic block gated by a branch only taken for on type).
1518
1519         * bytecode/ArrayProfile.cpp:
1520         (JSC::dumpArrayModes):
1521         * bytecode/ArrayProfile.h:
1522         (JSC::arrayModeFromStructure):
1523         * dfg/DFGArrayMode.cpp:
1524         (JSC::DFG::ArrayMode::fromObserved):
1525         (JSC::DFG::ArrayMode::refine):
1526         Maintain the refine() semantic. We do not support OutOfBounds access
1527         for GetByVal on typed array.
1528
1529         * runtime/IndexingType.h:
1530         * tests/stress/typed-array-get-by-val-profiling.js: Added.
1531         (testArray.testCode):
1532         (testArray):
1533         * tests/stress/typed-array-put-by-val-profiling.js: Added.
1534         (testArray.testCode):
1535         (testArray):
1536
1537 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1538
1539         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
1540         causes many debug test failures.
1541
1542         * runtime/JSGlobalObject.cpp:
1543         (JSC::JSGlobalObject::init):
1544         (JSC::JSGlobalObject::visitChildren):
1545         * runtime/JSGlobalObject.h:
1546         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1547         * runtime/JSObject.h:
1548         (JSC::JSObject::initializeIndex):
1549         * runtime/RegExpMatchesArray.cpp:
1550         (JSC::createRegExpMatchesArray):
1551
1552 2015-04-27  Andreas Kling  <akling@apple.com>
1553
1554         RegExp matches arrays should use contiguous indexing.
1555         <https://webkit.org/b/144286>
1556
1557         Reviewed by Geoffrey Garen.
1558
1559         We had a custom Structure being used for RegExp matches arrays that would
1560         put the arrays into SlowPutArrayStorageShape mode. This was just left
1561         from when matches arrays were custom, lazily initialized objects.
1562
1563         This change removes that Structure and switches the matches arrays to
1564         using the default ContiguousShape Structure. This allows the FTL JIT
1565         to compile the inner loop of the Octane/regexp benchmark.
1566
1567         Also made a version of initializeIndex() [inline] that takes the indexing
1568         type in an argument, allowing createRegExpMatchesArray() to initialize
1569         the entire array without branching on the indexing type for each entry.
1570
1571         ~3% progression on Octane/regexp.
1572
1573         * runtime/JSGlobalObject.cpp:
1574         (JSC::JSGlobalObject::init):
1575         (JSC::JSGlobalObject::visitChildren):
1576         * runtime/JSGlobalObject.h:
1577         (JSC::JSGlobalObject::mapStructure):
1578         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1579         * runtime/JSObject.h:
1580         (JSC::JSObject::initializeIndex):
1581         * runtime/RegExpMatchesArray.cpp:
1582         (JSC::createRegExpMatchesArray):
1583
1584 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
1585
1586         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1587         https://bugs.webkit.org/show_bug.cgi?id=144257
1588
1589         Temporarily disable skip these tests.
1590
1591         * tests/stress/template-literal-line-terminators.js:
1592         * tests/stress/template-literal-syntax.js:
1593         * tests/stress/template-literal.js:
1594
1595 2015-04-27  Basile Clement  <basile_clement@apple.com>
1596
1597         Function allocations shouldn't sink through Put operations
1598         https://bugs.webkit.org/show_bug.cgi?id=144176
1599
1600         Reviewed by Filip Pizlo.
1601
1602         By design, we don't support function allocation sinking through any
1603         related operation ; however object allocation can sink through PutByOffset et
1604         al.
1605
1606         Currently, the checks to prevent function allocation to sink through
1607         these are misguided and do not prevent anything ; function allocation sinking
1608         through these operations is prevented as a side effect of requiring an
1609         AllocatePropertyStorage through which the function allocation is seen as
1610         escaping.
1611
1612         This changes it so that ObjectAllocationSinkingPhase::handleNode()
1613         checks properly that only object allocations sink through related write
1614         operations.
1615
1616         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1617         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1618         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1619
1620 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
1621
1622         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
1623         https://bugs.webkit.org/show_bug.cgi?id=143843
1624
1625         Reviewed by Geoffrey Garen.
1626         
1627         It will soon come to pass that Phantom isn't available at the time that
1628         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
1629         a value dies for OSR.
1630         
1631         This is simplified by two things:
1632         
1633         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
1634            before by polishing the API.
1635         
1636         2) This phase already operates on one node at a time and allows itself to do a full search
1637            of the enclosing basic block for that node. This is fine because CreateDirectArguments
1638            and friends is a rarely occurring node. The fact that it operates on one node at a time
1639            makes it even easier to reason about OSR liveness - we just track the list of locals in
1640            which it is live.
1641         
1642         This change has no effect right now but it is a necessary prerequisite to implementing
1643         https://bugs.webkit.org/show_bug.cgi?id=143736.
1644
1645         * dfg/DFGBasicBlock.h:
1646         (JSC::DFG::BasicBlock::tryAt):
1647         * dfg/DFGForAllKills.h:
1648         (JSC::DFG::forAllKilledOperands):
1649         * dfg/DFGPhantomInsertionPhase.cpp:
1650         * dfg/DFGVarargsForwardingPhase.cpp:
1651
1652 2015-04-27  Jordan Harband  <ljharb@gmail.com>
1653
1654         Map#entries and Map#keys error for non-Maps is swapped
1655         https://bugs.webkit.org/show_bug.cgi?id=144253
1656
1657         Reviewed by Simon Fraser.
1658
1659         Correcting error messages on Set/Map methods when called on
1660         incompatible objects.
1661
1662         * runtime/MapPrototype.cpp:
1663         (JSC::mapProtoFuncEntries):
1664         (JSC::mapProtoFuncKeys):
1665         * runtime/SetPrototype.cpp:
1666         (JSC::setProtoFuncEntries):
1667
1668 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1669
1670         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
1671         https://bugs.webkit.org/show_bug.cgi?id=144186
1672
1673         Reviewed by Geoffrey Garen.
1674         
1675         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
1676         Int32. We may later perform code simplifications based on the proof that this is Int32, and
1677         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
1678         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
1679         except that we still need the overflow check!
1680
1681         Previously we mishandled this:
1682
1683         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
1684           to keep it alive. That's dirty and it's just indicative of a deeper issue.
1685
1686         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
1687           powerless. This was sort of hiding the bug.
1688
1689         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
1690           something that you are relying on for subsequent simplifications.
1691         
1692         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
1693         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
1694         we no longer need the weird MustGenerate node.
1695
1696         * dfg/DFGAbstractInterpreterInlines.h:
1697         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1698         * dfg/DFGArgumentsEliminationPhase.cpp:
1699         * dfg/DFGClobberize.h:
1700         (JSC::DFG::clobberize):
1701         * dfg/DFGDCEPhase.cpp:
1702         (JSC::DFG::DCEPhase::run):
1703         * dfg/DFGDoesGC.cpp:
1704         (JSC::DFG::doesGC):
1705         * dfg/DFGFixupPhase.cpp:
1706         (JSC::DFG::FixupPhase::fixupNode):
1707         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1708         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1709         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1710         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
1711         * dfg/DFGMayExit.cpp:
1712         (JSC::DFG::mayExit):
1713         * dfg/DFGNode.h:
1714         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1715         * dfg/DFGNodeType.h:
1716         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1717         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1718         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1719         (JSC::DFG::PhantomCanonicalizationPhase::run):
1720         * dfg/DFGPhantomRemovalPhase.cpp:
1721         (JSC::DFG::PhantomRemovalPhase::run):
1722         * dfg/DFGPlan.cpp:
1723         (JSC::DFG::Plan::compileInThreadImpl):
1724         * dfg/DFGPredictionPropagationPhase.cpp:
1725         (JSC::DFG::PredictionPropagationPhase::propagate):
1726         * dfg/DFGSafeToExecute.h:
1727         (JSC::DFG::safeToExecute):
1728         * dfg/DFGSpeculativeJIT32_64.cpp:
1729         (JSC::DFG::SpeculativeJIT::compile):
1730         * dfg/DFGSpeculativeJIT64.cpp:
1731         (JSC::DFG::SpeculativeJIT::compile):
1732         * dfg/DFGTypeCheckHoistingPhase.cpp:
1733         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1734         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1735         * dfg/DFGVarargsForwardingPhase.cpp:
1736         * ftl/FTLCapabilities.cpp:
1737         (JSC::FTL::canCompile):
1738         * ftl/FTLLowerDFGToLLVM.cpp:
1739         (JSC::FTL::LowerDFGToLLVM::compileNode):
1740         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
1741         (foo):
1742         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
1743         (foo):
1744         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
1745         (foo):
1746         * tests/stress/fold-based-on-int32-proof.js: Added.
1747         (foo):
1748
1749 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1750
1751         Class body ending with a semicolon throws a SyntaxError
1752         https://bugs.webkit.org/show_bug.cgi?id=144244
1753
1754         Reviewed by Darin Adler.
1755
1756         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
1757         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
1758         it by continue'ing when it encounters a semicolon.
1759
1760         * parser/Parser.cpp:
1761         (JSC::Parser<LexerType>::parseClass):
1762
1763 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1764
1765         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
1766         https://bugs.webkit.org/show_bug.cgi?id=144243
1767
1768         Reviewed by Darin Adler.
1769
1770         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
1771
1772         * parser/Parser.cpp:
1773         (JSC::Parser<LexerType>::parseGetterSetter):
1774
1775 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1776
1777         Map#forEach does not pass "map" argument to callback.
1778         https://bugs.webkit.org/show_bug.cgi?id=144187
1779
1780         Reviewed by Darin Adler.
1781
1782         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
1783         step 7.a.i., the callback should be called with three arguments.
1784
1785         * runtime/MapPrototype.cpp:
1786         (JSC::mapProtoFuncForEach):
1787
1788 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1789
1790         [ES6] Implement ES6 template literals
1791         https://bugs.webkit.org/show_bug.cgi?id=142691
1792
1793         Reviewed by Darin Adler.
1794
1795         This patch implements TemplateLiteral.
1796         Since TaggedTemplate requires some global states and
1797         primitive operations like GetTemplateObject,
1798         we separate the patch. It will be implemented in a subsequent patch.
1799
1800         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
1801         By disabling it, we can disable Template Literal support.
1802
1803         To implement template literals, in this patch,
1804         we newly introduces bytecode op_to_string.
1805         In template literals, we alternately evaluate the expression and
1806         perform ToString onto the result of evaluation.
1807         For example,
1808
1809         `${f1()} ${f2()}`
1810
1811         In this template literal, execution order is the following,
1812         1. calling f1()
1813         2. ToString(the result of f1())
1814         3. calling f2()
1815         4. ToString(the result of f2())
1816
1817         op_strcat also performs ToString. However, performing ToString
1818         onto expressions are batched in op_strcat, it's not the same to the
1819         template literal spec. In the above example,
1820         ToString(f1()) should be called before calling f2().
1821
1822         * Configurations/FeatureDefines.xcconfig:
1823         * bytecode/BytecodeList.json:
1824         * bytecode/BytecodeUseDef.h:
1825         (JSC::computeUsesForBytecodeOffset):
1826         (JSC::computeDefsForBytecodeOffset):
1827         * bytecode/CodeBlock.cpp:
1828         (JSC::CodeBlock::dumpBytecode):
1829         * bytecompiler/BytecodeGenerator.h:
1830         (JSC::BytecodeGenerator::emitToString):
1831         (JSC::BytecodeGenerator::emitToNumber): Deleted.
1832         * bytecompiler/NodesCodegen.cpp:
1833         (JSC::TemplateStringNode::emitBytecode):
1834         (JSC::TemplateLiteralNode::emitBytecode):
1835         * dfg/DFGByteCodeParser.cpp:
1836         (JSC::DFG::ByteCodeParser::parseBlock):
1837         * dfg/DFGCapabilities.cpp:
1838         (JSC::DFG::capabilityLevel):
1839         * jit/JIT.cpp:
1840         (JSC::JIT::privateCompileMainPass):
1841         (JSC::JIT::privateCompileSlowCases):
1842         * jit/JIT.h:
1843         * jit/JITOpcodes.cpp:
1844         (JSC::JIT::emit_op_to_string):
1845         (JSC::JIT::emitSlow_op_to_string):
1846         * jit/JITOpcodes32_64.cpp:
1847         (JSC::JIT::emit_op_to_string):
1848         (JSC::JIT::emitSlow_op_to_string):
1849         * llint/LowLevelInterpreter32_64.asm:
1850         * llint/LowLevelInterpreter64.asm:
1851         * parser/ASTBuilder.h:
1852         (JSC::ASTBuilder::createTemplateString):
1853         (JSC::ASTBuilder::createTemplateStringList):
1854         (JSC::ASTBuilder::createTemplateExpressionList):
1855         (JSC::ASTBuilder::createTemplateLiteral):
1856         * parser/Lexer.cpp:
1857         (JSC::Lexer<T>::Lexer):
1858         (JSC::Lexer<T>::parseIdentifierSlowCase):
1859         (JSC::Lexer<T>::parseString):
1860         (JSC::LineNumberAdder::LineNumberAdder):
1861         (JSC::LineNumberAdder::clear):
1862         (JSC::LineNumberAdder::add):
1863         (JSC::Lexer<T>::parseTemplateLiteral):
1864         (JSC::Lexer<T>::lex):
1865         (JSC::Lexer<T>::scanRegExp):
1866         (JSC::Lexer<T>::scanTrailingTemplateString):
1867         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
1868         * parser/Lexer.h:
1869         * parser/NodeConstructors.h:
1870         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
1871         (JSC::TemplateStringNode::TemplateStringNode):
1872         (JSC::TemplateStringListNode::TemplateStringListNode):
1873         (JSC::TemplateLiteralNode::TemplateLiteralNode):
1874         * parser/Nodes.h:
1875         (JSC::TemplateExpressionListNode::value):
1876         (JSC::TemplateExpressionListNode::next):
1877         (JSC::TemplateStringNode::cooked):
1878         (JSC::TemplateStringNode::raw):
1879         (JSC::TemplateStringListNode::value):
1880         (JSC::TemplateStringListNode::next):
1881         * parser/Parser.cpp:
1882         (JSC::Parser<LexerType>::parseTemplateString):
1883         (JSC::Parser<LexerType>::parseTemplateLiteral):
1884         (JSC::Parser<LexerType>::parsePrimaryExpression):
1885         * parser/Parser.h:
1886         * parser/ParserTokens.h:
1887         * parser/SyntaxChecker.h:
1888         (JSC::SyntaxChecker::createTemplateString):
1889         (JSC::SyntaxChecker::createTemplateStringList):
1890         (JSC::SyntaxChecker::createTemplateExpressionList):
1891         (JSC::SyntaxChecker::createTemplateLiteral):
1892         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
1893         * runtime/CommonSlowPaths.cpp:
1894         (JSC::SLOW_PATH_DECL):
1895         * runtime/CommonSlowPaths.h:
1896         * tests/stress/template-literal-line-terminators.js: Added.
1897         (test):
1898         (testEval):
1899         (testEvalLineNumber):
1900         * tests/stress/template-literal-syntax.js: Added.
1901         (testSyntax):
1902         (testSyntaxError):
1903         * tests/stress/template-literal.js: Added.
1904         (test):
1905         (testEval):
1906         (testEmbedded):
1907
1908 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1909
1910         Set#forEach does not pass "key" or "set" arguments to callback.
1911         https://bugs.webkit.org/show_bug.cgi?id=144188
1912
1913         Reviewed by Darin Adler.
1914
1915         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
1916         Set#forEach should pass 3 arguments to the callback.
1917
1918         * runtime/SetPrototype.cpp:
1919         (JSC::setProtoFuncForEach):
1920
1921 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
1922
1923         [JSC] Implement Math.clz32(), remove Number.clz()
1924         https://bugs.webkit.org/show_bug.cgi?id=144205
1925
1926         Reviewed by Michael Saboff.
1927
1928         This patch adds the ES6 function Math.clz32(), and remove the non-standard
1929         Number.clz(). Number.clz() probably came from an older draft.
1930
1931         The new function has a corresponding instrinsic: Clz32Intrinsic,
1932         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
1933
1934         * assembler/MacroAssemblerX86Common.h:
1935         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
1936         * assembler/X86Assembler.h:
1937         (JSC::X86Assembler::bsr_rr):
1938         The x86 assembler did not have countLeadingZeros32() because there is
1939         no native CLZ instruction on that architecture.
1940
1941         I have added the version with bsr + branches for the case of zero.
1942         An other popular version uses cmov to handle the case of zero. I kept
1943         it simple since the Assembler has no support for cmov.
1944
1945         It is unlikely to matter much. If the code is hot enough, LLVM picks
1946         something good based on the surrounding code.
1947
1948         * dfg/DFGAbstractInterpreterInlines.h:
1949         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1950         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
1951
1952         * dfg/DFGBackwardsPropagationPhase.cpp:
1953         (JSC::DFG::BackwardsPropagationPhase::propagate):
1954         Thanks to the definition of toUint32(), we can ignore plenty of details
1955         from doubles.
1956
1957         * dfg/DFGByteCodeParser.cpp:
1958         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1959         * dfg/DFGClobberize.h:
1960         (JSC::DFG::clobberize):
1961         * dfg/DFGDoesGC.cpp:
1962         (JSC::DFG::doesGC):
1963         * dfg/DFGFixupPhase.cpp:
1964         (JSC::DFG::FixupPhase::fixupNode):
1965         * dfg/DFGNodeType.h:
1966         * dfg/DFGPredictionPropagationPhase.cpp:
1967         (JSC::DFG::PredictionPropagationPhase::propagate):
1968         * dfg/DFGSafeToExecute.h:
1969         (JSC::DFG::safeToExecute):
1970         * dfg/DFGSpeculativeJIT.cpp:
1971         (JSC::DFG::SpeculativeJIT::compileArithClz32):
1972         * dfg/DFGSpeculativeJIT.h:
1973         * dfg/DFGSpeculativeJIT32_64.cpp:
1974         (JSC::DFG::SpeculativeJIT::compile):
1975         * dfg/DFGSpeculativeJIT64.cpp:
1976         (JSC::DFG::SpeculativeJIT::compile):
1977         * ftl/FTLCapabilities.cpp:
1978         (JSC::FTL::canCompile):
1979         * ftl/FTLIntrinsicRepository.h:
1980         * ftl/FTLLowerDFGToLLVM.cpp:
1981         (JSC::FTL::LowerDFGToLLVM::compileNode):
1982         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
1983         * ftl/FTLOutput.h:
1984         (JSC::FTL::Output::ctlz32):
1985         * jit/ThunkGenerators.cpp:
1986         (JSC::clz32ThunkGenerator):
1987         * jit/ThunkGenerators.h:
1988         * runtime/Intrinsic.h:
1989         * runtime/MathCommon.h:
1990         (JSC::clz32):
1991         Fun fact: InstCombine does not recognize this pattern to eliminate
1992         the branch which makes our FTL version better than the C version.
1993
1994         * runtime/MathObject.cpp:
1995         (JSC::MathObject::finishCreation):
1996         (JSC::mathProtoFuncClz32):
1997         * runtime/NumberPrototype.cpp:
1998         (JSC::clz): Deleted.
1999         (JSC::numberProtoFuncClz): Deleted.
2000         * runtime/VM.cpp:
2001         (JSC::thunkGeneratorForIntrinsic):
2002         * tests/stress/math-clz32-basics.js: Added.
2003         (mathClz32OnInteger):
2004         (testMathClz32OnIntegers):
2005         (verifyMathClz32OnIntegerWithOtherTypes):
2006         (mathClz32OnDouble):
2007         (testMathClz32OnDoubles):
2008         (verifyMathClz32OnDoublesWithOtherTypes):
2009         (mathClz32NoArguments):
2010         (mathClz32TooManyArguments):
2011         (testMathClz32OnConstants):
2012         (mathClz32StructTransition):
2013         (Math.clz32):
2014
2015 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
2016
2017         [ES6] Array.from need to accept iterables
2018         https://bugs.webkit.org/show_bug.cgi?id=141055
2019
2020         Reviewed by Darin Adler.
2021
2022         ES6 spec requires that Array.from accepts iterable objects.
2023         This patch introduces this functionality, Array.from accepting iterable objects.
2024
2025         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
2026         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
2027         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
2028         This will be fixed in the subsequent patch[1].
2029
2030         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
2031
2032         * builtins/ArrayConstructor.js:
2033         (from):
2034         * parser/Parser.cpp:
2035         (JSC::Parser<LexerType>::parseInner):
2036         * runtime/CommonIdentifiers.h:
2037         * runtime/JSGlobalObject.cpp:
2038         (JSC::JSGlobalObject::init):
2039         * tests/stress/array-from-with-iterable.js: Added.
2040         (shouldBe):
2041         (.set for):
2042         (.set var):
2043         (.get var):
2044         (argumentsGenerators):
2045         (.set shouldBe):
2046         (.set new):
2047         * tests/stress/array-from-with-iterator.js: Added.
2048         (shouldBe):
2049         (shouldThrow):
2050         (createIterator.iterator.return):
2051         (createIterator):
2052         (.):
2053
2054 2015-04-25  Jordan Harband  <ljharb@gmail.com>
2055
2056         Set#keys !== Set#values
2057         https://bugs.webkit.org/show_bug.cgi?id=144190
2058
2059         Reviewed by Darin Adler.
2060
2061         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
2062         Set#keys should === Set#values
2063
2064         * runtime/SetPrototype.cpp:
2065         (JSC::SetPrototype::finishCreation):
2066         (JSC::setProtoFuncValues):
2067         (JSC::setProtoFuncEntries):
2068         (JSC::setProtoFuncKeys): Deleted.
2069
2070 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
2071
2072         Allow for pausing a JSContext when opening a Web Inspector
2073         <rdar://problem/20564788>
2074
2075         Reviewed by Timothy Hatcher.
2076
2077         * inspector/remote/RemoteInspector.mm:
2078         (Inspector::RemoteInspector::receivedSetupMessage):
2079         * inspector/remote/RemoteInspectorConstants.h:
2080         * inspector/remote/RemoteInspectorDebuggable.h:
2081         * inspector/remote/RemoteInspectorDebuggableConnection.h:
2082         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
2083         (Inspector::RemoteInspectorDebuggableConnection::setup):
2084         On any incoming setup message, we may want to automatically
2085         pause the debuggable. If requested, pause the debuggable
2086         after we have setup the frontend connection.
2087
2088         * runtime/JSGlobalObjectDebuggable.h:
2089         * runtime/JSGlobalObjectDebuggable.cpp:
2090         (JSC::JSGlobalObjectDebuggable::pause):
2091         Pass through to the inspector controller.
2092
2093         * inspector/JSGlobalObjectInspectorController.h:
2094         * inspector/JSGlobalObjectInspectorController.cpp:
2095         (Inspector::JSGlobalObjectInspectorController::pause):
2096         Enable pause on next statement.
2097
2098 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
2099
2100         class methods should be non-enumerable
2101         https://bugs.webkit.org/show_bug.cgi?id=143181
2102
2103         Reviewed by Darin Adler.
2104
2105         Fixed the bug by using Object.defineProperty to define methods.
2106
2107         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
2108         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
2109
2110         * bytecode/CodeBlock.cpp: 
2111         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
2112         index of zero.
2113         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
2114         exactly one entry for Object.defineProperty.
2115         * bytecode/UnlinkedCodeBlock.h:
2116         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
2117         constant register for the link time constant we're adding.
2118         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
2119         * bytecompiler/BytecodeGenerator.cpp:
2120         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
2121         register for the specified link time constant and notify UnlinkedCodeBlock about it.
2122         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
2123         Object.defineProperty with it.
2124         * bytecompiler/BytecodeGenerator.h:
2125         * bytecompiler/NodesCodegen.cpp:
2126         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
2127         non-enumerable by using emitCallDefineProperty to define them.
2128         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
2129         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
2130         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
2131         * runtime/CommonIdentifiers.h:
2132         * runtime/JSGlobalObject.cpp:
2133         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
2134         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
2135         * runtime/JSGlobalObject.h:
2136         (JSC::JSGlobalObject::definePropertyFunction): Added.
2137         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
2138         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
2139         returns a JSCell; e.g. Object.defineProperty.
2140         * runtime/ObjectConstructor.cpp:
2141         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
2142         * runtime/ObjectConstructor.h:
2143
2144 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
2145
2146         [ES6] Implement String.fromCodePoint
2147         https://bugs.webkit.org/show_bug.cgi?id=144160
2148
2149         Reviewed by Darin Adler.
2150
2151         This patch implements String.fromCodePoint.
2152         It accepts multiple code points and generates a string that consists of given code points.
2153         The range [0x0000 - 0x10FFFF] is valid for code points.
2154         If the given value is out of range, throw a range error.
2155
2156         When a 0xFFFF <= valid code point is given,
2157         String.fromCodePoint generates a string that contains surrogate pairs.
2158
2159         * runtime/StringConstructor.cpp:
2160         (JSC::stringFromCodePoint):
2161         (JSC::constructWithStringConstructor):
2162         * tests/stress/string-from-code-point.js: Added.
2163         (shouldBe):
2164         (shouldThrow):
2165         (toCodePoints):
2166         (passThrough):
2167
2168 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
2169
2170         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
2171         https://bugs.webkit.org/show_bug.cgi?id=144182
2172
2173         Reviewed by Simon Fraser.
2174
2175         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
2176
2177 2015-04-25  Mark Lam  <mark.lam@apple.com>
2178
2179         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
2180         https://bugs.webkit.org/show_bug.cgi?id=144152
2181
2182         Reviewed by Filip Pizlo.
2183
2184         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
2185         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
2186         OSR exits.  This was overlooked in the original code.
2187
2188         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
2189         the Branch node, the other 3 may also trigger the same bug for other nodes.
2190         To prevent this bug from manifesting with other nodes (and future ones that
2191         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
2192         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
2193
2194         Also added a test to exercise a code path that will trigger this bug with
2195         the Branch node before the fix is applied.
2196
2197         * dfg/DFGMayExit.cpp:
2198         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
2199         (inlinedFunction):
2200         (foo):
2201
2202 2015-04-24  Commit Queue  <commit-queue@webkit.org>
2203
2204         Unreviewed, rolling out r183288.
2205         https://bugs.webkit.org/show_bug.cgi?id=144189
2206
2207         Made js/sort-with-side-effecting-comparisons.html time out in
2208         debug builds (Requested by ap on #webkit).
2209
2210         Reverted changeset:
2211
2212         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
2213         array."
2214         https://bugs.webkit.org/show_bug.cgi?id=144013
2215         http://trac.webkit.org/changeset/183288
2216
2217 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
2218
2219         CRASH in operationCreateDirectArgumentsDuringExit()
2220         https://bugs.webkit.org/show_bug.cgi?id=143962
2221
2222         Reviewed by Geoffrey Garen.
2223         
2224         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
2225         recoverable so long as they are live. Therefore, OSR exit should track liveness of
2226         constants instead of assuming that they are always live.
2227
2228         * dfg/DFGGenerationInfo.h:
2229         (JSC::DFG::GenerationInfo::noticeOSRBirth):
2230         (JSC::DFG::GenerationInfo::appendBirth):
2231         * dfg/DFGSpeculativeJIT.cpp:
2232         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2233         * dfg/DFGVariableEvent.cpp:
2234         (JSC::DFG::VariableEvent::dump):
2235         * dfg/DFGVariableEvent.h:
2236         (JSC::DFG::VariableEvent::birth):
2237         (JSC::DFG::VariableEvent::id):
2238         (JSC::DFG::VariableEvent::dataFormat):
2239         * dfg/DFGVariableEventStream.cpp:
2240         (JSC::DFG::VariableEventStream::reconstruct):
2241         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
2242         (foo):
2243         (bar):
2244         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
2245         (foo):
2246         (bar):
2247
2248 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
2249
2250         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
2251         https://bugs.webkit.org/show_bug.cgi?id=144169
2252
2253         Reviewed by Geoffrey Garen.
2254
2255         * runtime/JSObject.cpp:
2256         (JSC::JSObject::convertInt32ForValue):
2257         DoubleArray do not store NaN, they are used for holes.
2258         What happened was:
2259         1) We fail to insert the NaN in the Int32 array because it is a double.
2260         2) We were converting the array to DoubleArray.
2261         3) We were trying to insert the value again. We would fail again because
2262            DoubleArray does not store NaN.
2263         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
2264            to boxed values.
2265
2266         * tests/stress/int32array-transition-on-nan.js: Added.
2267         The behavior is not really observable. This only test nothing crashes in those
2268         cases.
2269
2270         (insertNaNWhileFilling):
2271         (testInsertNaNWhileFilling):
2272         (insertNaNAfterFilling):
2273         (testInsertNaNAfterFilling):
2274         (pushNaNWhileFilling):
2275         (testPushNaNWhileFilling):
2276
2277 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
2278
2279         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
2280         https://bugs.webkit.org/show_bug.cgi?id=144013
2281
2282         Reviewed by Mark Lam.
2283
2284         This patch implements Array.prototype.sort in JavaScript, removing the
2285         C++ implementations. It is simpler and less error-prone to express our
2286         operations in JavaScript, which provides memory safety, exception safety,
2287         and recursion safety.
2288
2289         The performance result is mixed, but net positive in my opinion. It's
2290         difficult to enumerate all the results, since we used to have so many
2291         different sorting modes, and there are lots of different data patterns
2292         across which you might want to measure sorting. Suffice it to say:
2293
2294             (*) The benchmarks we track are faster or unchanged.
2295
2296             (*) Sorting random input using a comparator -- which we think is
2297             common -- is 3X faster.
2298
2299             (*) Sorting random input in a non-array object -- which jQuery does
2300             -- is 4X faster.
2301
2302             (*) Sorting random input in a compact array of integers using a
2303             trivial pattern-matchable comparator is 2X *slower*.
2304
2305         * builtins/Array.prototype.js:
2306         (sort.min):
2307         (sort.stringComparator):
2308         (sort.compactSparse): Special case compaction for sparse arrays because
2309         we don't want to hang when sorting new Array(BIG).
2310
2311         (sort.compact):
2312         (sort.merge):
2313         (sort.mergeSort): Use merge sort because it's a reasonably efficient
2314         stable sort. We have evidence that some sites depend on stable sort,
2315         even though the ES6 spec does not mandate it. (See
2316         <http://trac.webkit.org/changeset/33967>.)
2317
2318         This is a textbook implementation of merge sort with three optimizations:
2319
2320             (1) Use iteration instead of recursion;
2321
2322             (2) Use array subscripting instead of array copying in order to
2323             create logical sub-lists without creating physical sub-lists;
2324
2325             (3) Swap src and dst at each iteration instead of copying src into
2326             dst, and only copy src into the subject array at the end if src is
2327             not the subject array.
2328
2329         (sort.inflate):
2330         (sort.comparatorSort):
2331         (sort): Sort in JavaScript for the win.
2332
2333         * builtins/BuiltinExecutables.cpp:
2334         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
2335         names so we can use helper functions.
2336
2337         * bytecode/CodeBlock.h:
2338         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
2339         * bytecode/UnlinkedCodeBlock.cpp:
2340         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2341         * bytecode/UnlinkedCodeBlock.h:
2342         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2343         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2344         * bytecompiler/BytecodeGenerator.cpp:
2345         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2346         * bytecompiler/BytecodeGenerator.h:
2347         * bytecompiler/NodesCodegen.cpp:
2348         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2349         on pattern matching anymore. This was mainly an optimization to avoid 
2350         the overhead of calling from C++ to JS, which we now avoid by
2351         sorting in JS.
2352
2353         * heap/Heap.cpp:
2354         (JSC::Heap::markRoots):
2355         (JSC::Heap::pushTempSortVector): Deleted.
2356         (JSC::Heap::popTempSortVector): Deleted.
2357         (JSC::Heap::visitTempSortVectors): Deleted.
2358         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
2359         in JavaScript using a normal JavaScript array for our temporary storage.
2360
2361         * parser/Parser.cpp:
2362         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
2363         helper functions.
2364
2365         * runtime/ArrayPrototype.cpp:
2366         (JSC::isNumericCompareFunction): Deleted.
2367         (JSC::attemptFastSort): Deleted.
2368         (JSC::performSlowSort): Deleted.
2369         (JSC::arrayProtoFuncSort): Deleted.
2370
2371         * runtime/CommonIdentifiers.h: New strings used by sort.
2372
2373         * runtime/JSArray.cpp:
2374         (JSC::compareNumbersForQSortWithInt32): Deleted.
2375         (JSC::compareNumbersForQSortWithDouble): Deleted.
2376         (JSC::compareNumbersForQSort): Deleted.
2377         (JSC::compareByStringPairForQSort): Deleted.
2378         (JSC::JSArray::sortNumericVector): Deleted.
2379         (JSC::JSArray::sortNumeric): Deleted.
2380         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
2381         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
2382         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
2383         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
2384         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
2385         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
2386         (JSC::JSArray::sortCompactedVector): Deleted.
2387         (JSC::JSArray::sort): Deleted.
2388         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
2389         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
2390         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
2391         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
2392         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
2393         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
2394         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
2395         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
2396         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
2397         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
2398         (JSC::JSArray::sortVector): Deleted.
2399         (JSC::JSArray::compactForSorting): Deleted.
2400         * runtime/JSArray.h:
2401
2402         * runtime/JSGlobalObject.cpp:
2403         (JSC::JSGlobalObject::init):
2404         * runtime/ObjectConstructor.cpp:
2405         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
2406         by sort.
2407
2408 2015-04-24  Matthew Mirman  <mmirman@apple.com>
2409
2410         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
2411         https://bugs.webkit.org/show_bug.cgi?id=141865
2412         rdar://problem/19927273
2413
2414         Reviewed by Filip Pizlo.
2415
2416         * runtime/JSGlobalObjectFunctions.cpp:
2417         (JSC::globalFuncProtoGetter):
2418         (JSC::globalFuncProtoSetter):
2419
2420 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
2421
2422         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
2423         https://bugs.webkit.org/show_bug.cgi?id=144118
2424
2425         Reviewed by Geoffrey Garen.
2426
2427         * dfg/DFGGraph.h:
2428         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
2429         Both block do the same thing.
2430
2431 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2432
2433         Web Inspector: Speculative fix for non-main thread auto-attach failures
2434         https://bugs.webkit.org/show_bug.cgi?id=144134
2435
2436         Reviewed by Timothy Hatcher.
2437
2438         * inspector/remote/RemoteInspector.mm:
2439         (Inspector::RemoteInspector::singleton):
2440
2441 2015-04-23  Basile Clement  <basile_clement@apple.com>
2442
2443         Allow function allocation sinking
2444         https://bugs.webkit.org/show_bug.cgi?id=144016
2445
2446         Reviewed by Filip Pizlo.
2447
2448         This adds the ability to sink function allocations in the
2449         DFGObjectAllocationSinkingPhase.
2450
2451         In order to enable this, we add a new PhantomNewFunction node that is
2452         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
2453         a sunk NewFunction and keep track of the allocations that have to be performed
2454         in case of OSR exit after the sunk allocation but before the real one.
2455         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
2456         are stored onto the PhantomNewFunction through PutHints in order for them
2457         to be recovered on OSR exit.
2458
2459         Contrary to sunk object allocations, sunk function allocations do not
2460         support any kind of operations (e.g. storing into a field) ; any such operation
2461         will mark the function allocation as escaping and trigger materialization. As
2462         such, function allocations can only be sunk to places where it would have been
2463         correct to syntactically move them, and we don't need a special
2464         MaterializeNewFunction node to recover possible operations on the function. A
2465         sunk NewFunction node will simply create new NewFunction nodes, then replace
2466         itself with a PhantomNewFunction node.
2467
2468         In itself, this change is not expected to have a significant impact on
2469         performances other than in degenerate cases (see e.g.
2470         JSRegress/sink-function), but it is a step towards being able to sink recursive
2471         closures onces we support CreateActivation sinking as well as allocation cycles
2472         sinking.
2473
2474         * dfg/DFGAbstractInterpreterInlines.h:
2475         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2476         * dfg/DFGClobberize.h:
2477         (JSC::DFG::clobberize):
2478         * dfg/DFGDoesGC.cpp:
2479         (JSC::DFG::doesGC):
2480         * dfg/DFGFixupPhase.cpp:
2481         (JSC::DFG::FixupPhase::fixupNode):
2482         * dfg/DFGNode.h:
2483         (JSC::DFG::Node::convertToPhantomNewFunction):
2484         (JSC::DFG::Node::isPhantomAllocation):
2485         * dfg/DFGNodeType.h:
2486         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2487         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2488         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2489         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2490         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2491         * dfg/DFGPredictionPropagationPhase.cpp:
2492         (JSC::DFG::PredictionPropagationPhase::propagate):
2493         * dfg/DFGPromotedHeapLocation.cpp:
2494         (WTF::printInternal):
2495         * dfg/DFGPromotedHeapLocation.h:
2496         * dfg/DFGSafeToExecute.h:
2497         (JSC::DFG::safeToExecute):
2498         * dfg/DFGSpeculativeJIT32_64.cpp:
2499         (JSC::DFG::SpeculativeJIT::compile):
2500         * dfg/DFGSpeculativeJIT64.cpp:
2501         (JSC::DFG::SpeculativeJIT::compile):
2502         * dfg/DFGValidate.cpp:
2503         (JSC::DFG::Validate::validateCPS):
2504         * ftl/FTLCapabilities.cpp:
2505         (JSC::FTL::canCompile):
2506         * ftl/FTLLowerDFGToLLVM.cpp:
2507         (JSC::FTL::LowerDFGToLLVM::compileNode):
2508         * ftl/FTLOperations.cpp:
2509         (JSC::FTL::operationMaterializeObjectInOSR):
2510         * tests/stress/function-sinking-no-double-allocate.js: Added.
2511         (call):
2512         (.f):
2513         (sink):
2514         * tests/stress/function-sinking-osrexit.js: Added.
2515         (.g):
2516         (sink):
2517         * tests/stress/function-sinking-put.js: Added.
2518         (.g):
2519         (sink):
2520
2521 2015-04-23  Basile Clement  <basile_clement@apple.com>
2522
2523         Make FunctionRareData allocation thread-safe
2524         https://bugs.webkit.org/show_bug.cgi?id=144001
2525
2526         Reviewed by Mark Lam.
2527
2528         The two things we want to prevent are:
2529
2530          1. A thread seeing a pointer to a not-yet-fully-created rare data from
2531             a JSFunction
2532          2. A thread seeing a pointer to a not-yet-fully-created Structure from
2533             an ObjectAllocationProfile
2534
2535         For 1., only the JS thread can be creating the rare data (in
2536         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
2537         worry about concurrent writes, and we don't need any fences when *reading* the
2538         rare data from the JS thread. Thus we only need a storeStoreFence between the
2539         rare data creation and assignment to m_rareData in
2540         JSFunction::createAndInitializeRareData() to ensure that when the store to
2541         m_rareData is issued, the rare data has been properly created.
2542
2543         For the DFG compilation threads, the only place they can access the
2544         rare data is through JSFunction::rareData(), and so we only need a
2545         loadLoadFence there to ensure that when we see a non-null pointer in
2546         m_rareData, the pointed object will be seen as a fully created
2547         FunctionRareData.
2548
2549
2550         For 2., the structure is created in
2551         ObjectAllocationProfile::initialize() (which appears to be called only by the
2552         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
2553         which always happen in the JS thread), and read through
2554         ObjectAllocationProfile::structure() and
2555         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
2556         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
2557         loadLoadFence in ObjectAllocationProfile::structure() (and change
2558         ObjectAllocationProfile::inlineCapacity() to go through
2559         ObjectAllocationProfile::structure()).
2560
2561         We don't need a fence in ObjectAllocationProfile::clear() because
2562         clearing the structure is already as atomic as it gets.
2563
2564         Finally, notice that we don't care about the ObjectAllocationProfile's
2565         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
2566         ObjectAllocationProfile::clear() that are always run in the JS thread.
2567         ObjectAllocationProfile::isNull() could cause some trouble, but it is
2568         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
2569         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
2570         thread anyway.
2571
2572         * bytecode/ObjectAllocationProfile.h:
2573         (JSC::ObjectAllocationProfile::initialize):
2574         (JSC::ObjectAllocationProfile::structure):
2575         (JSC::ObjectAllocationProfile::inlineCapacity):
2576         * runtime/JSFunction.cpp:
2577         (JSC::JSFunction::allocateAndInitializeRareData):
2578         * runtime/JSFunction.h:
2579         (JSC::JSFunction::rareData):
2580         (JSC::JSFunction::allocationStructure): Deleted.
2581         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2582
2583 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2584
2585         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
2586         https://bugs.webkit.org/show_bug.cgi?id=143735
2587
2588         Reviewed by Geoffrey Garen.
2589         
2590         We've always had bugs arising from the fact that we would MovHint something into a local,
2591         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
2592         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
2593         sophistication of the transformations we are doing today, this approach is just not sound
2594         anymore.
2595         
2596         This comprehensively fixes these bugs by having the DFG backend automatically insert
2597         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
2598         makes it much faster to query bytecode liveness.
2599         
2600         It's about as perf-neutral as it gets for a change that increases compiler work without
2601         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
2602         which should then speed us up. I can't really report concrete slow-down numbers because
2603         they are low enough to basically be in the noise. For example, a 20-iteration run of
2604         SunSpider yields "maybe 0.8% slower", whatever that means.
2605
2606         * CMakeLists.txt:
2607         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2608         * JavaScriptCore.xcodeproj/project.pbxproj:
2609         * bytecode/BytecodeLivenessAnalysis.cpp:
2610         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
2611         * bytecode/FullBytecodeLiveness.h:
2612         (JSC::FullBytecodeLiveness::getLiveness):
2613         * bytecode/VirtualRegister.h:
2614         (JSC::VirtualRegister::operator+):
2615         (JSC::VirtualRegister::operator-):
2616         * dfg/DFGForAllKills.h:
2617         (JSC::DFG::forAllLiveNodesAtTail):
2618         (JSC::DFG::forAllKilledOperands):
2619         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2620         * dfg/DFGGraph.cpp:
2621         (JSC::DFG::Graph::isLiveInBytecode):
2622         (JSC::DFG::Graph::localsLiveInBytecode):
2623         * dfg/DFGGraph.h:
2624         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2625         (JSC::DFG::Graph::forAllLiveInBytecode):
2626         * dfg/DFGMayExit.cpp:
2627         (JSC::DFG::mayExit):
2628         * dfg/DFGMovHintRemovalPhase.cpp:
2629         * dfg/DFGNodeType.h:
2630         * dfg/DFGPhantomInsertionPhase.cpp: Added.
2631         (JSC::DFG::performPhantomInsertion):
2632         * dfg/DFGPhantomInsertionPhase.h: Added.
2633         * dfg/DFGPlan.cpp:
2634         (JSC::DFG::Plan::compileInThreadImpl):
2635         * dfg/DFGScoreBoard.h:
2636         (JSC::DFG::ScoreBoard::sortFree):
2637         (JSC::DFG::ScoreBoard::assertClear):
2638         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2639         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2640         * ftl/FTLLowerDFGToLLVM.cpp:
2641         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2642         * tests/stress/phantom-inadequacy.js: Added.
2643         (bar):
2644         (baz):
2645         (foo):
2646
2647 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
2648
2649         Rename HardPhantom to MustGenerate.
2650
2651         Rubber stamped by Geoffrey Garen.
2652         
2653         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
2654         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
2655         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
2656         node should just be called MustGenerate.
2657
2658         * dfg/DFGAbstractInterpreterInlines.h:
2659         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2660         * dfg/DFGArgumentsEliminationPhase.cpp:
2661         * dfg/DFGClobberize.h:
2662         (JSC::DFG::clobberize):
2663         * dfg/DFGDCEPhase.cpp:
2664         (JSC::DFG::DCEPhase::run):
2665         * dfg/DFGDoesGC.cpp:
2666         (JSC::DFG::doesGC):
2667         * dfg/DFGFixupPhase.cpp:
2668         (JSC::DFG::FixupPhase::fixupNode):
2669         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
2670         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2671         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
2672         * dfg/DFGMayExit.cpp:
2673         (JSC::DFG::mayExit):
2674         * dfg/DFGNode.h:
2675         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2676         * dfg/DFGNodeType.h:
2677         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2678         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2679         * dfg/DFGPhantomCanonicalizationPhase.cpp:
2680         (JSC::DFG::PhantomCanonicalizationPhase::run):
2681         * dfg/DFGPhantomRemovalPhase.cpp:
2682         (JSC::DFG::PhantomRemovalPhase::run):
2683         * dfg/DFGPredictionPropagationPhase.cpp:
2684         (JSC::DFG::PredictionPropagationPhase::propagate):
2685         * dfg/DFGSafeToExecute.h:
2686         (JSC::DFG::safeToExecute):
2687         * dfg/DFGSpeculativeJIT32_64.cpp:
2688         (JSC::DFG::SpeculativeJIT::compile):
2689         * dfg/DFGSpeculativeJIT64.cpp:
2690         (JSC::DFG::SpeculativeJIT::compile):
2691         * dfg/DFGTypeCheckHoistingPhase.cpp:
2692         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2693         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2694         * dfg/DFGVarargsForwardingPhase.cpp:
2695         * ftl/FTLCapabilities.cpp:
2696         (JSC::FTL::canCompile):
2697         * ftl/FTLLowerDFGToLLVM.cpp:
2698         (JSC::FTL::LowerDFGToLLVM::compileNode):
2699
2700 2015-04-23  Jordan Harband  <ljharb@gmail.com>
2701
2702         Implement `Object.assign`
2703         https://bugs.webkit.org/show_bug.cgi?id=143980
2704
2705         Reviewed by Filip Pizlo.
2706
2707         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
2708
2709         * builtins/ObjectConstructor.js: Added.
2710         (assign):
2711         * runtime/CommonIdentifiers.h:
2712         * runtime/JSGlobalObject.cpp:
2713         (JSC::JSGlobalObject::init):
2714         * runtime/ObjectConstructor.cpp:
2715         * runtime/ObjectConstructor.h:
2716
2717 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2718
2719         Unreviewed, fix debug build.
2720
2721         * dfg/DFGGraph.h:
2722         (JSC::DFG::Graph::performSubstitutionForEdge):
2723
2724 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2725
2726         Nodes should have an optional epoch field
2727         https://bugs.webkit.org/show_bug.cgi?id=144084
2728
2729         Reviewed by Ryosuke Niwa and Mark Lam.
2730         
2731         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
2732         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
2733         used.
2734
2735         * dfg/DFGCPSRethreadingPhase.cpp:
2736         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2737         * dfg/DFGCSEPhase.cpp:
2738         * dfg/DFGEpoch.h:
2739         (JSC::DFG::Epoch::fromUnsigned):
2740         (JSC::DFG::Epoch::toUnsigned):
2741         * dfg/DFGGraph.cpp:
2742         (JSC::DFG::Graph::clearReplacements):
2743         (JSC::DFG::Graph::clearEpochs):
2744         * dfg/DFGGraph.h:
2745         (JSC::DFG::Graph::performSubstitutionForEdge):
2746         * dfg/DFGNode.h:
2747         (JSC::DFG::Node::Node):
2748         (JSC::DFG::Node::replaceWith):
2749         (JSC::DFG::Node::replacement):
2750         (JSC::DFG::Node::setReplacement):
2751         (JSC::DFG::Node::epoch):
2752         (JSC::DFG::Node::setEpoch):
2753         * dfg/DFGSSAConversionPhase.cpp:
2754         (JSC::DFG::SSAConversionPhase::run):
2755
2756 2015-04-22  Mark Lam  <mark.lam@apple.com>
2757
2758         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
2759         https://bugs.webkit.org/show_bug.cgi?id=143898
2760
2761         Reviewed by Filip Pizlo.
2762
2763         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
2764         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
2765         compilation threads because StringImpls are not thread safe. As a result, we get
2766         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
2767         build.
2768
2769         This patch fixes the issue by only collecting the CodeBlock (and associated info)
2770         into a DeferredSourceDump record while compiling, and stashing it away in a
2771         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
2772         later.
2773
2774         When compilation is done, the callback object will be notified that
2775         compilationDidComplete().  We will dump the SourceCode strings from there. 
2776         Since compilationDidComplete() is guaranteed to only be called on the thread
2777         doing JS execution, it is safe to access the SourceCode strings there and ref
2778         their underlying StringImpls as needed.        
2779
2780         * CMakeLists.txt:
2781         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2782         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2783         * JavaScriptCore.xcodeproj/project.pbxproj:
2784         * bytecode/DeferredCompilationCallback.cpp:
2785         (JSC::DeferredCompilationCallback::compilationDidComplete):
2786         (JSC::DeferredCompilationCallback::sourceDumpInfo):
2787         (JSC::DeferredCompilationCallback::dumpCompiledSources):
2788         * bytecode/DeferredCompilationCallback.h:
2789         * bytecode/DeferredSourceDump.cpp: Added.
2790         (JSC::DeferredSourceDump::DeferredSourceDump):
2791         (JSC::DeferredSourceDump::dump):
2792         * bytecode/DeferredSourceDump.h: Added.
2793         * dfg/DFGByteCodeParser.cpp:
2794         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2795         * dfg/DFGDriver.cpp:
2796         (JSC::DFG::compileImpl):
2797
2798 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
2799
2800         Implement String.codePointAt()
2801         https://bugs.webkit.org/show_bug.cgi?id=143934
2802
2803         Reviewed by Darin Adler.
2804
2805         This patch adds String.codePointAt() as defined by ES6.
2806         I opted for a C++ implementation for now.
2807
2808         * runtime/StringPrototype.cpp:
2809         (JSC::StringPrototype::finishCreation):
2810         (JSC::codePointAt):
2811         (JSC::stringProtoFuncCodePointAt):
2812
2813 2015-04-22  Mark Lam  <mark.lam@apple.com>
2814
2815         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
2816         https://bugs.webkit.org/show_bug.cgi?id=144067
2817
2818         Reviewed by Michael Saboff.
2819
2820         Currently, there are a few places where the JSObject that owns the
2821         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
2822         write barrier.  This is a bug and can result in the GC collecting the
2823         SparseArrayEntry even though it is being referenced by the
2824         SparseArrayValueMap.  This patch fixes the bug.
2825
2826         * runtime/JSObject.cpp:
2827         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
2828         (JSC::JSObject::putIndexedDescriptor):
2829         * tests/stress/sparse-array-entry-update-144067.js: Added.
2830         (useMemoryToTriggerGCs):
2831         (foo):
2832
2833 2015-04-22  Mark Lam  <mark.lam@apple.com>
2834
2835         Give the heap object iterators the ability to return early.
2836         https://bugs.webkit.org/show_bug.cgi?id=144011
2837
2838         Reviewed by Michael Saboff.
2839
2840         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
2841         candidate cell pointers, and, when in use, is called a lot more often than
2842         the normal way those iterators are used.  As a result, I see my instrumented
2843         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
2844         callback functor the ability to tell the iterators to return early when the
2845         functor no longer needs to continue iterating.  With this, my instrumented
2846         VM is useful again for debugging.
2847
2848         Since heap iteration is not something that we do in a typical fast path,
2849         I don't expect this to have any noticeable impact on performance.
2850
2851         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
2852         it checks JSCell addresses, not just JSObjects.
2853
2854         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2855         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2856         * JavaScriptCore.xcodeproj/project.pbxproj:
2857         * debugger/Debugger.cpp:
2858         * heap/GCLogging.cpp:
2859         (JSC::LoggingFunctor::operator()):
2860         * heap/Heap.cpp:
2861         (JSC::Zombify::visit):
2862         (JSC::Zombify::operator()):
2863         * heap/HeapStatistics.cpp:
2864         (JSC::StorageStatistics::visit):
2865         (JSC::StorageStatistics::operator()):
2866         * heap/HeapVerifier.cpp:
2867         (JSC::GatherLiveObjFunctor::visit):
2868         (JSC::GatherLiveObjFunctor::operator()):
2869         * heap/MarkedBlock.cpp:
2870         (JSC::SetNewlyAllocatedFunctor::operator()):
2871         * heap/MarkedBlock.h:
2872         (JSC::MarkedBlock::forEachCell):
2873         (JSC::MarkedBlock::forEachLiveCell):
2874         (JSC::MarkedBlock::forEachDeadCell):
2875         * heap/MarkedSpace.h:
2876         (JSC::MarkedSpace::forEachLiveCell):
2877         (JSC::MarkedSpace::forEachDeadCell):
2878         * inspector/agents/InspectorRuntimeAgent.cpp:
2879         (Inspector::TypeRecompiler::visit):
2880         (Inspector::TypeRecompiler::operator()):
2881         * runtime/IterationStatus.h: Added.
2882         * runtime/JSGlobalObject.cpp:
2883         * runtime/VM.cpp:
2884         (JSC::StackPreservingRecompiler::visit):
2885         (JSC::StackPreservingRecompiler::operator()):
2886         * tools/JSDollarVMPrototype.cpp:
2887         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2888         (JSC::CellAddressCheckFunctor::operator()):
2889         (JSC::JSDollarVMPrototype::isValidCell):
2890         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
2891         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
2892
2893 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
2894
2895         [[Set]] should be properly executed in JS builtins
2896         https://bugs.webkit.org/show_bug.cgi?id=143996
2897
2898         Reviewed by Geoffrey Garen.
2899
2900         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
2901         However,
2902
2903         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
2904         2. It's different from the default JS behavior.
2905
2906         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
2907         And dropping the current hack for builtins.
2908
2909         * builtins/Array.prototype.js:
2910         (filter):
2911         (map):
2912         (find):
2913         * bytecompiler/BytecodeGenerator.cpp:
2914         (JSC::BytecodeGenerator::emitPutByVal):
2915         * tests/stress/array-fill-put-by-val.js: Added.
2916         (shouldThrow):
2917         (.set get array):
2918         * tests/stress/array-filter-put-by-val-direct.js: Added.
2919         (shouldBe):
2920         (.set get var):
2921         * tests/stress/array-find-does-not-lookup-twice.js: Added.
2922         (shouldBe):
2923         (shouldThrow):
2924         (.get shouldBe):
2925         * tests/stress/array-from-put-by-val-direct.js: Added.
2926         (shouldBe):
2927         (.set get var):
2928         * tests/stress/array-from-set-length.js: Added.
2929         (shouldBe):
2930         (ArrayLike):
2931         (ArrayLike.prototype.set length):
2932         (ArrayLike.prototype.get length):
2933         * tests/stress/array-map-put-by-val-direct.js: Added.
2934         (shouldBe):
2935         (.set get var):
2936
2937 2015-04-22  Basile Clement  <basile_clement@apple.com>
2938  
2939         Don't de-allocate FunctionRareData
2940         https://bugs.webkit.org/show_bug.cgi?id=144000
2941
2942         Reviewed by Michael Saboff.
2943
2944         A function rare data (containing most notably its allocation profile) is currently
2945         freed and re-allocated each time the function's prototype is cleared.
2946         This is not optimal as it means we are invalidating the watchpoint and recompiling the
2947         scope each time the prototype is cleared.
2948
2949         This makes it so that a single rare data is reused, clearing the underlying
2950         ObjectAllocationProfile instead of throwing away the whole rare data on
2951         .prototype updates.
2952
2953         * runtime/FunctionRareData.cpp:
2954         (JSC::FunctionRareData::create):
2955         (JSC::FunctionRareData::finishCreation):
2956         * runtime/FunctionRareData.h:
2957         * runtime/JSFunction.cpp:
2958         (JSC::JSFunction::allocateAndInitializeRareData):
2959         (JSC::JSFunction::initializeRareData):
2960
2961 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2962
2963         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
2964
2965         * dfg/DFGSpeculativeJIT32_64.cpp:
2966         (JSC::DFG::SpeculativeJIT::compile):
2967
2968 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2969
2970         DFG should allow Phantoms after terminals
2971         https://bugs.webkit.org/show_bug.cgi?id=126778
2972
2973         Reviewed by Mark Lam.
2974         
2975         It's important for us to be able to place liveness-marking nodes after nodes that do
2976         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
2977         terminals. That made things awkward, especially for Switch and Branch, which may do
2978         things that necessitate liveness markers (for example they might want to use a converted
2979         version of a value rather than the value that was MovHinted). We previously made this
2980         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
2981         thing.
2982         
2983         This changes our IR to allow for the terminal to not be the last node in a block. Asking
2984         for the terminal involves a search. DFG::validate() checks that the nodes after the
2985         terminal are liveness markers that have no effects or checks.
2986         
2987         This is perf-neutral but will allow more optimizations in the future. It will also make
2988         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
2989
2990         * dfg/DFGBasicBlock.cpp:
2991         (JSC::DFG::BasicBlock::replaceTerminal):
2992         * dfg/DFGBasicBlock.h:
2993         (JSC::DFG::BasicBlock::findTerminal):
2994         (JSC::DFG::BasicBlock::terminal):
2995         (JSC::DFG::BasicBlock::insertBeforeTerminal):
2996         (JSC::DFG::BasicBlock::numSuccessors):
2997         (JSC::DFG::BasicBlock::successor):
2998         (JSC::DFG::BasicBlock::successorForCondition):
2999         (JSC::DFG::BasicBlock::successors):
3000         (JSC::DFG::BasicBlock::last): Deleted.
3001         (JSC::DFG::BasicBlock::takeLast): Deleted.
3002         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
3003         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
3004         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
3005         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
3006         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
3007         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
3008         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
3009         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
3010         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
3011         * dfg/DFGBasicBlockInlines.h:
3012         (JSC::DFG::BasicBlock::appendNonTerminal):
3013         (JSC::DFG::BasicBlock::replaceTerminal):
3014         * dfg/DFGByteCodeParser.cpp:
3015         (JSC::DFG::ByteCodeParser::addToGraph):
3016         (JSC::DFG::ByteCodeParser::inlineCall):
3017         (JSC::DFG::ByteCodeParser::handleInlining):
3018         (JSC::DFG::ByteCodeParser::parseBlock):
3019         (JSC::DFG::ByteCodeParser::linkBlock):
3020         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3021         * dfg/DFGCFGSimplificationPhase.cpp:
3022         (JSC::DFG::CFGSimplificationPhase::run):
3023         (JSC::DFG::CFGSimplificationPhase::convertToJump):
3024         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
3025         * dfg/DFGCPSRethreadingPhase.cpp:
3026         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3027         * dfg/DFGCommon.h:
3028         (JSC::DFG::NodeAndIndex::NodeAndIndex):
3029         (JSC::DFG::NodeAndIndex::operator!):
3030         * dfg/DFGFixupPhase.cpp:
3031         (JSC::DFG::FixupPhase::fixupBlock):
3032         (JSC::DFG::FixupPhase::fixupNode):
3033         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
3034         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
3035         * dfg/DFGForAllKills.h:
3036         (JSC::DFG::forAllLiveNodesAtTail):
3037         * dfg/DFGGraph.cpp:
3038         (JSC::DFG::Graph::terminalsAreValid):
3039         (JSC::DFG::Graph::dumpBlockHeader):
3040         * dfg/DFGGraph.h:
3041         * dfg/DFGInPlaceAbstractState.cpp:
3042         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
3043         * dfg/DFGLICMPhase.cpp:
3044         (JSC::DFG::LICMPhase::run):
3045         (JSC::DFG::LICMPhase::attemptHoist):
3046         * dfg/DFGMovHintRemovalPhase.cpp:
3047         * dfg/DFGNode.h:
3048         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
3049         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
3050         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
3051         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
3052         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
3053         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
3054         (JSC::DFG::Node::SuccessorsIterable::begin):
3055         (JSC::DFG::Node::SuccessorsIterable::end):
3056         (JSC::DFG::Node::successors):
3057         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3058         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
3059         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
3060         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
3061         * dfg/DFGPhantomRemovalPhase.cpp:
3062         (JSC::DFG::PhantomRemovalPhase::run):
3063         * dfg/DFGPutStackSinkingPhase.cpp:
3064         * dfg/DFGSSAConversionPhase.cpp:
3065         (JSC::DFG::SSAConversionPhase::run):
3066         * dfg/DFGSpeculativeJIT.h:
3067         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
3068         * dfg/DFGSpeculativeJIT32_64.cpp:
3069         (JSC::DFG::SpeculativeJIT::compile):
3070         * dfg/DFGSpeculativeJIT64.cpp:
3071         (JSC::DFG::SpeculativeJIT::compile):
3072         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
3073         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
3074         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3075         (JSC::DFG::TierUpCheckInjectionPhase::run):
3076         * dfg/DFGValidate.cpp:
3077         (JSC::DFG::Validate::validate):
3078         * ftl/FTLLowerDFGToLLVM.cpp:
3079         (JSC::FTL::LowerDFGToLLVM::compileNode):
3080         * tests/stress/closure-call-exit.js: Added.
3081         (foo):
3082
3083 2015-04-21  Basile Clement  <basile_clement@apple.com>
3084
3085         PhantomNewObject should be marked NodeMustGenerate
3086         https://bugs.webkit.org/show_bug.cgi?id=143974
3087
3088         Reviewed by Filip Pizlo.
3089
3090         * dfg/DFGNode.h:
3091         (JSC::DFG::Node::convertToPhantomNewObject):
3092         Was not properly marking NodeMustGenerate when converting.
3093
3094 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3095
3096         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
3097         https://bugs.webkit.org/show_bug.cgi?id=144007
3098
3099         Reviewed by Mark Lam.
3100         
3101         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
3102         if isForwardVarargs.
3103
3104         * dfg/DFGSpeculativeJIT32_64.cpp:
3105         (JSC::DFG::SpeculativeJIT::emitCall):
3106         * dfg/DFGSpeculativeJIT64.cpp:
3107         (JSC::DFG::SpeculativeJIT::emitCall):
3108         * tests/stress/varargs-then-slow-call.js: Added.
3109         (foo):
3110         (bar):
3111         (fuzz):
3112         (baz):
3113
3114 2015-04-21  Basile Clement  <basile_clement@apple.com>
3115
3116         Remove AllocationProfileWatchpoint node
3117         https://bugs.webkit.org/show_bug.cgi?id=143999
3118
3119         Reviewed by Filip Pizlo.
3120
3121         * dfg/DFGAbstractInterpreterInlines.h:
3122         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3123         * dfg/DFGByteCodeParser.cpp:
3124         (JSC::DFG::ByteCodeParser::parseBlock):
3125         * dfg/DFGClobberize.h:
3126         (JSC::DFG::clobberize):
3127         * dfg/DFGDoesGC.cpp:
3128         (JSC::DFG::doesGC):
3129         * dfg/DFGFixupPhase.cpp:
3130         (JSC::DFG::FixupPhase::fixupNode):
3131         * dfg/DFGHeapLocation.cpp:
3132         (WTF::printInternal):
3133         * dfg/DFGHeapLocation.h:
3134         * dfg/DFGNode.h:
3135         (JSC::DFG::Node::hasCellOperand):
3136         * dfg/DFGNodeType.h:
3137         * dfg/DFGPredictionPropagationPhase.cpp:
3138         (JSC::DFG::PredictionPropagationPhase::propagate):
3139         * dfg/DFGSafeToExecute.h:
3140         (JSC::DFG::safeToExecute):
3141         * dfg/DFGSpeculativeJIT32_64.cpp:
3142         (JSC::DFG::SpeculativeJIT::compile):
3143         * dfg/DFGSpeculativeJIT64.cpp:
3144         (JSC::DFG::SpeculativeJIT::compile):
3145         * dfg/DFGWatchpointCollectionPhase.cpp:
3146         (JSC::DFG::WatchpointCollectionPhase::handle):
3147         * ftl/FTLCapabilities.cpp:
3148         (JSC::FTL::canCompile):
3149         * ftl/FTLLowerDFGToLLVM.cpp:
3150         (JSC::FTL::LowerDFGToLLVM::compileNode):
3151         * runtime/JSFunction.h:
3152         (JSC::JSFunction::rareData):
3153         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
3154
3155 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
3156
3157         MovHint should be a strong use
3158         https://bugs.webkit.org/show_bug.cgi?id=143734
3159
3160         Reviewed by Geoffrey Garen.
3161         
3162         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
3163         so is a major step towards allowing more fancy DFG transformations and also probably fixing
3164         some bugs.
3165         
3166         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
3167         introducing a MovHint removal phase that runs in FTL.
3168         
3169         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
3170
3171         * CMakeLists.txt:
3172         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3173         * JavaScriptCore.xcodeproj/project.pbxproj:
3174         * bytecode/CodeOrigin.cpp:
3175         (JSC::InlineCallFrame::dumpInContext):
3176         * dfg/DFGDCEPhase.cpp:
3177         (JSC::DFG::DCEPhase::fixupBlock):
3178         * dfg/DFGDisassembler.cpp:
3179         (JSC::DFG::Disassembler::createDumpList):
3180         * dfg/DFGEpoch.cpp: Added.
3181         (JSC::DFG::Epoch::dump):
3182         * dfg/DFGEpoch.h: Added.
3183         (JSC::DFG::Epoch::Epoch):
3184         (JSC::DFG::Epoch::first):
3185         (JSC::DFG::Epoch::operator!):
3186         (JSC::DFG::Epoch::next):
3187         (JSC::DFG::Epoch::bump):
3188         (JSC::DFG::Epoch::operator==):
3189         (JSC::DFG::Epoch::operator!=):
3190         * dfg/DFGMayExit.cpp:
3191         (JSC::DFG::mayExit):
3192         * dfg/DFGMovHintRemovalPhase.cpp: Added.
3193         (JSC::DFG::performMovHintRemoval):
3194         * dfg/DFGMovHintRemovalPhase.h: Added.
3195         * dfg/DFGNodeType.h:
3196         * dfg/DFGPlan.cpp:
3197         (JSC::DFG::Plan::compileInThreadImpl):
3198         * dfg/DFGSpeculativeJIT.cpp:
3199         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3200         * dfg/DFGSpeculativeJIT64.cpp:
3201         (JSC::DFG::SpeculativeJIT::compile):
3202         * runtime/Options.h:
3203
3204 2015-04-21  Basile Clement  <basile_clement@apple.com>
3205
3206         REGRESSION (r182899): icloud.com crashes
3207         https://bugs.webkit.org/show_bug.cgi?id=143960
3208
3209         Reviewed by Filip Pizlo.
3210
3211         * runtime/JSFunction.h:
3212         (JSC::JSFunction::allocationStructure):
3213         * tests/stress/dfg-rare-data.js: Added.
3214         (F): Regression test
3215
3216 2015-04-21  Michael Saboff  <msaboff@apple.com>
3217
3218         Crash in JSC::Interpreter::execute
3219         https://bugs.webkit.org/show_bug.cgi?id=142625
3220
3221         Reviewed by Filip Pizlo.
3222
3223         We need to keep the FunctionExecutables in the code block for the eval flavor of 
3224         Interpreter::execute() in order to create the scope used to eval.
3225
3226         * bytecode/CodeBlock.cpp:
3227         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
3228         * bytecode/CodeBlock.h:
3229         * dfg/DFGGraph.cpp:
3230         (JSC::DFG::Graph::registerFrozenValues):
3231
3232 2015-04-21  Chris Dumez  <cdumez@apple.com>
3233
3234         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
3235         https://bugs.webkit.org/show_bug.cgi?id=143970
3236
3237         Reviewed by Darin Adler.
3238
3239         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
3240         constructor explicit as it copies the vector and it is easy to call it
3241         by mistake.
3242
3243         * bytecode/UnlinkedInstructionStream.cpp:
3244         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
3245         * bytecode/UnlinkedInstructionStream.h:
3246         * ftl/FTLLowerDFGToLLVM.cpp:
3247         (JSC::FTL::LowerDFGToLLVM::lower):
3248
3249 2015-04-20  Basile Clement  <basile_clement@apple.com>
3250
3251         PhantomNewObject should be marked NodeMustGenerate
3252         https://bugs.webkit.org/show_bug.cgi?id=143974
3253
3254         Reviewed by Filip Pizlo.
3255
3256         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
3257
3258 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3259
3260         Cleanup some StringBuilder use
3261         https://bugs.webkit.org/show_bug.cgi?id=143550
3262
3263         Reviewed by Darin Adler.
3264
3265         * runtime/Symbol.cpp:
3266         (JSC::Symbol::descriptiveString):
3267         * runtime/TypeProfiler.cpp:
3268         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
3269         * runtime/TypeSet.cpp:
3270         (JSC::TypeSet::toJSONString):
3271         (JSC::StructureShape::propertyHash):
3272         (JSC::StructureShape::stringRepresentation):
3273         (JSC::StructureShape::toJSONString):
3274
3275 2015-04-20  Mark Lam  <mark.lam@apple.com>
3276
3277         Add debugging tools to test if a given pointer is a valid object and in the heap.
3278         https://bugs.webkit.org/show_bug.cgi?id=143910
3279
3280         Reviewed by Geoffrey Garen.
3281
3282         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
3283         purported JSObject is really a valid object in the heap or not.  We can add the
3284         following utility functions to help:
3285             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
3286             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
3287             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
3288             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
3289
3290         Also moved lldb callable debug utility function prototypes from
3291         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
3292         JSDollarVMPrototype class.  This is so that we can conveniently #include that
3293         file to get the prototypes when we need to call them programmatically from
3294         instrumentation that we add while debugging an issue.
3295
3296         * heap/Heap.h:
3297         (JSC::Heap::storageSpace):
3298         * tools/JSDollarVMPrototype.cpp:
3299         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
3300         (JSC::ensureCurrentThreadOwnsJSLock):
3301         (JSC::JSDollarVMPrototype::gc):
3302         (JSC::functionGC):
3303         (JSC::JSDollarVMPrototype::edenGC):
3304         (JSC::functionEdenGC):
3305         (JSC::JSDollarVMPrototype::isInHeap):
3306         (JSC::JSDollarVMPrototype::isInObjectSpace):
3307         (JSC::JSDollarVMPrototype::isInStorageSpace):
3308         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
3309         (JSC::ObjectAddressCheckFunctor::operator()):
3310         (JSC::JSDollarVMPrototype::isValidCell):
3311         (JSC::JSDollarVMPrototype::isValidCodeBlock):
3312         (JSC::JSDollarVMPrototype::codeBlockForFrame):
3313         (JSC::functionCodeBlockForFrame):
3314         (JSC::codeBlockFromArg):
3315         (JSC::JSDollarVMPrototype::printCallFrame):
3316         (JSC::JSDollarVMPrototype::printStack):
3317         (JSC::JSDollarVMPrototype::printValue):
3318         (JSC::currentThreadOwnsJSLock): Deleted.
3319         (JSC::gc): Deleted.
3320         (JSC::edenGC): Deleted.
3321         (JSC::isValidCodeBlock): Deleted.
3322         (JSC::codeBlockForFrame): Deleted.
3323         (JSC::printCallFrame): Deleted.
3324         (JSC::printStack): Deleted.
3325         (JSC::printValue): Deleted.
3326         * tools/JSDollarVMPrototype.h:
3327
3328 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3329
3330         Web Inspector: Improve Support for WeakSet in Console
3331         https://bugs.webkit.org/show_bug.cgi?id=143951
3332
3333         Reviewed by Darin Adler.
3334
3335         * inspector/InjectedScriptSource.js:
3336         * inspector/JSInjectedScriptHost.cpp:
3337         (Inspector::JSInjectedScriptHost::subtype):
3338         (Inspector::JSInjectedScriptHost::weakSetSize):
3339         (Inspector::JSInjectedScriptHost::weakSetEntries):
3340         * inspector/JSInjectedScriptHost.h:
3341         * inspector/JSInjectedScriptHostPrototype.cpp:
3342         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3343         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
3344         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
3345         Treat WeakSets like special sets.
3346
3347         * inspector/protocol/Runtime.json:
3348         Add a new object subtype, "weakset".
3349
3350 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
3351
3352         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
3353         https://bugs.webkit.org/show_bug.cgi?id=143947
3354
3355         Reviewed by Darin Adler.
3356
3357         Type profiler has map between PropertyKey (StringImpl*) and offset.
3358         StringImpl* is also used for Symbol PropertyKey.
3359         So equality of hash tables is considered by interned StringImpl*'s pointer value.
3360         To do so, use IdentifierRepHash instead of StringHash.
3361
3362         * runtime/SymbolTable.h:
3363
3364 2015-04-20  Jordan Harband  <ljharb@gmail.com>
3365
3366         Implement `Object.is`
3367         https://bugs.webkit.org/show_bug.cgi?id=143865
3368
3369         Reviewed by Darin Adler.
3370
3371         Expose sameValue to JS, via Object.is
3372         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
3373
3374         * runtime/ObjectConstructor.cpp:
3375         (JSC::objectConstructorIs):
3376         * runtime/PropertyDescriptor.cpp:
3377         (JSC::sameValue):
3378
3379 2015-04-19  Darin Adler  <darin@apple.com>
3380
3381         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
3382         https://bugs.webkit.org/show_bug.cgi?id=143941
3383
3384         Reviewed by Gyuyoung Kim.
3385
3386         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
3387         * API/JSCallbackObjectFunctions.h: Ditto.
3388
3389         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
3390         create function and the constructor and for m_impl.
3391         * API/ObjCCallbackFunction.mm:
3392         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
3393         class by using RetainPtr<Class>.
3394         (ArgumentTypeDelegate::typeInteger): Use make_unique.
3395         (ArgumentTypeDelegate::typeDouble): Ditto.
3396         (ArgumentTypeDelegate::typeBool): Ditto.
3397         (ArgumentTypeDelegate::typeVoid): Ditto.
3398         (ArgumentTypeDelegate::typeId): Ditto.
3399         (ArgumentTypeDelegate::typeOfClass): Ditto.
3400         (ArgumentTypeDelegate::typeBlock): Ditto.
3401         (ArgumentTypeDelegate::typeStruct): Ditto.
3402         (ResultTypeDelegate::typeInteger): Ditto.
3403         (ResultTypeDelegate::typeDouble): Ditto.
3404         (ResultTypeDelegate::typeBool): Ditto.
3405         (ResultTypeDelegate::typeVoid): Ditto.
3406         (ResultTypeDelegate::typeId): Ditto.
3407         (ResultTypeDelegate::typeOfClass): Ditto.
3408         (ResultTypeDelegate::typeBlock): Ditto.
3409         (ResultTypeDelegate::typeStruct): Ditto.
3410         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
3411         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
3412         Use RetainPtr<Class> for m_instanceClass.
3413         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
3414         for non-Objective-C object pointer null.
3415         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
3416         the arguments to the constructor and for m_impl.
3417         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
3418         (skipNumber): Mark this static since it's local to this source file.
3419         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
3420         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
3421         nullptr instead of nil for JSObjectRef values.
3422         (objCCallbackFunctionForMethod): Tweaked comment.
3423         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
3424
3425         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
3426
3427         * heap/GCThread.cpp:
3428         (JSC::GCThread::GCThread): Use unique_ptr.
3429         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
3430         m_slotVisitor and m_copyVisitor.
3431         * heap/GCThreadSharedData.cpp:
3432         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
3433
3434         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
3435
3436 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
3437
3438         Improve the feature.json files
3439
3440         * features.json:
3441
3442 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3443
3444         Introduce bytecode intrinsics
3445         https://bugs.webkit.org/show_bug.cgi?id=143926
3446
3447         Reviewed by Filip Pizlo.
3448
3449         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
3450         When implementing functions in builtins/*.js,
3451         sometimes we require lower level functionality.
3452
3453         For example, in the current Array.from, we use `result[k] = value`.
3454         The spec requires `[[DefineOwnProperty]]` operation here.
3455         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
3456         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
3457
3458         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
3459         However, there's no syntax to generate it directly.
3460
3461         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
3462         Like @call, @apply, we introduce a new node, Intrinsic.
3463         These are generated when calling appropriate private symbols in privileged code.
3464         AST parser detects them and generates Intrinsic nodes and
3465         BytecodeCompiler detects them and generate required bytecodes.
3466
3467         Currently, Array.from implementation works fine without this patch.
3468         This is because when the target code is builtin JS,
3469         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
3470         This solves the above issue. However, instead of solving this issue,
3471         it raises another issue; There's no way to emit `[[Set]]` operation.
3472         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
3473         So to implement it precisely, introducing bytecode level intrinsics is necessary.
3474
3475         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
3476         for `result[k] = value` under builtin JS environment. Instead of that special handling,
3477         use bytecode intrinsics instead. It solves problems and it is more intuitive
3478         because written JS code in builtin works as the same to the usual JS code.
3479
3480         * CMakeLists.txt:
3481         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3482         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3483         * JavaScriptCore.xcodeproj/project.pbxproj:
3484         * builtins/ArrayConstructor.js:
3485         (from):
3486         * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
3487         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3488         (JSC::BytecodeIntrinsicRegistry::lookup):
3489         * bytecode/BytecodeIntrinsicRegistry.h: Added.
3490         * bytecompiler/NodesCodegen.cpp:
3491         (JSC::BytecodeIntrinsicNode::emitBytecode):
3492         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
3493         * parser/ASTBuilder.h:
3494         (JSC::ASTBuilder::makeFunctionCallNode):
3495         * parser/NodeConstructors.h:
3496         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
3497         * parser/Nodes.h:
3498         (JSC::BytecodeIntrinsicNode::identifier):
3499         * runtime/CommonIdentifiers.cpp:
3500         (JSC::CommonIdentifiers::CommonIdentifiers):
3501         * runtime/CommonIdentifiers.h:
3502         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
3503         * tests/stress/array-from-with-accessors.js: Added.
3504         (shouldBe):
3505
3506 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3507
3508         Make Builtin functions non constructible
3509         https://bugs.webkit.org/show_bug.cgi?id=143923
3510
3511         Reviewed by Darin Adler.
3512
3513         Builtin functions defined by builtins/*.js accidentally have [[Construct]].
3514         According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
3515         This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
3516
3517         Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
3518         However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
3519         In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
3520         So in this patch, we check `isBuiltinFunction()` in those places.
3521
3522         * dfg/DFGByteCodeParser.cpp:
3523         (JSC::DFG::ByteCodeParser::inliningCost):
3524         * jit/JITOperations.cpp:
3525         * llint/LLIntSlowPaths.cpp:
3526         (JSC::LLInt::setUpCall):
3527         * runtime/JSFunction.cpp:
3528         (JSC::JSFunction::getConstructData):
3529         * tests/stress/builtin-function-is-construct-type-none.js: Added.
3530         (shouldThrow):
3531
3532 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3533
3534         [ES6] Implement WeakSet
3535         https://bugs.webkit.org/show_bug.cgi?id=142408
3536
3537         Reviewed by Darin Adler.
3538
3539         This patch implements ES6 WeakSet.
3540         Current implementation simply leverages WeakMapData with undefined value.
3541         This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
3542
3543         And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
3544         Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
3545         methods return false (or undefined for WeakMap.prototype.get)
3546         when a key is not Object instead of throwing a type error.
3547
3548         [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
3549
3550         * CMakeLists.txt:
3551         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3552         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3553         * JavaScriptCore.xcodeproj/project.pbxproj:
3554         * runtime/CommonIdentifiers.h:
3555         * runtime/JSGlobalObject.cpp:
3556         * runtime/JSGlobalObject.h:
3557         * runtime/JSWeakSet.cpp: Added.
3558         (JSC::JSWeakSet::finishCreation):
3559         (JSC::JSWeakSet::visitChildren):
3560         * runtime/JSWeakSet.h: Added.
3561         (JSC::JSWeakSet::createStructure):
3562         (JSC::JSWeakSet::create):
3563         (JSC::JSWeakSet::weakMapData):
3564         (JSC::JSWeakSet::JSWeakSet):
3565         * runtime/WeakMapPrototype.cpp:
3566         (JSC::getWeakMapData):
3567         (JSC::protoFuncWeakMapDelete):
3568         (JSC::protoFuncWeakMapGet):
3569         (JSC::protoFuncWeakMapHas):
3570         * runtime/WeakSetConstructor.cpp: Added.
3571         (JSC::WeakSetConstructor::finishCreation):
3572         (JSC::callWeakSet):
3573         (JSC::constructWeakSet):
3574         (JSC::WeakSetConstructor::getConstructData):
3575         (JSC::WeakSetConstructor::getCallData):
3576         * runtime/WeakSetConstructor.h: Added.
3577         (JSC::WeakSetConstructor::create):
3578         (JSC::WeakSetConstructor::createStructure):
3579         (JSC::WeakSetConstructor::WeakSetConstructor):
3580         * runtime/WeakSetPrototype.cpp: Added.
3581         (JSC::WeakSetPrototype::finishCreation):
3582         (JSC::getWeakMapData):
3583         (JSC::protoFuncWeakSetDelete):
3584         (JSC::protoFuncWeakSetHas):
3585         (JSC::protoFuncWeakSetAdd):
3586         * runtime/WeakSetPrototype.h: Added.
3587         (JSC::WeakSetPrototype::create):
3588         (JSC::WeakSetPrototype::createStructure):
3589         (JSC::WeakSetPrototype::WeakSetPrototype):
3590         * tests/stress/weak-set-constructor-adder.js: Added.
3591         (WeakSet.prototype.add):
3592         * tests/stress/weak-set-constructor.js: Added.
3593
3594 2015-04-17  Alexey Proskuryakov  <ap@apple.com>
3595
3596         Remove unused BoundsCheckedPointer
3597         https://bugs.webkit.org/show_bug.cgi?id=143896
3598
3599         Reviewed by Geoffrey Garen.
3600
3601         * bytecode/SpeculatedType.cpp: The header was included here.
3602
3603 2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3604
3605         [ES6] Fix name enumeration of static functions for Symbol constructor
3606         https://bugs.webkit.org/show_bug.cgi?id=143891
3607
3608         Reviewed by Geoffrey Garen.
3609
3610         Fix missing symbolPrototypeTable registration to the js class object.
3611         This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
3612
3613         * runtime/SymbolConstructor.cpp:
3614
3615 2015-04-17  Basile Clement  <basile_clement@apple.com>
3616
3617         Inline JSFunction allocation in DFG
3618         https://bugs.webkit.org/show_bug.cgi?id=143858
3619
3620         Reviewed by Filip Pizlo.
3621
3622         Followup to my previous patch which inlines JSFunction allocation when
3623         using FTL, now also enabled in DFG.
3624
3625         * dfg/DFGSpeculativeJIT.cpp:
3626         (JSC::DFG::SpeculativeJIT::compileNewFunction):
3627
3628 2015-04-16  Jordan Harband  <ljharb@gmail.com>
3629
3630         Number.parseInt is not === global parseInt in nightly r182673
3631         https://bugs.webkit.org/show_bug.cgi?id=143799
3632
3633         Reviewed by Darin Adler.
3634
3635         Ensuring parseInt === Number.parseInt, per spec
3636         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
3637
3638         * runtime/CommonIdentifiers.h:
3639         * runtime/JSGlobalObject.cpp:
3640         (JSC::JSGlobalObject::init):
3641         * runtime/JSGlobalObject.h:
3642         (JSC::JSGlobalObject::parseIntFunction):
3643         * runtime/NumberConstructor.cpp:
3644         (JSC::NumberConstructor::finishCreation):
3645
3646 2015-04-16  Mark Lam  <mark.lam@apple.com>
3647
3648         Gardening: fix CLOOP build after r182927.
3649
3650         Not reviewed.
3651
3652         * interpreter/StackVisitor.cpp:
3653         (JSC::StackVisitor::Frame::print):
3654
3655 2015-04-16  Basile Clement  <basile_clement@apple.com>
3656
3657         Inline JSFunction allocation in FTL
3658         https://bugs.webkit.org/show_bug.cgi?id=143851
3659
3660         Reviewed by Filip Pizlo.
3661
3662         JSFunction allocation is a simple operation that should be inlined when possible.
3663
3664         * ftl/FTLAbstractHeapRepository.h:
3665         * ftl/FTLLowerDFGToLLVM.cpp:
3666         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
3667         * runtime/JSFunction.h:
3668         (JSC::JSFunction::allocationSize):
3669
3670 2015-04-16  Mark Lam  <mark.lam@apple.com>
3671
3672         Add $vm debugging tool.
3673         https://bugs.webkit.org/show_bug.cgi?id=143809
3674
3675         Reviewed by Geoffrey Garen.
3676
3677         For debugging VM bugs, it would be useful to be able to dump VM data structures
3678         from JS code that we instrument.  To this end, let's introduce a
3679         JS_enableDollarVM option that, if true, installs an $vm property into each JS
3680         global object at creation time.  The $vm property refers to an object that
3681         provides a collection of useful utility functions.  For this initial
3682         implementation, $vm will have the following:
3683
3684             crash() - trigger an intentional crash.
3685
3686             dfgTrue() - returns true if the current function is DFG compiled, else returns false.
3687             jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
3688             llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
3689
3690             gc() - runs a full GC.
3691             edenGC() - runs an eden GC.
3692
3693             codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
3694             printSourceFor(codeBlock) - prints the source code for the codeBlock.
3695             printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
3696
3697             print(str) - prints a string to dataLog output.
3698             printCallFrame() - prints the current CallFrame.
3699             printStack() - prints the JS stack.
3700             printInternal(value) - prints the JSC internal info for the specified value.
3701
3702         With JS_enableDollarVM=true, JS code can use the above functions like so:
3703
3704             $vm.print("Using $vm features\n");
3705
3706         * CMakeLists.txt:
3707         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3708         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3709         * JavaScriptCore.xcodeproj/project.pbxproj:
3710         * bytecode/CodeBlock.cpp:
3711         (JSC::CodeBlock::printCallOp):
3712         - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
3713           Hence, we skip this step if we're dumping an FTL codeBlock.
3714
3715         * heap/Heap.cpp:
3716         (JSC::Heap::collectAndSweep):
3717         (JSC::Heap::collectAllGarbage): Deleted.
3718         * heap/Heap.h:
3719         (JSC::Heap::collectAllGarbage):
3720         - Add ability to do an Eden collection and sweep.
3721
3722         * interpreter/StackVisitor.cpp:
3723         (JSC::printIndents):
3724         (JSC::log):
3725         (JSC::logF):
3726         (JSC::StackVisitor::Frame::print):
3727         (JSC::jitTypeName): Deleted.
3728         (JSC::printif): Deleted.
3729         - Modernize the implementation of StackVisitor::Frame::print(), and remove some
3730           now redundant code.
3731         - Also fix it so that it downgrades gracefully when encountering inlined DFG
3732           and compiled FTL functions.
3733
3734         (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
3735         (DebugPrintFrameFunctor::operator()): Deleted.
3736         (debugPrintCallFrame): Deleted.
3737         (debugPrintStack): Deleted.
3738         - these have been moved into JSDollarVMPrototype.cpp. 
3739
3740         * interpreter/StackVisitor.h:
3741         - StackVisitor::Frame::print() is now enabled for release builds as well so that
3742           we can call it from $vm.
3743
3744         * runtime/JSGlobalObject.cpp:
3745         (JSC::JSGlobalObject::init):
3746         (JSC::JSGlobalObject::visitChildren):
3747         * runtime/JSGlobalObject.h:
3748         - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
3749           option.
3750
3751         * runtime/Options.h:
3752         - Added the JSC_enableDollarVM option.
3753
3754         * tools/JSDollarVM.cpp: Added.
3755         * tools/JSDollarVM.h: Added.
3756         (JSC::JSDollarVM::createStructure):
3757         (JSC::JSDollarVM::create):
3758         (JSC::JSDollarVM::JSDollarVM):
3759
3760         * tools/JSDollarVMPrototype.cpp: Added.
3761         - This file contains 2 sets of functions:
3762
3763           a. a C++ implementation of debugging utility functions that are callable when
3764              doing debugging from lldb.  To the extent possible, these functions try to
3765              be cautious and not cause unintended crashes should the user call them with
3766              the wrong info.  Hence, they are designed to be robust rather than speedy.
3767
3768           b. the native implementations of JS functions in the $vm object.  Where there
3769              is overlapping functionality, these are built on top of the C++ functions
3770              above to do the work.
3771
3772           Note: it does not make sense for all of the $vm functions to have a C++
3773           counterpart for lldb debugging.  For example, the $vm.dfgTrue() function is
3774           only useful for JS code, and works via the DFG intrinsics mechanism.
3775           When doing debugging via lldb, the optimization level of the currently
3776           executing JS function can be gotten by dumping the current CallFrame instead.
3777
3778         (JSC::currentThreadOwnsJSLock):
3779         (JSC::ensureCurrentThreadOwnsJSLock):
3780         (JSC::JSDollarVMPrototype::addFunction):
3781         (JSC::functionCrash): - $vm.crash()
3782         (JSC::functionDFGTrue): - $vm.dfgTrue()
3783         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
3784         (JSC::CallerFrameJITTypeFunctor::operator()):
3785         (JSC::CallerFrameJITTypeFunctor::jitType):
3786         (JSC::functionLLintTrue): - $vm.llintTrue()
3787         (JSC::functionJITTrue): - $vm.jitTrue()
3788         (JSC::gc):
3789         (JSC::functionGC): - $vm.gc()
3790         (JSC::edenGC):
3791         (JSC::functionEdenGC): - $vm.edenGC()
3792         (JSC::isValidCodeBlock):
3793         (JSC::codeBlockForFrame):
3794         (JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
3795         (JSC::codeBlockFromArg):
3796         (JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
3797         (JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
3798         (JSC::functionPrint): - $vm.print(str)
3799         (JSC::PrintFrameFunctor::PrintFrameFunctor):
3800         (JSC::PrintFrameFunctor::operator()):
3801         (JSC::printCallFrame):
3802         (JSC::printStack):
3803         (JSC::functionPrintCallFrame): - $vm.printCallFrame()
3804         (JSC::functionPrintStack): - $vm.printStack()
3805         (JSC::printValue):
3806         (JSC::functionPrintValue): - $vm.printValue()
3807         (JSC::JSDollarVMPrototype::finishCreation):
3808         * tools/JSDollarVMPrototype.h: Added.
3809         (JSC::JSDollarVMPrototype::create):
3810         (JSC::JSDollarVMPrototype::createStructure):
3811         (JSC::JSDollarVMPrototype::JSDollarVMPrototype):
3812
3813 2015-04-16  Geoffrey Garen  <ggaren@apple.com>
3814
3815         Speculative fix after r182915
3816         https://bugs.webkit.org/show_bug.cgi?id=143404
3817
3818         Reviewed by Alexey Proskuryakov.
3819
3820         * runtime/SymbolConstructor.h:
3821
3822 2015-04-16  Mark Lam  <mark.lam@apple.com>
3823
3824         Fixed some typos in a comment.
3825
3826         Not reviewed.
3827
3828         * dfg/DFGGenerationInfo.h:
3829
3830 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
3831
3832         [ES6] Implement Symbol.for and Symbol.keyFor
3833         https://bugs.webkit.org/show_bug.cgi?id=143404
3834
3835         Reviewed by Geoffrey Garen.
3836
3837         This patch implements Symbol.for and Symbol.keyFor.
3838         SymbolRegistry maintains registered StringImpl* symbols.
3839         And to make this mapping enabled over realms,
3840         VM owns this mapping (not JSGlobalObject).
3841
3842         While there's Default AtomicStringTable per thread,
3843         SymbolRegistry should not exist over VMs.
3844         So everytime VM is created, SymbolRegistry is also created.
3845
3846         In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
3847         Theres are several reasons.
3848         1. StringImpl* which represents identity of Symbols is not GC-managed object.
3849            So we cannot use WeakGCMap directly.
3850            While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
3851            because distinct Symbol* can exist.
3852            Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.
3853
3854         2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
3855            However there's problem about when we prune staled entries in SymbolRegistry.
3856            Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
3857            and it is not in GC-heap.
3858            While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
3859            So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
3860            As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.
3861
3862         So instead of using Weak reference, we take relatively easy design.
3863         When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
3864         And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.
3865
3866         * CMakeLists.txt:
3867         * DerivedSources.make:
3868         * runtime/SymbolConstructor.cpp:
3869         (JSC::SymbolConstructor::getOwnPropertySlot):
3870         (JSC::symbolConstructorFor):
3871         (JSC::symbolConstructorKeyFor):
3872         * runtime/SymbolConstructor.h: