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