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