Unreviewed. More VS2010 solution makefile fixes.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-04-05  Roger Fong  <roger_fong@apple.com>
2
3         More VS2010 solution makefile fixes.
4         <rdar://problem/13588964>
5
6         * JavaScriptCore.vcxproj/JavaScriptCore.make:
7
8 2013-04-05  Allan Sandfeld Jensen  <allan.jensen@digia.com>
9
10         LLint should be able to use x87 instead of SSE for floating pointer
11
12         https://bugs.webkit.org/show_bug.cgi?id=112239
13
14         Reviewed by Filip Pizlo.
15
16         Implements LLInt floating point operations in x87, to ensure we support
17         x86 without SSE2.
18
19         X86 (except 64bit) now defaults to using x87 instructions in order to
20         support all 32bit x86 back to i686. The implementation uses the fucomi
21         instruction from i686 which sets the new minimum.
22
23         * offlineasm/x86.rb:
24
25 2013-04-04  Christophe Dumez  <ch.dumez@sisa.samsung.com>
26
27         Unreviewed EFL build fix.
28
29         We had undefined reference to `JSC::CodeOrigin::maximumBytecodeIndex'.
30
31         * bytecode/CodeBlock.cpp:
32         (JSC::CodeBlock::findClosureCallForReturnPC):
33         (JSC::CodeBlock::bytecodeOffset):
34
35 2013-04-04  Geoffrey Garen  <ggaren@apple.com>
36
37         Stop pretending that statements return a value
38         https://bugs.webkit.org/show_bug.cgi?id=113969
39
40         Reviewed by Oliver Hunt.
41
42         Expressions have an intrinsic value, which they return to their parent
43         in the AST.
44
45         Statements just execute for effect in sequence.
46
47         This patch moves emitBytecode into the ExpressionNode and StatementNode
48         subclasses, and changes the SatementNode subclass to return void. This
49         eliminates some cruft where we used to return 0, or try to save a bogus
50         register and return it, as if a statement had a consuming parent in the
51         AST.
52
53         * bytecompiler/BytecodeGenerator.h:
54         (JSC::BytecodeGenerator::emitNode):
55         (BytecodeGenerator):
56         (JSC::BytecodeGenerator::emitNodeInConditionContext):
57         * bytecompiler/NodesCodegen.cpp:
58         (JSC::ConstStatementNode::emitBytecode):
59         (JSC::BlockNode::emitBytecode):
60         (JSC::EmptyStatementNode::emitBytecode):
61         (JSC::DebuggerStatementNode::emitBytecode):
62         (JSC::ExprStatementNode::emitBytecode):
63         (JSC::VarStatementNode::emitBytecode):
64         (JSC::IfNode::emitBytecode):
65         (JSC::IfElseNode::emitBytecode):
66         (JSC::DoWhileNode::emitBytecode):
67         (JSC::WhileNode::emitBytecode):
68         (JSC::ForNode::emitBytecode):
69         (JSC::ForInNode::emitBytecode):
70         (JSC::ContinueNode::emitBytecode):
71         (JSC::BreakNode::emitBytecode):
72         (JSC::ReturnNode::emitBytecode):
73         (JSC::WithNode::emitBytecode):
74         (JSC::CaseClauseNode::emitBytecode):
75         (JSC::CaseBlockNode::emitBytecodeForBlock):
76         (JSC::SwitchNode::emitBytecode):
77         (JSC::LabelNode::emitBytecode):
78         (JSC::ThrowNode::emitBytecode):
79         (JSC::TryNode::emitBytecode):
80         (JSC::ScopeNode::emitStatementsBytecode):
81         (JSC::ProgramNode::emitBytecode):
82         (JSC::EvalNode::emitBytecode):
83         (JSC::FunctionBodyNode::emitBytecode):
84         (JSC::FuncDeclNode::emitBytecode):
85         * parser/NodeConstructors.h:
86         (JSC::PropertyListNode::PropertyListNode):
87         (JSC::ArgumentListNode::ArgumentListNode):
88         * parser/Nodes.h:
89         (Node):
90         (ExpressionNode):
91         (StatementNode):
92         (ConstStatementNode):
93         (BlockNode):
94         (EmptyStatementNode):
95         (DebuggerStatementNode):
96         (ExprStatementNode):
97         (VarStatementNode):
98         (IfNode):
99         (IfElseNode):
100         (DoWhileNode):
101         (WhileNode):
102         (ForNode):
103         (ForInNode):
104         (ContinueNode):
105         (BreakNode):
106         (ReturnNode):
107         (WithNode):
108         (LabelNode):
109         (ThrowNode):
110         (TryNode):
111         (ProgramNode):
112         (EvalNode):
113         (FunctionBodyNode):
114         (FuncDeclNode):
115         (CaseBlockNode):
116         (SwitchNode):
117
118 2013-04-04  Oliver Hunt  <oliver@apple.com>
119
120         Exception stack unwinding doesn't handle inline callframes correctly
121         https://bugs.webkit.org/show_bug.cgi?id=113952
122
123         Reviewed by Geoffrey Garen.
124
125         The basic problem here is that the exception stack unwinding was
126         attempting to be "clever" and avoid doing a correct stack walk
127         as it "knew" inline callframes couldn't have exception handlers.
128
129         This used to be safe as the exception handling machinery was
130         designed to fail gently and just claim that no handler existed.
131         This was "safe" and even "correct" inasmuch as we currently
132         don't run any code with exception handlers through the dfg.
133
134         This patch fixes the logic by simply making everything uniformly
135         use the safe stack walking machinery, and making the correct
136         boundary checks occur everywhere that they should.
137
138         * bytecode/CodeBlock.cpp:
139         (JSC::CodeBlock::findClosureCallForReturnPC):
140         (JSC::CodeBlock::bytecodeOffset):
141         * interpreter/Interpreter.cpp:
142         (JSC):
143         (JSC::Interpreter::dumpRegisters):
144         (JSC::Interpreter::unwindCallFrame):
145         (JSC::getCallerInfo):
146         (JSC::Interpreter::getStackTrace):
147         (JSC::Interpreter::retrieveCallerFromVMCode):
148
149 2013-04-04  Geoffrey Garen  <ggaren@apple.com>
150
151         Removed a defunct comment
152         https://bugs.webkit.org/show_bug.cgi?id=113948
153
154         Reviewed by Oliver Hunt.
155
156         This is also a convenient way to test the EWS.
157
158         * bytecompiler/BytecodeGenerator.cpp:
159         (JSC):
160
161 2013-04-04  Martin Robinson  <mrobinson@igalia.com>
162
163         [GTK] Remove the gyp build
164         https://bugs.webkit.org/show_bug.cgi?id=113942
165
166         Reviewed by Gustavo Noronha Silva.
167
168         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Removed.
169         * JavaScriptCore.gyp/redirect-stdout.sh: Removed.
170
171 2013-04-04  Geoffrey Garen  <ggaren@apple.com>
172
173         Simplified bytecode generation by merging prefix and postfix nodes
174         https://bugs.webkit.org/show_bug.cgi?id=113925
175
176         Reviewed by Filip Pizlo.
177
178         PostfixNode now inherits from PrefixNode, so when we detect that we're
179         in a context where postifx and prefix are equivalent, PostFixNode can
180         just call through to PrefixNode codegen, instead of duplicating the
181         logic.
182
183         * bytecompiler/NodesCodegen.cpp:
184         (JSC::PostfixNode::emitResolve):
185         (JSC::PostfixNode::emitBracket):
186         (JSC::PostfixNode::emitDot):
187         * parser/NodeConstructors.h:
188         (JSC::PostfixNode::PostfixNode):
189         * parser/Nodes.h:
190         (JSC):
191         (PrefixNode):
192         (PostfixNode):
193
194 2013-04-04  Andras Becsi  <andras.becsi@digia.com>
195
196         Fix the build with GCC 4.8
197         https://bugs.webkit.org/show_bug.cgi?id=113147
198
199         Reviewed by Allan Sandfeld Jensen.
200
201         Initialize JSObject* exception to suppress warnings that make
202         the build fail because of -Werror=maybe-uninitialized.
203
204         * runtime/Executable.cpp:
205         (JSC::FunctionExecutable::compileForCallInternal):
206         (JSC::FunctionExecutable::compileForConstructInternal):
207
208 2013-04-02  Mark Hahnenberg  <mhahnenberg@apple.com>
209
210         get_by_pname can become confused when iterating over objects with static properties
211         https://bugs.webkit.org/show_bug.cgi?id=113831
212
213         Reviewed by Geoffrey Garen.
214
215         get_by_pname doesn't take static properties into account when using a JSPropertyNameIterator to directly 
216         access an object's backing store. One way to fix this is to not cache any properties when iterating over 
217         objects with static properties. This patch fixes the bug that was originally reported on swisscom.ch.
218
219         * runtime/JSObject.cpp:
220         (JSC::JSObject::getOwnNonIndexPropertyNames):
221         * runtime/JSPropertyNameIterator.cpp:
222         (JSC::JSPropertyNameIterator::create):
223         * runtime/PropertyNameArray.h:
224         (JSC::PropertyNameArray::PropertyNameArray):
225         (JSC::PropertyNameArray::numCacheableSlots):
226         (JSC::PropertyNameArray::setNumCacheableSlots):
227         (PropertyNameArray):
228
229 2013-04-02  Geoffrey Garen  <ggaren@apple.com>
230
231         DFG should compile a little sooner
232         https://bugs.webkit.org/show_bug.cgi?id=113835
233
234         Unreviewed.
235
236         Rolled out r147511 because it was based on incorrect performance
237         measurement.
238
239         * bytecode/CodeBlock.cpp:
240         (JSC::CodeBlock::optimizationThresholdScalingFactor):
241
242 2013-04-02  Geoffrey Garen  <ggaren@apple.com>
243
244         DFG should compile a little sooner
245         https://bugs.webkit.org/show_bug.cgi?id=113835
246
247         Reviewed by Michael Saboff.
248
249         2% speedup on SunSpider.
250
251         2% speedup on JSRegress.
252
253         Neutral on Octane, v8, and Kraken.
254
255         The worst-hit single sub-test is kraken-stanford-crypto-ccm.js, which gets
256         18% slower. Since Kraken is neutral overall in its preferred mean, I
257         think that's OK for now.
258
259         (Our array indexing speculation fails pathologically on
260         kraken-stanford-crypto-ccm.js. Compiling sooner is a regression because
261         it triggers those failures sooner. I'm going to file some follow-up bugs
262         explaining how to fix our speculations on this sub-test, at which point
263         compiling earlier should become a slight speedup on Kraken overall.)
264
265         * bytecode/CodeBlock.cpp:
266         (JSC::CodeBlock::optimizationThresholdScalingFactor): I experimented
267         with a few different options, including reducing the coefficient 'a'.
268         A simple linear reduction on instruction count worked best.
269
270 2013-04-01  Benjamin Poulain  <benjamin@webkit.org>
271
272         Use Vector::reserveInitialCapacity and Vector::uncheckedAppend for JSC's APIs
273         https://bugs.webkit.org/show_bug.cgi?id=113651
274
275         Reviewed by Andreas Kling.
276
277         This removes a bunch of branches on initialization and when
278         filling the vector.
279
280         * API/JSCallbackConstructor.cpp:
281         (JSC::constructJSCallback):
282         * API/JSCallbackFunction.cpp:
283         (JSC::JSCallbackFunction::call):
284         * API/JSCallbackObjectFunctions.h:
285         (JSC::::construct):
286         (JSC::::call):
287         * API/JSObjectRef.cpp:
288         (JSObjectCopyPropertyNames):
289
290 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
291
292         Fixing borked VS 2010 project file
293
294         Unreviewed bot greening.
295
296         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
297         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
298
299 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
300
301         One more Windows build fix
302
303         Unreviewed.
304
305         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
306
307 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
308
309         More build fallout fixes.
310
311         Unreviewed build fix.
312
313         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add new export symbols.
314         * heap/SuperRegion.cpp: Windows didn't like "LLU". 
315
316 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
317
318         r147324 broke the world
319         https://bugs.webkit.org/show_bug.cgi?id=113704
320
321         Unreviewed build fix.
322
323         Remove a bunch of unused variables and use the correctly sized types for 32-bit platforms.
324
325         * heap/BlockAllocator.cpp:
326         (JSC::BlockAllocator::BlockAllocator):
327         * heap/BlockAllocator.h:
328         (BlockAllocator):
329         * heap/Heap.cpp:
330         (JSC::Heap::Heap):
331         * heap/SuperRegion.cpp:
332         (JSC::SuperRegion::SuperRegion):
333         * heap/SuperRegion.h:
334         (SuperRegion):
335
336 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
337
338         32-bit Windows build fix
339
340         Unreviewed build fix.
341
342         * heap/SuperRegion.cpp:
343         * heap/SuperRegion.h: Use uint64_t instead of size_t.
344         (SuperRegion):
345
346 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
347
348         EFL build fix
349
350         Unreviewed build fix.
351
352         * CMakeLists.txt:
353
354 2013-03-31  Mark Hahnenberg  <mhahnenberg@apple.com>
355
356         Regions should be allocated from the same contiguous segment of virtual memory
357         https://bugs.webkit.org/show_bug.cgi?id=113662
358
359         Reviewed by Filip Pizlo.
360
361         Instead of letting the OS spread our Regions all over the place, we should allocate them all within 
362         some range of each other. This change will open the door to some other optimizations, e.g. doing simple 
363         range checks for our write barriers and compressing JSCell pointers to 32-bits.
364
365         Added new SuperRegion class that encapsulates allocating Regions from a contiguous reserved chunk of 
366         virtual address space. It functions very similarly to the FixedVMPoolExecutableAllocator class used by the JIT.
367
368         Also added two new subclasses of Region, NormalRegion and ExcessRegion. 
369         
370         NormalRegion is the type of Region that is normally allocated when there is available space remaining 
371         in the SuperRegion. If we ever run out of space in the SuperRegion, we fall back to allocating 
372         ExcessRegions, which are identical to how Regions have behaved up until now, i.e. they contain a 
373         PageAllocationAligned.
374
375         We only use the SuperRegion (and NormalRegions) on 64-bit systems, since it doesn't make sense to reserve the 
376         entire 4 GB address space on 32-bit systems just for the JS heap.
377
378         * GNUmakefile.list.am:
379         * JavaScriptCore.gypi:
380         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
381         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
382         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
383         * JavaScriptCore.xcodeproj/project.pbxproj:
384         * Target.pri:
385         * heap/BlockAllocator.cpp:
386         (JSC::BlockAllocator::BlockAllocator):
387         * heap/BlockAllocator.h:
388         (JSC):
389         (BlockAllocator):
390         (JSC::BlockAllocator::allocate):
391         (JSC::BlockAllocator::allocateCustomSize):
392         (JSC::BlockAllocator::deallocateCustomSize):
393         * heap/Heap.cpp:
394         (JSC::Heap::Heap):
395         (JSC):
396         (JSC::Heap::didExceedFixedHeapSizeLimit):
397         * heap/Heap.h:
398         (Heap):
399         * heap/MarkedBlock.cpp:
400         (JSC::MarkedBlock::create):
401         * heap/Region.h:
402         (Region):
403         (JSC):
404         (NormalRegion):
405         (JSC::NormalRegion::base):
406         (JSC::NormalRegion::size):
407         (ExcessRegion):
408         (JSC::ExcessRegion::base):
409         (JSC::ExcessRegion::size):
410         (JSC::NormalRegion::NormalRegion):
411         (JSC::NormalRegion::tryCreate):
412         (JSC::NormalRegion::tryCreateCustomSize):
413         (JSC::NormalRegion::reset):
414         (JSC::ExcessRegion::ExcessRegion):
415         (JSC::ExcessRegion::~ExcessRegion):
416         (JSC::ExcessRegion::create):
417         (JSC::ExcessRegion::createCustomSize):
418         (JSC::ExcessRegion::reset):
419         (JSC::Region::Region):
420         (JSC::Region::initializeBlockList):
421         (JSC::Region::create):
422         (JSC::Region::createCustomSize):
423         (JSC::Region::~Region):
424         (JSC::Region::destroy):
425         (JSC::Region::reset):
426         (JSC::Region::deallocate):
427         (JSC::Region::base):
428         (JSC::Region::size):
429         * heap/SuperRegion.cpp: Added.
430         (JSC):
431         (JSC::SuperRegion::SuperRegion):
432         (JSC::SuperRegion::getAlignedBase):
433         (JSC::SuperRegion::allocateNewSpace):
434         (JSC::SuperRegion::notifyNeedPage):
435         (JSC::SuperRegion::notifyPageIsFree):
436         * heap/SuperRegion.h: Added.
437         (JSC):
438         (SuperRegion):
439
440 2013-04-01  Benjamin Poulain  <benjamin@webkit.org>
441
442         Remove an unused variable from the ARMv7 Assembler
443         https://bugs.webkit.org/show_bug.cgi?id=113653
444
445         Reviewed by Andreas Kling.
446
447         * assembler/ARMv7Assembler.h:
448         (ARMv7Assembler):
449
450 2013-03-31  Adam Barth  <abarth@webkit.org>
451
452         [Chromium] Yarr should build using a separate GYP file from JavaScriptCore
453         https://bugs.webkit.org/show_bug.cgi?id=113652
454
455         Reviewed by Nico Weber.
456
457         This patch moves JavaScriptCore.gyp to yarr.gyp because Chromium only
458         uses this GYP file to build yarr.
459
460         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp:
461         * JavaScriptCore.gypi:
462         * yarr/yarr.gyp: Renamed from Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCore.gyp.
463
464 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
465
466         Unreviewed, fix a comment. While thinking about TBAA for array accesses,
467         I realized that we have to be super careful about aliasing of typed arrays.
468
469         * dfg/DFGCSEPhase.cpp:
470         (JSC::DFG::CSEPhase::getByValLoadElimination):
471
472 2013-03-30  Mark Hahnenberg  <mhahnenberg@apple.com>
473
474         Move Region into its own header
475         https://bugs.webkit.org/show_bug.cgi?id=113617
476
477         Reviewed by Geoffrey Garen.
478
479         BlockAllocator.h is getting a little crowded. We should move the Region class into its own 
480         header, since it's pretty independent from the BlockAllocator.
481
482         * GNUmakefile.list.am:
483         * JavaScriptCore.gypi:
484         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
485         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
486         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
487         * JavaScriptCore.xcodeproj/project.pbxproj:
488         * heap/BlockAllocator.h:
489         (JSC):
490         * heap/Region.h: Added.
491         (JSC):
492         (DeadBlock):
493         (JSC::DeadBlock::DeadBlock):
494         (Region):
495         (JSC::Region::blockSize):
496         (JSC::Region::isFull):
497         (JSC::Region::isEmpty):
498         (JSC::Region::isCustomSize):
499         (JSC::Region::create):
500         (JSC::Region::createCustomSize):
501         (JSC::Region::Region):
502         (JSC::Region::~Region):
503         (JSC::Region::reset):
504         (JSC::Region::allocate):
505         (JSC::Region::deallocate):
506
507 2013-03-29  Mark Hahnenberg  <mhahnenberg@apple.com>
508
509         Objective-C API: Remove -[JSManagedValue managedValueWithValue:owner:]
510         https://bugs.webkit.org/show_bug.cgi?id=113602
511
512         Reviewed by Geoffrey Garen.
513
514         Since we put the primary way of keeping track of external object graphs (i.e. "managed" references) 
515         in JSVirtualMachine, there is some overlap in the functionality of that interface and JSManagedValue.
516         Specifically, we no longer need the methods that include an owner, since ownership is now tracked 
517         by JSVirtualMachine. These JSManagedValues will become weak pointers unless they are used 
518         with [JSVirtualMachine addManagedReference:withOwner:], in which case their lifetime is tied to that 
519         of their owner.
520
521         * API/JSManagedValue.h:
522         * API/JSManagedValue.mm:
523         (-[JSManagedValue init]):
524         (-[JSManagedValue initWithValue:]):
525         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
526         * API/JSVirtualMachine.mm:
527         (getInternalObjcObject):
528         * API/tests/testapi.mm:
529         (-[TextXYZ setOnclick:]):
530         (-[TextXYZ dealloc]):
531
532 2013-03-29  Geoffrey Garen  <ggaren@apple.com>
533
534         Simplified bytecode generation by unforking "condition context" codegen
535         https://bugs.webkit.org/show_bug.cgi?id=113554
536
537         Reviewed by Mark Hahnenberg.
538
539         Now, a node that establishes a condition context can always ask its child
540         nodes to generate into that context.
541
542         This has a few advantages:
543
544         (*) Removes a bunch of code;
545
546         (*) Optimizes a few missed cases like "if (!(x < 2))", "if (!!x)", and
547         "if (!x || !y)";
548
549         (*) Paves the way to removing more opcodes.
550
551         * bytecode/Opcode.h:
552         (JSC): Separated out the branching opcodes for clarity.
553         * bytecompiler/NodesCodegen.cpp:
554         (JSC::ExpressionNode::emitBytecodeInConditionContext): All expressions
555         can be emitted in a condition context now -- the default behavior is
556         to branch based on the expression's value.
557
558         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
559         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
560         (JSC::ConditionalNode::emitBytecode):
561         (JSC::IfNode::emitBytecode):
562         (JSC::IfElseNode::emitBytecode):
563         (JSC::DoWhileNode::emitBytecode):
564         (JSC::WhileNode::emitBytecode):
565         (JSC::ForNode::emitBytecode):
566         * parser/Nodes.h:
567         (JSC::ExpressionNode::isSubtract):
568         (ExpressionNode):
569         (LogicalNotNode):
570         (LogicalOpNode): Removed lots of code for handling expressions
571         that couldn't generate into a condition context because all expressions
572         can now.
573
574 2013-03-28  Geoffrey Garen  <ggaren@apple.com>
575
576         Simplified the bytecode by removing op_loop and op_loop_if_*
577         https://bugs.webkit.org/show_bug.cgi?id=113548
578
579         Reviewed by Filip Pizlo.
580
581         Regular jumps will suffice.
582
583         These opcodes are identical to branches, except they also do timeout
584         checking. That style of timeout checking has been broken for a long 
585         time, and when we add back timeout checking, it won't use these opcodes.
586
587         * JavaScriptCore.order:
588         * bytecode/CodeBlock.cpp:
589         (JSC::CodeBlock::dumpBytecode):
590         * bytecode/Opcode.h:
591         (JSC):
592         (JSC::padOpcodeName):
593         * bytecode/PreciseJumpTargets.cpp:
594         (JSC::computePreciseJumpTargets):
595         * bytecompiler/BytecodeGenerator.cpp:
596         (JSC::BytecodeGenerator::emitJump):
597         (JSC::BytecodeGenerator::emitJumpIfTrue):
598         (JSC::BytecodeGenerator::emitJumpIfFalse):
599         * dfg/DFGByteCodeParser.cpp:
600         (JSC::DFG::ByteCodeParser::parseBlock):
601         * dfg/DFGCapabilities.h:
602         (JSC::DFG::canCompileOpcode):
603         * jit/JIT.cpp:
604         (JSC::JIT::privateCompileMainPass):
605         (JSC::JIT::privateCompileSlowCases):
606         * jit/JIT.h:
607         (JIT):
608         (JSC):
609         * llint/LowLevelInterpreter.asm:
610         * llint/LowLevelInterpreter32_64.asm:
611         * llint/LowLevelInterpreter64.asm:
612
613 2013-03-28  Geoffrey Garen  <ggaren@apple.com>
614
615         Simplified the bytecode by removing op_jmp_scopes
616         https://bugs.webkit.org/show_bug.cgi?id=113545
617
618         Reviewed by Filip Pizlo.
619
620         We already have op_pop_scope and op_jmp, so we don't need op_jmp_scopes.
621         Using op_jmp_scopes was also adding a "jump to self" to codegen for
622         return statements, which was pretty silly.
623
624         * JavaScriptCore.order:
625         * bytecode/CodeBlock.cpp:
626         (JSC::CodeBlock::dumpBytecode):
627         * bytecode/Opcode.h:
628         (JSC::padOpcodeName):
629         * bytecode/PreciseJumpTargets.cpp:
630         (JSC::computePreciseJumpTargets):
631         * bytecompiler/BytecodeGenerator.cpp:
632         (JSC::BytecodeGenerator::emitComplexPopScopes):
633         (JSC::BytecodeGenerator::emitPopScopes):
634         * bytecompiler/BytecodeGenerator.h:
635         (BytecodeGenerator):
636         * bytecompiler/NodesCodegen.cpp:
637         (JSC::ContinueNode::emitBytecode):
638         (JSC::BreakNode::emitBytecode):
639         (JSC::ReturnNode::emitBytecode):
640         * jit/JIT.cpp:
641         (JSC::JIT::privateCompileMainPass):
642         * jit/JIT.h:
643         * jit/JITOpcodes.cpp:
644         * jit/JITOpcodes32_64.cpp:
645         * jit/JITStubs.cpp:
646         * jit/JITStubs.h:
647         * llint/LLIntSlowPaths.cpp:
648         * llint/LLIntSlowPaths.h:
649         * llint/LowLevelInterpreter.asm:
650
651 2013-03-28  Mark Hahnenberg  <mhahnenberg@apple.com>
652
653         Safari hangs during test262 run in CodeCache::pruneSlowCase
654         https://bugs.webkit.org/show_bug.cgi?id=113469
655
656         Reviewed by Geoffrey Garen.
657
658         We can end up hanging for quite some time if we add a lot of small keys to the CodeCache.
659         By the time we get around to pruning the cache, we have a potentially tens or hundreds of 
660         thousands of small entries, which can cause a noticeable hang when pruning them.
661
662         To fix this issue we added a hard cap to the number of entries in the cache because we 
663         could potentially have to remove every element in the map.
664
665         * runtime/CodeCache.cpp:
666         (JSC::CodeCacheMap::pruneSlowCase): We need to prune until we're both under the hard cap and the
667         capacity in bytes.
668         * runtime/CodeCache.h:
669         (CodeCacheMap):
670         (JSC::CodeCacheMap::numberOfEntries): Convenience accessor function to the number of entries in 
671         the map that does the cast to size_t of m_map.size() for us. 
672         (JSC::CodeCacheMap::canPruneQuickly): Checks that the total number is under the hard cap. We put this 
673         check inside a function to more accurately describe why we're doing the check and to abstract out 
674         the actual calculation in case we want to coalesce calls to pruneSlowCase in the future.
675         (JSC::CodeCacheMap::prune): Check the number of entries against our hard cap. If it's greater than
676         the cap then we need to drop down to pruneSlowCase.
677
678 2013-03-28  Zan Dobersek  <zdobersek@igalia.com>
679
680         Unreviewed build fix for the EFL and GTK ports.
681
682         * runtime/CodeCache.cpp:
683         (JSC::CodeCacheMap::pruneSlowCase): Pass a 0 casted to the int64_t type instead of 0LL
684         to the std::max call so the arguments' types match.
685
686 2013-03-27  Geoffrey Garen  <ggaren@apple.com>
687
688         Unreviewed build fix: Removed a dead field.
689
690         Pointed out by Mark Lam.
691
692         * dfg/DFGByteCodeParser.cpp:
693         (JSC::DFG::ByteCodeParser::ByteCodeParser):
694         (ByteCodeParser):
695
696 2013-03-27  Geoffrey Garen  <ggaren@apple.com>
697
698         Unreviewed build fix: Removed a dead field.
699
700         * dfg/DFGByteCodeParser.cpp:
701         (JSC::DFG::ByteCodeParser::ByteCodeParser):
702         (ByteCodeParser):
703
704 2013-03-27  Geoffrey Garen  <ggaren@apple.com>
705
706         Removed some dead code in the DFG bytecode parser
707         https://bugs.webkit.org/show_bug.cgi?id=113472
708
709         Reviewed by Sam Weinig.
710
711         Now that Phi creation and liveness analysis are separate passes, we can
712         remove the vestiges of code that used to do that in the bytecode
713         parser.
714
715         * dfg/DFGByteCodeParser.cpp:
716         (ByteCodeParser):
717         (JSC::DFG::ByteCodeParser::addToGraph):
718         (JSC::DFG::ByteCodeParser::parse):
719
720 2013-03-27  Filip Pizlo  <fpizlo@apple.com>
721
722         JIT and DFG should NaN-check loads from Float32 arrays
723         https://bugs.webkit.org/show_bug.cgi?id=113462
724         <rdar://problem/13490804>
725
726         Reviewed by Mark Hahnenberg.
727
728         * dfg/DFGSpeculativeJIT.cpp:
729         (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
730         * jit/JITPropertyAccess.cpp:
731         (JSC::JIT::emitFloatTypedArrayGetByVal):
732
733 2013-03-27  Mark Hahnenberg  <mhahnenberg@apple.com>
734
735         CodeCache::m_capacity can becoming negative, producing undefined results in pruneSlowCase
736         https://bugs.webkit.org/show_bug.cgi?id=113453
737
738         Reviewed by Geoffrey Garen.
739
740         * runtime/CodeCache.cpp:
741         (JSC::CodeCacheMap::pruneSlowCase): We make sure that m_minCapacity doesn't drop below zero now.
742         This prevents m_capacity from doing the same.
743
744 2013-03-27  Filip Pizlo  <fpizlo@apple.com>
745
746         DFG should use CheckStructure for typed array checks whenever possible
747         https://bugs.webkit.org/show_bug.cgi?id=113374
748
749         Reviewed by Geoffrey Garen.
750         
751         We used to do the right thing, but it appears that this regressed at some point. Since the
752         FixupPhase now has the ability to outright remove spurious CheckStructures on array
753         operations, it is profitable for the ByteCodeParser to insert CheckStructures whenver there
754         is a chance that it might be profitable, and when the profiling tells us what structure to
755         check.
756         
757         Also added some code for doing ArrayProfile debugging.
758         
759         This is a slightly speed-up. Maybe 3% on Mandreel.
760
761         * bytecode/ArrayProfile.cpp:
762         (JSC::ArrayProfile::computeUpdatedPrediction):
763         * dfg/DFGArrayMode.h:
764         (JSC::DFG::ArrayMode::benefitsFromStructureCheck):
765
766 2013-03-27  Zeno Albisser  <zeno@webkit.org>
767
768         [Qt] Remove Qt specific WorkQueueItem definitions.
769         https://bugs.webkit.org/show_bug.cgi?id=112891
770
771         This patch is preparation work for removing
772         WorkQueue related code from TestRunnerQt and
773         replacing it with generic TestRunner code.
774
775         Reviewed by Benjamin Poulain.
776
777         * API/JSStringRefQt.cpp:
778         (JSStringCreateWithQString):
779             Adding a convenience function to create a
780             JSStringRef from a QString.
781         * API/JSStringRefQt.h:
782
783 2013-03-26  Filip Pizlo  <fpizlo@apple.com>
784
785         REGRESSION: Sometimes, operations on proven strings ignore changes to the string prototype
786         https://bugs.webkit.org/show_bug.cgi?id=113353
787         <rdar://problem/13510778>
788
789         Reviewed by Mark Hahnenberg and Geoffrey Garen.
790         
791         ToString should call speculateStringObject() even if you know that it's a string object, since
792         it calls it to also get the watchpoint. Note that even with this change, if you do
793         Phantom(Check:StringObject:@a), it might get eliminated just because we proved that @a is a
794         string object (thereby eliminating the prototype watchpoint); that's fine since ToString is
795         MustGenerate and never decays to Phantom.
796
797         * dfg/DFGSpeculativeJIT.cpp:
798         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
799         (JSC::DFG::SpeculativeJIT::speculateStringObject):
800         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
801         * dfg/DFGSpeculativeJIT.h:
802         (SpeculativeJIT):
803         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
804
805 2013-03-26  Mark Hahnenberg  <mhahnenberg@apple.com>
806
807         REGRESSION(r144131): It made fast/js/regress/string-repeat-arith.html assert on 32 bit
808         https://bugs.webkit.org/show_bug.cgi?id=112106
809
810         Rubber stamped by Filip Pizlo.
811
812         * dfg/DFGSpeculativeJIT.cpp:
813         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): Get rid of the case for constants because
814         we would have done constant folding anyways on a ValueToInt32.
815         * dfg/DFGSpeculativeJIT32_64.cpp:
816         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): Fixed a random compile error with this flag enabled.
817
818 2013-03-26  Filip Pizlo  <fpizlo@apple.com>
819
820         JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
821         https://bugs.webkit.org/show_bug.cgi?id=113144
822
823         Reviewed by Geoffrey Garen.
824         
825         Forgot to include Geoff's requested change in the original commit.
826
827         * profiler/ProfilerDatabase.cpp:
828         (Profiler):
829
830 2013-03-25  Filip Pizlo  <fpizlo@apple.com>
831
832         JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
833         https://bugs.webkit.org/show_bug.cgi?id=113144
834
835         Reviewed by Geoffrey Garen.
836         
837         Added the ability to save profiler output with JSC_enableProfiler=true. It will save it
838         to the current directory, or JSC_PROFILER_PATH if the latter was specified.
839         
840         This works by saving the Profiler::Database either when it is destroyed or atexit(),
841         whichever happens first.
842         
843         This allows use of the profiler from any WebKit client.
844
845         * jsc.cpp:
846         (jscmain):
847         * profiler/ProfilerDatabase.cpp:
848         (Profiler):
849         (JSC::Profiler::Database::Database):
850         (JSC::Profiler::Database::~Database):
851         (JSC::Profiler::Database::registerToSaveAtExit):
852         (JSC::Profiler::Database::addDatabaseToAtExit):
853         (JSC::Profiler::Database::removeDatabaseFromAtExit):
854         (JSC::Profiler::Database::performAtExitSave):
855         (JSC::Profiler::Database::removeFirstAtExitDatabase):
856         (JSC::Profiler::Database::atExitCallback):
857         * profiler/ProfilerDatabase.h:
858         (JSC::Profiler::Database::databaseID):
859         (Database):
860         * runtime/JSGlobalData.cpp:
861         (JSC::JSGlobalData::JSGlobalData):
862
863 2013-03-25  Filip Pizlo  <fpizlo@apple.com>
864
865         ArrayMode should not consider SpecOther when refining the base
866         https://bugs.webkit.org/show_bug.cgi?id=113271
867
868         Reviewed by Geoffrey Garen.
869         
870         9% speed-up on Octane/pdfjs.
871
872         * dfg/DFGArrayMode.cpp:
873         (JSC::DFG::ArrayMode::refine):
874
875 2013-03-26  Csaba Osztrogonác  <ossy@webkit.org>
876
877         Fix unused parameter warnings in JITInlines.h
878         https://bugs.webkit.org/show_bug.cgi?id=112560
879
880         Reviewed by Zoltan Herczeg.
881
882         * jit/JITInlines.h:
883         (JSC::JIT::beginUninterruptedSequence):
884         (JSC::JIT::endUninterruptedSequence):
885         (JSC):
886
887 2013-03-25  Kent Tamura  <tkent@chromium.org>
888
889         Rename ENABLE_INPUT_TYPE_DATETIME
890         https://bugs.webkit.org/show_bug.cgi?id=113254
891
892         Reviewed by Kentaro Hara.
893
894         Rename ENABLE_INPUT_TYPE_DATETIME to ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE.
895         Actually I'd like to remove the code, but we shouldn't remove it yet
896         because we shipped products with it on some platforms.
897
898         * Configurations/FeatureDefines.xcconfig:
899
900 2013-03-25  Mark Lam  <mark.lam@apple.com>
901
902         Offlineasm cloop backend compiles op+branch incorrectly.
903         https://bugs.webkit.org/show_bug.cgi?id=113146.
904
905         Reviewed by Geoffrey Garen.
906
907         * dfg/DFGRepatch.h:
908         (JSC::DFG::dfgResetGetByID):
909         (JSC::DFG::dfgResetPutByID):
910         - These functions never return when the DFG is dsiabled, not just when
911           asserts are enabled. Changing the attribute from NO_RETURN_DUE_TO_ASSERT
912           to NO_RETURN.
913         * llint/LLIntOfflineAsmConfig.h:
914         - Added some #defines needed to get the cloop building again.
915         * offlineasm/cloop.rb:
916         - Fix cloopEmitOpAndBranchIfOverflow() and cloopEmitOpAndBranch() to
917           emit code that unconditionally executes the specified operation before
918           doing the conditional branch.
919
920 2013-03-25  Mark Hahnenberg  <mhahnenberg@apple.com>
921
922         JSObject::enterDictionaryIndexingMode doesn't have a case for ALL_BLANK_INDEXING_TYPES
923         https://bugs.webkit.org/show_bug.cgi?id=113236
924
925         Reviewed by Geoffrey Garen.
926
927         * runtime/JSObject.cpp:
928         (JSC::JSObject::enterDictionaryIndexingMode): We forgot blank indexing types.
929
930 2013-03-23  Mark Hahnenberg  <mhahnenberg@apple.com>
931
932         HandleSet should use HeapBlocks for storing handles
933         https://bugs.webkit.org/show_bug.cgi?id=113145
934
935         Reviewed by Geoffrey Garen.
936
937         * GNUmakefile.list.am: Build project changes.
938         * JavaScriptCore.gypi: Ditto.
939         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
940         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
941         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
942         * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
943         * heap/BlockAllocator.cpp: Rename the RegionSet to m_fourKBBlockRegionSet because there are 
944         too many block types to include them all in the name now.
945         (JSC::BlockAllocator::BlockAllocator):
946         * heap/BlockAllocator.h:
947         (BlockAllocator): Add the appropriate override for regionSetFor.
948         (JSC::WeakBlock):
949         (JSC::MarkStackSegment):
950         (JSC::HandleBlock):
951         * heap/HandleBlock.h: Added.
952         (HandleBlock): New class for HandleBlocks.
953         (JSC::HandleBlock::blockFor): Static method to get the block of the given HandleNode pointer. Allows
954         us to quickly figure out which HandleSet the HandleNode belongs to without storing the pointer to it
955         in the HandleNode.
956         (JSC::HandleBlock::handleSet): Getter.
957         * heap/HandleBlockInlines.h: Added.
958         (JSC::HandleBlock::create):
959         (JSC::HandleBlock::HandleBlock):
960         (JSC::HandleBlock::payloadEnd):
961         (JSC::HandleBlock::payload):
962         (JSC::HandleBlock::nodes):
963         (JSC::HandleBlock::nodeAtIndex):
964         (JSC::HandleBlock::nodeCapacity):
965         * heap/HandleSet.cpp:
966         (JSC::HandleSet::~HandleSet): 
967         (JSC::HandleSet::grow):
968         * heap/HandleSet.h:
969         (HandleNode): Move the internal Node class from HandleSet to be its own public class so it can be 
970         used by HandleBlock.
971         (HandleSet): Add a typedef so that Node refers to the new HandleNode class.
972         (JSC::HandleSet::toHandle):
973         (JSC::HandleSet::toNode):
974         (JSC::HandleSet::allocate):
975         (JSC::HandleSet::deallocate):
976         (JSC::HandleNode::HandleNode):
977         (JSC::HandleNode::slot):
978         (JSC::HandleNode::handleSet): Use the new blockFor static function to get the right HandleBlock and lookup 
979         the HandleSet.
980         (JSC::HandleNode::setPrev):
981         (JSC::HandleNode::prev):
982         (JSC::HandleNode::setNext):
983         (JSC::HandleNode::next):
984         (JSC::HandleSet::forEachStrongHandle):
985         * heap/Heap.h: Friend HandleSet so that it can access the BlockAllocator when allocating HandleBlocks.
986
987 2013-03-22  David Kilzer  <ddkilzer@apple.com>
988
989         BUILD FIX (r145119): Make JSValue* properties default to (assign)
990         <rdar://problem/13380794>
991
992         Reviewed by Mark Hahnenberg.
993
994         Fixes the following build failures:
995
996             Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
997             @property JSValue *onclick;
998             ^
999             Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: default property attrib ute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
1000             Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
1001             @property JSValue *weakOnclick;
1002             ^
1003             Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: default property attribute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
1004             4 errors generated.
1005
1006         * API/tests/testapi.mm: Default to (assign) for JSValue*
1007         properties.
1008
1009 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1010
1011         testLeakingPrototypesAcrossContexts added in r146682 doesn't compile on Win and fails on Mac
1012         https://bugs.webkit.org/show_bug.cgi?id=113125
1013
1014         Reviewed by Mark Hahnenberg
1015
1016         Remove the test added in r146682 as it's now failing on Mac.
1017         This is the test that was causing a compilation failure on Windows.
1018
1019         * API/tests/testapi.c:
1020         (main):
1021
1022 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1023
1024         Fix the typo: WIN -> WINDOWS.
1025
1026         * API/tests/testapi.c:
1027         (main):
1028
1029 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1030
1031         I really can't figure out what's wrong with this one.
1032         Temporarily disable the test added by r146682 on Windows since it doesn't compile.
1033
1034         * API/tests/testapi.c:
1035         (main):
1036
1037 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1038
1039         Another build fix (after r146693) for r146682.
1040
1041         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
1042         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
1043
1044 2013-03-22  Roger Fong  <roger_fong@apple.com>
1045
1046         Unreviewed. AppleWin build fix.
1047
1048         * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
1049         * JavaScriptCore.vcxproj/copy-files.cmd:
1050
1051 2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>
1052
1053         -[TinyDOMNode dealloc] should call [super dealloc] when ARC is not enabled
1054         https://bugs.webkit.org/show_bug.cgi?id=113054
1055
1056         Reviewed by Geoffrey Garen.
1057
1058         * API/tests/testapi.mm:
1059         (-[TinyDOMNode dealloc]):
1060
1061 2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>
1062
1063         opaqueJSClassData should be cached on JSGlobalObject, not the JSGlobalData
1064         https://bugs.webkit.org/show_bug.cgi?id=113086
1065
1066         Reviewed by Geoffrey Garen.
1067
1068         opaqueJSClassData stores cached prototypes for JSClassRefs in the C API. It doesn't make sense to 
1069         share these prototypes within a JSGlobalData across JSGlobalObjects, and in fact doing so will cause 
1070         a leak of the original JSGlobalObject that these prototypes were created in. Therefore we should move 
1071         this cache to JSGlobalObject where it belongs and where it won't cause memory leaks.
1072
1073         * API/JSBase.cpp: Needed to add an extern "C" so that testapi.c can use the super secret GC function.
1074         * API/JSClassRef.cpp: We now grab the cached context data from the global object rather than the global data.
1075         (OpaqueJSClass::contextData):
1076         * API/JSClassRef.h: Remove this header because it's unnecessary and causes circular dependencies.
1077         * API/tests/testapi.c: Added a new test that makes sure that using the same JSClassRef in two different contexts
1078         doesn't cause leaks of the original global object.
1079         (leakFinalize):
1080         (nestedAllocateObject): This is a hack to bypass the conservative scan of the GC, which was unnecessarily marking
1081         objects and keeping them alive, ruining the test result.
1082         (testLeakingPrototypesAcrossContexts):
1083         (main):
1084         * API/tests/testapi.mm: extern "C" this so we can continue using it here.
1085         * runtime/JSGlobalData.cpp: Remove JSClassRef related stuff.
1086         (JSC::JSGlobalData::~JSGlobalData):
1087         * runtime/JSGlobalData.h:
1088         (JSGlobalData):
1089         * runtime/JSGlobalObject.h: Add the stuff that JSGlobalData had. We add it to JSGlobalObjectRareData so that 
1090         clients who don't use the C API don't have to pay the memory cost of this extra HashMap.
1091         (JSGlobalObject):
1092         (JSGlobalObjectRareData):
1093         (JSC::JSGlobalObject::opaqueJSClassData):
1094
1095 2013-03-19  Martin Robinson  <mrobinson@igalia.com>
1096
1097         [GTK] Add support for building the WebCore bindings to the gyp build
1098         https://bugs.webkit.org/show_bug.cgi?id=112638
1099
1100         Reviewed by Nico Weber.
1101
1102         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Export all include directories to direct
1103         dependents and fix the indentation of the libjavascriptcore target.
1104
1105 2013-03-21  Filip Pizlo  <fpizlo@apple.com>
1106
1107         Fix some minor issues in the DFG's profiling of heap accesses
1108         https://bugs.webkit.org/show_bug.cgi?id=113010
1109
1110         Reviewed by Goeffrey Garen.
1111         
1112         1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.
1113
1114         2) If a CodeBlock clears a structure stub during GC, it should record this, and
1115         the DFG should prefer to not inline that access (i.e. treat it as if it had an
1116         exit site).
1117
1118         3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
1119         but it chose not to, then assume that it will take slow path.
1120
1121         4) If we frequently exited because of a structure check on a weak constant,
1122         don't try to inline that access in the future.
1123
1124         5) Treat all exits that were counted as being frequent.
1125         
1126         81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.
1127
1128         * bytecode/CodeBlock.cpp:
1129         (JSC::CodeBlock::finalizeUnconditionally):
1130         (JSC):
1131         (JSC::CodeBlock::resetStubDuringGCInternal):
1132         (JSC::CodeBlock::reoptimize):
1133         (JSC::CodeBlock::jettison):
1134         (JSC::ProgramCodeBlock::jettisonImpl):
1135         (JSC::EvalCodeBlock::jettisonImpl):
1136         (JSC::FunctionCodeBlock::jettisonImpl):
1137         (JSC::CodeBlock::tallyFrequentExitSites):
1138         * bytecode/CodeBlock.h:
1139         (CodeBlock):
1140         (JSC::CodeBlock::tallyFrequentExitSites):
1141         (ProgramCodeBlock):
1142         (EvalCodeBlock):
1143         (FunctionCodeBlock):
1144         * bytecode/GetByIdStatus.cpp:
1145         (JSC::GetByIdStatus::computeFor):
1146         * bytecode/PutByIdStatus.cpp:
1147         (JSC::PutByIdStatus::computeFor):
1148         * bytecode/StructureStubInfo.h:
1149         (JSC::StructureStubInfo::StructureStubInfo):
1150         (StructureStubInfo):
1151         * dfg/DFGByteCodeParser.cpp:
1152         (JSC::DFG::ByteCodeParser::handleGetById):
1153         (JSC::DFG::ByteCodeParser::parseBlock):
1154         * dfg/DFGOSRExit.cpp:
1155         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
1156         * dfg/DFGOSRExit.h:
1157         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
1158         (OSRExit):
1159         * jit/JITStubs.cpp:
1160         (JSC::DEFINE_STUB_FUNCTION):
1161         * runtime/Options.h:
1162         (JSC):
1163
1164 2013-03-22  Filip Pizlo  <fpizlo@apple.com>
1165
1166         DFG folding of PutById to SimpleReplace should consider the specialized function case
1167         https://bugs.webkit.org/show_bug.cgi?id=113093
1168
1169         Reviewed by Geoffrey Garen and Mark Hahnenberg.
1170
1171         * bytecode/PutByIdStatus.cpp:
1172         (JSC::PutByIdStatus::computeFor):
1173
1174 2013-03-22  David Kilzer  <ddkilzer@apple.com>
1175
1176         BUILD FIX (r146558): Build testapi.mm with ARC enabled for armv7s
1177         <http://webkit.org/b/112608>
1178
1179         Fixes the following build failure:
1180
1181             Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
1182             }
1183             ^
1184             1 error generated.
1185
1186         * Configurations/ToolExecutable.xcconfig: Enable ARC for armv7s
1187         architecture.
1188
1189 2013-03-22  David Kilzer  <ddkilzer@apple.com>
1190
1191         Revert "BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]"
1192
1193         This fixes a build failure introduced by this change:
1194
1195             Source/JavaScriptCore/API/tests/testapi.mm:206:6: error: ARC forbids explicit message send of 'dealloc'
1196                 [super dealloc];
1197                  ^     ~~~~~~~
1198             1 error generated.
1199
1200         Not sure why this didn't fail locally on my Mac Pro.
1201
1202         * API/tests/testapi.mm:
1203         (-[TinyDOMNode dealloc]): Remove call to [super dealloc].
1204
1205 2013-03-22  David Kilzer  <ddkilzer@apple.com>
1206
1207         BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]
1208         <http://webkit.org/b/112608>
1209
1210         Fixes the following build failure:
1211
1212             Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
1213             }
1214             ^
1215             1 error generated.
1216
1217         * API/tests/testapi.mm:
1218         (-[TinyDOMNode dealloc]): Call [super dealloc].
1219
1220 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1221
1222         Leak bots erroneously report JSC::WatchpointSet as leaking
1223         https://bugs.webkit.org/show_bug.cgi?id=107781
1224
1225         Reviewed by Filip Pizlo.
1226
1227         Since leaks doesn't support tagged pointers, avoid using it by flipping the bit flag to indicate
1228         the entry is "fat". We set the flag when the entry is NOT fat; i.e. slim.
1229
1230         Replaced FatFlag by SlimFlag and initialized m_bits with this flag to indicate that the entry is
1231         initially "slim".
1232
1233         * runtime/SymbolTable.cpp:
1234         (JSC::SymbolTableEntry::copySlow): Don't set FatFlag since it has been replaced by SlimFlag.
1235         (JSC::SymbolTableEntry::inflateSlow): Ditto.
1236
1237         * runtime/SymbolTable.h:
1238         (JSC::SymbolTableEntry::Fast::Fast): Set SlimFlag by default.
1239         (JSC::SymbolTableEntry::Fast::isNull): Ignore SlimFlag.
1240         (JSC::SymbolTableEntry::Fast::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag
1241         is not set.
1242
1243         (JSC::SymbolTableEntry::SymbolTableEntry): Set SlimFlag by default.
1244         (JSC::SymbolTableEntry::SymbolTableEntry::getFast): Set SlimFlag when creating Fast from a fat entry.
1245         (JSC::SymbolTableEntry::isNull): Ignore SlimFlag.
1246         (JSC::SymbolTableEntry::FatEntry::FatEntry): Strip SlimFlag.
1247         (JSC::SymbolTableEntry::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag is unset.
1248         (JSC::SymbolTableEntry::fatEntry): Don't strip FatFlag as this flag doesn't exist anymore.
1249         (JSC::SymbolTableEntry::pack): Preserve SlimFlag.
1250
1251         (JSC::SymbolTableIndexHashTraits): empty value is no longer zero so don't set emptyValueIsZero true.
1252
1253 2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>
1254
1255         Objective-C API: Need a good way to preserve custom properties on JS wrappers
1256         https://bugs.webkit.org/show_bug.cgi?id=112608
1257
1258         Reviewed by Geoffrey Garen.
1259
1260         Currently, we just use a weak map, which means that garbage collection can cause a wrapper to 
1261         disappear if it isn't directly exported to JavaScript.
1262
1263         The most straightforward and safe way (with respect to garbage collection and concurrency) is to have 
1264         clients add and remove their external references along with their owners. Effectively, the client is 
1265         recording the structure of the external object graph so that the garbage collector can make sure to 
1266         mark any wrappers that are reachable through either the JS object graph of the external Obj-C object 
1267         graph. By keeping these wrappers alive, this has the effect that custom properties on these wrappers 
1268         will also remain alive.
1269
1270         The rule for if an object needs to be tracked by the runtime (and therefore whether the client should report it) is as follows:
1271         For a particular object, its references to its children should be added if:
1272         1. The child is referenced from JavaScript.
1273         2. The child contains references to other objects for which (1) or (2) are true.
1274
1275         * API/JSAPIWrapperObject.mm:
1276         (JSAPIWrapperObjectHandleOwner::finalize):
1277         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots): A wrapper object is kept alive only if its JSGlobalObject
1278         is marked and its corresponding Objective-C object was added to the set of opaque roots.
1279         (JSC::JSAPIWrapperObject::visitChildren): We now call out to scanExternalObjectGraph, which handles adding all Objective-C
1280         objects to the set of opaque roots.
1281         * API/JSAPIWrapperObject.h:
1282         (JSAPIWrapperObject):
1283         * API/JSContext.mm: Moved dealloc to its proper place in the main implementation.
1284         (-[JSContext dealloc]):
1285         * API/JSVirtualMachine.h:
1286         * API/JSVirtualMachine.mm:
1287         (-[JSVirtualMachine initWithContextGroupRef:]):
1288         (-[JSVirtualMachine dealloc]):
1289         (getInternalObjcObject): Helper funciton to get the Objective-C object out of JSManagedValues or JSValues if there is one.
1290         (-[JSVirtualMachine addManagedReference:withOwner:]): Adds the Objective-C object to the set of objects 
1291         owned by the owner object in that particular virtual machine.
1292         (-[JSVirtualMachine removeManagedReference:withOwner:]): Removes the relationship between the two objects.
1293         (-[JSVirtualMachine externalObjectGraph]):
1294         (scanExternalObjectGraph): Does a depth-first search of the external object graph in a particular virtual machine starting at
1295         the specified root. Each new object it encounters it adds to the set of opaque roots. These opaque roots will keep their 
1296         corresponding wrapper objects alive if they have them. 
1297         * API/JSManagedReferenceInternal.h: Added.
1298         * API/JSVirtualMachine.mm: Added the per-JSVirtualMachine map between objects and the objects they own, which is more formally
1299         known as that virtual machine's external object graph.
1300         * API/JSWrapperMap.mm:
1301         (-[JSWrapperMap dealloc]): We were leaking this before :-(
1302         (-[JSVirtualMachine initWithContextGroupRef:]):
1303         (-[JSVirtualMachine dealloc]):
1304         (-[JSVirtualMachine externalObjectGraph]):
1305         * API/JSVirtualMachineInternal.h:
1306         * API/tests/testapi.mm: Added two new tests using the TinyDOMNode class. The first tests that a custom property added to a wrapper 
1307         doesn't vanish after GC, even though that wrapper isn't directly accessible to the JS garbage collector but is accessible through 
1308         the external Objective-C object graph. The second test makes sure that adding an object to the external object graph with the same 
1309         owner doesn't cause any sort of problems.
1310         (+[TinyDOMNode sharedVirtualMachine]):
1311         (-[TinyDOMNode init]):
1312         (-[TinyDOMNode dealloc]):
1313         (-[TinyDOMNode appendChild:]):
1314         (-[TinyDOMNode numberOfChildren]):
1315         (-[TinyDOMNode childAtIndex:]):
1316         (-[TinyDOMNode removeChildAtIndex:]):
1317         * JavaScriptCore.xcodeproj/project.pbxproj:
1318         * heap/SlotVisitor.h:
1319         (SlotVisitor):
1320         * heap/SlotVisitorInlines.h:
1321         (JSC::SlotVisitor::containsOpaqueRootTriState): Added a new method to SlotVisitor to allow scanExternalObjectGraph to have a 
1322         thread-safe view of opaque roots during parallel marking. The set of opaque roots available to any one SlotVisitor isn't guaranteed
1323         to be 100% correct, but that just results in a small duplication of work in scanExternalObjectGraph. To indicate this change for
1324         false negatives we return a TriState that's either true or mixed, but never false.
1325
1326 2013-03-21  Mark Lam  <mark.lam@apple.com>
1327
1328         Fix O(n^2) op_debug bytecode charPosition to column computation.
1329         https://bugs.webkit.org/show_bug.cgi?id=112957.
1330
1331         Reviewed by Geoffrey Garen.
1332
1333         The previous algorithm does a linear reverse scan of the source string
1334         to find the line start for any given char position. This results in a
1335         O(n^2) algortithm when the source string has no line breaks.
1336
1337         The new algorithm computes a line start column table for a
1338         SourceProvider on first use. This line start table is used to fix up
1339         op_debug's charPosition operand into a column operand when an
1340         UnlinkedCodeBlock is linked into a CodeBlock. The initialization of
1341         the line start table is O(n), and the CodeBlock column fix up is
1342         O(log(n)).
1343
1344         * bytecode/CodeBlock.cpp:
1345         (JSC::CodeBlock::dumpBytecode): 
1346         (JSC::CodeBlock::CodeBlock): - do column fix up.
1347         * interpreter/Interpreter.cpp:
1348         (JSC::Interpreter::debug): - no need to do column fixup anymore.
1349         * interpreter/Interpreter.h:
1350         * jit/JITStubs.cpp:
1351         (JSC::DEFINE_STUB_FUNCTION):
1352         * llint/LLIntSlowPaths.cpp:
1353         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1354         * parser/SourceProvider.cpp:
1355         (JSC::SourceProvider::lineStarts):
1356         (JSC::charPositionExtractor):
1357         (JSC::SourceProvider::charPositionToColumnNumber):
1358         - initialize line start column table if needed.
1359         - look up line start for the given char position.
1360         * parser/SourceProvider.h:
1361
1362 2013-03-21  Filip Pizlo  <fpizlo@apple.com>
1363
1364         JSC profiler should have an at-a-glance report of the success of DFG optimization
1365         https://bugs.webkit.org/show_bug.cgi?id=112988
1366
1367         Reviewed by Geoffrey Garen.
1368
1369         * dfg/DFGByteCodeParser.cpp:
1370         (JSC::DFG::ByteCodeParser::handleCall):
1371         (JSC::DFG::ByteCodeParser::handleGetById):
1372         (JSC::DFG::ByteCodeParser::parseBlock):
1373         * profiler/ProfilerCompilation.cpp:
1374         (JSC::Profiler::Compilation::Compilation):
1375         (JSC::Profiler::Compilation::toJS):
1376         * profiler/ProfilerCompilation.h:
1377         (JSC::Profiler::Compilation::noticeInlinedGetById):
1378         (JSC::Profiler::Compilation::noticeInlinedPutById):
1379         (JSC::Profiler::Compilation::noticeInlinedCall):
1380         (Compilation):
1381         * runtime/CommonIdentifiers.h:
1382
1383 2013-03-21  Mark Lam  <mark.lam@apple.com>
1384
1385         Fix lexer charPosition computation when "rewind"ing the lexer.
1386         https://bugs.webkit.org/show_bug.cgi?id=112952.
1387
1388         Reviewed by Michael Saboff.
1389
1390         Changed the Lexer to no longer keep a m_charPosition. Instead, we compute
1391         currentCharPosition() from m_code and m_codeStartPlusOffset, where
1392         m_codeStartPlusOffset is the SourceProvider m_codeStart + the SourceCode
1393         start offset. This ensures that the charPosition is always in sync with
1394         m_code.
1395
1396         * parser/Lexer.cpp:
1397         (JSC::::setCode):
1398         (JSC::::internalShift):
1399         (JSC::::shift):
1400         (JSC::::lex):
1401         * parser/Lexer.h:
1402         (JSC::Lexer::currentCharPosition):
1403         (JSC::::lexExpectIdentifier):
1404
1405 2013-03-21  Alberto Garcia  <agarcia@igalia.com>
1406
1407         [BlackBerry] GCActivityCallback: replace JSLock with JSLockHolder
1408         https://bugs.webkit.org/show_bug.cgi?id=112448
1409
1410         Reviewed by Xan Lopez.
1411
1412         This changed in r121381.
1413
1414         * runtime/GCActivityCallbackBlackBerry.cpp:
1415         (JSC::DefaultGCActivityCallback::doWork):
1416
1417 2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>
1418
1419         Objective-C API: wrapperClass holds a static JSClassRef, which causes JSGlobalObjects to leak
1420         https://bugs.webkit.org/show_bug.cgi?id=112856
1421
1422         Reviewed by Geoffrey Garen.
1423
1424         Through a very convoluted path that involves the caching of prototypes on the JSClassRef, we can leak 
1425         JSGlobalObjects when inserting an Objective-C object into multiple independent JSContexts.
1426
1427         * API/JSAPIWrapperObject.cpp: Removed.
1428         * API/JSAPIWrapperObject.h:
1429         (JSAPIWrapperObject):
1430         * API/JSAPIWrapperObject.mm: Copied from Source/JavaScriptCore/API/JSAPIWrapperObject.cpp. Made this an
1431         Objective-C++ file so that we can call release on the wrappedObject. Also added a WeakHandleOwner for 
1432         JSAPIWrapperObjects. This will also be used in a future patch for https://bugs.webkit.org/show_bug.cgi?id=112608.
1433         (JSAPIWrapperObjectHandleOwner):
1434         (jsAPIWrapperObjectHandleOwner):
1435         (JSAPIWrapperObjectHandleOwner::finalize): This finalize replaces the old finalize that was done through
1436         the C API.
1437         (JSC::JSAPIWrapperObject::finishCreation): Allocate the WeakImpl. Balanced in finalize.
1438         (JSC::JSAPIWrapperObject::setWrappedObject): We now do the retain of the wrappedObject here rather than in random
1439         places scattered around JSWrapperMap.mm
1440         * API/JSObjectRef.cpp: Added some ifdefs for platforms that don't support the Obj-C API.
1441         (JSObjectGetPrivate): Ditto.
1442         (JSObjectSetPrivate): Ditto.
1443         (JSObjectGetPrivateProperty): Ditto.
1444         (JSObjectSetPrivateProperty): Ditto.
1445         (JSObjectDeletePrivateProperty): Ditto.
1446         * API/JSValueRef.cpp: Ditto.
1447         (JSValueIsObjectOfClass): Ditto.
1448         * API/JSWrapperMap.mm: Remove wrapperClass().
1449         (objectWithCustomBrand): Change to no longer use a parent class, which was only used to give the ability to 
1450         finalize wrapper objects.
1451         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Change to no longer use wrapperClass(). 
1452         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Ditto.
1453         (tryUnwrapObjcObject): We now check if the object inherits from JSAPIWrapperObject.
1454         * API/tests/testapi.mm: Added a test that exports an Objective-C object to two different JSContexts and makes 
1455         sure that the first one is collected properly by using a weak JSManagedValue for the wrapper in the first JSContext.
1456         * CMakeLists.txt: Build file modifications.
1457         * GNUmakefile.list.am: Ditto.
1458         * JavaScriptCore.gypi: Ditto.
1459         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
1460         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
1461         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
1462         * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
1463         * runtime/JSGlobalObject.cpp: More ifdefs for unsupported platforms.
1464         (JSC::JSGlobalObject::reset): Ditto.
1465         (JSC::JSGlobalObject::visitChildren): Ditto.
1466         * runtime/JSGlobalObject.h: Ditto.
1467         (JSGlobalObject): Ditto.
1468         (JSC::JSGlobalObject::objcCallbackFunctionStructure): Ditto.
1469
1470 2013-03-21  Anton Muhin  <antonm@chromium.org>
1471
1472         Unreviewed, rolling out r146483.
1473         http://trac.webkit.org/changeset/146483
1474         https://bugs.webkit.org/show_bug.cgi?id=111695
1475
1476         Breaks debug builds.
1477
1478         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.
1479
1480 2013-03-21  Gabor Rapcsanyi  <rgabor@webkit.org>
1481
1482         Implement LLInt for CPU(ARM_TRADITIONAL)
1483         https://bugs.webkit.org/show_bug.cgi?id=97589
1484
1485         Reviewed by Zoltan Herczeg.
1486
1487         Enable LLInt for ARMv5 and ARMv7 traditional as well.
1488
1489         * llint/LLIntOfflineAsmConfig.h:
1490         * llint/LowLevelInterpreter.asm:
1491         * llint/LowLevelInterpreter32_64.asm:
1492         * offlineasm/arm.rb:
1493         * offlineasm/backends.rb:
1494         * offlineasm/instructions.rb:
1495
1496 2013-03-20  Cosmin Truta  <ctruta@blackberry.com>
1497
1498         [QNX][ARM] REGRESSION(r135330): Various failures in Octane
1499         https://bugs.webkit.org/show_bug.cgi?id=112863
1500
1501         Reviewed by Yong Li.
1502
1503         This was fixed in http://trac.webkit.org/changeset/146396 on Linux only.
1504         Enable this fix on QNX.
1505
1506         * assembler/ARMv7Assembler.h:
1507         (ARMv7Assembler):
1508         (JSC::ARMv7Assembler::replaceWithJump):
1509         (JSC::ARMv7Assembler::maxJumpReplacementSize):
1510         * assembler/MacroAssemblerARMv7.h:
1511         (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
1512
1513 2013-03-20  Filip Pizlo  <fpizlo@apple.com>
1514
1515         Fix indentation of JSString.h
1516
1517         Rubber stamped by Mark Hahnenberg.
1518
1519         * runtime/JSString.h:
1520
1521 2013-03-20  Filip Pizlo  <fpizlo@apple.com>
1522
1523         "" + x where x is not a string should be optimized by the DFG to some manner of ToString conversion
1524         https://bugs.webkit.org/show_bug.cgi?id=112845
1525
1526         Reviewed by Mark Hahnenberg.
1527         
1528         I like to do "" + x. So I decided to make DFG recognize it, and related idioms.
1529
1530         * dfg/DFGFixupPhase.cpp:
1531         (JSC::DFG::FixupPhase::fixupNode):
1532         (JSC::DFG::FixupPhase::fixupToPrimitive):
1533         (FixupPhase):
1534         (JSC::DFG::FixupPhase::fixupToString):
1535         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1536         * dfg/DFGPredictionPropagationPhase.cpp:
1537         (JSC::DFG::resultOfToPrimitive):
1538         (DFG):
1539         (JSC::DFG::PredictionPropagationPhase::propagate):
1540         * dfg/DFGPredictionPropagationPhase.h:
1541         (DFG):
1542
1543 2013-03-20  Zoltan Herczeg  <zherczeg@webkit.org>
1544
1545         ARMv7 replaceWithJump ASSERT failure after r135330.
1546         https://bugs.webkit.org/show_bug.cgi?id=103146
1547
1548         Reviewed by Filip Pizlo.
1549
1550         On Linux, the 24 bit distance range of jumps sometimes does not
1551         enough to cover all targets addresses. This patch supports jumps
1552         outside of this range using a mov/movt/bx 10 byte long sequence.
1553
1554         * assembler/ARMv7Assembler.h:
1555         (ARMv7Assembler):
1556         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
1557         (JSC::ARMv7Assembler::nopw):
1558         (JSC::ARMv7Assembler::label):
1559         (JSC::ARMv7Assembler::replaceWithJump):
1560         (JSC::ARMv7Assembler::maxJumpReplacementSize):
1561         * assembler/MacroAssemblerARMv7.h:
1562         (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
1563
1564 2013-03-20  Mark Hahnenberg  <mhahnenberg@apple.com>
1565
1566         Objective-C API: Fix over-releasing in allocateConstructorAndPrototypeWithSuperClassInfo:
1567         https://bugs.webkit.org/show_bug.cgi?id=112832
1568
1569         Reviewed by Geoffrey Garen.
1570
1571         If either the m_constructor or m_prototype (but not both) is collected, we will call 
1572         allocateConstructorAndPrototypeWithSuperClassInfo, which will create a new object to replace the one 
1573         that was collected, but at the end of the method we call release on both of them. 
1574         This is incorrect since we autorelease the JSValue in the case that the object doesn't need to be 
1575         reallocated. Thus we'll end up overreleasing later during the drain of the autorelease pool.
1576
1577         * API/JSWrapperMap.mm:
1578         (objectWithCustomBrand): We no longer alloc here. We instead call the JSValue valueWithValue class method,
1579         which autoreleases for us.
1580         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We no longer call release on the 
1581         constructor or prototype JSValues.
1582         * API/tests/testapi.mm: Added a new test that crashes on ToT due to over-releasing.
1583
1584 2013-03-19  Filip Pizlo  <fpizlo@apple.com>
1585
1586         It's called "Hash Consing" not "Hash Consting"
1587         https://bugs.webkit.org/show_bug.cgi?id=112768
1588
1589         Rubber stamped by Mark Hahnenberg.
1590         
1591         See http://en.wikipedia.org/wiki/Hash_consing
1592
1593         * heap/GCThreadSharedData.cpp:
1594         (JSC::GCThreadSharedData::GCThreadSharedData):
1595         (JSC::GCThreadSharedData::reset):
1596         * heap/GCThreadSharedData.h:
1597         (GCThreadSharedData):
1598         * heap/SlotVisitor.cpp:
1599         (JSC::SlotVisitor::SlotVisitor):
1600         (JSC::SlotVisitor::setup):
1601         (JSC::SlotVisitor::reset):
1602         (JSC::JSString::tryHashConsLock):
1603         (JSC::JSString::releaseHashConsLock):
1604         (JSC::JSString::shouldTryHashCons):
1605         (JSC::SlotVisitor::internalAppend):
1606         * heap/SlotVisitor.h:
1607         (SlotVisitor):
1608         * runtime/JSGlobalData.cpp:
1609         (JSC::JSGlobalData::JSGlobalData):
1610         * runtime/JSGlobalData.h:
1611         (JSGlobalData):
1612         (JSC::JSGlobalData::haveEnoughNewStringsToHashCons):
1613         (JSC::JSGlobalData::resetNewStringsSinceLastHashCons):
1614         * runtime/JSString.h:
1615         (JSC::JSString::finishCreation):
1616         (JSString):
1617         (JSC::JSString::isHashConsSingleton):
1618         (JSC::JSString::clearHashConsSingleton):
1619         (JSC::JSString::setHashConsSingleton):
1620
1621 2013-03-20  Filip Pizlo  <fpizlo@apple.com>
1622
1623         DFG implementation of op_strcat should inline rope allocations
1624         https://bugs.webkit.org/show_bug.cgi?id=112780
1625
1626         Reviewed by Oliver Hunt.
1627         
1628         This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can
1629         take either two or three operands, and allocates a rope string with either two or
1630         three fibers. (The magic choice of three children for non-VarArg nodes happens to
1631         match exactly with the magic choice of three fibers for rope strings.)
1632         
1633         ValueAdd on KnownString is replaced with MakeRope with two children.
1634         
1635         StrCat gets replaced by an appropriate sequence of MakeRope's.
1636         
1637         MakeRope does not do the dynamic check to see if its children are empty strings.
1638         This is replaced by a static check, instead. The downside is that we may use more
1639         memory if the strings passed to MakeRope turn out to dynamically be empty. The
1640         upside is that we do fewer checks in the cases where either the strings are not
1641         empty, or where the strings are statically known to be empty. I suspect both of
1642         those cases are more common, than the case where the string is dynamically empty.
1643         
1644         This also results in some badness for X86. MakeRope needs six registers if it is
1645         allocating a three-rope. We don't have six registers to spare on X86. Currently,
1646         the code side-steps this problem by just never usign three-ropes in optimized
1647         code on X86. All other architectures, including X86_64, don't have this problem.
1648         
1649         This is a shocking speed-up. 9% progressions on both V8/splay and
1650         SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression
1651         on SunSpider. 2x speed-up on microbenchmarks that test op_strcat.
1652
1653         * dfg/DFGAbstractState.cpp:
1654         (JSC::DFG::AbstractState::executeEffects):
1655         * dfg/DFGAdjacencyList.h:
1656         (AdjacencyList):
1657         (JSC::DFG::AdjacencyList::removeEdge):
1658         * dfg/DFGArgumentsSimplificationPhase.cpp:
1659         (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
1660         * dfg/DFGBackwardsPropagationPhase.cpp:
1661         (JSC::DFG::BackwardsPropagationPhase::propagate):
1662         * dfg/DFGByteCodeParser.cpp:
1663         (JSC::DFG::ByteCodeParser::parseBlock):
1664         * dfg/DFGCSEPhase.cpp:
1665         (JSC::DFG::CSEPhase::putStructureStoreElimination):
1666         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
1667         (JSC::DFG::CSEPhase::performNodeCSE):
1668         * dfg/DFGDCEPhase.cpp:
1669         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
1670         * dfg/DFGFixupPhase.cpp:
1671         (JSC::DFG::FixupPhase::fixupNode):
1672         (JSC::DFG::FixupPhase::createToString):
1673         (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
1674         (JSC::DFG::FixupPhase::convertStringAddUse):
1675         (FixupPhase):
1676         (JSC::DFG::FixupPhase::convertToMakeRope):
1677         (JSC::DFG::FixupPhase::fixupMakeRope):
1678         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1679         * dfg/DFGNodeType.h:
1680         (DFG):
1681         * dfg/DFGOperations.cpp:
1682         * dfg/DFGOperations.h:
1683         * dfg/DFGPredictionPropagationPhase.cpp:
1684         (JSC::DFG::PredictionPropagationPhase::propagate):
1685         * dfg/DFGSpeculativeJIT.cpp:
1686         (JSC::DFG::SpeculativeJIT::compileAdd):
1687         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1688         (DFG):
1689         * dfg/DFGSpeculativeJIT.h:
1690         (JSC::DFG::SpeculativeJIT::callOperation):
1691         (SpeculativeJIT):
1692         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
1693         (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand):
1694         (JSC::DFG::SpeculateCellOperand::gpr):
1695         (JSC::DFG::SpeculateCellOperand::use):
1696         * dfg/DFGSpeculativeJIT32_64.cpp:
1697         (JSC::DFG::SpeculativeJIT::compile):
1698         * dfg/DFGSpeculativeJIT64.cpp:
1699         (JSC::DFG::SpeculativeJIT::compile):
1700         * runtime/JSString.h:
1701         (JSRopeString):
1702
1703 2013-03-20  Peter Gal  <galpeter@inf.u-szeged.hu>
1704
1705         Implement and32 on MIPS platform
1706         https://bugs.webkit.org/show_bug.cgi?id=112665
1707
1708         Reviewed by Zoltan Herczeg.
1709
1710         * assembler/MacroAssemblerMIPS.h:
1711         (JSC::MacroAssemblerMIPS::and32): Added missing method.
1712         (MacroAssemblerMIPS):
1713
1714 2013-03-20  Mark Lam  <mark.lam@apple.com>
1715
1716         Fix incorrect debugger column number value.
1717         https://bugs.webkit.org/show_bug.cgi?id=112741.
1718
1719         Reviewed by Oliver Hunt.
1720
1721         1. In lexer, parser, and debugger code, renamed column to charPosition.
1722         2. Convert the charPosition to the equivalent column number before
1723            passing it to the debugger.
1724         3. Changed ScopeNodes to take both a startLocation and an endLocation.
1725            This allows FunctionBodyNodes, ProgramNodes, and EvalNodess to emit
1726            correct debug hooks with correct starting line and column numbers.
1727         4. Fixed the Lexer to not reset the charPosition (previously
1728            columnNumber) in Lexer::lex().
1729
1730         * JavaScriptCore.order:
1731         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
1732         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
1733         * bytecode/CodeBlock.cpp:
1734         (JSC::CodeBlock::dumpBytecode):
1735         * bytecompiler/BytecodeGenerator.cpp:
1736         (JSC::BytecodeGenerator::emitDebugHook):
1737         * bytecompiler/BytecodeGenerator.h:
1738         (JSC::BytecodeGenerator::emitExpressionInfo):
1739         * bytecompiler/NodesCodegen.cpp:
1740         (JSC::ArrayNode::toArgumentList):
1741         (JSC::ConstStatementNode::emitBytecode):
1742         (JSC::EmptyStatementNode::emitBytecode):
1743         (JSC::DebuggerStatementNode::emitBytecode):
1744         (JSC::ExprStatementNode::emitBytecode):
1745         (JSC::VarStatementNode::emitBytecode):
1746         (JSC::IfNode::emitBytecode):
1747         (JSC::IfElseNode::emitBytecode):
1748         (JSC::DoWhileNode::emitBytecode):
1749         (JSC::WhileNode::emitBytecode):
1750         (JSC::ForNode::emitBytecode):
1751         (JSC::ForInNode::emitBytecode):
1752         (JSC::ContinueNode::emitBytecode):
1753         (JSC::BreakNode::emitBytecode):
1754         (JSC::ReturnNode::emitBytecode):
1755         (JSC::WithNode::emitBytecode):
1756         (JSC::SwitchNode::emitBytecode):
1757         (JSC::LabelNode::emitBytecode):
1758         (JSC::ThrowNode::emitBytecode):
1759         (JSC::TryNode::emitBytecode):
1760         (JSC::ProgramNode::emitBytecode):
1761         (JSC::EvalNode::emitBytecode):
1762         (JSC::FunctionBodyNode::emitBytecode):
1763         * interpreter/Interpreter.cpp:
1764         (JSC::Interpreter::debug):
1765         - convert charPosition to column for the debugger.
1766         * interpreter/Interpreter.h:
1767         * jit/JITStubs.cpp:
1768         (DEFINE_STUB_FUNCTION(void, op_debug)):
1769         * llint/LLIntSlowPaths.cpp:
1770         (LLINT_SLOW_PATH_DECL(slow_op_debug)):
1771         * parser/ASTBuilder.h:
1772         (JSC::ASTBuilder::createFunctionExpr):
1773         (JSC::ASTBuilder::createFunctionBody):
1774         (JSC::ASTBuilder::createGetterOrSetterProperty):
1775         (JSC::ASTBuilder::createFuncDeclStatement):
1776         (JSC::ASTBuilder::createBlockStatement):
1777         (JSC::ASTBuilder::createExprStatement):
1778         (JSC::ASTBuilder::createIfStatement):
1779         (JSC::ASTBuilder::createForLoop):
1780         (JSC::ASTBuilder::createForInLoop):
1781         (JSC::ASTBuilder::createVarStatement):
1782         (JSC::ASTBuilder::createReturnStatement):
1783         (JSC::ASTBuilder::createBreakStatement):
1784         (JSC::ASTBuilder::createContinueStatement):
1785         (JSC::ASTBuilder::createTryStatement):
1786         (JSC::ASTBuilder::createSwitchStatement):
1787         (JSC::ASTBuilder::createWhileStatement):
1788         (JSC::ASTBuilder::createDoWhileStatement):
1789         (JSC::ASTBuilder::createWithStatement):
1790         (JSC::ASTBuilder::createThrowStatement):
1791         (JSC::ASTBuilder::createDebugger):
1792         (JSC::ASTBuilder::createConstStatement):
1793         * parser/Lexer.cpp:
1794         (JSC::::setCode):
1795         (JSC::::internalShift):
1796         (JSC::::shift):
1797         (JSC::::lex):
1798         * parser/Lexer.h:
1799         (JSC::Lexer::currentCharPosition):
1800         (Lexer):
1801         (JSC::::lexExpectIdentifier):
1802         * parser/NodeConstructors.h:
1803         (JSC::Node::Node):
1804         * parser/Nodes.cpp:
1805         (JSC::StatementNode::setLoc):
1806         (JSC::ScopeNode::ScopeNode):
1807         (JSC::ProgramNode::ProgramNode):
1808         (JSC::ProgramNode::create):
1809         (JSC::EvalNode::EvalNode):
1810         (JSC::EvalNode::create):
1811         (JSC::FunctionBodyNode::FunctionBodyNode):
1812         (JSC::FunctionBodyNode::create):
1813         * parser/Nodes.h:
1814         (JSC::Node::charPosition):
1815         (Node):
1816         (StatementNode):
1817         (JSC::StatementNode::lastLine):
1818         (ScopeNode):
1819         (JSC::ScopeNode::startLine):
1820         (JSC::ScopeNode::startCharPosition):
1821         (ProgramNode):
1822         (EvalNode):
1823         (FunctionBodyNode):
1824         * parser/Parser.cpp:
1825         (JSC::::Parser):
1826         (JSC::::parseFunctionBody):
1827         (JSC::::parseFunctionInfo):
1828         * parser/Parser.h:
1829         (JSC::::parse):
1830         * parser/ParserTokens.h:
1831         (JSC::JSTokenLocation::JSTokenLocation):
1832         (JSTokenLocation):
1833         * parser/SyntaxChecker.h:
1834         (JSC::SyntaxChecker::createFunctionBody):
1835
1836 2013-03-20  Csaba Osztrogonác  <ossy@webkit.org>
1837
1838         REGRESSION(r146089): It broke 20 sputnik tests on ARM traditional and Thumb2
1839         https://bugs.webkit.org/show_bug.cgi?id=112676
1840
1841         Rubber-stamped by Filip Pizlo.
1842
1843         Add one more EABI_32BIT_DUMMY_ARG to make DFG JIT ARM EABI compatible
1844         again after r146089 similar to https://bugs.webkit.org/show_bug.cgi?id=84449
1845
1846         * dfg/DFGSpeculativeJIT.h:
1847         (JSC::DFG::SpeculativeJIT::callOperation):
1848
1849 2013-03-19  Michael Saboff  <msaboff@apple.com>
1850
1851         Crash when loading http://www.jqchart.com/jquery/gauges/RadialGauge/LiveData
1852         https://bugs.webkit.org/show_bug.cgi?id=112694
1853
1854         Reviewed by Filip Pizlo.
1855
1856         We were trying to convert an NewArray to a Phantom, but convertToPhantom doesn't handle
1857         nodes with variable arguments.  Added code to insert a Phantom node in front of all the
1858         live children of a var args node.  Added ASSERT not var args for convertToPhantom to
1859         catch any other similar cases.  Added a new convertToPhantomUnchecked() for converting 
1860         var arg nodes.
1861
1862         * dfg/DFGDCEPhase.cpp:
1863         (JSC::DFG::DCEPhase::run):
1864         * dfg/DFGNode.h:
1865         (Node):
1866         (JSC::DFG::Node::setOpAndDefaultNonExitFlags): Added ASSERT(!(m_flags & NodeHasVarArgs))
1867         (JSC::DFG::Node::setOpAndDefaultNonExitFlagsUnchecked):
1868         (JSC::DFG::Node::convertToPhantomUnchecked):
1869
1870 2013-03-19  Mark Hahnenberg  <mhahnenberg@apple.com>
1871
1872         Crash in SpeculativeJIT::fillSpeculateIntInternal<false> on http://bellard.org/jslinux
1873         https://bugs.webkit.org/show_bug.cgi?id=112738
1874
1875         Reviewed by Filip Pizlo.
1876
1877         * dfg/DFGFixupPhase.cpp:
1878         (JSC::DFG::FixupPhase::fixIntEdge): We shouldn't be killing this node because it could be
1879         referenced by other people.
1880
1881 2013-03-19  Oliver Hunt  <oliver@apple.com>
1882
1883         RELEASE_ASSERT fires in exception handler lookup
1884
1885         RS=Geoff Garen.
1886
1887         Temporarily switch this RELEASE_ASSERT into a regular ASSERT 
1888         as currently this is producing fairly bad crashiness.
1889
1890         * bytecode/CodeBlock.cpp:
1891         (JSC::CodeBlock::handlerForBytecodeOffset):
1892
1893 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
1894
1895         DFG should optimize StringObject.length and StringOrStringObject.length
1896         https://bugs.webkit.org/show_bug.cgi?id=112658
1897
1898         Reviewed by Mark Hahnenberg.
1899         
1900         Implemented by injecting a ToString(StringObject:@a) or ToString(StringOrStringObject:@a) prior
1901         to GetArrayLength with ArrayMode(Array::String) if @a is predicted StringObject or
1902         StringOrStringObject.
1903
1904         * dfg/DFGFixupPhase.cpp:
1905         (JSC::DFG::FixupPhase::fixupNode):
1906         (JSC::DFG::FixupPhase::createToString):
1907         (FixupPhase):
1908         (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
1909         (JSC::DFG::FixupPhase::convertStringAddUse):
1910
1911 2013-03-19  Gabor Rapcsanyi  <rgabor@webkit.org>
1912
1913         Implement and32 on ARMv7 and ARM traditional platforms
1914         https://bugs.webkit.org/show_bug.cgi?id=112663
1915
1916         Reviewed by Zoltan Herczeg.
1917
1918         * assembler/MacroAssemblerARM.h:
1919         (JSC::MacroAssemblerARM::and32): Add missing method.
1920         (MacroAssemblerARM):
1921         * assembler/MacroAssemblerARMv7.h:
1922         (JSC::MacroAssemblerARMv7::and32): Add missing method.
1923         (MacroAssemblerARMv7):
1924
1925 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
1926
1927         DFG ToString generic cases should work correctly
1928         https://bugs.webkit.org/show_bug.cgi?id=112654
1929         <rdar://problem/13447250>
1930
1931         Reviewed by Geoffrey Garen.
1932
1933         * dfg/DFGSpeculativeJIT.cpp:
1934         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
1935         * dfg/DFGSpeculativeJIT32_64.cpp:
1936         (JSC::DFG::SpeculativeJIT::compile):
1937         * dfg/DFGSpeculativeJIT64.cpp:
1938         (JSC::DFG::SpeculativeJIT::compile):
1939
1940 2013-03-18  Michael Saboff  <msaboff@apple.com>
1941
1942         Unreviewed build fix for 32 bit builds.
1943
1944         * dfg/DFGSpeculativeJIT32_64.cpp:
1945         (JSC::DFG::SpeculativeJIT::compile):
1946
1947 2013-03-18  Michael Saboff  <msaboff@apple.com>
1948
1949         EFL: Unsafe branch detected in compilePutByValForFloatTypedArray()
1950         https://bugs.webkit.org/show_bug.cgi?id=112609
1951
1952         Reviewed by Geoffrey Garen.
1953
1954         Created local valueFPR and scratchFPR and filled them with valueOp.fpr() and scratch.fpr()
1955         respectively so that if valueOp.fpr() causes a spill during allocation, it occurs before the
1956         branch and also to follow convention.  Added register allocation checks to FPRTemporary.
1957         Cleaned up a couple of other places to follow the "AllocatVirtualRegType foo, get machine
1958         reg from foo" pattern.
1959
1960         * dfg/DFGSpeculativeJIT.cpp:
1961         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
1962         * dfg/DFGSpeculativeJIT.h:
1963         (JSC::DFG::SpeculativeJIT::fprAllocate):
1964         * dfg/DFGSpeculativeJIT32_64.cpp:
1965         (JSC::DFG::SpeculativeJIT::convertToDouble):
1966         (JSC::DFG::SpeculativeJIT::compile):
1967         * dfg/DFGSpeculativeJIT64.cpp:
1968         (JSC::DFG::SpeculativeJIT::compile):
1969
1970 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
1971
1972         DFG should inline binary string concatenations (i.e. ValueAdd with string children)
1973         https://bugs.webkit.org/show_bug.cgi?id=112599
1974
1975         Reviewed by Oliver Hunt.
1976         
1977         This does as advertised: if you do x + y where x and y are strings, you'll get
1978         a fast inlined JSRopeString allocation (along with whatever checks are necessary).
1979         It also does good things if either x or y (or both) are StringObjects, or some
1980         other thing like StringOrStringObject. It also lays the groundwork for making this
1981         fast if either x or y are numbers, or some other reasonably-cheap-to-convert
1982         value.
1983
1984         * dfg/DFGAbstractState.cpp:
1985         (JSC::DFG::AbstractState::executeEffects):
1986         * dfg/DFGFixupPhase.cpp:
1987         (JSC::DFG::FixupPhase::fixupNode):
1988         (FixupPhase):
1989         (JSC::DFG::FixupPhase::isStringObjectUse):
1990         (JSC::DFG::FixupPhase::convertStringAddUse):
1991         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1992         * dfg/DFGOperations.cpp:
1993         * dfg/DFGOperations.h:
1994         * dfg/DFGSpeculativeJIT.cpp:
1995         (JSC::DFG::SpeculativeJIT::compileAdd):
1996         * dfg/DFGSpeculativeJIT.h:
1997         (JSC::DFG::SpeculativeJIT::callOperation):
1998         (SpeculativeJIT):
1999         (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
2000         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
2001         * runtime/JSString.h:
2002         (JSC::JSString::offsetOfFlags):
2003         (JSString):
2004         (JSRopeString):
2005         (JSC::JSRopeString::offsetOfFibers):
2006
2007 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
2008
2009         JSC_NATIVE_FUNCTION() takes an identifier for the name and then uses #name, which is unsafe if name was already #define'd to something else
2010         https://bugs.webkit.org/show_bug.cgi?id=112639
2011
2012         Reviewed by Michael Saboff.
2013         
2014         Change it to take a string instead.
2015
2016         * runtime/JSObject.h:
2017         (JSC):
2018         * runtime/ObjectPrototype.cpp:
2019         (JSC::ObjectPrototype::finishCreation):
2020         * runtime/StringPrototype.cpp:
2021         (JSC::StringPrototype::finishCreation):
2022
2023 2013-03-18  Brent Fulgham  <bfulgham@webkit.org>
2024
2025         [WinCairo] Get build working under VS2010.
2026         https://bugs.webkit.org/show_bug.cgi?id=112604
2027
2028         Reviewed by Tim Horton.
2029
2030         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Use CFLite-specific
2031         build target (standard version links against CoreFoundation.lib
2032         instead of CFLite.lib).
2033         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Added.
2034         * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Added.
2035         * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Added.
2036
2037 2013-03-18  Roger Fong  <roger_fong@apple.com>
2038
2039         AppleWin VS2010 Debug configuration build fix..
2040
2041         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2042
2043 2013-03-18  Brent Fulgham  <bfulgham@webkit.org>
2044
2045         [WinCairo] Get build working under VS2010.
2046         https://bugs.webkit.org/show_bug.cgi?id=112604
2047
2048         Reviewed by Tim Horton.
2049
2050         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add build targets for
2051         Debug_WinCairo and Release_WinCairo using CFLite.
2052         * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Added.
2053         * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Added.
2054         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
2055         Add Debug_WinCairo and Release_WinCairo build targets to
2056         make sure headers are copied to proper build folder.
2057         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Ditto.
2058         * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Added.
2059         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
2060         Add Debug_WinCairo and Release_WinCairo build targets to
2061         make sure headers are copied to proper build folder.
2062         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
2063         Ditto.
2064         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
2065         Ditto.
2066         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto.
2067         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto.
2068         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto.
2069
2070 2013-03-18  Michael Saboff  <msaboff@apple.com>
2071
2072         Potentially unsafe register allocations in DFG code generation
2073         https://bugs.webkit.org/show_bug.cgi?id=112477
2074
2075         Reviewed by Geoffrey Garen.
2076
2077         Moved allocation of temporary GPRs to be before any generated branches in the functions below.
2078
2079         * dfg/DFGSpeculativeJIT32_64.cpp:
2080         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2081         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2082         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2083         * dfg/DFGSpeculativeJIT64.cpp:
2084         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2085         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2086         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2087
2088 2013-03-15  Filip Pizlo  <fpizlo@apple.com>
2089
2090         DFG string conversions and allocations should be inlined
2091         https://bugs.webkit.org/show_bug.cgi?id=112376
2092
2093         Reviewed by Geoffrey Garen.
2094         
2095         This turns new String(), String(), String.prototype.valueOf(), and
2096         String.prototype.toString() into intrinsics. It gives the DFG the ability to handle
2097         conversions from StringObject to JSString and vice-versa, and also gives it the
2098         ability to handle cases where a variable may be either a StringObject or a JSString.
2099         To do this, I added StringObject to value profiling (and removed the stale
2100         distinction between Myarguments and Foreignarguments). I also cleaned up ToPrimitive
2101         handling, using some of the new functionality but also taking advantage of the
2102         existence of Identity(String:@a).
2103         
2104         This is a 2% SunSpider speed-up. Also there are some speed-ups on V8v7 and Kraken.
2105         On microbenchmarks that stress new String() this is a 14x speed-up.
2106
2107         * CMakeLists.txt:
2108         * DerivedSources.make:
2109         * DerivedSources.pri:
2110         * GNUmakefile.list.am:
2111         * bytecode/CodeBlock.h:
2112         (CodeBlock):
2113         (JSC::CodeBlock::hasExitSite):
2114         (JSC):
2115         * bytecode/DFGExitProfile.cpp:
2116         (JSC::DFG::ExitProfile::hasExitSite):
2117         (DFG):
2118         * bytecode/DFGExitProfile.h:
2119         (ExitProfile):
2120         (JSC::DFG::ExitProfile::hasExitSite):
2121         * bytecode/ExitKind.cpp:
2122         (JSC::exitKindToString):
2123         * bytecode/ExitKind.h:
2124         * bytecode/SpeculatedType.cpp:
2125         (JSC::dumpSpeculation):
2126         (JSC::speculationToAbbreviatedString):
2127         (JSC::speculationFromClassInfo):
2128         * bytecode/SpeculatedType.h:
2129         (JSC):
2130         (JSC::isStringObjectSpeculation):
2131         (JSC::isStringOrStringObjectSpeculation):
2132         * create_hash_table:
2133         * dfg/DFGAbstractState.cpp:
2134         (JSC::DFG::AbstractState::executeEffects):
2135         * dfg/DFGAbstractState.h:
2136         (JSC::DFG::AbstractState::filterEdgeByUse):
2137         * dfg/DFGByteCodeParser.cpp:
2138         (ByteCodeParser):
2139         (JSC::DFG::ByteCodeParser::handleCall):
2140         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
2141         (DFG):
2142         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2143         * dfg/DFGCSEPhase.cpp:
2144         (JSC::DFG::CSEPhase::putStructureStoreElimination):
2145         * dfg/DFGEdge.h:
2146         (JSC::DFG::Edge::shift):
2147         * dfg/DFGFixupPhase.cpp:
2148         (JSC::DFG::FixupPhase::fixupNode):
2149         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
2150         (FixupPhase):
2151         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
2152         (JSC::DFG::FixupPhase::observeUseKindOnNode):
2153         * dfg/DFGGraph.h:
2154         (JSC::DFG::Graph::hasGlobalExitSite):
2155         (Graph):
2156         (JSC::DFG::Graph::hasExitSite):
2157         (JSC::DFG::Graph::clobbersWorld):
2158         * dfg/DFGNode.h:
2159         (JSC::DFG::Node::convertToToString):
2160         (Node):
2161         (JSC::DFG::Node::hasStructure):
2162         (JSC::DFG::Node::shouldSpeculateStringObject):
2163         (JSC::DFG::Node::shouldSpeculateStringOrStringObject):
2164         * dfg/DFGNodeType.h:
2165         (DFG):
2166         * dfg/DFGOperations.cpp:
2167         * dfg/DFGOperations.h:
2168         * dfg/DFGPredictionPropagationPhase.cpp:
2169         (JSC::DFG::PredictionPropagationPhase::propagate):
2170         * dfg/DFGSpeculativeJIT.cpp:
2171         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
2172         (DFG):
2173         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
2174         (JSC::DFG::SpeculativeJIT::speculateObject):
2175         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
2176         (JSC::DFG::SpeculativeJIT::speculateString):
2177         (JSC::DFG::SpeculativeJIT::speculateStringObject):
2178         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
2179         (JSC::DFG::SpeculativeJIT::speculate):
2180         * dfg/DFGSpeculativeJIT.h:
2181         (JSC::DFG::SpeculativeJIT::callOperation):
2182         (SpeculativeJIT):
2183         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
2184         (DFG):
2185         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
2186         * dfg/DFGSpeculativeJIT32_64.cpp:
2187         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2188         (JSC::DFG::SpeculativeJIT::compile):
2189         * dfg/DFGSpeculativeJIT64.cpp:
2190         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2191         (JSC::DFG::SpeculativeJIT::compile):
2192         * dfg/DFGUseKind.cpp:
2193         (WTF::printInternal):
2194         * dfg/DFGUseKind.h:
2195         (JSC::DFG::typeFilterFor):
2196         * interpreter/CallFrame.h:
2197         (JSC::ExecState::regExpPrototypeTable):
2198         * runtime/CommonIdentifiers.h:
2199         * runtime/Intrinsic.h:
2200         * runtime/JSDestructibleObject.h:
2201         (JSDestructibleObject):
2202         (JSC::JSDestructibleObject::classInfoOffset):
2203         * runtime/JSGlobalData.cpp:
2204         (JSC):
2205         (JSC::JSGlobalData::JSGlobalData):
2206         (JSC::JSGlobalData::~JSGlobalData):
2207         * runtime/JSGlobalData.h:
2208         (JSGlobalData):
2209         * runtime/JSObject.cpp:
2210         * runtime/JSObject.h:
2211         (JSC):
2212         * runtime/JSWrapperObject.h:
2213         (JSC::JSWrapperObject::allocationSize):
2214         (JSWrapperObject):
2215         (JSC::JSWrapperObject::internalValueOffset):
2216         (JSC::JSWrapperObject::internalValueCellOffset):
2217         * runtime/StringPrototype.cpp:
2218         (JSC):
2219         (JSC::StringPrototype::finishCreation):
2220         (JSC::StringPrototype::create):
2221         * runtime/StringPrototype.h:
2222         (StringPrototype):
2223
2224 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
2225
2226         ObjectPrototype properties should be eagerly created rather than lazily via static tables
2227         https://bugs.webkit.org/show_bug.cgi?id=112539
2228
2229         Reviewed by Oliver Hunt.
2230         
2231         This is the first part of https://bugs.webkit.org/show_bug.cgi?id=112233. Rolling this
2232         in first since it's the less-likely-to-be-broken part.
2233
2234         * CMakeLists.txt:
2235         * DerivedSources.make:
2236         * DerivedSources.pri:
2237         * GNUmakefile.list.am:
2238         * interpreter/CallFrame.h:
2239         (JSC::ExecState::objectConstructorTable):
2240         * runtime/CommonIdentifiers.h:
2241         * runtime/JSGlobalData.cpp:
2242         (JSC):
2243         (JSC::JSGlobalData::JSGlobalData):
2244         (JSC::JSGlobalData::~JSGlobalData):
2245         * runtime/JSGlobalData.h:
2246         (JSGlobalData):
2247         * runtime/JSObject.cpp:
2248         (JSC::JSObject::putDirectNativeFunction):
2249         (JSC):
2250         * runtime/JSObject.h:
2251         (JSObject):
2252         (JSC):
2253         * runtime/Lookup.cpp:
2254         (JSC::setUpStaticFunctionSlot):
2255         * runtime/ObjectPrototype.cpp:
2256         (JSC):
2257         (JSC::ObjectPrototype::finishCreation):
2258         (JSC::ObjectPrototype::create):
2259         * runtime/ObjectPrototype.h:
2260         (ObjectPrototype):
2261
2262 2013-03-16  Pratik Solanki  <psolanki@apple.com>
2263
2264         Disable High DPI Canvas on iOS
2265         https://bugs.webkit.org/show_bug.cgi?id=112511
2266
2267         Reviewed by Joseph Pecoraro.
2268
2269         * Configurations/FeatureDefines.xcconfig:
2270
2271 2013-03-15  Andreas Kling  <akling@apple.com>
2272
2273         Don't also clone StructureRareData when cloning Structure.
2274         <http://webkit.org/b/111672>
2275
2276         Reviewed by Mark Hahnenberg.
2277
2278         We were cloning a lot of StructureRareData with only the previousID pointer set since
2279         the enumerationCache is not shared between clones.
2280
2281         Let the Structure copy constructor decide whether it wants to clone the rare data.
2282         The decision is made by StructureRareData::needsCloning() and will currently always
2283         return false, since StructureRareData only holds on to caches at present.
2284         This may change in the future as more members are added to StructureRareData.
2285
2286         * runtime/Structure.cpp:
2287         (JSC::Structure::Structure):
2288         (JSC::Structure::cloneRareDataFrom):
2289         * runtime/StructureInlines.h:
2290         (JSC::Structure::create):
2291
2292 2013-03-15  Mark Hahnenberg  <mhahnenberg@apple.com>
2293
2294         Roll out r145838
2295         https://bugs.webkit.org/show_bug.cgi?id=112458
2296
2297         Unreviewed. Requested by Filip Pizlo.
2298
2299         * CMakeLists.txt:
2300         * DerivedSources.make:
2301         * DerivedSources.pri:
2302         * GNUmakefile.list.am:
2303         * dfg/DFGOperations.cpp:
2304         * interpreter/CallFrame.h:
2305         (JSC::ExecState::objectPrototypeTable):
2306         * jit/JITStubs.cpp:
2307         (JSC::getByVal):
2308         * llint/LLIntSlowPaths.cpp:
2309         (JSC::LLInt::getByVal):
2310         * runtime/CommonIdentifiers.h:
2311         * runtime/JSCell.cpp:
2312         (JSC):
2313         * runtime/JSCell.h:
2314         (JSCell):
2315         * runtime/JSCellInlines.h:
2316         (JSC):
2317         (JSC::JSCell::fastGetOwnProperty):
2318         * runtime/JSGlobalData.cpp:
2319         (JSC):
2320         (JSC::JSGlobalData::JSGlobalData):
2321         (JSC::JSGlobalData::~JSGlobalData):
2322         * runtime/JSGlobalData.h:
2323         (JSGlobalData):
2324         * runtime/JSObject.cpp:
2325         (JSC):
2326         * runtime/JSObject.h:
2327         (JSObject):
2328         (JSC):
2329         * runtime/Lookup.cpp:
2330         (JSC::setUpStaticFunctionSlot):
2331         * runtime/ObjectPrototype.cpp:
2332         (JSC):
2333         (JSC::ObjectPrototype::finishCreation):
2334         (JSC::ObjectPrototype::getOwnPropertySlot):
2335         (JSC::ObjectPrototype::getOwnPropertyDescriptor):
2336         * runtime/ObjectPrototype.h:
2337         (JSC::ObjectPrototype::create):
2338         (ObjectPrototype):
2339         * runtime/PropertyMapHashTable.h:
2340         (JSC::PropertyTable::findWithString):
2341         * runtime/Structure.h:
2342         (Structure):
2343         * runtime/StructureInlines.h:
2344         (JSC::Structure::get):
2345
2346 2013-03-15  Michael Saboff  <msaboff@apple.com>
2347
2348         Cleanup of DFG and Baseline JIT debugging code
2349         https://bugs.webkit.org/show_bug.cgi?id=111871
2350
2351         Reviewed by Geoffrey Garen.
2352
2353         Fixed various debug related issue in baseline and DFG JITs. See below.
2354
2355         * dfg/DFGRepatch.cpp:
2356         (JSC::DFG::dfgLinkClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
2357         * dfg/DFGScratchRegisterAllocator.h: Now use ScratchBuffer::activeLengthPtr() to get
2358         pointer to scratch register length.
2359         (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
2360         (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
2361         * dfg/DFGSpeculativeJIT.cpp:
2362         (JSC::DFG::SpeculativeJIT::checkConsistency): Added missing case labels for DataFormatOSRMarker,
2363         DataFormatDead, and DataFormatArguments and made them RELEASE_ASSERT_NOT_REACHED();
2364         * jit/JITCall.cpp:
2365         (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
2366         * jit/JITCall32_64.cpp:
2367         (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
2368         * runtime/JSGlobalData.h:
2369         (JSC::ScratchBuffer::ScratchBuffer): Fixed buffer allocation alignment to
2370         be on a double boundary.
2371         (JSC::ScratchBuffer::setActiveLength):
2372         (JSC::ScratchBuffer::activeLength):
2373         (JSC::ScratchBuffer::activeLengthPtr):
2374
2375 2013-03-15  Michael Saboff  <msaboff@apple.com>
2376
2377         Add runtime check for improper register allocations in DFG
2378         https://bugs.webkit.org/show_bug.cgi?id=112380
2379
2380         Reviewed by Geoffrey Garen.
2381
2382         Added framework to check for register allocation within a branch source - target range.  All register allocations
2383         are saved using the offset in the code stream where the allocation occurred.  Later when a jump is linked, the
2384         currently saved register allocations are checked to make sure that they didn't occur in the range of code that was
2385         jumped over.  This protects against the case where an allocation could have spilled register contents to free up 
2386         a register and that spill only occurs on one path of a many through the code.  A subsequent fill of the spilled
2387         register may load garbage.  See https://bugs.webkit.org/show_bug.cgi?id=111777 for one such bug.
2388         This code is protected by the compile time check of #if ENABLE(DFG_REGISTER_ALLOCATION_VALIDATION).
2389         The check is only done during the processing of SpeculativeJIT::compile(Node* node) and its callees.
2390  
2391         * assembler/AbstractMacroAssembler.h:
2392         (JSC::AbstractMacroAssembler::Jump::link): Invoke register allocation checks using source and target of link.
2393         (JSC::AbstractMacroAssembler::Jump::linkTo): Invoke register allocation checks using source and target of link.
2394         (AbstractMacroAssembler):
2395         (RegisterAllocationOffset): New helper class to store the instruction stream offset and compare against a 
2396         jump range.
2397         (JSC::AbstractMacroAssembler::RegisterAllocationOffset::RegisterAllocationOffset):
2398         (JSC::AbstractMacroAssembler::RegisterAllocationOffset::check):
2399         (JSC::AbstractMacroAssembler::addRegisterAllocationAtOffset):
2400         (JSC::AbstractMacroAssembler::clearRegisterAllocationOffsets): 
2401         (JSC::AbstractMacroAssembler::checkRegisterAllocationAgainstBranchRange):
2402         * dfg/DFGSpeculativeJIT.h:
2403         (JSC::DFG::SpeculativeJIT::allocate):
2404         * dfg/DFGSpeculativeJIT32_64.cpp:
2405         (JSC::DFG::SpeculativeJIT::compile):
2406         * dfg/DFGSpeculativeJIT64.cpp:
2407         (JSC::DFG::SpeculativeJIT::compile):
2408
2409 2013-03-14  Oliver Hunt  <oliver@apple.com>
2410
2411         REGRESSION(r145000): Crash loading arstechnica.com when Safari Web Inspector is open
2412         https://bugs.webkit.org/show_bug.cgi?id=111868
2413
2414         Reviewed by Antti Koivisto.
2415
2416         Don't allow non-local property lookup when the debugger is enabled.
2417
2418         * bytecompiler/BytecodeGenerator.cpp:
2419         (JSC::BytecodeGenerator::resolve):
2420
2421 2013-03-11  Mark Hahnenberg  <mhahnenberg@apple.com>
2422
2423         Objective-C API: Objective-C functions exposed to JavaScript have the wrong type (object instead of function)
2424         https://bugs.webkit.org/show_bug.cgi?id=105892
2425
2426         Reviewed by Geoffrey Garen.
2427
2428         Changed ObjCCallbackFunction to subclass JSCallbackFunction which already has all of the machinery to call
2429         functions using the C API. Since ObjCCallbackFunction is now a JSCell, we changed the old implementation of
2430         ObjCCallbackFunction to be the internal implementation and keep track of all the proper data so that we 
2431         don't have to put all of that in the header, which will now be included from C++ files (e.g. JSGlobalObject.cpp).
2432
2433         * API/JSCallbackFunction.cpp: Change JSCallbackFunction to allow subclassing. Originally it was internally
2434         passing its own Structure up the chain of constructors, but we now want to be able to pass other Structures as well.
2435         (JSC::JSCallbackFunction::JSCallbackFunction):
2436         (JSC::JSCallbackFunction::create):
2437         * API/JSCallbackFunction.h:
2438         (JSCallbackFunction):
2439         * API/JSWrapperMap.mm: Changed interface to tryUnwrapBlock.
2440         (tryUnwrapObjcObject):
2441         * API/ObjCCallbackFunction.h:
2442         (ObjCCallbackFunction): Moved into the JSC namespace, just like JSCallbackFunction.
2443         (JSC::ObjCCallbackFunction::createStructure): Overridden so that the correct ClassInfo gets used since we have 
2444         a destructor.
2445         (JSC::ObjCCallbackFunction::impl): Getter for the internal impl.
2446         * API/ObjCCallbackFunction.mm:
2447         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): What used to be ObjCCallbackFunction is now 
2448         ObjCCallbackFunctionImpl. It handles the Objective-C specific parts of managing callback functions.
2449         (JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl):
2450         (JSC::objCCallbackFunctionCallAsFunction): Same as the old one, but now it casts to ObjCCallbackFunction and grabs the impl 
2451         rather than using JSObjectGetPrivate.
2452         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): New bits to allow being part of the JSCell hierarchy.
2453         (JSC::ObjCCallbackFunction::create):
2454         (JSC::ObjCCallbackFunction::destroy):
2455         (JSC::ObjCCallbackFunctionImpl::call): Handles the actual invocation, just like it used to.
2456         (objCCallbackFunctionForInvocation):
2457         (tryUnwrapBlock): Changed to check the ClassInfo for inheritance directly, rather than going through the C API call.
2458         * API/tests/testapi.mm: Added new test to make sure that doing Function.prototype.toString.call(f) won't result in 
2459         an error when f is an Objective-C method or block underneath the covers.
2460         * runtime/JSGlobalObject.cpp: Added new Structure for ObjCCallbackFunction.
2461         (JSC::JSGlobalObject::reset):
2462         (JSC::JSGlobalObject::visitChildren):
2463         * runtime/JSGlobalObject.h:
2464         (JSGlobalObject):
2465         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
2466
2467 2013-03-14  Mark Hahnenberg  <mhahnenberg@apple.com>
2468
2469         Objective-C API: Nested dictionaries are not converted properly in the Objective-C binding
2470         https://bugs.webkit.org/show_bug.cgi?id=112377
2471
2472         Reviewed by Oliver Hunt.
2473
2474         Accidental reassignment of the root task in the container conversion logic was causing the last 
2475         array or dictionary processed to be returned in the case of nested containers.
2476
2477         * API/JSValue.mm:
2478         (containerValueToObject):
2479         * API/tests/testapi.mm:
2480
2481 2013-03-13  Filip Pizlo  <fpizlo@apple.com>
2482
2483         JSObject fast by-string access optimizations should work even on the prototype chain, and even when the result is undefined
2484         https://bugs.webkit.org/show_bug.cgi?id=112233
2485
2486         Reviewed by Oliver Hunt.
2487         
2488         Extended the existing fast access path for String keys to work over the entire prototype chain,
2489         not just the self access case. This will fail as soon as it sees an object that intercepts
2490         getOwnPropertySlot, so this patch also ensures that ObjectPrototype does not fall into that
2491         category. This is accomplished by making ObjectPrototype eagerly reify all of its properties.
2492         This is safe for ObjectPrototype because it's so common and we expect all of its properties to
2493         be reified for any interesting programs anyway. A new idiom for adding native functions to
2494         prototypes is introduced, which ought to work well for any other prototypes that we wish to do
2495         this conversion for.
2496         
2497         This is a >60% speed-up in the case that you frequently do by-string lookups that "miss", i.e.
2498         they don't turn up anything.
2499
2500         * CMakeLists.txt:
2501         * DerivedSources.make:
2502         * DerivedSources.pri:
2503         * GNUmakefile.list.am:
2504         * dfg/DFGOperations.cpp:
2505         * interpreter/CallFrame.h:
2506         (JSC::ExecState::objectConstructorTable):
2507         * jit/JITStubs.cpp:
2508         (JSC::getByVal):
2509         * llint/LLIntSlowPaths.cpp:
2510         (JSC::LLInt::getByVal):
2511         * runtime/CommonIdentifiers.h:
2512         * runtime/JSCell.cpp:
2513         (JSC::JSCell::getByStringSlow):
2514         (JSC):
2515         * runtime/JSCell.h:
2516         (JSCell):
2517         * runtime/JSCellInlines.h:
2518         (JSC):
2519         (JSC::JSCell::getByStringAndKey):
2520         (JSC::JSCell::getByString):
2521         * runtime/JSGlobalData.cpp:
2522         (JSC):
2523         (JSC::JSGlobalData::JSGlobalData):
2524         (JSC::JSGlobalData::~JSGlobalData):
2525         * runtime/JSGlobalData.h:
2526         (JSGlobalData):
2527         * runtime/JSObject.cpp:
2528         (JSC::JSObject::putDirectNativeFunction):
2529         (JSC):
2530         * runtime/JSObject.h:
2531         (JSObject):
2532         (JSC):
2533         * runtime/Lookup.cpp:
2534         (JSC::setUpStaticFunctionSlot):
2535         * runtime/ObjectPrototype.cpp:
2536         (JSC):
2537         (JSC::ObjectPrototype::finishCreation):
2538         (JSC::ObjectPrototype::create):
2539         * runtime/ObjectPrototype.h:
2540         (ObjectPrototype):
2541         * runtime/PropertyMapHashTable.h:
2542         (JSC::PropertyTable::findWithString):
2543         * runtime/Structure.h:
2544         (Structure):
2545         * runtime/StructureInlines.h:
2546         (JSC::Structure::get):
2547         (JSC):
2548
2549 2013-03-13  Filip Pizlo  <fpizlo@apple.com>
2550
2551         DFG bytecode parser is too aggressive about getting rid of GetLocals on captured variables
2552         https://bugs.webkit.org/show_bug.cgi?id=112287
2553         <rdar://problem/13342340>
2554
2555         Reviewed by Oliver Hunt.
2556
2557         * bytecode/CodeBlock.cpp:
2558         (JSC::CodeBlock::dumpBytecode):
2559         (JSC::CodeBlock::finalizeUnconditionally):
2560         * dfg/DFGByteCodeParser.cpp:
2561         (JSC::DFG::ByteCodeParser::getLocal):
2562
2563 2013-03-13  Ryosuke Niwa  <rniwa@webkit.org>
2564
2565         Threaded HTML Parser is missing feature define flags in all but Chromium port's build files
2566         https://bugs.webkit.org/show_bug.cgi?id=112277
2567
2568         Reviewed by Adam Barth.
2569
2570         * Configurations/FeatureDefines.xcconfig:
2571
2572 2013-03-13  Csaba Osztrogonác  <ossy@webkit.org>
2573
2574         LLINT C loop warning fix for GCC
2575         https://bugs.webkit.org/show_bug.cgi?id=112145
2576
2577         Reviewed by Filip Pizlo.
2578
2579         * llint/LowLevelInterpreter.cpp:
2580         (JSC::CLoop::execute):
2581
2582 2013-02-13  Simon Hausmann  <simon.hausmann@digia.com>
2583
2584         Add support for convenient conversion from JSStringRef to QString
2585         https://bugs.webkit.org/show_bug.cgi?id=109694
2586
2587         Reviewed by Allan Sandfeld Jensen.
2588
2589         Add JSStringCopyQString helper function that allows for the convenient
2590         extraction of a QString out of a JSStringRef.
2591
2592         * API/JSStringRefQt.cpp: Added.
2593         (JSStringCopyQString):
2594         * API/JSStringRefQt.h: Added.
2595         * API/OpaqueJSString.h:
2596         (OpaqueJSString):
2597         (OpaqueJSString::qString):
2598         (OpaqueJSString::OpaqueJSString):
2599         * Target.pri:
2600
2601 2013-03-13  Peter Gal  <galpeter@inf.u-szeged.hu>
2602
2603         Token 'not' is ignored in the offlineasm.
2604         https://bugs.webkit.org/show_bug.cgi?id=111568
2605
2606         Reviewed by Filip Pizlo.
2607
2608         * offlineasm/parser.rb: Build the Not AST node if the 'not' token is found.
2609
2610 2013-03-12  Tim Horton  <timothy_horton@apple.com>
2611
2612         WTF uses macros for exports. Try to fix the Windows build. Unreviewed.
2613
2614         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
2615         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2616
2617 2013-03-12  Filip Pizlo  <fpizlo@apple.com>
2618
2619         Array.prototype.sort should at least try to be PTIME even when the array is in some bizarre mode
2620         https://bugs.webkit.org/show_bug.cgi?id=112187
2621         <rdar://problem/13393550>
2622
2623         Reviewed by Michael Saboff and Gavin Barraclough.
2624         
2625         If we have an array-like object in crazy mode passed into Array.prototype.sort, and its length is large,
2626         then first copy all elements into a separate, compact, un-holy array and sort that. Then copy back.
2627         This means that sorting will be at worst O(n^2) in the actual number of things in the array, rather than
2628         O(n^2) in the array's length.
2629
2630         * runtime/ArrayPrototype.cpp:
2631         (JSC::attemptFastSort):
2632         (JSC::performSlowSort):
2633         (JSC):
2634         (JSC::arrayProtoFuncSort):
2635
2636 2013-03-12  Tim Horton  <timothy_horton@apple.com>
2637
2638         Try to fix the Windows build.
2639
2640         Not reviewed.
2641
2642         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
2643
2644 2013-03-12  Geoffrey Garen  <ggaren@apple.com>
2645
2646         Try to fix the Windows build.
2647
2648         Not reviewed.
2649
2650         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2651         Export a thing.
2652
2653 2013-03-11  Oliver Hunt  <oliver@apple.com>
2654
2655         Harden JSStringJoiner
2656         https://bugs.webkit.org/show_bug.cgi?id=112093
2657
2658         Reviewed by Filip Pizlo.
2659
2660         Harden JSStringJoiner, make it use our CheckedArithmetic
2661         class to simplify everything.
2662
2663         * runtime/JSStringJoiner.cpp:
2664         (JSC::JSStringJoiner::build):
2665         * runtime/JSStringJoiner.h:
2666         (JSStringJoiner):
2667         (JSC::JSStringJoiner::JSStringJoiner):
2668         (JSC::JSStringJoiner::append):
2669
2670 2013-03-12  Filip Pizlo  <fpizlo@apple.com>
2671
2672         DFG generic array access cases should not be guarded by CheckStructure even of the profiling tells us that it could be
2673         https://bugs.webkit.org/show_bug.cgi?id=112183
2674
2675         Reviewed by Oliver Hunt.
2676         
2677         Slight speed-up on string-unpack-code.
2678
2679         * dfg/DFGFixupPhase.cpp:
2680         (JSC::DFG::FixupPhase::findAndRemoveUnnecessaryStructureCheck):
2681         (FixupPhase):
2682         (JSC::DFG::FixupPhase::checkArray):
2683         (JSC::DFG::FixupPhase::blessArrayOperation):
2684
2685 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>
2686
2687         https://bugs.webkit.org/show_bug.cgi?id=112141
2688         LLInt CLoop backend misses Double2Ints() on 32bit architectures
2689
2690         Reviewed by Filip Pizlo.
2691
2692         Implement Double2Ints() in CLoop backend of LLInt on 32bit architectures.
2693
2694         * llint/LowLevelInterpreter.cpp:
2695         (LLInt):
2696         (JSC::LLInt::Double2Ints):
2697         * offlineasm/cloop.rb:
2698
2699 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>
2700
2701         Making more sophisticated cache flush on ARM Linux platform
2702         https://bugs.webkit.org/show_bug.cgi?id=111854
2703
2704         Reviewed by Zoltan Herczeg.
2705
2706         The cache flush on ARM Linux invalidates whole pages
2707         instead of just the required area.
2708
2709         * assembler/ARMAssembler.h:
2710         (ARMAssembler):
2711         (JSC::ARMAssembler::linuxPageFlush):
2712         (JSC::ARMAssembler::cacheFlush):
2713         * assembler/ARMv7Assembler.h:
2714         (ARMv7Assembler):
2715         (JSC::ARMv7Assembler::linuxPageFlush):
2716         (JSC::ARMv7Assembler::cacheFlush):
2717
2718 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>
2719
2720         Renaming the armv7.rb LLINT backend to arm.rb
2721         https://bugs.webkit.org/show_bug.cgi?id=110565
2722
2723         Reviewed by Zoltan Herczeg.
2724
2725         This is the first step of a unified ARM backend for
2726         all ARM 32 bit architectures in LLInt.
2727
2728         * CMakeLists.txt:
2729         * GNUmakefile.list.am:
2730         * JavaScriptCore.gypi:
2731         * LLIntOffsetsExtractor.pro:
2732         * offlineasm/arm.rb: Copied from Source/JavaScriptCore/offlineasm/armv7.rb.
2733         * offlineasm/armv7.rb: Removed.
2734         * offlineasm/backends.rb:
2735         * offlineasm/risc.rb:
2736
2737 2013-03-12  Csaba Osztrogonác  <ossy@webkit.org>
2738
2739         REGRESSION(r145482): It broke 33 jsc tests and zillion layout tests on all platform
2740         https://bugs.webkit.org/show_bug.cgi?id=112112
2741
2742         Reviewed by Oliver Hunt.
2743
2744         Rolling out https://trac.webkit.org/changeset/145482 to unbreak the bots.
2745
2746         * runtime/JSStringJoiner.cpp:
2747         (JSC::JSStringJoiner::build):
2748         * runtime/JSStringJoiner.h:
2749         (JSStringJoiner):
2750         (JSC::JSStringJoiner::JSStringJoiner):
2751         (JSC::JSStringJoiner::append):
2752
2753 2013-03-12  Filip Pizlo  <fpizlo@apple.com>
2754
2755         DFG prediction propagation phase should not rerun forward propagation if double voting has already converged
2756         https://bugs.webkit.org/show_bug.cgi?id=111920
2757
2758         Reviewed by Oliver Hunt.
2759         
2760         I don't know why we weren't exiting early after double voting if !m_changed.
2761         
2762         This change also removes backwards propagation from the voting fixpoint, since at that
2763         point short-circuiting loops is probably not particularly profitable. Profiling shows
2764         that this reduces the time spent in prediction propagation even further.
2765         
2766         This change appears to be a 1% SunSpider speed-up.
2767
2768         * dfg/DFGPredictionPropagationPhase.cpp:
2769         (JSC::DFG::PredictionPropagationPhase::run):
2770
2771 2013-03-11  Filip Pizlo  <fpizlo@apple.com>
2772
2773         DFG overflow check elimination is too smart for its own good
2774         https://bugs.webkit.org/show_bug.cgi?id=111832
2775
2776         Reviewed by Oliver Hunt and Gavin Barraclough.
2777         
2778         Rolling this back in after fixing accidental misuse of JSValue. The code was doing value < someInt
2779         rather than value.asInt32() < someInt. This "worked" when isWithinPowerOfTwo wasn't templatized.
2780         It worked by always being false and always disabling the relvant optimization.
2781         
2782         This improves overflow check elimination in three ways:
2783         
2784         1) It reduces the amount of time the compiler will spend doing it.
2785         
2786         2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation
2787            over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children)
2788            are int32's and then perform a possibly-overflowing operation, we must be careful not to assume
2789            that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that
2790            @b->children are int32's and that hence @b might produce a large enough result that doubles would
2791            start chopping low bits. The specific implication of this is that for a binary operation to not
2792            propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one
2793            of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such
2794            operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the
2795            latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that
2796            large won't even make it into the DFG currently.
2797         
2798         3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub
2799            are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate
2800            NodeUsedAsNumber to either @a or @b.
2801         
2802         This is neutral on V8v7 and a slight speed-up on compile time benchmarks.
2803
2804         * CMakeLists.txt:
2805         * GNUmakefile.list.am:
2806         * JavaScriptCore.xcodeproj/project.pbxproj:
2807         * Target.pri:
2808         * dfg/DFGArrayMode.cpp:
2809         (JSC::DFG::ArrayMode::refine):
2810         * dfg/DFGBackwardsPropagationPhase.cpp: Added.
2811         (DFG):
2812         (BackwardsPropagationPhase):
2813         (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase):
2814         (JSC::DFG::BackwardsPropagationPhase::run):
2815         (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
2816         (JSC::DFG::BackwardsPropagationPhase::isNotZero):
2817         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant):
2818         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive):
2819         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
2820         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
2821         (JSC::DFG::BackwardsPropagationPhase::propagate):
2822         (JSC::DFG::performBackwardsPropagation):
2823         * dfg/DFGBackwardsPropagationPhase.h: Added.
2824         (DFG):
2825         * dfg/DFGCPSRethreadingPhase.cpp:
2826         (JSC::DFG::CPSRethreadingPhase::run):
2827         (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom):
2828         (CPSRethreadingPhase):
2829         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2830         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2831         * dfg/DFGDriver.cpp:
2832         (JSC::DFG::compile):
2833         * dfg/DFGGraph.cpp:
2834         (JSC::DFG::Graph::dump):
2835         * dfg/DFGNodeFlags.cpp:
2836         (JSC::DFG::dumpNodeFlags):
2837         (DFG):
2838         * dfg/DFGNodeFlags.h:
2839         (DFG):
2840         * dfg/DFGPredictionPropagationPhase.cpp:
2841         (PredictionPropagationPhase):
2842         (JSC::DFG::PredictionPropagationPhase::propagate):
2843         * dfg/DFGUnificationPhase.cpp:
2844         (JSC::DFG::UnificationPhase::run):
2845         * dfg/DFGVariableAccessData.h:
2846         (JSC::DFG::VariableAccessData::VariableAccessData):
2847         (JSC::DFG::VariableAccessData::mergeIsLoadedFrom):
2848         (VariableAccessData):
2849         (JSC::DFG::VariableAccessData::setIsLoadedFrom):
2850         (JSC::DFG::VariableAccessData::isLoadedFrom):
2851
2852 2013-03-11  Oliver Hunt  <oliver@apple.com>
2853
2854         Harden JSStringJoiner
2855         https://bugs.webkit.org/show_bug.cgi?id=112093
2856
2857         Reviewed by Filip Pizlo.
2858
2859         Harden JSStringJoiner, make it use our CheckedArithmetic
2860         class to simplify everything.
2861
2862         * runtime/JSStringJoiner.cpp:
2863         (JSC::JSStringJoiner::build):
2864         * runtime/JSStringJoiner.h:
2865         (JSStringJoiner):
2866         (JSC::JSStringJoiner::JSStringJoiner):
2867         (JSC::JSStringJoiner::append):
2868
2869 2013-03-11  Michael Saboff  <msaboff@apple.com>
2870
2871         Crash beneath operationCreateInlinedArguments running fast/js/dfg-create-inlined-arguments-in-closure-inline.html (32-bit only)
2872         https://bugs.webkit.org/show_bug.cgi?id=112067
2873
2874         Reviewed by Geoffrey Garen.
2875
2876         We weren't setting the tag in SetCallee.  Therefore set it to CellTag.
2877
2878         * dfg/DFGSpeculativeJIT32_64.cpp:
2879         (JSC::DFG::SpeculativeJIT::compile):
2880
2881 2013-03-11  Oliver Hunt  <oliver@apple.com>
2882
2883         Make SegmentedVector Noncopyable
2884         https://bugs.webkit.org/show_bug.cgi?id=112059
2885
2886         Reviewed by Geoffrey Garen.
2887
2888         Copying a SegmentedVector is very expensive, and really shouldn't
2889         be necessary.  So I've taken the one place where we currently copy
2890         and replaced it with a regular Vector, and replaced the address
2891         dependent logic with a indexing ref instead.
2892
2893         * bytecompiler/BytecodeGenerator.cpp:
2894         (JSC::BytecodeGenerator::newLabelScope):
2895         (JSC::BytecodeGenerator::emitComplexJumpScopes):
2896         * bytecompiler/BytecodeGenerator.h:
2897         (BytecodeGenerator):
2898         * bytecompiler/LabelScope.h:
2899         (JSC):
2900         (JSC::LabelScopePtr::LabelScopePtr):
2901         (LabelScopePtr):
2902         (JSC::LabelScopePtr::operator=):
2903         (JSC::LabelScopePtr::~LabelScopePtr):
2904         (JSC::LabelScopePtr::operator*):
2905         (JSC::LabelScopePtr::operator->):
2906         * bytecompiler/NodesCodegen.cpp:
2907         (JSC::DoWhileNode::emitBytecode):
2908         (JSC::WhileNode::emitBytecode):
2909         (JSC::ForNode::emitBytecode):
2910         (JSC::ForInNode::emitBytecode):
2911         (JSC::SwitchNode::emitBytecode):
2912         (JSC::LabelNode::emitBytecode):
2913
2914 2013-03-10  Andreas Kling  <akling@apple.com>
2915
2916         SpeculativeJIT should use OwnPtr<SlowPathGenerator>.
2917         <http://webkit.org/b/111942>
2918
2919         Reviewed by Anders Carlsson.
2920
2921         There's no need to include DFGSlowPathGenerator.h from the header as long as the destructor is out-of-line,
2922         so let's use OwnPtr instead of raw pointers + deleteAllValues().
2923
2924         * dfg/DFGSpeculativeJIT.cpp:
2925         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
2926         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
2927         * dfg/DFGSpeculativeJIT.h:
2928         (SpeculativeJIT):
2929
2930 2013-03-09  Sheriff Bot  <webkit.review.bot@gmail.com>
2931
2932         Unreviewed, rolling out r145299.
2933         http://trac.webkit.org/changeset/145299
2934         https://bugs.webkit.org/show_bug.cgi?id=111928
2935
2936         compilation failure with recent clang
2937         (DFGBackwardsPropagationPhase.cpp:132:35: error: comparison of
2938         constant 10 with expression of type 'bool' is always false)
2939         (Requested by thorton on #webkit).
2940
2941         * CMakeLists.txt:
2942         * GNUmakefile.list.am:
2943         * JavaScriptCore.xcodeproj/project.pbxproj:
2944         * Target.pri:
2945         * dfg/DFGArrayMode.cpp:
2946         (JSC::DFG::ArrayMode::refine):
2947         * dfg/DFGBackwardsPropagationPhase.cpp: Removed.
2948         * dfg/DFGBackwardsPropagationPhase.h: Removed.
2949         * dfg/DFGCPSRethreadingPhase.cpp:
2950         (JSC::DFG::CPSRethreadingPhase::run):
2951         (CPSRethreadingPhase):
2952         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2953         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2954         * dfg/DFGDriver.cpp:
2955         (JSC::DFG::compile):
2956         * dfg/DFGGraph.cpp:
2957         (JSC::DFG::Graph::dump):
2958         * dfg/DFGNodeFlags.cpp:
2959         (JSC::DFG::nodeFlagsAsString):
2960         (DFG):
2961         * dfg/DFGNodeFlags.h:
2962         (DFG):
2963         * dfg/DFGPredictionPropagationPhase.cpp:
2964         (JSC::DFG::PredictionPropagationPhase::isNotNegZero):
2965         (PredictionPropagationPhase):
2966         (JSC::DFG::PredictionPropagationPhase::isNotZero):
2967         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant):
2968         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive):
2969         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo):
2970         (JSC::DFG::PredictionPropagationPhase::propagate):
2971         (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags):
2972         * dfg/DFGUnificationPhase.cpp:
2973         (JSC::DFG::UnificationPhase::run):
2974         * dfg/DFGVariableAccessData.h:
2975         (JSC::DFG::VariableAccessData::VariableAccessData):
2976         (VariableAccessData):
2977
2978 2013-03-08  Filip Pizlo  <fpizlo@apple.com>
2979
2980         DFG overflow check elimination is too smart for its own good
2981         https://bugs.webkit.org/show_bug.cgi?id=111832
2982
2983         Reviewed by Oliver Hunt and Gavin Barraclough.
2984         
2985         This improves overflow check elimination in three ways:
2986         
2987         1) It reduces the amount of time the compiler will spend doing it.
2988         
2989         2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation
2990            over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children)
2991            are int32's and then perform a possibly-overflowing operation, we must be careful not to assume
2992            that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that
2993            @b->children are int32's and that hence @b might produce a large enough result that doubles would
2994            start chopping low bits. The specific implication of this is that for a binary operation to not
2995            propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one
2996            of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such
2997            operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the
2998            latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that
2999            large won't even make it into the DFG currently.
3000         
3001         3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub
3002            are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate
3003            NodeUsedAsNumber to either @a or @b.
3004         
3005         This is neutral on V8v7 and a slight speed-up on compile time benchmarks.
3006
3007         * CMakeLists.txt:
3008         * GNUmakefile.list.am:
3009         * JavaScriptCore.xcodeproj/project.pbxproj:
3010         * Target.pri:
3011         * dfg/DFGArrayMode.cpp:
3012         (JSC::DFG::ArrayMode::refine):
3013         * dfg/DFGBackwardsPropagationPhase.cpp: Added.
3014         (DFG):
3015         (BackwardsPropagationPhase):
3016         (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase):
3017         (JSC::DFG::BackwardsPropagationPhase::run):
3018         (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
3019         (JSC::DFG::BackwardsPropagationPhase::isNotZero):
3020         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant):
3021         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive):
3022         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
3023         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
3024         (JSC::DFG::BackwardsPropagationPhase::propagate):
3025         (JSC::DFG::performBackwardsPropagation):
3026         * dfg/DFGBackwardsPropagationPhase.h: Added.
3027         (DFG):
3028         * dfg/DFGCPSRethreadingPhase.cpp:
3029         (JSC::DFG::CPSRethreadingPhase::run):
3030         (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom):
3031         (CPSRethreadingPhase):
3032         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
3033         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
3034         * dfg/DFGDriver.cpp:
3035         (JSC::DFG::compile):
3036         * dfg/DFGGraph.cpp:
3037         (JSC::DFG::Graph::dump):
3038         * dfg/DFGNodeFlags.cpp:
3039         (JSC::DFG::dumpNodeFlags):
3040         (DFG):
3041         * dfg/DFGNodeFlags.h:
3042         (DFG):
3043         * dfg/DFGPredictionPropagationPhase.cpp:
3044         (PredictionPropagationPhase):
3045         (JSC::DFG::PredictionPropagationPhase::propagate):
3046         * dfg/DFGUnificationPhase.cpp:
3047         (JSC::DFG::UnificationPhase::run):
3048         * dfg/DFGVariableAccessData.h:
3049         (JSC::DFG::VariableAccessData::VariableAccessData):
3050         (JSC::DFG::VariableAccessData::mergeIsLoadedFrom):
3051         (VariableAccessData):
3052         (JSC::DFG::VariableAccessData::setIsLoadedFrom):
3053         (JSC::DFG::VariableAccessData::isLoadedFrom):
3054
3055 2013-03-08  Roger Fong  <roger_fong@apple.com>
3056
3057         Makefile fixes.
3058
3059         * JavaScriptCore.vcxproj/JavaScriptCore.make:
3060
3061 2013-03-08  Gabor Rapcsanyi  <rgabor@webkit.org>
3062
3063         Cache flush problem on ARMv7 JSC
3064         https://bugs.webkit.org/show_bug.cgi?id=111441
3065
3066         Reviewed by Zoltan Herczeg.
3067
3068         Not proper cache flush causing random crashes on ARMv7 Linux with V8 tests.
3069         The problem is similar to https://bugs.webkit.org/show_bug.cgi?id=77712.
3070         Change the cache fulsh mechanism similar to ARM traditinal and revert the
3071         temporary fix.
3072
3073         * assembler/ARMv7Assembler.h:
3074         (JSC::ARMv7Assembler::cacheFlush):
3075
3076 2013-03-07  Geoffrey Garen  <ggaren@apple.com>
3077
3078         REGRESSION (r143759): 40% JSBench regression, 20% Octane/closure regression, 40% Octane/jquery regression, 2% Octane regression
3079         https://bugs.webkit.org/show_bug.cgi?id=111797
3080
3081         Reviewed by Oliver Hunt.
3082
3083         The bot's testing configuration stresses the cache's starting guess
3084         of 1MB.
3085
3086         This patch removes any starting guess, and just uses wall clock time
3087         to discover the initial working set size of an app, in code size.
3088
3089         * runtime/CodeCache.cpp:
3090         (JSC::CodeCacheMap::pruneSlowCase): Update our timer as we go.
3091
3092         Also fixed a bug where pruning from 0 to 0 would hang -- that case is
3093         a possibility now that we start with a capacity of 0.
3094
3095         * runtime/CodeCache.h:
3096         (CodeCacheMap):
3097         (JSC::CodeCacheMap::CodeCacheMap):
3098         (JSC::CodeCacheMap::add):
3099         (JSC::CodeCacheMap::prune): Don't prune if we're in the middle of
3100         discovering the working set size of an app, in code size.
3101
3102 2013-03-07  Michael Saboff  <msaboff@apple.com>
3103
3104         Crash when updating predictions below JSC::arrayProtoFuncForEach on tuaw.com article
3105         https://bugs.webkit.org/show_bug.cgi?id=111777
3106
3107         Reviewed by Filip Pizlo.
3108
3109         Moved register allocations to be above any generated control flow so that any
3110         resulting spill would be visible to all subsequently generated code.
3111
3112         * dfg/DFGSpeculativeJIT32_64.cpp:
3113         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3114         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3115         (JSC::DFG::SpeculativeJIT::compile):
3116         * dfg/DFGSpeculativeJIT64.cpp:
3117         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3118         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3119         (JSC::DFG::SpeculativeJIT::compile):
3120
3121 2013-03-07  Filip Pizlo  <fpizlo@apple.com>
3122
3123         DFG should not get corrupted IR in the case of code that is dead, unreachable, and contains a chain of nodes that use each other in an untyped way
3124         https://bugs.webkit.org/show_bug.cgi?id=111783
3125
3126         Reviewed by Mark Hahnenberg.
3127         
3128         Unreachable code is not touched by CFA and so thinks that even untyped uses are checked.
3129         But dead untyped uses don't need checks and hence don't need to be Phantom'd. The DCE knew
3130         this in findTypeCheckRoot() but not in eliminateIrrelevantPhantomChildren(), leading to a
3131         Phantom node that had another Phantom node as one of its kids.
3132
3133         * dfg/DFGDCEPhase.cpp:
3134         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
3135
3136 2013-03-07  Filip Pizlo  <fpizlo@apple.com>
3137
3138         The DFG fixpoint is not strictly profitable, and should be straight-lined
3139         https://bugs.webkit.org/show_bug.cgi?id=111764
3140
3141         Reviewed by Oliver Hunt and Geoffrey Garen.
3142         
3143         The DFG previously ran optimizations to fixpoint because there exists a circular dependency:
3144         
3145         CSE depends on CFG simplification: CFG simplification merges blocks, and CSE is block-local.
3146         
3147         CFG simplification depends on CFA and constant folding: constant folding reveals branches on
3148         constants.
3149         
3150         CFA depends on CSE: CSE reveals must-alias relationships by proving that two operations
3151         always produce identical values.
3152         
3153         Arguments simplification also depends on CSE, but it ought not depend on anything else.
3154         
3155         Hence we get a cycle like: CFA -> folding -> CFG -> CSE -> CFA.
3156         
3157         Note that before we had sparse conditional CFA, we also had CFA depending on CFG. This ought
3158         not be the case anymore: CFG simplification should not by itself lead to better CFA results.
3159         
3160         My guess is that the weakest link in this cycle is CFG -> CSE. CSE cuts both ways: if you
3161         CSE too much then you increase register pressure. Hence it's not clear that you always want
3162         to CSE after simplifying control flow. This leads to an order of optimization as follows:
3163         
3164         CSE -> arguments -> CFA -> folding -> CFG
3165         
3166         This is a 2.5% speed-up on SunSpider, a 4% speed-up on V8Spider, a possible 0.3% slow-down
3167         on V8v7, nothing on Kraken, and 1.2% speed-up in the JSRegress geomean. I'll take a 2.5%
3168         speed-up over a 0.3% V8v7 speed-up.
3169
3170         * dfg/DFGDriver.cpp:
3171         (JSC::DFG::compile):
3172
3173 2013-03-07  Roger Fong  <roger_fong@apple.com>
3174
3175         Build fix for AppleWin VS2010.
3176
3177         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3178         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3179
3180 2013-03-05  Mark Hahnenberg  <mhahnenberg@apple.com>
3181
3182         Objective-C API: Need a good way to reference event handlers without causing cycles
3183         https://bugs.webkit.org/show_bug.cgi?id=111088
3184
3185         Reviewed by Geoffrey Garen.
3186
3187         JSManagedValue is like a special kind of weak value. When you create a JSManagedValue, you can
3188         supply an Objective-C object as its "owner". As long as the Objective-C owner object remains
3189         alive and its wrapper remains accessible to the JSC garbage collector (e.g. by being marked by 
3190         the global object), the reference to the JavaScript value is strong. As soon as the Objective-C
3191         owner is deallocated or its wrapper becomes inaccessible to the garbage collector, the reference
3192         becomes weak.
3193
3194         If you do not supply an owner or you use the weakValueWithValue: convenience class method, the
3195         returned JSManagedValue behaves as a normal weak reference.
3196
3197         This new class allows clients to maintain references to JavaScript values in the Objective-C
3198         heap without creating reference cycles/leaking memory.
3199
3200         * API/JSAPIWrapperObject.cpp: Added.
3201         (JSC):
3202         (JSC::::createStructure):
3203         (JSC::JSAPIWrapperObject::JSAPIWrapperObject): This is a special JSObject for the Objective-C API that knows
3204         for the purposes of garbage collection/marking that it wraps an opaque Objective-C object.
3205         (JSC::JSAPIWrapperObject::visitChildren): We add the pointer to the wrapped Objective-C object to the set of
3206         opaque roots so that the weak handle owner for JSManagedValues can find it later.
3207         * API/JSAPIWrapperObject.h: Added.
3208         (JSC):
3209         (JSAPIWrapperObject):
3210         (JSC::JSAPIWrapperObject::wrappedObject):
3211         (JSC::JSAPIWrapperObject::setWrappedObject):
3212         * API/JSBase.cpp:
3213         (JSSynchronousGarbageCollect):
3214         * API/JSBasePrivate.h:
3215         * API/JSCallbackObject.cpp:
3216         (JSC):
3217         * API/JSCallbackObject.h:
3218         (JSC::JSCallbackObject::destroy): Moved this to the header so that we don't get link errors with JSAPIWrapperObject.
3219         * API/JSContext.mm:
3220         (-[JSContext initWithVirtualMachine:]): We weren't adding manually allocated/initialized JSVirtualMachine objects to 
3221         the global cache of virtual machines. The init methods handle this now rather than contextWithGlobalContextRef, since 
3222         not everyone is guaranteed to use the latter.
3223         (-[JSContext initWithGlobalContextRef:]):
3224         (+[JSContext contextWithGlobalContextRef:]):
3225         * API/JSManagedValue.h: Added.
3226         * API/JSManagedValue.mm: Added.
3227         (JSManagedValueHandleOwner):
3228         (managedValueHandleOwner):
3229         (+[JSManagedValue weakValueWithValue:]):
3230         (+[JSManagedValue managedValueWithValue:owner:]):
3231         (-[JSManagedValue init]): We explicitly call the ARC entrypoints to initialize/get the weak owner field since we don't 
3232         use ARC when building our framework.
3233         (-[JSManagedValue initWithValue:]):
3234         (-[JSManagedValue initWithValue:owner:]):
3235         (-[JSManagedValue dealloc]):
3236         (-[JSManagedValue value]):
3237         (-[JSManagedValue weakOwner]):
3238         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots): If the Objective-C owner is still alive (i.e. loading the weak field
3239         returns non-nil) and that value was added to the set of opaque roots by the wrapper for that Objective-C owner, then the the 
3240         JSObject to which the JSManagedObject refers is still alive.
3241         * API/JSObjectRef.cpp: We have to add explicit checks for the JSAPIWrapperObject, just like the other types of JSCallbackObjects.
3242         (JSObjectGetPrivate):
3243         (JSObjectSetPrivate):
3244         (JSObjectGetPrivateProperty):
3245         (JSObjectSetPrivateProperty):
3246         (JSObjectDeletePrivateProperty):
3247         * API/JSValue.mm:
3248         (objectToValueWithoutCopy):
3249         * API/JSValueRef.cpp:
3250         (JSValueIsObjectOfClass):
3251         * API/JSVirtualMachine.mm:
3252         (-[JSVirtualMachine initWithContextGroupRef:]):
3253         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
3254         * API/JSWrapperMap.mm:
3255         (wrapperFinalize):
3256         (makeWrapper): This is our own internal version of JSObjectMake which creates JSAPIWrapperObjects, the Obj-C API 
3257         version of JSCallbackObjects.
3258         (createObjectWithCustomBrand):
3259         (-[JSObjCClassInfo wrapperForObject:]):
3260         (tryUnwrapObjcObject):
3261         * API/JavaScriptCore.h:
3262         * API/tests/testapi.mm: Added new tests for the strong and weak uses of JSManagedValue in the context of an 
3263         onclick handler for an Objective-C object inserted into a JSContext.
3264         (-[TextXYZ setWeakOnclick:]):
3265         (-[TextXYZ setOnclick:]):
3266         (-[TextXYZ weakOnclick]):
3267         (-[TextXYZ onclick]):
3268         (-[TextXYZ click]):
3269         * CMakeLists.txt: Various build system additions.
3270         * GNUmakefile.list.am:
3271         * JavaScriptCore.gypi:
3272         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
3273         * JavaScriptCore.xcodeproj/project.pbxproj:
3274         * runtime/JSGlobalObject.cpp: Added the new canonical Structure for the JSAPIWrapperObject class.
3275         (JSC::JSGlobalObject::reset):
3276         (JSC):
3277         (JSC::JSGlobalObject::visitChildren):
3278         * runtime/JSGlobalObject.h:
3279         (JSGlobalObject):
3280         (JSC::JSGlobalObject::objcWrapperObjectStructure):
3281
3282 2013-03-06  Filip Pizlo  <fpizlo@apple.com>
3283
3284         ConvertThis should be turned into Identity based on predictions in Fixup, rather than based on proofs in ConstantFolding
3285         https://bugs.webkit.org/show_bug.cgi?id=111674
3286
3287         Reviewed by Oliver Hunt.
3288         
3289         This gets rid of the speculated forms of ConvertThis in the backend, and has Fixup
3290         convert them to either Identity(Object:@child) if the child is predicted object, or
3291         Phantom(Other:@child) ; WeakJSConstant(global this object) if it's predicted Other.
3292         
3293         The goal of this is to ensure that the optimization fixpoint doesn't create
3294         Identity's, since doing so requires a rerun of CSE. So far this isn't a speed-up
3295         but I'm hoping this will be a step towards reducing the need to rerun the fixpoint
3296         so as to ultimately reduce compile times.
3297
3298         * dfg/DFGAbstractState.cpp:
3299         (JSC::DFG::AbstractState::executeEffects):
3300         * dfg/DFGAssemblyHelpers.h:
3301         (AssemblyHelpers):
3302         * dfg/DFGConstantFoldingPhase.cpp:
3303         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3304         * dfg/DFGFixupPhase.cpp:
3305         (JSC::DFG::FixupPhase::fixupNode):
3306         (FixupPhase):
3307         (JSC::DFG::FixupPhase::observeUseKindOnNode):
3308         (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable):
3309         * dfg/DFGGraph.h:
3310         (JSC::DFG::Graph::globalThisObjectFor):
3311         (Graph):
3312         * dfg/DFGNode.h:
3313         (Node):
3314         (JSC::DFG::Node::convertToIdentity):
3315         (JSC::DFG::Node::convertToWeakConstant):
3316         * dfg/DFGSpeculativeJIT32_64.cpp:
3317         (JSC::DFG::SpeculativeJIT::compile):
3318         * dfg/DFGSpeculativeJIT64.cpp:
3319         (JSC::DFG::SpeculativeJIT::compile):
3320
3321 2013-03-07  Peter Gal  <galpeter@inf.u-szeged.hu>
3322
3323         Children method in LLINT AST Not class should return [@child]
3324         https://bugs.webkit.org/show_bug.cgi?id=90740
3325
3326         Reviewed by Filip Pizlo.
3327
3328         * offlineasm/ast.rb: Fixed the return value of the children method in the Not AST class.
3329
3330 2013-03-05  Oliver Hunt  <oliver@apple.com>
3331
3332         Bring back eager resolution of function scoped variables
3333         https://bugs.webkit.org/show_bug.cgi?id=111497
3334
3335         Reviewed by Geoffrey Garen.
3336
3337         This reverts the get/put_scoped_var part of the great non-local
3338         variable resolution refactoring.  This still leaves all the lazy
3339         variable resolution logic as it's necessary for global property
3340         resolution, and i don't want to make the patch bigger than it
3341         already is.
3342
3343         * bytecode/CodeBlock.cpp:
3344         (JSC::CodeBlock::dumpBytecode):
3345         (JSC::CodeBlock::CodeBlock):
3346         * bytecode/CodeBlock.h:
3347         (CodeBlock):
3348         * bytecode/Opcode.h:
3349         (JSC):
3350         (JSC::padOpcodeName):
3351         * bytecode/UnlinkedCodeBlock.cpp:
3352         (JSC::generateFunctionCodeBlock):
3353         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
3354         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3355         * bytecode/UnlinkedCodeBlock.h:
3356         (JSC):
3357         (UnlinkedFunctionExecutable):
3358         (UnlinkedCodeBlock):
3359         (JSC::UnlinkedCodeBlock::usesGlobalObject):
3360         (JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
3361         (JSC::UnlinkedCodeBlock::globalObjectRegister):
3362         * bytecompiler/BytecodeGenerator.cpp:
3363         (JSC::ResolveResult::checkValidity):
3364         (JSC::BytecodeGenerator::BytecodeGenerator):
3365         (JSC::BytecodeGenerator::emitLoadGlobalObject):
3366         (JSC):
3367         (JSC::BytecodeGenerator::resolve):
3368         (JSC::BytecodeGenerator::resolveConstDecl):
3369         (JSC::BytecodeGenerator::emitResolve):
3370         (JSC::BytecodeGenerator::emitResolveBase):
3371         (JSC::BytecodeGenerator::emitResolveBaseForPut):
3372         (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
3373         (JSC::BytecodeGenerator::emitResolveWithThis):
3374         (JSC::BytecodeGenerator::emitGetStaticVar):
3375         (JSC::BytecodeGenerator::emitPutStaticVar):
3376         * bytecompiler/BytecodeGenerator.h:
3377         (JSC::ResolveResult::lexicalResolve):
3378         (JSC::ResolveResult::isStatic):
3379         (JSC::ResolveResult::depth):
3380         (JSC::ResolveResult::index):
3381         (ResolveResult):
3382         (JSC::ResolveResult::ResolveResult):