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