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