r134080 causes heap problem on linux systems where PAGESIZE != 4096
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-01-18  Balazs Kilvady  <kilvadyb@homejinni.com>
2
3         r134080 causes heap problem on linux systems where PAGESIZE != 4096
4         https://bugs.webkit.org/show_bug.cgi?id=102828
5
6         Reviewed by Mark Hahnenberg.
7
8         Make MarkStackSegment::blockSize as the capacity of segments of a MarkStackArray.
9
10         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
11         * heap/MarkStack.cpp:
12         (JSC):
13         (JSC::MarkStackArray::MarkStackArray):
14         (JSC::MarkStackArray::expand):
15         (JSC::MarkStackArray::donateSomeCellsTo):
16         (JSC::MarkStackArray::stealSomeCellsFrom):
17         * heap/MarkStack.h:
18         (JSC::MarkStackSegment::data):
19         (CapacityFromSize):
20         (MarkStackArray):
21         * heap/MarkStackInlines.h:
22         (JSC::MarkStackArray::setTopForFullSegment):
23         (JSC::MarkStackArray::append):
24         (JSC::MarkStackArray::isEmpty):
25         (JSC::MarkStackArray::size):
26         * runtime/Options.h:
27         (JSC):
28
29 2013-01-18  Geoffrey Garen  <ggaren@apple.com>
30
31         Weak GC maps should be easier to use
32         https://bugs.webkit.org/show_bug.cgi?id=107312
33
34         Reviewed by Sam Weinig.
35
36         This patch changes WeakGCMap to not use a WeakImpl finalizer to remove
37         items from the map, and to instead have the map automatically remove
38         stale items itself upon insertion. This has a few advantages:
39
40         (1) WeakGCMap is now compatible with all the specializations you would
41         use for HashMap.
42
43         (2) There's no need for clients to write special finalization munging
44         functions.
45
46         (3) Clients can specify custom value finalizers if they like.
47
48         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Def!
49
50         * API/JSWeakObjectMapRefPrivate.cpp: Setter no longer requires a global
51         data, since we've reduced interdependency.
52
53         * heap/Handle.h: No more need to forward declare, since we've reduced
54         interdependency.
55
56         * heap/Weak.h:
57         (Weak): Use explicit so we can assign directly to a weak map iterator
58         without ambiguity between Weak<T> and PassWeak<T>.
59
60         * runtime/Structure.cpp:
61         (JSC::StructureTransitionTable::add): See above.
62
63         * runtime/Structure.h:
64         (JSC):
65         * runtime/StructureTransitionTable.h:
66         (StructureTransitionTable): Bad code goes away, programmer happy.
67
68         * runtime/WeakGCMap.h:
69         (JSC):
70         (WeakGCMap):
71         (JSC::WeakGCMap::WeakGCMap):
72         (JSC::WeakGCMap::set):
73         (JSC::WeakGCMap::add):
74         (JSC::WeakGCMap::find):
75         (JSC::WeakGCMap::contains):
76         (JSC::WeakGCMap::gcMap):
77         (JSC::WeakGCMap::gcMapIfNeeded): Inherit from HashMap and override any
78         function that might observe a Weak<T> that has died, just enough to
79         make such items appear as if they are not in the table.
80
81 2013-01-18  Michael Saboff  <msaboff@apple.com>
82
83         Refactor isPowerOf2() and add getLSBSet()
84         https://bugs.webkit.org/show_bug.cgi?id=107306
85
86         Reviewed by Filip Pizlo.
87
88         Moved implementation of isPowerOf2() to new hasOneBitSet() in wtf/MathExtras.h.
89
90         * runtime/PropertyMapHashTable.h:
91         (JSC::isPowerOf2):
92
93 2013-01-17  Mark Hahnenberg  <mhahnenberg@apple.com>
94
95         Objective-C API: Clean up JSValue.mm
96         https://bugs.webkit.org/show_bug.cgi?id=107163
97
98         Reviewed by Darin Adler.
99
100         m_context is no longer weak, so there is now a lot of dead code in in JSValue.mm, and a wasted message send 
101         on every API call.  In the head of just about every method in JSValue.mm we're doing:
102
103         JSContext *context = [self context];
104         if (!context)
105             return nil;
106
107         This is getting a retained copy of the context, which is no longer necessary now m_context is no longer weak.  
108         We can just delete all these lines from all functions doing this, and where they were referring to the local 
109         variable 'context', instead we can just access m_context directly.
110
111         Since we're already going to be modifying most of JSValue.mm, we'll also do the following:
112
113         1) context @property is no longer weak – the context property is declared as:
114
115             @property(readonly, weak) JSContext *context;
116
117         This is really only informative (since we're not presently synthesizing the ivar), but it is now misleading. 
118         We should change it to:
119
120             @property(readonly, retain) JSContext *context;
121
122         2) the JSContext ivar and accessor can be automatically generated.  Since we're no longer doing anything 
123         special with m_context, we can just let the compiler handle the ivar for us.  We'll delete:
124
125             JSContext *m_context;
126
127         and:
128
129             - (JSContext *)context
130             {
131                 return m_context;
132         
133             }
134
135         and find&replace "m_context" to "_context" in JSValue.mm.
136
137         * API/APIJSValue.h:
138         * API/JSValue.mm:
139         (-[JSValue toObject]):
140         (-[JSValue toBool]):
141         (-[JSValue toDouble]):
142         (-[JSValue toNumber]):
143         (-[JSValue toString]):
144         (-[JSValue toDate]):
145         (-[JSValue toArray]):
146         (-[JSValue toDictionary]):
147         (-[JSValue valueForProperty:]):
148         (-[JSValue setValue:forProperty:]):
149         (-[JSValue deleteProperty:]):
150         (-[JSValue hasProperty:]):
151         (-[JSValue defineProperty:descriptor:]):
152         (-[JSValue valueAtIndex:]):
153         (-[JSValue setValue:atIndex:]):
154         (-[JSValue isUndefined]):
155         (-[JSValue isNull]):
156         (-[JSValue isBoolean]):
157         (-[JSValue isNumber]):
158         (-[JSValue isString]):
159         (-[JSValue isObject]):
160         (-[JSValue isEqualToObject:]):
161         (-[JSValue isEqualWithTypeCoercionToObject:]):
162         (-[JSValue isInstanceOf:]):
163         (-[JSValue callWithArguments:]):
164         (-[JSValue constructWithArguments:]):
165         (-[JSValue invokeMethod:withArguments:]):
166         (-[JSValue objectForKeyedSubscript:]):
167         (-[JSValue setObject:forKeyedSubscript:]):
168         (-[JSValue initWithValue:inContext:]):
169         (-[JSValue dealloc]):
170         (-[JSValue description]):
171
172 2013-01-17  Mark Hahnenberg  <mhahnenberg@apple.com>
173
174         Objective-C API: Clean up JSValue
175         https://bugs.webkit.org/show_bug.cgi?id=107156
176
177         Reviewed by Oliver Hunt.
178
179         JSContext m_protectCounts, protect, unprotect are all now unnecessary overhead, and should all be removed.  
180         These exist to handle the context going away before the value does; the context needs to be able to unprotect 
181         values early.  Since the value is now keeping the context alive there is no longer any danger of this happening; 
182         instead we should just protect/unprotect the value in JSValue's init/dealloc methods.
183
184         * API/JSContext.mm:
185         (-[JSContext dealloc]):
186         * API/JSContextInternal.h:
187         * API/JSValue.mm:
188         (-[JSValue initWithValue:inContext:]):
189         (-[JSValue dealloc]):
190
191 2013-01-17  Filip Pizlo  <fpizlo@apple.com>
192
193         DFG Node::ref() and Node::deref() should not return bool, and should have postfixRef variants
194         https://bugs.webkit.org/show_bug.cgi?id=107147
195
196         Reviewed by Mark Hahnenberg.
197         
198         This small refactoring will enable a world where ref() returns Node*, which is useful for
199         https://bugs.webkit.org/show_bug.cgi?id=106868.  Also, while this refactoring does lead to
200         slightly less terse code, it's also slightly more self-explanatory.  I could never quite
201         remember what the meaning of the bool return from ref() and deref() was.
202
203         * dfg/DFGGraph.cpp:
204         (JSC::DFG::Graph::collectGarbage):
205         * dfg/DFGGraph.h:
206         (JSC::DFG::Graph::ref):
207         (JSC::DFG::Graph::deref):
208         * dfg/DFGNode.h:
209         (JSC::DFG::Node::ref):
210         (Node):
211         (JSC::DFG::Node::postfixRef):
212         (JSC::DFG::Node::deref):
213         (JSC::DFG::Node::postfixDeref):
214
215 2013-01-17  Alexey Proskuryakov  <ap@apple.com>
216
217         Added svn:ignore=*.pyc, so that ud_opcode.pyc and ud_optable.pyc don't show up
218         in svn stat.
219
220         * disassembler/udis86: Added property svn:ignore.
221
222 2013-01-16  Filip Pizlo  <fpizlo@apple.com>
223
224         DFG 32_64 backend doesn't check for hasArrayStorage() in NewArrayWithSize
225         https://bugs.webkit.org/show_bug.cgi?id=107081
226
227         Reviewed by Michael Saboff.
228
229         This bug led to the 32_64 backend emitting contiguous allocation code to allocate
230         ArrayStorage arrays. This then led to all manner of heap corruption, since
231         subsequent array accesses would be accessing the contiguous array "as if" it was
232         an arraystorage array.
233
234         * dfg/DFGSpeculativeJIT32_64.cpp:
235         (JSC::DFG::SpeculativeJIT::compile):
236
237 2013-01-16  Jonathan Liu  <net147@gmail.com>
238
239         Add missing sys/mman.h include on Mac
240         https://bugs.webkit.org/show_bug.cgi?id=98089
241
242         Reviewed by Darin Adler.
243
244         The madvise function and MADV_FREE constant require sys/mman.h.
245
246         * jit/ExecutableAllocatorFixedVMPool.cpp:
247
248 2013-01-15  Michael Saboff  <msaboff@apple.com>
249
250         DFG X86: division in the used-as-int case doesn't correctly check for -2^31/-1
251         https://bugs.webkit.org/show_bug.cgi?id=106978
252
253         Reviewed by Filip Pizlo.
254
255         Changed the numerator equal to -2^31 check to just return if we expect an integer
256         result, since the check is after we have determined that the denominator is -1.
257         The int result of -2^31 / -1 is -2^31, so just return the numerator as the result.
258
259         * dfg/DFGSpeculativeJIT.cpp:
260         (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86):
261
262 2013-01-15  Levi Weintraub  <leviw@chromium.org>
263
264         Unreviewed, rolling out r139792.
265         http://trac.webkit.org/changeset/139792
266         https://bugs.webkit.org/show_bug.cgi?id=106970
267
268         Broke the windows build.
269
270         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.
271
272 2013-01-15  Pratik Solanki  <psolanki@apple.com>
273
274         Use MADV_FREE_REUSABLE to return JIT memory to OS
275         https://bugs.webkit.org/show_bug.cgi?id=106830
276         <rdar://problem/11437701>
277
278         Reviewed by Geoffrey Garen.
279
280         Use MADV_FREE_REUSABLE to return JIT memory on OSes that have the underlying madvise bug
281         fixed.
282
283         * jit/ExecutableAllocatorFixedVMPool.cpp:
284         (JSC::FixedVMPoolExecutableAllocator::notifyPageIsFree):
285
286 2013-01-15  Levi Weintraub  <leviw@chromium.org>
287
288         Unreviewed, rolling out r139790.
289         http://trac.webkit.org/changeset/139790
290         https://bugs.webkit.org/show_bug.cgi?id=106948
291
292         The patch is failing its own test.
293
294         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.
295
296 2013-01-15  Zan Dobersek  <zandobersek@gmail.com>
297
298         [Autotools] Unify JavaScriptCore sources list, regardless of target OS
299         https://bugs.webkit.org/show_bug.cgi?id=106007
300
301         Reviewed by Gustavo Noronha Silva.
302
303         Include the Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp target
304         in the general sources list as it is guarded by the ENABLE_EXECUTABLE_ALLOCATOR_FIXED
305         feature define. This define is only used on 64-bit architecture and indirectly depends
306         on enabling either JIT or YARR JIT feature. Both of these defines are disabled on
307         Windows OS when using 64-bit architecture so there's no need to add this target to
308         sources only when the target OS is Windows.
309
310         * GNUmakefile.list.am:
311
312 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
313
314         DFG should not forget that it had proved something to be a constant during a merge just because it's merging against the empty value
315         https://bugs.webkit.org/show_bug.cgi?id=106727
316
317         Reviewed by Oliver Hunt.
318         
319         The problem was this statement:
320         
321         if (m_value != other.m_value)
322             m_value = JSValue();
323         
324         This is well-intentioned, in the sense that if we want our abstract value (i.e. this) to become the superset of the other
325         abstract value, and the two abstract values have proven different constants, then our abstract value should rescind its
326         claim that it has been proven to be constant. But this misses the special case that if the other abstract value is
327         completely clear (meaning that it wishes to contribute zero information and so the superset operation shouldn't change
328         this), it will have a clear m_value. So, the code prior to this patch would rescind the constant proof even though it
329         didn't have to.
330         
331         This comes up rarely and I don't believe it will be a performance win, but it is good to have the CFA been consistently
332         precise as often as possible.
333
334         * dfg/DFGAbstractValue.h:
335         (JSC::DFG::AbstractValue::merge):
336
337 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
338
339         Python implementation reports "MemoryError" instead of doing things
340         https://bugs.webkit.org/show_bug.cgi?id=106690
341
342         Reviewed by Oliver Hunt.
343         
344         The bug was that the CFA was assuming that a variable is dead at the end of a basic block and hence doesn't need to
345         be merged to the next block if the last mention of the variable was dead. This is almost correct, except that it
346         doesn't work if the last mention is a GetLocal - the GetLocal itself may be dead, but that doesn't mean that the
347         variable is dead - it may still be live. The appropriate thing to do is to look at the GetLocal's Phi. If the
348         variable is used in the next block then the next block will have a reference to the last mention in our block unless
349         that last mention is a GetLocal, in which case it will link to the Phi. Doing it this way captures everything that
350         the CFA wants: if the last use is a live GetLocal then the CFA needs to consider the GetLocal itself for possible
351         refinements to the proof of the value in the variable, but if the GetLocal is dead, then this must mean that the
352         variable is not mentioned in the block but may still be "passed through" it, which is what the Phi will tell us.
353         Note that it is not possible for the GetLocal to refer to anything other than a Phi, and it is also not possible
354         for the last mention of a variable to be a dead GetLocal while there are other mentions that aren't dead - if
355         there had been SetLocals or GetLocals prior to the dead one then the dead one wouldn't have been emitted by the
356         parser.
357         
358         This also fixes a similar bug in the handling of captured variables. If a variable is captured, then it doesn't
359         matter if the last mention is dead, or not. Either way, we already know that a captured variable will be live in
360         the next block, so we must merge it no matter what.
361         
362         Finally, this change makes the output of Operands dumping a bit more verbose: it now prints the variable name next
363         to each variable's dump. I've often found the lack of this information confusing particularly for operand dumps
364         that involve a lot of variables.
365
366         * bytecode/Operands.h:
367         (JSC::dumpOperands):
368         * dfg/DFGAbstractState.cpp:
369         (JSC::DFG::AbstractState::mergeStateAtTail):
370
371 2013-01-14  Roger Fong  <roger_fong@apple.com>
372
373         Unreviewed. Fix vcproj file. Missing file tag after http://trac.webkit.org/changeset/139541.
374
375         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
376
377 2013-01-13  Filip Pizlo  <fpizlo@apple.com>
378
379         DFG phases that store per-node information should store it in Node itself rather than using a secondary vector
380         https://bugs.webkit.org/show_bug.cgi?id=106753
381
382         Reviewed by Geoffrey Garen.
383
384         * dfg/DFGAbstractState.cpp:
385         (JSC::DFG::AbstractState::AbstractState):
386         (JSC::DFG::AbstractState::beginBasicBlock):
387         (JSC::DFG::AbstractState::dump):
388         * dfg/DFGAbstractState.h:
389         (JSC::DFG::AbstractState::forNode):
390         (AbstractState):
391         * dfg/DFGCFGSimplificationPhase.cpp:
392         * dfg/DFGCSEPhase.cpp:
393         (JSC::DFG::CSEPhase::CSEPhase):
394         (JSC::DFG::CSEPhase::performSubstitution):
395         (JSC::DFG::CSEPhase::setReplacement):
396         (CSEPhase):
397         * dfg/DFGNode.h:
398         (Node):
399
400 2013-01-12  Tim Horton  <timothy_horton@apple.com>
401
402         Unreviewed build fix.
403
404         * API/JSBlockAdaptor.mm:
405         * API/JSContext.mm:
406         * API/JSValue.mm:
407
408 2013-01-12  Csaba Osztrogonác  <ossy@webkit.org>
409
410         Unreviewed 64 bit buildfix after r139496.
411
412         * dfg/DFGOperations.cpp:
413
414 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
415
416         Unreviewed, speculative build fix.
417
418         * API/JSWrapperMap.mm:
419
420 2013-01-10  Filip Pizlo  <fpizlo@apple.com>
421
422         JITThunks should not compile only because of luck
423         https://bugs.webkit.org/show_bug.cgi?id=105696
424
425         Rubber stamped by Sam Weinig and Geoffrey Garen.
426         
427         This patch was supposed to just move JITThunks into its own file. But then I
428         realized that there is a horrible circular dependency chain between JSCell,
429         JSGlobalData, CallFrame, and Weak, which only works because of magical include
430         order in JITStubs.h, and the fact that JSGlobalData.h includes JITStubs.h
431         before it includes JSCell or JSValue.
432         
433         I first tried to just get JITThunks.h to just magically do the same pointless
434         includes that JITStubs.h had, but then I decided to actually fix the underflying
435         problem, which was that JSCell needed CallFrame, CallFrame needed JSGlobalData,
436         JSGlobalData needed JITThunks, JITThunks needed Weak, and Weak needed JSCell.
437         Now, all of JSCell's outgoing dependencies are placed in JSCellInlines.h. This
438         also gave me an opportunity to move JSValue inline methods from JSCell.h into
439         JSValueInlines.h. But to make this really work, I needed to remove includes of
440         *Inlines.h from other headers (CodeBlock.h for example included JSValueInlines.h,
441         which defeats the whole entire purpose of having an Inlines.h file), and I needed
442         to add includes of *Inlines.h into a bunch of .cpp files. I did this mostly by
443         having .cpp files include Operations.h. In future, if you're adding a .cpp file
444         to JSC, you'll almost certainly have to include Operations.h unless you enjoy
445         link errors.
446
447         * API/JSBase.cpp:
448         * API/JSCallbackConstructor.cpp:
449         * API/JSCallbackFunction.cpp:
450         * API/JSCallbackObject.cpp:
451         * API/JSClassRef.cpp:
452         * API/JSContextRef.cpp:
453         * API/JSObjectRef.cpp:
454         * API/JSScriptRef.cpp:
455         * API/JSWeakObjectMapRefPrivate.cpp:
456         * JSCTypedArrayStubs.h:
457         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
458         * JavaScriptCore.xcodeproj/project.pbxproj:
459         * bytecode/ArrayAllocationProfile.cpp:
460         * bytecode/CodeBlock.cpp:
461         * bytecode/GetByIdStatus.cpp:
462         * bytecode/LazyOperandValueProfile.cpp:
463         * bytecode/ResolveGlobalStatus.cpp:
464         * bytecode/SpeculatedType.cpp:
465         * bytecode/UnlinkedCodeBlock.cpp:
466         * bytecompiler/BytecodeGenerator.cpp:
467         * debugger/Debugger.cpp:
468         * debugger/DebuggerActivation.cpp:
469         * debugger/DebuggerCallFrame.cpp:
470         * dfg/DFGArgumentsSimplificationPhase.cpp:
471         * dfg/DFGArrayMode.cpp:
472         * dfg/DFGByteCodeParser.cpp:
473         * dfg/DFGConstantFoldingPhase.cpp:
474         * dfg/DFGDriver.cpp:
475         * dfg/DFGFixupPhase.cpp:
476         * dfg/DFGGraph.cpp:
477         * dfg/DFGJITCompiler.cpp:
478         * dfg/DFGOSREntry.cpp:
479         * dfg/DFGOSRExitCompiler.cpp:
480         * dfg/DFGOSRExitCompiler32_64.cpp:
481         * dfg/DFGOSRExitCompiler64.cpp:
482         * dfg/DFGPredictionPropagationPhase.cpp:
483         * dfg/DFGSpeculativeJIT.cpp:
484         (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
485         (DFG):
486         (JSC::DFG::SpeculativeJIT::silentSavePlanForFPR):
487         (JSC::DFG::SpeculativeJIT::silentSpill):
488         (JSC::DFG::SpeculativeJIT::silentFill):
489         * dfg/DFGSpeculativeJIT.h:
490         (SpeculativeJIT):
491         * dfg/DFGSpeculativeJIT32_64.cpp:
492         * dfg/DFGSpeculativeJIT64.cpp:
493         * dfg/DFGStructureCheckHoistingPhase.cpp:
494         * dfg/DFGVariableEventStream.cpp:
495         * heap/CopiedBlock.h:
496         * heap/CopiedSpace.cpp:
497         * heap/HandleSet.cpp:
498         * heap/Heap.cpp:
499         * heap/HeapStatistics.cpp:
500         * heap/SlotVisitor.cpp:
501         * heap/WeakBlock.cpp:
502         * interpreter/CallFrame.cpp:
503         * interpreter/CallFrame.h:
504         * jit/ClosureCallStubRoutine.cpp:
505         * jit/GCAwareJITStubRoutine.cpp:
506         * jit/JIT.cpp:
507         * jit/JITArithmetic.cpp:
508         * jit/JITArithmetic32_64.cpp:
509         * jit/JITCall.cpp:
510         * jit/JITCall32_64.cpp:
511         * jit/JITCode.h:
512         * jit/JITExceptions.cpp:
513         * jit/JITStubs.h:
514         * jit/JITThunks.h:
515         * jsc.cpp:
516         * llint/LLIntExceptions.cpp:
517         * profiler/LegacyProfiler.cpp:
518         * profiler/ProfileGenerator.cpp:
519         * profiler/ProfilerBytecode.cpp:
520         * profiler/ProfilerBytecodeSequence.cpp:
521         * profiler/ProfilerBytecodes.cpp:
522         * profiler/ProfilerCompilation.cpp:
523         * profiler/ProfilerCompiledBytecode.cpp:
524         * profiler/ProfilerDatabase.cpp:
525         * profiler/ProfilerOSRExit.cpp:
526         * profiler/ProfilerOSRExitSite.cpp:
527         * profiler/ProfilerOrigin.cpp:
528         * profiler/ProfilerOriginStack.cpp:
529         * profiler/ProfilerProfiledBytecodes.cpp:
530         * runtime/ArgList.cpp:
531         * runtime/Arguments.cpp:
532         * runtime/ArrayConstructor.cpp:
533         * runtime/BooleanConstructor.cpp:
534         * runtime/BooleanObject.cpp:
535         * runtime/BooleanPrototype.cpp:
536         * runtime/CallData.cpp:
537         * runtime/CodeCache.cpp:
538         * runtime/Completion.cpp:
539         * runtime/ConstructData.cpp:
540         * runtime/DateConstructor.cpp:
541         * runtime/DateInstance.cpp:
542         * runtime/DatePrototype.cpp:
543         * runtime/Error.cpp:
544         * runtime/ErrorConstructor.cpp:
545         * runtime/ErrorInstance.cpp:
546         * runtime/ErrorPrototype.cpp:
547         * runtime/ExceptionHelpers.cpp:
548         * runtime/Executable.cpp:
549         * runtime/FunctionConstructor.cpp:
550         * runtime/FunctionPrototype.cpp:
551         * runtime/GetterSetter.cpp:
552         * runtime/Identifier.cpp:
553         * runtime/InternalFunction.cpp:
554         * runtime/JSActivation.cpp:
555         * runtime/JSBoundFunction.cpp:
556         * runtime/JSCell.cpp:
557         * runtime/JSCell.h:
558         (JSC):
559         * runtime/JSCellInlines.h: Added.
560         (JSC):
561         (JSC::JSCell::JSCell):
562         (JSC::JSCell::finishCreation):
563         (JSC::JSCell::structure):
564         (JSC::JSCell::visitChildren):
565         (JSC::allocateCell):
566         (JSC::isZapped):
567         (JSC::JSCell::isObject):
568         (JSC::JSCell::isString):
569         (JSC::JSCell::isGetterSetter):
570         (JSC::JSCell::isProxy):
571         (JSC::JSCell::isAPIValueWrapper):
572         (JSC::JSCell::setStructure):
573         (JSC::JSCell::methodTable):
574         (JSC::JSCell::inherits):
575         (JSC::JSCell::fastGetOwnPropertySlot):
576         (JSC::JSCell::fastGetOwnProperty):
577         (JSC::JSCell::toBoolean):
578         * runtime/JSDateMath.cpp:
579         * runtime/JSFunction.cpp:
580         * runtime/JSFunction.h:
581         (JSC):
582         * runtime/JSGlobalData.h:
583         (JSC):
584         (JSGlobalData):
585         * runtime/JSGlobalObject.cpp:
586         * runtime/JSGlobalObjectFunctions.cpp:
587         * runtime/JSLock.cpp:
588         * runtime/JSNameScope.cpp:
589         * runtime/JSNotAnObject.cpp:
590         * runtime/JSONObject.cpp:
591         * runtime/JSObject.h:
592         (JSC):
593         * runtime/JSProxy.cpp:
594         * runtime/JSScope.cpp:
595         * runtime/JSSegmentedVariableObject.cpp:
596         * runtime/JSString.h:
597         (JSC):
598         * runtime/JSStringJoiner.cpp:
599         * runtime/JSSymbolTableObject.cpp:
600         * runtime/JSValue.cpp:
601         * runtime/JSValueInlines.h:
602         (JSC::JSValue::toInt32):
603         (JSC::JSValue::toUInt32):
604         (JSC):
605         (JSC::JSValue::isUInt32):
606         (JSC::JSValue::asUInt32):
607         (JSC::JSValue::asNumber):
608         (JSC::jsNaN):
609         (JSC::JSValue::JSValue):
610         (JSC::JSValue::encode):
611         (JSC::JSValue::decode):
612         (JSC::JSValue::operator bool):
613         (JSC::JSValue::operator==):
614         (JSC::JSValue::operator!=):
615         (JSC::JSValue::isEmpty):
616         (JSC::JSValue::isUndefined):
617         (JSC::JSValue::isNull):
618         (JSC::JSValue::isUndefinedOrNull):
619         (JSC::JSValue::isCell):
620         (JSC::JSValue::isInt32):
621         (JSC::JSValue::isDouble):
622         (JSC::JSValue::isTrue):
623         (JSC::JSValue::isFalse):
624         (JSC::JSValue::tag):
625         (JSC::JSValue::payload):
626         (JSC::JSValue::asInt32):
627         (JSC::JSValue::asDouble):
628         (JSC::JSValue::asCell):
629         (JSC::JSValue::isNumber):
630         (JSC::JSValue::isBoolean):
631         (JSC::JSValue::asBoolean):
632         (JSC::reinterpretDoubleToInt64):
633         (JSC::reinterpretInt64ToDouble):
634         (JSC::JSValue::isString):
635         (JSC::JSValue::isPrimitive):
636         (JSC::JSValue::isGetterSetter):
637         (JSC::JSValue::isObject):
638         (JSC::JSValue::getString):
639         (JSC::::getString):
640         (JSC::JSValue::getObject):
641         (JSC::JSValue::getUInt32):
642         (JSC::JSValue::toPrimitive):
643         (JSC::JSValue::getPrimitiveNumber):
644         (JSC::JSValue::toNumber):
645         (JSC::JSValue::toObject):
646         (JSC::JSValue::isFunction):
647         (JSC::JSValue::inherits):
648         (JSC::JSValue::toThisObject):
649         (JSC::JSValue::get):
650         (JSC::JSValue::put):
651         (JSC::JSValue::putByIndex):
652         (JSC::JSValue::structureOrUndefined):
653         (JSC::JSValue::equal):
654         (JSC::JSValue::equalSlowCaseInline):
655         (JSC::JSValue::strictEqualSlowCaseInline):
656         (JSC::JSValue::strictEqual):
657         * runtime/JSVariableObject.cpp:
658         * runtime/JSWithScope.cpp:
659         * runtime/JSWrapperObject.cpp:
660         * runtime/LiteralParser.cpp:
661         * runtime/Lookup.cpp:
662         * runtime/NameConstructor.cpp:
663         * runtime/NameInstance.cpp:
664         * runtime/NamePrototype.cpp:
665         * runtime/NativeErrorConstructor.cpp:
666         * runtime/NativeErrorPrototype.cpp:
667         * runtime/NumberConstructor.cpp:
668         * runtime/NumberObject.cpp:
669         * runtime/ObjectConstructor.cpp:
670         * runtime/ObjectPrototype.cpp:
671         * runtime/Operations.h:
672         (JSC):
673         * runtime/PropertySlot.cpp:
674         * runtime/RegExp.cpp:
675         * runtime/RegExpCache.cpp:
676         * runtime/RegExpCachedResult.cpp:
677         * runtime/RegExpConstructor.cpp:
678         * runtime/RegExpMatchesArray.cpp:
679         * runtime/RegExpObject.cpp:
680         * runtime/RegExpPrototype.cpp:
681         * runtime/SmallStrings.cpp:
682         * runtime/SparseArrayValueMap.cpp:
683         * runtime/StrictEvalActivation.cpp:
684         * runtime/StringConstructor.cpp:
685         * runtime/StringObject.cpp:
686         * runtime/StringRecursionChecker.cpp:
687         * runtime/Structure.h:
688         (JSC):
689         * runtime/StructureChain.cpp:
690         * runtime/TimeoutChecker.cpp:
691         * testRegExp.cpp:
692
693 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
694
695         If you use Phantom to force something to be live across an OSR exit, you should put it after the OSR exit
696         https://bugs.webkit.org/show_bug.cgi?id=106724
697
698         Reviewed by Oliver Hunt.
699         
700         In cases where we were getting it wrong, I think it was benign because we would either already have an
701         OSR exit prior to there, or the operand would be a constant.  But still, it's good to get this right.
702
703         * dfg/DFGByteCodeParser.cpp:
704         (JSC::DFG::ByteCodeParser::parseBlock):
705
706 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
707
708         Phantom(GetLocal) should be treated as relevant to OSR
709         https://bugs.webkit.org/show_bug.cgi?id=106715
710
711         Reviewed by Mark Hahnenberg.
712
713         * dfg/DFGCSEPhase.cpp:
714         (JSC::DFG::CSEPhase::performBlockCSE):
715
716 2013-01-11  Pratik Solanki  <psolanki@apple.com>
717
718         Fix function name typo ProgramExecutable::initalizeGlobalProperties()
719         https://bugs.webkit.org/show_bug.cgi?id=106701
720
721         Reviewed by Geoffrey Garen.
722
723         * interpreter/Interpreter.cpp:
724         (JSC::Interpreter::execute):
725         * runtime/Executable.cpp:
726         (JSC::ProgramExecutable::initializeGlobalProperties):
727         * runtime/Executable.h:
728
729 2013-01-11  Mark Hahnenberg  <mhahnenberg@apple.com>
730
731         testapi is failing with a block-related error in the Objc API
732         https://bugs.webkit.org/show_bug.cgi?id=106055
733
734         Reviewed by Filip Pizlo.
735
736         Same bug as in testapi.mm. We need to actually call the static block, rather than casting the block to a bool.
737
738         * API/ObjCCallbackFunction.mm:
739         (blockSignatureContainsClass):
740
741 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
742
743         Add a run-time option to print bytecode at DFG compile time
744         https://bugs.webkit.org/show_bug.cgi?id=106704
745
746         Reviewed by Mark Hahnenberg.
747
748         * dfg/DFGByteCodeParser.cpp:
749         (JSC::DFG::ByteCodeParser::parseCodeBlock):
750         * runtime/Options.h:
751         (JSC):
752
753 2013-01-11  Filip Pizlo  <fpizlo@apple.com>
754
755         It should be possible to enable verbose printing of each OSR exit at run-time (rather than compile-time) and it should print register state
756         https://bugs.webkit.org/show_bug.cgi?id=106700
757
758         Reviewed by Mark Hahnenberg.
759
760         * dfg/DFGAssemblyHelpers.h:
761         (DFG):
762         (JSC::DFG::AssemblyHelpers::debugCall):
763         * dfg/DFGCommon.h:
764         * dfg/DFGOSRExit.h:
765         (DFG):
766         * dfg/DFGOSRExitCompiler32_64.cpp:
767         (JSC::DFG::OSRExitCompiler::compileExit):
768         * dfg/DFGOSRExitCompiler64.cpp:
769         (JSC::DFG::OSRExitCompiler::compileExit):
770         * dfg/DFGOperations.cpp:
771         * dfg/DFGOperations.h:
772         * runtime/Options.h:
773         (JSC):
774
775 2013-01-11  Geoffrey Garen  <ggaren@apple.com>
776
777         Removed getDirectLocation and offsetForLocation and all their uses
778         https://bugs.webkit.org/show_bug.cgi?id=106692
779
780         Reviewed by Filip Pizlo.
781
782         getDirectLocation() and its associated offsetForLocation() relied on
783         detailed knowledge of the rules of PropertyOffset, JSObject, and
784         Structure, which is a hard thing to reverse-engineer reliably. Luckily,
785         it wasn't needed, and all clients either wanted a true value or a
786         PropertyOffset. So, I refactored accordingly.
787
788         * dfg/DFGOperations.cpp: Renamed putDirectOffset to putDirect, to clarify
789         that we are not putting an offset.
790
791         * runtime/JSActivation.cpp:
792         (JSC::JSActivation::getOwnPropertySlot): Get a value instead of a value
793         pointer, since we never wanted a pointer to begin with.
794
795         * runtime/JSFunction.cpp:
796         (JSC::JSFunction::getOwnPropertySlot): Use a PropertyOffset instead of a pointer,
797         so we don't have to reverse-engineer the offset from the pointer.
798
799         * runtime/JSObject.cpp:
800         (JSC::JSObject::put):
801         (JSC::JSObject::resetInheritorID):
802         (JSC::JSObject::inheritorID):
803         (JSC::JSObject::removeDirect):
804         (JSC::JSObject::fillGetterPropertySlot):
805         (JSC::JSObject::getOwnPropertyDescriptor): Renamed getDirectOffset and
806         putDirectOffset, as explaind above. We want to use the name "getDirectOffset"
807         for when the thing you're getting is the offset.
808
809         * runtime/JSObject.h:
810         (JSC::JSObject::getDirect):
811         (JSC::JSObject::getDirectOffset): Changed getDirectLocation to getDirectOffset,
812         since clients really wants PropertyOffsets and not locations.
813
814         (JSObject::offsetForLocation): Removed this function because it was hard
815         to get right.
816
817         (JSC::JSObject::putDirect):
818         (JSC::JSObject::putDirectUndefined):
819         (JSC::JSObject::inlineGetOwnPropertySlot):
820         (JSC::JSObject::putDirectInternal):
821         (JSC::JSObject::putDirectWithoutTransition):
822         * runtime/JSScope.cpp:
823         (JSC::executeResolveOperations):
824         (JSC::JSScope::resolvePut):
825         * runtime/JSValue.cpp:
826         (JSC::JSValue::putToPrimitive): Updated for renames.
827
828         * runtime/Lookup.cpp:
829         (JSC::setUpStaticFunctionSlot): Use a PropertyOffset instead of a pointer,
830         so we don't have to reverse-engineer the offset from the pointer.
831
832         * runtime/Structure.cpp:
833         (JSC::Structure::flattenDictionaryStructure): Updated for renames.
834
835 2013-01-11  Geoffrey Garen  <ggaren@apple.com>
836
837         Removed an unused version of getDirectLocation
838         https://bugs.webkit.org/show_bug.cgi?id=106691
839
840         Reviewed by Gavin Barraclough.
841
842         getDirectLocation is a weird operation. Removing the unused version is
843         the easy part.
844
845         * runtime/JSObject.h:
846         (JSObject):
847
848 2013-01-11  Mark Hahnenberg  <mhahnenberg@apple.com>
849
850         Objective-C objects that are passed to JavaScript leak (until the JSContext is destroyed)
851         https://bugs.webkit.org/show_bug.cgi?id=106056
852
853         Reviewed by Darin Adler.
854
855         * API/APIJSValue.h:
856         * API/JSValue.mm: Make the reference to the JSContext strong.
857         (-[JSValue context]):
858         (-[JSValue initWithValue:inContext:]):
859         (-[JSValue dealloc]):
860         * API/JSWrapperMap.mm: Make the reference back from wrappers to Obj-C objects weak instead of strong.
861         Also add an explicit WeakGCMap in the JSWrapperMap rather than using Obj-C associated object API which 
862         was causing memory leaks.
863         (wrapperClass):
864         (-[JSObjCClassInfo wrapperForObject:]):
865         (-[JSWrapperMap initWithContext:]):
866         (-[JSWrapperMap dealloc]):
867         (-[JSWrapperMap wrapperForObject:]):
868
869 2013-01-11  Geoffrey Garen  <ggaren@apple.com>
870
871         Fixed some bogus PropertyOffset ASSERTs
872         https://bugs.webkit.org/show_bug.cgi?id=106686
873
874         Reviewed by Gavin Barraclough.
875
876         The ASSERTs were passing a JSType instead of an inlineCapacity, due to
877         an incomplete refactoring.
878
879         The compiler didn't catch this because both types are int underneath.
880
881         * runtime/JSObject.h:
882         (JSC::JSObject::getDirect):
883         (JSC::JSObject::getDirectLocation):
884         (JSC::JSObject::offsetForLocation):
885         * runtime/Structure.cpp:
886         (JSC::Structure::addPropertyTransitionToExistingStructure): Validate against
887         our inline capacity, as we intended.
888
889 2013-01-11  Geoffrey Garen  <ggaren@apple.com>
890
891         Rename propertyOffsetFor => offsetForPropertyNumber
892         https://bugs.webkit.org/show_bug.cgi?id=106685
893
894         Reviewed by Gavin Barraclough.
895
896         Since the argument is just a typedef and not an object, I wanted to clarify the meaning.
897
898         * runtime/PropertyMapHashTable.h:
899         (JSC::PropertyTable::nextOffset): Updated for rename.
900
901         * runtime/PropertyOffset.h:
902         (JSC::offsetForPropertyNumber): Renamed. Also changed some PropertyOffset variables
903         to plain ints, because they're not actually on the PropertyOffsets number line.
904
905         * runtime/Structure.cpp:
906         (JSC::Structure::flattenDictionaryStructure):
907         * runtime/Structure.h:
908         (JSC::Structure::lastValidOffset): Updated for rename.
909
910 2013-01-10  Zan Dobersek  <zandobersek@gmail.com>
911
912         Remove the ENABLE_ANIMATION_API feature define occurences
913         https://bugs.webkit.org/show_bug.cgi?id=106544
914
915         Reviewed by Simon Fraser.
916
917         The Animation API code was removed in r137243. The ENABLE_ANIMATION_API
918         feature define handling still lingers in various build systems and configurations
919         but is of no use, so it should be removed.
920
921         * Configurations/FeatureDefines.xcconfig:
922
923 2013-01-09  Roger Fong  <roger_fong@apple.com>
924
925         Unreviewed. Just move the JavaScriptCore exports file around in the vcproj to make things clearer.
926
927         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
928
929 2013-01-09  Filip Pizlo  <fpizlo@apple.com>
930
931         Dont use a node reference after appending to the graph.
932         https://bugs.webkit.org/show_bug.cgi?id=103305
933         <rdar://problem/12753096>
934
935         Reviewed by Mark Hahnenberg.
936
937         * dfg/DFGArgumentsSimplificationPhase.cpp:
938         (JSC::DFG::ArgumentsSimplificationPhase::run):
939
940 2013-01-09  Roger Fong  <roger_fong@apple.com>
941
942         Rename export files to make them more easily findable.
943         https://bugs.webkit.org/show_bug.cgi?id=98695.
944
945         Reviewed by Timothy Horton.
946
947         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Removed.
948         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
949         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
950         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Copied from Source/JavaScriptCore/JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def.
951
952 2013-01-09  Carlos Garcia Campos  <cgarcia@igalia.com>
953
954         Unreviewed. Fix make distcheck.
955
956         * GNUmakefile.list.am: Add mips.rb to offlineasm_nosources.
957
958 2013-01-08  Oliver Hunt  <oliver@apple.com>
959
960         Support op_typeof in the DFG
961         https://bugs.webkit.org/show_bug.cgi?id=98898
962
963         Reviewed by Filip Pizlo.
964
965         Adds a TypeOf node to the DFG to support op_typeof.
966
967         To avoid adding too much GC horror, this also makes the
968         common strings portion of the SmallString cache strongly
969         referenced.
970
971         * dfg/DFGAbstractState.cpp:
972         (JSC::DFG::AbstractState::execute):
973           We try to determine the result early here, and substitute in a constant.
974           Otherwise we leave the node intact, and set the result type to SpecString.
975         * dfg/DFGByteCodeParser.cpp:
976         (JSC::DFG::ByteCodeParser::parseBlock):
977           Parse op_typeof
978         * dfg/DFGCSEPhase.cpp:
979         (JSC::DFG::CSEPhase::performNodeCSE):
980           TypeOf nodes can be subjected to pure CSE
981         * dfg/DFGCapabilities.h:
982         (JSC::DFG::canCompileOpcode):
983           We can handle typeof.
984         * dfg/DFGNodeType.h:
985         (DFG):
986           Define the node.
987         * dfg/DFGOperations.cpp:
988         * dfg/DFGOperations.h:
989           Add operationTypeOf to support the non-trivial cases.
990         * dfg/DFGPredictionPropagationPhase.cpp:
991         (JSC::DFG::PredictionPropagationPhase::propagate):
992         * dfg/DFGSpeculativeJIT32_64.cpp:
993         (JSC::DFG::SpeculativeJIT::compile):
994         * dfg/DFGSpeculativeJIT64.cpp:
995         (JSC::DFG::SpeculativeJIT::compile):
996           Actual codegen
997         * runtime/Operations.cpp:
998         (JSC::jsTypeStringForValue):
999         (JSC):
1000         * runtime/Operations.h:
1001         (JSC):
1002           Some refactoring to allow us to get the type string for an
1003           object without needing a callframe.
1004
1005
1006 2013-01-08  Filip Pizlo  <fpizlo@apple.com>
1007
1008         DFG shouldn't treat the 'this' argument as being captured if a code block uses arguments
1009         https://bugs.webkit.org/show_bug.cgi?id=106398
1010         <rdar://problem/12439776>
1011
1012         Reviewed by Mark Hahnenberg.
1013         
1014         This is a possible optimization for inlined calls, and fixes crashes for inlined constructors, in the case
1015         that the inlined code used arguments. The problem was that assuming that 'this' was captured implies the
1016         assumption that it was initialized by the caller, which is wrong for constructors and this.
1017         
1018         Also added a pretty essential DFG IR validation rule: we shouldn't have any live locals at the top of the
1019         root block. This helps to catch this bug: our assumption that 'this' was captured in an inlined constructor
1020         that used arguments led to liveness for the temporary that would have held 'this' in the caller being
1021         propagated all the way up to the entrypoint of the function.
1022
1023         * bytecode/CodeBlock.h:
1024         (JSC::CodeBlock::isCaptured):
1025         * dfg/DFGValidate.cpp:
1026         (JSC::DFG::Validate::validate):
1027         (JSC::DFG::Validate::reportValidationContext):
1028         (Validate):
1029         (JSC::DFG::Validate::dumpGraphIfAppropriate):
1030
1031 2013-01-08  Filip Pizlo  <fpizlo@apple.com>
1032
1033         REGRESSION (r138921): Crash in JSC::Arguments::create
1034         https://bugs.webkit.org/show_bug.cgi?id=106329
1035         <rdar://problem/12974196>
1036
1037         Reviewed by Mark Hahnenberg.
1038         
1039         Arguments::finishCreation() that takes an InlineCallFrame* needs to understand that the callee can
1040         be unset, indicating that the callee needs to be loaded from the true call frame. This adds a
1041         method to InlineCallFrame to do just that.
1042
1043         * bytecode/CodeOrigin.cpp:
1044         (JSC::InlineCallFrame::calleeForCallFrame):
1045         * bytecode/CodeOrigin.h:
1046         (InlineCallFrame):
1047         * runtime/Arguments.h:
1048         (JSC::Arguments::finishCreation):
1049
1050 2013-01-08  Filip Pizlo  <fpizlo@apple.com>
1051
1052         DFG initrinsic handling should ensure that we backwards propagate the fact that all operands may escape
1053         https://bugs.webkit.org/show_bug.cgi?id=106365
1054
1055         Reviewed by Mark Hahnenberg.
1056         
1057         Use the fact that Phantom means that things escaped, and just insert Phantoms for all
1058         of the operands.
1059
1060         * dfg/DFGByteCodeParser.cpp:
1061         (JSC::DFG::ByteCodeParser::handleCall):
1062
1063 2013-01-08  Filip Pizlo  <fpizlo@apple.com>
1064
1065         If array allocation profiling causes a new_array to allocate double arrays, then the holes should end up being correctly initialized
1066         https://bugs.webkit.org/show_bug.cgi?id=106363
1067
1068         Reviewed by Mark Hahnenberg.
1069
1070         * runtime/JSArray.h:
1071         (JSC::JSArray::tryCreateUninitialized):
1072
1073 2013-01-07  Filip Pizlo  <fpizlo@apple.com>
1074
1075         DFG should backwards-propagate NodeUsedAsValue for Phantom
1076         https://bugs.webkit.org/show_bug.cgi?id=106299
1077
1078         Reviewed by Mark Hahnenberg.
1079         
1080         This is currently benign because Phantom is only inserted by the bytecode parser for
1081         things that already happen to be used in contexts that backwards propagate
1082         NodeUsedAsValue. But that doesn't change the fact that the semantics of Phantom are
1083         that the value can be arbitrarily used by the baseline JIT.
1084
1085         * dfg/DFGPredictionPropagationPhase.cpp:
1086         (JSC::DFG::PredictionPropagationPhase::propagate):
1087
1088 2013-01-07  Filip Pizlo  <fpizlo@apple.com>
1089
1090         Rationalize closure call heuristics and profiling
1091         https://bugs.webkit.org/show_bug.cgi?id=106270
1092
1093         Reviewed by Oliver Hunt.
1094         
1095         Did a number of things:
1096         
1097         - CallLinkInfo now remembers if it was ever a closure call, and CallLinkStatus uses
1098           this. Reduces the likelihood that we will inline a closure call as if it was a
1099           normal call.
1100         
1101         - Made InlineCallFrame print inferred function names, and refactored
1102           CodeBlock::inferredName() to better use FunctionExecutable's API.
1103         
1104         - Made bytecode dumping print frequent exit sites that led to recompilation.
1105         
1106         - Made bytecode dumping for op_call and op_construct print what the CallLinkStatus
1107           saw.
1108         
1109         * bytecode/CallLinkInfo.h:
1110         (JSC::CallLinkInfo::CallLinkInfo):
1111         (CallLinkInfo):
1112         * bytecode/CallLinkStatus.cpp:
1113         (JSC::CallLinkStatus::computeFor):
1114         * bytecode/CodeBlock.cpp:
1115         (JSC::CodeBlock::inferredName):
1116         (JSC::CodeBlock::dumpBytecodeCommentAndNewLine):
1117         (JSC::CodeBlock::printCallOp):
1118         * bytecode/CodeOrigin.cpp:
1119         (JSC::CodeOrigin::dump):
1120         (JSC::InlineCallFrame::inferredName):
1121         (JSC):
1122         (JSC::InlineCallFrame::dumpBriefFunctionInformation):
1123         (JSC::InlineCallFrame::dump):
1124         * bytecode/CodeOrigin.h:
1125         (InlineCallFrame):
1126         * bytecode/DFGExitProfile.cpp:
1127         (JSC::DFG::ExitProfile::exitSitesFor):
1128         (DFG):
1129         * bytecode/DFGExitProfile.h:
1130         (ExitProfile):
1131         * jit/JITStubs.cpp:
1132         (JSC::DEFINE_STUB_FUNCTION):
1133
1134 2013-01-07  Ryosuke Niwa  <rniwa@webkit.org>
1135
1136         Sorted the xcodeproj file.
1137
1138         * JavaScriptCore.xcodeproj/project.pbxproj:
1139
1140 2013-01-07  Filip Pizlo  <fpizlo@apple.com>
1141
1142         Unreviewed, it should be possible to build JSC on ARM.
1143
1144         * API/JSBase.h:
1145         * jit/JITStubs.cpp:
1146         (JSC::performPlatformSpecificJITAssertions):
1147         (JSC):
1148         * jit/JITStubs.h:
1149         (JSC):
1150         * jit/JITThunks.cpp:
1151         (JSC::JITThunks::JITThunks):
1152         * jit/JITThunks.h:
1153         (JITThunks):
1154         * offlineasm/armv7.rb:
1155         * runtime/JSGlobalData.cpp:
1156         (JSC::JSGlobalData::JSGlobalData):
1157
1158 2013-01-07  Balazs Kilvady  <kilvadyb@homejinni.com>
1159
1160         MIPS LLInt implementation.
1161         https://bugs.webkit.org/show_bug.cgi?id=99706
1162
1163         Reviewed by Filip Pizlo.
1164
1165         LLInt implementation for MIPS.
1166
1167         * assembler/MacroAssemblerMIPS.h:
1168         (JSC::MacroAssemblerMIPS::jump):
1169         * dfg/DFGOperations.cpp:
1170         (JSC):
1171         * jit/JITStubs.cpp:
1172         (JSC):
1173         * jit/JITStubs.h:
1174         (JITStackFrame):
1175         * llint/LLIntOfflineAsmConfig.h:
1176         * llint/LowLevelInterpreter.asm:
1177         * llint/LowLevelInterpreter32_64.asm:
1178         * offlineasm/backends.rb:
1179         * offlineasm/instructions.rb:
1180         * offlineasm/mips.rb: Added.
1181
1182 2013-01-07  Mark Hahnenberg  <mhahnenberg@apple.com>
1183
1184         testapi is failing with a block-related error in the Objc API
1185         https://bugs.webkit.org/show_bug.cgi?id=106055
1186
1187         Reviewed by Geoffrey Garen.
1188
1189         Casting a block to a bool will always return true, which isn't the behavior that is intended here.
1190         Instead we need to call the block, but C semantics don't allow this, so we need to change 
1191         testapi.m to be Objective-C++ and therefore testapi.mm.
1192
1193         * API/tests/testapi.m: Removed.
1194         * API/tests/testapi.mm: Copied from Source/JavaScriptCore/API/tests/testapi.m.
1195         (blockSignatureContainsClass):
1196         * JavaScriptCore.xcodeproj/project.pbxproj:
1197
1198 2013-01-06  Filip Pizlo  <fpizlo@apple.com>
1199
1200         Simplify slow case profiling
1201         https://bugs.webkit.org/show_bug.cgi?id=106208
1202
1203         Reviewed by Mark Rowe.
1204         
1205         Removing the minimum execution ratio portion of slow case profiling, which allows
1206         the removal of a field from CodeBlock. This appears to be performance neutral,
1207         implying that the complexity incurred by the previous heuristic was purely
1208         harmful: it made the code more complicated, and it made CodeBlock larger, without
1209         resulting in any measurable benefits.
1210
1211         * bytecode/CodeBlock.cpp:
1212         (JSC::CodeBlock::CodeBlock):
1213         * bytecode/CodeBlock.h:
1214         (JSC::CodeBlock::likelyToTakeSlowCase):
1215         (JSC::CodeBlock::couldTakeSlowCase):
1216         (JSC::CodeBlock::likelyToTakeSpecialFastCase):
1217         (JSC::CodeBlock::couldTakeSpecialFastCase):
1218         (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
1219         (JSC::CodeBlock::likelyToTakeAnySlowCase):
1220         * jit/JIT.cpp:
1221         (JSC::JIT::privateCompile):
1222         * runtime/Options.h:
1223
1224 2013-01-05  Filip Pizlo  <fpizlo@apple.com>
1225
1226         DFG should inline closure calls
1227         https://bugs.webkit.org/show_bug.cgi?id=106067
1228
1229         Reviewed by Gavin Barraclough.
1230         
1231         This adds initial support for inlining closure calls to the DFG. A call is considered
1232         to be a closure call when the JSFunction* varies, but always has the same executable.
1233         We already have closure call inline caching in both JITs, which works by checking that
1234         the callee has an expected structure (as a cheap way of detecting that it is in fact
1235         a JSFunction) and an expected executable. Closure call inlining uses profiling data
1236         aggregated by CallLinkStatus to decide when to specialize the call to the particular
1237         structure/executable, and inline the call rather than emitting a call sequence. When
1238         we choose to do a closure inline rather than an ordinary inline, a number of things
1239         change about how inlining is performed:
1240         
1241         - The inline is guarded by a CheckStructure/CheckExecutable rather than a
1242           CheckFunction.
1243         
1244         - Instead of propagating a constant value for the scope, we emit GetMyScope every time
1245           that the scope is needed, which loads the scope from a local variable. We do similar
1246           things for the callee.
1247         
1248         - The prologue of the inlined code includes SetMyScope and SetCallee nodes to eagerly
1249           plant the scope and callee into the "true call frame", i.e. the place on the stack
1250           where the call frame would have been if the call had been actually performed. This
1251           allows GetMyScope/GetCallee to work as they would if the code wasn't inlined. It
1252           also allows for trivial handling of scope and callee for call frame reconstruction
1253           upon stack introspection and during OSR.
1254         
1255         - A new node called GetScope is introduced, which just gets the scope of a function.
1256           This node has the expected CSE support. This allows for the
1257           SetMyScope(GetScope(@function)) sequence to set up the scope in the true call frame.
1258         
1259         - GetMyScope/GetCallee CSE can match against SetMyScope/SetCallee, which means that
1260           the GetMyScope/GetCallee nodes emitted during parsing are often removed during CSE,
1261           if we can prove that it is safe to do so.
1262         
1263         - Inlining heuristics are adjusted to grok the cost of inlining a closure. We are
1264           less likely to inline a closure call than we are to inline a normal call, since we
1265           end up emitting more code for closures due to CheckStructure, CheckExecutable,
1266           GetScope, SetMyScope, and SetCallee.
1267         
1268         Additionally, I've fixed the VariableEventStream to ensure that we don't attempt to
1269         plant Undefined into the true call frames. This was previously a harmless oversight,
1270         but it becomes quite bad if OSR is relying on the scope/callee already having been
1271         set and not subsequently clobbered by the OSR itself.
1272         
1273         This is a ~60% speed-up on programs that frequently make calls to closures. It's
1274         neutral on V8v7 and other major benchmark suites.
1275         
1276         The lack of a definite speed-up is likely due the fact that closure inlining currently
1277         does not do any cardinality [1] optimizations. We don't observe when a closure was
1278         constructed within its caller, and so used the scope from its caller; and furthermore
1279         we have no facility to detect when the scope is single. All scoped variable accesses
1280         are assumed to be multiple instead. A subsequent step will be to ensure that closure
1281         call inlining will be single and loving it.
1282         
1283         [1] Single and loving it: Must-alias analysis for higher-order languages. Suresh
1284             Jagannathan, Peter Thiemann, Stephen Weeks, and Andrew Wright. In POPL '98.
1285
1286         * bytecode/CallLinkStatus.cpp:
1287         (JSC::CallLinkStatus::dump):
1288         * bytecode/CallLinkStatus.h:
1289         (JSC::CallLinkStatus::isClosureCall):
1290         (CallLinkStatus):
1291         * bytecode/CodeBlock.cpp:
1292         (JSC::CodeBlock::globalObjectFor):
1293         (JSC):
1294         * bytecode/CodeBlock.h:
1295         (CodeBlock):
1296         * bytecode/CodeOrigin.cpp:
1297         (JSC::InlineCallFrame::dump):
1298         * dfg/DFGAbstractState.cpp:
1299         (JSC::DFG::AbstractState::execute):
1300         * dfg/DFGByteCodeParser.cpp:
1301         (ByteCodeParser):
1302         (JSC::DFG::ByteCodeParser::handleCall):
1303         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
1304         (JSC::DFG::ByteCodeParser::handleInlining):
1305         * dfg/DFGCSEPhase.cpp:
1306         (JSC::DFG::CSEPhase::pureCSE):
1307         (CSEPhase):
1308         (JSC::DFG::CSEPhase::getCalleeLoadElimination):
1309         (JSC::DFG::CSEPhase::checkExecutableElimination):
1310         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
1311         (JSC::DFG::CSEPhase::performNodeCSE):
1312         * dfg/DFGCapabilities.cpp:
1313         (JSC::DFG::mightInlineFunctionForClosureCall):
1314         * dfg/DFGCapabilities.h:
1315         (DFG):
1316         (JSC::DFG::mightInlineFunctionForClosureCall):
1317         (JSC::DFG::canInlineFunctionForClosureCall):
1318         (JSC::DFG::canInlineFunctionFor):
1319         * dfg/DFGNode.h:
1320         (Node):
1321         (JSC::DFG::Node::hasExecutable):
1322         (JSC::DFG::Node::executable):
1323         * dfg/DFGNodeType.h:
1324         (DFG):
1325         * dfg/DFGPredictionPropagationPhase.cpp:
1326         (JSC::DFG::PredictionPropagationPhase::propagate):
1327         * dfg/DFGSpeculativeJIT32_64.cpp:
1328         (JSC::DFG::SpeculativeJIT::compile):
1329         * dfg/DFGSpeculativeJIT64.cpp:
1330         (JSC::DFG::SpeculativeJIT::compile):
1331         * dfg/DFGVariableEventStream.cpp:
1332         (JSC::DFG::VariableEventStream::reconstruct):
1333         * runtime/Options.h:
1334         (JSC):
1335
1336 2013-01-05  Filip Pizlo  <fpizlo@apple.com>
1337
1338         Data flow paths that carry non-numbers, non-undefined, non-null values should not cause subtractions and arithmetic additions (i.e. ++) to speculate double
1339         https://bugs.webkit.org/show_bug.cgi?id=106190
1340
1341         Reviewed by Sam Weinig.
1342         
1343         The problem is that the DFG logic for deciding when to speculate integer was
1344         confusing the special case of ValueAdd (where non-numeric values should cause us
1345         to not speculate integer, because we want to fall off into the generic case) with
1346         the more normal case of ArithAdd and ArithSub (where we want to speculate integer
1347         unless we have evidence that the operands are doubles, since the DFG doesn't have
1348         generic handling of non-numeric arithmetic). Prior to this change doing a - b where
1349         either a or b were possibly non-numeric would always force the subtraction to be
1350         done using doubles.
1351
1352         * dfg/DFGGraph.h:
1353         (JSC::DFG::Graph::addSpeculationMode):
1354         (Graph):
1355         (JSC::DFG::Graph::valueAddSpeculationMode):
1356         (JSC::DFG::Graph::arithAddSpeculationMode):
1357         (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
1358
1359 2013-01-04  Filip Pizlo  <fpizlo@apple.com>
1360
1361         DFG should trust array profiling over value profiling
1362         https://bugs.webkit.org/show_bug.cgi?id=106155
1363
1364         Reviewed by Gavin Barraclough.
1365         
1366         The real problem is that prediction propagation is not flow-sensitive. We had code
1367         like:
1368         
1369         var a = (some load from memory); // returns either an array or false
1370         if (a)
1371             a[i] = v;
1372         
1373         Because 'a' could be 'false', we were emitting a fully generic unoptimized PutByVal.
1374         This patch changes ArrayMode to ignore the type of the base of an array access, if
1375         array profiling tells us that the array access can be optimized.
1376         
1377         In the future, we could probably make this work even better with some flow
1378         sensitivity in the prediction propagator, but I also tend to think that this is a
1379         more robust overall solution. If we ever did want to support array accesses on
1380         array-or-false then we should change the array profiler to be able to tell us that
1381         this is what is going on.
1382         
1383         3.7% speed-up on V8/earley.
1384
1385         * dfg/DFGArrayMode.cpp:
1386         (JSC::DFG::ArrayMode::refine):
1387
1388 2013-01-04  Filip Pizlo  <fpizlo@apple.com>
1389
1390         Rationalize exit site profiling for calls
1391         https://bugs.webkit.org/show_bug.cgi?id=106150
1392
1393         Reviewed by Sam Weinig.
1394         
1395         This adds two new exit kinds for calls: BadFunction and BadExecutable. The latter is not used
1396         yet, but is already integrated with profiling. CheckFunction uses a BadFunction speculation
1397         instead of BadCache, now. This allows CallLinkStatus to turn itself into a closure call status
1398         if we had a BadFunction exit site but the CallLinkInfo told us to use a non-closure call. This
1399         might happen if we had call unlinking that led to information loss along the way.
1400         
1401         No performance impact. This is meant as another step towards inlining closure calls.
1402
1403         * bytecode/CallLinkStatus.cpp:
1404         * bytecode/CallLinkStatus.h:
1405         (JSC::CallLinkStatus::setIsProved):
1406         (JSC::CallLinkStatus::setHasBadFunctionExitSite):
1407         (CallLinkStatus):
1408         (JSC::CallLinkStatus::setHasBadCacheExitSite):
1409         (JSC::CallLinkStatus::setHasBadExecutableExitSite):
1410         * bytecode/ExitKind.cpp:
1411         (JSC::exitKindToString):
1412         * bytecode/ExitKind.h:
1413         * dfg/DFGByteCodeParser.cpp:
1414         (JSC::DFG::ByteCodeParser::handleCall):
1415         * dfg/DFGSpeculativeJIT32_64.cpp:
1416         (JSC::DFG::SpeculativeJIT::compile):
1417         * dfg/DFGSpeculativeJIT64.cpp:
1418         (JSC::DFG::SpeculativeJIT::compile):
1419
1420 2013-01-03  Filip Pizlo  <fpizlo@apple.com>
1421
1422         DFG should not elide CheckStructure if it's needed to perform a cell check
1423         https://bugs.webkit.org/show_bug.cgi?id=106074
1424
1425         Reviewed by Ryosuke Niwa.
1426         
1427         The problem here was that the constant folding phase was misinterpreting the meaning of the sets
1428         in DFG::AbstractValue.  AbstractValue describes a constraint on the values that a variable (i.e.
1429         a DFG Node, or a virtual register, i.e. local or argument) may have. It does so by containing
1430         four sets: the set of JSValues (either empty, the singleton set containing one JSValue, or the
1431         set of all JSValues); the set of "current known" structures, i.e. the set of structures that you
1432         already know that this value may have right now (also either empty, the singleton set, or the set
1433         of all structures); the set of "future possible" structures, i.e. the set of structures that this
1434         value could have in the future if none of the structure transition watchpoints for those
1435         structures had fired (also empty, singleton, or all); and the set of types, which is a
1436         SpeculatedType bitmask. The correct way to interpret the sets is to think of the AbstractValue as
1437         the intersection of these three sets of values:
1438         
1439         - The set of JSValues that have a type that belongs to the m_type set.
1440         - If m_value is not the empty value then: the set of all JSValues that are == m_value;
1441                                             else: the set of all JSValues.
1442           where '==' is as defined by JSValue::operator==.
1443         - Union of { the set of all cells that have a structure that belongs to m_currentKnownStructure }
1444                and { the set of all JSValues that are not cells }.
1445         
1446         You can then further intersect this set with the following set, if you guard the code with
1447         watchpoints on all structures in the m_futurePossibleStructure:
1448         
1449         - Union of { the set of all cells that have a structure that belongs to m_futurePossibleStructure }
1450                and { the set of all JSValues that are not cells }.
1451         
1452         One way to think of this is that m_currentKnownStructure is filtered by m_futurePossibleStructure
1453         (i.e. is set to the intersection of m_currentKnownStructure and m_futurePossibleStructure), if the
1454         code for which you're doing this is always preceded by watchpoints on all structures in
1455         m_futurePossibleStructure, and is always before any side-effects that could change the structures
1456         of objects.
1457         
1458         The incorrect optimization related to CheckStructure. CheckStructure checks that the value is a
1459         cell, and that it has a particular structure. It was incorrectly assuming that you could eliminate
1460         the CheckStructure, if m_currentKnownStructure contained the structure that CheckStructure was
1461         checking. But this is not the case, since m_currentKnownStructure does not prove that the value is
1462         a cell with a particular structure; it only proves that if the value was a cell then it would have
1463         a particular structure. Hence, to eliminate CheckStructure, it is also necessary to check that
1464         AbstractValue::m_type contains only cells (i.e. isCellSpeculation(m_type) == true).
1465         
1466         It wasn't doing that, and this changes makes sure that it does do that.
1467
1468         * dfg/DFGConstantFoldingPhase.cpp:
1469         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1470
1471 2013-01-04  Adam Klein  <adamk@chromium.org>
1472
1473         Remove ENABLE_MUTATION_OBSERVERS #define
1474         https://bugs.webkit.org/show_bug.cgi?id=105459
1475
1476         Reviewed by Ryosuke Niwa.
1477
1478         * Configurations/FeatureDefines.xcconfig:
1479
1480 2013-01-03  Filip Pizlo  <fpizlo@apple.com>
1481
1482         DFG::ByteCodeCache serves little or no purpose ever since we decided to keep bytecode around permanently
1483         https://bugs.webkit.org/show_bug.cgi?id=106058
1484
1485         Reviewed by Michael Saboff.
1486         
1487         All baseline code blocks now always have bytecode, so the bytecode cache's ability to minimize the
1488         number of times that the DFG produces bytecode sequences for code blocks is superfluous.
1489
1490         * GNUmakefile.list.am:
1491         * JavaScriptCore.xcodeproj/project.pbxproj:
1492         * dfg/DFGByteCodeCache.h: Removed.
1493         * dfg/DFGByteCodeParser.cpp:
1494         (ByteCodeParser):
1495         (JSC::DFG::ByteCodeParser::handleInlining):
1496         * runtime/Executable.cpp:
1497         (JSC):
1498         * runtime/Executable.h:
1499         (FunctionExecutable):
1500
1501 2013-01-03  Filip Pizlo  <fpizlo@apple.com>
1502
1503         Unreviewed, fix build for DFG JIT disabled.
1504
1505         * bytecode/CodeBlock.cpp:
1506         (JSC::CodeBlock::dumpValueProfiling):
1507         (JSC::CodeBlock::dumpArrayProfiling):
1508         * runtime/Executable.cpp:
1509         (JSC):
1510         (JSC::ExecutableBase::intrinsic):
1511
1512 2013-01-03  Filip Pizlo  <fpizlo@apple.com>
1513
1514         CallLinkStatus should be aware of closure calls, and the DFG bytecode parser should use that as its sole internal notion of how to optimize calls
1515         https://bugs.webkit.org/show_bug.cgi?id=106027
1516
1517         Reviewed by Mark Hahnenberg.
1518         
1519         Previously, the DFG bytecode parser had its own internal notion of exactly what CallLinkStatus was
1520         meant to do, in the form of a CallType, expectedFunction, intrinsic, etc. This change makes CallLinkStatus
1521         smart enough to do all of that, and also gives it the ability to understand closure calls.
1522
1523         * bytecode/CallLinkStatus.cpp:
1524         (JSC::CallLinkStatus::CallLinkStatus):
1525         (JSC):
1526         (JSC::CallLinkStatus::function):
1527         (JSC::CallLinkStatus::internalFunction):
1528         (JSC::CallLinkStatus::intrinsicFor):
1529         (JSC::CallLinkStatus::setIsProved):
1530         (JSC::CallLinkStatus::computeFromLLInt):
1531         (JSC::CallLinkStatus::computeFor):
1532         (JSC::CallLinkStatus::dump):
1533         * bytecode/CallLinkStatus.h:
1534         (JSC):
1535         (JSC::CallLinkStatus::CallLinkStatus):
1536         (CallLinkStatus):
1537         (JSC::CallLinkStatus::takesSlowPath):
1538         (JSC::CallLinkStatus::isSet):
1539         (JSC::CallLinkStatus::isClosureCall):
1540         (JSC::CallLinkStatus::callTarget):
1541         (JSC::CallLinkStatus::executable):
1542         (JSC::CallLinkStatus::structure):
1543         (JSC::CallLinkStatus::isProved):
1544         (JSC::CallLinkStatus::canOptimize):
1545         * dfg/DFGByteCodeParser.cpp:
1546         (JSC::DFG::ByteCodeParser::handleCall):
1547         * dfg/DFGGraph.h:
1548         (JSC::DFG::Graph::valueOfFunctionConstant):
1549
1550 2013-01-02  Simon Hausmann  <simon.hausmann@digia.com>
1551
1552         [MinGW-w64] Centralize workaround for pow() implementation
1553         https://bugs.webkit.org/show_bug.cgi?id=105925
1554
1555         Reviewed by Sam Weinig.
1556
1557         As suggested by Sam, move the MinGW-w64 workaround into MathExtras.h
1558         away from the JSC usage.
1559
1560         * runtime/MathObject.cpp:
1561         (JSC::mathPow):
1562
1563 2013-01-02  Gavin Barraclough  <barraclough@apple.com>
1564
1565         Objective-C API for JavaScriptCore
1566         https://bugs.webkit.org/show_bug.cgi?id=105889
1567
1568         Reviewed by Geoff Garen.
1569
1570         Fixes for more issues raised by Darin.
1571
1572         * API/JSBlockAdaptor.mm:
1573         (BlockArgument):
1574         (BlockArgumentStruct::BlockArgumentStruct):
1575         (BlockArgumentTypeDelegate::typeStruct):
1576         (BlockResult):
1577         (BlockResultStruct::BlockResultStruct):
1578         (buildBlockSignature):
1579         (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]):
1580         (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
1581             - fix * position for Objective-C types
1582         * API/JSContext.h:
1583             - fix * position for Objective-C types
1584         * API/JSContext.mm:
1585         (-[JSContext initWithVirtualMachine:]):
1586         (-[JSContext virtualMachine]):
1587         (contextInternalContext):
1588             - fix * position for Objective-C types
1589         (-[JSContext dealloc]):
1590         (-[JSContext protect:]):
1591         (-[JSContext unprotect:]):
1592             - HashMap<JSValueRef, size_t> -> HashCountedSet<JSValueRef>
1593         * API/JSContextInternal.h:
1594         (WeakContextRef):
1595             - fix * position for Objective-C types
1596         * API/JSValue.mm:
1597         (valueToString):
1598             - fix * position for Objective-C types
1599         (isNSBoolean):
1600             - Added helper to check for booleans.
1601         (objectToValueWithoutCopy):
1602             - Added contextRef
1603             - fix * position for Objective-C types
1604             - Remove @YES, @NO literal usage, use isNSBoolean instead
1605         (objectToValue):
1606             - Added contextRef
1607         (+[JSValue valueWithValue:inContext:]):
1608         (-[JSValue initWithValue:inContext:]):
1609             - fix * position for Objective-C types
1610         (createStructHandlerMap):
1611         (handerForStructTag):
1612             - getStructTagHandler -> handerForStructTag
1613             - Split out createStructHandlerMap
1614             - strncmp -> memcmp
1615             - String(type).impl() -> StringImpl::create(type)
1616         (+[JSValue selectorForStructToValue:]):
1617         (+[JSValue selectorForValueToStruct:]):
1618             - getStructTagHandler -> handerForStructTag
1619         (typeToValueInvocationFor):
1620         (valueToTypeInvocationFor):
1621             - fix * position for Objective-C types
1622         * API/JSValueInternal.h:
1623             - fix * position for Objective-C types
1624         * API/JSVirtualMachineInternal.h:
1625             - fix * position for Objective-C types
1626         * API/JSWrapperMap.h:
1627             - fix * position for Objective-C types
1628         * API/JSWrapperMap.mm:
1629         (selectorToPropertyName):
1630         (createObjectWithCustomBrand):
1631         (createRenameMap):
1632         (putNonEnumerable):
1633         (copyMethodsToObject):
1634         (copyPrototypeProperties):
1635         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
1636         (-[JSWrapperMap initWithContext:]):
1637         (-[JSWrapperMap wrapperForObject:]):
1638         (getJSExportProtocol):
1639             - fix * position for Objective-C types
1640         * API/ObjCCallbackFunction.h:
1641             - fix * position for Objective-C types
1642         * API/ObjCCallbackFunction.mm:
1643         (CallbackArgument):
1644         (CallbackArgumentStruct::CallbackArgumentStruct):
1645             - fix * position for Objective-C types
1646         (CallbackArgumentBlockCallback::createAdoptingJSBlockAdaptor):
1647             - Added to make adopt explicit
1648         (CallbackArgumentBlockCallback):
1649         (CallbackArgumentBlockCallback::CallbackArgumentBlockCallback):
1650         (ArgumentTypeDelegate::typeBlock):
1651             - Call createAdoptingJSBlockAdaptor
1652         (ArgumentTypeDelegate::typeStruct):
1653         (CallbackResult):
1654         (CallbackResultStruct::CallbackResultStruct):
1655         (ResultTypeDelegate::typeStruct):
1656         (ObjCCallbackFunction::ObjCCallbackFunction):
1657         (ObjCCallbackFunction::context):
1658         (objCCallbackFunctionForInvocation):
1659         (objCCallbackFunctionForMethod):
1660         (objCCallbackFunctionForBlock):
1661             - fix * position for Objective-C types
1662         * API/ObjcRuntimeExtras.h:
1663         (protocolImplementsProtocol):
1664         (forEachProtocolImplementingProtocol):
1665         (forEachMethodInProtocol):
1666         (forEachPropertyInProtocol):
1667             - fix * position for Objective-C types
1668         * API/tests/testapi.m:
1669         (-[TestObject testArgumentTypesWithInt:double:boolean:string:number:array:dictionary:]):
1670         (testObjectiveCAPI):
1671             - fix * position for Objective-C types
1672
1673 2013-01-02  Geoffrey Garen  <ggaren@apple.com>
1674
1675         Some renaming in the CodeCache
1676         https://bugs.webkit.org/show_bug.cgi?id=105966
1677
1678         Reviewed by Gavin Barraclough.
1679
1680         CodeBlockKey => SourceCodeKey because the key is not a CodeBlock.
1681
1682         m_recentlyUsedFunctionCode => m_recentlyUsedFunctions to match other names.
1683
1684         GlobalFunctionKey => FunctionKey because the key is not unique to globalness.
1685
1686         m_cachedGlobalFunctions => m_globalFunctions because "cached" is redundant
1687         for data members in an object called "CodeCache".
1688
1689         kMaxRootCodeBlockEntries => kMaxRootEntries because there are no non-CodeBlock
1690         entries in a CodeBlock cache.
1691
1692         kMaxFunctionCodeBlocks => kMaxChildFunctionEntries to clarify that this
1693         number models a parent-child relationship.
1694
1695         Also removed the initial "k" from enum constants. That's an interesting
1696         style for calling out constants, but it's not the WebKit style.
1697
1698         Finally, a behavior change: Use MaxRootEntries for the limit on global
1699         functions, and not MaxChildFunctionEntries. Previously, there was an
1700         unused constant that seemed to have been intended for this purpose.
1701
1702         * runtime/CodeCache.cpp:
1703         (JSC::CodeCache::makeSourceCodeKey):
1704         (JSC::CodeCache::getCodeBlock):
1705         (JSC::CodeCache::generateFunctionCodeBlock):
1706         (JSC::CodeCache::makeFunctionKey):
1707         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1708         (JSC::CodeCache::usedFunctionCode):
1709         * runtime/CodeCache.h:
1710         (JSC::CodeCache::clear):
1711
1712 2013-01-02  Filip Pizlo  <fpizlo@apple.com>
1713
1714         DFG inlining machinery should be robust against the inline callee varying while the executable stays the same
1715         https://bugs.webkit.org/show_bug.cgi?id=105953
1716
1717         Reviewed by Mark Hahnenberg.
1718         
1719         This institutes the policy that if InlineCallFrame::callee is null, then the callee and scope have already
1720         been stored into the true call frame (i.e. the place where the call frame of the inlined call would have
1721         been) and so any attempt to access the callee or scope should do a load instead of assuming that the value
1722         is constant. This wires the changes through the bytecode parser, the stack scanning logic, and the compiler
1723         optimization phases and backends.
1724
1725         * bytecode/CodeOrigin.cpp:
1726         (JSC::InlineCallFrame::dump):
1727         * bytecode/CodeOrigin.h:
1728         (CodeOrigin):
1729         (InlineCallFrame):
1730         (JSC::InlineCallFrame::isClosureCall):
1731         (JSC::CodeOrigin::stackOffset):
1732         (JSC):
1733         * dfg/DFGAssemblyHelpers.h:
1734         * dfg/DFGByteCodeParser.cpp:
1735         (JSC::DFG::ByteCodeParser::get):
1736         (InlineStackEntry):
1737         (JSC::DFG::ByteCodeParser::getScope):
1738         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1739         * dfg/DFGCSEPhase.cpp:
1740         (CSEPhase):
1741         (JSC::DFG::CSEPhase::genericPureCSE):
1742         (JSC::DFG::CSEPhase::pureCSE):
1743         (JSC::DFG::CSEPhase::pureCSERequiringSameInlineCallFrame):
1744         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
1745         (JSC::DFG::CSEPhase::performNodeCSE):
1746         * dfg/DFGOSRExitCompiler32_64.cpp:
1747         (JSC::DFG::OSRExitCompiler::compileExit):
1748         * dfg/DFGOSRExitCompiler64.cpp:
1749         (JSC::DFG::OSRExitCompiler::compileExit):
1750         * dfg/DFGSpeculativeJIT32_64.cpp:
1751         (JSC::DFG::SpeculativeJIT::compile):
1752         * dfg/DFGSpeculativeJIT64.cpp:
1753         (JSC::DFG::SpeculativeJIT::compile):
1754         * interpreter/CallFrame.cpp:
1755         (JSC::CallFrame::trueCallFrame):
1756
1757 2013-01-02  Gavin Barraclough  <barraclough@apple.com>
1758
1759         Objective-C API for JavaScriptCore
1760         https://bugs.webkit.org/show_bug.cgi?id=105889
1761
1762         Reviewed by Geoff Garen.
1763
1764         Fixes for a number of issues raised by Darin.
1765
1766         * API/APIJSValue.h:
1767             - Fix typos in comment
1768             - Add newline before NS_CLASS_AVAILABLE(10_9, NA)
1769             - cls -> expectedClass
1770             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
1771         * API/JSBase.h:
1772             - JS_OBJC_API_ENABLED no longer implies __OBJC__
1773         * API/JSBlockAdaptor.mm:
1774         (BlockArgumentStruct::BlockArgumentStruct):
1775         (BlockArgumentStruct):
1776             - mark virtual functions as virtual, override, and private
1777             - refactor out buffer allocation for struct types
1778         (BlockArgumentTypeDelegate::typeVoid):
1779         (BlockArgumentTypeDelegate::typeBlock):
1780         (BlockArgumentTypeDelegate::typeStruct):
1781             - return nil -> return 0
1782         (BlockResultStruct::BlockResultStruct):
1783         (BlockResultStruct):
1784             - mark virtual functions as virtual, override, and private
1785             - refactor out buffer allocation for struct types
1786         (buildBlockSignature):
1787             - %lu is not an appropriate format specifier for NSInteger
1788         (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]):
1789             - nil check [super init]
1790         (-[JSBlockAdaptor blockMatchesSignature:]):
1791         (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
1792             - ctx -> contextRef
1793         * API/JSContext.h:
1794             - Fix typos in comment
1795             - Add newline before NS_CLASS_AVAILABLE(10_9, NA)
1796             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
1797         * API/JSContext.mm:
1798         (-[JSContext initWithVirtualMachine:]):
1799             - nil check [super init]
1800         (+[JSContext currentArguments]):
1801             - args -> argumentArray
1802         (-[JSContext setObject:forKeyedSubscript:]):
1803             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
1804         (-[JSContext dealloc]):
1805         (-[JSContext protect:]):
1806         (-[JSContext unprotect:]):
1807             - m_protected -> m_protectCounts
1808         * API/JSValue.mm:
1809         (-[JSValue toObjectOfClass:]):
1810             - cls -> expectedClass
1811         (-[JSValue toBool]):
1812         (-[JSValue deleteProperty:]):
1813         (-[JSValue hasProperty:]):
1814         (-[JSValue isUndefined]):
1815         (-[JSValue isNull]):
1816         (-[JSValue isBoolean]):
1817         (-[JSValue isNumber]):
1818         (-[JSValue isString]):
1819         (-[JSValue isObject]):
1820         (-[JSValue isEqualToObject:]):
1821         (-[JSValue isEqualWithTypeCoercionToObject:]):
1822         (-[JSValue isInstanceOf:]):
1823             - removed ? YES : NO
1824         (-[JSValue callWithArguments:]):
1825         (-[JSValue constructWithArguments:]):
1826         (-[JSValue invokeMethod:withArguments:]):
1827             - args -> argumentArray
1828         (+[JSValue valueWithPoint:inContext:]):
1829         (+[JSValue valueWithRange:inContext:]):
1830         (+[JSValue valueWithRect:inContext:]):
1831         (+[JSValue valueWithSize:inContext:]):
1832             - [NSNumber numberWithFloat:] -> @()
1833         (-[JSValue objectForKeyedSubscript:]):
1834         (-[JSValue setObject:forKeyedSubscript:]):
1835             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
1836         (JSContainerConvertor):
1837         (JSContainerConvertor::isWorkListEmpty):
1838         (JSContainerConvertor::convert):
1839         (ObjcContainerConvertor):
1840         (ObjcContainerConvertor::isWorkListEmpty):
1841             - remove WTF::
1842             - isWorkListEmpty is const
1843         (objectToValue):
1844             -  use fast enumeration
1845         (-[JSValue initWithValue:inContext:]):
1846             - nil check [super init]
1847         (getStructTagHandler):
1848             - m_structHandlers -> structHandlers
1849         * API/JSVirtualMachine.h:
1850             - Add newline before NS_CLASS_AVAILABLE(10_9, NA)
1851         * API/JSVirtualMachine.mm:
1852         (-[JSVirtualMachine init]):
1853             - nil check [super init]
1854         * API/JSWrapperMap.mm:
1855         (selectorToPropertyName):
1856         (copyPrototypeProperties):
1857             - remove WTF::
1858             - use static_cast
1859         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
1860         (-[JSWrapperMap initWithContext:]):
1861             - nil check [super init]
1862         (-[JSWrapperMap wrapperForObject:]):
1863         (tryUnwrapObjcObject):
1864             - enable ASSERT
1865         (getJSExportProtocol):
1866         (getNSBlockClass):
1867             - remove if check on initializing static
1868         * API/JavaScriptCore.h:
1869             - JS_OBJC_API_ENABLED no longer implies __OBJC__
1870         * API/ObjCCallbackFunction.mm:
1871         (CallbackArgumentOfClass):
1872         (CallbackArgumentOfClass::~CallbackArgumentOfClass):
1873         (CallbackArgumentStruct::CallbackArgumentStruct):
1874         (CallbackArgumentStruct):
1875         (CallbackArgumentBlockCallback):
1876             - mark virtual functions as virtual, override, and private
1877             - refactor out buffer allocation for struct types
1878         (ArgumentTypeDelegate::typeVoid):
1879         (ArgumentTypeDelegate::typeOfClass):
1880         (ArgumentTypeDelegate::typeStruct):
1881             - return nil -> return 0
1882         (CallbackResultStruct::CallbackResultStruct):
1883         (CallbackResultStruct):
1884             - mark virtual functions as virtual, override, and private
1885             - refactor out buffer allocation for struct types
1886         (ResultTypeDelegate::typeStruct):
1887             - return nil -> return 0
1888         (ObjCCallbackFunction):
1889             - remove WTF::
1890         (objCCallbackFunctionFinalize):
1891             - use static_cast
1892         (objCCallbackFunctionCallAsFunction):
1893             - Fix typos in comment
1894         (createObjCCallbackFunctionClass):
1895         (objCCallbackFunctionClass):
1896             - Split out createObjCCallbackFunctionClass from objCCallbackFunctionClass
1897         (ObjCCallbackFunction::call):
1898             - ctx -> contextRef
1899         (blockSignatureContainsClass):
1900             - Remove tri-state enum.
1901         (skipNumber):
1902             - isdigit -> isASCIIDigit 
1903         (objCCallbackFunctionForInvocation):
1904             - clean up & comment blockSignatureContainsClass() usage
1905         (tryUnwrapBlock):
1906             - use static_cast
1907         * API/ObjcRuntimeExtras.h:
1908         (forEachProtocolImplementingProtocol):
1909         (forEachMethodInClass):
1910         (forEachMethodInProtocol):
1911         (forEachPropertyInProtocol):
1912             - Remove WTF::
1913             - Remove if (count) checks
1914         (skipPair):
1915             - NSUInteger -> size_t
1916         (StringRange):
1917         (StringRange::operator const char*):
1918         (StringRange::get):
1919         (StructBuffer):
1920         (StructBuffer::StructBuffer):
1921         (StructBuffer::~StructBuffer):
1922         (StructBuffer::operator void*):
1923             - Added helper for creating an aligned buffer, used by struct conversion invocations.
1924         (parseObjCType):
1925             - *(position++) -> *position++
1926         * API/tests/testapi.c:
1927             - PLATFORM(MAC) -> JS_OBJC_API_ENABLED
1928         * API/tests/testapi.m:
1929         (blockSignatureContainsClass):
1930             - Remove tri-state enum.
1931         (testObjectiveCAPI):
1932             - Added more result type checks.
1933
1934 2013-01-02  Filip Pizlo  <fpizlo@apple.com>
1935
1936         DFG should not use the InlineCallFrame's callee when it could have used the executable istead
1937         https://bugs.webkit.org/show_bug.cgi?id=105947
1938
1939         Reviewed by Mark Hahnenberg.
1940         
1941         We shouldn't use the callee to get the executable when we have the executable already. Not only
1942         does this make the logic more clear, but it also allows for a world where the executable is known
1943         but the callee isn't.
1944
1945         * dfg/DFGAssemblyHelpers.h:
1946         (JSC::DFG::AssemblyHelpers::strictModeFor):
1947
1948 2013-01-02  Filip Pizlo  <fpizlo@apple.com>
1949
1950         DFG inliner should not use the callee's bytecode variable for resolving references to the callee in inlined code
1951         https://bugs.webkit.org/show_bug.cgi?id=105938
1952
1953         Reviewed by Mark Hahnenberg.
1954         
1955         This simplifies a bunch of code for referring to the callee. It also ought to simplify how we do
1956         closure call inlining: for inlined closure call frames we will simply require that the callee is
1957         already stashed on the stack in the Callee slot in the inline call frame header.
1958
1959         * dfg/DFGByteCodeParser.cpp:
1960         (ByteCodeParser):
1961         (JSC::DFG::ByteCodeParser::getDirect):
1962         (JSC::DFG::ByteCodeParser::get):
1963         (InlineStackEntry):
1964         (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand):
1965         (JSC::DFG::ByteCodeParser::handleCall):
1966         (JSC::DFG::ByteCodeParser::handleInlining):
1967         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1968         (JSC::DFG::ByteCodeParser::parse):
1969
1970 2013-01-02  Ryosuke Niwa  <rniwa@webkit.org>
1971
1972         Another Windows port build fix attempt. Try not exporting this symbol from JSC
1973         since it's also compiled in WebCore.
1974
1975         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
1976
1977 2013-01-02  Csaba Osztrogonác  <ossy@webkit.org>
1978
1979         One more unreviewed buildfix after r138609.
1980
1981         * jit/JITCall.cpp: Add a missing include.
1982
1983 2013-01-02  Csaba Osztrogonác  <ossy@webkit.org>
1984
1985         Unreviewed buildfix after r138609.
1986
1987         * jit/JITCall32_64.cpp: Add a missing include.
1988
1989 2013-01-01  Filip Pizlo  <fpizlo@apple.com>
1990
1991         Baseline JIT should have closure call caching
1992         https://bugs.webkit.org/show_bug.cgi?id=105900
1993
1994         Reviewed by Gavin Barraclough.
1995         
1996         This is not a speed-up by itself, but is meant to allow the DFG inliner to
1997         accurately discern between closure calls and non-closure calls, so that it can
1998         do closure call inlining in the future.
1999
2000         * bytecode/CallLinkStatus.cpp:
2001         (JSC::CallLinkStatus::computeFromLLInt):
2002         (JSC::CallLinkStatus::computeFor):
2003         * bytecode/CallLinkStatus.h:
2004         (JSC::CallLinkStatus::CallLinkStatus):
2005         (JSC::CallLinkStatus::isClosureCall):
2006         (CallLinkStatus):
2007         * dfg/DFGByteCodeParser.cpp:
2008         (JSC::DFG::ByteCodeParser::handleCall):
2009         * jit/JIT.cpp:
2010         (JSC::JIT::linkFor):
2011         (JSC::JIT::linkSlowCall):
2012         * jit/JIT.h:
2013         (JSC::JIT::compileClosureCall):
2014         * jit/JITCall.cpp:
2015         (JSC::JIT::privateCompileClosureCall):
2016         * jit/JITCall32_64.cpp:
2017         (JSC::JIT::privateCompileClosureCall):
2018         * jit/JITStubs.cpp:
2019         (JSC::DEFINE_STUB_FUNCTION):
2020         * jit/JITStubs.h:
2021         * jit/ThunkGenerators.cpp:
2022         (JSC::linkClosureCallGenerator):
2023         * jit/ThunkGenerators.h:
2024
2025 2013-01-01  Dan Bernstein  <mitz@apple.com>
2026
2027         <rdar://problem/12942239> Update copyright strings
2028
2029         Reviewed by Sam Weinig.
2030
2031         * Info.plist:
2032
2033 2012-12-31  Gavin Barraclough  <barraclough@apple.com>
2034
2035         Objective-C API for JavaScriptCore
2036         https://bugs.webkit.org/show_bug.cgi?id=105889
2037
2038         Reviewed by Filip Pizlo.
2039
2040         For a detailed description of the API implemented here, see:
2041             JSContext.h
2042             APIJSValue.h
2043             JSVirtualMachine.h
2044             JSExport.h
2045         Still to do -
2046             (1) Shoud rename APIJSValue.h -> JSValue.h (but we'll have to rename JSValue.h first).
2047             (2) Numerous FIXMEs, all with separate bugs filed.
2048
2049         * API/APIJSValue.h: Added.
2050             - this Objective-C class is used to reference a JavaScript object.
2051         * API/JSBase.h:
2052             - added JS_OBJC_API_ENABLED macro to control ObjC API support.
2053         * API/JSBlockAdaptor.h: Added.
2054             - this Objective-C class is used in creating a special NSBlock proxying a JavaScript function.
2055         * API/JSBlockAdaptor.mm: Added.
2056         (BlockArgument):
2057         (BlockArgument::~BlockArgument):
2058         (BlockArgumentBoolean):
2059         (BlockArgumentBoolean::get):
2060         (BlockArgumentNumeric):
2061         (BlockArgumentNumeric::get):
2062         (BlockArgumentId):
2063         (BlockArgumentId::get):
2064         (BlockArgumentStruct):
2065         (BlockArgumentStruct::BlockArgumentStruct):
2066         (BlockArgumentStruct::~BlockArgumentStruct):
2067         (BlockArgumentStruct::get):
2068             - decoded arguent type information of a JSBlockAdaptor.
2069         (BlockArgumentTypeDelegate):
2070         (BlockArgumentTypeDelegate::typeInteger):
2071         (BlockArgumentTypeDelegate::typeDouble):
2072         (BlockArgumentTypeDelegate::typeBool):
2073         (BlockArgumentTypeDelegate::typeVoid):
2074         (BlockArgumentTypeDelegate::typeId):
2075         (BlockArgumentTypeDelegate::typeOfClass):
2076         (BlockArgumentTypeDelegate::typeBlock):
2077         (BlockArgumentTypeDelegate::typeStruct):
2078             - delegate for use in conjunction with parseObjCType.
2079         (BlockResult):
2080         (BlockResult::~BlockResult):
2081         (BlockResultVoid):
2082         (BlockResultVoid::set):
2083         (BlockResultInteger):
2084         (BlockResultInteger::set):
2085         (BlockResultDouble):
2086         (BlockResultDouble::set):
2087         (BlockResultBoolean):
2088         (BlockResultBoolean::set):
2089         (BlockResultStruct):
2090         (BlockResultStruct::BlockResultStruct):
2091         (BlockResultStruct::~BlockResultStruct):
2092         (BlockResultStruct::set):
2093             - decoded result type information of a JSBlockAdaptor.
2094         (buildBlockSignature):
2095             - partial step in constructing a signature with stack offset information from one without.
2096         (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]):
2097             - constructor.
2098         (-[JSBlockAdaptor blockMatchesSignature:]):
2099             - check whether signature strings match, where only one contains stack frame offsets.
2100         (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
2101             - use the adaptor to create a special forwarding block.
2102         * API/JSCallbackObjectFunctions.h:
2103         (JSC::::inherits):
2104             - add missing braces to multiline for statement.
2105         * API/JSContext.h: Added.
2106             - this Objective-C class is used to reference a JavaScript context.
2107         * API/JSContext.mm: Added.
2108         (-[JSContext init]):
2109             - constructor.
2110         (-[JSContext initWithVirtualMachine:]):
2111             - construct in a given VM (JSGlobalData).
2112         (-[JSContext evaluateScript:]):
2113         (-[JSContext globalObject]):
2114             - evaluate a script, global object accessor.
2115         (+[JSContext currentContext]):
2116         (+[JSContext currentThis]):
2117         (+[JSContext currentArguments]):
2118             - These methods obtain context, this, arguments from within a callback.
2119         (-[JSContext virtualMachine]):
2120             - implementation for .virtualMachine property.
2121         (-[JSContext objectForKeyedSubscript:]):
2122         (-[JSContext setObject:forKeyedSubscript:]):
2123             - support for subscript property access.
2124         (contextInternalContext):
2125             - internal accessor to m_context.
2126         (-[JSContext dealloc]):
2127             - desctructor.
2128         (-[JSContext notifyException:]):
2129         (-[JSContext valueFromNotifyException:]):
2130         (-[JSContext boolFromNotifyException:]):
2131             - internal method to record an exception was thrown.
2132         (-[JSContext beginCallbackWithData:thisValue:argumentCount:arguments:]):
2133         (-[JSContext endCallbackWithData:]):
2134             - internal methods to push/pop a callback record.
2135         (-[JSContext protect:]):
2136         (-[JSContext unprotect:]):
2137             - internal methods to add a value to a protect set (used to protect the internal property of JSValue).
2138         (-[JSContext wrapperForObject:]):
2139             - internal method to create a wrapper object.
2140         (WeakContextRef::WeakContextRef):
2141         (WeakContextRef::~WeakContextRef):
2142         (WeakContextRef::get):
2143         (WeakContextRef::set):
2144             - Helper class to implement a weak reference to a JSContext.
2145         * API/JSContextInternal.h: Added.
2146         (CallbackData):
2147         (WeakContextRef):
2148             - see API/JSContext.mm for description of internal methods.
2149         * API/JSExport.h: Added.
2150             - Provides JSExport protocol & JSExportAs macro.
2151         * API/JSValue.mm: Added.
2152         (+[JSValue valueWithObject:inContext:]):
2153         (+[JSValue valueWithBool:inContext:]):
2154         (+[JSValue valueWithDouble:inContext:]):
2155         (+[JSValue valueWithInt32:inContext:]):
2156         (+[JSValue valueWithUInt32:inContext:]):
2157         (+[JSValue valueWithNewObjectInContext:]):
2158         (+[JSValue valueWithNewArrayInContext:]):
2159         (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]):
2160         (+[JSValue valueWithNewErrorFromMessage:inContext:]):
2161         (+[JSValue valueWithNullInContext:]):
2162         (+[JSValue valueWithUndefinedInContext:]):
2163             - Constructors.
2164         (-[JSValue toObject]):
2165         (-[JSValue toObjectOfClass:]):
2166         (-[JSValue toBool]):
2167         (-[JSValue toDouble]):
2168         (-[JSValue toInt32]):
2169         (-[JSValue toUInt32]):
2170         (-[JSValue toNumber]):
2171         (-[JSValue toString]):
2172         (-[JSValue toDate]):
2173         (-[JSValue toArray]):
2174         (-[JSValue toDictionary]):
2175             - Conversion to Objective-C types.
2176         (-[JSValue valueForProperty:]):
2177         (-[JSValue setValue:forProperty:]):
2178         (-[JSValue deleteProperty:]):
2179         (-[JSValue hasProperty:]):
2180         (-[JSValue defineProperty:descriptor:]):
2181             - Property access by property name.
2182         (-[JSValue valueAtIndex:]):
2183         (-[JSValue setValue:atIndex:]):
2184             - Property access by index.
2185         (-[JSValue isUndefined]):
2186         (-[JSValue isNull]):
2187         (-[JSValue isBoolean]):
2188         (-[JSValue isNumber]):
2189         (-[JSValue isString]):
2190         (-[JSValue isObject]):
2191             - Test JavaScript type.
2192         (-[JSValue isEqualToObject:]):
2193         (-[JSValue isEqualWithTypeCoercionToObject:]):
2194         (-[JSValue isInstanceOf:]):
2195             - ===, ==, instanceof operators.
2196         (-[JSValue callWithArguments:]):
2197         (-[JSValue constructWithArguments:]):
2198         (-[JSValue invokeMethod:withArguments:]):
2199             - Call & construct.
2200         (-[JSValue context]):
2201             - implementation for .context property.
2202         (-[JSValue toPoint]):
2203         (-[JSValue toRange]):
2204         (-[JSValue toRect]):
2205         (-[JSValue toSize]):
2206         (+[JSValue valueWithPoint:inContext:]):
2207         (+[JSValue valueWithRange:inContext:]):
2208         (+[JSValue valueWithRect:inContext:]):
2209         (+[JSValue valueWithSize:inContext:]):
2210             - Support for NS struct types.
2211         (-[JSValue objectForKeyedSubscript:]):
2212         (-[JSValue objectAtIndexedSubscript:]):
2213         (-[JSValue setObject:forKeyedSubscript:]):
2214         (-[JSValue setObject:atIndexedSubscript:]):
2215             - support for subscript property access.
2216         (isDate):
2217         (isArray):
2218             - internal helper functions to check for instances of JS Date, Array types.
2219         (JSContainerConvertor):
2220         (Task):
2221         (JSContainerConvertor::JSContainerConvertor):
2222         (JSContainerConvertor::isWorkListEmpty):
2223         (JSContainerConvertor::convert):
2224         (JSContainerConvertor::add):
2225         (JSContainerConvertor::take):
2226             - helper class for tracking state while converting to Array/Dictionary objects.
2227         (valueToObjectWithoutCopy):
2228         (containerValueToObject):
2229         (valueToObject):
2230         (valueToNumber):
2231         (valueToString):
2232         (valueToDate):
2233         (valueToArray):
2234         (valueToDictionary):
2235             - function for converting JavaScript values to Objective-C objects.
2236         (ObjcContainerConvertor):
2237         (ObjcContainerConvertor::ObjcContainerConvertor):
2238         (ObjcContainerConvertor::isWorkListEmpty):
2239         (ObjcContainerConvertor::convert):
2240         (ObjcContainerConvertor::add):
2241         (ObjcContainerConvertor::take):
2242             - helper class for tracking state while converting to Array/Dictionary values.
2243         (objectToValueWithoutCopy):
2244         (objectToValue):
2245         (valueInternalValue):
2246             - function for converting Objective-C objects to JavaScript values.
2247         (+[JSValue valueWithValue:inContext:]):
2248         (-[JSValue initWithValue:inContext:]):
2249             - internal constructors.
2250         (StructTagHandler):
2251         (getStructTagHandler):
2252         (+[JSValue selectorForStructToValue:]):
2253         (+[JSValue selectorForValueToStruct:]):
2254             - methods to tracking struct types that support conversion to/from JSValue.
2255         (-[JSValue dealloc]):
2256             - destructor.
2257         (-[JSValue description]):
2258             - Objective-C to-NSString conversion.
2259         (typeToValueInvocationFor):
2260         (valueToTypeInvocationFor):
2261             - create invocation objects for conversion to/from JSValue.
2262         * API/JSValueInternal.h: Added.
2263             - see API/JSValue.mm for description of internal methods.
2264         * API/JSVirtualMachine.h: Added.
2265             - this Objective-C class is used to reference a JavaScript virtual machine (JSGlobalData).
2266         * API/JSVirtualMachine.mm: Added.
2267         (-[JSVirtualMachine init]):
2268         (-[JSVirtualMachine dealloc]):
2269             - constructor & destructor.
2270         (getGroupFromVirtualMachine):
2271             - internal accessor for m_group property.
2272         * API/JSVirtualMachineInternal.h: Added.
2273             - see API/JSVirtualMachine.mm for description of internal methods.
2274         * API/JSWrapperMap.h: Added.
2275         * API/JSWrapperMap.mm: Added.
2276         (wrapperClass):
2277             - singleton root for detction (& unwrapping) of wrapper objects.
2278         (selectorToPropertyName):
2279             - default selector to property name conversion.
2280         (createObjectWithCustomBrand):
2281             - creates a JSObject with a custom NativeBrand (class name).
2282         (createRenameMap):
2283             - parse @optional properties of a JSExport protocol.
2284         (putNonEnumerable):
2285             - property put with enumerable=false.
2286         (copyMethodsToObject):
2287             - iterate methods in a protocol; add functions to a JSObject.
2288         (parsePropertyAttributes):
2289             - examine protocol property metadata.
2290         (makeSetterName):
2291             - "foo" -> "setFoo"
2292         (copyPrototypeProperties):
2293             - create properties on a Protocol object reflecting the instance methods & properties of a protocol.
2294         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
2295         (-[JSObjCClassInfo dealloc]):
2296         (-[JSObjCClassInfo wrapperForObject:]):
2297         (-[JSObjCClassInfo constructor]):
2298             - cache the Protocol/Constructor objects for an Objective-C type.
2299         (-[JSWrapperMap initWithContext:]):
2300         (-[JSWrapperMap dealloc]):
2301             - constructor & desctructor.
2302         (-[JSWrapperMap classInfoForClass:]):
2303             - maps Class -> JSObjCClassInfo.
2304         (-[JSWrapperMap wrapperForObject:]):
2305             - cretae or retrieve a cached wrapper value for an object.
2306         (tryUnwrapObjcObject):
2307             - check whether a value is a wrapper object; unwrap if so.
2308         * API/JavaScriptCore.h:
2309             - Added includes for new API headers.
2310         * API/ObjCCallbackFunction.h: Added.
2311             - this class is used to wrap Objective-C instance methods, class methods & blocks as JSFunction objects.
2312         * API/ObjCCallbackFunction.mm: Added.
2313         (CallbackArgument):
2314         (CallbackArgument::~CallbackArgument):
2315         (CallbackArgumentBoolean):
2316         (CallbackArgumentBoolean::set):
2317         (CallbackArgumentInteger):
2318         (CallbackArgumentInteger::set):
2319         (CallbackArgumentDouble):
2320         (CallbackArgumentDouble::set):
2321         (CallbackArgumentJSValue):
2322         (CallbackArgumentJSValue::set):
2323         (CallbackArgumentId):
2324         (CallbackArgumentId::set):
2325         (CallbackArgumentOfClass):
2326         (CallbackArgumentOfClass::CallbackArgumentOfClass):
2327         (CallbackArgumentOfClass::~CallbackArgumentOfClass):
2328         (CallbackArgumentOfClass::set):
2329         (CallbackArgumentNSNumber):
2330         (CallbackArgumentNSNumber::set):
2331         (CallbackArgumentNSString):
2332         (CallbackArgumentNSString::set):
2333         (CallbackArgumentNSDate):
2334         (CallbackArgumentNSDate::set):
2335         (CallbackArgumentNSArray):
2336         (CallbackArgumentNSArray::set):
2337         (CallbackArgumentNSDictionary):
2338         (CallbackArgumentNSDictionary::set):
2339         (CallbackArgumentStruct):
2340         (CallbackArgumentStruct::CallbackArgumentStruct):
2341         (CallbackArgumentStruct::~CallbackArgumentStruct):
2342         (CallbackArgumentStruct::set):
2343         (CallbackArgumentBlockCallback):
2344         (CallbackArgumentBlockCallback::CallbackArgumentBlockCallback):
2345         (CallbackArgumentBlockCallback::~CallbackArgumentBlockCallback):
2346         (CallbackArgumentBlockCallback::set):
2347             - decoded arguent type information of a ObjCCallbackFunction.
2348         (ArgumentTypeDelegate):
2349         (ArgumentTypeDelegate::typeInteger):
2350         (ArgumentTypeDelegate::typeDouble):
2351         (ArgumentTypeDelegate::typeBool):
2352         (ArgumentTypeDelegate::typeVoid):
2353         (ArgumentTypeDelegate::typeId):
2354         (ArgumentTypeDelegate::typeOfClass):
2355         (ArgumentTypeDelegate::typeBlock):
2356         (ArgumentTypeDelegate::typeStruct):
2357             - delegate for use in conjunction with parseObjCType.
2358         (CallbackResult):
2359         (CallbackResult::~CallbackResult):
2360         (CallbackResultVoid):
2361         (CallbackResultVoid::get):
2362         (CallbackResultId):
2363         (CallbackResultId::get):
2364         (CallbackResultNumeric):
2365         (CallbackResultNumeric::get):
2366         (CallbackResultBoolean):
2367         (CallbackResultBoolean::get):
2368         (CallbackResultStruct):
2369         (CallbackResultStruct::CallbackResultStruct):
2370         (CallbackResultStruct::~CallbackResultStruct):
2371         (CallbackResultStruct::get):
2372             - decoded result type information of a ObjCCallbackFunction.
2373         (ResultTypeDelegate):
2374         (ResultTypeDelegate::typeInteger):
2375         (ResultTypeDelegate::typeDouble):
2376         (ResultTypeDelegate::typeBool):
2377         (ResultTypeDelegate::typeVoid):
2378         (ResultTypeDelegate::typeId):
2379         (ResultTypeDelegate::typeOfClass):
2380         (ResultTypeDelegate::typeBlock):
2381         (ResultTypeDelegate::typeStruct):
2382             - delegate for use in conjunction with parseObjCType.
2383         (ObjCCallbackFunction):
2384         (ObjCCallbackFunction::ObjCCallbackFunction):
2385         (ObjCCallbackFunction::~ObjCCallbackFunction):
2386             - constructor & destructor.
2387         (ObjCCallbackFunction::context):
2388             - accessor.
2389         (ObjCCallbackFunction::wrappedBlock):
2390             - attemmpt to unwrap a block object.
2391         (objCCallbackFunctionFinalize):
2392         (objCCallbackFunctionCallAsFunction):
2393         (objCCallbackFunctionClass):
2394             - JSClassRef used to represent ObjCCallbackFunction objects.
2395         (ObjCCallbackFunction::call):
2396         (blockSignatureContainsClass):
2397             - helper function to determine if we're running on a recent Clang.
2398         (skipNumber):
2399             - helper used in parsing signature strings.
2400         (objCCallbackFunctionForInvocation):
2401         (objCCallbackFunctionForMethod):
2402         (objCCallbackFunctionForBlock):
2403             - functions to try to create ObjCCallbackFunction instances for methods/blocks.
2404         (tryUnwrapBlock):
2405             - attemmpt to unwrap a block object.
2406         * API/ObjcRuntimeExtras.h: Added.
2407         (protocolImplementsProtocol):
2408         (forEachProtocolImplementingProtocol):
2409         (forEachMethodInClass):
2410         (forEachMethodInProtocol):
2411         (forEachPropertyInProtocol):
2412             - functions used in reflecting on Objective-C types.
2413         (skipPair):
2414             - parsing helper used by parseObjCType, scans for matching parentheses.
2415         (StringRange):
2416         (StringRange::StringRange):
2417         (StringRange::~StringRange):
2418         (StringRange::operator const char*):
2419         (StringRange::get):
2420             - Helper class - create a c string copy of a range of an existing string.
2421         (parseObjCType):
2422             - function to parse Objective-C type strings, makes callbacks to a deleagte.
2423         * API/tests/testapi.c:
2424         (main):
2425             - added call to testObjectiveCAPI (in testapi.m).
2426         * API/tests/testapi.m: Added.
2427         (+[ParentObject parentTest]):
2428         (+[TestObject testObject]):
2429         (+[TestObject classTest]):
2430         (-[TestObject getString]):
2431         (-[TestObject testArgumentTypesWithInt:double:boolean:string:number:array:dictionary:]):
2432         (-[TestObject callback:]):
2433         (-[TextXYZ test:]):
2434             - test object, used in various test vases.
2435         (checkResult):
2436             - helper function.
2437         (blockSignatureContainsClass):
2438             - helper function to determine if we're running on a recent Clang.
2439         (testObjectiveCAPI):
2440             - new test cases.
2441         * JavaScriptCore.xcodeproj/project.pbxproj:
2442             - added new files.
2443         * runtime/JSGlobalData.cpp:
2444         (JSC::JSGlobalData::JSGlobalData):
2445         * runtime/JSGlobalData.h:
2446         (JSGlobalData):
2447             - added m_apiData - provide convenient storage for use by the API.
2448         * runtime/JSGlobalObject.cpp:
2449         (JSC::JSGlobalObject::JSGlobalObject):
2450         * runtime/JSGlobalObject.h:
2451         (JSGlobalObject):
2452             - added m_apiData - provide convenient storage for use by the API.
2453
2454 2012-12-27  Csaba Osztrogonác  <ossy@webkit.org>
2455
2456         One more unreviwed holiday MIPS and SH4 buildfixes after r138516.
2457
2458         * jit/ThunkGenerators.cpp:
2459
2460 2012-12-27  Csaba Osztrogonác  <ossy@webkit.org>
2461
2462         Unreviwed holiday ARM and SH4 buildfixes after r138516.
2463
2464         * jit/ThunkGenerators.cpp:
2465         (JSC::nativeForGenerator):
2466
2467 2012-12-26  Filip Pizlo  <fpizlo@apple.com>
2468
2469         All JIT stubs should go through the getCTIStub API
2470         https://bugs.webkit.org/show_bug.cgi?id=105750
2471
2472         Reviewed by Sam Weinig.
2473         
2474         Previously JITThunks had two sets of thunks: one static set stored in a struct,
2475         which was filled by JIT::privateCompileCTITrampolines, and another set stored in
2476         a HashMap. Moreover, the code to generate the code for the CTI trampoline struct
2477         had loads of copy-paste between JSVALUE32_64 and JSVALUE64, and was total
2478         unmodular with respect to calls versus constructors, among other things.
2479                   
2480         This changeset removes this struct and rationalizes the code that generates those
2481         thunks. All of thunks are now generated through the getCTIStub HashMap API. All
2482         thunks for the baseline JIT now use the JSInterfaceJIT and have their codegen
2483         located in ThunkGenerators.cpp. All thunks now share as much code as possible -
2484         it turns out that they are almost 100% identical between 32_64 and 64, so that
2485         works out great. A bunch of call vs. construct duplication was eliminated. And,
2486         most of the call link versus virtual call duplication was also eliminated.
2487         
2488         This does not change behavior but it does make it easier to add more thunks in
2489         the future.
2490
2491         * bytecode/CallLinkInfo.cpp:
2492         (JSC::CallLinkInfo::unlink):
2493         * jit/JIT.cpp:
2494         (JSC::JIT::linkFor):
2495         * jit/JIT.h:
2496         (JIT):
2497         * jit/JITCall.cpp:
2498         (JSC::JIT::compileCallEvalSlowCase):
2499         (JSC::JIT::compileOpCallSlowCase):
2500         * jit/JITCall32_64.cpp:
2501         (JSC::JIT::compileCallEvalSlowCase):
2502         (JSC::JIT::compileOpCallSlowCase):
2503         * jit/JITInlines.h:
2504         (JSC):
2505         * jit/JITOpcodes.cpp:
2506         (JSC):
2507         (JSC::JIT::privateCompileCTINativeCall):
2508         * jit/JITOpcodes32_64.cpp:
2509         (JSC):
2510         * jit/JITStubs.cpp:
2511         (JSC::tryCacheGetByID):
2512         * jit/JITThunks.cpp:
2513         (JSC::JITThunks::JITThunks):
2514         (JSC::JITThunks::ctiNativeCall):
2515         (JSC::JITThunks::ctiNativeConstruct):
2516         (JSC):
2517         (JSC::JITThunks::hostFunctionStub):
2518         * jit/JITThunks.h:
2519         (JSC):
2520         (JITThunks):
2521         * jit/JSInterfaceJIT.h:
2522         (JSInterfaceJIT):
2523         (JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
2524         (JSC):
2525         (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck):
2526         (JSC::JSInterfaceJIT::emitJumpIfNotType):
2527         (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr):
2528         (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
2529         (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader):
2530         (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader):
2531         (JSC::JSInterfaceJIT::preserveReturnAddressAfterCall):
2532         (JSC::JSInterfaceJIT::restoreReturnAddressBeforeReturn):
2533         (JSC::JSInterfaceJIT::restoreArgumentReference):
2534         * jit/ThunkGenerators.cpp:
2535         (JSC::generateSlowCaseFor):
2536         (JSC):
2537         (JSC::linkForGenerator):
2538         (JSC::linkCallGenerator):
2539         (JSC::linkConstructGenerator):
2540         (JSC::virtualForGenerator):
2541         (JSC::virtualCallGenerator):
2542         (JSC::virtualConstructGenerator):
2543         (JSC::stringLengthTrampolineGenerator):
2544         (JSC::nativeForGenerator):
2545         (JSC::nativeCallGenerator):
2546         (JSC::nativeConstructGenerator):
2547         (JSC::charCodeAtThunkGenerator):
2548         (JSC::charAtThunkGenerator):
2549         (JSC::fromCharCodeThunkGenerator):
2550         (JSC::sqrtThunkGenerator):
2551         (JSC::floorThunkGenerator):
2552         (JSC::ceilThunkGenerator):
2553         (JSC::roundThunkGenerator):
2554         (JSC::expThunkGenerator):
2555         (JSC::logThunkGenerator):
2556         (JSC::absThunkGenerator):
2557         (JSC::powThunkGenerator):
2558         * jit/ThunkGenerators.h:
2559         (JSC):
2560         * runtime/Executable.h:
2561         (NativeExecutable):
2562         (JSC::NativeExecutable::nativeFunctionFor):
2563         (JSC::NativeExecutable::offsetOfNativeFunctionFor):
2564
2565 2012-12-25  Gyuyoung Kim  <gyuyoung.kim@samsung.com>
2566
2567         [CMAKE] Remove header files in JavaScriptCore/CMakeLists.txt
2568         https://bugs.webkit.org/show_bug.cgi?id=105753
2569
2570         Reviewed by Laszlo Gombos.
2571
2572         * CMakeLists.txt: Remove header files in source list.
2573
2574 2012-12-25  Filip Pizlo  <fpizlo@apple.com>
2575
2576         JITThunks should be in its own file
2577         https://bugs.webkit.org/show_bug.cgi?id=105744
2578
2579         Rubber stamped by Sam Weinig.
2580         
2581         Moved JITThunks into its own file and removed some static methods from it
2582         that were not related to what JITThunks currently does. Performed various
2583         pagan rituals to get it to build - apparently there is a circular dependency
2584         between JSCell, Weak, and JITThunks, which magically resolves itself if you
2585         make sure to first include Register.h. Making it so that fewer pagan rituals
2586         need to be performed if this code changes in the future is covered by
2587         https://bugs.webkit.org/show_bug.cgi?id=105696.
2588
2589         * CMakeLists.txt:
2590         * GNUmakefile.list.am:
2591         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
2592         * JavaScriptCore.xcodeproj/project.pbxproj:
2593         * Target.pri:
2594         * jit/JITStubs.cpp:
2595         (JSC::tryCachePutByID):
2596         (JSC::tryCacheGetByID):
2597         * jit/JITStubs.h:
2598         (JSC::JITStackFrame::returnAddressSlot):
2599         (JSC::returnAddressIsInCtiTrampoline):
2600         * jit/JITThunks.cpp: Added.
2601         (JSC::JITThunks::JITThunks):
2602         (JSC::JITThunks::~JITThunks):
2603         (JSC::JITThunks::ctiStub):
2604         (JSC::JITThunks::hostFunctionStub):
2605         (JSC::JITThunks::clearHostFunctionStubs):
2606         * jit/JITThunks.h: Added.
2607         (JSC::JITThunks::ctiStringLengthTrampoline):
2608         (JSC::JITThunks::ctiVirtualCallLink):
2609         (JSC::JITThunks::ctiVirtualConstructLink):
2610         (JSC::JITThunks::ctiVirtualCall):
2611         (JSC::JITThunks::ctiVirtualConstruct):
2612         (JSC::JITThunks::ctiNativeCall):
2613         (JSC::JITThunks::ctiNativeConstruct):
2614         * jit/ThunkGenerator.h: Added.
2615         * jit/ThunkGenerators.cpp:
2616         * jit/ThunkGenerators.h:
2617         * runtime/JSGlobalData.h:
2618
2619 2012-12-25  Ilya Tikhonovsky  <loislo@chromium.org>
2620
2621         Unreviewed follow-up for r138455.
2622
2623         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
2624
2625 2012-12-24  Ilya Tikhonovsky  <loislo@chromium.org>
2626
2627         Unreviewed compilation fix for r138452.
2628
2629         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
2630
2631 2012-12-24  Laszlo Gombos  <l.gombos@samsung.com>
2632
2633         Remove wtf/Platform.h includes from {c|cpp} files
2634         https://bugs.webkit.org/show_bug.cgi?id=105678
2635
2636         Reviewed by Kentaro Hara.
2637
2638         Remove wtf/Platform.h from the include list as it is already
2639         included in config.h.
2640
2641         * disassembler/udis86/udis86.c:
2642         * disassembler/udis86/udis86_decode.c:
2643         * disassembler/udis86/udis86_input.c:
2644         * disassembler/udis86/udis86_itab_holder.c:
2645         * disassembler/udis86/udis86_syn-att.c:
2646         * disassembler/udis86/udis86_syn-intel.c:
2647         * disassembler/udis86/udis86_syn.c:
2648         * heap/VTableSpectrum.cpp:
2649
2650 2012-12-21  Filip Pizlo  <fpizlo@apple.com>
2651
2652         DFG Arrayify slow path should be out-of-line
2653         https://bugs.webkit.org/show_bug.cgi?id=105400
2654
2655         Reviewed by Gavin Barraclough.
2656         
2657         The interesting bit of this change is allowing out-of-line slow path generators
2658         to emit speculation checks. This is accomplished by having a version of
2659         speculationCheck() that returns a jump placeholder instead of taking a jump (or
2660         jump list) as an argument. You can then fill in that jump placeholder at a
2661         later time, so long as you do it before OSR exit linking. Slow path generators
2662         run before linking, so that just naturally ends up working.
2663         
2664         This isn't really a big win, but we know that out-of-lining slow paths is
2665         generally a good thing to do, so it's fair to assume that this is a move in the
2666         right direction.
2667
2668         * CMakeLists.txt:
2669         * GNUmakefile.list.am:
2670         * JavaScriptCore.xcodeproj/project.pbxproj:
2671         * Target.pri:
2672         * dfg/DFGArrayifySlowPathGenerator.h: Added.
2673         (DFG):
2674         (ArrayifySlowPathGenerator):
2675         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
2676         (JSC::DFG::ArrayifySlowPathGenerator::generateInternal):
2677         * dfg/DFGOSRExitJumpPlaceholder.cpp: Added.
2678         (DFG):
2679         (JSC::DFG::OSRExitJumpPlaceholder::fill):
2680         * dfg/DFGOSRExitJumpPlaceholder.h: Added.
2681         (DFG):
2682         (OSRExitJumpPlaceholder):
2683         (JSC::DFG::OSRExitJumpPlaceholder::OSRExitJumpPlaceholder):
2684         (JSC::DFG::OSRExitJumpPlaceholder::operator!):
2685         * dfg/DFGSpeculativeJIT.cpp:
2686         (JSC::DFG::SpeculativeJIT::speculationCheck):
2687         (DFG):
2688         (JSC::DFG::SpeculativeJIT::arrayify):
2689         * dfg/DFGSpeculativeJIT.h:
2690         (SpeculativeJIT):
2691
2692 2012-12-20  Oliver Hunt  <oliver@apple.com>
2693
2694         Finally found the problem.  Using the wrong JSContextGroup.
2695
2696         * API/tests/testapi.c:
2697         (main):
2698
2699 2012-12-20  Oliver Hunt  <oliver@apple.com>
2700
2701         Try to convince bots to be happy with testapi.
2702
2703         * API/JSScriptRefPrivate.h:
2704
2705 2012-12-20  Michael Saboff  <msaboff@apple.com>
2706
2707         JIT: Change uninitialized pointer value -1 to constant
2708         https://bugs.webkit.org/show_bug.cgi?id=105576
2709
2710         Rubber stamped by Gavin Barraclough.
2711
2712         Changed the use of -1 as a pointer value in the JITs to be the constant unusedPointer defined in the
2713         new file jit/UnusedPointer.h.  Made it's value 0xd1e7beef, which is a bad pointer on most architectures
2714         because it is odd, and to distinguish it from other common values.
2715
2716         * GNUmakefile.list.am:
2717         * JavaScriptCore.xcodeproj/project.pbxproj:
2718         * dfg/DFGRepatch.cpp:
2719         (JSC::DFG::dfgResetGetByID):
2720         (JSC::DFG::dfgResetPutByID):
2721         * dfg/DFGSpeculativeJIT32_64.cpp:
2722         (JSC::DFG::SpeculativeJIT::cachedGetById):
2723         (JSC::DFG::SpeculativeJIT::cachedPutById):
2724         * dfg/DFGSpeculativeJIT64.cpp:
2725         (JSC::DFG::SpeculativeJIT::cachedGetById):
2726         (JSC::DFG::SpeculativeJIT::cachedPutById):
2727         * jit/JIT.h:
2728         * jit/JITPropertyAccess.cpp:
2729         (JSC::JIT::resetPatchGetById):
2730         (JSC::JIT::resetPatchPutById):
2731         * jit/JITPropertyAccess32_64.cpp:
2732         (JSC::JIT::resetPatchGetById):
2733         (JSC::JIT::resetPatchPutById):
2734         * jit/JITWriteBarrier.h:
2735         (JSC::JITWriteBarrierBase::clearToUnusedPointer):
2736         (JSC::JITWriteBarrierBase::get):
2737         * jit/UnusedPointer.h: Added.
2738
2739 2012-12-20  Filip Pizlo  <fpizlo@apple.com>
2740
2741         DFG shouldn't emit CheckStructure on array accesses if exit profiling tells it not to
2742         https://bugs.webkit.org/show_bug.cgi?id=105577
2743
2744         Reviewed by Mark Hahnenberg.
2745         
2746         I don't know why this wasn't there from the beginning.
2747
2748         * dfg/DFGByteCodeParser.cpp:
2749         (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
2750
2751 2012-12-19  Filip Pizlo  <fpizlo@apple.com>
2752
2753         DFG speculation checks that take JumpList should consolidate OSRExits
2754         https://bugs.webkit.org/show_bug.cgi?id=105401
2755
2756         Reviewed by Oliver Hunt.
2757
2758         Change OSRExitCompilationInfo to always contain a JumpList, and change JumpList
2759         to be more compact. This way, a speculationCheck that takes a JumpList only has
2760         to emit one OSRExit structure, and one OSRExit landing pad.
2761         
2762         The downside is that we get less precise information about *where* we exited
2763         from. So, this also includes changes to the profiler to be more relaxed about
2764         what an ExitSite is.
2765
2766         * assembler/AbstractMacroAssembler.h:
2767         (JumpList):
2768         * dfg/DFGJITCompiler.cpp:
2769         (JSC::DFG::JITCompiler::linkOSRExits):
2770         (JSC::DFG::JITCompiler::link):
2771         * dfg/DFGJITCompiler.h:
2772         (DFG):
2773         (JSC::DFG::JITCompiler::appendExitInfo):
2774         (JITCompiler):
2775         * dfg/DFGOSRExitCompilationInfo.h:
2776         (OSRExitCompilationInfo):
2777         * dfg/DFGSpeculativeJIT.cpp:
2778         (JSC::DFG::SpeculativeJIT::speculationCheck):
2779         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
2780         (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
2781         * profiler/ProfilerCompilation.cpp:
2782         (JSC::Profiler::Compilation::addOSRExitSite):
2783         * profiler/ProfilerCompilation.h:
2784         (Compilation):
2785         * profiler/ProfilerOSRExitSite.cpp:
2786         (JSC::Profiler::OSRExitSite::toJS):
2787         * profiler/ProfilerOSRExitSite.h:
2788         (JSC::Profiler::OSRExitSite::OSRExitSite):
2789         (JSC::Profiler::OSRExitSite::codeAddress):
2790         (OSRExitSite):
2791
2792 2012-12-19  Oliver Hunt  <oliver@apple.com>
2793
2794         Fix some incorrect tests in testapi.c
2795
2796         Reviewed by Simon Fraser.
2797
2798         * API/tests/testapi.c:
2799         (main):
2800
2801 2012-12-19  Filip Pizlo  <fpizlo@apple.com>
2802
2803         JSObject::ensure<IndexingType> should gracefully handle InterceptsGetOwn..., and should never be called when the 'this' is not an object
2804         https://bugs.webkit.org/show_bug.cgi?id=105468
2805
2806         Reviewed by Mark Hahnenberg, Oliver Hunt, and Gavin Barraclough.
2807
2808         Changed JSObject::ensure<IndexingType> methods to gracefully handle
2809         InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero. Most of them handle it by returning
2810         null as a result of indexingShouldBeSparse() returning true, while ensureArrayStorage handles it
2811         by entering dictionary indexing mode, which forces the object to behave correctly even if there
2812         is proxying or weird prototype stuff going on.
2813         
2814         Changed DFGOperations entrypoints to reject non-objects, so that JSObject doesn't have to deal
2815         with pretending to be JSString. In particular, this would go wrong in the ArrayStorage case
2816         since we'd try to resize a butterfly on a JSString, but JSString has something other than
2817         m_butterfly at that offset.
2818         
2819         Finally, removed all InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero from JIT code
2820         since those are now redundant.
2821
2822         * dfg/DFGOperations.cpp:
2823         * dfg/DFGOperations.h:
2824         * dfg/DFGSpeculativeJIT.cpp:
2825         (JSC::DFG::SpeculativeJIT::arrayify):
2826         * dfg/DFGSpeculativeJIT.h:
2827         (JSC::DFG::SpeculativeJIT::callOperation):
2828         * runtime/JSObject.cpp:
2829         (JSC::JSObject::enterDictionaryIndexingMode):
2830         (JSC::JSObject::ensureInt32Slow):
2831         (JSC::JSObject::ensureDoubleSlow):
2832         (JSC::JSObject::ensureContiguousSlow):
2833         (JSC::JSObject::ensureArrayStorageSlow):
2834         (JSC):
2835         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
2836         * runtime/JSObject.h:
2837         (JSObject):
2838
2839 2012-12-19  Oliver Hunt  <oliver@apple.com>
2840
2841         Tidy up JSScriptRef API
2842         https://bugs.webkit.org/show_bug.cgi?id=105470
2843
2844         Reviewed by Anders Carlsson.
2845
2846         People found the API's use of a context confusing, so we'll switch to a JSContextGroup based
2847         API, and drop a number of the unnecessary uses of contexts.
2848
2849         * API/JSScriptRef.cpp:
2850         (OpaqueJSScript::globalData):
2851         (parseScript):
2852         * API/JSScriptRefPrivate.h:
2853         * API/tests/testapi.c:
2854         (main):
2855
2856 2012-12-19  Alexis Menard  <alexis@webkit.org>
2857
2858         Implement CSS parsing for CSS transitions unprefixed.
2859         https://bugs.webkit.org/show_bug.cgi?id=104804
2860
2861         Reviewed by Dean Jackson.
2862
2863         Add a new flag ENABLE_CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED
2864         to cover the work of unprefixing Transforms, Animations and 
2865         Transitions. It will let the possibility of each ports to turn it off 
2866         in their release branches until we're confident that these CSS 
2867         properties are ready to be unprefixed.
2868
2869         * Configurations/FeatureDefines.xcconfig:
2870
2871 2012-12-18  Filip Pizlo  <fpizlo@apple.com>
2872
2873         Proxies should set InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero
2874         https://bugs.webkit.org/show_bug.cgi?id=105379
2875
2876         Reviewed by Gavin Barraclough.
2877
2878         Forgetting to set this flag led to the DFG trying to ensure array storage on a proxy. I've
2879         now hardened the code with a release assertion as well as fixing the bug. A release assertion
2880         is appropriate here since this is slow-path code.
2881
2882         * runtime/JSObject.cpp:
2883         (JSC::JSObject::enterDictionaryIndexingMode):
2884         (JSC::JSObject::ensureInt32Slow):
2885         (JSC::JSObject::ensureDoubleSlow):
2886         (JSC::JSObject::ensureContiguousSlow):
2887         (JSC::JSObject::ensureArrayStorageSlowNoCheck):
2888         (JSC::JSObject::ensureArrayStorageSlow):
2889         (JSC):
2890         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
2891         * runtime/JSObject.h:
2892         (JSObject):
2893         * runtime/JSProxy.h:
2894         (JSProxy):
2895
2896 2012-12-18  Oliver Hunt  <oliver@apple.com>
2897
2898         Add a JSScriptRef API to JSC so that we can allow API users to avoid the full cost of reparsing everytime the execute a script.
2899         https://bugs.webkit.org/show_bug.cgi?id=105340
2900
2901         Reviewed by Gavin Barraclough.
2902
2903         This patch adds a (currently private) API to allow users of the JSC API to create a JSScript object
2904         that references a reusable version of the script that they wish to evaluate.  This can help us avoid
2905         numeorus copies that are otherwise induced by our existing API and gives us an opaque object that we
2906         can hang various caches off.  Currently this is simply a simple SourceProvider, but in future we may
2907         be able to add more caching without requiring new/replacement APIs. 
2908
2909         * API/JSScriptRef.cpp: Added.
2910         * API/JSScriptRefPrivate.h: Added.
2911         * API/tests/testapi.c:
2912           Add tests for new APIs.
2913         * JavaScriptCore.xcodeproj/project.pbxproj:
2914
2915 2012-12-18  Filip Pizlo  <fpizlo@apple.com>
2916
2917         DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode incorrectly checks for non-array array storage when it should be checking for array array storage
2918         https://bugs.webkit.org/show_bug.cgi?id=105365
2919
2920         Reviewed by Mark Hahnenberg.
2921
2922         * dfg/DFGSpeculativeJIT.cpp:
2923         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
2924
2925 2012-12-18  Filip Pizlo  <fpizlo@apple.com>
2926
2927         SunSpider/date-format-tofte shouldn't compile each of the tiny worthless eval's only to OSR exit in the prologue every time
2928         https://bugs.webkit.org/show_bug.cgi?id=105335
2929
2930         Reviewed by Geoffrey Garen.
2931
2932         The first thing I did was restructure the logic of canInlineResolveOperations(),
2933         because I didn't understand it. This was relevant because the OSR exits are
2934         caused by a resolve that the DFG cannot handle.
2935         
2936         I was then going to make it so that we didn't compile the resolve at all, but
2937         realized that this would not be the best fix: it didn't seem sensible to me to
2938         be optimizing these evals after only 60 invocations. Evals should have a higher
2939         threshold, since they often contain code for which the baseline JIT does a
2940         pretty good job already (if all you've got is a single heap access or a single
2941         hard-to-inline call, then the baseline JIT has got you covered), and typically
2942         if we see one eval code block we expect to see more (from the same eval site):
2943         so our typical low threshold could lead to a *lot* of compilation. As such, the
2944         main effect of this patch is to introduce an evalThresholdMultiplier, which is
2945         now set to 10.
2946         
2947         This is a ~5% speed-up on data-format-tofte. No regressions anywhere as far as
2948         I can see.
2949
2950         * bytecode/CodeBlock.cpp:
2951         (JSC::CodeBlock::codeTypeThresholdMultiplier):
2952         (JSC):
2953         (JSC::CodeBlock::optimizationThresholdScalingFactor):
2954         (JSC::CodeBlock::exitCountThresholdForReoptimization):
2955         (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
2956         * bytecode/CodeBlock.h:
2957         (CodeBlock):
2958         * dfg/DFGCapabilities.h:
2959         (JSC::DFG::canInlineResolveOperations):
2960         * dfg/DFGOSRExitCompiler.cpp:
2961         * runtime/Options.h:
2962         (JSC):
2963
2964 2012-12-18  Filip Pizlo  <fpizlo@apple.com>
2965
2966         Convert indexingTypeToString to IndexingTypeDump
2967         https://bugs.webkit.org/show_bug.cgi?id=105351
2968
2969         Reviewed by Mark Hahnenberg.
2970
2971         This gets rid of another case of static char buffer[thingy].
2972
2973         * dfg/DFGGraph.cpp:
2974         (JSC::DFG::Graph::dump):
2975         * runtime/IndexingType.cpp:
2976         (JSC::dumpIndexingType):
2977         * runtime/IndexingType.h:
2978         (JSC):
2979         * runtime/JSValue.cpp:
2980         (JSC::JSValue::dump):
2981
2982 2012-12-18  Beth Dakin  <bdakin@apple.com>
2983
2984         https://bugs.webkit.org/show_bug.cgi?id=102579
2985         [mac] Enable scaled cursors
2986
2987         Reviewed by Dean Jackson.
2988
2989         * Configurations/FeatureDefines.xcconfig:
2990
2991 2012-12-18  Mark Hahnenberg  <mhahnenberg@apple.com>
2992
2993         Restrictions on oversize CopiedBlock allocations should be relaxed
2994         https://bugs.webkit.org/show_bug.cgi?id=105339
2995
2996         Reviewed by Filip Pizlo.
2997
2998         Currently the DFG has a single branch in the inline allocation path for property/array storage where 
2999         it checks to see if the number of bytes requested will fit in the current block. This does not match 
3000         what the C++ allocation path does; it checks if the requested number of bytes is oversize, and then 
3001         if it's not, it tries to fit it in the current block. The garbage collector assumes that ALL allocations 
3002         that are greater than 16KB are in oversize blocks. Therefore, this mismatch can lead to crashes when 
3003         the collector tries to perform some operation on a CopiedBlock.
3004
3005         To avoid adding an extra branch to the inline allocation path in the JIT, we should make it so that 
3006         oversize blocks are allocated on the same alignment boundaries so that there is a single mask to find 
3007         the block header of any CopiedBlock (rather than two, one for normal and one for oversize blocks), and 
3008         we should figure out if a block is oversize by some other method than just whatever the JSObject says 
3009         it is. One way we could record this info Region of the block, since we allocate a one-off Region for 
3010         oversize blocks.
3011
3012         * heap/BlockAllocator.h:
3013         (JSC::Region::isCustomSize): 
3014         (Region):
3015         (JSC::Region::createCustomSize):
3016         (JSC::Region::Region):
3017         (JSC::BlockAllocator::deallocateCustomSize):
3018         * heap/CopiedBlock.h:
3019         (CopiedBlock):
3020         (JSC::CopiedBlock::isOversize): 
3021         (JSC):
3022         * heap/CopiedSpace.cpp:
3023         (JSC::CopiedSpace::tryAllocateOversize):
3024         (JSC::CopiedSpace::tryReallocate):
3025         (JSC::CopiedSpace::tryReallocateOversize):
3026         * heap/CopiedSpace.h:
3027         (CopiedSpace): 
3028         * heap/CopiedSpaceInlines.h:
3029         (JSC::CopiedSpace::contains):
3030         (JSC::CopiedSpace::tryAllocate):
3031         (JSC):
3032         * heap/CopyVisitor.h:
3033         (CopyVisitor):
3034         * heap/CopyVisitorInlines.h:
3035         (JSC::CopyVisitor::checkIfShouldCopy):
3036         (JSC::CopyVisitor::didCopy):
3037         * heap/SlotVisitorInlines.h:
3038         (JSC::SlotVisitor::copyLater):
3039         * runtime/JSObject.cpp:
3040         (JSC::JSObject::copyButterfly):
3041
3042 2012-12-18  Joseph Pecoraro  <pecoraro@apple.com>
3043
3044         [Mac] Add Build Phase to Check Headers for Inappropriate Macros (Platform.h macros)
3045         https://bugs.webkit.org/show_bug.cgi?id=104279
3046
3047         Reviewed by David Kilzer.
3048
3049         Add a build phase to check the public JavaScriptCore headers for
3050         inappropriate macros.
3051
3052         * JavaScriptCore.xcodeproj/project.pbxproj:
3053
3054 2012-12-18  Michael Saboff  <msaboff@apple.com>
3055
3056         [Qt] Fix the ARMv7 build after r137976
3057         https://bugs.webkit.org/show_bug.cgi?id=105270
3058
3059         Reviewed by Csaba Osztrogonác.
3060
3061         Add default value for Jump parameter to fix build.
3062
3063         * assembler/AbstractMacroAssembler.h:
3064         (JSC::AbstractMacroAssembler::Jump::Jump):
3065
3066 2012-12-17  Geoffrey Garen  <ggaren@apple.com>
3067
3068         Constant fold !{number} in the parser
3069         https://bugs.webkit.org/show_bug.cgi?id=105232
3070
3071         Reviewed by Filip Pizlo.
3072
3073         Typically, we wait for hot execution and constant fold in the DFG.
3074         However, !0 and !1 are common enough in minifiers that it can be good
3075         to get them out of the way early, for faster/smaller parsing and startup.
3076
3077         * parser/ASTBuilder.h:
3078         (JSC::ASTBuilder::createLogicalNot): !{literal} is super simple, especially
3079         since there's no literal form of NaN or Inf.
3080
3081 2012-12-17  Filip Pizlo  <fpizlo@apple.com>
3082
3083         DFG is too aggressive eliding overflow checks for additions involving large constants
3084         https://bugs.webkit.org/show_bug.cgi?id=105239
3085
3086         Reviewed by Gavin Barraclough.
3087
3088         If we elide overflow checks on an addition (or subtraction) involving a larger-than-2^32 immediate,
3089         then make sure that the non-constant child of the addition knows that he's got to do an overflow
3090         check, by flowing the UsedAsNumber property at him.
3091
3092         * dfg/DFGGraph.h:
3093         (JSC::DFG::Graph::addSpeculationMode):
3094         (Graph):
3095         (JSC::DFG::Graph::addShouldSpeculateInteger):
3096         (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
3097         * dfg/DFGPredictionPropagationPhase.cpp:
3098         (JSC::DFG::PredictionPropagationPhase::propagate):
3099
3100 2012-12-17  Michael Saboff  <msaboff@apple.com>
3101
3102         DFG: Refactor DFGCorrectableJumpPoint to reduce size of OSRExit data
3103         https://bugs.webkit.org/show_bug.cgi?id=105237
3104
3105         Reviewed by Filip Pizlo.
3106
3107         Replaced DFGCorrectableJumpPoint with OSRExitCompilationInfo which is used and kept alive only while we are
3108         compiling in the DFG.  Moved the patchable branch offset directly into OSRExit.
3109
3110         * CMakeLists.txt:
3111         * GNUmakefile.list.am:
3112         * JavaScriptCore.xcodeproj/project.pbxproj:
3113         * Target.pri:
3114         * assembler/AbstractMacroAssembler.h:
3115         * dfg/DFGCorrectableJumpPoint.cpp: Removed.
3116         * dfg/DFGCorrectableJumpPoint.h: Removed.
3117         * dfg/DFGJITCompiler.cpp:
3118         (JSC::DFG::JITCompiler::linkOSRExits):
3119         (JSC::DFG::JITCompiler::link):
3120         * dfg/DFGJITCompiler.h:
3121         (JSC::DFG::JITCompiler::appendExitJump):
3122         (JITCompiler):
3123         * dfg/DFGOSRExit.cpp:
3124         (JSC::DFG::OSRExit::OSRExit):
3125         (JSC::DFG::OSRExit::setPatchableCodeOffset):
3126         (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump):
3127         (JSC::DFG::OSRExit::codeLocationForRepatch):
3128         (JSC::DFG::OSRExit::correctJump):
3129         * dfg/DFGOSRExit.h:
3130         (OSRExit):
3131         * dfg/DFGOSRExitCompilationInfo.h: Added.
3132         (OSRExitCompilationInfo):
3133         (JSC::DFG::OSRExitCompilationInfo::OSRExitCompilationInfo):
3134         (JSC::DFG::OSRExitCompilationInfo::failureJump):
3135         * dfg/DFGOSRExitCompiler.cpp:
3136         * dfg/DFGSpeculativeJIT.cpp:
3137         (JSC::DFG::SpeculativeJIT::speculationCheck):
3138         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
3139
3140 2012-12-17  Filip Pizlo  <fpizlo@apple.com>
3141
3142         DFG is too aggressive with eliding overflow checks in loops
3143         https://bugs.webkit.org/show_bug.cgi?id=105226
3144
3145         Reviewed by Mark Hahnenberg and Oliver Hunt.
3146
3147         If we see a variable's live range cross basic block boundaries, conservatively assume that it may
3148         be part of a data-flow back-edge, and as a result, we may have entirely integer operations that
3149         could lead to the creation of an integer that is out of range of 2^52 (the significand of a double
3150         float). This does not seem to regress any of the benchmarks we care about, and it fixes the bug.
3151         
3152         In future we may want to actually look at whether or not there was a data-flow back-edge instead
3153         of being super conservative about it. But we have no evidence, yet, that this would help us on
3154         real code.
3155
3156         * dfg/DFGNodeFlags.h:
3157         (DFG):
3158         * dfg/DFGPredictionPropagationPhase.cpp:
3159         (JSC::DFG::PredictionPropagationPhase::propagate):
3160
3161 2012-12-17  Mark Hahnenberg  <mhahnenberg@apple.com>
3162
3163         Butterfly::growArrayRight shouldn't be called on null Butterfly objects
3164         https://bugs.webkit.org/show_bug.cgi?id=105221
3165
3166         Reviewed by Filip Pizlo.
3167
3168         Currently we depend upon the fact that Butterfly::growArrayRight works with null Butterfly 
3169         objects purely by coincidence. We should add a new static function that null checks the old 
3170         Butterfly object and creates a new one if it's null, or calls growArrayRight if it isn't for 
3171         use in the couple of places in JSObject that expect such behavior to work.
3172
3173         * runtime/Butterfly.h:
3174         (Butterfly):
3175         * runtime/ButterflyInlines.h:
3176         (JSC::Butterfly::createOrGrowArrayRight):
3177         (JSC):
3178         * runtime/JSObject.cpp:
3179         (JSC::JSObject::createInitialIndexedStorage):
3180         (JSC::JSObject::createArrayStorage):
3181
3182 2012-12-17  Filip Pizlo  <fpizlo@apple.com>
3183
3184         javascript integer overflow
3185         https://bugs.webkit.org/show_bug.cgi?id=104967
3186
3187         Reviewed by Mark Hahnenberg.
3188
3189         Fix PutScopedVar backward flow.
3190
3191         * dfg/DFGPredictionPropagationPhase.cpp:
3192         (JSC::DFG::PredictionPropagationPhase::propagate):
3193
3194 2012-12-16  Filip Pizlo  <fpizlo@apple.com>
3195
3196         Rationalize array profiling for out-of-bounds and hole cases
3197         https://bugs.webkit.org/show_bug.cgi?id=105139
3198
3199         Reviewed by Geoffrey Garen.
3200
3201         This makes ArrayProfile track whether or not we had out-of-bounds, which allows
3202         for more precise decision-making in the DFG.
3203         
3204         Also cleaned up ExitKinds for out-of-bounds and hole cases to make it easier to
3205         look at them in the profiler.
3206         
3207         Slight speed-up (5-8%) on SunSpider/crypto-md5.
3208
3209         * bytecode/ArrayProfile.cpp:
3210         (JSC::ArrayProfile::computeUpdatedPrediction):
3211         (JSC::ArrayProfile::briefDescription):
3212         * bytecode/ArrayProfile.h:
3213         (JSC::ArrayProfile::ArrayProfile):
3214         (JSC::ArrayProfile::addressOfOutOfBounds):
3215         (JSC::ArrayProfile::expectedStructure):
3216         (JSC::ArrayProfile::structureIsPolymorphic):
3217         (JSC::ArrayProfile::outOfBounds):
3218         (JSC::ArrayProfile::polymorphicStructure):
3219         * bytecode/CodeBlock.cpp:
3220         (JSC::dumpChain):
3221         * bytecode/ExitKind.cpp:
3222         (JSC::exitKindToString):
3223         (JSC::exitKindIsCountable):
3224         * bytecode/ExitKind.h:
3225         * dfg/DFGByteCodeParser.cpp:
3226         (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
3227         * dfg/DFGSpeculativeJIT.cpp:
3228         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
3229         * dfg/DFGSpeculativeJIT32_64.cpp:
3230         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
3231         (JSC::DFG::SpeculativeJIT::compile):
3232         * dfg/DFGSpeculativeJIT64.cpp:
3233         (JSC::DFG::SpeculativeJIT::compile):
3234         * jit/JIT.h:
3235         * jit/JITInlines.h:
3236         (JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase):
3237         * jit/JITPropertyAccess.cpp:
3238         (JSC::JIT::emitSlow_op_get_by_val):
3239         (JSC::JIT::emitSlow_op_put_by_val):
3240         * jit/JITPropertyAccess32_64.cpp:
3241         (JSC::JIT::emitSlow_op_get_by_val):
3242         (JSC::JIT::emitSlow_op_put_by_val):
3243         * llint/LowLevelInterpreter32_64.asm:
3244         * llint/LowLevelInterpreter64.asm:
3245
3246 2012-12-17  Balazs Kilvady  <kilvadyb@homejinni.com>
3247
3248         Implement add64 for MIPS assembler after r136601
3249         https://bugs.webkit.org/show_bug.cgi?id=104106
3250
3251         Reviewed by Zoltan Herczeg.
3252
3253         Added add64 function to MacroAssebler of MIPS.
3254
3255         * assembler/MacroAssemblerMIPS.h:
3256         (JSC::MacroAssemblerMIPS::add32):
3257         (JSC::MacroAssemblerMIPS::add64):
3258         (MacroAssemblerMIPS):
3259
3260 2012-12-17  Jonathan Liu  <net147@gmail.com>
3261
3262         Fix Math.pow implementation with MinGW-w64
3263         https://bugs.webkit.org/show_bug.cgi?id=105087
3264
3265         Reviewed by Simon Hausmann.
3266
3267         The MinGW-w64 runtime has different behaviour for pow()
3268         compared to other C runtimes. This results in the following
3269         test262 tests failing with the latest MinGW-w64 runtime:
3270         - S15.8.2.13_A14
3271         - S15.8.2.13_A16
3272         - S15.8.2.13_A20
3273         - S15.8.2.13_A22
3274
3275         Handle the special cases that are different with MinGW-w64.
3276
3277         * runtime/MathObject.cpp:
3278         (JSC::mathPow):
3279
3280 2012-12-16  Filip Pizlo  <fpizlo@apple.com>
3281
3282         Bytecode dumping should show rare case profiles
3283         https://bugs.webkit.org/show_bug.cgi?id=105133
3284
3285         Reviewed by Geoffrey Garen.
3286
3287         Refactored the dumper to call dumpBytecodeCommandAndNewLine in just one place,
3288         rather than in all of the places. Changed the rare case profile getters to use
3289         tryBinarySearch rather than binarySearch, so that they can be used speculatively
3290         even if you don't know that the bytecode has rare case profiles. This actually
3291         increases our assertion level, since it means that in release builds we will get
3292         null and crash rather than getting some random adjacent profile. And then this
3293         adds some printing of the rare case profiles.
3294
3295         * bytecode/CodeBlock.cpp:
3296         (JSC::CodeBlock::printUnaryOp):
3297         (JSC::CodeBlock::printBinaryOp):
3298         (JSC::CodeBlock::printConditionalJump):
3299         (JSC::CodeBlock::printCallOp):
3300         (JSC::CodeBlock::printPutByIdOp):
3301         (JSC::CodeBlock::beginDumpProfiling):
3302         (JSC):
3303         (JSC::CodeBlock::dumpValueProfiling):
3304         (JSC::CodeBlock::dumpArrayProfiling):
3305         (JSC::CodeBlock::dumpRareCaseProfile):
3306         (JSC::CodeBlock::dumpBytecode):
3307         * bytecode/CodeBlock.h:
3308         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
3309         (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset):
3310
3311 2012-12-13  Filip Pizlo  <fpizlo@apple.com>
3312
3313         Attempt to rationalize and simplify WTF::binarySearch
3314         https://bugs.webkit.org/show_bug.cgi?id=104890
3315
3316         Reviewed by Maciej Stachowiak.
3317
3318         Switch to using the new binarySearch() API. No change in behavior.
3319
3320         * bytecode/CodeBlock.cpp:
3321         (JSC::CodeBlock::bytecodeOffset):
3322         (JSC::CodeBlock::codeOriginForReturn):
3323         * bytecode/CodeBlock.h:
3324         (JSC::CodeBlock::getStubInfo):
3325         (JSC::CodeBlock::getByValInfo):
3326         (JSC::CodeBlock::getCallLinkInfo):
3327         (JSC::CodeBlock::dfgOSREntryDataForBytecodeIndex):
3328         (JSC::CodeBlock::valueProfileForBytecodeOffset):
3329         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
3330         (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset):
3331         * dfg/DFGGraph.h:
3332         (JSC::DFG::Graph::blockIndexForBytecodeOffset):
3333         * dfg/DFGMinifiedGraph.h:
3334         (JSC::DFG::MinifiedGraph::at):
3335         * dfg/DFGOSRExitCompiler32_64.cpp:
3336         (JSC::DFG::OSRExitCompiler::compileExit):
3337         * dfg/DFGOSRExitCompiler64.cpp:
3338         (JSC::DFG::OSRExitCompiler::compileExit):
3339         * llint/LLIntSlowPaths.cpp:
3340         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3341         * profiler/ProfilerBytecodeSequence.cpp:
3342         (JSC::Profiler::BytecodeSequence::indexForBytecodeIndex):
3343
3344 2012-12-13  Filip Pizlo  <fpizlo@apple.com>
3345
3346         Don't assert that flags <= 0x3ff in JSTypeInfo
3347         https://bugs.webkit.org/show_bug.cgi?id=104988
3348
3349         Reviewed by Sam Weinig.
3350
3351         This assertion doesn't accomplish anything other than crashes.
3352
3353         * runtime/JSTypeInfo.h:
3354         (JSC::TypeInfo::TypeInfo):
3355
3356 2012-12-13  Filip Pizlo  <fpizlo@apple.com>
3357