9613758f312b1f7ae7a9c3d73605a1c12facc192
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-04-27  Jordan Harband  <ljharb@gmail.com>
2
3         Map#entries and Map#keys error for non-Maps is swapped
4         https://bugs.webkit.org/show_bug.cgi?id=144253
5
6         Reviewed by Simon Fraser.
7
8         Correcting error messages on Set/Map methods when called on
9         incompatible objects.
10
11         * runtime/MapPrototype.cpp:
12         (JSC::mapProtoFuncEntries):
13         (JSC::mapProtoFuncKeys):
14         * runtime/SetPrototype.cpp:
15         (JSC::setProtoFuncEntries):
16
17 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
18
19         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
20         https://bugs.webkit.org/show_bug.cgi?id=144186
21
22         Reviewed by Geoffrey Garen.
23         
24         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
25         Int32. We may later perform code simplifications based on the proof that this is Int32, and
26         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
27         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
28         except that we still need the overflow check!
29
30         Previously we mishandled this:
31
32         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
33           to keep it alive. That's dirty and it's just indicative of a deeper issue.
34
35         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
36           powerless. This was sort of hiding the bug.
37
38         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
39           something that you are relying on for subsequent simplifications.
40         
41         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
42         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
43         we no longer need the weird MustGenerate node.
44
45         * dfg/DFGAbstractInterpreterInlines.h:
46         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
47         * dfg/DFGArgumentsEliminationPhase.cpp:
48         * dfg/DFGClobberize.h:
49         (JSC::DFG::clobberize):
50         * dfg/DFGDCEPhase.cpp:
51         (JSC::DFG::DCEPhase::run):
52         * dfg/DFGDoesGC.cpp:
53         (JSC::DFG::doesGC):
54         * dfg/DFGFixupPhase.cpp:
55         (JSC::DFG::FixupPhase::fixupNode):
56         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
57         * dfg/DFGIntegerCheckCombiningPhase.cpp:
58         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
59         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
60         * dfg/DFGMayExit.cpp:
61         (JSC::DFG::mayExit):
62         * dfg/DFGNode.h:
63         (JSC::DFG::Node::willHaveCodeGenOrOSR):
64         * dfg/DFGNodeType.h:
65         * dfg/DFGObjectAllocationSinkingPhase.cpp:
66         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
67         * dfg/DFGPhantomCanonicalizationPhase.cpp:
68         (JSC::DFG::PhantomCanonicalizationPhase::run):
69         * dfg/DFGPhantomRemovalPhase.cpp:
70         (JSC::DFG::PhantomRemovalPhase::run):
71         * dfg/DFGPlan.cpp:
72         (JSC::DFG::Plan::compileInThreadImpl):
73         * dfg/DFGPredictionPropagationPhase.cpp:
74         (JSC::DFG::PredictionPropagationPhase::propagate):
75         * dfg/DFGSafeToExecute.h:
76         (JSC::DFG::safeToExecute):
77         * dfg/DFGSpeculativeJIT32_64.cpp:
78         (JSC::DFG::SpeculativeJIT::compile):
79         * dfg/DFGSpeculativeJIT64.cpp:
80         (JSC::DFG::SpeculativeJIT::compile):
81         * dfg/DFGTypeCheckHoistingPhase.cpp:
82         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
83         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
84         * dfg/DFGVarargsForwardingPhase.cpp:
85         * ftl/FTLCapabilities.cpp:
86         (JSC::FTL::canCompile):
87         * ftl/FTLLowerDFGToLLVM.cpp:
88         (JSC::FTL::LowerDFGToLLVM::compileNode):
89         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
90         (foo):
91         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
92         (foo):
93         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
94         (foo):
95         * tests/stress/fold-based-on-int32-proof.js: Added.
96         (foo):
97
98 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
99
100         Class body ending with a semicolon throws a SyntaxError
101         https://bugs.webkit.org/show_bug.cgi?id=144244
102
103         Reviewed by Darin Adler.
104
105         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
106         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
107         it by continue'ing when it encounters a semicolon.
108
109         * parser/Parser.cpp:
110         (JSC::Parser<LexerType>::parseClass):
111
112 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
113
114         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
115         https://bugs.webkit.org/show_bug.cgi?id=144243
116
117         Reviewed by Darin Adler.
118
119         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
120
121         * parser/Parser.cpp:
122         (JSC::Parser<LexerType>::parseGetterSetter):
123
124 2015-04-26  Jordan Harband  <ljharb@gmail.com>
125
126         Map#forEach does not pass "map" argument to callback.
127         https://bugs.webkit.org/show_bug.cgi?id=144187
128
129         Reviewed by Darin Adler.
130
131         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
132         step 7.a.i., the callback should be called with three arguments.
133
134         * runtime/MapPrototype.cpp:
135         (JSC::mapProtoFuncForEach):
136
137 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
138
139         [ES6] Implement ES6 template literals
140         https://bugs.webkit.org/show_bug.cgi?id=142691
141
142         Reviewed by Darin Adler.
143
144         This patch implements TemplateLiteral.
145         Since TaggedTemplate requires some global states and
146         primitive operations like GetTemplateObject,
147         we separate the patch. It will be implemented in a subsequent patch.
148
149         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
150         By disabling it, we can disable Template Literal support.
151
152         To implement template literals, in this patch,
153         we newly introduces bytecode op_to_string.
154         In template literals, we alternately evaluate the expression and
155         perform ToString onto the result of evaluation.
156         For example,
157
158         `${f1()} ${f2()}`
159
160         In this template literal, execution order is the following,
161         1. calling f1()
162         2. ToString(the result of f1())
163         3. calling f2()
164         4. ToString(the result of f2())
165
166         op_strcat also performs ToString. However, performing ToString
167         onto expressions are batched in op_strcat, it's not the same to the
168         template literal spec. In the above example,
169         ToString(f1()) should be called before calling f2().
170
171         * Configurations/FeatureDefines.xcconfig:
172         * bytecode/BytecodeList.json:
173         * bytecode/BytecodeUseDef.h:
174         (JSC::computeUsesForBytecodeOffset):
175         (JSC::computeDefsForBytecodeOffset):
176         * bytecode/CodeBlock.cpp:
177         (JSC::CodeBlock::dumpBytecode):
178         * bytecompiler/BytecodeGenerator.h:
179         (JSC::BytecodeGenerator::emitToString):
180         (JSC::BytecodeGenerator::emitToNumber): Deleted.
181         * bytecompiler/NodesCodegen.cpp:
182         (JSC::TemplateStringNode::emitBytecode):
183         (JSC::TemplateLiteralNode::emitBytecode):
184         * dfg/DFGByteCodeParser.cpp:
185         (JSC::DFG::ByteCodeParser::parseBlock):
186         * dfg/DFGCapabilities.cpp:
187         (JSC::DFG::capabilityLevel):
188         * jit/JIT.cpp:
189         (JSC::JIT::privateCompileMainPass):
190         (JSC::JIT::privateCompileSlowCases):
191         * jit/JIT.h:
192         * jit/JITOpcodes.cpp:
193         (JSC::JIT::emit_op_to_string):
194         (JSC::JIT::emitSlow_op_to_string):
195         * jit/JITOpcodes32_64.cpp:
196         (JSC::JIT::emit_op_to_string):
197         (JSC::JIT::emitSlow_op_to_string):
198         * llint/LowLevelInterpreter32_64.asm:
199         * llint/LowLevelInterpreter64.asm:
200         * parser/ASTBuilder.h:
201         (JSC::ASTBuilder::createTemplateString):
202         (JSC::ASTBuilder::createTemplateStringList):
203         (JSC::ASTBuilder::createTemplateExpressionList):
204         (JSC::ASTBuilder::createTemplateLiteral):
205         * parser/Lexer.cpp:
206         (JSC::Lexer<T>::Lexer):
207         (JSC::Lexer<T>::parseIdentifierSlowCase):
208         (JSC::Lexer<T>::parseString):
209         (JSC::LineNumberAdder::LineNumberAdder):
210         (JSC::LineNumberAdder::clear):
211         (JSC::LineNumberAdder::add):
212         (JSC::Lexer<T>::parseTemplateLiteral):
213         (JSC::Lexer<T>::lex):
214         (JSC::Lexer<T>::scanRegExp):
215         (JSC::Lexer<T>::scanTrailingTemplateString):
216         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
217         * parser/Lexer.h:
218         * parser/NodeConstructors.h:
219         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
220         (JSC::TemplateStringNode::TemplateStringNode):
221         (JSC::TemplateStringListNode::TemplateStringListNode):
222         (JSC::TemplateLiteralNode::TemplateLiteralNode):
223         * parser/Nodes.h:
224         (JSC::TemplateExpressionListNode::value):
225         (JSC::TemplateExpressionListNode::next):
226         (JSC::TemplateStringNode::cooked):
227         (JSC::TemplateStringNode::raw):
228         (JSC::TemplateStringListNode::value):
229         (JSC::TemplateStringListNode::next):
230         * parser/Parser.cpp:
231         (JSC::Parser<LexerType>::parseTemplateString):
232         (JSC::Parser<LexerType>::parseTemplateLiteral):
233         (JSC::Parser<LexerType>::parsePrimaryExpression):
234         * parser/Parser.h:
235         * parser/ParserTokens.h:
236         * parser/SyntaxChecker.h:
237         (JSC::SyntaxChecker::createTemplateString):
238         (JSC::SyntaxChecker::createTemplateStringList):
239         (JSC::SyntaxChecker::createTemplateExpressionList):
240         (JSC::SyntaxChecker::createTemplateLiteral):
241         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
242         * runtime/CommonSlowPaths.cpp:
243         (JSC::SLOW_PATH_DECL):
244         * runtime/CommonSlowPaths.h:
245         * tests/stress/template-literal-line-terminators.js: Added.
246         (test):
247         (testEval):
248         (testEvalLineNumber):
249         * tests/stress/template-literal-syntax.js: Added.
250         (testSyntax):
251         (testSyntaxError):
252         * tests/stress/template-literal.js: Added.
253         (test):
254         (testEval):
255         (testEmbedded):
256
257 2015-04-26  Jordan Harband  <ljharb@gmail.com>
258
259         Set#forEach does not pass "key" or "set" arguments to callback.
260         https://bugs.webkit.org/show_bug.cgi?id=144188
261
262         Reviewed by Darin Adler.
263
264         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
265         Set#forEach should pass 3 arguments to the callback.
266
267         * runtime/SetPrototype.cpp:
268         (JSC::setProtoFuncForEach):
269
270 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
271
272         [JSC] Implement Math.clz32(), remove Number.clz()
273         https://bugs.webkit.org/show_bug.cgi?id=144205
274
275         Reviewed by Michael Saboff.
276
277         This patch adds the ES6 function Math.clz32(), and remove the non-standard
278         Number.clz(). Number.clz() probably came from an older draft.
279
280         The new function has a corresponding instrinsic: Clz32Intrinsic,
281         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
282
283         * assembler/MacroAssemblerX86Common.h:
284         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
285         * assembler/X86Assembler.h:
286         (JSC::X86Assembler::bsr_rr):
287         The x86 assembler did not have countLeadingZeros32() because there is
288         no native CLZ instruction on that architecture.
289
290         I have added the version with bsr + branches for the case of zero.
291         An other popular version uses cmov to handle the case of zero. I kept
292         it simple since the Assembler has no support for cmov.
293
294         It is unlikely to matter much. If the code is hot enough, LLVM picks
295         something good based on the surrounding code.
296
297         * dfg/DFGAbstractInterpreterInlines.h:
298         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
299         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
300
301         * dfg/DFGBackwardsPropagationPhase.cpp:
302         (JSC::DFG::BackwardsPropagationPhase::propagate):
303         Thanks to the definition of toUint32(), we can ignore plenty of details
304         from doubles.
305
306         * dfg/DFGByteCodeParser.cpp:
307         (JSC::DFG::ByteCodeParser::handleIntrinsic):
308         * dfg/DFGClobberize.h:
309         (JSC::DFG::clobberize):
310         * dfg/DFGDoesGC.cpp:
311         (JSC::DFG::doesGC):
312         * dfg/DFGFixupPhase.cpp:
313         (JSC::DFG::FixupPhase::fixupNode):
314         * dfg/DFGNodeType.h:
315         * dfg/DFGPredictionPropagationPhase.cpp:
316         (JSC::DFG::PredictionPropagationPhase::propagate):
317         * dfg/DFGSafeToExecute.h:
318         (JSC::DFG::safeToExecute):
319         * dfg/DFGSpeculativeJIT.cpp:
320         (JSC::DFG::SpeculativeJIT::compileArithClz32):
321         * dfg/DFGSpeculativeJIT.h:
322         * dfg/DFGSpeculativeJIT32_64.cpp:
323         (JSC::DFG::SpeculativeJIT::compile):
324         * dfg/DFGSpeculativeJIT64.cpp:
325         (JSC::DFG::SpeculativeJIT::compile):
326         * ftl/FTLCapabilities.cpp:
327         (JSC::FTL::canCompile):
328         * ftl/FTLIntrinsicRepository.h:
329         * ftl/FTLLowerDFGToLLVM.cpp:
330         (JSC::FTL::LowerDFGToLLVM::compileNode):
331         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
332         * ftl/FTLOutput.h:
333         (JSC::FTL::Output::ctlz32):
334         * jit/ThunkGenerators.cpp:
335         (JSC::clz32ThunkGenerator):
336         * jit/ThunkGenerators.h:
337         * runtime/Intrinsic.h:
338         * runtime/MathCommon.h:
339         (JSC::clz32):
340         Fun fact: InstCombine does not recognize this pattern to eliminate
341         the branch which makes our FTL version better than the C version.
342
343         * runtime/MathObject.cpp:
344         (JSC::MathObject::finishCreation):
345         (JSC::mathProtoFuncClz32):
346         * runtime/NumberPrototype.cpp:
347         (JSC::clz): Deleted.
348         (JSC::numberProtoFuncClz): Deleted.
349         * runtime/VM.cpp:
350         (JSC::thunkGeneratorForIntrinsic):
351         * tests/stress/math-clz32-basics.js: Added.
352         (mathClz32OnInteger):
353         (testMathClz32OnIntegers):
354         (verifyMathClz32OnIntegerWithOtherTypes):
355         (mathClz32OnDouble):
356         (testMathClz32OnDoubles):
357         (verifyMathClz32OnDoublesWithOtherTypes):
358         (mathClz32NoArguments):
359         (mathClz32TooManyArguments):
360         (testMathClz32OnConstants):
361         (mathClz32StructTransition):
362         (Math.clz32):
363
364 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
365
366         [ES6] Array.from need to accept iterables
367         https://bugs.webkit.org/show_bug.cgi?id=141055
368
369         Reviewed by Darin Adler.
370
371         ES6 spec requires that Array.from accepts iterable objects.
372         This patch introduces this functionality, Array.from accepting iterable objects.
373
374         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
375         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
376         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
377         This will be fixed in the subsequent patch[1].
378
379         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
380
381         * builtins/ArrayConstructor.js:
382         (from):
383         * parser/Parser.cpp:
384         (JSC::Parser<LexerType>::parseInner):
385         * runtime/CommonIdentifiers.h:
386         * runtime/JSGlobalObject.cpp:
387         (JSC::JSGlobalObject::init):
388         * tests/stress/array-from-with-iterable.js: Added.
389         (shouldBe):
390         (.set for):
391         (.set var):
392         (.get var):
393         (argumentsGenerators):
394         (.set shouldBe):
395         (.set new):
396         * tests/stress/array-from-with-iterator.js: Added.
397         (shouldBe):
398         (shouldThrow):
399         (createIterator.iterator.return):
400         (createIterator):
401         (.):
402
403 2015-04-25  Jordan Harband  <ljharb@gmail.com>
404
405         Set#keys !== Set#values
406         https://bugs.webkit.org/show_bug.cgi?id=144190
407
408         Reviewed by Darin Adler.
409
410         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
411         Set#keys should === Set#values
412
413         * runtime/SetPrototype.cpp:
414         (JSC::SetPrototype::finishCreation):
415         (JSC::setProtoFuncValues):
416         (JSC::setProtoFuncEntries):
417         (JSC::setProtoFuncKeys): Deleted.
418
419 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
420
421         Allow for pausing a JSContext when opening a Web Inspector
422         <rdar://problem/20564788>
423
424         Reviewed by Timothy Hatcher.
425
426         * inspector/remote/RemoteInspector.mm:
427         (Inspector::RemoteInspector::receivedSetupMessage):
428         * inspector/remote/RemoteInspectorConstants.h:
429         * inspector/remote/RemoteInspectorDebuggable.h:
430         * inspector/remote/RemoteInspectorDebuggableConnection.h:
431         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
432         (Inspector::RemoteInspectorDebuggableConnection::setup):
433         On any incoming setup message, we may want to automatically
434         pause the debuggable. If requested, pause the debuggable
435         after we have setup the frontend connection.
436
437         * runtime/JSGlobalObjectDebuggable.h:
438         * runtime/JSGlobalObjectDebuggable.cpp:
439         (JSC::JSGlobalObjectDebuggable::pause):
440         Pass through to the inspector controller.
441
442         * inspector/JSGlobalObjectInspectorController.h:
443         * inspector/JSGlobalObjectInspectorController.cpp:
444         (Inspector::JSGlobalObjectInspectorController::pause):
445         Enable pause on next statement.
446
447 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
448
449         class methods should be non-enumerable
450         https://bugs.webkit.org/show_bug.cgi?id=143181
451
452         Reviewed by Darin Adler.
453
454         Fixed the bug by using Object.defineProperty to define methods.
455
456         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
457         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
458
459         * bytecode/CodeBlock.cpp: 
460         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
461         index of zero.
462         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
463         exactly one entry for Object.defineProperty.
464         * bytecode/UnlinkedCodeBlock.h:
465         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
466         constant register for the link time constant we're adding.
467         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
468         * bytecompiler/BytecodeGenerator.cpp:
469         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
470         register for the specified link time constant and notify UnlinkedCodeBlock about it.
471         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
472         Object.defineProperty with it.
473         * bytecompiler/BytecodeGenerator.h:
474         * bytecompiler/NodesCodegen.cpp:
475         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
476         non-enumerable by using emitCallDefineProperty to define them.
477         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
478         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
479         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
480         * runtime/CommonIdentifiers.h:
481         * runtime/JSGlobalObject.cpp:
482         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
483         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
484         * runtime/JSGlobalObject.h:
485         (JSC::JSGlobalObject::definePropertyFunction): Added.
486         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
487         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
488         returns a JSCell; e.g. Object.defineProperty.
489         * runtime/ObjectConstructor.cpp:
490         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
491         * runtime/ObjectConstructor.h:
492
493 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
494
495         [ES6] Implement String.fromCodePoint
496         https://bugs.webkit.org/show_bug.cgi?id=144160
497
498         Reviewed by Darin Adler.
499
500         This patch implements String.fromCodePoint.
501         It accepts multiple code points and generates a string that consists of given code points.
502         The range [0x0000 - 0x10FFFF] is valid for code points.
503         If the given value is out of range, throw a range error.
504
505         When a 0xFFFF <= valid code point is given,
506         String.fromCodePoint generates a string that contains surrogate pairs.
507
508         * runtime/StringConstructor.cpp:
509         (JSC::stringFromCodePoint):
510         (JSC::constructWithStringConstructor):
511         * tests/stress/string-from-code-point.js: Added.
512         (shouldBe):
513         (shouldThrow):
514         (toCodePoints):
515         (passThrough):
516
517 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
518
519         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
520         https://bugs.webkit.org/show_bug.cgi?id=144182
521
522         Reviewed by Simon Fraser.
523
524         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
525
526 2015-04-25  Mark Lam  <mark.lam@apple.com>
527
528         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
529         https://bugs.webkit.org/show_bug.cgi?id=144152
530
531         Reviewed by Filip Pizlo.
532
533         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
534         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
535         OSR exits.  This was overlooked in the original code.
536
537         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
538         the Branch node, the other 3 may also trigger the same bug for other nodes.
539         To prevent this bug from manifesting with other nodes (and future ones that
540         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
541         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
542
543         Also added a test to exercise a code path that will trigger this bug with
544         the Branch node before the fix is applied.
545
546         * dfg/DFGMayExit.cpp:
547         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
548         (inlinedFunction):
549         (foo):
550
551 2015-04-24  Commit Queue  <commit-queue@webkit.org>
552
553         Unreviewed, rolling out r183288.
554         https://bugs.webkit.org/show_bug.cgi?id=144189
555
556         Made js/sort-with-side-effecting-comparisons.html time out in
557         debug builds (Requested by ap on #webkit).
558
559         Reverted changeset:
560
561         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
562         array."
563         https://bugs.webkit.org/show_bug.cgi?id=144013
564         http://trac.webkit.org/changeset/183288
565
566 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
567
568         CRASH in operationCreateDirectArgumentsDuringExit()
569         https://bugs.webkit.org/show_bug.cgi?id=143962
570
571         Reviewed by Geoffrey Garen.
572         
573         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
574         recoverable so long as they are live. Therefore, OSR exit should track liveness of
575         constants instead of assuming that they are always live.
576
577         * dfg/DFGGenerationInfo.h:
578         (JSC::DFG::GenerationInfo::noticeOSRBirth):
579         (JSC::DFG::GenerationInfo::appendBirth):
580         * dfg/DFGSpeculativeJIT.cpp:
581         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
582         * dfg/DFGVariableEvent.cpp:
583         (JSC::DFG::VariableEvent::dump):
584         * dfg/DFGVariableEvent.h:
585         (JSC::DFG::VariableEvent::birth):
586         (JSC::DFG::VariableEvent::id):
587         (JSC::DFG::VariableEvent::dataFormat):
588         * dfg/DFGVariableEventStream.cpp:
589         (JSC::DFG::VariableEventStream::reconstruct):
590         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
591         (foo):
592         (bar):
593         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
594         (foo):
595         (bar):
596
597 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
598
599         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
600         https://bugs.webkit.org/show_bug.cgi?id=144169
601
602         Reviewed by Geoffrey Garen.
603
604         * runtime/JSObject.cpp:
605         (JSC::JSObject::convertInt32ForValue):
606         DoubleArray do not store NaN, they are used for holes.
607         What happened was:
608         1) We fail to insert the NaN in the Int32 array because it is a double.
609         2) We were converting the array to DoubleArray.
610         3) We were trying to insert the value again. We would fail again because
611            DoubleArray does not store NaN.
612         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
613            to boxed values.
614
615         * tests/stress/int32array-transition-on-nan.js: Added.
616         The behavior is not really observable. This only test nothing crashes in those
617         cases.
618
619         (insertNaNWhileFilling):
620         (testInsertNaNWhileFilling):
621         (insertNaNAfterFilling):
622         (testInsertNaNAfterFilling):
623         (pushNaNWhileFilling):
624         (testPushNaNWhileFilling):
625
626 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
627
628         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
629         https://bugs.webkit.org/show_bug.cgi?id=144013
630
631         Reviewed by Mark Lam.
632
633         This patch implements Array.prototype.sort in JavaScript, removing the
634         C++ implementations. It is simpler and less error-prone to express our
635         operations in JavaScript, which provides memory safety, exception safety,
636         and recursion safety.
637
638         The performance result is mixed, but net positive in my opinion. It's
639         difficult to enumerate all the results, since we used to have so many
640         different sorting modes, and there are lots of different data patterns
641         across which you might want to measure sorting. Suffice it to say:
642
643             (*) The benchmarks we track are faster or unchanged.
644
645             (*) Sorting random input using a comparator -- which we think is
646             common -- is 3X faster.
647
648             (*) Sorting random input in a non-array object -- which jQuery does
649             -- is 4X faster.
650
651             (*) Sorting random input in a compact array of integers using a
652             trivial pattern-matchable comparator is 2X *slower*.
653
654         * builtins/Array.prototype.js:
655         (sort.min):
656         (sort.stringComparator):
657         (sort.compactSparse): Special case compaction for sparse arrays because
658         we don't want to hang when sorting new Array(BIG).
659
660         (sort.compact):
661         (sort.merge):
662         (sort.mergeSort): Use merge sort because it's a reasonably efficient
663         stable sort. We have evidence that some sites depend on stable sort,
664         even though the ES6 spec does not mandate it. (See
665         <http://trac.webkit.org/changeset/33967>.)
666
667         This is a textbook implementation of merge sort with three optimizations:
668
669             (1) Use iteration instead of recursion;
670
671             (2) Use array subscripting instead of array copying in order to
672             create logical sub-lists without creating physical sub-lists;
673
674             (3) Swap src and dst at each iteration instead of copying src into
675             dst, and only copy src into the subject array at the end if src is
676             not the subject array.
677
678         (sort.inflate):
679         (sort.comparatorSort):
680         (sort): Sort in JavaScript for the win.
681
682         * builtins/BuiltinExecutables.cpp:
683         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
684         names so we can use helper functions.
685
686         * bytecode/CodeBlock.h:
687         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
688         * bytecode/UnlinkedCodeBlock.cpp:
689         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
690         * bytecode/UnlinkedCodeBlock.h:
691         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
692         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
693         * bytecompiler/BytecodeGenerator.cpp:
694         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
695         * bytecompiler/BytecodeGenerator.h:
696         * bytecompiler/NodesCodegen.cpp:
697         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
698         on pattern matching anymore. This was mainly an optimization to avoid 
699         the overhead of calling from C++ to JS, which we now avoid by
700         sorting in JS.
701
702         * heap/Heap.cpp:
703         (JSC::Heap::markRoots):
704         (JSC::Heap::pushTempSortVector): Deleted.
705         (JSC::Heap::popTempSortVector): Deleted.
706         (JSC::Heap::visitTempSortVectors): Deleted.
707         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
708         in JavaScript using a normal JavaScript array for our temporary storage.
709
710         * parser/Parser.cpp:
711         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
712         helper functions.
713
714         * runtime/ArrayPrototype.cpp:
715         (JSC::isNumericCompareFunction): Deleted.
716         (JSC::attemptFastSort): Deleted.
717         (JSC::performSlowSort): Deleted.
718         (JSC::arrayProtoFuncSort): Deleted.
719
720         * runtime/CommonIdentifiers.h: New strings used by sort.
721
722         * runtime/JSArray.cpp:
723         (JSC::compareNumbersForQSortWithInt32): Deleted.
724         (JSC::compareNumbersForQSortWithDouble): Deleted.
725         (JSC::compareNumbersForQSort): Deleted.
726         (JSC::compareByStringPairForQSort): Deleted.
727         (JSC::JSArray::sortNumericVector): Deleted.
728         (JSC::JSArray::sortNumeric): Deleted.
729         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
730         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
731         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
732         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
733         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
734         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
735         (JSC::JSArray::sortCompactedVector): Deleted.
736         (JSC::JSArray::sort): Deleted.
737         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
738         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
739         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
740         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
741         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
742         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
743         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
744         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
745         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
746         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
747         (JSC::JSArray::sortVector): Deleted.
748         (JSC::JSArray::compactForSorting): Deleted.
749         * runtime/JSArray.h:
750
751         * runtime/JSGlobalObject.cpp:
752         (JSC::JSGlobalObject::init):
753         * runtime/ObjectConstructor.cpp:
754         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
755         by sort.
756
757 2015-04-24  Matthew Mirman  <mmirman@apple.com>
758
759         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
760         https://bugs.webkit.org/show_bug.cgi?id=141865
761         rdar://problem/19927273
762
763         Reviewed by Filip Pizlo.
764
765         * runtime/JSGlobalObjectFunctions.cpp:
766         (JSC::globalFuncProtoGetter):
767         (JSC::globalFuncProtoSetter):
768
769 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
770
771         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
772         https://bugs.webkit.org/show_bug.cgi?id=144118
773
774         Reviewed by Geoffrey Garen.
775
776         * dfg/DFGGraph.h:
777         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
778         Both block do the same thing.
779
780 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
781
782         Web Inspector: Speculative fix for non-main thread auto-attach failures
783         https://bugs.webkit.org/show_bug.cgi?id=144134
784
785         Reviewed by Timothy Hatcher.
786
787         * inspector/remote/RemoteInspector.mm:
788         (Inspector::RemoteInspector::singleton):
789
790 2015-04-23  Basile Clement  <basile_clement@apple.com>
791
792         Allow function allocation sinking
793         https://bugs.webkit.org/show_bug.cgi?id=144016
794
795         Reviewed by Filip Pizlo.
796
797         This adds the ability to sink function allocations in the
798         DFGObjectAllocationSinkingPhase.
799
800         In order to enable this, we add a new PhantomNewFunction node that is
801         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
802         a sunk NewFunction and keep track of the allocations that have to be performed
803         in case of OSR exit after the sunk allocation but before the real one.
804         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
805         are stored onto the PhantomNewFunction through PutHints in order for them
806         to be recovered on OSR exit.
807
808         Contrary to sunk object allocations, sunk function allocations do not
809         support any kind of operations (e.g. storing into a field) ; any such operation
810         will mark the function allocation as escaping and trigger materialization. As
811         such, function allocations can only be sunk to places where it would have been
812         correct to syntactically move them, and we don't need a special
813         MaterializeNewFunction node to recover possible operations on the function. A
814         sunk NewFunction node will simply create new NewFunction nodes, then replace
815         itself with a PhantomNewFunction node.
816
817         In itself, this change is not expected to have a significant impact on
818         performances other than in degenerate cases (see e.g.
819         JSRegress/sink-function), but it is a step towards being able to sink recursive
820         closures onces we support CreateActivation sinking as well as allocation cycles
821         sinking.
822
823         * dfg/DFGAbstractInterpreterInlines.h:
824         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
825         * dfg/DFGClobberize.h:
826         (JSC::DFG::clobberize):
827         * dfg/DFGDoesGC.cpp:
828         (JSC::DFG::doesGC):
829         * dfg/DFGFixupPhase.cpp:
830         (JSC::DFG::FixupPhase::fixupNode):
831         * dfg/DFGNode.h:
832         (JSC::DFG::Node::convertToPhantomNewFunction):
833         (JSC::DFG::Node::isPhantomAllocation):
834         * dfg/DFGNodeType.h:
835         * dfg/DFGObjectAllocationSinkingPhase.cpp:
836         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
837         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
838         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
839         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
840         * dfg/DFGPredictionPropagationPhase.cpp:
841         (JSC::DFG::PredictionPropagationPhase::propagate):
842         * dfg/DFGPromotedHeapLocation.cpp:
843         (WTF::printInternal):
844         * dfg/DFGPromotedHeapLocation.h:
845         * dfg/DFGSafeToExecute.h:
846         (JSC::DFG::safeToExecute):
847         * dfg/DFGSpeculativeJIT32_64.cpp:
848         (JSC::DFG::SpeculativeJIT::compile):
849         * dfg/DFGSpeculativeJIT64.cpp:
850         (JSC::DFG::SpeculativeJIT::compile):
851         * dfg/DFGValidate.cpp:
852         (JSC::DFG::Validate::validateCPS):
853         * ftl/FTLCapabilities.cpp:
854         (JSC::FTL::canCompile):
855         * ftl/FTLLowerDFGToLLVM.cpp:
856         (JSC::FTL::LowerDFGToLLVM::compileNode):
857         * ftl/FTLOperations.cpp:
858         (JSC::FTL::operationMaterializeObjectInOSR):
859         * tests/stress/function-sinking-no-double-allocate.js: Added.
860         (call):
861         (.f):
862         (sink):
863         * tests/stress/function-sinking-osrexit.js: Added.
864         (.g):
865         (sink):
866         * tests/stress/function-sinking-put.js: Added.
867         (.g):
868         (sink):
869
870 2015-04-23  Basile Clement  <basile_clement@apple.com>
871
872         Make FunctionRareData allocation thread-safe
873         https://bugs.webkit.org/show_bug.cgi?id=144001
874
875         Reviewed by Mark Lam.
876
877         The two things we want to prevent are:
878
879          1. A thread seeing a pointer to a not-yet-fully-created rare data from
880             a JSFunction
881          2. A thread seeing a pointer to a not-yet-fully-created Structure from
882             an ObjectAllocationProfile
883
884         For 1., only the JS thread can be creating the rare data (in
885         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
886         worry about concurrent writes, and we don't need any fences when *reading* the
887         rare data from the JS thread. Thus we only need a storeStoreFence between the
888         rare data creation and assignment to m_rareData in
889         JSFunction::createAndInitializeRareData() to ensure that when the store to
890         m_rareData is issued, the rare data has been properly created.
891
892         For the DFG compilation threads, the only place they can access the
893         rare data is through JSFunction::rareData(), and so we only need a
894         loadLoadFence there to ensure that when we see a non-null pointer in
895         m_rareData, the pointed object will be seen as a fully created
896         FunctionRareData.
897
898
899         For 2., the structure is created in
900         ObjectAllocationProfile::initialize() (which appears to be called only by the
901         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
902         which always happen in the JS thread), and read through
903         ObjectAllocationProfile::structure() and
904         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
905         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
906         loadLoadFence in ObjectAllocationProfile::structure() (and change
907         ObjectAllocationProfile::inlineCapacity() to go through
908         ObjectAllocationProfile::structure()).
909
910         We don't need a fence in ObjectAllocationProfile::clear() because
911         clearing the structure is already as atomic as it gets.
912
913         Finally, notice that we don't care about the ObjectAllocationProfile's
914         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
915         ObjectAllocationProfile::clear() that are always run in the JS thread.
916         ObjectAllocationProfile::isNull() could cause some trouble, but it is
917         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
918         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
919         thread anyway.
920
921         * bytecode/ObjectAllocationProfile.h:
922         (JSC::ObjectAllocationProfile::initialize):
923         (JSC::ObjectAllocationProfile::structure):
924         (JSC::ObjectAllocationProfile::inlineCapacity):
925         * runtime/JSFunction.cpp:
926         (JSC::JSFunction::allocateAndInitializeRareData):
927         * runtime/JSFunction.h:
928         (JSC::JSFunction::rareData):
929         (JSC::JSFunction::allocationStructure): Deleted.
930         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
931
932 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
933
934         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
935         https://bugs.webkit.org/show_bug.cgi?id=143735
936
937         Reviewed by Geoffrey Garen.
938         
939         We've always had bugs arising from the fact that we would MovHint something into a local,
940         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
941         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
942         sophistication of the transformations we are doing today, this approach is just not sound
943         anymore.
944         
945         This comprehensively fixes these bugs by having the DFG backend automatically insert
946         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
947         makes it much faster to query bytecode liveness.
948         
949         It's about as perf-neutral as it gets for a change that increases compiler work without
950         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
951         which should then speed us up. I can't really report concrete slow-down numbers because
952         they are low enough to basically be in the noise. For example, a 20-iteration run of
953         SunSpider yields "maybe 0.8% slower", whatever that means.
954
955         * CMakeLists.txt:
956         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
957         * JavaScriptCore.xcodeproj/project.pbxproj:
958         * bytecode/BytecodeLivenessAnalysis.cpp:
959         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
960         * bytecode/FullBytecodeLiveness.h:
961         (JSC::FullBytecodeLiveness::getLiveness):
962         * bytecode/VirtualRegister.h:
963         (JSC::VirtualRegister::operator+):
964         (JSC::VirtualRegister::operator-):
965         * dfg/DFGForAllKills.h:
966         (JSC::DFG::forAllLiveNodesAtTail):
967         (JSC::DFG::forAllKilledOperands):
968         (JSC::DFG::forAllKilledNodesAtNodeIndex):
969         * dfg/DFGGraph.cpp:
970         (JSC::DFG::Graph::isLiveInBytecode):
971         (JSC::DFG::Graph::localsLiveInBytecode):
972         * dfg/DFGGraph.h:
973         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
974         (JSC::DFG::Graph::forAllLiveInBytecode):
975         * dfg/DFGMayExit.cpp:
976         (JSC::DFG::mayExit):
977         * dfg/DFGMovHintRemovalPhase.cpp:
978         * dfg/DFGNodeType.h:
979         * dfg/DFGPhantomInsertionPhase.cpp: Added.
980         (JSC::DFG::performPhantomInsertion):
981         * dfg/DFGPhantomInsertionPhase.h: Added.
982         * dfg/DFGPlan.cpp:
983         (JSC::DFG::Plan::compileInThreadImpl):
984         * dfg/DFGScoreBoard.h:
985         (JSC::DFG::ScoreBoard::sortFree):
986         (JSC::DFG::ScoreBoard::assertClear):
987         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
988         (JSC::DFG::VirtualRegisterAllocationPhase::run):
989         * ftl/FTLLowerDFGToLLVM.cpp:
990         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
991         * tests/stress/phantom-inadequacy.js: Added.
992         (bar):
993         (baz):
994         (foo):
995
996 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
997
998         Rename HardPhantom to MustGenerate.
999
1000         Rubber stamped by Geoffrey Garen.
1001         
1002         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
1003         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
1004         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
1005         node should just be called MustGenerate.
1006
1007         * dfg/DFGAbstractInterpreterInlines.h:
1008         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1009         * dfg/DFGArgumentsEliminationPhase.cpp:
1010         * dfg/DFGClobberize.h:
1011         (JSC::DFG::clobberize):
1012         * dfg/DFGDCEPhase.cpp:
1013         (JSC::DFG::DCEPhase::run):
1014         * dfg/DFGDoesGC.cpp:
1015         (JSC::DFG::doesGC):
1016         * dfg/DFGFixupPhase.cpp:
1017         (JSC::DFG::FixupPhase::fixupNode):
1018         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1019         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1020         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
1021         * dfg/DFGMayExit.cpp:
1022         (JSC::DFG::mayExit):
1023         * dfg/DFGNode.h:
1024         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1025         * dfg/DFGNodeType.h:
1026         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1027         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1028         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1029         (JSC::DFG::PhantomCanonicalizationPhase::run):
1030         * dfg/DFGPhantomRemovalPhase.cpp:
1031         (JSC::DFG::PhantomRemovalPhase::run):
1032         * dfg/DFGPredictionPropagationPhase.cpp:
1033         (JSC::DFG::PredictionPropagationPhase::propagate):
1034         * dfg/DFGSafeToExecute.h:
1035         (JSC::DFG::safeToExecute):
1036         * dfg/DFGSpeculativeJIT32_64.cpp:
1037         (JSC::DFG::SpeculativeJIT::compile):
1038         * dfg/DFGSpeculativeJIT64.cpp:
1039         (JSC::DFG::SpeculativeJIT::compile):
1040         * dfg/DFGTypeCheckHoistingPhase.cpp:
1041         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1042         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1043         * dfg/DFGVarargsForwardingPhase.cpp:
1044         * ftl/FTLCapabilities.cpp:
1045         (JSC::FTL::canCompile):
1046         * ftl/FTLLowerDFGToLLVM.cpp:
1047         (JSC::FTL::LowerDFGToLLVM::compileNode):
1048
1049 2015-04-23  Jordan Harband  <ljharb@gmail.com>
1050
1051         Implement `Object.assign`
1052         https://bugs.webkit.org/show_bug.cgi?id=143980
1053
1054         Reviewed by Filip Pizlo.
1055
1056         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
1057
1058         * builtins/ObjectConstructor.js: Added.
1059         (assign):
1060         * runtime/CommonIdentifiers.h:
1061         * runtime/JSGlobalObject.cpp:
1062         (JSC::JSGlobalObject::init):
1063         * runtime/ObjectConstructor.cpp:
1064         * runtime/ObjectConstructor.h:
1065
1066 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
1067
1068         Unreviewed, fix debug build.
1069
1070         * dfg/DFGGraph.h:
1071         (JSC::DFG::Graph::performSubstitutionForEdge):
1072
1073 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
1074
1075         Nodes should have an optional epoch field
1076         https://bugs.webkit.org/show_bug.cgi?id=144084
1077
1078         Reviewed by Ryosuke Niwa and Mark Lam.
1079         
1080         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
1081         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
1082         used.
1083
1084         * dfg/DFGCPSRethreadingPhase.cpp:
1085         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
1086         * dfg/DFGCSEPhase.cpp:
1087         * dfg/DFGEpoch.h:
1088         (JSC::DFG::Epoch::fromUnsigned):
1089         (JSC::DFG::Epoch::toUnsigned):
1090         * dfg/DFGGraph.cpp:
1091         (JSC::DFG::Graph::clearReplacements):
1092         (JSC::DFG::Graph::clearEpochs):
1093         * dfg/DFGGraph.h:
1094         (JSC::DFG::Graph::performSubstitutionForEdge):
1095         * dfg/DFGNode.h:
1096         (JSC::DFG::Node::Node):
1097         (JSC::DFG::Node::replaceWith):
1098         (JSC::DFG::Node::replacement):
1099         (JSC::DFG::Node::setReplacement):
1100         (JSC::DFG::Node::epoch):
1101         (JSC::DFG::Node::setEpoch):
1102         * dfg/DFGSSAConversionPhase.cpp:
1103         (JSC::DFG::SSAConversionPhase::run):
1104
1105 2015-04-22  Mark Lam  <mark.lam@apple.com>
1106
1107         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
1108         https://bugs.webkit.org/show_bug.cgi?id=143898
1109
1110         Reviewed by Filip Pizlo.
1111
1112         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
1113         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
1114         compilation threads because StringImpls are not thread safe. As a result, we get
1115         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
1116         build.
1117
1118         This patch fixes the issue by only collecting the CodeBlock (and associated info)
1119         into a DeferredSourceDump record while compiling, and stashing it away in a
1120         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
1121         later.
1122
1123         When compilation is done, the callback object will be notified that
1124         compilationDidComplete().  We will dump the SourceCode strings from there. 
1125         Since compilationDidComplete() is guaranteed to only be called on the thread
1126         doing JS execution, it is safe to access the SourceCode strings there and ref
1127         their underlying StringImpls as needed.        
1128
1129         * CMakeLists.txt:
1130         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1131         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1132         * JavaScriptCore.xcodeproj/project.pbxproj:
1133         * bytecode/DeferredCompilationCallback.cpp:
1134         (JSC::DeferredCompilationCallback::compilationDidComplete):
1135         (JSC::DeferredCompilationCallback::sourceDumpInfo):
1136         (JSC::DeferredCompilationCallback::dumpCompiledSources):
1137         * bytecode/DeferredCompilationCallback.h:
1138         * bytecode/DeferredSourceDump.cpp: Added.
1139         (JSC::DeferredSourceDump::DeferredSourceDump):
1140         (JSC::DeferredSourceDump::dump):
1141         * bytecode/DeferredSourceDump.h: Added.
1142         * dfg/DFGByteCodeParser.cpp:
1143         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1144         * dfg/DFGDriver.cpp:
1145         (JSC::DFG::compileImpl):
1146
1147 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
1148
1149         Implement String.codePointAt()
1150         https://bugs.webkit.org/show_bug.cgi?id=143934
1151
1152         Reviewed by Darin Adler.
1153
1154         This patch adds String.codePointAt() as defined by ES6.
1155         I opted for a C++ implementation for now.
1156
1157         * runtime/StringPrototype.cpp:
1158         (JSC::StringPrototype::finishCreation):
1159         (JSC::codePointAt):
1160         (JSC::stringProtoFuncCodePointAt):
1161
1162 2015-04-22  Mark Lam  <mark.lam@apple.com>
1163
1164         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
1165         https://bugs.webkit.org/show_bug.cgi?id=144067
1166
1167         Reviewed by Michael Saboff.
1168
1169         Currently, there are a few places where the JSObject that owns the
1170         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
1171         write barrier.  This is a bug and can result in the GC collecting the
1172         SparseArrayEntry even though it is being referenced by the
1173         SparseArrayValueMap.  This patch fixes the bug.
1174
1175         * runtime/JSObject.cpp:
1176         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
1177         (JSC::JSObject::putIndexedDescriptor):
1178         * tests/stress/sparse-array-entry-update-144067.js: Added.
1179         (useMemoryToTriggerGCs):
1180         (foo):
1181
1182 2015-04-22  Mark Lam  <mark.lam@apple.com>
1183
1184         Give the heap object iterators the ability to return early.
1185         https://bugs.webkit.org/show_bug.cgi?id=144011
1186
1187         Reviewed by Michael Saboff.
1188
1189         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
1190         candidate cell pointers, and, when in use, is called a lot more often than
1191         the normal way those iterators are used.  As a result, I see my instrumented
1192         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
1193         callback functor the ability to tell the iterators to return early when the
1194         functor no longer needs to continue iterating.  With this, my instrumented
1195         VM is useful again for debugging.
1196
1197         Since heap iteration is not something that we do in a typical fast path,
1198         I don't expect this to have any noticeable impact on performance.
1199
1200         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
1201         it checks JSCell addresses, not just JSObjects.
1202
1203         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1204         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1205         * JavaScriptCore.xcodeproj/project.pbxproj:
1206         * debugger/Debugger.cpp:
1207         * heap/GCLogging.cpp:
1208         (JSC::LoggingFunctor::operator()):
1209         * heap/Heap.cpp:
1210         (JSC::Zombify::visit):
1211         (JSC::Zombify::operator()):
1212         * heap/HeapStatistics.cpp:
1213         (JSC::StorageStatistics::visit):
1214         (JSC::StorageStatistics::operator()):
1215         * heap/HeapVerifier.cpp:
1216         (JSC::GatherLiveObjFunctor::visit):
1217         (JSC::GatherLiveObjFunctor::operator()):
1218         * heap/MarkedBlock.cpp:
1219         (JSC::SetNewlyAllocatedFunctor::operator()):
1220         * heap/MarkedBlock.h:
1221         (JSC::MarkedBlock::forEachCell):
1222         (JSC::MarkedBlock::forEachLiveCell):
1223         (JSC::MarkedBlock::forEachDeadCell):
1224         * heap/MarkedSpace.h:
1225         (JSC::MarkedSpace::forEachLiveCell):
1226         (JSC::MarkedSpace::forEachDeadCell):
1227         * inspector/agents/InspectorRuntimeAgent.cpp:
1228         (Inspector::TypeRecompiler::visit):
1229         (Inspector::TypeRecompiler::operator()):
1230         * runtime/IterationStatus.h: Added.
1231         * runtime/JSGlobalObject.cpp:
1232         * runtime/VM.cpp:
1233         (JSC::StackPreservingRecompiler::visit):
1234         (JSC::StackPreservingRecompiler::operator()):
1235         * tools/JSDollarVMPrototype.cpp:
1236         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
1237         (JSC::CellAddressCheckFunctor::operator()):
1238         (JSC::JSDollarVMPrototype::isValidCell):
1239         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
1240         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
1241
1242 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1243
1244         [[Set]] should be properly executed in JS builtins
1245         https://bugs.webkit.org/show_bug.cgi?id=143996
1246
1247         Reviewed by Geoffrey Garen.
1248
1249         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
1250         However,
1251
1252         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
1253         2. It's different from the default JS behavior.
1254
1255         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
1256         And dropping the current hack for builtins.
1257
1258         * builtins/Array.prototype.js:
1259         (filter):
1260         (map):
1261         (find):
1262         * bytecompiler/BytecodeGenerator.cpp:
1263         (JSC::BytecodeGenerator::emitPutByVal):
1264         * tests/stress/array-fill-put-by-val.js: Added.
1265         (shouldThrow):
1266         (.set get array):
1267         * tests/stress/array-filter-put-by-val-direct.js: Added.
1268         (shouldBe):
1269         (.set get var):
1270         * tests/stress/array-find-does-not-lookup-twice.js: Added.
1271         (shouldBe):
1272         (shouldThrow):
1273         (.get shouldBe):
1274         * tests/stress/array-from-put-by-val-direct.js: Added.
1275         (shouldBe):
1276         (.set get var):
1277         * tests/stress/array-from-set-length.js: Added.
1278         (shouldBe):
1279         (ArrayLike):
1280         (ArrayLike.prototype.set length):
1281         (ArrayLike.prototype.get length):
1282         * tests/stress/array-map-put-by-val-direct.js: Added.
1283         (shouldBe):
1284         (.set get var):
1285
1286 2015-04-22  Basile Clement  <basile_clement@apple.com>
1287  
1288         Don't de-allocate FunctionRareData
1289         https://bugs.webkit.org/show_bug.cgi?id=144000
1290
1291         Reviewed by Michael Saboff.
1292
1293         A function rare data (containing most notably its allocation profile) is currently
1294         freed and re-allocated each time the function's prototype is cleared.
1295         This is not optimal as it means we are invalidating the watchpoint and recompiling the
1296         scope each time the prototype is cleared.
1297
1298         This makes it so that a single rare data is reused, clearing the underlying
1299         ObjectAllocationProfile instead of throwing away the whole rare data on
1300         .prototype updates.
1301
1302         * runtime/FunctionRareData.cpp:
1303         (JSC::FunctionRareData::create):
1304         (JSC::FunctionRareData::finishCreation):
1305         * runtime/FunctionRareData.h:
1306         * runtime/JSFunction.cpp:
1307         (JSC::JSFunction::allocateAndInitializeRareData):
1308         (JSC::JSFunction::initializeRareData):
1309
1310 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
1311
1312         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
1313
1314         * dfg/DFGSpeculativeJIT32_64.cpp:
1315         (JSC::DFG::SpeculativeJIT::compile):
1316
1317 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
1318
1319         DFG should allow Phantoms after terminals
1320         https://bugs.webkit.org/show_bug.cgi?id=126778
1321
1322         Reviewed by Mark Lam.
1323         
1324         It's important for us to be able to place liveness-marking nodes after nodes that do
1325         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
1326         terminals. That made things awkward, especially for Switch and Branch, which may do
1327         things that necessitate liveness markers (for example they might want to use a converted
1328         version of a value rather than the value that was MovHinted). We previously made this
1329         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
1330         thing.
1331         
1332         This changes our IR to allow for the terminal to not be the last node in a block. Asking
1333         for the terminal involves a search. DFG::validate() checks that the nodes after the
1334         terminal are liveness markers that have no effects or checks.
1335         
1336         This is perf-neutral but will allow more optimizations in the future. It will also make
1337         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
1338
1339         * dfg/DFGBasicBlock.cpp:
1340         (JSC::DFG::BasicBlock::replaceTerminal):
1341         * dfg/DFGBasicBlock.h:
1342         (JSC::DFG::BasicBlock::findTerminal):
1343         (JSC::DFG::BasicBlock::terminal):
1344         (JSC::DFG::BasicBlock::insertBeforeTerminal):
1345         (JSC::DFG::BasicBlock::numSuccessors):
1346         (JSC::DFG::BasicBlock::successor):
1347         (JSC::DFG::BasicBlock::successorForCondition):
1348         (JSC::DFG::BasicBlock::successors):
1349         (JSC::DFG::BasicBlock::last): Deleted.
1350         (JSC::DFG::BasicBlock::takeLast): Deleted.
1351         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
1352         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
1353         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
1354         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
1355         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
1356         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
1357         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
1358         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
1359         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
1360         * dfg/DFGBasicBlockInlines.h:
1361         (JSC::DFG::BasicBlock::appendNonTerminal):
1362         (JSC::DFG::BasicBlock::replaceTerminal):
1363         * dfg/DFGByteCodeParser.cpp:
1364         (JSC::DFG::ByteCodeParser::addToGraph):
1365         (JSC::DFG::ByteCodeParser::inlineCall):
1366         (JSC::DFG::ByteCodeParser::handleInlining):
1367         (JSC::DFG::ByteCodeParser::parseBlock):
1368         (JSC::DFG::ByteCodeParser::linkBlock):
1369         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1370         * dfg/DFGCFGSimplificationPhase.cpp:
1371         (JSC::DFG::CFGSimplificationPhase::run):
1372         (JSC::DFG::CFGSimplificationPhase::convertToJump):
1373         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1374         * dfg/DFGCPSRethreadingPhase.cpp:
1375         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1376         * dfg/DFGCommon.h:
1377         (JSC::DFG::NodeAndIndex::NodeAndIndex):
1378         (JSC::DFG::NodeAndIndex::operator!):
1379         * dfg/DFGFixupPhase.cpp:
1380         (JSC::DFG::FixupPhase::fixupBlock):
1381         (JSC::DFG::FixupPhase::fixupNode):
1382         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1383         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
1384         * dfg/DFGForAllKills.h:
1385         (JSC::DFG::forAllLiveNodesAtTail):
1386         * dfg/DFGGraph.cpp:
1387         (JSC::DFG::Graph::terminalsAreValid):
1388         (JSC::DFG::Graph::dumpBlockHeader):
1389         * dfg/DFGGraph.h:
1390         * dfg/DFGInPlaceAbstractState.cpp:
1391         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
1392         * dfg/DFGLICMPhase.cpp:
1393         (JSC::DFG::LICMPhase::run):
1394         (JSC::DFG::LICMPhase::attemptHoist):
1395         * dfg/DFGMovHintRemovalPhase.cpp:
1396         * dfg/DFGNode.h:
1397         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
1398         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
1399         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
1400         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
1401         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
1402         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
1403         (JSC::DFG::Node::SuccessorsIterable::begin):
1404         (JSC::DFG::Node::SuccessorsIterable::end):
1405         (JSC::DFG::Node::successors):
1406         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1407         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
1408         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
1409         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1410         * dfg/DFGPhantomRemovalPhase.cpp:
1411         (JSC::DFG::PhantomRemovalPhase::run):
1412         * dfg/DFGPutStackSinkingPhase.cpp:
1413         * dfg/DFGSSAConversionPhase.cpp:
1414         (JSC::DFG::SSAConversionPhase::run):
1415         * dfg/DFGSpeculativeJIT.h:
1416         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
1417         * dfg/DFGSpeculativeJIT32_64.cpp:
1418         (JSC::DFG::SpeculativeJIT::compile):
1419         * dfg/DFGSpeculativeJIT64.cpp:
1420         (JSC::DFG::SpeculativeJIT::compile):
1421         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
1422         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
1423         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1424         (JSC::DFG::TierUpCheckInjectionPhase::run):
1425         * dfg/DFGValidate.cpp:
1426         (JSC::DFG::Validate::validate):
1427         * ftl/FTLLowerDFGToLLVM.cpp:
1428         (JSC::FTL::LowerDFGToLLVM::compileNode):
1429         * tests/stress/closure-call-exit.js: Added.
1430         (foo):
1431
1432 2015-04-21  Basile Clement  <basile_clement@apple.com>
1433
1434         PhantomNewObject should be marked NodeMustGenerate
1435         https://bugs.webkit.org/show_bug.cgi?id=143974
1436
1437         Reviewed by Filip Pizlo.
1438
1439         * dfg/DFGNode.h:
1440         (JSC::DFG::Node::convertToPhantomNewObject):
1441         Was not properly marking NodeMustGenerate when converting.
1442
1443 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
1444
1445         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
1446         https://bugs.webkit.org/show_bug.cgi?id=144007
1447
1448         Reviewed by Mark Lam.
1449         
1450         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
1451         if isForwardVarargs.
1452
1453         * dfg/DFGSpeculativeJIT32_64.cpp:
1454         (JSC::DFG::SpeculativeJIT::emitCall):
1455         * dfg/DFGSpeculativeJIT64.cpp:
1456         (JSC::DFG::SpeculativeJIT::emitCall):
1457         * tests/stress/varargs-then-slow-call.js: Added.
1458         (foo):
1459         (bar):
1460         (fuzz):
1461         (baz):
1462
1463 2015-04-21  Basile Clement  <basile_clement@apple.com>
1464
1465         Remove AllocationProfileWatchpoint node
1466         https://bugs.webkit.org/show_bug.cgi?id=143999
1467
1468         Reviewed by Filip Pizlo.
1469
1470         * dfg/DFGAbstractInterpreterInlines.h:
1471         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1472         * dfg/DFGByteCodeParser.cpp:
1473         (JSC::DFG::ByteCodeParser::parseBlock):
1474         * dfg/DFGClobberize.h:
1475         (JSC::DFG::clobberize):
1476         * dfg/DFGDoesGC.cpp:
1477         (JSC::DFG::doesGC):
1478         * dfg/DFGFixupPhase.cpp:
1479         (JSC::DFG::FixupPhase::fixupNode):
1480         * dfg/DFGHeapLocation.cpp:
1481         (WTF::printInternal):
1482         * dfg/DFGHeapLocation.h:
1483         * dfg/DFGNode.h:
1484         (JSC::DFG::Node::hasCellOperand):
1485         * dfg/DFGNodeType.h:
1486         * dfg/DFGPredictionPropagationPhase.cpp:
1487         (JSC::DFG::PredictionPropagationPhase::propagate):
1488         * dfg/DFGSafeToExecute.h:
1489         (JSC::DFG::safeToExecute):
1490         * dfg/DFGSpeculativeJIT32_64.cpp:
1491         (JSC::DFG::SpeculativeJIT::compile):
1492         * dfg/DFGSpeculativeJIT64.cpp:
1493         (JSC::DFG::SpeculativeJIT::compile):
1494         * dfg/DFGWatchpointCollectionPhase.cpp:
1495         (JSC::DFG::WatchpointCollectionPhase::handle):
1496         * ftl/FTLCapabilities.cpp:
1497         (JSC::FTL::canCompile):
1498         * ftl/FTLLowerDFGToLLVM.cpp:
1499         (JSC::FTL::LowerDFGToLLVM::compileNode):
1500         * runtime/JSFunction.h:
1501         (JSC::JSFunction::rareData):
1502         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
1503
1504 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
1505
1506         MovHint should be a strong use
1507         https://bugs.webkit.org/show_bug.cgi?id=143734
1508
1509         Reviewed by Geoffrey Garen.
1510         
1511         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
1512         so is a major step towards allowing more fancy DFG transformations and also probably fixing
1513         some bugs.
1514         
1515         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
1516         introducing a MovHint removal phase that runs in FTL.
1517         
1518         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
1519
1520         * CMakeLists.txt:
1521         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1522         * JavaScriptCore.xcodeproj/project.pbxproj:
1523         * bytecode/CodeOrigin.cpp:
1524         (JSC::InlineCallFrame::dumpInContext):
1525         * dfg/DFGDCEPhase.cpp:
1526         (JSC::DFG::DCEPhase::fixupBlock):
1527         * dfg/DFGDisassembler.cpp:
1528         (JSC::DFG::Disassembler::createDumpList):
1529         * dfg/DFGEpoch.cpp: Added.
1530         (JSC::DFG::Epoch::dump):
1531         * dfg/DFGEpoch.h: Added.
1532         (JSC::DFG::Epoch::Epoch):
1533         (JSC::DFG::Epoch::first):
1534         (JSC::DFG::Epoch::operator!):
1535         (JSC::DFG::Epoch::next):
1536         (JSC::DFG::Epoch::bump):
1537         (JSC::DFG::Epoch::operator==):
1538         (JSC::DFG::Epoch::operator!=):
1539         * dfg/DFGMayExit.cpp:
1540         (JSC::DFG::mayExit):
1541         * dfg/DFGMovHintRemovalPhase.cpp: Added.
1542         (JSC::DFG::performMovHintRemoval):
1543         * dfg/DFGMovHintRemovalPhase.h: Added.
1544         * dfg/DFGNodeType.h:
1545         * dfg/DFGPlan.cpp:
1546         (JSC::DFG::Plan::compileInThreadImpl):
1547         * dfg/DFGSpeculativeJIT.cpp:
1548         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1549         * dfg/DFGSpeculativeJIT64.cpp:
1550         (JSC::DFG::SpeculativeJIT::compile):
1551         * runtime/Options.h:
1552
1553 2015-04-21  Basile Clement  <basile_clement@apple.com>
1554
1555         REGRESSION (r182899): icloud.com crashes
1556         https://bugs.webkit.org/show_bug.cgi?id=143960
1557
1558         Reviewed by Filip Pizlo.
1559
1560         * runtime/JSFunction.h:
1561         (JSC::JSFunction::allocationStructure):
1562         * tests/stress/dfg-rare-data.js: Added.
1563         (F): Regression test
1564
1565 2015-04-21  Michael Saboff  <msaboff@apple.com>
1566
1567         Crash in JSC::Interpreter::execute
1568         https://bugs.webkit.org/show_bug.cgi?id=142625
1569
1570         Reviewed by Filip Pizlo.
1571
1572         We need to keep the FunctionExecutables in the code block for the eval flavor of 
1573         Interpreter::execute() in order to create the scope used to eval.
1574
1575         * bytecode/CodeBlock.cpp:
1576         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
1577         * bytecode/CodeBlock.h:
1578         * dfg/DFGGraph.cpp:
1579         (JSC::DFG::Graph::registerFrozenValues):
1580
1581 2015-04-21  Chris Dumez  <cdumez@apple.com>
1582
1583         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
1584         https://bugs.webkit.org/show_bug.cgi?id=143970
1585
1586         Reviewed by Darin Adler.
1587
1588         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
1589         constructor explicit as it copies the vector and it is easy to call it
1590         by mistake.
1591
1592         * bytecode/UnlinkedInstructionStream.cpp:
1593         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
1594         * bytecode/UnlinkedInstructionStream.h:
1595         * ftl/FTLLowerDFGToLLVM.cpp:
1596         (JSC::FTL::LowerDFGToLLVM::lower):
1597
1598 2015-04-20  Basile Clement  <basile_clement@apple.com>
1599
1600         PhantomNewObject should be marked NodeMustGenerate
1601         https://bugs.webkit.org/show_bug.cgi?id=143974
1602
1603         Reviewed by Filip Pizlo.
1604
1605         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
1606
1607 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
1608
1609         Cleanup some StringBuilder use
1610         https://bugs.webkit.org/show_bug.cgi?id=143550
1611
1612         Reviewed by Darin Adler.
1613
1614         * runtime/Symbol.cpp:
1615         (JSC::Symbol::descriptiveString):
1616         * runtime/TypeProfiler.cpp:
1617         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
1618         * runtime/TypeSet.cpp:
1619         (JSC::TypeSet::toJSONString):
1620         (JSC::StructureShape::propertyHash):
1621         (JSC::StructureShape::stringRepresentation):
1622         (JSC::StructureShape::toJSONString):
1623
1624 2015-04-20  Mark Lam  <mark.lam@apple.com>
1625
1626         Add debugging tools to test if a given pointer is a valid object and in the heap.
1627         https://bugs.webkit.org/show_bug.cgi?id=143910
1628
1629         Reviewed by Geoffrey Garen.
1630
1631         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
1632         purported JSObject is really a valid object in the heap or not.  We can add the
1633         following utility functions to help:
1634             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
1635             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
1636             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
1637             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
1638
1639         Also moved lldb callable debug utility function prototypes from
1640         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
1641         JSDollarVMPrototype class.  This is so that we can conveniently #include that
1642         file to get the prototypes when we need to call them programmatically from
1643         instrumentation that we add while debugging an issue.
1644
1645         * heap/Heap.h:
1646         (JSC::Heap::storageSpace):
1647         * tools/JSDollarVMPrototype.cpp:
1648         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
1649         (JSC::ensureCurrentThreadOwnsJSLock):
1650         (JSC::JSDollarVMPrototype::gc):
1651         (JSC::functionGC):
1652         (JSC::JSDollarVMPrototype::edenGC):
1653         (JSC::functionEdenGC):
1654         (JSC::JSDollarVMPrototype::isInHeap):
1655         (JSC::JSDollarVMPrototype::isInObjectSpace):
1656         (JSC::JSDollarVMPrototype::isInStorageSpace):
1657         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
1658         (JSC::ObjectAddressCheckFunctor::operator()):
1659         (JSC::JSDollarVMPrototype::isValidCell):
1660         (JSC::JSDollarVMPrototype::isValidCodeBlock):
1661         (JSC::JSDollarVMPrototype::codeBlockForFrame):
1662         (JSC::functionCodeBlockForFrame):
1663         (JSC::codeBlockFromArg):
1664         (JSC::JSDollarVMPrototype::printCallFrame):
1665         (JSC::JSDollarVMPrototype::printStack):
1666         (JSC::JSDollarVMPrototype::printValue):
1667         (JSC::currentThreadOwnsJSLock): Deleted.
1668         (JSC::gc): Deleted.
1669         (JSC::edenGC): Deleted.
1670         (JSC::isValidCodeBlock): Deleted.
1671         (JSC::codeBlockForFrame): Deleted.
1672         (JSC::printCallFrame): Deleted.
1673         (JSC::printStack): Deleted.
1674         (JSC::printValue): Deleted.
1675         * tools/JSDollarVMPrototype.h:
1676
1677 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
1678
1679         Web Inspector: Improve Support for WeakSet in Console
1680         https://bugs.webkit.org/show_bug.cgi?id=143951
1681
1682         Reviewed by Darin Adler.
1683
1684         * inspector/InjectedScriptSource.js:
1685         * inspector/JSInjectedScriptHost.cpp:
1686         (Inspector::JSInjectedScriptHost::subtype):
1687         (Inspector::JSInjectedScriptHost::weakSetSize):
1688         (Inspector::JSInjectedScriptHost::weakSetEntries):
1689         * inspector/JSInjectedScriptHost.h:
1690         * inspector/JSInjectedScriptHostPrototype.cpp:
1691         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1692         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
1693         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
1694         Treat WeakSets like special sets.
1695
1696         * inspector/protocol/Runtime.json:
1697         Add a new object subtype, "weakset".
1698
1699 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1700
1701         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
1702         https://bugs.webkit.org/show_bug.cgi?id=143947
1703
1704         Reviewed by Darin Adler.
1705
1706         Type profiler has map between PropertyKey (StringImpl*) and offset.
1707         StringImpl* is also used for Symbol PropertyKey.
1708         So equality of hash tables is considered by interned StringImpl*'s pointer value.
1709         To do so, use IdentifierRepHash instead of StringHash.
1710
1711         * runtime/SymbolTable.h:
1712
1713 2015-04-20  Jordan Harband  <ljharb@gmail.com>
1714
1715         Implement `Object.is`
1716         https://bugs.webkit.org/show_bug.cgi?id=143865
1717
1718         Reviewed by Darin Adler.
1719
1720         Expose sameValue to JS, via Object.is
1721         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
1722
1723         * runtime/ObjectConstructor.cpp:
1724         (JSC::objectConstructorIs):
1725         * runtime/PropertyDescriptor.cpp:
1726         (JSC::sameValue):
1727
1728 2015-04-19  Darin Adler  <darin@apple.com>
1729
1730         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
1731         https://bugs.webkit.org/show_bug.cgi?id=143941
1732
1733         Reviewed by Gyuyoung Kim.
1734
1735         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
1736         * API/JSCallbackObjectFunctions.h: Ditto.
1737
1738         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
1739         create function and the constructor and for m_impl.
1740         * API/ObjCCallbackFunction.mm:
1741         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
1742         class by using RetainPtr<Class>.
1743         (ArgumentTypeDelegate::typeInteger): Use make_unique.
1744         (ArgumentTypeDelegate::typeDouble): Ditto.
1745         (ArgumentTypeDelegate::typeBool): Ditto.
1746         (ArgumentTypeDelegate::typeVoid): Ditto.
1747         (ArgumentTypeDelegate::typeId): Ditto.
1748         (ArgumentTypeDelegate::typeOfClass): Ditto.
1749         (ArgumentTypeDelegate::typeBlock): Ditto.
1750         (ArgumentTypeDelegate::typeStruct): Ditto.
1751         (ResultTypeDelegate::typeInteger): Ditto.
1752         (ResultTypeDelegate::typeDouble): Ditto.
1753         (ResultTypeDelegate::typeBool): Ditto.
1754         (ResultTypeDelegate::typeVoid): Ditto.
1755         (ResultTypeDelegate::typeId): Ditto.
1756         (ResultTypeDelegate::typeOfClass): Ditto.
1757         (ResultTypeDelegate::typeBlock): Ditto.
1758         (ResultTypeDelegate::typeStruct): Ditto.
1759         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
1760         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
1761         Use RetainPtr<Class> for m_instanceClass.
1762         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
1763         for non-Objective-C object pointer null.
1764         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
1765         the arguments to the constructor and for m_impl.
1766         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
1767         (skipNumber): Mark this static since it's local to this source file.
1768         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
1769         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
1770         nullptr instead of nil for JSObjectRef values.
1771         (objCCallbackFunctionForMethod): Tweaked comment.
1772         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
1773
1774         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
1775
1776         * heap/GCThread.cpp:
1777         (JSC::GCThread::GCThread): Use unique_ptr.
1778         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
1779         m_slotVisitor and m_copyVisitor.
1780         * heap/GCThreadSharedData.cpp:
1781         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
1782
1783         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
1784
1785 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
1786
1787         Improve the feature.json files
1788
1789         * features.json:
1790
1791 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1792
1793         Introduce bytecode intrinsics
1794         https://bugs.webkit.org/show_bug.cgi?id=143926
1795
1796         Reviewed by Filip Pizlo.
1797
1798         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
1799         When implementing functions in builtins/*.js,
1800         sometimes we require lower level functionality.
1801
1802         For example, in the current Array.from, we use `result[k] = value`.
1803         The spec requires `[[DefineOwnProperty]]` operation here.
1804         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
1805         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
1806
1807         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
1808         However, there's no syntax to generate it directly.
1809
1810         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
1811         Like @call, @apply, we introduce a new node, Intrinsic.
1812         These are generated when calling appropriate private symbols in privileged code.
1813         AST parser detects them and generates Intrinsic nodes and
1814         BytecodeCompiler detects them and generate required bytecodes.
1815
1816         Currently, Array.from implementation works fine without this patch.
1817         This is because when the target code is builtin JS,
1818         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
1819         This solves the above issue. However, instead of solving this issue,
1820         it raises another issue; There's no way to emit `[[Set]]` operation.
1821         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
1822         So to implement it precisely, introducing bytecode level intrinsics is necessary.
1823
1824         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
1825         for `result[k] = value` under builtin JS environment. Instead of that special handling,
1826         use bytecode intrinsics instead. It solves problems and it is more intuitive
1827         because written JS code in builtin works as the same to the usual JS code.
1828
1829         * CMakeLists.txt:
1830         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1831         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1832         * JavaScriptCore.xcodeproj/project.pbxproj:
1833         * builtins/ArrayConstructor.js:
1834         (from):
1835         * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
1836         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1837         (JSC::BytecodeIntrinsicRegistry::lookup):
1838         * bytecode/BytecodeIntrinsicRegistry.h: Added.
1839         * bytecompiler/NodesCodegen.cpp:
1840         (JSC::BytecodeIntrinsicNode::emitBytecode):
1841         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
1842         * parser/ASTBuilder.h:
1843         (JSC::ASTBuilder::makeFunctionCallNode):
1844         * parser/NodeConstructors.h:
1845         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
1846         * parser/Nodes.h:
1847         (JSC::BytecodeIntrinsicNode::identifier):
1848         * runtime/CommonIdentifiers.cpp:
1849         (JSC::CommonIdentifiers::CommonIdentifiers):
1850         * runtime/CommonIdentifiers.h:
1851         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
1852         * tests/stress/array-from-with-accessors.js: Added.
1853         (shouldBe):
1854
1855 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1856
1857         Make Builtin functions non constructible
1858         https://bugs.webkit.org/show_bug.cgi?id=143923
1859
1860         Reviewed by Darin Adler.
1861
1862         Builtin functions defined by builtins/*.js accidentally have [[Construct]].
1863         According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
1864         This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
1865
1866         Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
1867         However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
1868         In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
1869         So in this patch, we check `isBuiltinFunction()` in those places.
1870
1871         * dfg/DFGByteCodeParser.cpp:
1872         (JSC::DFG::ByteCodeParser::inliningCost):
1873         * jit/JITOperations.cpp:
1874         * llint/LLIntSlowPaths.cpp:
1875         (JSC::LLInt::setUpCall):
1876         * runtime/JSFunction.cpp:
1877         (JSC::JSFunction::getConstructData):
1878         * tests/stress/builtin-function-is-construct-type-none.js: Added.
1879         (shouldThrow):
1880
1881 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1882
1883         [ES6] Implement WeakSet
1884         https://bugs.webkit.org/show_bug.cgi?id=142408
1885
1886         Reviewed by Darin Adler.
1887
1888         This patch implements ES6 WeakSet.
1889         Current implementation simply leverages WeakMapData with undefined value.
1890         This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
1891
1892         And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
1893         Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
1894         methods return false (or undefined for WeakMap.prototype.get)
1895         when a key is not Object instead of throwing a type error.
1896
1897         [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
1898
1899         * CMakeLists.txt:
1900         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1901         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1902         * JavaScriptCore.xcodeproj/project.pbxproj:
1903         * runtime/CommonIdentifiers.h:
1904         * runtime/JSGlobalObject.cpp:
1905         * runtime/JSGlobalObject.h:
1906         * runtime/JSWeakSet.cpp: Added.
1907         (JSC::JSWeakSet::finishCreation):
1908         (JSC::JSWeakSet::visitChildren):
1909         * runtime/JSWeakSet.h: Added.
1910         (JSC::JSWeakSet::createStructure):
1911         (JSC::JSWeakSet::create):
1912         (JSC::JSWeakSet::weakMapData):
1913         (JSC::JSWeakSet::JSWeakSet):
1914         * runtime/WeakMapPrototype.cpp:
1915         (JSC::getWeakMapData):
1916         (JSC::protoFuncWeakMapDelete):
1917         (JSC::protoFuncWeakMapGet):
1918         (JSC::protoFuncWeakMapHas):
1919         * runtime/WeakSetConstructor.cpp: Added.
1920         (JSC::WeakSetConstructor::finishCreation):
1921         (JSC::callWeakSet):
1922         (JSC::constructWeakSet):
1923         (JSC::WeakSetConstructor::getConstructData):
1924         (JSC::WeakSetConstructor::getCallData):
1925         * runtime/WeakSetConstructor.h: Added.
1926         (JSC::WeakSetConstructor::create):
1927         (JSC::WeakSetConstructor::createStructure):
1928         (JSC::WeakSetConstructor::WeakSetConstructor):
1929         * runtime/WeakSetPrototype.cpp: Added.
1930         (JSC::WeakSetPrototype::finishCreation):
1931         (JSC::getWeakMapData):
1932         (JSC::protoFuncWeakSetDelete):
1933         (JSC::protoFuncWeakSetHas):
1934         (JSC::protoFuncWeakSetAdd):
1935         * runtime/WeakSetPrototype.h: Added.
1936         (JSC::WeakSetPrototype::create):
1937         (JSC::WeakSetPrototype::createStructure):
1938         (JSC::WeakSetPrototype::WeakSetPrototype):
1939         * tests/stress/weak-set-constructor-adder.js: Added.
1940         (WeakSet.prototype.add):
1941         * tests/stress/weak-set-constructor.js: Added.
1942
1943 2015-04-17  Alexey Proskuryakov  <ap@apple.com>
1944
1945         Remove unused BoundsCheckedPointer
1946         https://bugs.webkit.org/show_bug.cgi?id=143896
1947
1948         Reviewed by Geoffrey Garen.
1949
1950         * bytecode/SpeculatedType.cpp: The header was included here.
1951
1952 2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1953
1954         [ES6] Fix name enumeration of static functions for Symbol constructor
1955         https://bugs.webkit.org/show_bug.cgi?id=143891
1956
1957         Reviewed by Geoffrey Garen.
1958
1959         Fix missing symbolPrototypeTable registration to the js class object.
1960         This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
1961
1962         * runtime/SymbolConstructor.cpp:
1963
1964 2015-04-17  Basile Clement  <basile_clement@apple.com>
1965
1966         Inline JSFunction allocation in DFG
1967         https://bugs.webkit.org/show_bug.cgi?id=143858
1968
1969         Reviewed by Filip Pizlo.
1970
1971         Followup to my previous patch which inlines JSFunction allocation when
1972         using FTL, now also enabled in DFG.
1973
1974         * dfg/DFGSpeculativeJIT.cpp:
1975         (JSC::DFG::SpeculativeJIT::compileNewFunction):
1976
1977 2015-04-16  Jordan Harband  <ljharb@gmail.com>
1978
1979         Number.parseInt is not === global parseInt in nightly r182673
1980         https://bugs.webkit.org/show_bug.cgi?id=143799
1981
1982         Reviewed by Darin Adler.
1983
1984         Ensuring parseInt === Number.parseInt, per spec
1985         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
1986
1987         * runtime/CommonIdentifiers.h:
1988         * runtime/JSGlobalObject.cpp:
1989         (JSC::JSGlobalObject::init):
1990         * runtime/JSGlobalObject.h:
1991         (JSC::JSGlobalObject::parseIntFunction):
1992         * runtime/NumberConstructor.cpp:
1993         (JSC::NumberConstructor::finishCreation):
1994
1995 2015-04-16  Mark Lam  <mark.lam@apple.com>
1996
1997         Gardening: fix CLOOP build after r182927.
1998
1999         Not reviewed.
2000
2001         * interpreter/StackVisitor.cpp:
2002         (JSC::StackVisitor::Frame::print):
2003
2004 2015-04-16  Basile Clement  <basile_clement@apple.com>
2005
2006         Inline JSFunction allocation in FTL
2007         https://bugs.webkit.org/show_bug.cgi?id=143851
2008
2009         Reviewed by Filip Pizlo.
2010
2011         JSFunction allocation is a simple operation that should be inlined when possible.
2012
2013         * ftl/FTLAbstractHeapRepository.h:
2014         * ftl/FTLLowerDFGToLLVM.cpp:
2015         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
2016         * runtime/JSFunction.h:
2017         (JSC::JSFunction::allocationSize):
2018
2019 2015-04-16  Mark Lam  <mark.lam@apple.com>
2020
2021         Add $vm debugging tool.
2022         https://bugs.webkit.org/show_bug.cgi?id=143809
2023
2024         Reviewed by Geoffrey Garen.
2025
2026         For debugging VM bugs, it would be useful to be able to dump VM data structures
2027         from JS code that we instrument.  To this end, let's introduce a
2028         JS_enableDollarVM option that, if true, installs an $vm property into each JS
2029         global object at creation time.  The $vm property refers to an object that
2030         provides a collection of useful utility functions.  For this initial
2031         implementation, $vm will have the following:
2032
2033             crash() - trigger an intentional crash.
2034
2035             dfgTrue() - returns true if the current function is DFG compiled, else returns false.
2036             jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
2037             llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
2038
2039             gc() - runs a full GC.
2040             edenGC() - runs an eden GC.
2041
2042             codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
2043             printSourceFor(codeBlock) - prints the source code for the codeBlock.
2044             printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
2045
2046             print(str) - prints a string to dataLog output.
2047             printCallFrame() - prints the current CallFrame.
2048             printStack() - prints the JS stack.
2049             printInternal(value) - prints the JSC internal info for the specified value.
2050
2051         With JS_enableDollarVM=true, JS code can use the above functions like so:
2052
2053             $vm.print("Using $vm features\n");
2054
2055         * CMakeLists.txt:
2056         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2057         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2058         * JavaScriptCore.xcodeproj/project.pbxproj:
2059         * bytecode/CodeBlock.cpp:
2060         (JSC::CodeBlock::printCallOp):
2061         - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
2062           Hence, we skip this step if we're dumping an FTL codeBlock.
2063
2064         * heap/Heap.cpp:
2065         (JSC::Heap::collectAndSweep):
2066         (JSC::Heap::collectAllGarbage): Deleted.
2067         * heap/Heap.h:
2068         (JSC::Heap::collectAllGarbage):
2069         - Add ability to do an Eden collection and sweep.
2070
2071         * interpreter/StackVisitor.cpp:
2072         (JSC::printIndents):
2073         (JSC::log):
2074         (JSC::logF):
2075         (JSC::StackVisitor::Frame::print):
2076         (JSC::jitTypeName): Deleted.
2077         (JSC::printif): Deleted.
2078         - Modernize the implementation of StackVisitor::Frame::print(), and remove some
2079           now redundant code.
2080         - Also fix it so that it downgrades gracefully when encountering inlined DFG
2081           and compiled FTL functions.
2082
2083         (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
2084         (DebugPrintFrameFunctor::operator()): Deleted.
2085         (debugPrintCallFrame): Deleted.
2086         (debugPrintStack): Deleted.
2087         - these have been moved into JSDollarVMPrototype.cpp. 
2088
2089         * interpreter/StackVisitor.h:
2090         - StackVisitor::Frame::print() is now enabled for release builds as well so that
2091           we can call it from $vm.
2092
2093         * runtime/JSGlobalObject.cpp:
2094         (JSC::JSGlobalObject::init):
2095         (JSC::JSGlobalObject::visitChildren):
2096         * runtime/JSGlobalObject.h:
2097         - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
2098           option.
2099
2100         * runtime/Options.h:
2101         - Added the JSC_enableDollarVM option.
2102
2103         * tools/JSDollarVM.cpp: Added.
2104         * tools/JSDollarVM.h: Added.
2105         (JSC::JSDollarVM::createStructure):
2106         (JSC::JSDollarVM::create):
2107         (JSC::JSDollarVM::JSDollarVM):
2108
2109         * tools/JSDollarVMPrototype.cpp: Added.
2110         - This file contains 2 sets of functions:
2111
2112           a. a C++ implementation of debugging utility functions that are callable when
2113              doing debugging from lldb.  To the extent possible, these functions try to
2114              be cautious and not cause unintended crashes should the user call them with
2115              the wrong info.  Hence, they are designed to be robust rather than speedy.
2116
2117           b. the native implementations of JS functions in the $vm object.  Where there
2118              is overlapping functionality, these are built on top of the C++ functions
2119              above to do the work.
2120
2121           Note: it does not make sense for all of the $vm functions to have a C++
2122           counterpart for lldb debugging.  For example, the $vm.dfgTrue() function is
2123           only useful for JS code, and works via the DFG intrinsics mechanism.
2124           When doing debugging via lldb, the optimization level of the currently
2125           executing JS function can be gotten by dumping the current CallFrame instead.
2126
2127         (JSC::currentThreadOwnsJSLock):
2128         (JSC::ensureCurrentThreadOwnsJSLock):
2129         (JSC::JSDollarVMPrototype::addFunction):
2130         (JSC::functionCrash): - $vm.crash()
2131         (JSC::functionDFGTrue): - $vm.dfgTrue()
2132         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2133         (JSC::CallerFrameJITTypeFunctor::operator()):
2134         (JSC::CallerFrameJITTypeFunctor::jitType):
2135         (JSC::functionLLintTrue): - $vm.llintTrue()
2136         (JSC::functionJITTrue): - $vm.jitTrue()
2137         (JSC::gc):
2138         (JSC::functionGC): - $vm.gc()
2139         (JSC::edenGC):
2140         (JSC::functionEdenGC): - $vm.edenGC()
2141         (JSC::isValidCodeBlock):
2142         (JSC::codeBlockForFrame):
2143         (JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
2144         (JSC::codeBlockFromArg):
2145         (JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
2146         (JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
2147         (JSC::functionPrint): - $vm.print(str)
2148         (JSC::PrintFrameFunctor::PrintFrameFunctor):
2149         (JSC::PrintFrameFunctor::operator()):
2150         (JSC::printCallFrame):
2151         (JSC::printStack):
2152         (JSC::functionPrintCallFrame): - $vm.printCallFrame()
2153         (JSC::functionPrintStack): - $vm.printStack()
2154         (JSC::printValue):
2155         (JSC::functionPrintValue): - $vm.printValue()
2156         (JSC::JSDollarVMPrototype::finishCreation):
2157         * tools/JSDollarVMPrototype.h: Added.
2158         (JSC::JSDollarVMPrototype::create):
2159         (JSC::JSDollarVMPrototype::createStructure):
2160         (JSC::JSDollarVMPrototype::JSDollarVMPrototype):
2161
2162 2015-04-16  Geoffrey Garen  <ggaren@apple.com>
2163
2164         Speculative fix after r182915
2165         https://bugs.webkit.org/show_bug.cgi?id=143404
2166
2167         Reviewed by Alexey Proskuryakov.
2168
2169         * runtime/SymbolConstructor.h:
2170
2171 2015-04-16  Mark Lam  <mark.lam@apple.com>
2172
2173         Fixed some typos in a comment.
2174
2175         Not reviewed.
2176
2177         * dfg/DFGGenerationInfo.h:
2178
2179 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2180
2181         [ES6] Implement Symbol.for and Symbol.keyFor
2182         https://bugs.webkit.org/show_bug.cgi?id=143404
2183
2184         Reviewed by Geoffrey Garen.
2185
2186         This patch implements Symbol.for and Symbol.keyFor.
2187         SymbolRegistry maintains registered StringImpl* symbols.
2188         And to make this mapping enabled over realms,
2189         VM owns this mapping (not JSGlobalObject).
2190
2191         While there's Default AtomicStringTable per thread,
2192         SymbolRegistry should not exist over VMs.
2193         So everytime VM is created, SymbolRegistry is also created.
2194
2195         In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
2196         Theres are several reasons.
2197         1. StringImpl* which represents identity of Symbols is not GC-managed object.
2198            So we cannot use WeakGCMap directly.
2199            While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
2200            because distinct Symbol* can exist.
2201            Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.
2202
2203         2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
2204            However there's problem about when we prune staled entries in SymbolRegistry.
2205            Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
2206            and it is not in GC-heap.
2207            While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
2208            So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
2209            As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.
2210
2211         So instead of using Weak reference, we take relatively easy design.
2212         When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
2213         And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.
2214
2215         * CMakeLists.txt:
2216         * DerivedSources.make:
2217         * runtime/SymbolConstructor.cpp:
2218         (JSC::SymbolConstructor::getOwnPropertySlot):
2219         (JSC::symbolConstructorFor):
2220         (JSC::symbolConstructorKeyFor):
2221         * runtime/SymbolConstructor.h:
2222         * runtime/VM.cpp:
2223         * runtime/VM.h:
2224         (JSC::VM::symbolRegistry):
2225         * tests/stress/symbol-registry.js: Added.
2226         (test):
2227
2228 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2229
2230         [ES6] Use specific functions for @@iterator functions
2231         https://bugs.webkit.org/show_bug.cgi?id=143838
2232
2233         Reviewed by Geoffrey Garen.
2234
2235         In ES6, some methods are defined with the different names.
2236
2237         For example,
2238
2239         Map.prototype[Symbol.iterator] === Map.prototype.entries
2240         Set.prototype[Symbol.iterator] === Set.prototype.values
2241         Array.prototype[Symbol.iterator] === Array.prototype.values
2242         %Arguments%[Symbol.iterator] === Array.prototype.values
2243
2244         However, current implementation creates different function objects per name.
2245         This patch fixes it by setting the object that is used for the other method to @@iterator.
2246         e.g. Setting Array.prototype.values function object to Array.prototype[Symbol.iterator].
2247
2248         And we drop Arguments' iterator implementation and replace Argument[@@iterator] implementation
2249         with Array.prototype.values to conform to the spec.
2250
2251         * CMakeLists.txt:
2252         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2253         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2254         * JavaScriptCore.xcodeproj/project.pbxproj:
2255         * inspector/JSInjectedScriptHost.cpp:
2256         (Inspector::JSInjectedScriptHost::subtype):
2257         (Inspector::JSInjectedScriptHost::getInternalProperties):
2258         (Inspector::JSInjectedScriptHost::iteratorEntries):
2259         * runtime/ArgumentsIteratorConstructor.cpp: Removed.
2260         * runtime/ArgumentsIteratorConstructor.h: Removed.
2261         * runtime/ArgumentsIteratorPrototype.cpp: Removed.
2262         * runtime/ArgumentsIteratorPrototype.h: Removed.
2263         * runtime/ArrayPrototype.cpp:
2264         (JSC::ArrayPrototype::finishCreation):
2265         * runtime/ArrayPrototype.h:
2266         * runtime/ClonedArguments.cpp:
2267         (JSC::ClonedArguments::getOwnPropertySlot):
2268         (JSC::ClonedArguments::put):
2269         (JSC::ClonedArguments::deleteProperty):
2270         (JSC::ClonedArguments::defineOwnProperty):
2271         (JSC::ClonedArguments::materializeSpecials):
2272         * runtime/ClonedArguments.h:
2273         * runtime/CommonIdentifiers.h:
2274         * runtime/DirectArguments.cpp:
2275         (JSC::DirectArguments::overrideThings):
2276         * runtime/GenericArgumentsInlines.h:
2277         (JSC::GenericArguments<Type>::getOwnPropertySlot):
2278         (JSC::GenericArguments<Type>::getOwnPropertyNames):
2279         (JSC::GenericArguments<Type>::put):
2280         (JSC::GenericArguments<Type>::deleteProperty):
2281         (JSC::GenericArguments<Type>::defineOwnProperty):
2282         * runtime/JSArgumentsIterator.cpp: Removed.
2283         * runtime/JSArgumentsIterator.h: Removed.
2284         * runtime/JSGlobalObject.cpp:
2285         (JSC::JSGlobalObject::init):
2286         (JSC::JSGlobalObject::visitChildren):
2287         * runtime/JSGlobalObject.h:
2288         (JSC::JSGlobalObject::arrayProtoValuesFunction):
2289         * runtime/MapPrototype.cpp:
2290         (JSC::MapPrototype::finishCreation):
2291         * runtime/ScopedArguments.cpp:
2292         (JSC::ScopedArguments::overrideThings):
2293         * runtime/SetPrototype.cpp:
2294         (JSC::SetPrototype::finishCreation):
2295         * tests/stress/arguments-iterator.js: Added.
2296         (test):
2297         (testArguments):
2298         * tests/stress/iterator-functions.js: Added.
2299         (test):
2300         (argumentsTests):
2301
2302 2015-04-14  Mark Lam  <mark.lam@apple.com>
2303
2304         Add JSC_functionOverrides=<overrides file> debugging tool.
2305         https://bugs.webkit.org/show_bug.cgi?id=143717
2306
2307         Reviewed by Geoffrey Garen.
2308
2309         This tool allows us to do runtime replacement of function bodies with alternatives
2310         for debugging purposes.  For example, this is useful when we need to debug VM bugs
2311         which manifest in scripts executing in webpages downloaded from remote servers
2312         that we don't control.  The tool allows us to augment those scripts with logging
2313         or test code to help isolate the bugs.
2314
2315         This tool works by substituting the SourceCode at FunctionExecutable creation
2316         time.  It identifies which SourceCode to substitute by comparing the source
2317         string against keys in a set of key value pairs.
2318
2319         The keys are function body strings defined by 'override' clauses in the overrides
2320         file specified by in the JSC_functionOverrides option.  The values are function
2321         body strings defines by 'with' clauses in the overrides file.
2322         See comment blob at top of FunctionOverrides.cpp on the formatting
2323         of the overrides file.
2324
2325         At FunctionExecutable creation time, if the SourceCode string matches one of the
2326         'override' keys from the overrides file, the tool will replace the SourceCode with
2327         a new one based on the corresponding 'with' value string.  The FunctionExecutable
2328         will then be created with the new SourceCode instead.
2329
2330         Some design decisions:
2331         1. We opted to require that the 'with' clause appear on a separate line than the
2332            'override' clause because this makes it easier to read and write when the
2333            'override' clause's function body is single lined and long.
2334
2335         2. The user can use any sequence of characters for the delimiter (except for '{',
2336            '}' and white space characters) because this ensures that there can always be
2337            some delimiter pattern that does not appear in the function body in the clause
2338            e.g. in the body of strings in the JS code.
2339
2340            '{' and '}' are disallowed because they are used to mark the boundaries of the
2341            function body string.  White space characters are disallowed because they can
2342            be error prone (the user may not be able to tell between spaces and tabs).
2343
2344         3. The start and end delimiter must be an identical sequence of characters.
2345
2346            I had considered allowing the use of complementary characters like <>, [], and
2347            () for making delimiter pairs like:
2348                [[[[ ... ]]]]
2349                <[([( ... )])]>
2350
2351            But in the end, decided against it because:
2352            a. These sequences of complementary characters can exists in JS code.
2353               In contrast, a repeating delimiter like %%%% is unlikely to appear in JS
2354               code.
2355            b. It can be error prone for the user to have to type the exact complement
2356               character for the end delimiter in reverse order.
2357               In contrast, a repeating delimiter like %%%% is much easier to type and
2358               less error prone.  Even a sequence like @#$%^ is less error prone than
2359               a complementary sequence because it can be copy-pasted, and need not be
2360               typed in reverse order.
2361            c. It is easier to parse for the same delimiter string for both start and end.
2362
2363         4. The tool does a lot of checks for syntax errors in the overrides file because
2364            we don't want any overrides to fail silently.  If a syntax error is detected,
2365            the tool will print an error message and call exit().  This avoids the user
2366            wasting time doing debugging only to be surprised later that their specified
2367            overrides did not take effect because of some unnoticed typo.
2368
2369         * CMakeLists.txt:
2370         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2371         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2372         * JavaScriptCore.xcodeproj/project.pbxproj:
2373         * bytecode/UnlinkedCodeBlock.cpp:
2374         (JSC::UnlinkedFunctionExecutable::link):
2375         * runtime/Executable.h:
2376         * runtime/Options.h:
2377         * tools/FunctionOverrides.cpp: Added.
2378         (JSC::FunctionOverrides::overrides):
2379         (JSC::FunctionOverrides::FunctionOverrides):
2380         (JSC::initializeOverrideInfo):
2381         (JSC::FunctionOverrides::initializeOverrideFor):
2382         (JSC::hasDisallowedCharacters):
2383         (JSC::parseClause):
2384         (JSC::FunctionOverrides::parseOverridesInFile):
2385         * tools/FunctionOverrides.h: Added.
2386
2387 2015-04-16  Basile Clement  <basile_clement@apple.com>
2388  
2389         Extract the allocation profile from JSFunction into a rare object
2390         https://bugs.webkit.org/show_bug.cgi?id=143807
2391  
2392         Reviewed by Filip Pizlo.
2393  
2394         The allocation profile is only needed for those functions that are used
2395         to create objects with [new].
2396         Extracting it into its own JSCell removes the need for JSFunction and
2397         JSCallee to be JSDestructibleObjects, which should improve performances in most
2398         cases at the cost of an extra pointer dereference when the allocation profile
2399         is actually needed.
2400  
2401         * CMakeLists.txt:
2402         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2403         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2404         * JavaScriptCore.xcodeproj/project.pbxproj:
2405         * dfg/DFGOperations.cpp:
2406         * dfg/DFGSpeculativeJIT32_64.cpp:
2407         (JSC::DFG::SpeculativeJIT::compile):
2408         * dfg/DFGSpeculativeJIT64.cpp:
2409         (JSC::DFG::SpeculativeJIT::compile):
2410         * jit/JITOpcodes.cpp:
2411         (JSC::JIT::emit_op_create_this):
2412         * jit/JITOpcodes32_64.cpp:
2413         (JSC::JIT::emit_op_create_this):
2414         * llint/LowLevelInterpreter32_64.asm:
2415         * llint/LowLevelInterpreter64.asm:
2416         * runtime/CommonSlowPaths.cpp:
2417         (JSC::SLOW_PATH_DECL):
2418         * runtime/FunctionRareData.cpp: Added.
2419         (JSC::FunctionRareData::create):
2420         (JSC::FunctionRareData::destroy):
2421         (JSC::FunctionRareData::createStructure):
2422         (JSC::FunctionRareData::visitChildren):
2423         (JSC::FunctionRareData::FunctionRareData):
2424         (JSC::FunctionRareData::~FunctionRareData):
2425         (JSC::FunctionRareData::finishCreation):
2426         * runtime/FunctionRareData.h: Added.
2427         (JSC::FunctionRareData::offsetOfAllocationProfile):
2428         (JSC::FunctionRareData::allocationProfile):
2429         (JSC::FunctionRareData::allocationStructure):
2430         (JSC::FunctionRareData::allocationProfileWatchpointSet):
2431         * runtime/JSBoundFunction.cpp:
2432         (JSC::JSBoundFunction::destroy): Deleted.
2433         * runtime/JSBoundFunction.h:
2434         * runtime/JSCallee.cpp:
2435         (JSC::JSCallee::destroy): Deleted.
2436         * runtime/JSCallee.h:
2437         * runtime/JSFunction.cpp:
2438         (JSC::JSFunction::JSFunction):
2439         (JSC::JSFunction::createRareData):
2440         (JSC::JSFunction::visitChildren):
2441         (JSC::JSFunction::put):
2442         (JSC::JSFunction::defineOwnProperty):
2443         (JSC::JSFunction::destroy): Deleted.
2444         (JSC::JSFunction::createAllocationProfile): Deleted.
2445         * runtime/JSFunction.h:
2446         (JSC::JSFunction::offsetOfRareData):
2447         (JSC::JSFunction::rareData):
2448         (JSC::JSFunction::allocationStructure):
2449         (JSC::JSFunction::allocationProfileWatchpointSet):
2450         (JSC::JSFunction::offsetOfAllocationProfile): Deleted.
2451         (JSC::JSFunction::allocationProfile): Deleted.
2452         * runtime/JSFunctionInlines.h:
2453         (JSC::JSFunction::JSFunction):
2454         * runtime/VM.cpp:
2455         (JSC::VM::VM):
2456         * runtime/VM.h:
2457  
2458 2015-04-16  Csaba Osztrogon√°c  <ossy@webkit.org>
2459
2460         Remove the unnecessary WTF_CHANGES define
2461         https://bugs.webkit.org/show_bug.cgi?id=143825
2462
2463         Reviewed by Andreas Kling.
2464
2465         * config.h:
2466
2467 2015-04-15  Andreas Kling  <akling@apple.com>
2468
2469         Make MarkedBlock and WeakBlock 4x smaller.
2470         <https://webkit.org/b/143802>
2471
2472         Reviewed by Mark Hahnenberg.
2473
2474         To reduce GC heap fragmentation and generally use less memory, reduce the size of MarkedBlock
2475         and its buddy WeakBlock by 4x, bringing them from 64kB+4kB to 16kB+1kB.
2476
2477         In a sampling of cool web sites, I'm seeing ~8% average reduction in overall GC heap size.
2478         Some examples:
2479
2480                    apple.com:  6.3MB ->  5.5MB (14.5% smaller)
2481                   reddit.com:  4.5MB ->  4.1MB ( 9.7% smaller)
2482                  twitter.com: 23.2MB -> 21.4MB ( 8.4% smaller)
2483             cuteoverload.com: 24.5MB -> 23.6MB ( 3.8% smaller)
2484
2485         Benchmarks look mostly neutral.
2486         Some small slowdowns on Octane, some slightly bigger speedups on Kraken and SunSpider.
2487
2488         * heap/MarkedBlock.h:
2489         * heap/WeakBlock.h:
2490         * llint/LLIntData.cpp:
2491         (JSC::LLInt::Data::performAssertions):
2492         * llint/LowLevelInterpreter.asm:
2493
2494 2015-04-15  Jordan Harband  <ljharb@gmail.com>
2495
2496         String.prototype.startsWith/endsWith/includes have wrong length in r182673
2497         https://bugs.webkit.org/show_bug.cgi?id=143659
2498
2499         Reviewed by Benjamin Poulain.
2500
2501         Fix lengths of String.prototype.{includes,startsWith,endsWith} per spec
2502         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
2503         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
2504         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
2505
2506         * runtime/StringPrototype.cpp:
2507         (JSC::StringPrototype::finishCreation):
2508
2509 2015-04-15  Mark Lam  <mark.lam@apple.com>
2510
2511         Remove obsolete VMInspector debugging tool.
2512         https://bugs.webkit.org/show_bug.cgi?id=143798
2513
2514         Reviewed by Michael Saboff.
2515
2516         I added the VMInspector tool 3 years ago to aid in VM hacking work.  Some of it
2517         has bit rotted, and now the VM also has better ways to achieve its functionality.
2518         Hence this code is now obsolete and should be removed.
2519
2520         * CMakeLists.txt:
2521         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2522         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2523         * JavaScriptCore.xcodeproj/project.pbxproj:
2524         * interpreter/CallFrame.h:
2525         * interpreter/VMInspector.cpp: Removed.
2526         * interpreter/VMInspector.h: Removed.
2527         * llint/LowLevelInterpreter.cpp:
2528
2529 2015-04-15  Jordan Harband  <ljharb@gmail.com>
2530
2531         Math.imul has wrong length in Safari 8.0.4
2532         https://bugs.webkit.org/show_bug.cgi?id=143658
2533
2534         Reviewed by Benjamin Poulain.
2535
2536         Correcting function length from 1, to 2, to match spec
2537         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.imul
2538
2539         * runtime/MathObject.cpp:
2540         (JSC::MathObject::finishCreation):
2541
2542 2015-04-15  Jordan Harband  <ljharb@gmail.com>
2543
2544         Number.parseInt in nightly r182673 has wrong length
2545         https://bugs.webkit.org/show_bug.cgi?id=143657
2546
2547         Reviewed by Benjamin Poulain.
2548
2549         Correcting function length from 1, to 2, to match spec
2550         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
2551
2552         * runtime/NumberConstructor.cpp:
2553         (JSC::NumberConstructor::finishCreation):
2554
2555 2015-04-15  Filip Pizlo  <fpizlo@apple.com>
2556
2557         Harden DFGForAllKills
2558         https://bugs.webkit.org/show_bug.cgi?id=143792
2559
2560         Reviewed by Geoffrey Garen.
2561         
2562         Unfortunately, we don't have a good way to test this yet - but it will be needed to prevent
2563         bugs in https://bugs.webkit.org/show_bug.cgi?id=143734.
2564         
2565         Previously ForAllKills used the bytecode kill analysis. That seemed like a good idea because
2566         that analysis is cheaper than the full liveness analysis. Unfortunately, it's probably wrong:
2567         
2568         - It looks for kill sites at forExit origin boundaries. But, something might have been killed
2569           by an operation that was logically in between the forExit origins at the boundary, but was
2570           removed from the DFG for whatever reason. The DFG is allowed to have bytecode instruction
2571           gaps.
2572         
2573         - It overlooked the fact that a MovHint that addresses a local that is always live kills that
2574           local. For example, storing to an argument means that the prior value of the argument is
2575           killed.
2576         
2577         This fixes the analysis by making it handle MovHints directly, and making it define kills in
2578         the most conservative way possible: it asks if you were live before but dead after. If we
2579         have the compile time budget to afford this more direct approach, then it's definitel a good
2580         idea since it's so fool-proof.
2581
2582         * dfg/DFGArgumentsEliminationPhase.cpp:
2583         * dfg/DFGForAllKills.h:
2584         (JSC::DFG::forAllKilledOperands):
2585         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2586         (JSC::DFG::forAllDirectlyKilledOperands): Deleted.
2587
2588 2015-04-15  Joseph Pecoraro  <pecoraro@apple.com>
2589
2590         Provide SPI to allow changing whether JSContexts are remote debuggable by default
2591         https://bugs.webkit.org/show_bug.cgi?id=143681
2592
2593         Reviewed by Darin Adler.
2594
2595         * API/JSRemoteInspector.h:
2596         * API/JSRemoteInspector.cpp:
2597         (JSRemoteInspectorGetInspectionEnabledByDefault):
2598         (JSRemoteInspectorSetInspectionEnabledByDefault):
2599         Provide SPI to toggle the default enabled inspection state of debuggables.
2600
2601         * API/JSContextRef.cpp:
2602         (JSGlobalContextCreateInGroup):
2603         Respect the default setting.
2604
2605 2015-04-15  Joseph Pecoraro  <pecoraro@apple.com>
2606
2607         JavaScriptCore: Use kCFAllocatorDefault where possible
2608         https://bugs.webkit.org/show_bug.cgi?id=143747
2609
2610         Reviewed by Darin Adler.
2611
2612         * heap/HeapTimer.cpp:
2613         (JSC::HeapTimer::HeapTimer):
2614         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
2615         (Inspector::RemoteInspectorInitializeGlobalQueue):
2616         (Inspector::RemoteInspectorDebuggableConnection::setupRunLoop):
2617         For consistency and readability use the constant instead of
2618         different representations of null.
2619
2620 2015-04-14  Michael Saboff  <msaboff@apple.com>
2621
2622         Remove JavaScriptCoreUseJIT default from JavaScriptCore
2623         https://bugs.webkit.org/show_bug.cgi?id=143746
2624
2625         Reviewed by Mark Lam.
2626
2627         * runtime/VM.cpp:
2628         (JSC::enableAssembler):
2629
2630 2015-04-14  Chris Dumez  <cdumez@apple.com>
2631
2632         Regression(r180020): Web Inspector crashes on pages that have a stylesheet with an invalid MIME type
2633         https://bugs.webkit.org/show_bug.cgi?id=143745
2634         <rdar://problem/20243916>
2635
2636         Reviewed by Joseph Pecoraro.
2637
2638         Add assertion in ContentSearchUtilities::findMagicComment() to make
2639         sure the content String is not null or we would crash in
2640         JSC::Yarr::interpret() later.
2641
2642         * inspector/ContentSearchUtilities.cpp:
2643         (Inspector::ContentSearchUtilities::findMagicComment):
2644
2645 2015-04-14  Michael Saboff  <msaboff@apple.com>
2646
2647         DFG register fillSpeculate*() functions should validate incoming spill format is compatible with requested fill format
2648         https://bugs.webkit.org/show_bug.cgi?id=143727
2649
2650         Reviewed by Geoffrey Garen.
2651
2652         Used the result of AbstractInterpreter<>::filter() to check that the current spill format is compatible
2653         with the requested fill format.  If filter() reports a contradiction, then we force an OSR exit.
2654         Removed individual checks made redundant by the new check.
2655
2656         * dfg/DFGSpeculativeJIT32_64.cpp:
2657         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2658         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2659         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2660         * dfg/DFGSpeculativeJIT64.cpp:
2661         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2662         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
2663         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2664         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2665
2666 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2667
2668         Replace JavaScriptCoreOutputConsoleMessagesToSystemConsole default with an SPI
2669         https://bugs.webkit.org/show_bug.cgi?id=143691
2670
2671         Reviewed by Geoffrey Garen.
2672
2673         * API/JSRemoteInspector.h:
2674         * API/JSRemoteInspector.cpp:
2675         (JSRemoteInspectorSetLogToSystemConsole):
2676         Add SPI to enable/disable logging to the system console.
2677         This only affects JSContext `console` logs and warnings.
2678
2679         * inspector/JSGlobalObjectConsoleClient.h:
2680         * inspector/JSGlobalObjectConsoleClient.cpp:
2681         (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
2682         (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
2683         (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
2684         (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole): Deleted.
2685         Simplify access to the setting now that it doesn't need to
2686         initialize its value from preferences.
2687
2688 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2689
2690         Web Inspector: Auto-attach fails after r179562, initialization too late after dispatch
2691         https://bugs.webkit.org/show_bug.cgi?id=143682
2692
2693         Reviewed by Timothy Hatcher.
2694
2695         * inspector/remote/RemoteInspector.mm:
2696         (Inspector::RemoteInspector::singleton):
2697         If we are on the main thread, run the initialization immediately.
2698         Otherwise dispatch to the main thread. This way if the first JSContext
2699         was created on the main thread it can get auto-attached if applicable.
2700
2701 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2702
2703         Unreviewed build fix for Mavericks.
2704
2705         Mavericks includes this file but does not enable ENABLE_REMOTE_INSPECTOR
2706         so the Inspector namespace is not available when compiling this file.
2707
2708         * API/JSRemoteInspector.cpp:
2709
2710 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2711
2712         Web Inspector: Expose private APIs to interact with RemoteInspector instead of going through WebKit
2713         https://bugs.webkit.org/show_bug.cgi?id=143729
2714
2715         Reviewed by Timothy Hatcher.
2716
2717         * API/JSRemoteInspector.h: Added.
2718         * API/JSRemoteInspector.cpp: Added.
2719         (JSRemoteInspectorDisableAutoStart):
2720         (JSRemoteInspectorStart):
2721         (JSRemoteInspectorSetParentProcessInformation):
2722         Add the new SPIs for basic remote inspection behavior.
2723
2724         * JavaScriptCore.xcodeproj/project.pbxproj:
2725         Add the new files to Mac only, since remote inspection is only
2726         enabled there anyways.
2727
2728 2015-04-14  Mark Lam  <mark.lam@apple.com>
2729
2730         Rename JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist.
2731         https://bugs.webkit.org/show_bug.cgi?id=143722
2732
2733         Reviewed by Michael Saboff.
2734
2735         Renaming JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist so that it is
2736         shorter, and easier to remember (without having to look it up) and to
2737         type.  JSC options now support descriptions, and one can always look up
2738         the description if the option's purpose is not already obvious.
2739
2740         * dfg/DFGFunctionWhitelist.cpp:
2741         (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist):
2742         (JSC::DFG::FunctionWhitelist::contains):
2743         * runtime/Options.h:
2744
2745 2015-04-13  Filip Pizlo  <fpizlo@apple.com>
2746
2747         Unreviewed, fix Windows build. Windows doesn't take kindly to private classes that use FAST_ALLOCATED.
2748
2749         * runtime/InferredValue.h:
2750
2751 2015-04-13  Filip Pizlo  <fpizlo@apple.com>
2752
2753         Unreviewed, fix build. I introduced a new cell type at the same time as kling changed how new cell types are written.
2754
2755         * runtime/InferredValue.h:
2756
2757 2015-04-08  Filip Pizlo  <fpizlo@apple.com>
2758
2759         JSC should detect singleton functions
2760         https://bugs.webkit.org/show_bug.cgi?id=143232
2761
2762         Reviewed by Geoffrey Garen.
2763         
2764         This started out as an attempt to make constructors faster by detecting when a constructor is a
2765         singleton. The idea is that each FunctionExecutable has a VariableWatchpointSet - a watchpoint
2766         along with an inferred value - that detects if only one JSFunction has been allocated for that
2767         executable, and if so, what that JSFunction is. Then, inside the code for the FunctionExecutable,
2768         if the watchpoint set has an inferred value (i.e. it's been initialized and it is still valid),
2769         we can constant-fold GetCallee.
2770         
2771         Unfortunately, constructors don't use GetCallee anymore, so that didn't pan out. But in the
2772         process I realized a bunch of things:
2773         
2774         - This allows us to completely eliminate the GetCallee/GetScope sequence that we still sometimes
2775           had even in code where our singleton-closure detection worked. That's because singleton-closure
2776           inference worked at the op_resolve_scope, and that op_resolve_scope still needed to keep alive
2777           the incoming scope in case we OSR exit. But by constant-folding GetCallee, that sequence
2778           disappears. OSR exit can rematerialize the callee or the scope by just knowing their constant
2779           values.
2780           
2781         - Singleton detection should be a reusable thing. So, I got rid of VariableWatchpointSet and
2782           created InferredValue. InferredValue is a cell, so it can handle its own GC magic.
2783           FunctionExecutable uses an InferredValue to tell you about singleton JSFunctions.
2784         
2785         - The old singleton-scope detection in op_resolve_scope is better abstracted as a SymbolTable
2786           detecting a singleton JSSymbolTableObject. So, SymbolTable uses an InferredValue to tell you
2787           about singleton JSSymbolTableObjects. It's curious that we want to have singleton detection in
2788           SymbolTable if we already have it in FunctionExecutable. This comes into play in two ways.
2789           First, it means that the DFG can realize sooner that a resolve_scope resolves to a constant
2790           scope. Ths saves compile times and it allows prediction propagation to benefit from the
2791           constant folding. Second, it means that we will detect a singleton scope even if it is
2792           referenced from a non-singleton scope that is nearer to us in the scope chain. This refactoring
2793           allows us to eliminate the function reentry watchpoint.
2794         
2795         - This allows us to use a normal WatchpointSet, instead of a VariableWatchpointSet, for inferring
2796           constant values in scopes. Previously when the DFG inferred that a closure variable was
2797           constant, it wouldn't know which closure that variable was in and so it couldn't just load that
2798           value. But now we are first inferring that the function is a singleton, which means that we
2799           know exactly what scope it points to, and we can load the value from the scope. Using a
2800           WatchpointSet instead of a VariableWatchpointSet saves some memory and simplifies a bunch of
2801           code. This also means that now, the only user of VariableWatchpointSet is FunctionExecutable.
2802           I've tweaked the code of VariableWatchpointSet to reduce its power to just be what
2803           FunctionExecutable wants.
2804         
2805         This also has the effect of simplifying the implementation of block scoping. Prior to this
2806         change, block scoping would have needed to have some story for the function reentry watchpoint on
2807         any nested symbol table. That's totally weird to think about; it's not really a function reentry
2808         but a scope reentry. Now we don't have to think about this. Constant inference on nested scopes
2809         will "just work": if we prove that we know the constant value of the scope then the machinery
2810         kicks in, otherwise it doesn't.
2811         
2812         This is a small Octane and AsmBench speed-up. AsmBench sees 1% while Octane sees sub-1%.
2813
2814         * CMakeLists.txt:
2815         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2816         * JavaScriptCore.xcodeproj/project.pbxproj:
2817         * bytecode/BytecodeList.json:
2818         * bytecode/BytecodeUseDef.h:
2819         (JSC::computeUsesForBytecodeOffset):
2820         (JSC::computeDefsForBytecodeOffset):
2821         * bytecode/CodeBlock.cpp:
2822         (JSC::CodeBlock::dumpBytecode):
2823         (JSC::CodeBlock::CodeBlock):
2824         (JSC::CodeBlock::finalizeUnconditionally):
2825         (JSC::CodeBlock::valueProfileForBytecodeOffset):
2826         * bytecode/CodeBlock.h:
2827         (JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
2828         * bytecode/CodeOrigin.cpp:
2829         (JSC::InlineCallFrame::calleeConstant):
2830         (JSC::InlineCallFrame::visitAggregate):
2831         * bytecode/CodeOrigin.h:
2832         (JSC::InlineCallFrame::calleeConstant): Deleted.
2833         (JSC::InlineCallFrame::visitAggregate): Deleted.
2834         * bytecode/Instruction.h:
2835         * bytecode/VariableWatchpointSet.cpp: Removed.
2836         * bytecode/VariableWatchpointSet.h: Removed.
2837         * bytecode/VariableWatchpointSetInlines.h: Removed.
2838         * bytecode/VariableWriteFireDetail.cpp: Added.
2839         (JSC::VariableWriteFireDetail::dump):
2840         (JSC::VariableWriteFireDetail::touch):
2841         * bytecode/VariableWriteFireDetail.h: Added.
2842         (JSC::VariableWriteFireDetail::VariableWriteFireDetail):
2843         * bytecode/Watchpoint.h:
2844         (JSC::WatchpointSet::stateOnJSThread):
2845         (JSC::WatchpointSet::startWatching):
2846         (JSC::WatchpointSet::fireAll):
2847         (JSC::WatchpointSet::touch):
2848         (JSC::WatchpointSet::invalidate):
2849         (JSC::InlineWatchpointSet::stateOnJSThread):
2850         (JSC::InlineWatchpointSet::state):
2851         (JSC::InlineWatchpointSet::hasBeenInvalidated):
2852         (JSC::InlineWatchpointSet::invalidate):
2853         (JSC::InlineWatchpointSet::touch):
2854         * bytecompiler/BytecodeGenerator.cpp:
2855         (JSC::BytecodeGenerator::BytecodeGenerator):
2856         * dfg/DFGAbstractInterpreterInlines.h:
2857         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2858         * dfg/DFGByteCodeParser.cpp:
2859         (JSC::DFG::ByteCodeParser::get):
2860         (JSC::DFG::ByteCodeParser::parseBlock):
2861         (JSC::DFG::ByteCodeParser::getScope): Deleted.
2862         * dfg/DFGCapabilities.cpp:
2863         (JSC::DFG::capabilityLevel):
2864         * dfg/DFGClobberize.h:
2865         (JSC::DFG::clobberize):
2866         * dfg/DFGDesiredWatchpoints.cpp:
2867         (JSC::DFG::InferredValueAdaptor::add):
2868         (JSC::DFG::DesiredWatchpoints::addLazily):
2869         (JSC::DFG::DesiredWatchpoints::reallyAdd):
2870         (JSC::DFG::DesiredWatchpoints::areStillValid):
2871         * dfg/DFGDesiredWatchpoints.h:
2872         (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
2873         (JSC::DFG::DesiredWatchpoints::isWatched):
2874         * dfg/DFGGraph.cpp:
2875         (JSC::DFG::Graph::dump):
2876         (JSC::DFG::Graph::tryGetConstantClosureVar):
2877         * dfg/DFGNode.h:
2878         (JSC::DFG::Node::hasWatchpointSet):
2879         (JSC::DFG::Node::watchpointSet):
2880         (JSC::DFG::Node::hasVariableWatchpointSet): Deleted.
2881         (JSC::DFG::Node::variableWatchpointSet): Deleted.
2882         * dfg/DFGOperations.cpp:
2883         * dfg/DFGOperations.h:
2884         * dfg/DFGSpeculativeJIT.cpp:
2885         (JSC::DFG::SpeculativeJIT::compileNewFunction):
2886         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
2887         (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
2888         * dfg/DFGSpeculativeJIT.h:
2889         (JSC::DFG::SpeculativeJIT::callOperation):
2890         * dfg/DFGSpeculativeJIT32_64.cpp:
2891         (JSC::DFG::SpeculativeJIT::compile):
2892         * dfg/DFGSpeculativeJIT64.cpp:
2893         (JSC::DFG::SpeculativeJIT::compile):
2894         * dfg/DFGVarargsForwardingPhase.cpp:
2895         * ftl/FTLIntrinsicRepository.h:
2896         * ftl/FTLLowerDFGToLLVM.cpp:
2897         (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
2898         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
2899         (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
2900         * interpreter/Interpreter.cpp:
2901         (JSC::StackFrame::friendlySourceURL):
2902         (JSC::StackFrame::friendlyFunctionName):
2903         * interpreter/Interpreter.h:
2904         (JSC::StackFrame::friendlySourceURL): Deleted.
2905         (JSC::StackFrame::friendlyFunctionName): Deleted.
2906         * jit/JIT.cpp:
2907         (JSC::JIT::emitNotifyWrite):
2908         (JSC::JIT::privateCompileMainPass):
2909         * jit/JIT.h:
2910         * jit/JITOpcodes.cpp:
2911         (JSC::JIT::emit_op_touch_entry): Deleted.
2912         * jit/JITOperations.cpp:
2913         * jit/JITOperations.h:
2914         * jit/JITPropertyAccess.cpp:
2915         (JSC::JIT::emitPutGlobalVar):
2916         (JSC::JIT::emitPutClosureVar):
2917         (JSC::JIT::emitNotifyWrite): Deleted.
2918         * jit/JITPropertyAccess32_64.cpp:
2919         (JSC::JIT::emitPutGlobalVar):
2920         (JSC::JIT::emitPutClosureVar):
2921         (JSC::JIT::emitNotifyWrite): Deleted.
2922         * llint/LLIntSlowPaths.cpp:
2923         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2924         * llint/LowLevelInterpreter.asm:
2925         * llint/LowLevelInterpreter32_64.asm:
2926         * llint/LowLevelInterpreter64.asm:
2927         * runtime/CommonSlowPaths.cpp:
2928         (JSC::SLOW_PATH_DECL): Deleted.
2929         * runtime/CommonSlowPaths.h:
2930         * runtime/Executable.cpp:
2931         (JSC::FunctionExecutable::finishCreation):
2932         (JSC::FunctionExecutable::visitChildren):
2933         * runtime/Executable.h:
2934         (JSC::FunctionExecutable::singletonFunction):
2935         * runtime/InferredValue.cpp: Added.
2936         (JSC::InferredValue::create):
2937         (JSC::InferredValue::destroy):
2938         (JSC::InferredValue::createStructure):
2939         (JSC::InferredValue::visitChildren):
2940         (JSC::InferredValue::InferredValue):
2941         (JSC::InferredValue::~InferredValue):
2942         (JSC::InferredValue::notifyWriteSlow):
2943         (JSC::InferredValue::ValueCleanup::ValueCleanup):
2944         (JSC::InferredValue::ValueCleanup::~ValueCleanup):
2945         (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
2946         * runtime/InferredValue.h: Added.
2947         (JSC::InferredValue::inferredValue):
2948         (JSC::InferredValue::state):
2949         (JSC::InferredValue::isStillValid):
2950         (JSC::InferredValue::hasBeenInvalidated):
2951         (JSC::InferredValue::add):
2952         (JSC::InferredValue::notifyWrite):
2953         (JSC::InferredValue::invalidate):
2954         * runtime/JSEnvironmentRecord.cpp:
2955         (JSC::JSEnvironmentRecord::visitChildren):
2956         * runtime/JSEnvironmentRecord.h:
2957         (JSC::JSEnvironmentRecord::isValid):
2958         (JSC::JSEnvironmentRecord::finishCreation):
2959         * runtime/JSFunction.cpp:
2960         (JSC::JSFunction::create):
2961         * runtime/JSFunction.h:
2962         (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
2963         (JSC::JSFunction::createImpl):
2964         (JSC::JSFunction::create): Deleted.
2965         * runtime/JSGlobalObject.cpp:
2966         (JSC::JSGlobalObject::addGlobalVar):
2967         (JSC::JSGlobalObject::addFunction):
2968         * runtime/JSGlobalObject.h:
2969         * runtime/JSLexicalEnvironment.cpp:
2970         (JSC::JSLexicalEnvironment::symbolTablePut):
2971         * runtime/JSScope.h:
2972         (JSC::ResolveOp::ResolveOp):
2973         * runtime/JSSegmentedVariableObject.h:
2974         (JSC::JSSegmentedVariableObject::finishCreation):
2975         * runtime/JSSymbolTableObject.h:
2976         (JSC::JSSymbolTableObject::JSSymbolTableObject):
2977         (JSC::JSSymbolTableObject::setSymbolTable):
2978         (JSC::symbolTablePut):
2979         (JSC::symbolTablePutWithAttributes):
2980         * runtime/PutPropertySlot.h:
2981         * runtime/SymbolTable.cpp:
2982         (JSC::SymbolTableEntry::prepareToWatch):
2983         (JSC::SymbolTable::SymbolTable):
2984         (JSC::SymbolTable::finishCreation):
2985         (JSC::SymbolTable::visitChildren):
2986         (JSC::SymbolTableEntry::inferredValue): Deleted.
2987         (JSC::SymbolTableEntry::notifyWriteSlow): Deleted.
2988         (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): Deleted.
2989         (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): Deleted.
2990         (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): Deleted.
2991         * runtime/SymbolTable.h:
2992         (JSC::SymbolTableEntry::disableWatching):
2993         (JSC::SymbolTableEntry::watchpointSet):
2994         (JSC::SymbolTable::singletonScope):
2995         (JSC::SymbolTableEntry::notifyWrite): Deleted.
2996         * runtime/TypeProfiler.cpp:
2997         * runtime/VM.cpp:
2998         (JSC::VM::VM):
2999         * runtime/VM.h:
3000         * tests/stress/infer-uninitialized-closure-var.js: Added.
3001         (foo.f):
3002         (foo):
3003         * tests/stress/singleton-scope-then-overwrite.js: Added.
3004         (foo.f):
3005         (foo):
3006         * tests/stress/singleton-scope-then-realloc-and-overwrite.js: Added.
3007         (foo):
3008         * tests/stress/singleton-scope-then-realloc.js: Added.
3009         (foo):
3010
3011 2015-04-13  Andreas Kling  <akling@apple.com>
3012
3013         Don't segregate heap objects based on Structure immortality.
3014         <https://webkit.org/b/143638>
3015
3016         Reviewed by Darin Adler.
3017
3018         Put all objects that need a destructor call into the same MarkedBlock.
3019         This reduces memory consumption in many situations, while improving locality,
3020         since much more of the MarkedBlock space can be shared.
3021
3022         Instead of branching on the MarkedBlock type, we now check a bit in the
3023         JSCell's inline type flags (StructureIsImmortal) to see whether it's safe
3024         to access the cell's Structure during destruction or not.
3025
3026         Performance benchmarks look mostly neutral. Maybe a small regression on
3027         SunSpider's date objects.
3028
3029         On the amazon.com landing page, this saves us 50 MarkedBlocks (3200kB) along
3030         with a bunch of WeakBlocks that were hanging off of them. That's on the higher
3031         end of savings we can get from this, but still a very real improvement.
3032
3033         Most of this patch is removing the "hasImmortalStructure" constant from JSCell
3034         derived classes and passing that responsibility to the StructureIsImmortal flag.
3035         StructureFlags is made public so that it's accessible from non-member functions.
3036         I made sure to declare it everywhere and make classes final to try to make it
3037         explicit what each class is doing to its inherited flags.
3038
3039         * API/JSCallbackConstructor.h:
3040         * API/JSCallbackObject.h:
3041         * bytecode/UnlinkedCodeBlock.h:
3042         * debugger/DebuggerScope.h:
3043         * dfg/DFGSpeculativeJIT.cpp:
3044         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3045         * ftl/FTLLowerDFGToLLVM.cpp:
3046         (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
3047         * heap/Heap.h:
3048         (JSC::Heap::subspaceForObjectDestructor):
3049         (JSC::Heap::allocatorForObjectWithDestructor):
3050         (JSC::Heap::subspaceForObjectNormalDestructor): Deleted.
3051         (JSC::Heap::subspaceForObjectsWithImmortalStructure): Deleted.
3052         (JSC::Heap::allocatorForObjectWithNormalDestructor): Deleted.
3053         (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): Deleted.
3054         * heap/HeapInlines.h:
3055         (JSC::Heap::allocateWithDestructor):
3056         (JSC::Heap::allocateObjectOfType):
3057         (JSC::Heap::subspaceForObjectOfType):
3058         (JSC::Heap::allocatorForObjectOfType):
3059         (JSC::Heap::allocateWithNormalDestructor): Deleted.
3060         (JSC::Heap::allocateWithImmortalStructureDestructor): Deleted.
3061         * heap/MarkedAllocator.cpp:
3062         (JSC::MarkedAllocator::allocateBlock):
3063         * heap/MarkedAllocator.h:
3064         (JSC::MarkedAllocator::needsDestruction):
3065         (JSC::MarkedAllocator::MarkedAllocator):
3066         (JSC::MarkedAllocator::init):
3067         (JSC::MarkedAllocator::destructorType): Deleted.
3068         * heap/MarkedBlock.cpp:
3069         (JSC::MarkedBlock::create):
3070         (JSC::MarkedBlock::MarkedBlock):
3071         (JSC::MarkedBlock::callDestructor):
3072         (JSC::MarkedBlock::specializedSweep):
3073         (JSC::MarkedBlock::sweep):
3074         (JSC::MarkedBlock::sweepHelper):
3075         * heap/MarkedBlock.h:
3076         (JSC::MarkedBlock::needsDestruction):
3077         (JSC::MarkedBlock::destructorType): Deleted.
3078         * heap/MarkedSpace.cpp:
3079         (JSC::MarkedSpace::MarkedSpace):
3080         (JSC::MarkedSpace::resetAllocators):
3081         (JSC::MarkedSpace::forEachAllocator):
3082         (JSC::MarkedSpace::isPagedOut):
3083         (JSC::MarkedSpace::clearNewlyAllocated):
3084         * heap/MarkedSpace.h:
3085         (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
3086         (JSC::MarkedSpace::destructorAllocatorFor):
3087         (JSC::MarkedSpace::allocateWithDestructor):
3088         (JSC::MarkedSpace::forEachBlock):
3089         (JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor): Deleted.
3090         (JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure): Deleted.
3091         (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): Deleted.
3092         (JSC::MarkedSpace::normalDestructorAllocatorFor): Deleted.
3093         (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): Deleted.
3094         (JSC::MarkedSpace::allocateWithNormalDestructor): Deleted.
3095         * inspector/JSInjectedScriptHost.h:
3096         * inspector/JSInjectedScriptHostPrototype.h:
3097         * inspector/JSJavaScriptCallFrame.h:
3098         * inspector/JSJavaScriptCallFramePrototype.h:
3099         * jsc.cpp:
3100         * runtime/ArrayBufferNeuteringWatchpoint.h:
3101         * runtime/ArrayConstructor.h:
3102         * runtime/ArrayIteratorPrototype.h:
3103         * runtime/BooleanPrototype.h:
3104         * runtime/ClonedArguments.h:
3105         * runtime/CustomGetterSetter.h:
3106         * runtime/DateConstructor.h:
3107         * runtime/DatePrototype.h:
3108         * runtime/ErrorPrototype.h:
3109         * runtime/ExceptionHelpers.h:
3110         * runtime/Executable.h:
3111         * runtime/GenericArguments.h:
3112         * runtime/GetterSetter.h:
3113         * runtime/InternalFunction.h:
3114         * runtime/JSAPIValueWrapper.h:
3115         * runtime/JSArgumentsIterator.h:
3116         * runtime/JSArray.h:
3117         * runtime/JSArrayBuffer.h:
3118         * runtime/JSArrayBufferView.h:
3119         * runtime/JSBoundFunction.h:
3120         * runtime/JSCallee.h:
3121         * runtime/JSCell.h:
3122         * runtime/JSCellInlines.h:
3123         (JSC::JSCell::classInfo):
3124         * runtime/JSDataViewPrototype.h:
3125         * runtime/JSEnvironmentRecord.h:
3126         * runtime/JSFunction.h:
3127         * runtime/JSGenericTypedArrayView.h:
3128         * runtime/JSGlobalObject.h:
3129         * runtime/JSLexicalEnvironment.h:
3130         * runtime/JSNameScope.h:
3131         * runtime/JSNotAnObject.h:
3132         * runtime/JSONObject.h:
3133         * runtime/JSObject.h:
3134         (JSC::JSFinalObject::JSFinalObject):
3135         * runtime/JSPromiseConstructor.h:
3136         * runtime/JSPromiseDeferred.h:
3137         * runtime/JSPromisePrototype.h:
3138         * runtime/JSPromiseReaction.h:
3139         * runtime/JSPropertyNameEnumerator.h:
3140         * runtime/JSProxy.h:
3141         * runtime/JSScope.h:
3142         * runtime/JSString.h:
3143         * runtime/JSSymbolTableObject.h:
3144         * runtime/JSTypeInfo.h:
3145         (JSC::TypeInfo::structureIsImmortal):
3146         * runtime/MathObject.h:
3147         * runtime/NumberConstructor.h:
3148         * runtime/NumberPrototype.h:
3149         * runtime/ObjectConstructor.h:
3150         * runtime/PropertyMapHashTable.h:
3151         * runtime/RegExp.h:
3152         * runtime/RegExpConstructor.h:
3153         * runtime/RegExpObject.h:
3154         * runtime/RegExpPrototype.h:
3155         * runtime/ScopedArgumentsTable.h:
3156         * runtime/SparseArrayValueMap.h:
3157         * runtime/StrictEvalActivation.h:
3158         * runtime/StringConstructor.h:
3159         * runtime/StringIteratorPrototype.h:
3160         * runtime/StringObject.h:
3161         * runtime/StringPrototype.h:
3162         * runtime/Structure.cpp:
3163         (JSC::Structure::Structure):
3164         * runtime/Structure.h:
3165         * runtime/StructureChain.h:
3166         * runtime/StructureRareData.h:
3167         * runtime/Symbol.h:
3168         * runtime/SymbolPrototype.h:
3169         * runtime/SymbolTable.h:
3170         * runtime/WeakMapData.h:
3171
3172 2015-04-13  Mark Lam  <mark.lam@apple.com>
3173
3174         DFG inlining of op_call_varargs should keep the callee alive in case of OSR exit.
3175         https://bugs.webkit.org/show_bug.cgi?id=143407
3176
3177         Reviewed by Filip Pizlo.
3178
3179         DFG inlining of a varargs call / construct needs to keep the local
3180         containing the callee alive with a Phantom node because the LoadVarargs
3181         node may OSR exit.  After the OSR exit, the baseline JIT executes the
3182         op_call_varargs with that callee in the local.
3183
3184         Previously, because that callee local was not explicitly kept alive,
3185         the op_call_varargs case can OSR exit a DFG function and leave an
3186         undefined value in that local.  As a result, the baseline observes the
3187         side effect of an op_call_varargs on an undefined value instead of the
3188         function it expected.
3189
3190         Note: this issue does not manifest with op_construct_varargs because
3191         the inlined constructor will have an op_create_this which operates on
3192         the incoming callee value, thereby keeping it alive.
3193
3194         * dfg/DFGByteCodeParser.cpp:
3195         (JSC::DFG::ByteCodeParser::handleInlining):
3196         * tests/stress/call-varargs-with-different-arguments-length-after-warmup.js: Added.
3197         (foo):
3198         (Foo):
3199         (doTest):
3200
3201 2015-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
3202
3203         [ES6] Implement Array.prototype.values
3204         https://bugs.webkit.org/show_bug.cgi?id=143633
3205
3206         Reviewed by Darin Adler.
3207
3208         Symbol.unscopables is implemented, so we can implement Array.prototype.values
3209         without largely breaking the web. The following script passes.
3210
3211         var array = [];
3212         var values = 42;
3213         with (array) {
3214             assert(values, 42);
3215         }
3216
3217         * runtime/ArrayPrototype.cpp:
3218         * tests/stress/array-iterators-next.js:
3219         * tests/stress/map-iterators-next.js:
3220         * tests/stress/set-iterators-next.js:
3221         * tests/stress/values-unscopables.js: Added.
3222         (test):
3223
3224 2015-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3225
3226         Run flaky conservative GC related test first before polluting stack and registers
3227         https://bugs.webkit.org/show_bug.cgi?id=143634
3228
3229         Reviewed by Ryosuke Niwa.
3230
3231         After r182653, JSC API tests fail. However, it's not related to the change.
3232         After investigating the cause of this failure, I've found that the failed test is flaky
3233         because JSC's GC is conservative. If previously allocated JSGlobalObject is accidentally alive
3234         due to conservative roots in C stack and registers, this test fails.
3235
3236         Since GC marks C stack and registers as roots conservatively,
3237         objects not referenced logically can be accidentally marked and alive.
3238         To avoid this situation as possible as we can,
3239         1. run this test first before stack is polluted,
3240         2. extract this test as a function to suppress stack height.
3241
3242         * API/tests/testapi.mm:
3243         (testWeakValue):
3244         (testObjectiveCAPIMain):
3245         (testObjectiveCAPI):
3246
3247 2015-04-11  Matt Baker  <mattbaker@apple.com>
3248
3249         Web Inspector: create content view and details sidebar for Frames timeline
3250         https://bugs.webkit.org/show_bug.cgi?id=143533
3251
3252         Reviewed by Timothy Hatcher.
3253
3254         Refactoring: RunLoop prefix changed to RenderingFrame.
3255
3256         * inspector/protocol/Timeline.json:
3257
3258 2015-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3259
3260         [ES6] Enable Symbol in web pages
3261         https://bugs.webkit.org/show_bug.cgi?id=143375
3262
3263         Reviewed by Ryosuke Niwa.
3264
3265         Expose Symbol to web pages.
3266         Symbol was exposed, but it was hidden since it breaks Facebook comments.
3267         This is because at that time Symbol is implemented,
3268         but methods for Symbol.iterator and Object.getOwnPropertySymbols are not implemented yet
3269         and it breaks React.js and immutable.js.
3270
3271         Now methods for Symbol.iterator and Object.getOwnPropertySymbols are implemented
3272         and make sure that Facebook comment input functionality is not broken with exposed Symbol.
3273
3274         So this patch replaces runtime flags SymbolEnabled to SymbolDisabled
3275         and makes enabling symbols by default.
3276
3277         * runtime/ArrayPrototype.cpp:
3278         (JSC::ArrayPrototype::finishCreation):
3279         * runtime/CommonIdentifiers.h:
3280         * runtime/JSGlobalObject.cpp:
3281         (JSC::JSGlobalObject::init):
3282         * runtime/ObjectConstructor.cpp:
3283         (JSC::ObjectConstructor::finishCreation):
3284         * runtime/RuntimeFlags.h:
3285
3286 2015-04-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3287
3288         ES6: Iterator toString names should be consistent
3289         https://bugs.webkit.org/show_bug.cgi?id=142424
3290
3291         Reviewed by Geoffrey Garen.
3292
3293         Iterator Object Names in the spec right now have spaces.
3294         In our implementation some do and some don't.
3295         This patch aligns JSC to the spec.
3296
3297         * runtime/JSArrayIterator.cpp:
3298         * runtime/JSStringIterator.cpp:
3299         * tests/stress/iterator-names.js: Added.
3300         (test):
3301         (iter):
3302         (check):
3303
3304 2015-04-10  Michael Saboff  <msaboff@apple.com>
3305
3306         REGRESSION (182567): regress/script-tests/sorting-benchmark.js fails on 32 bit dfg-eager tests
3307         https://bugs.webkit.org/show_bug.cgi?id=143582
3308
3309         Reviewed by Mark Lam.
3310
3311         For 32 bit builds, we favor spilling unboxed values.  The ASSERT at the root of this bug doesn't
3312         fire for 64 bit builds, because we spill an "Other" value as a full JS value (DataFormatJS).
3313         For 32 bit builds however, if we are able, we spill Other values as JSCell* (DataFormatCell).
3314         The fix is to add a check in fillSpeculateInt32Internal() before the ASSERT that always OSR exits
3315         if the spillFormat is DataFormatCell.  Had we spilled in DataFormatJS and the value was a JSCell*,
3316         we would still OSR exit after the speculation check.
3317
3318         * dfg/DFGFixupPhase.cpp:
3319         (JSC::DFG::FixupPhase::fixupNode): Fixed an error in a comment while debugging.
3320         * dfg/DFGSpeculativeJIT32_64.cpp:
3321         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
3322
3323 2015-04-10  Milan Crha  <mcrha@redhat.com>
3324
3325         Disable Linux-specific code in a Windows build
3326         https://bugs.webkit.org/show_bug.cgi?id=137973
3327
3328         Reviewed by Joseph Pecoraro.
3329
3330         * inspector/JSGlobalObjectInspectorController.cpp:
3331         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
3332
3333 2015-04-10  Csaba Osztrogon√°c  <ossy@webkit.org>
3334
3335         [ARM] Fix calleeSaveRegisters() on non iOS platforms after r180516
3336         https://bugs.webkit.org/show_bug.cgi?id=143368
3337
3338         Reviewed by Michael Saboff.
3339
3340         * jit/RegisterSet.cpp:
3341         (JSC::RegisterSet::calleeSaveRegisters):
3342
3343 2015-04-08  Joseph Pecoraro  <pecoraro@apple.com>
3344
3345         Use jsNontrivialString in more places if the string is guaranteed to be 2 or more characters
3346         https://bugs.webkit.org/show_bug.cgi?id=143430
3347
3348         Reviewed by Darin Adler.
3349
3350         * runtime/ExceptionHelpers.cpp:
3351         (JSC::errorDescriptionForValue):
3352         * runtime/NumberPrototype.cpp:
3353         (JSC::numberProtoFuncToExponential):
3354         (JSC::numberProtoFuncToPrecision):
3355         (JSC::numberProtoFuncToString):
3356         * runtime/SymbolPrototype.cpp:
3357         (JSC::symbolProtoFuncToString):
3358
3359 2015-04-08  Filip Pizlo  <fpizlo@apple.com>
3360
3361         JSArray::sortNumeric should handle ArrayWithUndecided
3362         https://bugs.webkit.org/show_bug.cgi?id=143535
3363
3364         Reviewed by Geoffrey Garen.
3365         
3366         ArrayWithUndecided is what you get if you haven't stored anything into the array yet. We need to handle it.
3367
3368         * runtime/JSArray.cpp:
3369         (JSC::JSArray::sortNumeric):
3370         * tests/stress/sort-array-with-undecided.js: Added.
3371
3372 2015-04-08  Filip Pizlo  <fpizlo@apple.com>
3373
3374         DFG::IntegerCheckCombiningPhase's wrap-around check shouldn't trigger C++ undef behavior on wrap-around
3375         https://bugs.webkit.org/show_bug.cgi?id=143532
3376
3377         Reviewed by Gavin Barraclough.
3378         
3379         Oh the irony!  We were protecting an optimization that only worked if there was no wrap-around in JavaScript.
3380         But the C++ code had wrap-around, which is undef in C++.  So, if the compiler was smart enough, our compiler
3381         would think that there never was wrap-around.
3382         
3383         This fixes a failure in stress/tricky-array-boiunds-checks.js when JSC is compiled with bleeding-edge clang.
3384
3385         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3386         (JSC::DFG::IntegerCheckCombiningPhase::isValid):
3387
3388 2015-04-07  Michael Saboff  <msaboff@apple.com>
3389
3390         Lazily initialize LogToSystemConsole flag to reduce memory usage
3391         https://bugs.webkit.org/show_bug.cgi?id=143506
3392
3393         Reviewed by Mark Lam.
3394
3395         Only call into CF preferences code when we need to in order to reduce memory usage.
3396
3397         * inspector/JSGlobalObjectConsoleClient.cpp:
3398         (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
3399         (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
3400         (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole):
3401         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
3402
3403 2015-04-07  Benjamin Poulain  <benjamin@webkit.org>
3404
3405         Get the features.json files ready for open contributions
3406         https://bugs.webkit.org/show_bug.cgi?id=143436
3407
3408         Reviewed by Darin Adler.
3409
3410         * features.json:
3411
3412 2015-04-07  Filip Pizlo  <fpizlo@apple.com>
3413
3414         Constant folding of typed array properties should be handled by AI rather than strength reduction
3415         https://bugs.webkit.org/show_bug.cgi?id=143496
3416
3417         Reviewed by Geoffrey Garen.
3418         
3419         Handling constant folding in AI is better because it precludes us from having to fixpoint the CFA
3420         phase and whatever other phase did the folding in order to find all constants.
3421         
3422         This also removes the TypedArrayWatchpoint node type because we can just set the watchpoint
3423         directly.
3424         
3425         This also fixes a bug in FTL lowering of GetTypedArrayByteOffset. The bug was previously not
3426         found because all of the tests for it involved the property getting constant folded. I found that
3427         the codegen was bad because an earlier version of the patch broke that constant folding. This
3428         adds a new test for that node type, which makes constant folding impossible by allocating a new
3429         typed array every type. The lesson here is: if you write a test for something, run the test with
3430         full IR dumps to make sure it's actually testing the thing you want it to test.
3431
3432         * dfg/DFGAbstractInterpreterInlines.h:
3433         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3434         * dfg/DFGClobberize.h:
3435         (JSC::DFG::clobberize):
3436         * dfg/DFGConstantFoldingPhase.cpp:
3437         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3438         * dfg/DFGDoesGC.cpp:
3439         (JSC::DFG::doesGC):
3440         * dfg/DFGFixupPhase.cpp:
3441         (JSC::DFG::FixupPhase::fixupNode):
3442         * dfg/DFGGraph.cpp:
3443         (JSC::DFG::Graph::dump):
3444         (JSC::DFG::Graph::tryGetFoldableView):
3445         (JSC::DFG::Graph::tryGetFoldableViewForChild1): Deleted.
3446         * dfg/DFGGraph.h:
3447         * dfg/DFGNode.h:
3448         (JSC::DFG::Node::hasTypedArray): Deleted.
3449         (JSC::DFG::Node::typedArray): Deleted.
3450         * dfg/DFGNodeType.h:
3451         * dfg/DFGPredictionPropagationPhase.cpp:
3452         (JSC::DFG::PredictionPropagationPhase::propagate):
3453         * dfg/DFGSafeToExecute.h:
3454         (JSC::DFG::safeToExecute):
3455         * dfg/DFGSpeculativeJIT.cpp:
3456         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
3457         * dfg/DFGSpeculativeJIT32_64.cpp:
3458         (JSC::DFG::SpeculativeJIT::compile):
3459         * dfg/DFGSpeculativeJIT64.cpp:
3460         (JSC::DFG::SpeculativeJIT::compile):
3461         * dfg/DFGStrengthReductionPhase.cpp:
3462         (JSC::DFG::StrengthReductionPhase::handleNode):
3463         (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): Deleted.
3464         (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): Deleted.
3465         * dfg/DFGWatchpointCollectionPhase.cpp:
3466         (JSC::DFG::WatchpointCollectionPhase::handle):
3467         (JSC::DFG::WatchpointCollectionPhase::addLazily):
3468         * ftl/FTLCapabilities.cpp:
3469         (JSC::FTL::canCompile):
3470         * ftl/FTLLowerDFGToLLVM.cpp:
3471         (JSC::FTL::LowerDFGToLLVM::compileNode):
3472         (JSC::FTL::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
3473         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
3474         * tests/stress/fold-typed-array-properties.js:
3475         (foo):
3476         * tests/stress/typed-array-byte-offset.js: Added.
3477         (foo):
3478
3479 2015-04-07  Matthew Mirman  <mmirman@apple.com>
3480
3481         Source and stack information should get appended only to native errors
3482         and should be added directly after construction rather than when thrown. 
3483         This fixes frozen objects being unfrozen when thrown while conforming to 
3484         ecma script standard and other browser behavior.
3485         rdar://problem/19927293
3486         https://bugs.webkit.org/show_bug.cgi?id=141871
3487         
3488         Reviewed by Geoffrey Garen.
3489
3490         Appending stack, source, line, and column information to an object whenever that object is thrown 
3491         is incorrect because it violates the ecma script standard for the behavior of throw.  Suppose for example
3492         that the object being thrown already has one of these properties or is frozen.  Adding the properties 
3493         would then violate the frozen contract or overwrite those properties.  Other browsers do not do this,
3494         and doing this causes unnecessary performance hits in code with heavy use of the throw construct as
3495         a control flow construct rather than just an error reporting mechanism.  
3496         
3497         Because WebCore adds "native" errors which do not inherit from any JSC native error, 
3498         appending the error properties as a seperate call after construction of the error is required 
3499         to avoid having to manually truncate the stack and gather local source information due to 
3500         the stack being extended by a nested call to construct one of the native jsc error.
3501         
3502         * interpreter/Interpreter.cpp:
3503         (JSC::Interpreter::execute):
3504         * interpreter/Interpreter.h:
3505         * parser/ParserError.h:
3506         (JSC::ParserError::toErrorObject):
3507         * runtime/CommonIdentifiers.h:
3508         * runtime/Error.cpp:
3509         (JSC::createError):
3510         (JSC::createEvalError):
3511         (JSC::createRangeError):
3512         (JSC::createReferenceError):
3513         (JSC::createSyntaxError):
3514         (JSC::createTypeError):
3515         (JSC::createNotEnoughArgumentsError):
3516         (JSC::createURIError):
3517         (JSC::createOutOfMemoryError):
3518         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
3519         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
3520         (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
3521         (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
3522         (JSC::addErrorInfoAndGetBytecodeOffset):  Added.
3523         (JSC::addErrorInfo): Added special case for appending complete error info 
3524         to a newly constructed error object.
3525         * runtime/Error.h:
3526         * runtime/ErrorConstructor.cpp:
3527         (JSC::Interpreter::constructWithErrorConstructor):
3528         (JSC::Interpreter::callErrorConstructor):
3529         * runtime/ErrorInstance.cpp:
3530         (JSC::appendSourceToError): Moved from VM.cpp
3531         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
3532         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
3533         (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
3534         (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
3535         (JSC::addErrorInfoAndGetBytecodeOffset):
3536         (JSC::ErrorInstance::finishCreation):
3537         * runtime/ErrorInstance.h:
3538         (JSC::ErrorInstance::create):
3539         * runtime/ErrorPrototype.cpp:
3540         (JSC::ErrorPrototype::finishCreation):
3541         * runtime/ExceptionFuzz.cpp:
3542         (JSC::doExceptionFuzzing):
3543         * runtime/ExceptionHelpers.cpp:
3544         (JSC::createError):
3545         (JSC::createInvalidFunctionApplyParameterError):
3546         (JSC::createInvalidInParameterError):
3547         (JSC::createInvalidInstanceofParameterError):
3548         (JSC::createNotAConstructorError):
3549         (JSC::createNotAFunctionError):
3550         (JSC::createNotAnObjectError):
3551         (JSC::throwOutOfMemoryError):
3552         (JSC::createStackOverflowError): Deleted.
3553         (JSC::createOutOfMemoryError): Deleted.
3554         * runtime/ExceptionHelpers.h:
3555         * runtime/JSArrayBufferConstructor.cpp:
3556         (JSC::constructArrayBuffer):
3557         * runtime/JSArrayBufferPrototype.cpp:
3558         (JSC::arrayBufferProtoFuncSlice):
3559         * runtime/JSGenericTypedArrayViewInlines.h:
3560         (JSC::JSGenericTypedArrayView<Adaptor>::create):
3561         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
3562         * runtime/NativeErrorConstructor.cpp:
3563         (JSC::Interpreter::constructWithNativeErrorConstructor):
3564         (JSC::Interpreter::callNativeErrorConstructor):
3565         * runtime/VM.cpp:
3566         (JSC::VM::throwException):
3567         (JSC::appendSourceToError): Moved to Error.cpp
3568         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted.
3569         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted.
3570         (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame): Deleted.
3571         (JSC::FindFirstCallerFrameWithCodeblockFunctor::index): Deleted.
3572         * tests/stress/freeze_leek.js: Added.
3573
3574 2015-04-07  Joseph Pecoraro  <pecoraro@apple.com>
3575
3576         Web Inspector: ES6: Show Symbol properties on Objects
3577         https://bugs.webkit.org/show_bug.cgi?id=141279
3578
3579         Reviewed by Timothy Hatcher.
3580
3581         * inspector/protocol/Runtime.json:
3582         Give PropertyDescriptor a reference to the Symbol RemoteObject
3583         if the property is a symbol property.
3584
3585         * inspector/InjectedScriptSource.js:
3586         Enumerate symbol properties on objects.
3587
3588 2015-04-07  Filip Pizlo  <fpizlo@apple.com>
3589
3590         Make it possible to enable LLVM FastISel
3591         https://bugs.webkit.org/show_bug.cgi?id=143489
3592
3593         Reviewed by Michael Saboff.
3594
3595         The decision to enable FastISel is made by Options.h|cpp, but the LLVM library can disable it if it finds that it is built
3596         against a version of LLVM that doesn't support it. Thereafter, JSC::enableLLVMFastISel is the flag that tells the system
3597         if we should enable it.
3598
3599         * ftl/FTLCompile.cpp:
3600         (JSC::FTL::mmAllocateDataSection):
3601         * llvm/InitializeLLVM.cpp:
3602         (JSC::initializeLLVMImpl):
3603         * llvm/InitializeLLVM.h:
3604         * llvm/InitializeLLVMLinux.cpp:
3605         (JSC::getLLVMInitializerFunction):
3606         (JSC::initializeLLVMImpl): Deleted.
3607         * llvm/InitializeLLVMMac.cpp:
3608         (JSC::getLLVMInitializerFunction):
3609         (JSC::initializeLLVMImpl): Deleted.
3610         * llvm/InitializeLLVMPOSIX.cpp:
3611         (JSC::getLLVMInitializerFunctionPOSIX):
3612         (JSC::initializeLLVMPOSIX): Deleted.
3613         * llvm/InitializeLLVMPOSIX.h:
3614         * llvm/InitializeLLVMWin.cpp:
3615         (JSC::getLLVMInitializerFunction):
3616         (JSC::initializeLLVMImpl): Deleted.
3617         * llvm/LLVMAPI.cpp:
3618         * llvm/LLVMAPI.h:
3619         * llvm/library/LLVMExports.cpp:
3620         (initCommandLine):
3621         (initializeAndGetJSCLLVMAPI):
3622         * runtime/Options.cpp:
3623         (JSC::Options::initialize):
3624
3625 2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3626
3627         put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
3628         https://bugs.webkit.org/show_bug.cgi?id=140426
3629
3630         Reviewed by Darin Adler.
3631
3632         In the put_by_val_direct operation, we use JSObject::putDirect.
3633         However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
3634         This patch checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
3635
3636         * dfg/DFGOperations.cpp:
3637         (JSC::DFG::putByVal):
3638         (JSC::DFG::operationPutByValInternal):
3639         * jit/JITOperations.cpp:
3640         * llint/LLIntSlowPaths.cpp:
3641         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3642         * runtime/Identifier.h:
3643         (JSC::isIndex):
3644         (JSC::parseIndex):
3645         * tests/stress/dfg-put-by-val-direct-with-edge-numbers.js: Added.
3646         (lookupWithKey):
3647         (toStringThrowsError.toString):
3648
3649 2015-04-06  Alberto Garcia  <berto@igalia.com>
3650
3651         [GTK] Fix HPPA build
3652         https://bugs.webkit.org/show_bug.cgi?id=143453
3653
3654         Reviewed by Darin Adler.
3655
3656         Add HPPA to the list of supported CPUs.
3657
3658         * CMakeLists.txt:
3659
3660 2015-04-06  Mark Lam  <mark.lam@apple.com>
3661
3662         In the 64-bit DFG and FTL, Array::Double case for HasIndexedProperty should set its result to true when all is well.
3663         <https://webkit.org/b/143396>
3664
3665         Reviewed by Filip Pizlo.
3666
3667         The DFG was neglecting to set the result boolean.  The FTL was setting it with
3668         an inverted value.  Both of these are now resolved.
3669
3670         * dfg/DFGSpeculativeJIT64.cpp:
3671         (JSC::DFG::SpeculativeJIT::compile):
3672         * ftl/FTLLowerDFGToLLVM.cpp:
3673         (JSC::FTL::LowerDFGToLLVM::compileHasIndexedProperty):
3674         * tests/stress/for-in-array-mode.js: Added.
3675         (.):
3676         (test):
3677
3678 2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3679
3680         [ES6] DFG and FTL should be aware of that StringConstructor behavior for symbols becomes different from ToString
3681         https://bugs.webkit.org/show_bug.cgi?id=143424
3682
3683         Reviewed by Geoffrey Garen.
3684
3685         In ES6, StringConstructor behavior becomes different from ToString abstract operations in the spec. (and JSValue::toString).
3686
3687         ToString(symbol) throws a type error.
3688         However, String(symbol) produces SymbolDescriptiveString(symbol).
3689
3690         So, in DFG and FTL phase, they should not inline StringConstructor to ToString.
3691
3692         Now, in the template literals patch, ToString DFG operation is planned to be used.
3693         And current ToString behavior is aligned to the spec (and JSValue::toString) and it's better.
3694         So intead of changing ToString behavior, this patch adds CallStringConstructor operation into DFG and FTL.
3695         In CallStringConstructor, all behavior in DFG analysis is the same.
3696         Only the difference from ToString is, when calling DFG operation functions, it calls
3697         operationCallStringConstructorOnCell and operationCallStringConstructor instead of
3698         operationToStringOnCell and operationToString.
3699
3700         * dfg/DFGAbstractInterpreterInlines.h:
3701         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3702         * dfg/DFGBackwardsPropagationPhase.cpp:
3703         (JSC::DFG::BackwardsPropagationPhase::propagate):
3704         * dfg/DFGByteCodeParser.cpp:
3705         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3706         * dfg/DFGClobberize.h:
3707         (JSC::DFG::clobberize):
3708         * dfg/DFGDoesGC.cpp:
3709         (JSC::DFG::doesGC):
3710         * dfg/DFGFixupPhase.cpp:
3711         (JSC::DFG::FixupPhase::fixupNode):
3712         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
3713         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
3714         (JSC::DFG::FixupPhase::fixupToString): Deleted.
3715         * dfg/DFGNodeType.h:
3716         * dfg/DFGOperations.cpp:
3717         * dfg/DFGOperations.h:
3718         * dfg/DFGPredictionPropagationPhase.cpp:
3719         (JSC::DFG::PredictionPropagationPhase::propagate):
3720         * dfg/DFGSafeToExecute.h:
3721         (JSC::DFG::safeToExecute):
3722         * dfg/DFGSpeculativeJIT.cpp:
3723         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
3724         (JSC::DFG::SpeculativeJIT::compileToStringOnCell): Deleted.
3725         * dfg/DFGSpeculativeJIT.h:
3726         * dfg/DFGSpeculativeJIT32_64.cpp:
3727         (JSC::DFG::SpeculativeJIT::compile):
3728         * dfg/DFGSpeculativeJIT64.cpp:
3729         (JSC::DFG::SpeculativeJIT::compile):
3730         * dfg/DFGStructureRegistrationPhase.cpp:
3731         (JSC::DFG::StructureRegistrationPhase::run):
3732         * ftl/FTLCapabilities.cpp:
3733         (JSC::FTL::canCompile):
3734         * ftl/FTLLowerDFGToLLVM.cpp:
3735         (JSC::FTL::LowerDFGToLLVM::compileNode):
3736         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
3737         (JSC::FTL::LowerDFGToLLVM::compileToString): Deleted.
3738         * runtime/StringConstructor.cpp:
3739         (JSC::stringConstructor):
3740         (JSC::callStringConstructor):
3741         * runtime/StringConstructor.h:
3742         * tests/stress/symbol-and-string-constructor.js: Added.
3743         (performString):
3744
3745 2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3746
3747         Return Optional<uint32_t> from PropertyName::asIndex
3748         https://bugs.webkit.org/show_bug.cgi?id=143422
3749
3750         Reviewed by Darin Adler.
3751
3752         PropertyName::asIndex returns uint32_t and use UINT_MAX as NotAnIndex.
3753         But it's not obvious to callers.
3754
3755         This patch changes
3756         1. PropertyName::asIndex() to return Optional<uint32_t> and
3757         2. function name `asIndex()` to `parseIndex()`.
3758         It forces callers to check the value is index or not explicitly.
3759
3760         * bytecode/GetByIdStatus.cpp:
3761         (JSC::GetByIdStatus::computeFor):
3762         * bytecode/PutByIdStatus.cpp:
3763         (JSC::PutByIdStatus::computeFor):
3764         * bytecompiler/BytecodeGenerator.cpp:
3765         (JSC::BytecodeGenerator::emitDirectPutById):
3766         * jit/Repatch.cpp:
3767         (JSC::emitPutTransitionStubAndGetOldStructure):
3768         * jsc.cpp:
3769         * runtime/ArrayPrototype.cpp:
3770         (JSC::arrayProtoFuncSort):
3771         * runtime/GenericArgumentsInlines.h:
3772         (JSC::GenericArguments<Type>::getOwnPropertySlot):
3773         (JSC::GenericArguments<Type>::put):
3774         (JSC::GenericArguments<Type>::deleteProperty):
3775         (JSC::GenericArguments<Type>::defineOwnProperty):
3776         * runtime/Identifier.h:
3777         (JSC::parseIndex):
3778         (JSC::Identifier::isSymbol):
3779         * runtime/JSArray.cpp:
3780         (JSC::JSArray::defineOwnProperty):
3781         * runtime/JSCJSValue.cpp:
3782         (JSC::JSValue::putToPrimitive):
3783         * runtime/JSGenericTypedArrayViewInlines.h:
3784         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
3785         (JSC::JSGenericTypedArrayView<Adaptor>::put):
3786         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
3787         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
3788         * runtime/JSObject.cpp:
3789         (JSC::JSObject::put):
3790         (JSC::JSObject::putDirectAccessor):
3791         (JSC::JSObject::putDirectCustomAccessor):
3792         (JSC::JSObject::deleteProperty):
3793         (JSC::JSObject::putDirectMayBeIndex):
3794         (JSC::JSObject::defineOwnProperty):
3795         * runtime/JSObject.h:
3796         (JSC::JSObject::getOwnPropertySlot):
3797         (JSC::JSObject::getPropertySlot):
3798         (JSC::JSObject::putDirectInternal):
3799         * runtime/JSString.cpp:
3800         (JSC::JSString::getStringPropertyDescriptor):
3801         * runtime/JSString.h:
3802         (JSC::JSString::getStringPropertySlot):
3803         * runtime/LiteralParser.cpp:
3804         (JSC::LiteralParser<CharType>::parse):
3805         * runtime/PropertyName.h:
3806         (JSC::parseIndex):
3807         (JSC::toUInt32FromCharacters): Deleted.
3808         (JSC::toUInt32FromStringImpl): Deleted.
3809         (JSC::PropertyName::asIndex): Deleted.
3810         * runtime/PropertyNameArray.cpp:
3811         (JSC::PropertyNameArray::add):
3812         * runtime/StringObject.cpp:
3813         (JSC::StringObject::deleteProperty):
3814         * runtime/Structure.cpp:
3815         (JSC::Structure::prototypeChainMayInterceptStoreTo):
3816
3817 2015-04-05  Andreas Kling  <akling@apple.com>
3818
3819         URI encoding/escaping should use efficient string building instead of calling snprintf().
3820         <https://webkit.org/b/143426>
3821
3822         Reviewed by Gavin Barraclough.
3823
3824         I saw 0.5% of main thread time in snprintf() on <http://polymerlabs.github.io/benchmarks/>
3825         which seemed pretty silly. This change gets that down to nothing in favor of using our
3826         existing JSStringBuilder and HexNumber.h facilities.
3827
3828         These APIs are well-exercised by our existing test suite.
3829
3830         * runtime/JSGlobalObjectFunctions.cpp:
3831         (JSC::encode):
3832         (JSC::globalFuncEscape):
3833
3834 2015-04-05  Masataka Yakura  <masataka.yakura@gmail.com>
3835
3836         documentation for ES Promises points to the wrong one
3837         https://bugs.webkit.org/show_bug.cgi?id=143263
3838
3839         Reviewed by Darin Adler.
3840
3841         * features.json:
3842
3843 2015-04-05  Simon Fraser  <simon.fraser@apple.com>
3844
3845         Remove "go ahead and" from comments
3846         https://bugs.webkit.org/show_bug.cgi?id=143421
3847
3848         Reviewed by Darin Adler, Benjamin Poulain.
3849
3850         Remove the phrase "go ahead and" from comments where it doesn't add
3851         anything (which is almost all of them).
3852
3853         * interpreter/JSStack.cpp:
3854         (JSC::JSStack::growSlowCase):
3855
3856 2015-04-04  Andreas Kling  <akling@apple.com>
3857
3858         Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
3859         <https://webkit.org/b/143210>
3860
3861         Reviewed by Geoffrey Garen.
3862
3863         Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
3864         we had a little problem where WeakBlocks with only null pointers would still keep their
3865         MarkedBlock alive.
3866
3867         This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
3868         that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
3869         to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
3870         destroying them once they're fully dead.
3871
3872         This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
3873         a mysterious issue where doing two full garbage collections back-to-back would free additional
3874         memory in the second collection.
3875
3876         Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
3877         an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
3878         calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.
3879
3880         * heap/Heap.h:
3881         * heap/Heap.cpp:
3882         (JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
3883         owned by Heap, after everything else has been swept.
3884
3885         (JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
3886         after a full garbage collection ends. Note that we don't do this after Eden collections, since
3887         they are unlikely to cause entire WeakBlocks to go empty.
3888
3889         (JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
3890         to the Heap when it's detached from a WeakSet.
3891
3892         (JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
3893         of the logically empty WeakBlocks owned by Heap.
3894
3895         (JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
3896         and updates the next-logically-empty-weak-block-to-sweep index.
3897
3898         (JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
3899         won't be another chance after this.
3900
3901 &nb