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