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