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