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