Source/JavaScriptCore: Qt build fix. Add a return to make the compiler happy.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-09-12  Ryosuke Niwa  <rniwa@webkit.org>
2
3         Qt build fix. Add a return to make the compiler happy.
4
5         * dfg/DFGGPRInfo.h:
6         (JSC::DFG::JSValueRegs::gpr):
7
8 2013-09-12  Filip Pizlo  <fpizlo@apple.com>
9
10         DFG::GenerationInfo init/fill methods shouldn't duplicate a bunch of logic
11         https://bugs.webkit.org/show_bug.cgi?id=121253
12
13         Reviewed by Oliver Hunt.
14
15         * dfg/DFGGenerationInfo.h:
16         (JSC::DFG::GenerationInfo::initGPR):
17         (JSC::DFG::GenerationInfo::initInt32):
18         (JSC::DFG::GenerationInfo::initJSValue):
19         (JSC::DFG::GenerationInfo::initCell):
20         (JSC::DFG::GenerationInfo::initBoolean):
21         (JSC::DFG::GenerationInfo::initStorage):
22         (JSC::DFG::GenerationInfo::fillGPR):
23         (JSC::DFG::GenerationInfo::fillJSValue):
24         (JSC::DFG::GenerationInfo::fillCell):
25         (JSC::DFG::GenerationInfo::fillInt32):
26         (JSC::DFG::GenerationInfo::fillBoolean):
27         (JSC::DFG::GenerationInfo::fillStorage):
28
29 2013-09-12  Filip Pizlo  <fpizlo@apple.com>
30
31         Unreviewed, fix mispelling (Specualte -> Speculate) that I introduced in an
32         earlier patch.
33
34         * dfg/DFGSpeculativeJIT.h:
35         (JSC::DFG::SpeculateInt32Operand::gpr):
36         (JSC::DFG::SpeculateStrictInt32Operand::gpr):
37         * dfg/DFGSpeculativeJIT32_64.cpp:
38         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
39         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32):
40         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict):
41         * dfg/DFGSpeculativeJIT64.cpp:
42         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
43         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32):
44         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict):
45
46 2013-09-12  Filip Pizlo  <fpizlo@apple.com>
47
48         GPRTemporary's reuse constructor should be templatized to reduce code duplication, and the bool to denote tag or payload should be replaced with an enum
49         https://bugs.webkit.org/show_bug.cgi?id=121250
50
51         Reviewed by Oliver Hunt.
52
53         * dfg/DFGGPRInfo.h:
54         (JSC::DFG::JSValueRegs::gpr):
55         * dfg/DFGSpeculativeJIT.cpp:
56         (JSC::DFG::GPRTemporary::GPRTemporary):
57         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
58         (JSC::DFG::SpeculativeJIT::compileAdd):
59         (JSC::DFG::SpeculativeJIT::compileStringEquality):
60         (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
61         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
62         * dfg/DFGSpeculativeJIT.h:
63         (JSC::DFG::JSValueOperand::gpr):
64         (JSC::DFG::GPRTemporary::GPRTemporary):
65         * dfg/DFGSpeculativeJIT32_64.cpp:
66         (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
67         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
68         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
69         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
70         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
71         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
72         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
73         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
74         (JSC::DFG::SpeculativeJIT::compile):
75         * dfg/DFGSpeculativeJIT64.cpp:
76         (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
77         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
78         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
79         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
80         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
81         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
82         (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
83         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
84         (JSC::DFG::SpeculativeJIT::compile):
85         * runtime/JSCJSValue.h:
86
87 2013-09-12  Mark Hahnenberg  <mhahnenberg@apple.com>
88
89         MarkedBlocks shouldn't be put in Allocated state if they didn't produce a FreeList
90         https://bugs.webkit.org/show_bug.cgi?id=121236
91
92         Reviewed by Geoffrey Garen.
93
94         Right now, after a collection all MarkedBlocks are in the Marked block state. When lazy sweeping 
95         happens, if a block returns an empty free list after being swept, we call didConsumeFreeList(), 
96         which moves the block into the Allocated block state. This happens to both the block that was 
97         just being allocated out of (i.e. m_currentBlock) as well as any blocks who are completely full. 
98         We should distinguish between these two cases: m_currentBlock should transition to 
99         Allocated (because we were just allocating out of it) and any subsequent block that returns an 
100         empty free list should transition back to the Marked state. This will make the block state more 
101         consistent with the actual state the block is in, and it will also allow us to speed up moving 
102         all blocks to the Marked state during generational collection.
103
104         * heap/MarkedAllocator.cpp:
105         (JSC::MarkedAllocator::tryAllocateHelper):
106         * heap/MarkedBlock.h:
107         (JSC::MarkedBlock::didConsumeEmptyFreeList):
108
109 2013-09-12  Mark Lam  <mark.lam@apple.com>
110
111         Change debug hooks to pass sourceID and position info via the DebuggerCallFrame.
112         https://bugs.webkit.org/show_bug.cgi?id=121214.
113
114         Reviewed by Geoffrey Garen.
115
116         * debugger/Debugger.h:
117         * debugger/DebuggerCallFrame.cpp:
118         (JSC::DebuggerCallFrame::sourceId):
119         (JSC::DebuggerCallFrame::clear):
120         * debugger/DebuggerCallFrame.h:
121         (JSC::DebuggerCallFrame::DebuggerCallFrame):
122         (JSC::DebuggerCallFrame::line):
123         (JSC::DebuggerCallFrame::column):
124         * interpreter/Interpreter.cpp:
125         (JSC::unwindCallFrame):
126         (JSC::Interpreter::unwind):
127         (JSC::Interpreter::debug):
128
129 2013-09-12  Csaba Osztrogon√°c  <ossy@webkit.org>
130
131         Add back c++11 features removed by buildfixes after all ports did the switch
132         https://bugs.webkit.org/show_bug.cgi?id=119266
133
134         Reviewed by Anders Carlsson.
135
136         * bytecode/GetByIdStatus.h:
137         (JSC::GetByIdStatus::GetByIdStatus):
138         * dfg/DFGWorklist.cpp:
139         (JSC::DFG::Worklist::~Worklist):
140         * interpreter/StackVisitor.cpp:
141         (JSC::StackVisitor::Frame::codeType):
142         (JSC::StackVisitor::Frame::functionName):
143         (JSC::StackVisitor::Frame::sourceURL):
144         (JSC::StackVisitor::Frame::print):
145
146 2013-09-12  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>
147
148         Remove home-brewed nullptr
149         https://bugs.webkit.org/show_bug.cgi?id=119624
150
151         Reviewed by Anders Carlsson.
152
153         The standard C++11 nullptr and std::nullptr_t type should be used now.
154
155         * heap/PassWeak.h:
156         * heap/Weak.h:
157
158 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
159
160         Rename initInteger() to initInt32()
161
162         Rubber stamped by Mark Hahnenberg.
163
164         * dfg/DFGGenerationInfo.h:
165         (JSC::DFG::GenerationInfo::initInt32):
166         * dfg/DFGSpeculativeJIT.h:
167         (JSC::DFG::SpeculativeJIT::integerResult):
168         * dfg/DFGSpeculativeJIT32_64.cpp:
169         (JSC::DFG::SpeculativeJIT::compile):
170         * dfg/DFGSpeculativeJIT64.cpp:
171         (JSC::DFG::SpeculativeJIT::compile):
172
173 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
174
175         Rename IntegerOperand to Int32Operand and fillInteger() to fillInt32().
176
177         Rubber stamped by Mark Hahnenberg.
178
179         * dfg/DFGGenerationInfo.h:
180         (JSC::DFG::GenerationInfo::fillInt32):
181         * dfg/DFGSpeculativeJIT.cpp:
182         (JSC::DFG::GPRTemporary::GPRTemporary):
183         (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
184         * dfg/DFGSpeculativeJIT.h:
185         (JSC::DFG::Int32Operand::Int32Operand):
186         (JSC::DFG::Int32Operand::~Int32Operand):
187         (JSC::DFG::Int32Operand::gpr):
188         * dfg/DFGSpeculativeJIT32_64.cpp:
189         (JSC::DFG::SpeculativeJIT::fillInt32):
190         (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
191         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
192         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
193         * dfg/DFGSpeculativeJIT64.cpp:
194         (JSC::DFG::SpeculativeJIT::fillInt32):
195         (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
196         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
197         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
198
199 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
200
201         FixupPhase should always call fixEdge() exactly once for every edge
202         https://bugs.webkit.org/show_bug.cgi?id=121211
203
204         Reviewed by Geoffrey Garen.
205         
206         Previously we only call fixEdge() on edges that we want to make typed. UntypedUse
207         edges don't get fixEdge() called. This makes it difficult to add functionality in
208         fixEdge() that runs for UntypedUses. It's difficult to remember to call fixEdge()
209         for every edge that we don't want to turn into a typed edge; in an alternative
210         universe where we did this, it would mean that every case in FixupPhase would
211         have to make a fixEdge() call for *every* edge even ones that it doesn't want to
212         modify.
213         
214         This patch takes a different path. fixEdge() must never be called explicitly with
215         UntypedUse. fixEdge() should be used to set the UseKind of edges. Consequently,
216         all that FixupPhase has to do is call fixEdge<UntypedUse>(edge) for every edge
217         that was still UntypedUse after we are done processing a node.
218         
219         This is cheap and easy to implement and ought to be easy to maintain. We won't
220         have a need to call fixEdge<UntypedUse>(edge) explicitly, so depending on that is
221         only natural.
222
223         * dfg/DFGFixupPhase.cpp:
224         (JSC::DFG::FixupPhase::fixupNode):
225         (JSC::DFG::FixupPhase::observeUntypedEdge):
226         (JSC::DFG::FixupPhase::observeUseKindOnNode):
227
228 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
229
230         FixupPhase's setUseKindAndUnboxBlahbittyblah and fixDoubleEdge methods should be merged and given intuitive names
231         https://bugs.webkit.org/show_bug.cgi?id=121202
232
233         Reviewed by Geoffrey Garen.
234         
235         Got rid of a method whose name was so descriptive that I couldn't ever remember
236         it. And despite the descriptive name, I always had to look at its implementation
237         to remind myself what it did, anyway.
238         
239         Now that method is called fixEdge(). This is a good name because we're in a phase
240         called FixupPhase, and we call this fixEdge() method on pretty much every edge.
241         For the Int48 work, it makes more sense for this method to be a kind of hook into
242         which we can place various things: it's just a way of observing edges that need
243         attention.
244         
245         As part of this refactoring, I also fold fixDoubleEdge into fixEdge. This makes
246         sense because previously it was never correct to call fixDoubleEdge with non-
247         double use kinds; and conversely it was never correct to call fixEdge with double
248         use kinds.
249         
250         Also I found that isDouble() in DFGUseKind.h would return true for KnownInt32Use.
251         That's almost certainly wrong, and removing that behavior doesn't fail any tests.
252         I'm assuming that was just a bug.
253
254         * dfg/DFGFixupPhase.cpp:
255         (JSC::DFG::FixupPhase::fixupNode):
256         (JSC::DFG::FixupPhase::fixupToPrimitive):
257         (JSC::DFG::FixupPhase::fixupToString):
258         (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
259         (JSC::DFG::FixupPhase::fixEdge):
260         (JSC::DFG::FixupPhase::fixIntEdge):
261         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
262         (JSC::DFG::FixupPhase::convertToGetArrayLength):
263         (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
264         * dfg/DFGUseKind.h:
265         (JSC::DFG::isDouble):
266
267 2013-09-11  Mark Lam  <mark.lam@apple.com>
268
269         Fixed indentation in JSC Debugger header files.
270         https://bugs.webkit.org/show_bug.cgi?id=121203.
271
272         Reviewed by Ryosuke Niwa.
273
274         * debugger/Debugger.h:
275         * debugger/DebuggerActivation.h:
276         (JSC::DebuggerActivation::create):
277         (JSC::DebuggerActivation::createStructure):
278         * debugger/DebuggerCallFrame.h:
279         (JSC::DebuggerCallFrame::DebuggerCallFrame):
280         (JSC::DebuggerCallFrame::callFrame):
281         (JSC::DebuggerCallFrame::dynamicGlobalObject):
282         (JSC::DebuggerCallFrame::scope):
283         (JSC::DebuggerCallFrame::exception):
284
285 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
286
287         Remove needsDataFormatConversion because it is unused.
288
289         Rubber stamped by Mark Hahnenberg.
290
291         * bytecode/DataFormat.h:
292
293 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
294
295         Rename fillSpeculateInt to fillSpeculateInt32.
296
297         Rubber stamped by Mark Hahnenberg.
298
299         * dfg/DFGSpeculativeJIT.h:
300         (JSC::DFG::SpeculateInt32Operand::gpr):
301         (JSC::DFG::SpeculateStrictInt32Operand::gpr):
302         * dfg/DFGSpeculativeJIT32_64.cpp:
303         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
304         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32):
305         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Strict):
306         * dfg/DFGSpeculativeJIT64.cpp:
307         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
308         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32):
309         (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Strict):
310
311 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
312
313         Rename DataFormatInteger to DataFormatInt32.
314
315         Rubber stamped by Mark Hahnenberg.
316
317         * bytecode/DataFormat.h:
318         (JSC::dataFormatToString):
319         (JSC::needDataFormatConversion):
320         (JSC::isJSInt32):
321         * bytecode/ValueRecovery.h:
322         (JSC::ValueRecovery::inGPR):
323         (JSC::ValueRecovery::displacedInJSStack):
324         * dfg/DFGGenerationInfo.h:
325         (JSC::DFG::GenerationInfo::initInteger):
326         (JSC::DFG::GenerationInfo::isJSInt32):
327         (JSC::DFG::GenerationInfo::fillInteger):
328         * dfg/DFGSpeculativeJIT.cpp:
329         (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
330         (JSC::DFG::SpeculativeJIT::checkConsistency):
331         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
332         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
333         * dfg/DFGSpeculativeJIT.h:
334         (JSC::DFG::SpeculativeJIT::spill):
335         (JSC::DFG::SpeculativeJIT::integerResult):
336         (JSC::DFG::SpeculativeJIT::jsValueResult):
337         (JSC::DFG::SpeculativeJIT::isInteger):
338         (JSC::DFG::IntegerOperand::format):
339         (JSC::DFG::SpeculateInt32Operand::format):
340         * dfg/DFGSpeculativeJIT32_64.cpp:
341         (JSC::DFG::SpeculativeJIT::fillInteger):
342         (JSC::DFG::SpeculativeJIT::fillJSValue):
343         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
344         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
345         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
346         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
347         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
348         * dfg/DFGSpeculativeJIT64.cpp:
349         (JSC::DFG::SpeculativeJIT::fillInteger):
350         (JSC::DFG::SpeculativeJIT::fillJSValue):
351         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
352         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
353         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
354         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
355         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
356         (JSC::DFG::SpeculativeJIT::compile):
357         * dfg/DFGValueSource.h:
358         (JSC::DFG::dataFormatToValueSourceKind):
359         (JSC::DFG::valueSourceKindToDataFormat):
360
361 2013-09-11  Filip Pizlo  <fpizlo@apple.com>
362
363         Int32ToDouble should be predicted SpecInt48 and predictions should have nothing to do with constant folding
364         https://bugs.webkit.org/show_bug.cgi?id=121141
365
366         Reviewed by Oliver Hunt.
367         
368         Just changing Int32ToDouble to be predicted SpecInt48 breaks constant folding on that
369         node because of soooper old code that prevented constant folding on mismatched
370         predictions. Kill that code.
371
372         * dfg/DFGAbstractInterpreter.h:
373         (JSC::DFG::AbstractInterpreter::setConstant):
374         * dfg/DFGAbstractInterpreterInlines.h:
375         (JSC::DFG::::executeEffects):
376         * dfg/DFGFixupPhase.cpp:
377         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
378
379 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
380
381         VariableAccessData::flushFormat() should be the universal way of deciding how to speculate on stores to locals and how locals are formatted
382         https://bugs.webkit.org/show_bug.cgi?id=121142
383
384         Reviewed by Geoffrey Garen.
385         
386         Make everyone rely on VariableAccessData::flushFormat() instead of trying to
387         compute that information from scratch. The FTL already used flushFormat(), now
388         the DFG does, too.
389
390         * dfg/DFGArgumentPosition.h:
391         (JSC::DFG::ArgumentPosition::someVariable):
392         (JSC::DFG::ArgumentPosition::flushFormat):
393         * dfg/DFGCSEPhase.cpp:
394         (JSC::DFG::CSEPhase::performNodeCSE):
395         * dfg/DFGFixupPhase.cpp:
396         (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
397         * dfg/DFGGraph.cpp:
398         (JSC::DFG::Graph::dump):
399         * dfg/DFGInPlaceAbstractState.cpp:
400         (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
401         * dfg/DFGJITCompiler.h:
402         (JSC::DFG::JITCompiler::noticeOSREntry):
403         * dfg/DFGSpeculativeJIT.cpp:
404         (JSC::DFG::SpeculativeJIT::compileInlineStart):
405         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
406         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
407         * dfg/DFGSpeculativeJIT32_64.cpp:
408         (JSC::DFG::SpeculativeJIT::compile):
409         * dfg/DFGSpeculativeJIT64.cpp:
410         (JSC::DFG::SpeculativeJIT::compile):
411         * dfg/DFGValueSource.h:
412         (JSC::DFG::ValueSource::forFlushFormat):
413         * dfg/DFGVariableAccessDataDump.cpp:
414         (JSC::DFG::VariableAccessDataDump::dump):
415         * ftl/FTLLowerDFGToLLVM.cpp:
416         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
417
418 2013-09-11  Oliver Hunt  <oliver@apple.com>
419
420         Partial Information Leakage in Hash Table implementations (PrivateName)
421         https://bugs.webkit.org/show_bug.cgi?id=120663
422
423         Reviewed by Michael Saboff.
424
425         Undo change to the PropertyTable in my last patch, instead lets just
426         use a random value as the initial hash for unique strings.
427
428         * runtime/PropertyMapHashTable.h:
429         (JSC::PropertyTable::find):
430         (JSC::PropertyTable::findWithString):
431         (JSC::PropertyTable::rehash):
432
433 2013-09-11  Oliver Hunt  <oliver@apple.com>
434
435         Partial Information Leakage in Hash Table implementations (PrivateName)
436         https://bugs.webkit.org/show_bug.cgi?id=120663
437
438         Reviewed by Michael Saboff.
439
440         These hashtables mix keys that are hashed on pointers or user controlled
441         data.  To prevent any potential information leak we mask the keys with
442         a per table entropy value.
443
444         * runtime/MapData.cpp:
445         (JSC::MapData::MapData):
446         (JSC::MapData::find):
447         (JSC::MapData::add):
448         (JSC::MapData::remove):
449         * runtime/MapData.h:
450         * runtime/PropertyMapHashTable.h:
451         (JSC::PropertyTable::find):
452         (JSC::PropertyTable::findWithString):
453         (JSC::PropertyTable::rehash):
454         * runtime/PropertyTable.cpp:
455         (JSC::PropertyTable::PropertyTable):
456
457 2013-09-11  Sam Weinig  <sam@webkit.org>
458
459         MapData and WeakMapData don't need to be objects
460         https://bugs.webkit.org/show_bug.cgi?id=121167
461
462         Reviewed by Geoffrey Garen.
463
464         * runtime/JSGlobalObject.cpp:
465         (JSC::JSGlobalObject::reset):
466         (JSC::JSGlobalObject::visitChildren):
467         * runtime/JSGlobalObject.h:
468         (JSC::JSGlobalObject::mapStructure):
469         Remove MapData and WeakMapData structures (they moved to VM with other non-object Structures).
470
471         * runtime/JSMap.cpp:
472         (JSC::JSMap::finishCreation):
473         * runtime/JSMap.h:
474         (JSC::JSMap::create):
475         * runtime/JSSet.cpp:
476         (JSC::JSSet::finishCreation):
477         * runtime/JSSet.h:
478         (JSC::JSSet::create):
479         * runtime/JSWeakMap.cpp:
480         (JSC::JSWeakMap::finishCreation):
481         * runtime/JSWeakMap.h:
482         (JSC::JSWeakMap::create):
483         Update to not pass a global object to the MapData or WeakMapData Structure.
484
485         * runtime/MapData.cpp:
486         (JSC::MapData::MapData):
487         * runtime/MapData.h:
488         (JSC::MapData::create):
489         (JSC::MapData::createStructure):
490         * runtime/WeakMapData.cpp:
491         (JSC::WeakMapData::WeakMapData):
492         (JSC::WeakMapData::set): Change to take a VM rather than a CallFrame, as that it all it needs.
493         * runtime/WeakMapData.h:
494         (JSC::WeakMapData::create):
495         (JSC::WeakMapData::createStructure):
496         Instead of inheriting from JSDestructibleObject, inherit from JSCell and mark self as needing destruction
497         and having an immortal structure.
498
499         * runtime/VM.cpp:
500         (JSC::VM::VM):
501         * runtime/VM.h:
502         Add MapData and WeakMapData Structures.
503
504         * runtime/WeakMapPrototype.cpp:
505         (JSC::protoFuncWeakMapSet):
506         Pass a VM rather than an ExecState.
507
508 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
509
510         Propagate the Int48 stuff into the prediction propagator.
511         https://bugs.webkit.org/show_bug.cgi?id=121132
512
513         Reviewed by Mark Hahnenberg.
514         
515         This still has no effect on codegen since Int48 still looks like a Double right now.
516
517         * bytecode/ExitKind.cpp:
518         (JSC::exitKindToString):
519         * bytecode/ExitKind.h:
520         * bytecode/SpeculatedType.cpp:
521         (JSC::speculationFromValue):
522         * bytecode/SpeculatedType.h:
523         (JSC::isMachineIntSpeculation):
524         (JSC::isMachineIntSpeculationExpectingDefined):
525         (JSC::isMachineIntSpeculationForArithmetic):
526         * dfg/DFGGraph.cpp:
527         (JSC::DFG::Graph::dump):
528         * dfg/DFGGraph.h:
529         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
530         (JSC::DFG::Graph::mulShouldSpeculateInt32):
531         (JSC::DFG::Graph::mulShouldSpeculateMachineInt):
532         (JSC::DFG::Graph::negateShouldSpeculateMachineInt):
533         (JSC::DFG::Graph::hasExitSite):
534         * dfg/DFGNode.h:
535         (JSC::DFG::Node::shouldSpeculateMachineInt):
536         (JSC::DFG::Node::shouldSpeculateMachineIntForArithmetic):
537         (JSC::DFG::Node::shouldSpeculateMachineIntExpectingDefined):
538         (JSC::DFG::Node::canSpeculateInt48):
539         * dfg/DFGNodeFlags.h:
540         (JSC::DFG::nodeCanSpeculateInt48):
541         * dfg/DFGPredictionPropagationPhase.cpp:
542         (JSC::DFG::PredictionPropagationPhase::propagate):
543
544 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
545
546         Be explicit about backwards propagation properties that care about escaping to bytecode, as opposed to just escaping within DFG code.
547
548         Rubber stamped by Mark Hahnenberg.
549         
550         We need to care about escaping to bytecode if we're doing a lossy optimization,
551         i.e. the optimization means we produce less information and so we can't rescue
552         ourselves during OSR exit.
553         
554         We only need to care about escaping within the DFG code (and can ignore what
555         might happen in bytecode) if we're doing an optimization that is lossless, i.e.
556         we can always still reconstruct the values that bytecode wants.
557         
558         Example #1:
559         
560             Large int32 + int32 which overflows. We want to optimize away the overflow
561             check and just do a 32-bit add.
562             
563             This is lossy; the result should have one extra bit but we simply throw
564             that bit away by doing a check-less 32-bit add. Hence we need to know that 
565             even the bytecode wouldn't have cared about that bit. This is true in cases
566             like (a + b) | 0.
567         
568         Example #2:
569         
570             Larbe int32 + int32 which overflows. We want to optimize away the overflow
571             check by doing a 64-bit add.
572             
573             This is lossless. We can always convert the resulting 64-bit int back to a
574             double if that's what bytecode wants. Hence we only need to know that the
575             DFG code won't want to do something to this value that would make 64-bit
576             ints either unprofitable or unsound.
577         
578         The backwards propagator's notions of flags (NodeUsedAsValue, etc) are for lossy
579         optimizations and so should be named in a way that reflects this. This patch
580         calls then NodeBytecodeUsesAsValue, etc.
581         
582         * dfg/DFGAbstractInterpreterInlines.h:
583         (JSC::DFG::::executeEffects):
584         * dfg/DFGArrayMode.cpp:
585         (JSC::DFG::ArrayMode::refine):
586         * dfg/DFGBackwardsPropagationPhase.cpp:
587         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
588         (JSC::DFG::BackwardsPropagationPhase::propagate):
589         * dfg/DFGFixupPhase.cpp:
590         (JSC::DFG::FixupPhase::fixupNode):
591         * dfg/DFGGraph.h:
592         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
593         * dfg/DFGNode.h:
594         (JSC::DFG::Node::arithNodeFlags):
595         * dfg/DFGNodeFlags.cpp:
596         (JSC::DFG::dumpNodeFlags):
597         * dfg/DFGNodeFlags.h:
598         (JSC::DFG::bytecodeUsesAsNumber):
599         (JSC::DFG::bytecodeCanTruncateInteger):
600         (JSC::DFG::bytecodeCanIgnoreNegativeZero):
601         (JSC::DFG::nodeMayNegZero):
602         (JSC::DFG::nodeCanSpeculateInt32):
603         * dfg/DFGPredictionPropagationPhase.cpp:
604         (JSC::DFG::PredictionPropagationPhase::propagate):
605         * dfg/DFGSpeculativeJIT.cpp:
606         (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
607         (JSC::DFG::SpeculativeJIT::compileAdd):
608         (JSC::DFG::SpeculativeJIT::compileArithSub):
609         (JSC::DFG::SpeculativeJIT::compileArithNegate):
610         (JSC::DFG::SpeculativeJIT::compileArithMul):
611         (JSC::DFG::SpeculativeJIT::compileArithDiv):
612         (JSC::DFG::SpeculativeJIT::compileArithMod):
613         * dfg/DFGVariableAccessData.h:
614         (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
615         * ftl/FTLLowerDFGToLLVM.cpp:
616         (JSC::FTL::LowerDFGToLLVM::compileAdd):
617         (JSC::FTL::LowerDFGToLLVM::compileArithSub):
618         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
619         (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
620         (JSC::FTL::LowerDFGToLLVM::compileArithMod):
621         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
622
623 2013-09-10  Chris Curtis  <chris_curtis@apple.com>
624
625         WebKit crashes when trying to send a msg via 'today's birthdays' dialogue box on Facebook
626         https://bugs.webkit.org/show_bug.cgi?id=120612#add_comment
627         Reviewed by Geoffrey Garen.
628
629         The codeBlock was assumed to exist when appendSourceToMessage was set.
630         This was an invalid assumption. I added a check to ensure that there is a
631         valid codeBlock before accessing it.
632
633         * API/tests/testapi.c:
634         (valueToObjectExceptionCallAsFunction):
635         (valueToObjectExceptionTest):
636         (main):
637         * runtime/VM.cpp:
638         (JSC::VM::throwException):
639
640 2013-09-10  Mark Lam  <mark.lam@apple.com>
641
642         Fix some indentation in Interpreter.cpp.
643         https://bugs.webkit.org/show_bug.cgi?id=121136.
644
645         Reviewed by Darin Adler.
646
647         * interpreter/Interpreter.cpp:
648         (JSC::UnwindFunctor::operator()):
649
650 2013-09-10  Mark Hahnenberg  <mhahnenberg@apple.com>
651
652         MapData has some issues
653         https://bugs.webkit.org/show_bug.cgi?id=121118
654
655         Reviewed by Geoffrey Garen.
656
657         * heap/CopiedBlock.h: Added some debug-only consistency checking logic. We now make sure that 
658         m_liveBytes is consistent with another field, m_liveObjects. m_liveObjects is the number of 
659         "objects" that currently reside in the CopiedBlock. If we have zero live bytes then we should have
660         zero live objects. The converse and the inverse should also be true.
661         (JSC::CopiedBlock::CopiedBlock):
662         (JSC::CopiedBlock::didSurviveGC):
663         (JSC::CopiedBlock::didEvacuateBytes):
664         (JSC::CopiedBlock::canBeRecycled):
665         (JSC::CopiedBlock::shouldEvacuate):
666         (JSC::CopiedBlock::liveBytes):
667         (JSC::CopiedBlock::checkConsistency):
668         * heap/CopiedBlockInlines.h:
669         (JSC::CopiedBlock::reportLiveBytes):
670         * heap/CopyVisitorInlines.h:
671         (JSC::CopyVisitor::didCopy):
672         * runtime/MapData.cpp:
673         (JSC::MapData::replaceAndPackBackingStore): Renamed parameter to be consistent with its meaning.
674         (JSC::MapData::replaceBackingStore): Ditto. Also removed an unnecessary local variable.
675         (JSC::MapData::visitChildren): Before we passed the size of the MapData to copyLater(), which 
676         was wrong. Now we pass capacity * sizeof(Entry).
677         (JSC::MapData::copyBackingStore): Before when we reassigned the newly copied backing store, we 
678         set the capacity (in elements) to the size (in bytes) of the backing store. This made us think 
679         we're way bigger than we actually are. Now we just pass the old capacity in.
680         * runtime/MapData.h:
681         (JSC::MapData::capacityInBytes): Helper function to calculate the size of the backing store.
682
683 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
684
685         We should say Int32 when we mean Int32. Saying Integer is just weird.
686
687         Rubber stamped by Mark Hahnenberg.
688
689         * dfg/DFGAbstractInterpreterInlines.h:
690         (JSC::DFG::::executeEffects):
691         * dfg/DFGFixupPhase.cpp:
692         (JSC::DFG::FixupPhase::fixupNode):
693         (JSC::DFG::FixupPhase::fixupToPrimitive):
694         (JSC::DFG::FixupPhase::fixIntEdge):
695         (JSC::DFG::FixupPhase::truncateConstantsIfNecessary):
696         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
697         * dfg/DFGGraph.h:
698         (JSC::DFG::Graph::addSpeculationMode):
699         (JSC::DFG::Graph::valueAddSpeculationMode):
700         (JSC::DFG::Graph::arithAddSpeculationMode):
701         (JSC::DFG::Graph::addShouldSpeculateInt32):
702         (JSC::DFG::Graph::mulShouldSpeculateInt32):
703         (JSC::DFG::Graph::negateShouldSpeculateInt32):
704         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
705         (JSC::DFG::Graph::mulImmediateShouldSpeculateInt32):
706         * dfg/DFGNode.h:
707         (JSC::DFG::Node::shouldSpeculateInt32):
708         (JSC::DFG::Node::shouldSpeculateInt32ForArithmetic):
709         (JSC::DFG::Node::shouldSpeculateInt32ExpectingDefined):
710         (JSC::DFG::Node::canSpeculateInt32):
711         * dfg/DFGNodeFlags.h:
712         (JSC::DFG::nodeCanSpeculateInt32):
713         * dfg/DFGPredictionPropagationPhase.cpp:
714         (JSC::DFG::PredictionPropagationPhase::propagate):
715         (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
716         * dfg/DFGSpeculativeJIT.cpp:
717         (JSC::DFG::SpeculativeJIT::arrayify):
718         (JSC::DFG::GPRTemporary::GPRTemporary):
719         (JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch):
720         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
721         (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
722         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
723         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
724         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
725         (JSC::DFG::SpeculativeJIT::compileAdd):
726         (JSC::DFG::SpeculativeJIT::compileArithSub):
727         (JSC::DFG::SpeculativeJIT::compileArithNegate):
728         (JSC::DFG::SpeculativeJIT::compileArithIMul):
729         (JSC::DFG::SpeculativeJIT::compileArithMul):
730         (JSC::DFG::SpeculativeJIT::compileArithDiv):
731         (JSC::DFG::SpeculativeJIT::compileArithMod):
732         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
733         (JSC::DFG::SpeculativeJIT::speculateInt32):
734         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
735         * dfg/DFGSpeculativeJIT.h:
736         (JSC::DFG::SpeculateInt32Operand::SpeculateInt32Operand):
737         (JSC::DFG::SpeculateInt32Operand::~SpeculateInt32Operand):
738         * dfg/DFGSpeculativeJIT32_64.cpp:
739         (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
740         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
741         (JSC::DFG::SpeculativeJIT::emitBranch):
742         (JSC::DFG::SpeculativeJIT::compile):
743         * dfg/DFGSpeculativeJIT64.cpp:
744         (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
745         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
746         (JSC::DFG::SpeculativeJIT::emitBranch):
747         (JSC::DFG::SpeculativeJIT::compile):
748         * ftl/FTLLowerDFGToLLVM.cpp:
749         (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
750         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
751
752 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
753
754         Introduce a SpecInt48 type and be more careful about what we mean by "Top"
755         https://bugs.webkit.org/show_bug.cgi?id=121116
756
757         Reviewed by Oliver Hunt.
758         
759         SpecInt48 will mean that we have something that would be a double if it was a JSValue,
760         but it's profitable to represent it as something other than a double.
761         
762         SpecInt48AsDouble means that it has a value that could have been represented like
763         SpecInt48, but we're making a heuristic decision not to do it.
764
765         * bytecode/SpeculatedType.h:
766         (JSC::isInt48Speculation):
767         * dfg/DFGAbstractInterpreterInlines.h:
768         (JSC::DFG::::executeEffects):
769         (JSC::DFG::::clobberCapturedVars):
770         * dfg/DFGAbstractValue.cpp:
771         (JSC::DFG::AbstractValue::filter):
772         * dfg/DFGAbstractValue.h:
773         (JSC::DFG::AbstractValue::makeHeapTop):
774         (JSC::DFG::AbstractValue::makeBytecodeTop):
775         (JSC::DFG::AbstractValue::isHeapTop):
776         (JSC::DFG::AbstractValue::heapTop):
777         (JSC::DFG::AbstractValue::validateType):
778         (JSC::DFG::AbstractValue::validate):
779         (JSC::DFG::AbstractValue::makeTop):
780         * dfg/DFGInPlaceAbstractState.cpp:
781         (JSC::DFG::InPlaceAbstractState::initialize):
782         * dfg/DFGJITCompiler.h:
783         (JSC::DFG::JITCompiler::noticeOSREntry):
784         * dfg/DFGUseKind.h:
785         (JSC::DFG::typeFilterFor):
786
787 2013-09-09  Oliver Hunt  <oliver@apple.com>
788
789         Support WeakMap
790         https://bugs.webkit.org/show_bug.cgi?id=120912
791
792         Reviewed by Geoffrey Garen.
793
794         Add support for ES6 WeakMap.  Add the cluster of boilerplate
795         classes around the core WeakMapData class.
796
797         WeakMapData is a simple object->value hash table that uses a
798         combo of WeakReferenceHarvester to conditionally keep the weak
799         value reference live, and UnconditionalFinalizer to clean the
800         dead keys from the table post-GC.
801
802         * CMakeLists.txt:
803         * GNUmakefile.list.am:
804         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
805         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
806         * JavaScriptCore.xcodeproj/project.pbxproj:
807         * Target.pri:
808         * runtime/CommonIdentifiers.h:
809         * runtime/JSGlobalObject.cpp:
810         * runtime/JSGlobalObject.h:
811         (JSC::JSGlobalObject::weakMapDataStructure):
812         * runtime/JSWeakMap.cpp: Added.
813         (JSC::JSWeakMap::finishCreation):
814         (JSC::JSWeakMap::visitChildren):
815         * runtime/JSWeakMap.h: Added.
816         (JSC::JSWeakMap::createStructure):
817         (JSC::JSWeakMap::create):
818         (JSC::JSWeakMap::weakMapData):
819         (JSC::JSWeakMap::JSWeakMap):
820         * runtime/WeakMapConstructor.cpp: Added.
821         (JSC::WeakMapConstructor::finishCreation):
822         (JSC::constructWeakMap):
823         (JSC::WeakMapConstructor::getConstructData):
824         (JSC::WeakMapConstructor::getCallData):
825         * runtime/WeakMapConstructor.h: Added.
826         (JSC::WeakMapConstructor::create):
827         (JSC::WeakMapConstructor::createStructure):
828         (JSC::WeakMapConstructor::WeakMapConstructor):
829         * runtime/WeakMapData.cpp: Added.
830         (JSC::WeakMapData::WeakMapData):
831         (JSC::WeakMapData::finishCreation):
832         (JSC::WeakMapData::destroy):
833         (JSC::WeakMapData::visitChildren):
834         (JSC::WeakMapData::set):
835         (JSC::WeakMapData::get):
836         (JSC::WeakMapData::remove):
837         (JSC::WeakMapData::contains):
838         (JSC::WeakMapData::clear):
839         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
840         (JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
841         * runtime/WeakMapData.h: Added.
842         (JSC::WeakMapData::create):
843         (JSC::WeakMapData::createStructure):
844         (JSC::WeakMapData::DeadKeyCleaner::DeadKeyCleaner):
845         * runtime/WeakMapPrototype.cpp: Added.
846         (JSC::WeakMapPrototype::finishCreation):
847         (JSC::getWeakMapData):
848         (JSC::protoFuncWeakMapClear):
849         (JSC::protoFuncWeakMapDelete):
850         (JSC::protoFuncWeakMapGet):
851         (JSC::protoFuncWeakMapHas):
852         (JSC::protoFuncWeakMapSet):
853         * runtime/WeakMapPrototype.h: Added.
854         (JSC::WeakMapPrototype::create):
855         (JSC::WeakMapPrototype::createStructure):
856         (JSC::WeakMapPrototype::WeakMapPrototype):
857
858 2013-09-10  Joseph Pecoraro  <pecoraro@apple.com>
859
860         Web Inspector: [JSC] Caught exception is treated as uncaught
861         https://bugs.webkit.org/show_bug.cgi?id=93607
862
863         Reviewed by Geoff Garen.
864
865         Check up the entire call stack to see if there is an exception handler.
866
867         * interpreter/Interpreter.cpp:
868         (JSC::GetExceptionHandlerFunctor::GetExceptionHandlerFunctor):
869         (JSC::GetExceptionHandlerFunctor::handler):
870         (JSC::GetExceptionHandlerFunctor::operator()):
871
872 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
873
874         SpecType should have SpecInt48AsDouble
875         https://bugs.webkit.org/show_bug.cgi?id=121065
876
877         Reviewed by Oliver Hunt.
878
879         * bytecode/SpeculatedType.cpp:
880         (JSC::dumpSpeculation):
881         (JSC::speculationToAbbreviatedString):
882         (JSC::speculationFromValue):
883         * bytecode/SpeculatedType.h:
884         (JSC::isInt48AsDoubleSpeculation):
885         (JSC::isIntegerSpeculation):
886         (JSC::isDoubleRealSpeculation):
887
888 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
889
890         Don't GC while in the OSR-triggered jettison code
891         https://bugs.webkit.org/show_bug.cgi?id=121106
892
893         Reviewed by Mark Hahnenberg.
894
895         * dfg/DFGOperations.cpp:
896
897 2013-09-10  Filip Pizlo  <fpizlo@apple.com>
898
899         jsc commandline's run() function should take extra arguments
900         https://bugs.webkit.org/show_bug.cgi?id=121098
901
902         Reviewed by Michael Saboff.
903
904         * jsc.cpp:
905         (functionRun):
906
907 2013-09-09  Michael Saboff  <msaboff@apple.com>
908
909         There should be one "invalid" virtual register constant
910         https://bugs.webkit.org/show_bug.cgi?id=121057
911
912         Reviewed by Filip Pizlo.
913
914         Unify all references to an invalid virtual register to be the enum InvalidVirtualRegister.
915         Changed the value of InvalidVirtualRegister to be maximum integer value.
916
917         * bytecode/CodeBlock.h:
918         (JSC::CodeBlock::setArgumentsRegister):
919         (JSC::CodeBlock::usesArguments):
920         * bytecode/LazyOperandValueProfile.h:
921         (JSC::LazyOperandValueProfileKey::LazyOperandValueProfileKey):
922         (JSC::LazyOperandValueProfileKey::operator!):
923         (JSC::LazyOperandValueProfileKey::isHashTableDeletedValue):
924         (JSC::LazyOperandValueProfile::LazyOperandValueProfile):
925         * bytecode/UnlinkedCodeBlock.cpp:
926         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
927         * bytecode/UnlinkedCodeBlock.h:
928         (JSC::UnlinkedCodeBlock::usesArguments):
929         (JSC::UnlinkedCodeBlock::usesGlobalObject):
930         * bytecode/VirtualRegister.h:
931
932 2013-09-09  Michael Saboff  <msaboff@apple.com>
933
934         Change virtual register function arguments from unsigned to int
935         https://bugs.webkit.org/show_bug.cgi?id=121055
936
937         Reviewed by Filip Pizlo.
938
939         This is a largely mechanical change.  This changes function paramaters and local variables used to
940         represent bytecode operands from being unsigned to be int.
941
942         * bytecode/CodeOrigin.h:
943         * dfg/DFGByteCodeParser.cpp:
944         * jit/JIT.h:
945         * jit/JITArithmetic.cpp:
946         * jit/JITArithmetic32_64.cpp:
947         * jit/JITInlines.h:
948         * jit/JITOpcodes.cpp:
949         * jit/JITOpcodes32_64.cpp:
950         * jit/JITPropertyAccess.cpp:
951         * jit/JITPropertyAccess32_64.cpp:
952         * jit/JITStubCall.h:
953
954 2013-09-09  Michael Saboff  <msaboff@apple.com>
955
956         Add local to/from operand helpers similar to argument to/from operand2
957         https://bugs.webkit.org/show_bug.cgi?id=121056
958
959         Reviewed by Geoffrey Garen.
960
961         Added localToOperand(), operandToLocal() and operandIsLocal() to Operands.h, very similar to
962         argumentToOperand(), et al.  Used the new helpers everywhere where an index into a data
963         structure is intended instead of the actual virtual register offset.  When the stack is
964         changed to grow down, local register offsets can be negative.  Also added the helper
965         DFG::SpeculativeJIT::generationInfoFromVirtualRegister() for the common case accessing 
966         m_generationInfo[operandToLocal(val)].
967
968         * bytecode/CodeBlock.cpp:
969         * bytecode/CodeBlock.h:
970         * bytecode/Operands.h:
971         (JSC::localToOperand):
972         (JSC::operandIsLocal):
973         (JSC::operandToLocal):
974         * bytecompiler/BytecodeGenerator.h:
975         * dfg/DFGAbstractInterpreterInlines.h:
976         * dfg/DFGByteCodeParser.cpp:
977         * dfg/DFGCFGSimplificationPhase.cpp:
978         * dfg/DFGCPSRethreadingPhase.cpp:
979         * dfg/DFGOSREntry.cpp:
980         * dfg/DFGOSRExitCompiler32_64.cpp:
981         * dfg/DFGOSRExitCompiler64.cpp:
982         * dfg/DFGScoreBoard.h:
983         * dfg/DFGSpeculativeJIT.cpp:
984         * dfg/DFGSpeculativeJIT.h:
985         (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
986         * dfg/DFGSpeculativeJIT32_64.cpp:
987         * dfg/DFGSpeculativeJIT64.cpp:
988         * dfg/DFGValidate.cpp:
989         * dfg/DFGVariableEventStream.cpp:
990         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
991         * jit/JITInlines.h:
992         * jit/JITOpcodes.cpp:
993         * jit/JITOpcodes32_64.cpp:
994
995 2013-09-09  Filip Pizlo  <fpizlo@apple.com>
996
997         Unreviewed, disable GC logging.
998
999         * heap/Heap.cpp:
1000
1001 2013-09-09  Mark Hahnenberg  <mhahnenberg@apple.com>
1002
1003         CopiedSpace::startedCopying should not call MarkedSpace::capacity
1004         https://bugs.webkit.org/show_bug.cgi?id=121045
1005
1006         Reviewed by Geoffrey Garen.
1007
1008         MarkedSpace::capacity() iterates every block in MarkedSpace. Instead we should just 
1009         keep track of our total capacity in MarkedSpace as we add and remove MarkedBlocks.
1010
1011         * heap/MarkedSpace.cpp:
1012         (JSC::MarkedSpace::freeBlock):
1013         * heap/MarkedSpace.h:
1014         (JSC::MarkedSpace::didAddBlock):
1015         (JSC::MarkedSpace::capacity):
1016
1017 2013-09-09  Michael Saboff  <msaboff@apple.com>
1018
1019         Wrong for SlowPathCall to load callFrame reg from vm.topCallFrame after call
1020         https://bugs.webkit.org/show_bug.cgi?id=120537
1021
1022         Reviewed by Geoffrey Garen.
1023
1024         Changed JITSlowPathCall::call() to update vm.topCallFrame from the callFrameRegister instead of the
1025         other way around.
1026
1027         * jit/JIT.h:
1028         * jit/JITInlines.h:
1029         * jit/SlowPathCall.h:
1030         (JSC::JITSlowPathCall::call):
1031
1032 2013-08-29  Mark Hahnenberg  <mhahnenberg@apple.com>
1033
1034         JSArray::shiftCountWithArrayStorage doesn't change indexBias when shifting the last element in m_vector
1035         https://bugs.webkit.org/show_bug.cgi?id=120389
1036
1037         Reviewed by Michael Saboff.
1038
1039         Went through and cleaned up shiftCountWithArrayStorage. Gave meaningful variable names
1040         and commented the confusing parts. This led to realizing how to fix this bug, which has
1041         been done. The issue was that we were modifying the vector length unconditionally, even
1042         when we weren't logically changing the length of the vector. Instead, we should only modify
1043         the vector length when we modify the index bias.
1044
1045         * runtime/JSArray.cpp:
1046         (JSC::JSArray::shiftCountWithArrayStorage):
1047
1048 2013-09-08  Anders Carlsson  <andersca@apple.com>
1049
1050         Begin moving off of TypeTraits.h
1051         https://bugs.webkit.org/show_bug.cgi?id=121006
1052
1053         Reviewed by Darin Adler.
1054
1055         Convert uses of WTF type traits to STL type traits.
1056
1057         * heap/PassWeak.h:
1058         * runtime/JSCell.h:
1059         (JSC::jsCast):
1060         (JSC::jsDynamicCast):
1061         * runtime/WriteBarrier.h:
1062         (JSC::validateCell):
1063
1064 2013-09-08  Mark Hahnenberg  <mhahnenberg@apple.com>
1065
1066         Calculating the size of the Heap should not require walking over it
1067         https://bugs.webkit.org/show_bug.cgi?id=120910
1068
1069         Reviewed by Geoffrey Garen.
1070
1071         Currently Heap::size() is O(sizeof(Heap)). This is too expensive to 
1072         call during a collection. We should keep a count of visited and copied 
1073         bytes as each collection progresses so as to avoid re-walking the Heap 
1074         at the end of collection.
1075
1076         * heap/GCThreadSharedData.cpp:
1077         (JSC::GCThreadSharedData::childBytesVisited):
1078         (JSC::GCThreadSharedData::childBytesCopied):
1079         * heap/GCThreadSharedData.h:
1080         * heap/Heap.cpp:
1081         (JSC::Heap::Heap):
1082         (JSC::Heap::markRoots):
1083         (JSC::Heap::sizeAfterCollect):
1084         (JSC::Heap::collect):
1085         * heap/Heap.h:
1086         * heap/SlotVisitor.cpp:
1087         (JSC::SlotVisitor::SlotVisitor):
1088         (JSC::SlotVisitor::reset):
1089         * heap/SlotVisitor.h:
1090         (JSC::SlotVisitor::bytesVisited):
1091         (JSC::SlotVisitor::bytesCopied):
1092         * heap/SlotVisitorInlines.h:
1093         (JSC::SlotVisitor::internalAppend):
1094         (JSC::SlotVisitor::copyLater):
1095
1096 2013-09-08  Mark Hahnenberg  <mhahnenberg@apple.com>
1097
1098         Clearing MarkedBlock::m_newlyAllocated should be separate from MarkedBlock::clearMarks
1099         https://bugs.webkit.org/show_bug.cgi?id=121007
1100
1101         Reviewed by Oliver Hunt.
1102
1103         We call clearMarks on every MarkedBlock in the Heap, whereas we only need to clear 
1104         m_newlyAllocated for the m_currentBlock at the time of the last canonicalizeCellLiveness() 
1105         for each MarkedAllocator. We also need to call it on every block in the largeAllocators 
1106         because each one of their blocks is canonicalized as it is used.
1107
1108         * heap/Heap.cpp:
1109         (JSC::Heap::markRoots):
1110         * heap/MarkedAllocator.h:
1111         (JSC::MarkedAllocator::getAndClearCanonicalizedBlock):
1112         (JSC::MarkedAllocator::MarkedAllocator):
1113         (JSC::MarkedAllocator::canonicalizeCellLivenessData):
1114         * heap/MarkedBlock.h:
1115         (JSC::MarkedBlock::lastChanceToFinalize):
1116         (JSC::MarkedBlock::clearMarks):
1117         (JSC::MarkedBlock::clearNewlyAllocated):
1118         * heap/MarkedSpace.cpp:
1119         (JSC::clearNewlyAllocatedInBlock):
1120         (JSC::ClearNewlyAllocated::operator()):
1121         (JSC::MarkedSpace::clearNewlyAllocated):
1122         * heap/MarkedSpace.h:
1123
1124 2013-09-07  Filip Pizlo  <fpizlo@apple.com>
1125
1126         FTL should support typed array PutByVal
1127         https://bugs.webkit.org/show_bug.cgi?id=120972
1128
1129         Reviewed by Oliver Hunt.
1130
1131         Due to increased FTL coverage, this revealed a bug in LICM where we were trying to
1132         have AI execute the tail of a block that !cfaDidFinish. We don't need to execute AI
1133         for such blocks since LICM will bail for them anyway, and AI asserts that cfaDidFinish
1134         is true.
1135
1136         * dfg/DFGLICMPhase.cpp:
1137         (JSC::DFG::LICMPhase::attemptHoist):
1138         * ftl/FTLAbbreviations.h:
1139         (JSC::FTL::buildFPToUI):
1140         * ftl/FTLCapabilities.cpp:
1141         (JSC::FTL::canCompile):
1142         * ftl/FTLIntrinsicRepository.h:
1143         * ftl/FTLLowerDFGToLLVM.cpp:
1144         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
1145         (JSC::FTL::LowerDFGToLLVM::doubleToInt32):
1146         (JSC::FTL::LowerDFGToLLVM::doubleToUInt32):
1147         * ftl/FTLOutput.h:
1148         (JSC::FTL::Output::fpToUInt):
1149         (JSC::FTL::Output::fpToUInt32):
1150         (JSC::FTL::Output::store8):
1151         (JSC::FTL::Output::store16):
1152         (JSC::FTL::Output::storeFloat):
1153
1154 2013-09-07  Filip Pizlo  <fpizlo@apple.com>
1155
1156         FTL should support basic closure operations
1157         https://bugs.webkit.org/show_bug.cgi?id=120987
1158
1159         Reviewed by Oliver Hunt.
1160
1161         * ftl/FTLAbstractHeapRepository.cpp:
1162         * ftl/FTLAbstractHeapRepository.h:
1163         * ftl/FTLCapabilities.cpp:
1164         (JSC::FTL::canCompile):
1165         * ftl/FTLLowerDFGToLLVM.cpp:
1166         (JSC::FTL::LowerDFGToLLVM::compileNode):
1167         (JSC::FTL::LowerDFGToLLVM::compileGetMyScope):
1168         (JSC::FTL::LowerDFGToLLVM::compileSkipScope):
1169         (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters):
1170         (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
1171         (JSC::FTL::LowerDFGToLLVM::compilePutClosureVar):
1172
1173 2013-09-07  Filip Pizlo  <fpizlo@apple.com>
1174
1175         Only run FTL tests if we have the FTL
1176         https://bugs.webkit.org/show_bug.cgi?id=120974
1177
1178         Reviewed by Geoffrey Garen.
1179         
1180         The test infrastructure is now smart enough to not pass --useExperimentalFTL=true
1181         unless it knows that we have the FTL.
1182
1183         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1184         (JSC::DFG::TierUpCheckInjectionPhase::run):
1185
1186 2013-09-07  Anders Carlsson  <andersca@apple.com>
1187
1188         Get rid of PassOwnArrayPtr
1189         https://bugs.webkit.org/show_bug.cgi?id=120964
1190
1191         Reviewed by Andreas Kling.
1192
1193         Use OwnArrayPtr instead of PassOwnArrayPtr.
1194
1195         * bytecompiler/BytecodeGenerator.cpp:
1196         (JSC::BytecodeGenerator::BytecodeGenerator):
1197         * runtime/SymbolTable.h:
1198         (JSC::SharedSymbolTable::setSlowArguments):
1199
1200 2013-09-07  Filip Pizlo  <fpizlo@apple.com>
1201
1202         FTL should support typed array GetByVal and related ops
1203         https://bugs.webkit.org/show_bug.cgi?id=120965
1204
1205         Reviewed by Oliver Hunt.
1206         
1207         This adds support for typed array instantiations of the following DFG IR ops:
1208         
1209         - GetByVal
1210         
1211         - GetIndexedPropertyStorage
1212         
1213         - CheckArray
1214         
1215         - GetArrayLength
1216         
1217         This also adds CheckArray for Int32/Double/Contiguous arrays.
1218
1219         * dfg/DFGArrayMode.cpp:
1220         (JSC::DFG::toIndexingShape):
1221         * dfg/DFGArrayMode.h:
1222         (JSC::DFG::ArrayMode::shapeMask):
1223         * ftl/FTLAbbreviations.h:
1224         (JSC::FTL::floatType):
1225         (JSC::FTL::buildSExt):
1226         (JSC::FTL::buildFPCast):
1227         * ftl/FTLAbstractHeapRepository.h:
1228         * ftl/FTLCapabilities.cpp:
1229         (JSC::FTL::canCompile):
1230         * ftl/FTLCommonValues.cpp:
1231         (JSC::FTL::CommonValues::CommonValues):
1232         * ftl/FTLCommonValues.h:
1233         * ftl/FTLLowerDFGToLLVM.cpp:
1234         (JSC::FTL::LowerDFGToLLVM::compileNode):
1235         (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
1236         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
1237         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
1238         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1239         (JSC::FTL::LowerDFGToLLVM::isArrayType):
1240         (JSC::FTL::LowerDFGToLLVM::hasClassInfo):
1241         * ftl/FTLOutput.h:
1242         (JSC::FTL::Output::constIntPtr):
1243         (JSC::FTL::Output::signExt):
1244         (JSC::FTL::Output::fpCast):
1245         (JSC::FTL::Output::loadFloat):
1246
1247 2013-09-07  Anders Carlsson  <andersca@apple.com>
1248
1249         VectorMover should use std::move
1250         https://bugs.webkit.org/show_bug.cgi?id=120959
1251
1252         Reviewed by Geoffrey Garen.
1253
1254         Work around a bug in GCC by changing the type of the callType bitfield 
1255         in CallLinkInfo to be unsigned instead of CallType.
1256
1257         * bytecode/CallLinkInfo.h:
1258
1259 2013-09-07  Anders Carlsson  <andersca@apple.com>
1260
1261         Get rid of FastAllocBase.h
1262         https://bugs.webkit.org/show_bug.cgi?id=120952
1263
1264         Reviewed by Antti Koivisto.
1265
1266         Include FastMalloc.h instead of FastAllocBase.h.
1267
1268         * assembler/LinkBuffer.h:
1269         * bytecode/CodeBlock.h:
1270         * bytecode/StructureStubClearingWatchpoint.h:
1271         * dfg/DFGFinalizer.h:
1272         * dfg/DFGLongLivedState.h:
1273         * dfg/DFGSlowPathGenerator.h:
1274         * ftl/FTLAbstractHeap.h:
1275         * heap/JITStubRoutineSet.h:
1276         * jit/CompactJITCodeMap.h:
1277         * profiler/ProfilerDatabase.h:
1278         * profiler/ProfilerExecutionCounter.h:
1279
1280 2013-09-06  Filip Pizlo  <fpizlo@apple.com>
1281
1282         FTL should support Call/Construct in the worst way possible
1283         https://bugs.webkit.org/show_bug.cgi?id=120916
1284
1285         Reviewed by Oliver Hunt.
1286         
1287         This adds support for Call/Construct by just calling out to C code that uses
1288         the JSC::call/JSC::construct runtime functions for making calls. This is slow
1289         and terrible, but it dramatically extends FTL coverage.
1290         
1291         Supporting calls in a meaningful way meant also supporting
1292         GlobalVarWatchpoint.
1293         
1294         The extension of coverage helped to find a bunch of bugs:
1295         
1296         - ObjectOrOtherUse was claimed to be supported in the FTL but speculate()
1297           didn't support it. That means that any node with an ObjectOrOtherUse edge
1298           that got DCE'd would cause the FTL to ICE.
1299         
1300         - There was a bad fall-through compileCompareStrictEq() that led to ICE.
1301         
1302         - The OSR exit reconstruction code was assuming it could do fast checks on
1303           node->child1() before even determining the type of node; that crashes if
1304           the node is HasVarArgs. Fixed by checking HasVarArgs first.
1305         
1306         - The OSR exit compiler was using the wrong peekOffset for CArgumentGetter.
1307           The default is 1, which assumes that you didn't push anything onto the
1308           stack after getting called. The OSR exit thunks push FP, so the offset
1309           should be 2.
1310         
1311         This passes stress tests and is probably huge performance regression if you
1312         --useExperimentalFTL=true. The regression will be fixed in
1313         https://bugs.webkit.org/show_bug.cgi?id=113621.
1314
1315         * dfg/DFGOperations.cpp:
1316         * dfg/DFGOperations.h:
1317         * ftl/FTLCapabilities.cpp:
1318         (JSC::FTL::canCompile):
1319         * ftl/FTLIntrinsicRepository.h:
1320         * ftl/FTLLowerDFGToLLVM.cpp:
1321         (JSC::FTL::LowerDFGToLLVM::compileNode):
1322         (JSC::FTL::LowerDFGToLLVM::compileGlobalVarWatchpoint):
1323         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
1324         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
1325         (JSC::FTL::LowerDFGToLLVM::speculate):
1326         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
1327         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
1328         * ftl/FTLOSRExitCompiler.cpp:
1329         (JSC::FTL::compileStub):
1330
1331 2013-09-06  Filip Pizlo  <fpizlo@apple.com>
1332
1333         jsc shell should destroy VM as a workaround for LLVM's exit-time destructors
1334         https://bugs.webkit.org/show_bug.cgi?id=120921
1335
1336         Reviewed by Oliver Hunt.
1337         
1338         LLVM's exit-time destructors will fire when we exit. If there is an on-going
1339         FTL compile at exit, which will happen if the VM that triggered the compile
1340         isn't shut down, then we will crash.
1341         
1342         We should get rid of LLVM's exit-time destructors. But before we do that, we
1343         should just do a clean VM shutdown to suppress spurious crashes. This will
1344         help in expanding LLVM coverage for now.
1345
1346         * jsc.cpp:
1347         (jscmain):
1348
1349 2013-09-06  Filip Pizlo  <fpizlo@apple.com>
1350
1351         FTL ArithMod Int32Use doesn't check for negative zero correctly
1352         https://bugs.webkit.org/show_bug.cgi?id=120905
1353
1354         Reviewed by Mark Hahnenberg.
1355
1356         * ftl/FTLLowerDFGToLLVM.cpp:
1357         (JSC::FTL::LowerDFGToLLVM::compileArithMod):
1358
1359 2013-09-06  Filip Pizlo  <fpizlo@apple.com>
1360
1361         FTL ArithNeg Int32Use doesn't check negative zero
1362         https://bugs.webkit.org/show_bug.cgi?id=120900
1363
1364         Reviewed by Mark Hahnenberg.
1365
1366         * ftl/FTLLowerDFGToLLVM.cpp:
1367         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
1368
1369 2013-09-06  Anders Carlsson  <andersca@apple.com>
1370
1371         Stop using fastNew/fastDelete in JavaScriptCore
1372         https://bugs.webkit.org/show_bug.cgi?id=120898
1373
1374         Reviewed by Oliver Hunt.
1375
1376         Change all the hash table members in ExecState to be OwnPtrs and use
1377         adoptPtr instead. Also, since none of the hash tables can be null, change their getters
1378         to return references and propagate the reference types wherever we know that a HashTable can't be null.
1379
1380         * interpreter/CallFrame.h:
1381         (JSC::ExecState::arrayConstructorTable):
1382         (JSC::ExecState::arrayPrototypeTable):
1383         (JSC::ExecState::booleanPrototypeTable):
1384         (JSC::ExecState::dataViewTable):
1385         (JSC::ExecState::dateTable):
1386         (JSC::ExecState::dateConstructorTable):
1387         (JSC::ExecState::errorPrototypeTable):
1388         (JSC::ExecState::globalObjectTable):
1389         (JSC::ExecState::jsonTable):
1390         (JSC::ExecState::numberConstructorTable):
1391         (JSC::ExecState::numberPrototypeTable):
1392         (JSC::ExecState::objectConstructorTable):
1393         (JSC::ExecState::privateNamePrototypeTable):
1394         (JSC::ExecState::regExpTable):
1395         (JSC::ExecState::regExpConstructorTable):
1396         (JSC::ExecState::regExpPrototypeTable):
1397         (JSC::ExecState::stringConstructorTable):
1398         (JSC::ExecState::promisePrototypeTable):
1399         (JSC::ExecState::promiseConstructorTable):
1400         (JSC::ExecState::promiseResolverPrototypeTable):
1401         * runtime/ClassInfo.h:
1402         (JSC::ClassInfo::propHashTable):
1403         * runtime/Lookup.h:
1404         (JSC::getStaticPropertySlot):
1405         (JSC::getStaticFunctionSlot):
1406         (JSC::getStaticValueSlot):
1407         (JSC::lookupPut):
1408         * runtime/VM.cpp:
1409         (JSC::VM::VM):
1410         (JSC::VM::~VM):
1411         * runtime/VM.h:
1412
1413 2013-09-06  Filip Pizlo  <fpizlo@apple.com>
1414
1415         Concurrent FTL causes !hasOptimizedReplacement() asserts in cti_optimize
1416         https://bugs.webkit.org/show_bug.cgi?id=120890
1417
1418         Reviewed by Mark Hahnenberg.
1419         
1420         Don't install an FTL code block if the DFG code block has already been jettisoned.
1421
1422         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
1423         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1424
1425 2013-09-06  Filip Pizlo  <fpizlo@apple.com>
1426
1427         REGRESSION(149636, merged in 153145): ToThis conversion doesn't work in the DFG
1428         https://bugs.webkit.org/show_bug.cgi?id=120781
1429
1430         Reviewed by Mark Hahnenberg.
1431         
1432         Roll this back in with a build fix.
1433         
1434         - Use some method table hacks to detect if the CheckStructure optimization is
1435           valid for to_this.
1436         
1437         - Introduce a FinalObjectUse and use it for ToThis->Identity conversion.
1438         
1439         This looks like it might be perf-neutral on the major benchmarks, but it
1440         introduces some horrible performance cliffs. For example if you add methods to
1441         the Array prototype, you'll get horrible performance cliffs. As in virtual calls
1442         to C++ every time you call a JS function even if it's inlined.
1443         LongSpider/3d-cube appears to hit this.
1444
1445         * dfg/DFGAbstractInterpreterInlines.h:
1446         (JSC::DFG::::executeEffects):
1447         * dfg/DFGByteCodeParser.cpp:
1448         (JSC::DFG::ByteCodeParser::parseBlock):
1449         * dfg/DFGFixupPhase.cpp:
1450         (JSC::DFG::FixupPhase::fixupNode):
1451         * dfg/DFGRepatch.cpp:
1452         (JSC::DFG::emitPutTransitionStub):
1453         * dfg/DFGSafeToExecute.h:
1454         (JSC::DFG::SafeToExecuteEdge::operator()):
1455         * dfg/DFGSpeculativeJIT.cpp:
1456         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1457         (JSC::DFG::SpeculativeJIT::speculate):
1458         * dfg/DFGSpeculativeJIT.h:
1459         * dfg/DFGSpeculativeJIT32_64.cpp:
1460         (JSC::DFG::SpeculativeJIT::compile):
1461         * dfg/DFGSpeculativeJIT64.cpp:
1462         (JSC::DFG::SpeculativeJIT::compile):
1463         * dfg/DFGUseKind.cpp:
1464         (WTF::printInternal):
1465         * dfg/DFGUseKind.h:
1466         (JSC::DFG::typeFilterFor):
1467         (JSC::DFG::isCell):
1468
1469 2013-09-05  Filip Pizlo  <fpizlo@apple.com>
1470
1471         Introduce a way to run benchmarks and JSRegress as stress tests with different jsc command-line options
1472         https://bugs.webkit.org/show_bug.cgi?id=120808
1473
1474         Reviewed by Mark Hahnenberg and rubber stamped by Geoffrey Garen.
1475         
1476         Allow --useExperimentalFTL=true even if FTL isn't built since this simplifies
1477         testing.
1478
1479         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1480         (JSC::DFG::TierUpCheckInjectionPhase::run):
1481
1482 2013-09-06  Zan Dobersek  <zdobersek@igalia.com>
1483
1484         Unreviewed build fix for the GTK port when building with FTL JIT enabled.
1485
1486         * GNUmakefile.list.am: Add the missing files to the build.
1487
1488 2013-09-05  Oliver Hunt  <oliver@apple.com>
1489
1490         Make it simpler to introduce new data types to the global object
1491         https://bugs.webkit.org/show_bug.cgi?id=120801
1492
1493         Reviewed by Gavin Barraclough.
1494
1495         Add an iterator macro that lists all the "simple" ES types (e.g. type
1496         consists of instance, constructor, and prototype classes).  So that
1497         we don't need to have every new type litter JSGlobalObject.{cpp,h} with
1498         members, accessors, and manual GC visiting.
1499
1500         * runtime/JSGlobalObject.cpp:
1501         (JSC::JSGlobalObject::visitChildren):
1502         * runtime/JSGlobalObject.h:
1503
1504 2013-09-05  Mark Rowe  <mrowe@apple.com>
1505         
1506         Roll out r155149 since it broke the build.
1507
1508 2013-09-05  Michael Saboff  <msaboff@apple.com>
1509
1510         Cleanup formatting of byte code debug output
1511         Source/JavaScriptCore/ChangeLog
1512
1513         Rubber stamped by Filip Pizlo.
1514
1515         Put the formatting of the byte code offset and operation into one common function to
1516         simplify and unify formatting.  Changed CodeBlock::registerName() to return
1517         "thist" for argument register 0, "argN" for other argument registers and "locN" for
1518         local registers.
1519
1520         * bytecode/CodeBlock.cpp:
1521         (JSC::CodeBlock::registerName):
1522         (JSC::CodeBlock::printUnaryOp):
1523         (JSC::CodeBlock::printBinaryOp):
1524         (JSC::CodeBlock::printConditionalJump):
1525         (JSC::CodeBlock::printGetByIdOp):
1526         (JSC::CodeBlock::printCallOp):
1527         (JSC::CodeBlock::printPutByIdOp):
1528         (JSC::CodeBlock::dumpBytecode):
1529         * bytecode/CodeBlock.h:
1530         (JSC::CodeBlock::printLocationAndOp):
1531         (JSC::CodeBlock::printLocationOpAndRegisterOperand):
1532
1533 2013-09-05  Filip Pizlo  <fpizlo@apple.com>
1534
1535         REGRESSION(149636, merged in 153145): ToThis conversion doesn't work in the DFG
1536         https://bugs.webkit.org/show_bug.cgi?id=120781
1537
1538         Reviewed by Mark Hahnenberg.
1539         
1540         - Use some method table hacks to detect if the CheckStructure optimization is
1541           valid for to_this.
1542         
1543         - Introduce a FinalObjectUse and use it for ToThis->Identity conversion.
1544         
1545         This looks like it might be perf-neutral on the major benchmarks, but it
1546         introduces some horrible performance cliffs. For example if you add methods to
1547         the Array prototype, you'll get horrible performance cliffs. As in virtual calls
1548         to C++ every time you call a JS function even if it's inlined.
1549         LongSpider/3d-cube appears to hit this.
1550
1551         * dfg/DFGAbstractInterpreterInlines.h:
1552         (JSC::DFG::::executeEffects):
1553         * dfg/DFGByteCodeParser.cpp:
1554         (JSC::DFG::ByteCodeParser::parseBlock):
1555         * dfg/DFGFixupPhase.cpp:
1556         (JSC::DFG::FixupPhase::fixupNode):
1557         * dfg/DFGSafeToExecute.h:
1558         (JSC::DFG::SafeToExecuteEdge::operator()):
1559         * dfg/DFGSpeculativeJIT.cpp:
1560         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1561         (JSC::DFG::SpeculativeJIT::speculate):
1562         * dfg/DFGSpeculativeJIT.h:
1563         * dfg/DFGSpeculativeJIT32_64.cpp:
1564         (JSC::DFG::SpeculativeJIT::compile):
1565         * dfg/DFGSpeculativeJIT64.cpp:
1566         (JSC::DFG::SpeculativeJIT::compile):
1567         * dfg/DFGUseKind.cpp:
1568         (WTF::printInternal):
1569         * dfg/DFGUseKind.h:
1570         (JSC::DFG::typeFilterFor):
1571         (JSC::DFG::isCell):
1572
1573 2013-09-05  Anders Carlsson  <andersca@apple.com>
1574
1575         GCAssertions.h should use STL type traits and static_assert
1576         https://bugs.webkit.org/show_bug.cgi?id=120785
1577
1578         Reviewed by Andreas Kling.
1579
1580         There's no need to rely on compiler specific support to figure out if a class is trivially destructable,
1581         we can just use type traits from STL. Do this, fix the assert macro to use static_assert directly and
1582         rename it from ASSERT_HAS_TRIVIAL_DESTRUCTOR to STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE to clarify that
1583         it's a static assert and to match the STL nomenclature.
1584         
1585         * API/JSCallbackFunction.cpp:
1586         * debugger/DebuggerActivation.cpp:
1587         * heap/GCAssertions.h:
1588         * runtime/ArrayConstructor.cpp:
1589         * runtime/BooleanConstructor.cpp:
1590         * runtime/BooleanObject.cpp:
1591         * runtime/BooleanPrototype.cpp:
1592         * runtime/DateConstructor.cpp:
1593         * runtime/ErrorConstructor.cpp:
1594         * runtime/ErrorInstance.cpp:
1595         * runtime/ErrorPrototype.cpp:
1596         * runtime/ExceptionHelpers.cpp:
1597         * runtime/FunctionConstructor.cpp:
1598         * runtime/FunctionPrototype.cpp:
1599         * runtime/GetterSetter.cpp:
1600         * runtime/InternalFunction.cpp:
1601         * runtime/JSAPIValueWrapper.cpp:
1602         * runtime/JSArray.cpp:
1603         * runtime/JSCell.cpp:
1604         * runtime/JSNotAnObject.cpp:
1605         * runtime/JSONObject.cpp:
1606         * runtime/JSObject.cpp:
1607         * runtime/JSPromiseConstructor.cpp:
1608         * runtime/JSPromisePrototype.cpp:
1609         * runtime/JSPromiseResolverConstructor.cpp:
1610         * runtime/JSPromiseResolverPrototype.cpp:
1611         * runtime/JSProxy.cpp:
1612         * runtime/JSScope.cpp:
1613         * runtime/JSWrapperObject.cpp:
1614         * runtime/MathObject.cpp:
1615         * runtime/NameConstructor.cpp:
1616         * runtime/NativeErrorConstructor.cpp:
1617         * runtime/NumberConstructor.cpp:
1618         * runtime/NumberObject.cpp:
1619         * runtime/NumberPrototype.cpp:
1620         * runtime/ObjectConstructor.cpp:
1621         * runtime/ObjectPrototype.cpp:
1622         * runtime/RegExpObject.cpp:
1623         * runtime/StrictEvalActivation.cpp:
1624         * runtime/StringConstructor.cpp:
1625         * runtime/StringObject.cpp:
1626         * runtime/StringPrototype.cpp:
1627
1628 2013-09-05  Brent Fulgham  <bfulgham@apple.com>
1629
1630         [Windows] Unreviewed build fix for DebugSuffix target.
1631
1632         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Don't build 64-bit assembly in 32-bit build.
1633         Also correct 'filters' file so that files appear in categories that match their on-disk locations.
1634
1635 2013-09-04  Filip Pizlo  <fpizlo@apple.com>
1636
1637         jsc tests should have timeouts
1638         https://bugs.webkit.org/show_bug.cgi?id=120725
1639
1640         Reviewed by Geoffrey Garen.
1641         
1642         Add the timeout logic directly to 'jsc' because that's easier to do than
1643         writing shell/perl code for it.
1644
1645         * jsc.cpp:
1646         (timeoutThreadMain):
1647         (main):
1648
1649 2013-09-04  Filip Pizlo  <fpizlo@apple.com>
1650
1651         fast/js/dfg-* tests should wait for the concurrent JIT
1652         https://bugs.webkit.org/show_bug.cgi?id=120723
1653
1654         Reviewed by Geoffrey Garen.
1655         
1656         * runtime/TestRunnerUtils.cpp:
1657         (JSC::numberOfDFGCompiles): This should also handle constructors.
1658
1659 2013-09-04  Filip Pizlo  <fpizlo@apple.com>
1660
1661         run-fast-jsc should work with new-school fast/js tests that loop until the DFG tiers up
1662         https://bugs.webkit.org/show_bug.cgi?id=120697
1663
1664         Reviewed by Mark Hahnenberg.
1665
1666         * API/JSCTestRunnerUtils.cpp:
1667         (JSC::numberOfDFGCompiles):
1668         (JSC::setNeverInline):
1669         * CMakeLists.txt:
1670         * GNUmakefile.list.am:
1671         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1672         * JavaScriptCore.xcodeproj/project.pbxproj:
1673         * Target.pri:
1674         * jsc.cpp:
1675         (GlobalObject::finishCreation):
1676         (functionNeverInlineFunction):
1677         (functionNumberOfDFGCompiles):
1678         * runtime/TestRunnerUtils.cpp: Added.
1679         (JSC::getExecutable):
1680         (JSC::numberOfDFGCompiles):
1681         (JSC::setNeverInline):
1682         * runtime/TestRunnerUtils.h: Added.
1683
1684 2013-09-04  Mark Lam  <mark.lam@apple.com>
1685
1686         Renamed StackIterator to StackVisitor.
1687         https://bugs.webkit.org/show_bug.cgi?id=120706.
1688
1689         Reviewed by Geoffrey Garen.
1690
1691         Also did some minor refactoring:
1692         - Renamed StackIterator::iterate() to StackVisitor::visit().
1693         - Make StackVisitor::visit() a static method.
1694         - Move the instantiation of the StackVisitor instance into StackVisitor::visit()
1695           from CallFrame::iterate().
1696         - Removed StackIterator::resetIterator() and inline its body into the
1697           StackVisitor constructor since this is the only remaining caller of it.
1698
1699         * API/JSContextRef.cpp:
1700         (BacktraceFunctor::operator()):
1701         * CMakeLists.txt:
1702         * GNUmakefile.list.am:
1703         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1704         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1705         * JavaScriptCore.xcodeproj/project.pbxproj:
1706         * Target.pri:
1707         * interpreter/CallFrame.h:
1708         (JSC::ExecState::iterate):
1709         * interpreter/Interpreter.cpp:
1710         (JSC::DumpRegisterFunctor::operator()):
1711         (JSC::unwindCallFrame):
1712         (JSC::getStackFrameCodeType):
1713         (JSC::GetStackTraceFunctor::operator()):
1714         (JSC::UnwindFunctor::operator()):
1715         * interpreter/Interpreter.h:
1716         * interpreter/StackIterator.cpp: Removed.
1717         * interpreter/StackIterator.h: Removed.
1718         * interpreter/StackVisitor.cpp: Copied from Source/JavaScriptCore/interpreter/StackIterator.cpp.
1719         (JSC::StackVisitor::StackVisitor):
1720         (JSC::StackVisitor::gotoNextFrame):
1721         (JSC::StackVisitor::readFrame):
1722         (JSC::StackVisitor::readNonInlinedFrame):
1723         (JSC::StackVisitor::readInlinedFrame):
1724         (JSC::StackVisitor::Frame::codeType):
1725         (JSC::StackVisitor::Frame::functionName):
1726         (JSC::StackVisitor::Frame::sourceURL):
1727         (JSC::StackVisitor::Frame::toString):
1728         (JSC::StackVisitor::Frame::arguments):
1729         (JSC::StackVisitor::Frame::computeLineAndColumn):
1730         (JSC::StackVisitor::Frame::retrieveExpressionInfo):
1731         (JSC::StackVisitor::Frame::setToEnd):
1732         (JSC::StackVisitor::Frame::print):
1733         (DebugPrintFrameFunctor::operator()):
1734         * interpreter/StackVisitor.h: Copied from Source/JavaScriptCore/interpreter/StackIterator.h.
1735         (JSC::StackVisitor::visit):
1736         * jsc.cpp:
1737         (FunctionJSCStackFunctor::operator()):
1738         * profiler/ProfileGenerator.cpp:
1739         (JSC::AddParentForConsoleStartFunctor::operator()):
1740         * runtime/JSFunction.cpp:
1741         (JSC::RetrieveArgumentsFunctor::operator()):
1742         (JSC::RetrieveCallerFunctionFunctor::operator()):
1743         * runtime/JSGlobalObjectFunctions.cpp:
1744         (JSC::GlobalFuncProtoGetterFunctor::operator()):
1745         (JSC::GlobalFuncProtoSetterFunctor::operator()):
1746         * runtime/ObjectConstructor.cpp:
1747         (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
1748
1749 2013-09-04  Roger Fong  <roger_fong@apple.com>
1750
1751         Unreviewed Build fix for Windows DebugSuffix configuration.
1752
1753         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1754         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1755
1756 2013-09-04  Mark Lam  <mark.lam@apple.com>
1757
1758         Refining the StackIterator callback interface.
1759         https://bugs.webkit.org/show_bug.cgi?id=120695.
1760
1761         Reviewed by Geoffrey Garen.
1762
1763         Introduce CallFrame::iterate() which instantiates a StackIterator and
1764         invoke its iterate() method with the passed in functor. The only place
1765         where the client code gets access to the StackIterator now is as an
1766         argument to the client's functor.
1767
1768         * API/JSContextRef.cpp:
1769         (JSContextCreateBacktrace):
1770         * interpreter/CallFrame.cpp:
1771         * interpreter/CallFrame.h:
1772         (JSC::ExecState::iterate):
1773         * interpreter/Interpreter.cpp:
1774         (JSC::Interpreter::dumpRegisters):
1775         (JSC::Interpreter::getStackTrace):
1776         (JSC::Interpreter::unwind):
1777         * interpreter/StackIterator.cpp:
1778         (JSC::StackIterator::StackIterator):
1779         (DebugPrintFrameFunctor::DebugPrintFrameFunctor):
1780         (DebugPrintFrameFunctor::operator()):
1781         (debugPrintCallFrame):
1782         (debugPrintStack):
1783         * interpreter/StackIterator.h:
1784         (JSC::StackIterator::iterate):
1785         * jsc.cpp:
1786         (functionJSCStack):
1787         * profiler/ProfileGenerator.cpp:
1788         (JSC::ProfileGenerator::addParentForConsoleStart):
1789         * runtime/JSFunction.cpp:
1790         (JSC::retrieveArguments):
1791         (JSC::RetrieveCallerFunctionFunctor::operator()):
1792         (JSC::retrieveCallerFunction):
1793         * runtime/JSGlobalObjectFunctions.cpp:
1794         (JSC::globalFuncProtoGetter):
1795         (JSC::globalFuncProtoSetter):
1796         * runtime/ObjectConstructor.cpp:
1797         (JSC::objectConstructorGetPrototypeOf):
1798
1799 2013-09-04  Benjamin Poulain  <benjamin@webkit.org>
1800
1801         JSGenericTypedArrayViewConstructor.h is referenced twice in the XCode project build section, causing warnings
1802         https://bugs.webkit.org/show_bug.cgi?id=120698
1803
1804         Reviewed by Darin Adler.
1805
1806         * JavaScriptCore.xcodeproj/project.pbxproj:
1807
1808 2013-09-04  Mark Hahnenberg  <mhahnenberg@apple.com>
1809
1810         ASSERT in MarkedAllocator::allocateSlowCase is wrong
1811         https://bugs.webkit.org/show_bug.cgi?id=120639
1812
1813         Reviewed by Oliver Hunt.
1814
1815         ASSERT(!m_heap->shouldCollect()) is no longer true due to our use of the GC 
1816         deferral mechanism. We could technically be beyond our byte allocation limit, 
1817         but still not try to collect due to deferral. This patch amends shouldCollect() 
1818         to return false if GC is currently deferred.
1819
1820         * heap/Heap.h:
1821         (JSC::Heap::shouldCollect):
1822
1823 2013-09-03  Filip Pizlo  <fpizlo@apple.com>
1824
1825         The DFG should be able to tier-up and OSR enter into the FTL
1826         https://bugs.webkit.org/show_bug.cgi?id=112838
1827
1828         Reviewed by Mark Hahnenberg.
1829         
1830         This adds the ability for the DFG to tier-up into the FTL. This works in both
1831         of the expected tier-up modes:
1832         
1833         Replacement: frequently called functions eventually have their entrypoint
1834         replaced with one that goes into FTL-compiled code. Note, this will be a
1835         slow-down for now since we don't yet have LLVM calling convention integration.
1836         
1837         OSR entry: code stuck in hot loops gets OSR'd into the FTL from the DFG.
1838         
1839         This means that if the DFG detects that a function is an FTL candidate, it
1840         inserts execution counting code similar to the kind that the baseline JIT
1841         would use. If you trip on a loop count in a loop header that is an OSR
1842         candidate (it's not an inlined loop), we do OSR; otherwise we do replacement.
1843         OSR almost always also implies future replacement.
1844         
1845         OSR entry into the FTL is really cool. It uses a specialized FTL compile of
1846         the code, where early in the DFG pipeline we replace the original root block
1847         with an OSR entrypoint block that jumps to the pre-header of the hot loop.
1848         The OSR entrypoint loads all live state at the loop pre-header using loads
1849         from a scratch buffer, which gets populated by the runtime's OSR entry
1850         preparation code (FTL::prepareOSREntry()). This approach appears to work well
1851         with all of our subsequent optimizations, including prediction propagation,
1852         CFA, and LICM. LLVM seems happy with it, too. Best of all, it works naturally
1853         with concurrent compilation: when we hit the tier-up trigger we spawn a
1854         compilation plan at the bytecode index from which we triggered; once the
1855         compilation finishes the next trigger will try to enter, at that bytecode
1856         index. If it can't - for example because the code has moved on to another
1857         loop - then we just try again. Loops that get hot enough for OSR entry (about
1858         25,000 iterations) will probably still be running when a concurrent compile
1859         finishes, so this doesn't appear to be a big problem.
1860         
1861         This immediately gives us a 70% speed-up on imaging-gaussian-blur. We could
1862         get a bigger speed-up by adding some more intelligence and tweaking LLVM to
1863         compile code faster. Those things will happen eventually but this is a good
1864         start. Probably this code will see more tuning as we get more coverage in the
1865         FTL JIT, but I'll worry about that in future patches.
1866
1867         * CMakeLists.txt:
1868         * GNUmakefile.list.am:
1869         * JavaScriptCore.xcodeproj/project.pbxproj:
1870         * Target.pri:
1871         * bytecode/CodeBlock.cpp:
1872         (JSC::CodeBlock::CodeBlock):
1873         (JSC::CodeBlock::hasOptimizedReplacement):
1874         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
1875         * bytecode/CodeBlock.h:
1876         * dfg/DFGAbstractInterpreterInlines.h:
1877         (JSC::DFG::::executeEffects):
1878         * dfg/DFGByteCodeParser.cpp:
1879         (JSC::DFG::ByteCodeParser::parseBlock):
1880         (JSC::DFG::ByteCodeParser::parse):
1881         * dfg/DFGCFGSimplificationPhase.cpp:
1882         (JSC::DFG::CFGSimplificationPhase::run):
1883         * dfg/DFGClobberize.h:
1884         (JSC::DFG::clobberize):
1885         * dfg/DFGDriver.cpp:
1886         (JSC::DFG::compileImpl):
1887         (JSC::DFG::compile):
1888         * dfg/DFGDriver.h:
1889         * dfg/DFGFixupPhase.cpp:
1890         (JSC::DFG::FixupPhase::fixupNode):
1891         * dfg/DFGGraph.cpp:
1892         (JSC::DFG::Graph::dump):
1893         (JSC::DFG::Graph::killBlockAndItsContents):
1894         (JSC::DFG::Graph::killUnreachableBlocks):
1895         * dfg/DFGGraph.h:
1896         * dfg/DFGInPlaceAbstractState.cpp:
1897         (JSC::DFG::InPlaceAbstractState::initialize):
1898         * dfg/DFGJITCode.cpp:
1899         (JSC::DFG::JITCode::reconstruct):
1900         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
1901         (JSC::DFG::JITCode::optimizeNextInvocation):
1902         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
1903         (JSC::DFG::JITCode::optimizeAfterWarmUp):
1904         (JSC::DFG::JITCode::optimizeSoon):
1905         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
1906         (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
1907         * dfg/DFGJITCode.h:
1908         * dfg/DFGJITFinalizer.cpp:
1909         (JSC::DFG::JITFinalizer::finalize):
1910         (JSC::DFG::JITFinalizer::finalizeFunction):
1911         (JSC::DFG::JITFinalizer::finalizeCommon):
1912         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
1913         (JSC::DFG::createPreHeader):
1914         (JSC::DFG::LoopPreHeaderCreationPhase::run):
1915         * dfg/DFGLoopPreHeaderCreationPhase.h:
1916         * dfg/DFGNode.h:
1917         (JSC::DFG::Node::hasUnlinkedLocal):
1918         (JSC::DFG::Node::unlinkedLocal):
1919         * dfg/DFGNodeType.h:
1920         * dfg/DFGOSREntry.cpp:
1921         (JSC::DFG::prepareOSREntry):
1922         * dfg/DFGOSREntrypointCreationPhase.cpp: Added.
1923         (JSC::DFG::OSREntrypointCreationPhase::OSREntrypointCreationPhase):
1924         (JSC::DFG::OSREntrypointCreationPhase::run):
1925         (JSC::DFG::performOSREntrypointCreation):
1926         * dfg/DFGOSREntrypointCreationPhase.h: Added.
1927         * dfg/DFGOperations.cpp:
1928         * dfg/DFGOperations.h:
1929         * dfg/DFGPlan.cpp:
1930         (JSC::DFG::Plan::Plan):
1931         (JSC::DFG::Plan::compileInThread):
1932         (JSC::DFG::Plan::compileInThreadImpl):
1933         * dfg/DFGPlan.h:
1934         * dfg/DFGPredictionInjectionPhase.cpp:
1935         (JSC::DFG::PredictionInjectionPhase::run):
1936         * dfg/DFGPredictionPropagationPhase.cpp:
1937         (JSC::DFG::PredictionPropagationPhase::propagate):
1938         * dfg/DFGSafeToExecute.h:
1939         (JSC::DFG::safeToExecute):
1940         * dfg/DFGSpeculativeJIT32_64.cpp:
1941         (JSC::DFG::SpeculativeJIT::compile):
1942         * dfg/DFGSpeculativeJIT64.cpp:
1943         (JSC::DFG::SpeculativeJIT::compile):
1944         * dfg/DFGTierUpCheckInjectionPhase.cpp: Added.
1945         (JSC::DFG::TierUpCheckInjectionPhase::TierUpCheckInjectionPhase):
1946         (JSC::DFG::TierUpCheckInjectionPhase::run):
1947         (JSC::DFG::performTierUpCheckInjection):
1948         * dfg/DFGTierUpCheckInjectionPhase.h: Added.
1949         * dfg/DFGToFTLDeferredCompilationCallback.cpp: Added.
1950         (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
1951         (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
1952         (JSC::DFG::ToFTLDeferredCompilationCallback::create):
1953         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1954         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1955         * dfg/DFGToFTLDeferredCompilationCallback.h: Added.
1956         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp: Added.
1957         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
1958         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
1959         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create):
1960         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1961         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
1962         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: Added.
1963         * dfg/DFGWorklist.cpp:
1964         (JSC::DFG::globalWorklist):
1965         * dfg/DFGWorklist.h:
1966         * ftl/FTLCapabilities.cpp:
1967         (JSC::FTL::canCompile):
1968         * ftl/FTLCapabilities.h:
1969         * ftl/FTLForOSREntryJITCode.cpp: Added.
1970         (JSC::FTL::ForOSREntryJITCode::ForOSREntryJITCode):
1971         (JSC::FTL::ForOSREntryJITCode::~ForOSREntryJITCode):
1972         (JSC::FTL::ForOSREntryJITCode::ftlForOSREntry):
1973         (JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
1974         * ftl/FTLForOSREntryJITCode.h: Added.
1975         (JSC::FTL::ForOSREntryJITCode::entryBuffer):
1976         (JSC::FTL::ForOSREntryJITCode::setBytecodeIndex):
1977         (JSC::FTL::ForOSREntryJITCode::bytecodeIndex):
1978         (JSC::FTL::ForOSREntryJITCode::countEntryFailure):
1979         (JSC::FTL::ForOSREntryJITCode::entryFailureCount):
1980         * ftl/FTLJITFinalizer.cpp:
1981         (JSC::FTL::JITFinalizer::finalizeFunction):
1982         * ftl/FTLLink.cpp:
1983         (JSC::FTL::link):
1984         * ftl/FTLLowerDFGToLLVM.cpp:
1985         (JSC::FTL::LowerDFGToLLVM::compileBlock):
1986         (JSC::FTL::LowerDFGToLLVM::compileNode):
1987         (JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal):
1988         (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
1989         (JSC::FTL::LowerDFGToLLVM::addWeakReference):
1990         * ftl/FTLOSREntry.cpp: Added.
1991         (JSC::FTL::prepareOSREntry):
1992         * ftl/FTLOSREntry.h: Added.
1993         * ftl/FTLOutput.h:
1994         (JSC::FTL::Output::crashNonTerminal):
1995         (JSC::FTL::Output::crash):
1996         * ftl/FTLState.cpp:
1997         (JSC::FTL::State::State):
1998         * interpreter/Register.h:
1999         (JSC::Register::unboxedDouble):
2000         * jit/JIT.cpp:
2001         (JSC::JIT::emitEnterOptimizationCheck):
2002         * jit/JITCode.cpp:
2003         (JSC::JITCode::ftlForOSREntry):
2004         * jit/JITCode.h:
2005         * jit/JITStubs.cpp:
2006         (JSC::DEFINE_STUB_FUNCTION):
2007         * runtime/Executable.cpp:
2008         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
2009         * runtime/Options.h:
2010         * runtime/VM.cpp:
2011         (JSC::VM::ensureWorklist):
2012         * runtime/VM.h:
2013
2014 2013-09-03  Filip Pizlo  <fpizlo@apple.com>
2015
2016         CodeBlock memory cost reporting should be rationalized
2017         https://bugs.webkit.org/show_bug.cgi?id=120615
2018
2019         Reviewed by Darin Adler.
2020         
2021         Report the size of the instruction stream, and then remind the GC that we're
2022         using memory when we trace.
2023         
2024         This is a slight slow-down on some JSBench tests because it makes us GC a
2025         bit more frequently. But I think it's well worth it; if we really want those
2026         tests to GC less frequently then we can achieve that through other kinds of
2027         tuning. It's better that the GC knows that CodeBlocks do in fact use memory;
2028         what it does with that information is a somewhat orthogonal question.
2029
2030         * bytecode/CodeBlock.cpp:
2031         (JSC::CodeBlock::CodeBlock):
2032         (JSC::CodeBlock::visitAggregate):
2033
2034 2013-09-03  Mark Lam  <mark.lam@apple.com>
2035
2036         Converting StackIterator to a callback interface.
2037         https://bugs.webkit.org/show_bug.cgi?id=120564.
2038
2039         Reviewed by Filip Pizlo.
2040
2041         * API/JSContextRef.cpp:
2042         (BacktraceFunctor::BacktraceFunctor):
2043         (BacktraceFunctor::operator()):
2044         (JSContextCreateBacktrace):
2045         * interpreter/CallFrame.cpp:
2046         * interpreter/CallFrame.h:
2047         * interpreter/Interpreter.cpp:
2048         (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
2049         (JSC::DumpRegisterFunctor::operator()):
2050         (JSC::Interpreter::dumpRegisters):
2051         (JSC::unwindCallFrame):
2052         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
2053         (JSC::GetStackTraceFunctor::operator()):
2054         (JSC::Interpreter::getStackTrace):
2055         (JSC::Interpreter::stackTraceAsString):
2056         (JSC::UnwindFunctor::UnwindFunctor):
2057         (JSC::UnwindFunctor::operator()):
2058         (JSC::Interpreter::unwind):
2059         * interpreter/Interpreter.h:
2060         * interpreter/StackIterator.cpp:
2061         (JSC::StackIterator::numberOfFrames):
2062         (JSC::StackIterator::gotoFrameAtIndex):
2063         (JSC::StackIterator::gotoNextFrameWithFilter):
2064         (JSC::StackIterator::resetIterator):
2065         (JSC::StackIterator::Frame::print):
2066         (debugPrintCallFrame):
2067         (DebugPrintStackFunctor::operator()):
2068         (debugPrintStack): Added for debugging convenience.
2069         * interpreter/StackIterator.h:
2070         (JSC::StackIterator::Frame::index):
2071         (JSC::StackIterator::iterate):
2072         * jsc.cpp:
2073         (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
2074         (FunctionJSCStackFunctor::operator()):
2075         (functionJSCStack):
2076         * profiler/ProfileGenerator.cpp:
2077         (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor):
2078         (JSC::AddParentForConsoleStartFunctor::foundParent):
2079         (JSC::AddParentForConsoleStartFunctor::operator()):
2080         (JSC::ProfileGenerator::addParentForConsoleStart):
2081         * runtime/JSFunction.cpp:
2082         (JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
2083         (JSC::RetrieveArgumentsFunctor::result):
2084         (JSC::RetrieveArgumentsFunctor::operator()):
2085         (JSC::retrieveArguments):
2086         (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
2087         (JSC::RetrieveCallerFunctionFunctor::result):
2088         (JSC::RetrieveCallerFunctionFunctor::operator()):
2089         (JSC::retrieveCallerFunction):
2090         * runtime/JSGlobalObjectFunctions.cpp:
2091         (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
2092         (JSC::GlobalFuncProtoGetterFunctor::result):
2093         (JSC::GlobalFuncProtoGetterFunctor::operator()):
2094         (JSC::globalFuncProtoGetter):
2095         (JSC::GlobalFuncProtoSetterFunctor::GlobalFuncProtoSetterFunctor):
2096         (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
2097         (JSC::GlobalFuncProtoSetterFunctor::operator()):
2098         (JSC::globalFuncProtoSetter):
2099         * runtime/ObjectConstructor.cpp:
2100         (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
2101         (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
2102         (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
2103         (JSC::objectConstructorGetPrototypeOf):
2104
2105 2013-09-03  Oliver Hunt  <oliver@apple.com>
2106
2107         Support structured clone of Map and Set
2108         https://bugs.webkit.org/show_bug.cgi?id=120654
2109
2110         Reviewed by Simon Fraser.
2111
2112         Make xcode copy the required headers, and add appropriate export attributes
2113
2114         * JavaScriptCore.xcodeproj/project.pbxproj:
2115         * runtime/JSMap.h:
2116         * runtime/JSSet.h:
2117         * runtime/MapData.h:
2118
2119 2013-09-02  Ryosuke Niwa  <rniwa@webkit.org>
2120
2121         Support the "json" responseType and JSON response entity in XHR
2122         https://bugs.webkit.org/show_bug.cgi?id=73648
2123
2124         Reviewed by Oliver Hunt.
2125
2126         Based on the patch written by Jarred Nicholls.
2127
2128         Add JSC::JSONParse. This function will be used in XMLHttpRequest.response of type 'json'.
2129
2130         * JavaScriptCore.xcodeproj/project.pbxproj:
2131         * runtime/JSONObject.cpp:
2132         (JSC::JSONParse):
2133         * runtime/JSONObject.h:
2134
2135 2013-09-02  Filip Pizlo  <fpizlo@apple.com>
2136
2137         CodeBlock::jettison() should be implicit
2138         https://bugs.webkit.org/show_bug.cgi?id=120567
2139
2140         Reviewed by Oliver Hunt.
2141         
2142         This is a risky change from a performance standpoint, but I believe it's
2143         necessary. This makes all CodeBlocks get swept by GC. Nobody but the GC
2144         can delete CodeBlocks because the GC always holds a reference to them.
2145         Once a CodeBlock reaches just one reference (i.e. the one from the GC)
2146         then the GC will free it only if it's not on the stack.
2147         
2148         This allows me to get rid of the jettisoning logic. We need this for FTL
2149         tier-up. Well; we don't need it, but it will help prevent a lot of bugs.
2150         Previously, if you wanted to to replace one code block with another, you
2151         had to remember to tell the GC that the previous code block is
2152         "jettisoned". We would need to do this when tiering up from DFG to FTL
2153         and when dealing with DFG-to-FTL OSR entry code blocks. There are a lot
2154         of permutations here - tiering up to the FTL, OSR entering into the FTL,
2155         deciding that an OSR entry code block is not relevant anymore - just to
2156         name a few. In each of these cases we'd have to jettison the previous
2157         code block. It smells like a huge source of future bugs.
2158         
2159         So I made jettisoning implicit by making the GC always watch out for a
2160         CodeBlock being owned solely by the GC.
2161         
2162         This change is performance neutral.
2163
2164         * CMakeLists.txt:
2165         * GNUmakefile.list.am:
2166         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2167         * JavaScriptCore.xcodeproj/project.pbxproj:
2168         * Target.pri:
2169         * bytecode/CodeBlock.cpp:
2170         (JSC::CodeBlock::CodeBlock):
2171         (JSC::CodeBlock::~CodeBlock):
2172         (JSC::CodeBlock::visitAggregate):
2173         (JSC::CodeBlock::jettison):
2174         * bytecode/CodeBlock.h:
2175         (JSC::CodeBlock::setJITCode):
2176         (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
2177         (JSC::CodeBlockSet::mark):
2178         * dfg/DFGCommonData.h:
2179         (JSC::DFG::CommonData::CommonData):
2180         * heap/CodeBlockSet.cpp: Added.
2181         (JSC::CodeBlockSet::CodeBlockSet):
2182         (JSC::CodeBlockSet::~CodeBlockSet):
2183         (JSC::CodeBlockSet::add):
2184         (JSC::CodeBlockSet::clearMarks):
2185         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
2186         (JSC::CodeBlockSet::traceMarked):
2187         * heap/CodeBlockSet.h: Added.
2188         * heap/ConservativeRoots.cpp:
2189         (JSC::ConservativeRoots::add):
2190         * heap/ConservativeRoots.h:
2191         * heap/DFGCodeBlocks.cpp: Removed.
2192         * heap/DFGCodeBlocks.h: Removed.
2193         * heap/Heap.cpp:
2194         (JSC::Heap::markRoots):
2195         (JSC::Heap::deleteAllCompiledCode):
2196         (JSC::Heap::deleteUnmarkedCompiledCode):
2197         * heap/Heap.h:
2198         * interpreter/JSStack.cpp:
2199         (JSC::JSStack::gatherConservativeRoots):
2200         * interpreter/JSStack.h:
2201         * runtime/Executable.cpp:
2202         (JSC::ScriptExecutable::installCode):
2203         * runtime/Executable.h:
2204         * runtime/VM.h:
2205
2206 2013-09-02  Darin Adler  <darin@apple.com>
2207
2208         [Mac] No need for HardAutorelease, which is same as CFBridgingRelease
2209         https://bugs.webkit.org/show_bug.cgi?id=120569
2210
2211         Reviewed by Andy Estes.
2212
2213         * API/JSValue.mm:
2214         (valueToString): Use CFBridgingRelease.
2215
2216 2013-08-30  Filip Pizlo  <fpizlo@apple.com>
2217
2218         CodeBlock refactoring broke profile dumping
2219         https://bugs.webkit.org/show_bug.cgi?id=120551
2220
2221         Reviewed by Michael Saboff.
2222         
2223         Fix the bug, and did a big clean-up of how Executable returns CodeBlocks. A lot
2224         of the problems we have with code like CodeBlock::baselineVersion() is that we
2225         were trying *way too hard* to side-step the fact that Executable can't return a
2226         CodeBlock*. Previously it could only return CodeBlock&, so if it didn't have a
2227         CodeBlock yet, you were screwed. And if you didn't know, or weren't sure, if it
2228         did have a CodeBlock, you were really going to have a bad time. Also it really
2229         bugs me that the methods were called generatedBytecode(). In all other contexts
2230         if you ask for a CodeBlock, then method to call is codeBlock(). So I made all
2231         of those changes.
2232
2233         * bytecode/CodeBlock.cpp:
2234         (JSC::CodeBlock::baselineVersion):
2235         (JSC::ProgramCodeBlock::replacement):
2236         (JSC::EvalCodeBlock::replacement):
2237         (JSC::FunctionCodeBlock::replacement):
2238         (JSC::CodeBlock::globalObjectFor):
2239         * bytecode/CodeOrigin.cpp:
2240         (JSC::InlineCallFrame::hash):
2241         * dfg/DFGOperations.cpp:
2242         * interpreter/Interpreter.cpp:
2243         (JSC::Interpreter::execute):
2244         (JSC::Interpreter::executeCall):
2245         (JSC::Interpreter::executeConstruct):
2246         (JSC::Interpreter::prepareForRepeatCall):
2247         * jit/JITCode.h:
2248         (JSC::JITCode::isExecutableScript):
2249         (JSC::JITCode::isLowerTier):
2250         * jit/JITStubs.cpp:
2251         (JSC::lazyLinkFor):
2252         (JSC::DEFINE_STUB_FUNCTION):
2253         * llint/LLIntSlowPaths.cpp:
2254         (JSC::LLInt::traceFunctionPrologue):
2255         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2256         (JSC::LLInt::setUpCall):
2257         * runtime/ArrayPrototype.cpp:
2258         (JSC::isNumericCompareFunction):
2259         * runtime/CommonSlowPaths.h:
2260         (JSC::CommonSlowPaths::arityCheckFor):
2261         * runtime/Executable.cpp:
2262         (JSC::ScriptExecutable::installCode):
2263         * runtime/Executable.h:
2264         (JSC::EvalExecutable::codeBlock):
2265         (JSC::ProgramExecutable::codeBlock):
2266         (JSC::FunctionExecutable::eitherCodeBlock):
2267         (JSC::FunctionExecutable::codeBlockForCall):
2268         (JSC::FunctionExecutable::codeBlockForConstruct):
2269         (JSC::FunctionExecutable::codeBlockFor):
2270         * runtime/FunctionExecutableDump.cpp:
2271         (JSC::FunctionExecutableDump::dump):
2272
2273 2013-08-30  Oliver Hunt  <oliver@apple.com>
2274
2275         Implement ES6 Set class
2276         https://bugs.webkit.org/show_bug.cgi?id=120549
2277
2278         Reviewed by Filip Pizlo.
2279
2280         We simply reuse the MapData type from JSMap making the
2281         it much simpler.
2282
2283         * JavaScriptCore.xcodeproj/project.pbxproj:
2284         * runtime/CommonIdentifiers.h:
2285         * runtime/JSGlobalObject.cpp:
2286         (JSC::JSGlobalObject::reset):
2287         (JSC::JSGlobalObject::visitChildren):
2288         * runtime/JSGlobalObject.h:
2289         (JSC::JSGlobalObject::setStructure):
2290         * runtime/JSSet.cpp: Added.
2291         (JSC::JSSet::visitChildren):
2292         (JSC::JSSet::finishCreation):
2293         * runtime/JSSet.h: Added.
2294         (JSC::JSSet::createStructure):
2295         (JSC::JSSet::create):
2296         (JSC::JSSet::mapData):
2297         (JSC::JSSet::JSSet):
2298         * runtime/SetConstructor.cpp: Added.
2299         (JSC::SetConstructor::finishCreation):
2300         (JSC::callSet):
2301         (JSC::constructSet):
2302         (JSC::SetConstructor::getConstructData):
2303         (JSC::SetConstructor::getCallData):
2304         * runtime/SetConstructor.h: Added.
2305         (JSC::SetConstructor::create):
2306         (JSC::SetConstructor::createStructure):
2307         (JSC::SetConstructor::SetConstructor):
2308         * runtime/SetPrototype.cpp: Added.
2309         (JSC::SetPrototype::finishCreation):
2310         (JSC::getMapData):
2311         (JSC::setProtoFuncAdd):
2312         (JSC::setProtoFuncClear):
2313         (JSC::setProtoFuncDelete):
2314         (JSC::setProtoFuncForEach):
2315         (JSC::setProtoFuncHas):
2316         (JSC::setProtoFuncSize):
2317         * runtime/SetPrototype.h: Added.
2318         (JSC::SetPrototype::create):
2319         (JSC::SetPrototype::createStructure):
2320         (JSC::SetPrototype::SetPrototype):
2321
2322 2013-08-30  Oliver Hunt  <oliver@apple.com>
2323
2324         Make JSValue bool conversion less dangerous
2325         https://bugs.webkit.org/show_bug.cgi?id=120505
2326
2327         Reviewed by Darin Adler.
2328
2329         Replaces JSValue::operator bool() with a operator UnspecifiedBoolType* as
2330         we do elsewhere.  Then fix the places where terrible type coercion was
2331         happening.  All of the changes made had no fundamental behavioural impact
2332         as they were coercion results that were ignored (returning undefined 
2333         after an exception).  
2334
2335         * dfg/DFGOperations.cpp:
2336         * interpreter/CallFrame.h:
2337         (JSC::ExecState::hadException):
2338         * runtime/JSCJSValue.h:
2339         * runtime/JSCJSValueInlines.h:
2340         (JSC::JSValue::operator UnspecifiedBoolType*):
2341         * runtime/JSGlobalObjectFunctions.cpp:
2342         (JSC::globalFuncEval):
2343         * runtime/PropertyDescriptor.cpp:
2344         (JSC::PropertyDescriptor::equalTo)
2345
2346 2013-08-30  Chris Curtis  <chris_curtis@apple.com>
2347
2348         Cleaning errorDescriptionForValue after r154839
2349         https://bugs.webkit.org/show_bug.cgi?id=120531
2350         
2351         Reviewed by Darin Adler.
2352         
2353         Changed the assert to ASSERT_NOT_REACHED, now that r154839 has landed. errorDescriptionForValue 
2354         can assert again that the parameterized JSValue is !isEmpty().
2355         
2356         * runtime/ExceptionHelpers.cpp:
2357         (JSC::errorDescriptionForValue):
2358
2359 2013-08-30  Antti Koivisto  <antti@apple.com>
2360
2361         Remove code behind ENABLE(DIALOG_ELEMENT)
2362         https://bugs.webkit.org/show_bug.cgi?id=120467
2363
2364         Reviewed by Darin Adler.
2365
2366         * Configurations/FeatureDefines.xcconfig:
2367
2368 2013-08-29  Andreas Kling  <akling@apple.com>
2369
2370         De-bork Qt build.
2371
2372         * Target.pri:
2373
2374 2013-08-29  Ryuan Choi  <ryuan.choi@samsung.com>
2375
2376         Unreviewed build fix attempt for Windows.
2377
2378         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2379         Renamed JSMapConstructor and JSMapPrototype.
2380
2381 2013-08-29  Ryuan Choi  <ryuan.choi@samsung.com>
2382
2383         Fix build break after r154861
2384         https://bugs.webkit.org/show_bug.cgi?id=120503
2385
2386         Reviewed by Geoffrey Garen.
2387
2388         Unreviewed build fix attempt for GTK, Qt Windows and CMake based ports.
2389
2390         * CMakeLists.txt:
2391         * GNUmakefile.list.am:
2392         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2393         * Target.pri:
2394         * runtime/MapData.h:
2395         (JSC::MapData::KeyType::KeyType):
2396
2397 2013-08-29  Andreas Kling  <akling@apple.com>
2398
2399         CodeBlock: LLIntCallLinkInfo vector can be sized-to-fit at creation.
2400         <https://webkit.org/b/120487>
2401
2402         Reviewed by Oliver Hunt.
2403
2404         CodeBlock::m_llintCallLinkInfos never changes size after creation, so make it a Vector
2405         instead of a SegmentedVector. Use resizeToFit() instead of grow() since we know the
2406         exact amount of space needed.
2407
2408         * bytecode/CodeBlock.h:
2409         * bytecode/CodeBlock.cpp:
2410         (JSC::CodeBlock::CodeBlock):
2411         (JSC::CodeBlock::shrinkToFit):
2412
2413 2013-08-29  Oliver Hunt  <oliver@apple.com>
2414
2415         Fix issues found by MSVC (which also happily fixes an unintentional pessimisation)
2416
2417         * runtime/MapData.h:
2418         (JSC::MapData::KeyType::KeyType):
2419
2420 2013-08-29  Oliver Hunt  <oliver@apple.com>
2421
2422
2423         Implement ES6 Map object
2424         https://bugs.webkit.org/show_bug.cgi?id=120333
2425
2426         Reviewed by Geoffrey Garen.
2427
2428         Implement support for the ES6 Map type and related classes.
2429
2430         * JavaScriptCore.xcodeproj/project.pbxproj:
2431         * heap/CopyToken.h: Add a new token to track copying the backing store
2432         * runtime/CommonIdentifiers.h: Add new identifiers
2433         * runtime/JSGlobalObject.cpp:
2434         * runtime/JSGlobalObject.h:
2435             Add new structures and prototypes
2436
2437         * runtime/JSMap.cpp: Added.
2438         * runtime/JSMap.h: Added.
2439             New JSMap class to represent a Map instance
2440
2441         * runtime/MapConstructor.cpp: Added.
2442         * runtime/MapConstructor.h: Added.
2443             The Map constructor
2444
2445         * runtime/MapData.cpp: Added.
2446         * runtime/MapData.h: Added.
2447             The most interesting data structure.  The roughly corresponds
2448             to the ES6 notion of MapData.  It provides the core JSValue->JSValue
2449             map implementation.  We implement it using 2 hashtables and a flat
2450             table.  Due to the different semantics of string comparisons vs.
2451             all others we need have one map keyed by String and the other by
2452             generic JSValue.  The actual table is represented more or less
2453             exactly as described in the ES6 draft - a single contiguous list of
2454             key/value pairs.  The entire map could be achieved with just this
2455             table, however we need the HashMaps in order to maintain O(1) lookup.
2456
2457             Deleted values are simply cleared as the draft says, however the
2458             implementation compacts the storage on copy as long as the are no
2459             active iterators.
2460
2461         * runtime/MapPrototype.cpp: Added.
2462         * runtime/MapPrototype.h: Added.
2463             Implement Map prototype functions
2464
2465         * runtime/VM.cpp:
2466             Add new structures.
2467
2468 2013-08-29  Filip Pizlo  <fpizlo@apple.com>
2469
2470         Teach DFG::Worklist and its clients that it may be reused for different kinds of compilations
2471         https://bugs.webkit.org/show_bug.cgi?id=120489
2472
2473         Reviewed by Geoffrey Garen.
2474         
2475         If the baseline JIT hits an OSR entry trigger into the DFG and we already have a
2476         DFG compilation but we've also started one or more FTL compilations, then we
2477         shouldn't get confused. Previously we would have gotten confused because we would
2478         see an in-process deferred compile (the FTL compile) and also an optimized
2479         replacement (the DFG code).
2480         
2481         If the baseline JIT hits an OSR entry trigger into the DFG and we previously
2482         did two things in this order: triggered a tier-up compilation from the DFG into
2483         the FTL, and then jettisoned the DFG code because it exited a bunch, then we
2484         shouldn't be confused by the presence of an in-process deferred compile (the FTL
2485         compile). Previously we would have waited for that compile to finish; but the more
2486         sensible thing to do is to let it complete and then invalidate it, while at the
2487         same time enqueueing a DFG compile to create a new, more valid, DFG code block.
2488         
2489         If the DFG JIT hits a loop OSR entry trigger (into the FTL) and it has already
2490         triggered an FTL compile for replacement, then it should fire off a second compile
2491         instead of thinking that it can wait for that one to finish. Or vice-versa. We
2492         need to allow for two FTL compiles to be enqueued at the same time (one for
2493         replacement and one for OSR entry in a loop).
2494         
2495         Then there's also the problem that DFG::compile() is almost certainly going to be
2496         the hook for triggering both DFG compiles and the two kinds of FTL compiles, but
2497         right now there is no way to tell it which one you want.
2498         
2499         This fixes these problems and removes a bunch of potential confusion by making the
2500         key for a compile in the DFG::Worklist be a CompilationMode (one of DFGMode,
2501         FTLMode, or FTLForOSREntryMode). That mode is also passed to DFG::compile().
2502         
2503         Awkwardly, this still leaves us in a no DFG->FTL tier-up situation - so
2504         DFG::compile() is always passed DFGMode and then it might do an FTL compile if
2505         possible. Fixing that is a bigger issue for a later changeset.
2506
2507         * CMakeLists.txt:
2508         * GNUmakefile.list.am:
2509         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2510         * JavaScriptCore.xcodeproj/project.pbxproj:
2511         * Target.pri:
2512         * bytecode/CodeBlock.cpp:
2513         (JSC::CodeBlock::checkIfOptimizationThresholdReached):
2514         * dfg/DFGCompilationKey.cpp: Added.
2515         (JSC::DFG::CompilationKey::dump):
2516         * dfg/DFGCompilationKey.h: Added.
2517         (JSC::DFG::CompilationKey::CompilationKey):
2518         (JSC::DFG::CompilationKey::operator!):
2519         (JSC::DFG::CompilationKey::isHashTableDeletedValue):
2520         (JSC::DFG::CompilationKey::profiledBlock):
2521         (JSC::DFG::CompilationKey::mode):
2522         (JSC::DFG::CompilationKey::operator==):
2523         (JSC::DFG::CompilationKey::hash):
2524         (JSC::DFG::CompilationKeyHash::hash):
2525         (JSC::DFG::CompilationKeyHash::equal):
2526         * dfg/DFGCompilationMode.cpp: Added.
2527         (WTF::printInternal):
2528         * dfg/DFGCompilationMode.h: Added.
2529         * dfg/DFGDriver.cpp:
2530         (JSC::DFG::compileImpl):
2531         (JSC::DFG::compile):
2532         * dfg/DFGDriver.h:
2533         * dfg/DFGPlan.cpp:
2534         (JSC::DFG::Plan::Plan):
2535         (JSC::DFG::Plan::key):
2536         * dfg/DFGPlan.h:
2537         * dfg/DFGWorklist.cpp:
2538         (JSC::DFG::Worklist::enqueue):
2539         (JSC::DFG::Worklist::compilationState):
2540         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
2541         (JSC::DFG::Worklist::runThread):
2542         * dfg/DFGWorklist.h:
2543         * jit/JITStubs.cpp:
2544         (JSC::DEFINE_STUB_FUNCTION):
2545
2546 2013-08-29  Brent Fulgham  <bfulgham@apple.com>
2547
2548         [Windows] Unreviewed build fix after r154847.
2549         If you are going to exclude promises, actually exclude the build components.
2550
2551         * interpreter/CallFrame.h: Exclude promise declarations
2552         * runtime/JSGlobalObject.cpp:
2553         (JSC::JSGlobalObject::reset): Exclude promise code.
2554         (JSC::JSGlobalObject::visitChildren): Ditto.
2555         * runtime/VM.cpp: Ditto.
2556         (JSC::VM::VM):
2557         (JSC::VM::~VM):
2558         * runtime/VM.h:
2559
2560 2013-08-29  Sam Weinig  <sam@webkit.org>
2561
2562         Add ENABLE guards for Promises
2563         https://bugs.webkit.org/show_bug.cgi?id=120488
2564
2565         Reviewed by Andreas Kling.
2566
2567         * Configurations/FeatureDefines.xcconfig:
2568         * runtime/JSGlobalObject.cpp:
2569         * runtime/JSGlobalObject.h:
2570         * runtime/JSPromise.cpp:
2571         * runtime/JSPromise.h:
2572         * runtime/JSPromiseCallback.cpp:
2573         * runtime/JSPromiseCallback.h:
2574         * runtime/JSPromiseConstructor.cpp:
2575         * runtime/JSPromiseConstructor.h:
2576         * runtime/JSPromisePrototype.cpp:
2577         * runtime/JSPromisePrototype.h:
2578         * runtime/JSPromiseResolver.cpp:
2579         * runtime/JSPromiseResolver.h:
2580         * runtime/JSPromiseResolverConstructor.cpp:
2581         * runtime/JSPromiseResolverConstructor.h:
2582         * runtime/JSPromiseResolverPrototype.cpp:
2583         * runtime/JSPromiseResolverPrototype.h:
2584
2585 2013-08-29  Filip Pizlo  <fpizlo@apple.com>
2586
2587         Unreviewed, fix FTL build.
2588
2589         * ftl/FTLLowerDFGToLLVM.cpp:
2590         (JSC::FTL::LowerDFGToLLVM::callCheck):
2591
2592 2013-08-29  Julien Brianceau  <jbriance@cisco.com>
2593
2594         REGRESSION(r153222, 32-bit): NULL JSValue() seen when running peacekeeper benchmark.
2595         https://bugs.webkit.org/show_bug.cgi?id=120080
2596
2597         Reviewed by Michael Saboff.
2598
2599         * jit/JITOpcodes32_64.cpp:
2600         (JSC::JIT::emitSlow_op_get_argument_by_val): Revert changes introduced by r153222 in this function.
2601
2602 2013-08-29  Filip Pizlo  <fpizlo@apple.com>
2603
2604         Kill code that became dead after http://trac.webkit.org/changeset/154833
2605
2606         Rubber stamped by Oliver Hunt.
2607
2608         * dfg/DFGDriver.h:
2609
2610 2013-08-29  Filip Pizlo  <fpizlo@apple.com>
2611
2612         CodeBlock's magic for scaling tier-up thresholds should be more reusable
2613         https://bugs.webkit.org/show_bug.cgi?id=120486
2614
2615         Reviewed by Oliver Hunt.
2616         
2617         Removed the counterValueForBlah() methods and exposed the reusable scaling logic
2618         as a adjustedCounterValue() method.
2619
2620         * bytecode/CodeBlock.cpp:
2621         (JSC::CodeBlock::adjustedCounterValue):
2622         (JSC::CodeBlock::optimizeAfterWarmUp):
2623         (JSC::CodeBlock::optimizeAfterLongWarmUp):
2624         (JSC::CodeBlock::optimizeSoon):
2625         * bytecode/CodeBlock.h:
2626         * dfg/DFGOSRExitCompilerCommon.cpp:
2627         (JSC::DFG::handleExitCounts):
2628
2629 2013-08-29  Filip Pizlo  <fpizlo@apple.com>
2630
2631         CodeBlock::prepareForExecution() is silly
2632         https://bugs.webkit.org/show_bug.cgi?id=120453
2633
2634         Reviewed by Oliver Hunt.
2635         
2636         Instead of saying:
2637         
2638             codeBlock->prepareForExecution(stuff, BaselineJIT, more stuff)
2639         
2640         we should just say:
2641         
2642             JIT::compile(stuff, codeBlock, more stuff);
2643         
2644         And similarly for the LLInt and DFG.
2645         
2646         This kills a bunch of code, since CodeBlock::prepareForExecution() is just a
2647         wrapper that uses the JITType argument to call into the appropriate execution
2648         engine, which is what the user wanted to do in the first place.
2649
2650         * CMakeLists.txt:
2651         * GNUmakefile.list.am:
2652         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2653         * JavaScriptCore.xcodeproj/project.pbxproj:
2654         * Target.pri:
2655         * bytecode/CodeBlock.cpp:
2656         * bytecode/CodeBlock.h:
2657         * dfg/DFGDriver.cpp:
2658         (JSC::DFG::compileImpl):
2659         (JSC::DFG::compile):
2660         * dfg/DFGDriver.h:
2661         (JSC::DFG::tryCompile):
2662         * dfg/DFGOSRExitPreparation.cpp:
2663         (JSC::DFG::prepareCodeOriginForOSRExit):
2664         * dfg/DFGWorklist.cpp:
2665         (JSC::DFG::globalWorklist):
2666         * dfg/DFGWorklist.h:
2667         * jit/JIT.cpp:
2668         (JSC::JIT::privateCompile):
2669         * jit/JIT.h:
2670         (JSC::JIT::compile):
2671         * jit/JITStubs.cpp:
2672         (JSC::DEFINE_STUB_FUNCTION):
2673         * llint/LLIntEntrypoint.cpp: Copied from Source/JavaScriptCore/llint/LLIntEntrypoints.cpp.
2674         (JSC::LLInt::setFunctionEntrypoint):
2675         (JSC::LLInt::setEvalEntrypoint):
2676         (JSC::LLInt::setProgramEntrypoint):
2677         (JSC::LLInt::setEntrypoint):
2678         * llint/LLIntEntrypoint.h: Copied from Source/JavaScriptCore/llint/LLIntEntrypoints.h.
2679         * llint/LLIntEntrypoints.cpp: Removed.
2680         * llint/LLIntEntrypoints.h: Removed.
2681         * llint/LLIntSlowPaths.cpp:
2682         (JSC::LLInt::jitCompileAndSetHeuristics):
2683         * runtime/Executable.cpp:
2684         (JSC::ScriptExecutable::prepareForExecutionImpl):
2685
2686 2013-08-29  Mark Lam  <mark.lam@apple.com>
2687
2688         Gardening: fixed broken non-DFG build.
2689         https://bugs.webkit.org/show_bug.cgi?id=120481.
2690
2691         Not reviewed.
2692
2693         * interpreter/StackIterator.h:
2694
2695 2013-08-29  Filip Pizlo  <fpizlo@apple.com>
2696
2697         CodeBlock compilation and installation should be simplified and rationalized
2698         https://bugs.webkit.org/show_bug.cgi?id=120326
2699
2700         Reviewed by Oliver Hunt.
2701         
2702         Rolling r154804 back in after fixing no-LLInt build.
2703         
2704         Previously Executable owned the code for generating JIT code; you always had
2705         to go through Executable. But often you also had to go through CodeBlock,
2706         because ScriptExecutable couldn't have virtual methods, but CodeBlock could.
2707         So you'd ask CodeBlock to do something, which would dispatch through a
2708         virtual method that would select the appropriate Executable subtype's method.
2709         This all meant that the same code would often be duplicated, because most of
2710         the work needed to compile something was identical regardless of code type.
2711         But then we tried to fix this, by having templatized helpers in
2712         ExecutionHarness.h and JITDriver.h. The result was that if you wanted to find
2713         out what happened when you asked for something to be compiled, you'd go on a
2714         wild ride that started with CodeBlock, touched upon Executable, and then
2715         ricocheted into either ExecutionHarness or JITDriver (likely both).
2716         
2717         Another awkwardness was that for concurrent compiles, the DFG::Worklist had
2718         super-special inside knowledge of what JITStubs.cpp's cti_optimize would have
2719         done once the compilation finished.
2720         
2721         Also, most of the DFG JIT drivers assumed that they couldn't install the
2722         JITCode into the CodeBlock directly - instead they would return it via a
2723         reference, which happened to be a reference to the JITCode pointer in
2724         Executable. This was super weird.
2725         
2726         Finally, there was no notion of compiling code into a special CodeBlock that
2727         wasn't used for handling calls into an Executable. I'd like this for FTL OSR
2728         entry.
2729         
2730         This patch solves these problems by reducing all of that complexity into just
2731         three primitives:
2732         
2733         - Executable::newCodeBlock(). This gives you a new code block, either for call
2734           or for construct, and either to serve as the baseline code or the optimized
2735           code. The new code block is then owned by the caller; Executable doesn't
2736           register it anywhere. The new code block has no JITCode and isn't callable,
2737           but it has all of the bytecode.
2738         
2739         - CodeBlock::prepareForExecution(). This takes the CodeBlock's bytecode and
2740           produces a JITCode, and then installs the JITCode into the CodeBlock. This
2741           method takes a JITType, and always compiles with that JIT. If you ask for
2742           JITCode::InterpreterThunk then you'll get JITCode that just points to the
2743           LLInt entrypoints. Once this returns, it is possible to call into the
2744           CodeBlock if you do so manually - but the Executable still won't know about
2745           it so JS calls to that Executable will still be routed to whatever CodeBlock
2746           is associated with the Executable.
2747         
2748         - Executable::installCode(). This takes a CodeBlock and makes it the code-for-
2749           entry for that Executable. This involves unlinking the Executable's last
2750           CodeBlock, if there was one. This also tells the GC about any effect on
2751           memory usage and does a bunch of weird data structure rewiring, since
2752           Executable caches some of CodeBlock's fields for the benefit of virtual call
2753           fast paths.
2754         
2755         This functionality is then wrapped around three convenience methods:
2756         
2757         - Executable::prepareForExecution(). If there is no code block for that
2758           Executable, then one is created (newCodeBlock()), compiled
2759           (CodeBlock::prepareForExecution()) and installed (installCode()).
2760         
2761         - CodeBlock::newReplacement(). Asks the Executable for a new CodeBlock that
2762           can serve as an optimized replacement of the current one.
2763         
2764         - CodeBlock::install(). Asks the Executable to install this code block.
2765         
2766         This patch allows me to kill *a lot* of code and to remove a lot of
2767         specializations for functions vs. not-functions, and a lot of places where we
2768         pass around JITCode references and such. ExecutionHarness and JITDriver are
2769         both gone. Overall this patch has more red than green.
2770         
2771         It also allows me to work on FTL OSR entry and tier-up:
2772         
2773         - FTL tier-up: this will involve DFGOperations.cpp asking the DFG::Worklist
2774           to do some compilation, but it will require the DFG::Worklist to do
2775           something different than what JITStubs.cpp would want, once the compilation
2776           finishes. This patch introduces a callback mechanism for that purpose.
2777         
2778         - FTL OSR entry: this will involve creating a special auto-jettisoned
2779           CodeBlock that is used only for FTL OSR entry. The new set of primitives
2780           allows for this: Executable can vend you a fresh new CodeBlock, and you can
2781           ask that CodeBlock to compile itself with any JIT of your choosing. Or you
2782           can take that CodeBlock and compile it yourself. Previously the act of
2783           producing a CodeBlock-for-optimization and the act of compiling code for it
2784           were tightly coupled; now you can separate them and you can create such
2785           auto-jettisoned CodeBlocks that are used for a one-shot OSR entry.
2786
2787         * CMakeLists.txt:
2788         * GNUmakefile.list.am:
2789         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2790         * JavaScriptCore.xcodeproj/project.pbxproj:
2791         * Target.pri:
2792         * bytecode/CodeBlock.cpp:
2793         (JSC::CodeBlock::unlinkIncomingCalls):
2794         (JSC::CodeBlock::prepareForExecutionImpl):
2795         (JSC::CodeBlock::prepareForExecution):
2796         (JSC::CodeBlock::prepareForExecutionAsynchronously):
2797         (JSC::CodeBlock::install):
2798         (JSC::CodeBlock::newReplacement):
2799         (JSC::FunctionCodeBlock::jettisonImpl):
2800         * bytecode/CodeBlock.h:
2801         (JSC::CodeBlock::hasBaselineJITProfiling):
2802         * bytecode/DeferredCompilationCallback.cpp: Added.
2803         (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
2804         (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
2805         * bytecode/DeferredCompilationCallback.h: Added.
2806         * dfg/DFGDriver.cpp:
2807         (JSC::DFG::tryCompile):
2808         * dfg/DFGDriver.h:
2809         (JSC::DFG::tryCompile):
2810         * dfg/DFGFailedFinalizer.cpp:
2811         (JSC::DFG::FailedFinalizer::finalize):
2812         (JSC::DFG::FailedFinalizer::finalizeFunction):
2813         * dfg/DFGFailedFinalizer.h:
2814         * dfg/DFGFinalizer.h:
2815         * dfg/DFGJITFinalizer.cpp:
2816         (JSC::DFG::JITFinalizer::finalize):
2817         (JSC::DFG::JITFinalizer::finalizeFunction):
2818         * dfg/DFGJITFinalizer.h:
2819         * dfg/DFGOSRExitPreparation.cpp:
2820         (JSC::DFG::prepareCodeOriginForOSRExit):
2821         * dfg/DFGOperations.cpp:
2822         * dfg/DFGPlan.cpp:
2823         (JSC::DFG::Plan::Plan):
2824         (JSC::DFG::Plan::compileInThreadImpl):
2825         (JSC::DFG::Plan::notifyReady):
2826         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2827         (JSC::DFG::Plan::finalizeAndNotifyCallback):
2828         * dfg/DFGPlan.h:
2829         * dfg/DFGSpeculativeJIT32_64.cpp:
2830         (JSC::DFG::SpeculativeJIT::compile):
2831         * dfg/DFGWorklist.cpp:
2832         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
2833         (JSC::DFG::Worklist::runThread):
2834         * ftl/FTLJITFinalizer.cpp:
2835         (JSC::FTL::JITFinalizer::finalize):
2836         (JSC::FTL::JITFinalizer::finalizeFunction):
2837         * ftl/FTLJITFinalizer.h:
2838         * heap/Heap.h:
2839         (JSC::Heap::isDeferred):
2840         * interpreter/Interpreter.cpp:
2841         (JSC::Interpreter::execute):
2842         (JSC::Interpreter::executeCall):
2843         (JSC::Interpreter::executeConstruct):
2844         (JSC::Interpreter::prepareForRepeatCall):
2845         * jit/JITDriver.h: Removed.
2846         * jit/JITStubs.cpp:
2847         (JSC::DEFINE_STUB_FUNCTION):
2848         (JSC::jitCompileFor):
2849         (JSC::lazyLinkFor):
2850         * jit/JITToDFGDeferredCompilationCallback.cpp: Added.
2851         (JSC::JITToDFGDeferredCompilationCallback::JITToDFGDeferredCompilationCallback):
2852         (JSC::JITToDFGDeferredCompilationCallback::~JITToDFGDeferredCompilationCallback):
2853         (JSC::JITToDFGDeferredCompilationCallback::create):
2854         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
2855         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
2856         * jit/JITToDFGDeferredCompilationCallback.h: Added.
2857         * llint/LLIntEntrypoints.cpp:
2858         (JSC::LLInt::setFunctionEntrypoint):
2859         (JSC::LLInt::setEvalEntrypoint):
2860         (JSC::LLInt::setProgramEntrypoint):
2861         * llint/LLIntEntrypoints.h:
2862         * llint/LLIntSlowPaths.cpp:
2863         (JSC::LLInt::jitCompileAndSetHeuristics):
2864         (JSC::LLInt::setUpCall):
2865         * runtime/ArrayPrototype.cpp:
2866         (JSC::isNumericCompareFunction):
2867         * runtime/CommonSlowPaths.cpp:
2868         * runtime/CompilationResult.cpp:
2869         (WTF::printInternal):
2870         * runtime/CompilationResult.h:
2871         * runtime/Executable.cpp:
2872         (JSC::ScriptExecutable::installCode):
2873         (JSC::ScriptExecutable::newCodeBlockFor):
2874         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
2875         (JSC::ScriptExecutable::prepareForExecutionImpl):
2876         * runtime/Executable.h:
2877         (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
2878         (JSC::ExecutableBase::offsetOfNumParametersFor):
2879         (JSC::ScriptExecutable::prepareForExecution):
2880         (JSC::FunctionExecutable::jettisonOptimizedCodeFor):
2881         * runtime/ExecutionHarness.h: Removed.
2882
2883 2013-08-29  Mark Lam  <mark.lam@apple.com>
2884
2885         Change StackIterator to not require writes to the JS stack.
2886         https://bugs.webkit.org/show_bug.cgi?id=119657.
2887
2888         Reviewed by Geoffrey Garen.
2889
2890         * GNUmakefile.list.am:
2891         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2892         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2893         * JavaScriptCore.xcodeproj/project.pbxproj:
2894         * interpreter/CallFrame.h:
2895         - Removed references to StackIteratorPrivate.h.
2896         * interpreter/StackIterator.cpp:
2897         (JSC::StackIterator::numberOfFrames):
2898         (JSC::StackIterator::gotoFrameAtIndex):
2899         (JSC::StackIterator::gotoNextFrame):
2900         (JSC::StackIterator::resetIterator):
2901         (JSC::StackIterator::find):
2902         (JSC::StackIterator::readFrame):
2903         (JSC::StackIterator::readNonInlinedFrame):
2904         - Reads in the current CallFrame's data for non-inlined frames.
2905         (JSC::inlinedFrameOffset):
2906         - Convenience function to compute the inlined frame offset based on the
2907           CodeOrigin. If the offset is 0, then we're looking at the physical frame.
2908           Otherwise, it's an inlined frame.
2909         (JSC::StackIterator::readInlinedFrame):
2910         - Determines the inlined frame's caller frame. Will read in the caller
2911           frame if it is also an inlined frame i.e. we haven't reached the
2912           outer most frame yet. Otherwise, will call readNonInlinedFrame() to
2913           read on the outer most frame.
2914           This is based on the old StackIterator::Frame::logicalFrame().
2915         (JSC::StackIterator::updateFrame):
2916         - Reads the data of the caller frame of the current one. This function
2917           is renamed and moved from the old StackIterator::Frame::logicalCallerFrame(),
2918           but is now simplified because it delegates to the readInlinedFrame()
2919           to get the caller for inlined frames.
2920         (JSC::StackIterator::Frame::arguments):
2921         - Fixed to use the inlined frame versions of Arguments::create() and
2922           Arguments::tearOff() when the frame is an inlined frame.
2923         (JSC::StackIterator::Frame::print):
2924         (debugPrintCallFrame):
2925         (debugPrintStack):
2926         - Because sometimes, we want to see the whole stack while debugging.
2927         * interpreter/StackIterator.h:
2928         (JSC::StackIterator::Frame::argumentCount):
2929         (JSC::StackIterator::Frame::callerFrame):
2930         (JSC::StackIterator::Frame::callee):
2931         (JSC::StackIterator::Frame::scope):
2932         (JSC::StackIterator::Frame::codeBlock):
2933         (JSC::StackIterator::Frame::bytecodeOffset):
2934         (JSC::StackIterator::Frame::inlinedFrameInfo):
2935         (JSC::StackIterator::Frame::isJSFrame):
2936         (JSC::StackIterator::Frame::isInlinedFrame):
2937         (JSC::StackIterator::Frame::callFrame):
2938         (JSC::StackIterator::Frame::Frame):
2939         (JSC::StackIterator::Frame::~Frame):
2940         - StackIterator::Frame now caches commonly used accessed values from
2941           the CallFrame. It still delegates argument queries to the CallFrame.
2942         (JSC::StackIterator::operator*):
2943         (JSC::StackIterator::operator->):
2944         (JSC::StackIterator::operator!=):
2945         (JSC::StackIterator::operator++):
2946         (JSC::StackIterator::end):
2947         (JSC::StackIterator::operator==):
2948         * interpreter/StackIteratorPrivate.h: Removed.
2949
2950 2013-08-29  Chris Curtis  <chris_curtis@apple.com>
2951
2952         VM::throwException() crashes reproducibly in testapi with !ENABLE(JIT)
2953         https://bugs.webkit.org/show_bug.cgi?id=120472
2954
2955         Reviewed by Filip Pizlo.
2956         
2957         With the JIT disabled, interpreterThrowInCaller was attempting to throw an error, 
2958         but the topCallFrame was not set yet. By passing the error object into interpreterThrowInCaller
2959         throwException can be called when topCallFrame is set.
2960         * llint/LLIntSlowPaths.cpp:
2961         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2962         * runtime/CommonSlowPaths.cpp:
2963         (JSC::SLOW_PATH_DECL):
2964         * runtime/CommonSlowPathsExceptions.cpp:
2965         (JSC::CommonSlowPaths::interpreterThrowInCaller):
2966         * runtime/CommonSlowPathsExceptions.h:
2967
2968         Renamed genericThrow -> genericUnwind, because this function no longer has the ability
2969         to throw errors. It unwinds the stack in order to report them. 
2970         * dfg/DFGOperations.cpp:
2971         * jit/JITExceptions.cpp:
2972         (JSC::genericUnwind):
2973         (JSC::jitThrowNew):
2974         (JSC::jitThrow):
2975         * jit/JITExceptions.h:
2976         * llint/LLIntExceptions.cpp:
2977         (JSC::LLInt::doThrow):
2978     
2979 2013-08-29  Commit Queue  <commit-queue@webkit.org>
2980
2981         Unreviewed, rolling out r154804.
2982         http://trac.webkit.org/changeset/154804
2983         https://bugs.webkit.org/show_bug.cgi?id=120477
2984
2985         Broke Windows build (assumes LLInt features not enabled on
2986         this build) (Requested by bfulgham on #webkit).
2987
2988         * CMakeLists.txt:
2989         * GNUmakefile.list.am:
2990         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2991         * JavaScriptCore.xcodeproj/project.pbxproj:
2992         * Target.pri:
2993         * bytecode/CodeBlock.cpp:
2994         (JSC::CodeBlock::linkIncomingCall):
2995         (JSC::CodeBlock::unlinkIncomingCalls):
2996         (JSC::CodeBlock::reoptimize):
2997         (JSC::ProgramCodeBlock::replacement):
2998         (JSC::EvalCodeBlock::replacement):
2999         (JSC::FunctionCodeBlock::replacement):
3000         (JSC::ProgramCodeBlock::compileOptimized):
3001         (JSC::ProgramCodeBlock::replaceWithDeferredOptimizedCode):
3002         (JSC::EvalCodeBlock::compileOptimized):
3003         (JSC::EvalCodeBlock::replaceWithDeferredOptimizedCode):
3004         (JSC::FunctionCodeBlock::compileOptimized):
3005         (JSC::FunctionCodeBlock::replaceWithDeferredOptimizedCode):
3006         (JSC::ProgramCodeBlock::jitCompileImpl):
3007         (JSC::EvalCodeBlock::jitCompileImpl):
3008         (JSC::FunctionCodeBlock::jitCompileImpl):
3009         * bytecode/CodeBlock.h:
3010         (JSC::CodeBlock::jitType):
3011         (JSC::CodeBlock::jitCompile):
3012         * bytecode/DeferredCompilationCallback.cpp: Removed.
3013         * bytecode/DeferredCompilationCallback.h: Removed.
3014         * dfg/DFGDriver.cpp:
3015         (JSC::DFG::compile):
3016         (JSC::DFG::tryCompile):
3017         (JSC::DFG::tryCompileFunction):
3018         (JSC::DFG::tryFinalizePlan):
3019         * dfg/DFGDriver.h:
3020         (JSC::DFG::tryCompile):
3021         (JSC::DFG::tryCompileFunction):
3022         (JSC::DFG::tryFinalizePlan):
3023         * dfg/DFGFailedFinalizer.cpp:
3024         (JSC::DFG::FailedFinalizer::finalize):
3025         (JSC::DFG::FailedFinalizer::finalizeFunction):
3026         * dfg/DFGFailedFinalizer.h:
3027         * dfg/DFGFinalizer.h:
3028         * dfg/DFGJITFinalizer.cpp:
3029         (JSC::DFG::JITFinalizer::finalize):
3030         (JSC::DFG::JITFinalizer::finalizeFunction):
3031         * dfg/DFGJITFinalizer.h:
3032         * dfg/DFGOSRExitPreparation.cpp:
3033         (JSC::DFG::prepareCodeOriginForOSRExit):
3034         * dfg/DFGOperations.cpp:
3035         * dfg/DFGPlan.cpp:
3036         (JSC::DFG::Plan::Plan):
3037         (JSC::DFG::Plan::compileInThreadImpl):
3038         (JSC::DFG::Plan::finalize):
3039         * dfg/DFGPlan.h:
3040         * dfg/DFGSpeculativeJIT32_64.cpp:
3041         (JSC::DFG::SpeculativeJIT::compile):
3042         * dfg/DFGWorklist.cpp:
3043         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
3044         (JSC::DFG::Worklist::runThread):
3045         * ftl/FTLJITFinalizer.cpp:
3046         (JSC::FTL::JITFinalizer::finalize):
3047         (JSC::FTL::JITFinalizer::finalizeFunction):
3048         * ftl/FTLJITFinalizer.h:
3049         * heap/Heap.h:
3050         * interpreter/Interpreter.cpp:
3051         (JSC::Interpreter::execute):
3052         (JSC::Interpreter::executeCall):
3053         (JSC::Interpreter::executeConstruct):
3054         (JSC::Interpreter::prepareForRepeatCall):
3055         * jit/JITDriver.h: Added.
3056         (JSC::jitCompileIfAppropriateImpl):
3057         (JSC::jitCompileFunctionIfAppropriateImpl):
3058         (JSC::jitCompileIfAppropriate):
3059         (JSC::jitCompileFunctionIfAppropriate):
3060         * jit/JITStubs.cpp:
3061         (JSC::DEFINE_STUB_FUNCTION):
3062         (JSC::jitCompileFor):
3063         (JSC::lazyLinkFor):
3064         * jit/JITToDFGDeferredCompilationCallback.cpp: Removed.
3065         * jit/JITToDFGDeferredCompilationCallback.h: Removed.
3066         * llint/LLIntEntrypoints.cpp:
3067         (JSC::LLInt::getFunctionEntrypoint):
3068         (JSC::LLInt::getEvalEntrypoint):
3069         (JSC::LLInt::getProgramEntrypoint):
3070         * llint/LLIntEntrypoints.h:
3071         (JSC::LLInt::getEntrypoint):
3072         * llint/LLIntSlowPaths.cpp:
3073         (JSC::LLInt::jitCompileAndSetHeuristics):
3074         (JSC::LLInt::setUpCall):
3075         * runtime/ArrayPrototype.cpp:
3076         (JSC::isNumericCompareFunction):
3077         * runtime/CommonSlowPaths.cpp:
3078         * runtime/CompilationResult.cpp:
3079         (WTF::printInternal):
3080         * runtime/CompilationResult.h:
3081         * runtime/Executable.cpp:
3082         (JSC::EvalExecutable::compileOptimized):
3083         (JSC::EvalExecutable::jitCompile):
3084         (JSC::EvalExecutable::compileInternal):
3085         (JSC::EvalExecutable::replaceWithDeferredOptimizedCode):
3086         (JSC::ProgramExecutable::compileOptimized):
3087         (JSC::ProgramExecutable::jitCompile):
3088         (JSC::ProgramExecutable::compileInternal):
3089         (JSC::ProgramExecutable::replaceWithDeferredOptimizedCode):
3090         (JSC::FunctionExecutable::compileOptimizedForCall):
3091         (JSC::FunctionExecutable::compileOptimizedForConstruct):
3092         (JSC::FunctionExecutable::jitCompileForCall):
3093         (JSC::FunctionExecutable::jitCompileForConstruct):
3094         (JSC::FunctionExecutable::produceCodeBlockFor):
3095         (JSC::FunctionExecutable::compileForCallInternal):
3096         (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForCall):
3097         (JSC::FunctionExecutable::compileForConstructInternal):
3098         (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForConstruct):
3099         * runtime/Executable.h:
3100         (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
3101         (JSC::ExecutableBase::offsetOfNumParametersFor):
3102         (JSC::ExecutableBase::catchRoutineFor):
3103         (JSC::EvalExecutable::compile):
3104         (JSC::ProgramExecutable::compile):
3105         (JSC::FunctionExecutable::compileForCall):
3106         (JSC::FunctionExecutable::compileForConstruct):
3107         (JSC::FunctionExecutable::compileFor):
3108         (JSC::FunctionExecutable::compileOptimizedFor):
3109         (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeFor):
3110         (JSC::FunctionExecutable::jitCompileFor):
3111         * runtime/ExecutionHarness.h: Added.
3112         (JSC::prepareForExecutionImpl):
3113         (JSC::prepareFunctionForExecutionImpl):
3114         (JSC::installOptimizedCode):
3115         (JSC::prepareForExecution):
3116         (JSC::prepareFunctionForExecution):
3117         (JSC::replaceWithDeferredOptimizedCode):
3118
3119 2013-08-28  Filip Pizlo  <fpizlo@apple.com>
3120
3121         CodeBlock compilation and installation should be simplified and rationalized
3122         https://bugs.webkit.org/show_bug.cgi?id=120326
3123
3124         Reviewed by Oliver Hunt.
3125         
3126         Previously Executable owned the code for generating JIT code; you always had
3127         to go through Executable. But often you also had to go through CodeBlock,
3128         because ScriptExecutable couldn't have virtual methods, but CodeBlock could.
3129         So you'd ask CodeBlock to do something, which would dispatch through a
3130         virtual method that would select the appropriate Executable subtype's method.
3131         This all meant that the same code would often be duplicated, because most of
3132         the work needed to compile something was identical regardless of code type.
3133         But then we tried to fix this, by having templatized helpers in
3134         ExecutionHarness.h and JITDriver.h. The result was that if you wanted to find
3135         out what happened when you asked for something to be compiled, you'd go on a
3136         wild ride that started with CodeBlock, touched upon Executable, and then
3137         ricocheted into either ExecutionHarness or JITDriver (likely both).
3138         
3139         Another awkwardness was that for concurrent compiles, the DFG::Worklist had
3140         super-special inside knowledge of what JITStubs.cpp's cti_optimize would have
3141         done once the compilation finished.
3142         
3143         Also, most of the DFG JIT drivers assumed that they couldn't install the
3144         JITCode into the CodeBlock directly - instead they would return it via a
3145         reference, which happened to be a reference to the JITCode pointer in
3146         Executable. This was super weird.
3147         
3148         Finally, there was no notion of compiling code into a special CodeBlock that
3149         wasn't used for handling calls into an Executable. I'd like this for FTL OSR
3150         entry.
3151         
3152         This patch solves these problems by reducing all of that complexity into just
3153         three primitives:
3154         
3155         - Executable::newCodeBlock(). This gives you a new code block, either for call
3156           or for construct, and either to serve as the baseline code or the optimized
3157           code. The new code block is then owned by the caller; Executable doesn't
3158           register it anywhere. The new code block has no JITCode and isn't callable,
3159           but it has all of the bytecode.
3160         
3161         - CodeBlock::prepareForExecution(). This takes the CodeBlock's bytecode and
3162           produces a JITCode, and then installs the JITCode into the CodeBlock. This
3163           method takes a JITType, and always compiles with that JIT. If you ask for
3164           JITCode::InterpreterThunk then you'll get JITCode that just points to the
3165           LLInt entrypoints. Once this returns, it is possible to call into the
3166           CodeBlock if you do so manually - but the Executable still won't know about
3167           it so JS calls to that Executable will still be routed to whatever CodeBlock
3168           is associated with the Executable.
3169         
3170         - Executable::installCode(). This takes a CodeBlock and makes it the code-for-
3171           entry for that Executable. This involves unlinking the Executable's last
3172           CodeBlock, if there was one. This also tells the GC about any effect on
3173           memory usage and does a bunch of weird data structure rewiring, since
3174           Executable caches some of CodeBlock's fields for the benefit of virtual call
3175           fast paths.
3176         
3177         This functionality is then wrapped around three convenience methods:
3178         
3179         - Executable::prepareForExecution(). If there is no code block for that
3180           Executable, then one is created (newCodeBlock()), compiled
3181           (CodeBlock::prepareForExecution()) and installed (installCode()).
3182         
3183         - CodeBlock::newReplacement(). Asks the Executable for a new CodeBlock that
3184           can serve as an optimized replacement of the current one.
3185         
3186         - CodeBlock::install(). Asks the Executable to install this code block.
3187         
3188         This patch allows me to kill *a lot* of code and to remove a lot of
3189         specializations for functions vs. not-functions, and a lot of places where we
3190         pass around JITCode references and such. ExecutionHarness and JITDriver are
3191         both gone. Overall this patch has more red than green.
3192         
3193         It also allows me to work on FTL OSR entry and tier-up:
3194         
3195         - FTL tier-up: this will involve DFGOperations.cpp asking the DFG::Worklist
3196           to do some compilation, but it will require the DFG::Worklist to do
3197           something different than what JITStubs.cpp would want, once the compilation
3198           finishes. This patch introduces a callback mechanism for that purpose.
3199         
3200         - FTL OSR entry: this will involve creating a special auto-jettisoned
3201           CodeBlock that is used only for FTL OSR entry. The new set of primitives
3202           allows for this: Executable can vend you a fresh new CodeBlock, and you can
3203           ask that CodeBlock to compile itself with any JIT of your choosing. Or you
3204           can take that CodeBlock and compile it yourself. Previously the act of
3205           producing a CodeBlock-for-optimization and the act of compiling code for it
3206           were tightly coupled; now you can separate them and you can create such
3207           auto-jettisoned CodeBlocks that are used for a one-shot OSR entry.
3208
3209         * CMakeLists.txt:
3210         * GNUmakefile.list.am:
3211         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3212         * JavaScriptCore.xcodeproj/project.pbxproj:
3213         * Target.pri:
3214         * bytecode/CodeBlock.cpp:
3215         (JSC::CodeBlock::prepareForExecution):
3216         (JSC::CodeBlock::install):
3217         (JSC::CodeBlock::newReplacement):
3218         (JSC::FunctionCodeBlock::jettisonImpl):
3219         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
3220         * bytecode/CodeBlock.h:
3221         (JSC::CodeBlock::hasBaselineJITProfiling):
3222         * bytecode/DeferredCompilationCallback.cpp: Added.
3223         (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
3224         (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
3225         * bytecode/DeferredCompilationCallback.h: Added.
3226         * dfg/DFGDriver.cpp:
3227         (JSC::DFG::tryCompile):
3228         * dfg/DFGDriver.h:
3229         (JSC::DFG::tryCompile):
3230         * dfg/DFGFailedFinalizer.cpp:
3231         (JSC::DFG::FailedFinalizer::finalize):
3232         (JSC::DFG::FailedFinalizer::finalizeFunction):
3233         * dfg/DFGFailedFinalizer.h:
3234         * dfg/DFGFinalizer.h:
3235         * dfg/DFGJITFinalizer.cpp:
3236         (JSC::DFG::JITFinalizer::finalize):
3237         (JSC::DFG::JITFinalizer::finalizeFunction):
3238         * dfg/DFGJITFinalizer.h:
3239         * dfg/DFGOSRExitPreparation.cpp:
3240         (JSC::DFG::prepareCodeOriginForOSRExit):
3241         * dfg/DFGOperations.cpp:
3242         * dfg/DFGPlan.cpp:
3243         (JSC::DFG::Plan::Plan):
3244         (JSC::DFG::Plan::compileInThreadImpl):
3245         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
3246         (JSC::DFG::Plan::finalizeAndNotifyCallback):
3247         * dfg/DFGPlan.h:
3248         * dfg/DFGWorklist.cpp:
3249         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
3250         * ftl/FTLJITFinalizer.cpp:
3251         (JSC::FTL::JITFinalizer::finalize):
3252         (JSC::FTL::JITFinalizer::finalizeFunction):
3253         * ftl/FTLJITFinalizer.h:
3254         * heap/Heap.h:
3255         (JSC::Heap::isDeferred):
3256         * interpreter/Interpreter.cpp:
3257         (JSC::Interpreter::execute):
3258         (JSC::Interpreter::executeCall):
3259         (JSC::Interpreter::executeConstruct):
3260         (JSC::Interpreter::prepareForRepeatCall):
3261         * jit/JITDriver.h: Removed.
3262         * jit/JITStubs.cpp:
3263         (JSC::DEFINE_STUB_FUNCTION):
3264         (JSC::jitCompileFor):
3265         (JSC::lazyLinkFor):
3266         * jit/JITToDFGDeferredCompilationCallback.cpp: Added.
3267         (JSC::JITToDFGDeferredCompilationCallback::JITToDFGDeferredCompilationCallback):
3268         (JSC::JITToDFGDeferredCompilationCallback::~JITToDFGDeferredCompilationCallback):
3269         (JSC::JITToDFGDeferredCompilationCallback::create):
3270         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
3271         * jit/JITToDFGDeferredCompilationCallback.h: Added.
3272         * llint/LLIntEntrypoints.cpp:
3273         (JSC::LLInt::setFunctionEntrypoint):
3274         (JSC::LLInt::setEvalEntrypoint):
3275         (JSC::LLInt::setProgramEntrypoint):
3276         * llint/LLIntEntrypoints.h:
3277         * llint/LLIntSlowPaths.cpp:
3278         (JSC::LLInt::jitCompileAndSetHeuristics):
3279         (JSC::LLInt::setUpCall):
3280         * runtime/ArrayPrototype.cpp:
3281         (JSC::isNumericCompareFunction):
3282         * runtime/CommonSlowPaths.cpp:
3283         * runtime/CompilationResult.cpp:
3284         (WTF::printInternal):
3285         * runtime/CompilationResult.h:
3286         * runtime/Executable.cpp:
3287         (JSC::ScriptExecutable::installCode):
3288         (JSC::ScriptExecutable::newCodeBlockFor):
3289         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
3290         (JSC::ScriptExecutable::prepareForExecutionImpl):
3291         * runtime/Executable.h:
3292         (JSC::ScriptExecutable::prepareForExecution):
3293         (JSC::FunctionExecutable::jettisonOptimizedCodeFor):
3294         * runtime/ExecutionHarness.h: Removed.
3295
3296 2013-08-28  Chris Curtis  <chris_curtis@apple.com>
3297
3298         https://bugs.webkit.org/show_bug.cgi?id=119548
3299         Refactoring Exception throws.
3300         
3301         Reviewed by Geoffrey Garen.
3302         
3303         Gardening of exception throws. The act of throwing an exception was being handled in 
3304         different ways depending on whether the code was running in the LLint, Baseline JIT, 
3305         or the DFG Jit. This made development in the vm exception and error objects difficult.
3306         
3307          * runtime/VM.cpp:
3308         (JSC::appendSourceToError): 
3309         This function moved from the interpreter into the VM. It views the developers code
3310         (if there is a codeBlock) to extract what was trying to be evaluated when the error
3311         occurred.
3312         
3313         (JSC::VM::throwException):
3314         This function takes in the error object and sets the following:
3315             1: The VM's exception stack
3316             2: The VM's exception 
3317             3: Appends extra information on the error message(via appendSourceToError)
3318             4: The error object's line number
3319             5: The error object's column number
3320             6: The error object's sourceURL
3321             7: The error object's stack trace (unless it already exists because the developer 
3322                 created the error object). 
3323
3324         (JSC::VM::getExceptionInfo):
3325         (JSC::VM::setExceptionInfo):
3326         (JSC::VM::clearException):
3327         (JSC::clearExceptionStack):
3328         * runtime/VM.h:
3329         (JSC::VM::exceptionOffset):
3330         (JSC::VM::exception):
3331         (JSC::VM::addressOfException):
3332         (JSC::VM::exceptionStack):
3333         VM exception and exceptionStack are now private data members.
3334
3335         * interpreter/Interpreter.h:
3336         (JSC::ClearExceptionScope::ClearExceptionScope):
3337         Created this structure to temporarily clear the exception within the VM. This 
3338         needed to see if addition errors occur when setting the debugger as we are 
3339         unwinding the stack.
3340
3341          * interpreter/Interpreter.cpp:
3342         (JSC::Interpreter::unwind): 
3343         Removed the code that would try to add error information if it did not exist. 
3344         All of this functionality has moved into the VM and all error information is set 
3345         at the time the error occurs. 
3346
3347         The rest of these functions reference the new calling convention to throw an error.
3348
3349         * API/APICallbackFunction.h:
3350         (JSC::APICallbackFunction::call):
3351         * API/JSCallbackConstructor.cpp:
3352         (JSC::constructJSCallback):
3353         * API/JSCallbackObjectFunctions.h:
3354         (JSC::::getOwnPropertySlot):
3355         (JSC::::defaultValue):
3356         (JSC::::put):
3357         (JSC::::putByIndex):
3358         (JSC::::deleteProperty):
3359         (JSC::::construct):
3360         (JSC::::customHasInstance):