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