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