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