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