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