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