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