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