JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
2
3         JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
4         https://bugs.webkit.org/show_bug.cgi?id=149879
5
6         Reviewed by Saam Barati.
7
8         To simplify my work to insert barriers on loads of the butterfly, I want to reduce the amount
9         of abstraction we have around code that loads the butterfly.
10
11         * jit/JIT.h:
12         * jit/JITPropertyAccess.cpp:
13         (JSC::JIT::emitLoadWithStructureCheck):
14         (JSC::JIT::emitGetVarFromPointer):
15         (JSC::JIT::emit_op_get_from_scope):
16         (JSC::JIT::emitSlow_op_get_from_scope):
17         (JSC::JIT::emitPutGlobalVariable):
18         (JSC::JIT::emit_op_put_to_scope):
19         (JSC::JIT::emitGetGlobalProperty): Deleted.
20         (JSC::JIT::emitPutGlobalProperty): Deleted.
21         * jit/JITPropertyAccess32_64.cpp:
22         (JSC::JIT::emitLoadWithStructureCheck):
23         (JSC::JIT::emitGetVarFromPointer):
24         (JSC::JIT::emit_op_get_from_scope):
25         (JSC::JIT::emitSlow_op_get_from_scope):
26         (JSC::JIT::emitPutGlobalVariable):
27         (JSC::JIT::emit_op_put_to_scope):
28         (JSC::JIT::emitGetGlobalProperty): Deleted.
29         (JSC::JIT::emitPutGlobalProperty): Deleted.
30
31 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
32
33         JIT::compileGetDirectOffset is useless
34         https://bugs.webkit.org/show_bug.cgi?id=149878
35
36         Reviewed by Mark Lam.
37
38         Two of the overloads of this method were never called. The other was called only from one
39         place, in a manner that rendered most of its code dead. This change removes the dead code and
40         folds the method into its one caller.
41
42         * jit/JIT.h:
43         * jit/JITPropertyAccess.cpp:
44         (JSC::JIT::emitSlow_op_get_by_val):
45         (JSC::JIT::emit_op_put_by_val):
46         (JSC::JIT::compilePutDirectOffset):
47         (JSC::JIT::emitVarInjectionCheck):
48         (JSC::JIT::emitGetGlobalProperty):
49         (JSC::JIT::emitGetVarFromPointer):
50         (JSC::JIT::compileGetDirectOffset): Deleted.
51         * jit/JITPropertyAccess32_64.cpp:
52         (JSC::JIT::compilePutDirectOffset):
53         (JSC::JIT::emitVarInjectionCheck):
54         (JSC::JIT::emitGetGlobalProperty):
55         (JSC::JIT::emitGetVarFromPointer):
56         (JSC::JIT::compileGetDirectOffset): Deleted.
57
58 2015-10-06  Filip Pizlo  <fpizlo@apple.com>
59
60         Inline caches should handle out-of-line offsets out-of-line
61         https://bugs.webkit.org/show_bug.cgi?id=149869
62
63         Reviewed by Saam Barati.
64
65         If we want to have a concurrent copying GC, then we need a read barrier on copied space
66         pointers. That makes the convertible load portion of the get_by_id/put_by_id inline caches
67         rather challenging. Currently we have a load instruction that we can turn into an add
68         instruction - the add case is when we have an inline offset, and the load case is when we
69         have an out-of-line offset and we need to load a copied space pointer. But if the load from
70         copied space requires a barrier, then there is no easy way to convert that back to the inline
71         case.
72
73         This patch removes the convertible load. The inline path of get_by_id/put_by_id only handles
74         the inline offsets. Out-of-line offsets are now handled using out-of-line stubs.
75
76         * bytecode/StructureStubInfo.h:
77         * ftl/FTLInlineCacheSize.cpp:
78         (JSC::FTL::sizeOfGetById):
79         (JSC::FTL::sizeOfPutById):
80         * jit/JITInlineCacheGenerator.cpp:
81         (JSC::JITByIdGenerator::finalize):
82         (JSC::JITByIdGenerator::generateFastPathChecks):
83         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
84         (JSC::JITGetByIdGenerator::generateFastPath):
85         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
86         (JSC::JITPutByIdGenerator::generateFastPath):
87         * jit/JITInlineCacheGenerator.h:
88         * jit/Repatch.cpp:
89         (JSC::repatchByIdSelfAccess):
90         (JSC::tryCacheGetByID):
91         (JSC::tryCachePutByID):
92         * runtime/JSObject.h:
93         (JSC::JSObject::butterflyTotalSize):
94         (JSC::indexRelativeToBase):
95         (JSC::offsetRelativeToBase):
96         (JSC::maxOffsetRelativeToBase):
97         (JSC::makeIdentifier):
98         (JSC::offsetRelativeToPatchedStorage): Deleted.
99         (JSC::maxOffsetRelativeToPatchedStorage): Deleted.
100
101 2015-10-07  Commit Queue  <commit-queue@webkit.org>
102
103         Unreviewed, rolling out r190664.
104         https://bugs.webkit.org/show_bug.cgi?id=149877
105
106         mac build is sometimes borken due to missing generated header
107         file (Requested by youenn on #webkit).
108
109         Reverted changeset:
110
111         "Automate WebCore JS builtins generation and build system"
112         https://bugs.webkit.org/show_bug.cgi?id=149751
113         http://trac.webkit.org/changeset/190664
114
115 2015-10-07  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
116
117         Automate WebCore JS builtins generation and build system
118         https://bugs.webkit.org/show_bug.cgi?id=149751
119
120         Reviewed by Darin Adler.
121
122         * generate-js-builtins: updating the part related to WebCore JS binding.
123
124 2015-10-06  Mark Lam  <mark.lam@apple.com>
125
126         Factoring out op_sub baseline code generation into JITSubGenerator.
127         https://bugs.webkit.org/show_bug.cgi?id=149600
128
129         Reviewed by Geoffrey Garen.
130
131         We're going to factor out baseline code generation into snippet generators so
132         that we can later use them in the DFG and FTL to emit code for to perform the
133         JS operations where the operand types are predicted to be polymorphic.
134         We are starting in this patch with the implementation of op_sub.
135
136         What was done in this patch:
137         1. Created JITSubGenerator based on the baseline implementation of op_sub as
138            expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase().
139            I did not attempt to do write a more optimal version of op_sub.  I'll
140            leave that to a later patch.
141
142         2. Convert the 32-bit op_sub baseline implementation to use the same
143            JITSubGenerator which was based on the 64-bit implementation.  The
144            pre-existing 32-bit baseline op_sub had handling for more optimization cases.
145            However, a benchmark run shows that simply going with the 64-bit version
146            (foregoing those extra optimizations) did not change the performance.
147
148            Also, previously, the 32-bit version was able to move double results directly
149            into the result location on the stack directly.  By using JITSubGenerator,
150            we now always move that result into a pair of GPRs before storing it into
151            the stack location.
152
153         3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs.
154
155         * JavaScriptCore.xcodeproj/project.pbxproj:
156         * jit/AssemblyHelpers.h:
157         (JSC::AssemblyHelpers::boxDouble):
158         (JSC::AssemblyHelpers::unboxDouble):
159         (JSC::AssemblyHelpers::boxBooleanPayload):
160         * jit/JIT.h:
161         (JSC::JIT::linkDummySlowCase):
162         * jit/JITArithmetic.cpp:
163         (JSC::JIT::compileBinaryArithOp):
164         (JSC::JIT::compileBinaryArithOpSlowCase):
165         (JSC::JIT::emitSlow_op_div):
166         (JSC::JIT::emit_op_sub):
167         (JSC::JIT::emitSlow_op_sub):
168         * jit/JITArithmetic32_64.cpp:
169         (JSC::JIT::emitBinaryDoubleOp):
170         (JSC::JIT::emit_op_sub): Deleted.
171         (JSC::JIT::emitSub32Constant): Deleted.
172         (JSC::JIT::emitSlow_op_sub): Deleted.
173         * jit/JITInlines.h:
174         (JSC::JIT::linkSlowCaseIfNotJSCell):
175         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
176         (JSC::JIT::addSlowCase):
177         (JSC::JIT::emitLoad):
178         (JSC::JIT::emitGetVirtualRegister):
179         (JSC::JIT::emitPutVirtualRegister):
180         * jit/JITSubGenerator.h: Added.
181         (JSC::JITSubGenerator::JITSubGenerator):
182         (JSC::JITSubGenerator::generateFastPath):
183         (JSC::JITSubGenerator::slowPathJumpList):
184
185 2015-10-06  Daniel Bates  <dbates@webkit.org>
186
187         Enable XSLT when building WebKit for iOS using the public iOS SDK
188         https://bugs.webkit.org/show_bug.cgi?id=149827
189
190         Reviewed by Alexey Proskuryakov.
191
192         * Configurations/FeatureDefines.xcconfig:
193
194 2015-10-05  Commit Queue  <commit-queue@webkit.org>
195
196         Unreviewed, rolling out r190599.
197         https://bugs.webkit.org/show_bug.cgi?id=149836
198
199         Made perf tests randomly crash (Requested by ap on #webkit).
200
201         Reverted changeset:
202
203         "GC shouldn't cancel every FTL compilation"
204         https://bugs.webkit.org/show_bug.cgi?id=149821
205         http://trac.webkit.org/changeset/190599
206
207 2015-10-05  Commit Queue  <commit-queue@webkit.org>
208
209         Unreviewed, rolling out r190589.
210         https://bugs.webkit.org/show_bug.cgi?id=149833
211
212         Caused lots of leaks, and possibly crashes (Requested by ap on
213         #webkit).
214
215         Reverted changeset:
216
217         "Unreviewed, rolling back in r190450"
218         https://bugs.webkit.org/show_bug.cgi?id=149727
219         http://trac.webkit.org/changeset/190589
220
221 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
222
223         Remove a few includes from JSGlobalObject.h
224         https://bugs.webkit.org/show_bug.cgi?id=148004
225
226         Reviewed by Saam Barati.
227
228         * parser/VariableEnvironment.cpp:
229         * parser/VariableEnvironment.h:
230         * runtime/JSGlobalObject.h:
231         * runtime/JSString.cpp:
232         (JSC::JSString::createStructure):
233         (JSC::JSRopeString::RopeBuilder::expand):
234         * runtime/JSString.h:
235         (JSC::JSString::canGetIndex):
236         (JSC::JSString::offsetOfLength):
237         (JSC::JSString::offsetOfFlags):
238         (JSC::JSString::createStructure): Deleted.
239         * runtime/Structure.h:
240         * runtime/StructureInlines.h:
241         * runtime/StructureRareDataInlines.h:
242
243 2015-10-05  Filip Pizlo  <fpizlo@apple.com>
244
245         GC shouldn't cancel every FTL compilation
246         https://bugs.webkit.org/show_bug.cgi?id=149821
247
248         Reviewed by Saam Barati.
249
250         During one of the CodeBlock GC refactorings, we messed up the GC's compilation cancellation
251         code. The GC should be able to cancel compilation plans if it determines that the plan will
252         be DOA. But, prior to this fix, that code was killing every FTL compilation. This happened
253         because the meaning of CodeBlock::isKnownToBeLiveDuringGC() changed.
254
255         It's funny that this didn't show up as a bigger slow-down. Basically, those benchmarks that
256         GC a lot usually don't rely on good compilation, while those benchmarks that do rely on good
257         compilation usually don't GC a lot. That's probably why this wasn't super obvious when we
258         broke it.
259
260         This change just changes the cancellation logic so that it only cancels plans if the owning
261         executable is dead. This is safe; in fact the relevant method would be correct even if it
262         always returned true. It would also be correct if it always returned false. So, compared to
263         what we had before we changed isKnownToBeLiveDuringGC(), this new code will cancel fewer
264         compilations. But, that's better than cancelling every compilation. I've filed a bug and
265         written a FIXME for investigating ways to resurrect the old behavior:
266         https://bugs.webkit.org/show_bug.cgi?id=149823
267
268         Nonetheless, this change looks like it might be a 1% speed-up on Octane. It improves earley
269         and gbemu.
270
271         * dfg/DFGPlan.cpp:
272         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
273
274 2015-10-05  Sukolsak Sakshuwong  <sukolsak@gmail.com>
275
276         [Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector<String>
277         https://bugs.webkit.org/show_bug.cgi?id=149807
278
279         Reviewed by Benjamin Poulain.
280
281         From ECMA-402, 9.2.1, the abstract operation CanonicalizeLocaleList
282         returns a List of Strings. From the spec, we never modify the result
283         from CanonicalizeLocaleList(). We never expose it to the user either.
284         This patch changes the return type of canonicalizeLocaleList() from
285         JSArray* to Vector<String>. This should ease the workload of the GC and
286         make the code a bit easier to read.
287
288         * runtime/IntlCollatorConstructor.cpp:
289         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
290         * runtime/IntlDateTimeFormatConstructor.cpp:
291         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
292         * runtime/IntlNumberFormatConstructor.cpp:
293         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
294         * runtime/IntlObject.cpp:
295         (JSC::canonicalizeLocaleList):
296         (JSC::lookupSupportedLocales):
297         (JSC::bestFitSupportedLocales):
298         (JSC::supportedLocales):
299         * runtime/IntlObject.h:
300
301 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
302
303         Unreviewed, rolling back in r190450
304         https://bugs.webkit.org/show_bug.cgi?id=149727
305
306         The cause of the leak was VM shutdown, which happens in workers.
307
308         The fix is for CodeBlockSet to participate in lastChanceToFinalize,
309         since it's responsible for running CodeBlock destructors.
310
311         I ran the leaks tests locally and did not see any CodeBlock-related leaks.
312
313         Restored changesets:
314
315         "CodeBlock should be a GC object"
316         https://bugs.webkit.org/show_bug.cgi?id=149727
317         http://trac.webkit.org/changeset/190450
318
319 2015-10-03  Filip Pizlo  <fpizlo@apple.com>
320
321         Allow an object's marking state to track The Three Colors
322         https://bugs.webkit.org/show_bug.cgi?id=149654
323
324         Reviewed by Geoffrey Garen.
325
326         I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432).
327         Concurrent GC require barriers to be executed during certain heap operations. We already have a
328         generational GC. Generational GCs also need barriers, and we already have those. The generational
329         GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a
330         collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get
331         reset. If the sticky mark bit is set in between two collections, then we know that the object is in
332         old space. This is sufficient to determine when to put things into remembered sets. Additionally,
333         the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on
334         a remembered set.
335
336         This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes
337         to the heap that change the object graph to do different things depending on an object's marking
338         state, which is usually referred to as its color. White means that the object has never been seen
339         by the collector. All white objects are presumed dead at the flip. Grey objects are those that are
340         known to the collector but have not been scanned. Black objects are those that have been scanned,
341         and will not be scanned again. White is exactly just "not being marked", and both grey and black
342         mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the
343         current "Marked" and "MarkedAndRemembered" states that we have for generational GC.
344         "MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black".
345
346         I want to make a concurrent GC that unifies the generational and concurrent barriers into a single
347         fast path check. Even better if the two barriers are entirely identical. You can do this using
348         Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and
349         v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC
350         "rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack,
351         setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit.
352
353         This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and
354         generational, and we want to basically keep our current barriers unchanged. The only things missing
355         are just some small changes to allow the concurrent GC to know precisely when an object is black,
356         and to know during object visiting if we are visiting the object for the first time during a
357         collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering
358         (generational GC). So, this patch does the following:
359
360         - Changes the terminology used for the gcData header byte in JSCell. This changes the name of this
361           to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a
362           lot like the old GCData did. It has the following members, with the following correspondence to
363           the old GCData:
364
365           OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack
366               as soon as the object starts to be scanned. Previously, an object might be
367               MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked
368               objects during a post-processing step at the end of GC. This patch gets rid of that
369               post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that
370               our definition of "black" is not that the object is done being scanned, but that it is either
371               being scanned right now or it has already been scanned. This is like a combination of
372               Siebert's anthracite and black states [3].
373
374           NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated.
375               It's impossible for an object to return to this state.
376
377           OldGrey: the object is on the mark stack and will be scanned at some point in the future. This
378               also means that this isn't the first time in this cycle that the object has been grey. In an
379               eden collection, an old object that has been remembered is thought of as being OldGrey, even
380               if this is the first time during this eden collection that it is grey. That's because an eden
381               collection must behave "as if" the grey->black transition for old objects magically happened
382               at the start of GC. Remembered objects are like old objects that underwent a concurrent
383               barrier re-greying just after the magical old object grey->black transition at the start of
384               GC. This state is almost exactly like MarkedAndRemembered, except that an object now
385               transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously
386               we transitioned from MarkedAndRemembered to Marked at the bitter end of GC.
387
388           NewGray: the object is on the mark stack and will be scanned at some point in the future. This
389               state has no clear relative in the old state system. It means that the object became grey due
390               to ordinary marking. Previously, ordinary marking would make the object Marked.
391
392         - Removal of the post-processing phase that "clears" the remembered set by moving all remembered
393           objects to the Marked state. This now happens magically during visiting, as described above.
394
395         - SlotVisitor now remembers the state that the object did have just before visiting. While visiting
396           that object, it's possible to query what the state was. This is used for copy space decisions and
397           for extra memory usage accounting. We don't want to put the backing store on the copy worklist,
398           and we don't want to count extra memory usage, if the object was OldGrey at the start of
399           visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since
400           that state wouldn't get cleared until after all marking finished. This change also simplifies
401           some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods
402           no longer ask the cell for its state - instead they use the saved pre-visiting state.
403
404         - Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if
405           an object was "marked" and if an object was "remembered". We had helpers for adjusting these
406           states, and those helpers would assert that they were being used the right way. This is not very
407           useful for concurrent GC, since now the set of possible state transitions is much larger. Also,
408           the previous use of the word "marked" was pretty bad - for example in Heap, "marked" refers to
409           the primary mark bit (that gets cleared at the flip), while in JSCell, "marked" refers to the
410           sticky mark bit (that does not get cleared, ever). This change gets rid of a lot of those helpers
411           and inlines their logic. This actually makes the code easier and more fun to read, since you can
412           now look at the marking and barrier code and see how that code uses the four CellStates. For
413           example, it's fun to see that the barrier gets fired for o.f=v exactly when o is OldBlack and v
414           is NewWhite.
415
416         This change shouldn't have any effect on performance or GC behavior. It does put our code in a
417         weird state where we now have states and comments referencing a concurrent GC that doesn't exist
418         yet.
419
420         Finally, some thoughts about the concurrent GC barrier and its implications for performance. This
421         barrier exhibits very poor guarantees about collector progress, but maximizes throughput by just
422         reusing the existing barrier code we already emit and optimize. I believe that even our epoch-based
423         barrier insertion DFG phase is correct for the concurrent interpretation of our existing barrier.
424         But, the barrier can regress the progress that the collector has made for two reasons:
425
426         Incremental update: you don't want to use this barrier with a black stack, since that would mean
427         that heap loads of white objects will have to explicitly re-grey the stack. The way you implement
428         this kind of collector is that collector termination will rescan the stack. Termination is reached
429         only if the at-termination re-scan greys no objects. This means that the collector is a fixpoint.
430         Luckily, our collector is already a fixpoint because of opaque roots and structure transitions.
431
432         Marking ain't monotonic: normally, once an object is black, it stays that way. In this collector,
433         black objects may become grey again. I don't have personal experience with such concurrent GCs, but
434         I suspect that this will basically be fine. Concurrent collections finish pretty quickly, and the
435         mutator usually touches only a subset of the heap. Only that subset of the heap that the mutator is
436         touching could be re-greyed. Probably, the GC will have to be hybrid incremental and concurrent,
437         and towards the end of GC when we do the termination stack re-scan, we can ensure that the
438         collector does some minimal amount of marking. If the minimal amount of marking done by the
439         collector is large enough, we can ensure that we reach termination before the mutator can regress
440         progress. The barrier cannot un-terminate the collector; if the collector reaches termination and
441         the barrier re-greys an object then it's actually doing a generational remembering rather than a
442         concurrent re-greying.
443
444         That's sort of the cute thing about the barrier - it is exactly a re-greying barrier during GC and
445         it is exactly a remembering barrier in between GCs.
446
447         [1] http://www.cs.utexas.edu/ftp/garbage/submit/readable/ppirinen11.ps
448         [2] http://dl.acm.org/citation.cfm?id=361005
449         [3] http://www.aicas.com/papers/ISMM132-siebert.pdf
450
451         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
452         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
453         * JavaScriptCore.xcodeproj/project.pbxproj:
454         * bytecode/CodeBlock.cpp:
455         (JSC::CodeBlock::visitChildren):
456         * ftl/FTLAbstractHeapRepository.cpp:
457         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
458         * ftl/FTLAbstractHeapRepository.h:
459         * ftl/FTLLowerDFGToLLVM.cpp:
460         (JSC::FTL::DFG::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
461         (JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
462         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
463         (JSC::FTL::DFG::LowerDFGToLLVM::loadMarkByte): Deleted.
464         * heap/CellState.h: Added.
465         * heap/CodeBlockSet.cpp:
466         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
467         * heap/CopiedBlock.h:
468         * heap/CopiedBlockInlines.h:
469         (JSC::CopiedBlock::reportLiveBytes):
470         (JSC::CopiedBlock::shouldReportLiveBytes): Deleted.
471         * heap/GCLogging.cpp:
472         (JSC::LoggingFunctor::reviveCells):
473         * heap/Heap.cpp:
474         (JSC::Heap::markRoots):
475         (JSC::Heap::visitWeakHandles):
476         (JSC::Heap::updateObjectCounts):
477         (JSC::Heap::addToRememberedSet):
478         (JSC::Heap::clearRememberedSet): Deleted.
479         * heap/Heap.h:
480         * heap/HeapInlines.h:
481         (JSC::Heap::isLive):
482         (JSC::Heap::isMarked):
483         (JSC::Heap::writeBarrier):
484         (JSC::Heap::reportExtraMemoryAllocated):
485         (JSC::Heap::reportExtraMemoryVisited):
486         (JSC::Heap::isRemembered): Deleted.
487         * heap/SlotVisitor.cpp:
488         (JSC::SlotVisitor::append):
489         (JSC::SlotVisitor::visitChildren):
490         (JSC::SlotVisitor::donateKnownParallel):
491         (JSC::SlotVisitor::drain):
492         (JSC::visitChildren): Deleted.
493         * heap/SlotVisitor.h:
494         (JSC::SlotVisitor::childCount):
495         (JSC::SlotVisitor::incrementChildCount):
496         (JSC::SlotVisitor::dataBeforeVisitingCurrentObject):
497         * heap/SlotVisitorInlines.h:
498         (JSC::SlotVisitor::internalAppend):
499         (JSC::SlotVisitor::copyLater):
500         (JSC::SlotVisitor::reportExtraMemoryVisited):
501         (JSC::SlotVisitor::heap):
502         * jit/AssemblyHelpers.h:
503         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
504         * llint/LowLevelInterpreter.asm:
505         * llint/LowLevelInterpreter32_64.asm:
506         * llint/LowLevelInterpreter64.asm:
507         * runtime/JSCell.h:
508         (JSC::JSCell::cellState):
509         (JSC::JSCell::setCellState):
510         (JSC::JSCell::structureIDOffset):
511         (JSC::JSCell::indexingTypeOffset):
512         (JSC::JSCell::cellStateOffset):
513         (JSC::JSCell::setMarked): Deleted.
514         (JSC::JSCell::setRemembered): Deleted.
515         (JSC::JSCell::isMarked): Deleted.
516         (JSC::JSCell::isRemembered): Deleted.
517         (JSC::JSCell::gcDataOffset): Deleted.
518         * runtime/JSCellInlines.h:
519         (JSC::JSCell::JSCell):
520         * runtime/JSGenericTypedArrayViewInlines.h:
521         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
522         * runtime/JSObject.cpp:
523         (JSC::JSObject::copyBackingStore):
524         * runtime/JSString.cpp:
525         (JSC::JSString::visitChildren):
526         * runtime/StructureIDBlob.h:
527         (JSC::StructureIDBlob::StructureIDBlob):
528         (JSC::StructureIDBlob::operator=):
529         * runtime/WeakMapData.cpp:
530         (JSC::WeakMapData::visitChildren):
531         (JSC::WeakMapData::set):
532         * tests/stress/basic-eden-gc-test.js: Added.
533             Hilariously, an earlier version of this patch that didn't have the NewGrey/OldGrey distinction
534             would only crash super-big tests that GCd twice but it didn't crash any small focused test. All
535             it took to show the need for the NewGrey/OldGrey distinction was this super simple test.
536
537 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
538
539         JSC::SlotVisitor should not be a hot mess
540         https://bugs.webkit.org/show_bug.cgi?id=149798
541
542         Reviewed by Andreas Kling.
543
544         I had to debug JSC::SlotVisitor the other day. It was hard to follow.
545         Let's make it easy to follow.
546
547         * heap/Heap.cpp:
548         (JSC::Heap::markRoots):
549         (JSC::Heap::resetVisitors):
550         (JSC::Heap::objectCount):
551         (JSC::Heap::addToRememberedSet):
552         (JSC::Heap::collectAndSweep):
553         * heap/Heap.h: Deleted the string hash-consing code. It
554         was dead code.
555
556         Since no benchmark noticed the commit that broke this feature, perhaps
557         it's not worth having.
558
559         Either way, the best thing to do with dead code is to delete it.
560         It's still there in svn if we ever want to pick it up again.
561
562         * heap/HeapRootVisitor.h:
563         (JSC::HeapRootVisitor::visit):
564         (JSC::HeapRootVisitor::visitor): Removed the private append functions
565         for unsafe pointers and switched HeapRootVisitor over to the public
566         specially named functions for unsafe pointers.
567
568         In future, we should either remove the public specially named functions
569         or remove HeapRootVisitor, since they serve the same purpose. At least
570         for now we don't have pairs of functions on SlotVisitor that do the
571         exact same thing.
572
573         * heap/SlotVisitor.cpp:
574         (JSC::validate): Moved this static function to the top of the file.
575
576         (JSC::SlotVisitor::SlotVisitor):
577         (JSC::SlotVisitor::didStartMarking):
578         (JSC::SlotVisitor::reset): More hash cons removal.
579
580         (JSC::SlotVisitor::append):
581
582         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
583         (JSC::SlotVisitor::appendToMarkStack): Renamed these functions to 
584         distinguish them from the up-front helper functions that just do type
585         conversions. These are the functions that actually do stuff.
586
587         Moved these functions out of line to make it easier to set breakpoints,
588         and to enable code changes for debugging, like printf and synchronous
589         marking, without recompiling the world.
590
591         setMarkedAndAppendToMarkStack is roughly 258 bytes long (not including
592         function prologue and epilogue), so inlining it was probably not a
593         great idea in the first place.
594
595         (JSC::SlotVisitor::donateKnownParallel):
596         (JSC::SlotVisitor::drain):
597         (JSC::SlotVisitor::drainFromShared): Removed some stack probing code.
598         It was also dead.
599
600         (JSC::SlotVisitor::addOpaqueRoot):
601         (JSC::SlotVisitor::containsOpaqueRoot):
602         (JSC::SlotVisitor::containsOpaqueRootTriState):
603         (JSC::SlotVisitor::opaqueRootCount):
604         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
605         (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable):
606         (JSC::SlotVisitor::donate):
607         (JSC::SlotVisitor::donateAndDrain):
608         (JSC::SlotVisitor::copyLater):
609         (JSC::SlotVisitor::mergeOpaqueRoots):
610         (JSC::SlotVisitor::harvestWeakReferences):
611         (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
612         (JSC::SlotVisitor::dump): Moved more code out-of-line. These code paths
613         are not hot and/or not small, so we need more evidence before we inline
614         them. The SlotVisitor headers are included everywhere, so we should
615         make them include less.
616
617         Removed "internal" from all function names because it wasn't applied in
618         any consistent way that would mean anything.
619
620         (JSC::JSString::tryHashConsLock): Deleted.
621         (JSC::JSString::releaseHashConsLock): Deleted.
622         (JSC::JSString::shouldTryHashCons): Deleted.
623         (JSC::SlotVisitor::internalAppend): Deleted.
624         (JSC::SlotVisitor::validate): Deleted.
625
626         * heap/SlotVisitor.h:
627         (JSC::SlotVisitor::resetChildCount): Deleted.
628         (JSC::SlotVisitor::childCount): Deleted.
629         (JSC::SlotVisitor::incrementChildCount): Deleted. Removed this child
630         count thing. It was dead code.
631
632         * heap/SlotVisitorInlines.h:
633         (JSC::SlotVisitor::appendUnbarrieredPointer):
634         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer):
635         (JSC::SlotVisitor::appendUnbarrieredValue):
636         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Some renaming and un-inlining.
637
638         (JSC::SlotVisitor::appendUnbarrieredWeak): Don't null check our input.
639         The one true place where null checking happens is our out-of-line
640         code. All inline functions do only type conversions.
641
642         (JSC::SlotVisitor::append):
643         (JSC::SlotVisitor::appendValues):
644         (JSC::SlotVisitor::addWeakReferenceHarvester):
645         (JSC::SlotVisitor::addUnconditionalFinalizer):
646         (JSC::SlotVisitor::reportExtraMemoryVisited): Some renaming and un-inlining.
647
648         (JSC::SlotVisitor::internalAppend): Deleted.
649         (JSC::SlotVisitor::unconditionallyAppend): Deleted.
650         (JSC::SlotVisitor::addOpaqueRoot): Deleted.
651         (JSC::SlotVisitor::containsOpaqueRoot): Deleted.
652         (JSC::SlotVisitor::containsOpaqueRootTriState): Deleted.
653         (JSC::SlotVisitor::opaqueRootCount): Deleted.
654         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
655         (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted.
656         (JSC::SlotVisitor::donate): Deleted.
657         (JSC::SlotVisitor::donateAndDrain): Deleted.
658         (JSC::SlotVisitor::copyLater): Deleted.
659
660         * runtime/JSString.h:
661         (JSC::JSString::finishCreation):
662         (JSC::JSString::setIs8Bit):
663         (JSC::JSString::isHashConsSingleton): Deleted.
664         (JSC::JSString::clearHashConsSingleton): Deleted.
665         (JSC::JSString::setHashConsSingleton): Deleted. More hash cons removal.
666
667         * runtime/VM.cpp:
668         (JSC::VM::VM):
669         * runtime/VM.h:
670         (JSC::VM::currentThreadIsHoldingAPILock):
671         (JSC::VM::apiLock):
672         (JSC::VM::haveEnoughNewStringsToHashCons): Deleted.
673         (JSC::VM::resetNewStringsSinceLastHashCons): Deleted. More hash cons removal.
674
675 2015-10-04  Filip Pizlo  <fpizlo@apple.com>
676
677         Inline cache repatching should be throttled if it happens a lot
678         https://bugs.webkit.org/show_bug.cgi?id=149796
679         rdar://problem/22674436
680
681         Reviewed by Saam Barati.
682
683         We noticed a slight PLT regression from http://trac.webkit.org/changeset/189586. It's because
684         some pages do things that our inline caches mishandle, in the sense that some ICs end up
685         repatching themselves very frequently. The cost of repatching outweighs the speed-up on those
686         pages. There are probably super smart things we could do to tune the IC heuristics to make the
687         ICs do the right thing on those pages. But more fundamentally, we should ensure that our ICs
688         back off from continuous repatching if they repatch a lot. That's what this change does.
689
690         With this change, StructureStubInfo counts the number of repatchings. If that exceeds a
691         threshold, we put the IC into a cool-down mode, where some number of future repatch events do
692         nothing but decrement the cool-down counter. The duration of cool-down increases exponentially
693         every time we have to do it.
694
695         This change also outlines a lot of code. The fact that StructureStubInfo had a lot of inline
696         methods was starting to get on my nerves. Now it only has inline methods for things that need
697         to be inlined. Also, I changed StructureStubInfo to be a class rather than a struct. Maybe
698         with enough such incremental changes, eventually StructureStubInfo will actually behave like a
699         proper class.
700
701         This has no effect on JSC benchmarks. It progresses one of the pages that was hit by the
702         regression by 15%. It's hard to see if this totally fixes the entire PLT regression since the
703         geomean regression was very close to noise.
704
705         * bytecode/CodeBlock.cpp:
706         (JSC::CodeBlock::printGetByIdCacheStatus):
707         (JSC::CodeBlock::printPutByIdCacheStatus):
708         (JSC::CodeBlock::CodeBlock):
709         (JSC::CodeBlock::checkIfOptimizationThresholdReached):
710         * bytecode/CodeBlock.h:
711         * bytecode/GetByIdStatus.cpp:
712         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
713         (JSC::GetByIdStatus::computeFor):
714         * bytecode/PolymorphicAccess.cpp:
715         (JSC::PolymorphicAccess::regenerate):
716         * bytecode/PolymorphicAccess.h:
717         * bytecode/PutByIdStatus.cpp:
718         (JSC::PutByIdStatus::computeForStubInfo):
719         * bytecode/StructureStubClearingWatchpoint.h:
720         * bytecode/StructureStubInfo.cpp:
721         (JSC::StructureStubInfo::StructureStubInfo):
722         (JSC::StructureStubInfo::~StructureStubInfo):
723         (JSC::StructureStubInfo::initGetByIdSelf):
724         (JSC::StructureStubInfo::initPutByIdReplace):
725         (JSC::StructureStubInfo::initStub):
726         (JSC::StructureStubInfo::deref):
727         (JSC::StructureStubInfo::addAccessCase):
728         * bytecode/StructureStubInfo.h:
729         (JSC::StructureStubInfo::considerCaching):
730         (JSC::StructureStubInfo::willRepatch):
731         (JSC::StructureStubInfo::willCoolDown):
732         (JSC::getStructureStubInfoCodeOrigin):
733         (JSC::StructureStubInfo::StructureStubInfo): Deleted.
734         (JSC::StructureStubInfo::initGetByIdSelf): Deleted.
735         (JSC::StructureStubInfo::initPutByIdReplace): Deleted.
736         (JSC::StructureStubInfo::initStub): Deleted.
737         (JSC::StructureStubInfo::seenOnce): Deleted.
738         (JSC::StructureStubInfo::setSeen): Deleted.
739         * jit/JIT.h:
740         * jit/JITOperations.cpp:
741         * jit/Repatch.cpp:
742         (JSC::tryCacheGetByID):
743         (JSC::tryCachePutByID):
744         (JSC::tryRepatchIn):
745         * runtime/Options.h:
746
747 2015-10-04  Filip Pizlo  <fpizlo@apple.com>
748
749         CodeBlock.h shouldn't be included from everywhere
750         https://bugs.webkit.org/show_bug.cgi?id=149785
751
752         Reviewed by Andreas Kling.
753
754         * JavaScriptCore.xcodeproj/project.pbxproj:
755         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
756         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
757         * interpreter/CallFrame.cpp:
758         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
759         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
760         (JSC::CallFrame::callSiteAsRawBits):
761         (JSC::CallFrame::callSiteIndex):
762         (JSC::CallFrame::hasActivation):
763         (JSC::CallFrame::uncheckedActivation):
764         (JSC::CallFrame::stack):
765         * interpreter/CallFrameInlines.h: Removed.
766         * interpreter/Interpreter.cpp:
767         * interpreter/StackVisitor.cpp:
768         * runtime/DirectArguments.cpp:
769         * runtime/ErrorInstance.cpp:
770         * runtime/JSArray.cpp:
771         * runtime/JSCInlines.h:
772         * runtime/LiteralParser.cpp:
773         * runtime/NullSetterFunction.cpp:
774         * tools/JSDollarVMPrototype.cpp:
775
776 2015-10-03  Commit Queue  <commit-queue@webkit.org>
777
778         Unreviewed, rolling out r190522.
779         https://bugs.webkit.org/show_bug.cgi?id=149787
780
781         Caused a lot of leaks (Requested by ap on #webkit).
782
783         Reverted changeset:
784
785         "Unreviewed, rolling back in r190450"
786         https://bugs.webkit.org/show_bug.cgi?id=149727
787         http://trac.webkit.org/changeset/190522
788
789 2015-10-02  Matt Baker  <mattbaker@apple.com>
790
791         Web Inspector: Add breakpoint option to ignore n times before stopping
792         https://bugs.webkit.org/show_bug.cgi?id=147664
793
794         Reviewed by Timothy Hatcher.
795
796         * debugger/Breakpoint.h:
797         (JSC::Breakpoint::Breakpoint):
798         Added ignoreCount and hitCount fields. Cleaned up initializers.
799
800         * debugger/Debugger.cpp:
801         (JSC::Debugger::hasBreakpoint):
802         If a breakpoint matches the current text position, increment breakpoint hit count and
803         compare with ignore count before testing the breakpoint condition.
804
805         * inspector/ScriptBreakpoint.h:
806         (Inspector::ScriptBreakpoint::ScriptBreakpoint):
807         Added ignoreCount field. Cleaned up initializers.
808
809         * inspector/ScriptDebugServer.cpp:
810         (Inspector::ScriptDebugServer::setBreakpoint):
811         Added ignoreCount field.
812
813         * inspector/agents/InspectorDebuggerAgent.cpp:
814         (Inspector::buildObjectForBreakpointCookie):
815         (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
816         (Inspector::InspectorDebuggerAgent::setBreakpoint):
817         (Inspector::InspectorDebuggerAgent::continueToLocation):
818         (Inspector::InspectorDebuggerAgent::didParseSource):
819         Plumbing for ignoreCount property.
820
821         * inspector/protocol/Debugger.json:
822         Added optional ignoreCount property to BreakpointOptions object.
823
824 2015-10-02  Filip Pizlo <fpizlo@apple.com> and Mark Lam <mark.lam@apple.com>
825
826         We should not add InferredTypeTables to old Structures
827         https://bugs.webkit.org/show_bug.cgi?id=149767
828         rdar://problem/22825526
829
830         Reviewed by Saam Barati.
831
832         Our property type inference has an optimization where the absence of an InferredTypeTable is
833         taken to mean that all properties are TOP. This is great because most Structures come into
834         existence through reflective stores, and we don't want to waste time inferring types for
835         those.
836
837         But our code was not obeying this rule properly. If we were doing a transition, we would
838         assume that this meant that we were creating a new structure, and so we would give it an
839         InferredTypeTable if we were doing a non-reflective store (i.e. context = PutById). But that
840         same structure could already have been in use prior to us giving it an InferredTypeTable. At
841         that point bad things will start to happen because the objects created before we created the
842         table, and the inline caches compiled before then, will have types that disagree with the new
843         objects and inline caches despite them sharing the same structure and property names.
844
845         * runtime/JSObject.h:
846         (JSC::JSObject::putDirectInternal):
847         (JSC::JSObject::putDirectWithoutTransition):
848         * runtime/Structure.h:
849         * tests/stress/add-inferred-type-table-to-existing-structure.js: Added.
850         (foo):
851         (bar):
852         (baz):
853
854 2015-10-02  Joseph Pecoraro  <pecoraro@apple.com>
855
856         Unreviewed, rolling out r190520, some tests assert / crash.
857
858         * CMakeLists.txt:
859         * DerivedSources.make:
860         * JavaScriptCore.xcodeproj/project.pbxproj:
861         * heap/Heap.cpp:
862         (JSC::Heap::willStartCollection): Deleted.
863         (JSC::Heap::didFinishCollection): Deleted.
864         * heap/Heap.h:
865         (JSC::Heap::addObserver): Deleted.
866         (JSC::Heap::removeObserver): Deleted.
867         * heap/HeapObserver.h: Removed.
868         * heap/MarkedSpace.h:
869         * inspector/InspectorEnvironment.h:
870         * inspector/JSGlobalObjectInspectorController.cpp:
871         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
872         (Inspector::JSGlobalObjectInspectorController::vm): Deleted.
873         * inspector/JSGlobalObjectInspectorController.h:
874         * inspector/agents/InspectorHeapAgent.cpp: Removed.
875         * inspector/agents/InspectorHeapAgent.h: Removed.
876         * inspector/protocol/Heap.json: Removed.
877
878 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
879
880         Unreviewed, rolling back in r190450
881         https://bugs.webkit.org/show_bug.cgi?id=149727
882
883         The cause of the crash was a CodeBlock, after surviving a call to
884         deleteAllCode by virtue of being in the remembered set, trying to mark
885         its inlined CodeBlocks via pointers from its inlined executables.
886         Since deleteAllCode clears those pointers, the CodeBlock would ASSERT.
887         (Any other choice to retain a CodeBlock after deleteAllCode -- for
888         example, conservative marking -- could trigger the same bug.)
889
890         The fix is for InlineCallFrame to point directly to its inlined CodeBlock
891         instead of pointing indirectly via an executable. This guarantees that
892         CodeBlocks are GC safe regardless of whether we've called deleteAllCode.
893
894         Restored changesets:
895
896         "CodeBlock should be a GC object"
897         https://bugs.webkit.org/show_bug.cgi?id=149727
898         http://trac.webkit.org/changeset/190450
899
900 2015-10-02  Joseph Pecoraro  <pecoraro@apple.com>
901
902         Web Inspector: Include Garbage Collection Event in Timeline
903         https://bugs.webkit.org/show_bug.cgi?id=142510
904
905         Reviewed by Geoffrey Garen.
906
907         * CMakeLists.txt:
908         * DerivedSources.make:
909         * JavaScriptCore.xcodeproj/project.pbxproj:
910
911         * heap/HeapObserver.h:        
912         * heap/Heap.cpp:
913         (JSC::Heap::willStartCollection):
914         (JSC::Heap::didFinishCollection):
915         * heap/Heap.h:
916         (JSC::Heap::addObserver):
917         (JSC::Heap::removeObserver):
918         Allow observers on heap to add hooks for starting / ending garbage collection.
919
920         * inspector/InspectorEnvironment.h:
921         * inspector/JSGlobalObjectInspectorController.cpp:
922         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
923         (Inspector::JSGlobalObjectInspectorController::vm):
924         * inspector/JSGlobalObjectInspectorController.h:
925         Access the VM through the InspectorEnvironment as it won't change.
926
927         * inspector/agents/InspectorHeapAgent.cpp: Added.
928         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
929         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
930         (Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
931         (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
932         (Inspector::InspectorHeapAgent::enable):
933         (Inspector::InspectorHeapAgent::disable):
934         (Inspector::InspectorHeapAgent::gc):
935         (Inspector::protocolTypeForHeapOperation):
936         (Inspector::InspectorHeapAgent::willGarbageCollect):
937         (Inspector::InspectorHeapAgent::didGarbageCollect):
938         * inspector/agents/InspectorHeapAgent.h: Added.
939         * inspector/protocol/Heap.json: Added.
940         New domain and agent to handle tasks related to the JavaScriptCore heap.
941
942 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
943
944         Unreviewed, rolling out r190450
945         https://bugs.webkit.org/show_bug.cgi?id=148560
946
947         Crashes seen on el cap wk1 bots.
948
949         Reverted changesets:
950
951         "CodeBlock should be a GC object"
952         https://bugs.webkit.org/show_bug.cgi?id=149727
953         http://trac.webkit.org/changeset/190450
954
955         * bytecode/CodeBlock.cpp:
956         (JSC::CodeBlock::inferredName):
957         (JSC::CodeBlock::dumpAssumingJITType):
958         (JSC::CodeBlock::CodeBlock):
959         (JSC::CodeBlock::~CodeBlock):
960         (JSC::CodeBlock::setNumParameters):
961         (JSC::CodeBlock::specialOSREntryBlockOrNull):
962         (JSC::CodeBlock::visitStrongly):
963         (JSC::CodeBlock::visitAggregate):
964         (JSC::CodeBlock::shouldVisitStrongly):
965         (JSC::CodeBlock::isKnownToBeLiveDuringGC):
966         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
967         (JSC::CodeBlock::shouldJettisonDueToOldAge):
968         (JSC::CodeBlock::determineLiveness):
969         (JSC::CodeBlock::visitWeakReferences):
970         (JSC::CodeBlock::finalizeLLIntInlineCaches):
971         (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
972         (JSC::CodeBlock::finalizeUnconditionally):
973         (JSC::CodeBlock::visitOSRExitTargets):
974         (JSC::CodeBlock::unlinkIncomingCalls):
975         (JSC::CodeBlock::linkIncomingCall):
976         (JSC::CodeBlock::newReplacement):
977         (JSC::ProgramCodeBlock::replacement):
978         (JSC::ModuleProgramCodeBlock::replacement):
979         (JSC::EvalCodeBlock::replacement):
980         (JSC::FunctionCodeBlock::replacement):
981         (JSC::ProgramCodeBlock::capabilityLevelInternal):
982         (JSC::ModuleProgramCodeBlock::capabilityLevelInternal):
983         (JSC::EvalCodeBlock::capabilityLevelInternal):
984         (JSC::FunctionCodeBlock::capabilityLevelInternal):
985         (JSC::WebAssemblyCodeBlock::replacement):
986         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
987         (JSC::CodeBlock::jettison):
988         (JSC::CodeBlock::capabilityLevel):
989         (JSC::FunctionCodeBlock::destroy): Deleted.
990         (JSC::WebAssemblyCodeBlock::destroy): Deleted.
991         (JSC::ProgramCodeBlock::destroy): Deleted.
992         (JSC::ModuleProgramCodeBlock::destroy): Deleted.
993         (JSC::EvalCodeBlock::destroy): Deleted.
994         (JSC::CodeBlock::finishCreation): Deleted.
995         (JSC::CodeBlock::setAlternative): Deleted.
996         (JSC::CodeBlock::visitWeakly): Deleted.
997         (JSC::CodeBlock::visitChildren): Deleted.
998         (JSC::timeToLive): Deleted.
999         (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
1000         (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
1001         (JSC::CodeBlock::replacement): Deleted.
1002         (JSC::CodeBlock::computeCapabilityLevel): Deleted.
1003         * bytecode/CodeBlock.h:
1004         (JSC::CodeBlock::unlinkedCodeBlock):
1005         (JSC::CodeBlock::addressOfNumParameters):
1006         (JSC::CodeBlock::offsetOfNumParameters):
1007         (JSC::CodeBlock::alternative):
1008         (JSC::CodeBlock::setAlternative):
1009         (JSC::CodeBlock::forEachRelatedCodeBlock):
1010         (JSC::CodeBlock::specializationKind):
1011         (JSC::CodeBlock::instructionCount):
1012         (JSC::CodeBlock::setJITCode):
1013         (JSC::CodeBlock::hasBaselineJITProfiling):
1014         (JSC::CodeBlock::capabilityLevelState):
1015         (JSC::CodeBlock::addConstant):
1016         (JSC::CodeBlock::appendExceptionHandler):
1017         (JSC::CodeBlock::setConstantRegisters):
1018         (JSC::CodeBlock::replaceConstant):
1019         (JSC::GlobalCodeBlock::GlobalCodeBlock):
1020         (JSC::ProgramCodeBlock::ProgramCodeBlock):
1021         (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
1022         (JSC::EvalCodeBlock::EvalCodeBlock):
1023         (JSC::EvalCodeBlock::variable):
1024         (JSC::EvalCodeBlock::numVariables):
1025         (JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
1026         (JSC::FunctionCodeBlock::FunctionCodeBlock):
1027         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
1028         (JSC::ExecState::uncheckedR):
1029         (JSC::CodeBlock::clearMarks):
1030         (JSC::CodeBlockSet::mark):
1031         (JSC::ScriptExecutable::forEachCodeBlock):
1032         (JSC::ProgramCodeBlock::create): Deleted.
1033         (JSC::ProgramCodeBlock::createStructure): Deleted.
1034         (JSC::ModuleProgramCodeBlock::create): Deleted.
1035         (JSC::ModuleProgramCodeBlock::createStructure): Deleted.
1036         (JSC::EvalCodeBlock::create): Deleted.
1037         (JSC::EvalCodeBlock::createStructure): Deleted.
1038         (JSC::FunctionCodeBlock::create): Deleted.
1039         (JSC::FunctionCodeBlock::createStructure): Deleted.
1040         (JSC::WebAssemblyCodeBlock::create): Deleted.
1041         (JSC::WebAssemblyCodeBlock::createStructure): Deleted.
1042         (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
1043         * bytecode/DeferredCompilationCallback.cpp:
1044         (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
1045         (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
1046         (JSC::DeferredCompilationCallback::compilationDidComplete):
1047         * bytecode/DeferredCompilationCallback.h:
1048         * bytecode/EvalCodeCache.h:
1049         (JSC::EvalCodeCache::tryGet):
1050         (JSC::EvalCodeCache::getSlow):
1051         * bytecode/PolymorphicAccess.cpp:
1052         (JSC::AccessCase::generate):
1053         (JSC::PolymorphicAccess::regenerate):
1054         * bytecode/StructureStubInfo.cpp:
1055         (JSC::StructureStubInfo::addAccessCase):
1056         * dfg/DFGByteCodeParser.cpp:
1057         (JSC::DFG::ByteCodeParser::parse):
1058         * dfg/DFGDesiredTransitions.cpp:
1059         (JSC::DFG::DesiredTransition::reallyAdd):
1060         * dfg/DFGDesiredWeakReferences.cpp:
1061         (JSC::DFG::DesiredWeakReferences::reallyAdd):
1062         * dfg/DFGDriver.cpp:
1063         (JSC::DFG::compile):
1064         * dfg/DFGGraph.cpp:
1065         (JSC::DFG::Graph::Graph):
1066         * dfg/DFGJITCode.h:
1067         (JSC::DFG::JITCode::osrEntryBlock): Deleted.
1068         (JSC::DFG::JITCode::setOSREntryBlock): Deleted.
1069         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
1070         * dfg/DFGJITFinalizer.cpp:
1071         (JSC::DFG::JITFinalizer::finalize):
1072         (JSC::DFG::JITFinalizer::finalizeFunction):
1073         (JSC::DFG::JITFinalizer::finalizeCommon):
1074         * dfg/DFGOSRExitCompilerCommon.cpp:
1075         (JSC::DFG::adjustAndJumpToTarget):
1076         * dfg/DFGOperations.cpp:
1077         * dfg/DFGPlan.cpp:
1078         (JSC::DFG::Plan::Plan):
1079         (JSC::DFG::Plan::reallyAdd):
1080         (JSC::DFG::Plan::notifyReady):
1081         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
1082         (JSC::DFG::Plan::finalizeAndNotifyCallback):
1083         (JSC::DFG::Plan::key):
1084         (JSC::DFG::Plan::clearCodeBlockMarks):
1085         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
1086         (JSC::DFG::Plan::rememberCodeBlocks): Deleted.
1087         * dfg/DFGPlan.h:
1088         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
1089         (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
1090         (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
1091         (JSC::DFG::ToFTLDeferredCompilationCallback::create):
1092         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1093         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1094         * dfg/DFGToFTLDeferredCompilationCallback.h:
1095         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
1096         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
1097         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
1098         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
1099         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1100         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
1101         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
1102         * dfg/DFGWorklist.cpp:
1103         (JSC::DFG::Worklist::completeAllPlansForVM):
1104         (JSC::DFG::Worklist::clearCodeBlockMarks):
1105         (JSC::DFG::completeAllPlansForVM):
1106         (JSC::DFG::clearCodeBlockMarks):
1107         (JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
1108         (JSC::DFG::rememberCodeBlocks): Deleted.
1109         * dfg/DFGWorklist.h:
1110         (JSC::DFG::worklistForIndexOrNull):
1111         * ftl/FTLJITFinalizer.cpp:
1112         (JSC::FTL::JITFinalizer::finalizeFunction):
1113         * heap/CodeBlockSet.cpp:
1114         (JSC::CodeBlockSet::~CodeBlockSet):
1115         (JSC::CodeBlockSet::add):
1116         (JSC::CodeBlockSet::clearMarksForFullCollection):
1117         (JSC::CodeBlockSet::clearMarksForEdenCollection):
1118         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
1119         (JSC::CodeBlockSet::remove):
1120         (JSC::CodeBlockSet::traceMarked):
1121         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
1122         (JSC::CodeBlockSet::dump):
1123         * heap/CodeBlockSet.h:
1124         * heap/Heap.cpp:
1125         (JSC::Heap::markRoots):
1126         (JSC::Heap::clearLivenessData):
1127         (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
1128         (JSC::Heap::deleteAllCodeBlocks):
1129         (JSC::Heap::deleteAllUnlinkedCodeBlocks):
1130         (JSC::Heap::clearUnmarkedExecutables):
1131         (JSC::Heap::willStartCollection):
1132         * interpreter/Interpreter.cpp:
1133         (JSC::eval):
1134         * jit/GCAwareJITStubRoutine.h:
1135         * jit/JITCode.h:
1136         (JSC::JITCode::isJIT):
1137         (JSC::JITCode::timeToLive):
1138         (JSC::JITCode::isLowerTier):
1139         * jit/JITOpcodes.cpp:
1140         (JSC::JIT::emit_op_enter):
1141         * jit/JITOperations.cpp:
1142         * jit/JITToDFGDeferredCompilationCallback.cpp:
1143         (JSC::JITToDFGDeferredCompilationCallback::create):
1144         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1145         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1146         * jit/JITToDFGDeferredCompilationCallback.h:
1147         * jit/Repatch.cpp:
1148         (JSC::tryCacheGetByID):
1149         (JSC::tryCachePutByID):
1150         (JSC::tryRepatchIn):
1151         (JSC::linkFor):
1152         (JSC::linkPolymorphicCall):
1153         * llint/LLIntSlowPaths.cpp:
1154         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1155         (JSC::LLInt::setUpCall):
1156         * runtime/CommonSlowPaths.cpp:
1157         (JSC::SLOW_PATH_DECL):
1158         * runtime/CommonSlowPaths.h:
1159         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
1160         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
1161         * runtime/Executable.cpp:
1162         (JSC::ExecutableBase::clearCode):
1163         (JSC::ScriptExecutable::installCode):
1164         (JSC::ScriptExecutable::newCodeBlockFor):
1165         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
1166         (JSC::ScriptExecutable::prepareForExecutionImpl):
1167         (JSC::EvalExecutable::visitChildren):
1168         (JSC::EvalExecutable::clearCode):
1169         (JSC::ProgramExecutable::checkSyntax):
1170         (JSC::ProgramExecutable::visitChildren):
1171         (JSC::ProgramExecutable::clearCode):
1172         (JSC::ModuleProgramExecutable::visitChildren):
1173         (JSC::ModuleProgramExecutable::clearCode):
1174         (JSC::FunctionExecutable::baselineCodeBlockFor):
1175         (JSC::FunctionExecutable::visitChildren):
1176         (JSC::FunctionExecutable::clearCode):
1177         (JSC::FunctionExecutable::fromGlobalCode):
1178         (JSC::WebAssemblyExecutable::visitChildren):
1179         (JSC::WebAssemblyExecutable::clearCode):
1180         (JSC::WebAssemblyExecutable::prepareForExecution):
1181         * runtime/Executable.h:
1182         (JSC::ExecutableBase::generatedJITCodeForCall):
1183         (JSC::ScriptExecutable::prepareForExecution):
1184         (JSC::ExecutableBase::clearCodeVirtual):
1185         * runtime/VM.cpp:
1186         (JSC::VM::VM):
1187         * runtime/VM.h:
1188
1189 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
1190
1191         CodeBlock should be a GC object
1192         https://bugs.webkit.org/show_bug.cgi?id=149727
1193
1194         Reviewed by Filip Pizlo.
1195
1196         We want CodeBlock to be a GC object:
1197
1198         (1) Sane write barriers. Because CodeBlock wasn't a GC object, we couldn't
1199         execute a write barrier on it. This caused us to do weird things that
1200         were hard to reason about, like executing a barrier on a related executable
1201         (even though the executable might stop pointing to the CodeBlock before
1202         the next GC), or pretending that an object had written to itself. Now,
1203         when we write to a CodeBlock, we barrier the CodeBlock, and that's that.
1204
1205         (2) Simpler marking and destruction logic. There's no need to have a
1206         custom remembered set or a destruction fixpoint if we just obey normal
1207         GC rules.
1208
1209         * bytecode/CodeBlock.cpp:
1210         (JSC::FunctionCodeBlock::destroy):
1211         (JSC::WebAssemblyCodeBlock::destroy):
1212         (JSC::ProgramCodeBlock::destroy):
1213         (JSC::ModuleProgramCodeBlock::destroy):
1214         (JSC::EvalCodeBlock::destroy): Add ClassInfo and destroy functions
1215         because our GC object model requires them.
1216
1217         Note that we do not set the needsDestruction flag. Since CodeBlock needs
1218         eager destruction, it runs its destructors through CodeBlockSet,
1219         and not through normal object sweeping.
1220
1221         (JSC::CodeBlock::finishCreation): Factor out finishCreation from the
1222         constructor because our GC object model requires it. Change write
1223         barriers to note the CodeBlock as the owner.
1224
1225         (JSC::CodeBlock::~CodeBlock): Refactor to use the shared
1226         unlinkIncomingCalls() function instead of rolling a copy by hand.
1227
1228         (JSC::CodeBlock::visitWeakly): New helper function for owner executables
1229         to do weak marking that might jettison a CodeBlock. Our new GC logic
1230         says that a CodeBlock pointer is a strong reference by default, and
1231         clients need to opt in if they want to allow a CodeBlock to jettison.
1232         This is easier to get right because it means that only those
1233         specific owners that want jettison behavior need to worry about it,
1234         while all other pointers are valid by default.
1235
1236         (JSC::CodeBlock::visitChildren): The default visit function keeps
1237         everything alive.
1238
1239         (JSC::CodeBlock::shouldVisitStrongly):
1240         (JSC::CodeBlock::isKnownToBeLiveDuringGC): No need to keep special state
1241         anymore. If we're marked, we're live -- just like any other object.
1242
1243         (JSC::timeToLive): Move this code into CodeBlock.cpp so you can mess
1244         with it without recompiling, and also because it's really a CodeBlock
1245         policy.
1246
1247         (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
1248         (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Use
1249         internal objects for virtual callbacks because GC objects can't have
1250         vtables.
1251
1252         (JSC::CodeBlock::unlinkIncomingCalls): Remove a fast path check that does
1253         not exist in the copy of this code in ~CodeBlock because it is not
1254         actually an optimization.
1255
1256         (JSC::CodeBlock::replacement):
1257         (JSC::CodeBlock::computeCapabilityLevel): Make these functions generic
1258         instead of virtual because GC objects can't have vtables.
1259
1260         (JSC::CodeBlock::visitStrongly): Deleted.
1261         (JSC::CodeBlock::visitAggregate): Deleted.
1262         (JSC::CodeBlock::visitWeakReferences): Deleted.
1263         (JSC::CodeBlock::finalizeUnconditionally): Deleted.
1264         (JSC::ProgramCodeBlock::replacement): Deleted.
1265         (JSC::ModuleProgramCodeBlock::replacement): Deleted.
1266         (JSC::EvalCodeBlock::replacement): Deleted.
1267         (JSC::FunctionCodeBlock::replacement): Deleted.
1268         (JSC::ProgramCodeBlock::capabilityLevelInternal): Deleted.
1269         (JSC::ModuleProgramCodeBlock::capabilityLevelInternal): Deleted.
1270         (JSC::EvalCodeBlock::capabilityLevelInternal): Deleted.
1271         (JSC::FunctionCodeBlock::capabilityLevelInternal): Deleted.
1272         (JSC::WebAssemblyCodeBlock::replacement): Deleted.
1273         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal): Deleted.
1274
1275         * bytecode/CodeBlock.h:
1276         (JSC::CodeBlock::unlinkedCodeBlock):
1277         (JSC::CodeBlock::addressOfNumParameters):
1278         (JSC::CodeBlock::offsetOfNumParameters):
1279         (JSC::CodeBlock::alternative):
1280         (JSC::CodeBlock::forEachRelatedCodeBlock):
1281         (JSC::CodeBlock::specializationKind):
1282         (JSC::CodeBlock::instructionCount):
1283         (JSC::CodeBlock::setJITCode):
1284         (JSC::CodeBlock::hasBaselineJITProfiling):
1285         (JSC::CodeBlock::capabilityLevelState):
1286         (JSC::CodeBlock::addConstant):
1287         (JSC::CodeBlock::appendExceptionHandler):
1288         (JSC::CodeBlock::setConstantRegisters):
1289         (JSC::CodeBlock::replaceConstant):
1290         (JSC::GlobalCodeBlock::GlobalCodeBlock):
1291         (JSC::ProgramCodeBlock::create):
1292         (JSC::ProgramCodeBlock::createStructure):
1293         (JSC::ProgramCodeBlock::ProgramCodeBlock):
1294         (JSC::ModuleProgramCodeBlock::create):
1295         (JSC::ModuleProgramCodeBlock::createStructure):
1296         (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
1297         (JSC::EvalCodeBlock::create):
1298         (JSC::EvalCodeBlock::createStructure):
1299         (JSC::EvalCodeBlock::variable):
1300         (JSC::EvalCodeBlock::numVariables):
1301         (JSC::EvalCodeBlock::EvalCodeBlock):
1302         (JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
1303         (JSC::FunctionCodeBlock::create):
1304         (JSC::FunctionCodeBlock::createStructure):
1305         (JSC::FunctionCodeBlock::FunctionCodeBlock):
1306         (JSC::WebAssemblyCodeBlock::create):
1307         (JSC::WebAssemblyCodeBlock::createStructure):
1308         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
1309         (JSC::ExecState::uncheckedR):
1310         (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
1311         (JSC::CodeBlockSet::mark):
1312         (JSC::ScriptExecutable::forEachCodeBlock):
1313         (JSC::CodeBlock::setAlternative): Deleted.
1314         (JSC::CodeBlock::clearMarks): Deleted. Lots of mechanical changes to
1315         match the logic changes above.
1316
1317         * bytecode/DeferredCompilationCallback.cpp:
1318         (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
1319         (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
1320         (JSC::DeferredCompilationCallback::compilationDidComplete):
1321         * bytecode/DeferredCompilationCallback.h: Provide a profiledDFGCodeBlock
1322         to all compilation callbacks instead of requiring the callback to
1323         store the profiledDFGCodeBlock. This is how the rest of compilation
1324         around the callback works anyway, and it is easier to do things this
1325         way than to think about how a non-GC malloc'd object should keep its
1326         CodeBlock alive.
1327
1328         * bytecode/EvalCodeCache.h:
1329         (JSC::EvalCodeCache::tryGet):
1330         (JSC::EvalCodeCache::getSlow):
1331         * bytecode/PolymorphicAccess.cpp:
1332         (JSC::AccessCase::generate):
1333         (JSC::PolymorphicAccess::regenerate):
1334         * bytecode/StructureStubInfo.cpp:
1335         (JSC::StructureStubInfo::addAccessCase): Change the owner for write
1336         barrier purposes to CodeBlock.
1337
1338         * dfg/DFGByteCodeParser.cpp:
1339         (JSC::DFG::ByteCodeParser::parse):
1340         * dfg/DFGDesiredTransitions.cpp:
1341         (JSC::DFG::DesiredTransition::reallyAdd):
1342         * dfg/DFGDesiredWeakReferences.cpp:
1343         (JSC::DFG::DesiredWeakReferences::reallyAdd):
1344         * dfg/DFGDriver.cpp:
1345         (JSC::DFG::compile):
1346         * dfg/DFGGraph.cpp:
1347         (JSC::DFG::Graph::Graph): Ditto.
1348
1349         * dfg/DFGJITCode.h:
1350         (JSC::DFG::JITCode::osrEntryBlock):
1351         (JSC::DFG::JITCode::setOSREntryBlock):
1352         (JSC::DFG::JITCode::clearOSREntryBlock): Use helper functions for 
1353         accessing osrEntryBlock to help with write barrier stuff.
1354
1355         * dfg/DFGJITFinalizer.cpp:
1356         (JSC::DFG::JITFinalizer::finalize):
1357         (JSC::DFG::JITFinalizer::finalizeFunction):
1358         (JSC::DFG::JITFinalizer::finalizeCommon):
1359         * dfg/DFGOSRExitCompilerCommon.cpp:
1360         (JSC::DFG::adjustAndJumpToTarget): Use CodeBlock as owner instead of
1361         executable.
1362
1363         * dfg/DFGOperations.cpp:
1364         * dfg/DFGPlan.cpp:
1365         (JSC::DFG::Plan::Plan):
1366         (JSC::DFG::Plan::reallyAdd):
1367         (JSC::DFG::Plan::notifyReady):
1368         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
1369         (JSC::DFG::Plan::finalizeAndNotifyCallback):
1370         (JSC::DFG::Plan::key):
1371         (JSC::DFG::Plan::rememberCodeBlocks):
1372         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
1373         (JSC::DFG::Plan::clearCodeBlockMarks): Deleted.
1374         * dfg/DFGPlan.h: Use normal GC write barrier concepts to model the fact
1375         that the compiler writes to CodeBlocks.
1376
1377         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
1378         (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
1379         (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
1380         (JSC::DFG::ToFTLDeferredCompilationCallback::create):
1381         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1382         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1383         * dfg/DFGToFTLDeferredCompilationCallback.h:
1384         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
1385         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
1386         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
1387         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
1388         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1389         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
1390         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: We always have
1391         a profiledDFGCodeBlock passed to use -- see above.
1392
1393         * dfg/DFGWorklist.cpp:
1394         (JSC::DFG::Worklist::completeAllPlansForVM):
1395         (JSC::DFG::Worklist::rememberCodeBlocks):
1396         (JSC::DFG::completeAllPlansForVM):
1397         (JSC::DFG::rememberCodeBlocks):
1398         (JSC::DFG::Worklist::clearCodeBlockMarks): Deleted.
1399         (JSC::DFG::clearCodeBlockMarks): Deleted.
1400         * dfg/DFGWorklist.h:
1401         (JSC::DFG::worklistForIndexOrNull): Renamed to use remembered set terminology.
1402
1403         * ftl/FTLJITFinalizer.cpp:
1404         (JSC::FTL::JITFinalizer::finalizeFunction):
1405
1406         * heap/CodeBlockSet.cpp:
1407         (JSC::CodeBlockSet::~CodeBlockSet):
1408         (JSC::CodeBlockSet::add):
1409         (JSC::CodeBlockSet::clearMarksForFullCollection):
1410         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): No need for a fixpoint
1411         anymore since the GC can tell us if we are live.
1412
1413         (JSC::CodeBlockSet::remove):
1414         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
1415         (JSC::CodeBlockSet::dump):
1416         (JSC::CodeBlockSet::clearMarksForEdenCollection): Deleted. No need for
1417         this logic anymore since the GC will clear our mark bit.
1418
1419         (JSC::CodeBlockSet::traceMarked): Deleted. No need for this marking
1420         fixpoint anymore either.
1421
1422         * heap/CodeBlockSet.h:
1423
1424         * heap/Heap.cpp:
1425         (JSC::Heap::markRoots): Moved some of this logic around to make the
1426         algorithm clearer. 
1427
1428         (JSC::Heap::deleteAllCodeBlocks): Deleting CodeBlocks can only clear
1429         pointers immediately; they won't fully delete until the next GC and sweep.
1430
1431         * interpreter/Interpreter.cpp:
1432         (JSC::eval):
1433         * jit/GCAwareJITStubRoutine.h: CodeBlock is owner now.
1434
1435         * jit/JITCode.h:
1436         (JSC::JITCode::isJIT):
1437         (JSC::JITCode::isLowerTier):
1438         (JSC::JITCode::timeToLive): Deleted.
1439
1440         * jit/JITOpcodes.cpp:
1441         (JSC::JIT::emit_op_enter): CodeBlock is owner now.
1442
1443         * jit/JITOperations.cpp:
1444         * jit/JITToDFGDeferredCompilationCallback.cpp:
1445         (JSC::JITToDFGDeferredCompilationCallback::create):
1446         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1447         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1448         * jit/JITToDFGDeferredCompilationCallback.h:
1449
1450         * jit/Repatch.cpp:
1451         (JSC::tryCacheGetByID):
1452         (JSC::tryCachePutByID):
1453         (JSC::tryRepatchIn):
1454         (JSC::linkFor):
1455         (JSC::linkPolymorphicCall):
1456         * llint/LLIntSlowPaths.cpp:
1457         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1458         (JSC::LLInt::setUpCall):
1459         * runtime/CommonSlowPaths.cpp:
1460         (JSC::SLOW_PATH_DECL): 
1461         * runtime/CommonSlowPaths.h:
1462         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
1463         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): CodeBlock is owner now.
1464
1465         * runtime/Executable.cpp:
1466         (JSC::ExecutableBase::clearCode): Provide a generic clearCode() so that
1467         it can be used on any Executable. This fixes a very subtle bug where
1468         deleteAllCode() does not remove CodeBlocks from non-function executables
1469         that have been saved in stack traces.
1470
1471         (JSC::ScriptExecutable::installCode): WriteBarrier requires special
1472         handling for pointers that may be null.
1473
1474         (JSC::ScriptExecutable::newCodeBlockFor):
1475         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
1476         (JSC::ScriptExecutable::prepareForExecutionImpl): Update for interface
1477         changes.
1478
1479         (JSC::EvalExecutable::visitChildren):
1480         (JSC::ProgramExecutable::visitChildren):
1481         (JSC::ModuleProgramExecutable::visitChildren):
1482         (JSC::FunctionExecutable::visitChildren):
1483         (JSC::WebAssemblyExecutable::visitChildren): Visit weakly because we want
1484         to participate in jettisoning.
1485
1486         (JSC::WebAssemblyExecutable::prepareForExecution):
1487         (JSC::EvalExecutable::clearCode): Deleted.
1488         (JSC::ProgramExecutable::clearCode): Deleted.
1489         (JSC::ModuleProgramExecutable::clearCode): Deleted.
1490         (JSC::FunctionExecutable::clearCode): Deleted.
1491         (JSC::WebAssemblyExecutable::clearCode): Deleted.
1492
1493         * runtime/Executable.h:
1494         (JSC::ExecutableBase::generatedJITCodeForCall):
1495         (JSC::ScriptExecutable::prepareForExecution):
1496         (JSC::ExecutableBase::clearCodeVirtual): Deleted.
1497
1498         * runtime/VM.cpp:
1499         (JSC::VM::VM):
1500         * runtime/VM.h: Provide structures because our GC requires it.
1501
1502 2015-10-01  Mark Lam  <mark.lam@apple.com>
1503
1504         Remove unnecessary SpecialFastCaseProfiles.
1505         https://bugs.webkit.org/show_bug.cgi?id=149729
1506
1507         Reviewed by Saam Barati.
1508
1509         The current baseline code creates special fast case profiles records for
1510         bytecodes that don't need them.  This was done to keep the DFG from crashing when
1511         it searches for such a profile and don't find one.  Instead, we will fix the code
1512         to check for the existence of the profile before dereferencing it to get a count.
1513
1514         * bytecode/CodeBlock.h:
1515         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
1516         (JSC::CodeBlock::couldTakeSpecialFastCase):
1517         (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
1518         (JSC::CodeBlock::numberOfArrayProfiles):
1519         (JSC::CodeBlock::arrayProfiles):
1520         (JSC::CodeBlock::addArrayProfile):
1521         (JSC::CodeBlock::likelyToTakeSpecialFastCase): Deleted.  Not used.
1522         (JSC::CodeBlock::likelyToTakeAnySlowCase): Deleted.   Not used.
1523         * jit/JITArithmetic.cpp:
1524
1525         (JSC::JIT::compileBinaryArithOp):
1526         - Only op_mul needs the profile.  So, only allocate it in the op_mul case.
1527
1528         (JSC::JIT::emit_op_mul):
1529         - These op_mul cases create the profile but never increments its counter.
1530           Hence, we can get rid of these.
1531
1532 2015-10-01  Keith Miller  <keith_miller@apple.com>
1533
1534         [ES6] Add TypedArray.prototype functionality.
1535         https://bugs.webkit.org/show_bug.cgi?id=148035
1536
1537         Reviewed by Geoffrey Garen.
1538
1539         This patch should add most of the functionality for
1540         the prototype properties of TypedArray objects in ES6.
1541         There are a few exceptions to this, which will be added
1542         in upcoming patches:
1543
1544         1) First we do not use the species constructor for some
1545         of the TypedArray prototype functions (namely: map, filter,
1546         slice, and subarray). That will need to be added when
1547         species constructors are finished.
1548
1549         2) TypedArrays still have a length, byteOffset, byteLength,
1550         and buffer are still attached to the TypedArray instance (in
1551         the spec they are on the TypedArray.prototype instance object)
1552         since the JIT currently assumes those properties are fixed.
1553
1554         3) The TypedArray.constructor property is not added yet
1555         as it should point to the TypedArray instance object,
1556         which will be added in a future patch.
1557
1558         * CMakeLists.txt:
1559         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1560         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1561         * JavaScriptCore.xcodeproj/project.pbxproj:
1562         * builtins/TypedArray.prototype.js: Added.
1563         (every):
1564         (find):
1565         (findIndex):
1566         (forEach):
1567         (some):
1568         (sort.min):
1569         (sort.merge):
1570         (sort.mergeSort):
1571         (sort):
1572         (reduce):
1573         (reduceRight):
1574         (map):
1575         (filter):
1576         (toLocaleString):
1577         * runtime/ArrayPrototype.cpp:
1578         * runtime/ArrayPrototype.h:
1579         * runtime/CommonIdentifiers.h:
1580         * runtime/JSGenericTypedArrayView.h:
1581         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
1582         (JSC::JSGenericTypedArrayView::setRangeToValue):
1583         (JSC::JSGenericTypedArrayView::sort):
1584         (JSC::JSGenericTypedArrayView::purifyArray):
1585         (JSC::JSGenericTypedArrayView::sortComparison):
1586         (JSC::JSGenericTypedArrayView::sortFloat):
1587         * runtime/JSGenericTypedArrayViewInlines.h:
1588         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
1589         (JSC::argumentClampedIndexFromStartOrEnd):
1590         (JSC::genericTypedArrayViewProtoFuncSet):
1591         (JSC::genericTypedArrayViewProtoFuncEntries):
1592         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
1593         (JSC::genericTypedArrayViewProtoFuncFill):
1594         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1595         (JSC::genericTypedArrayViewProtoFuncJoin):
1596         (JSC::genericTypedArrayViewProtoFuncKeys):
1597         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1598         (JSC::genericTypedArrayViewProtoGetterFuncLength):
1599         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
1600         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
1601         (JSC::genericTypedArrayViewProtoFuncReverse):
1602         (JSC::genericTypedArrayViewPrivateFuncSort):
1603         (JSC::genericTypedArrayViewProtoFuncSlice):
1604         (JSC::genericTypedArrayViewProtoFuncSubarray):
1605         (JSC::typedArrayViewProtoFuncValues):
1606         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1607         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1608         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
1609         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
1610         * runtime/JSGlobalObject.cpp:
1611         (JSC::JSGlobalObject::init):
1612         * runtime/JSObject.h:
1613         * runtime/JSTypedArrayPrototypes.cpp:
1614         * runtime/JSTypedArrayPrototypes.h:
1615         * runtime/JSTypedArrayViewPrototype.cpp: Added.
1616         (JSC::typedArrayViewPrivateFuncLength):
1617         (JSC::typedArrayViewPrivateFuncSort):
1618         (JSC::typedArrayViewProtoFuncSet):
1619         (JSC::typedArrayViewProtoFuncEntries):
1620         (JSC::typedArrayViewProtoFuncCopyWithin):
1621         (JSC::typedArrayViewProtoFuncFill):
1622         (JSC::typedArrayViewProtoFuncLastIndexOf):
1623         (JSC::typedArrayViewProtoFuncIndexOf):
1624         (JSC::typedArrayViewProtoFuncJoin):
1625         (JSC::typedArrayViewProtoFuncKeys):
1626         (JSC::typedArrayViewProtoGetterFuncLength):
1627         (JSC::typedArrayViewProtoGetterFuncByteLength):
1628         (JSC::typedArrayViewProtoGetterFuncByteOffset):
1629         (JSC::typedArrayViewProtoFuncReverse):
1630         (JSC::typedArrayViewProtoFuncSubarray):
1631         (JSC::typedArrayViewProtoFuncSlice):
1632         (JSC::typedArrayViewProtoFuncValues):
1633         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
1634         (JSC::JSTypedArrayViewPrototype::finishCreation):
1635         (JSC::JSTypedArrayViewPrototype::create):
1636         (JSC::JSTypedArrayViewPrototype::createStructure):
1637         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
1638         * tests/es6.yaml:
1639         * tests/stress/resources/standalone-pre.js: Added.
1640         (description):
1641         (debug):
1642         (escapeString):
1643         (testPassed):
1644         (testFailed):
1645         (areNumbersEqual):
1646         (areArraysEqual):
1647         (isMinusZero):
1648         (isTypedArray):
1649         (isResultCorrect):
1650         (stringify):
1651         (shouldBe):
1652         (dfgShouldBe):
1653         (shouldBeType):
1654         (shouldBeTrue):
1655         (shouldBeFalse):
1656         (shouldBeNaN):
1657         (shouldBeNull):
1658         (shouldBeEqualToString):
1659         (shouldBeUndefined):
1660         (shouldNotThrow):
1661         (shouldThrow):
1662         (dfgCompiled):
1663         (dfgIncrement):
1664         (noInline):
1665         (finishJSTest):
1666         * tests/stress/resources/typedarray-test-helper-functions.js: Added.
1667         (forEachTypedArray):
1668         (isSameFunctionForEachTypedArrayPrototype.eq):
1669         (isSameFunctionForEachTypedArrayPrototype):
1670         (hasSameValues):
1671         (foo):
1672         (testPrototypeFunctionHelper):
1673         (testPrototypeFunctionOnSigned):
1674         (testPrototypeFunctionOnFloat):
1675         (testPrototypeFunction):
1676         (tester):
1677         (testPrototypeReceivesArray):
1678         * tests/stress/typedarray-copyWithin.js: Added.
1679         * tests/stress/typedarray-every.js: Added.
1680         (isBigEnough):
1681         (isBigEnoughAndChange):
1682         (isBigEnoughAndException):
1683         * tests/stress/typedarray-fill.js: Added.
1684         * tests/stress/typedarray-filter.js: Added.
1685         (keepEven):
1686         (keepEvenAndChange):
1687         (isBigEnoughAndException):
1688         * tests/stress/typedarray-find.js: Added.
1689         (keepEven):
1690         (keepEvenAndChange):
1691         (isBigEnoughAndException):
1692         * tests/stress/typedarray-findIndex.js: Added.
1693         (keepEven):
1694         (keepEvenAndChange):
1695         (isBigEnoughAndException):
1696         * tests/stress/typedarray-forEach.js: Added.
1697         (checkCorrect.let.list):
1698         (checkCorrect):
1699         (createChecker):
1700         (foo):
1701         (changeArray):
1702         (isBigEnoughAndException):
1703         * tests/stress/typedarray-indexOf.js: Added.
1704         (keepEven):
1705         * tests/stress/typedarray-lastIndexOf.js: Added.
1706         * tests/stress/typedarray-map.js: Added.
1707         (even):
1708         (evenAndChange):
1709         (isBigEnoughAndException):
1710         * tests/stress/typedarray-reduce.js: Added.
1711         (createArray):
1712         (sum):
1713         (createArrayAndChange):
1714         (isBigEnoughAndException):
1715         * tests/stress/typedarray-reduceRight.js: Added.
1716         (createArray):
1717         (sum):
1718         (createArrayAndChange):
1719         (isBigEnoughAndException):
1720         * tests/stress/typedarray-slice.js: Added.
1721         * tests/stress/typedarray-some.js: Added.
1722         (isBigEnough):
1723         (isBigEnoughAndChange):
1724         (isBigEnoughAndException):
1725         * tests/stress/typedarray-sort.js: Added.
1726         (sortBackwards):
1727         (compareException):
1728
1729 2015-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
1730
1731         Introduce SymbolUse optimization into CompareEq and CompareStrictEq
1732         https://bugs.webkit.org/show_bug.cgi?id=149616
1733
1734         Reviewed by Saam Barati.
1735
1736         Since ES6 Symbols are used as an enum value[1] (And WebKit inspector do so for Esprima's type of nodes),
1737         optimizing equality comparison for symbols makes much sense.
1738
1739         This patch leverages SymbolUse for CompareEq and CompareStrictEq.
1740         Optimizations for both DFG and FTL are implemented.
1741
1742         [1]: http://www.2ality.com/2014/12/es6-symbols.html
1743
1744         * dfg/DFGAbstractInterpreterInlines.h:
1745         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1746         * dfg/DFGFixupPhase.cpp:
1747         (JSC::DFG::FixupPhase::fixupNode):
1748         * dfg/DFGNode.h:
1749         (JSC::DFG::Node::shouldSpeculateSymbol):
1750         * dfg/DFGSpeculativeJIT.cpp:
1751         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
1752         (JSC::DFG::SpeculativeJIT::compare):
1753         (JSC::DFG::SpeculativeJIT::compileStrictEq):
1754         (JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols):
1755         (JSC::DFG::SpeculativeJIT::compileSymbolEquality):
1756         (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
1757         * dfg/DFGSpeculativeJIT.h:
1758         * ftl/FTLCapabilities.cpp:
1759         (JSC::FTL::canCompile):
1760         * ftl/FTLLowerDFGToLLVM.cpp:
1761         (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
1762         (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
1763         * tests/stress/symbol-equality.js: Added.
1764         (shouldBe):
1765         (equal):
1766         (strictEqual):
1767         (list.forEach.result.set 1):
1768
1769 2015-10-01  Youenn Fablet  <youenn.fablet@crf.canon.fr>
1770
1771         [Streams API] Add support for private WebCore JS builtins functions
1772         https://bugs.webkit.org/show_bug.cgi?id=149518
1773
1774         Reviewed by Darin Adler.
1775
1776         Adding API to add private identifiers on the fly.
1777         This is used to support private JS Builtin functions/private JS Builtin names in WebCore.
1778
1779         * builtins/BuiltinNames.h:
1780         (JSC::BuiltinNames::appendExternalName):
1781         * runtime/CommonIdentifiers.cpp:
1782         (JSC::CommonIdentifiers::appendExternalName):
1783         * runtime/CommonIdentifiers.h:
1784
1785 2015-09-30  Jaehun Lim  <ljaehun.lim@samsung.com>
1786
1787         Unreviewed, cleanup after r190385
1788
1789         TypedArray.prototype.js is removed at r190385.
1790         Remove it from CMakeLists.txt as well.
1791
1792         * CMakeLists.txt:
1793
1794 2015-09-30  Commit Queue  <commit-queue@webkit.org>
1795
1796         Unreviewed, rolling out r190367 and r190373.
1797         https://bugs.webkit.org/show_bug.cgi?id=149694
1798
1799         Windows build broken (Requested by smfr on #webkit).
1800
1801         Reverted changesets:
1802
1803         "[ES6] Add TypedArray.prototype functionality."
1804         https://bugs.webkit.org/show_bug.cgi?id=148035
1805         http://trac.webkit.org/changeset/190367
1806
1807         "Unreviewed Windows buildfix."
1808         http://trac.webkit.org/changeset/190373
1809
1810 2015-09-30  Keith Miller  <keith_miller@apple.com>
1811
1812         Unreviewed Windows buildfix.
1813
1814         * CMakeLists.txt:
1815
1816 2015-09-30  Michael Saboff  <msaboff@apple.com>
1817
1818         Relanding r190289 with the following two fixes:
1819
1820          1. REGRESSION(r190289): It made Speedometer/Full.html performance test fail
1821             https://bugs.webkit.org/show_bug.cgi?id=149621
1822
1823             Reviewed by Saam Barati.
1824
1825             We need to restore callee saves for both the fast and slow paths before making a
1826             tail call in the FTL.
1827
1828             * ftl/FTLJSCallBase.cpp:
1829             (JSC::FTL::JSCallBase::emit):
1830
1831          2. [ARM] REGRESSION(r190289): It made 374 tests crash on 32 bit ARM Linux
1832             https://bugs.webkit.org/show_bug.cgi?id=149619
1833
1834             Reviewed by Filip Pizlo.
1835
1836             Need to check for ARMv7_TRADITIONAL and ARMv7 in addition to ARM in "if"
1837             statement to handle platforms with a link register.
1838             
1839             * llint/LowLevelInterpreter.asm:
1840             (prepareForTailCall):
1841
1842 2015-09-30  Keith Miller  <keith_miller@apple.com>
1843
1844         [ES6] Add TypedArray.prototype functionality.
1845         https://bugs.webkit.org/show_bug.cgi?id=148035
1846
1847         Reviewed by Geoffrey Garen.
1848
1849         This patch should add most of the functionality for
1850         the prototype properties of TypedArray objects in ES6.
1851         There are a few exceptions to this, which will be added
1852         in upcoming patches:
1853
1854         1) First we do not use the species constructor for some
1855         of the TypedArray prototype functions (namely: map, filter,
1856         slice, and subarray). That will need to be added when
1857         species constructors are finished.
1858
1859         2) TypedArrays still have a length, byteOffset, byteLength,
1860         and buffer are still attached to the TypedArray instance (in
1861         the spec they are on the TypedArray.prototype instance object)
1862         since the JIT currently assumes those properties are fixed.
1863
1864         3) The TypedArray.constructor property is not added yet
1865         as it should point to the TypedArray instance object,
1866         which will be added in a future patch.
1867
1868         * CMakeLists.txt:
1869         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1870         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1871         * JavaScriptCore.xcodeproj/project.pbxproj:
1872         * builtins/TypedArray.prototype.js: Added.
1873         (every):
1874         (find):
1875         (findIndex):
1876         (forEach):
1877         (some):
1878         (sort.min):
1879         (sort.merge):
1880         (sort.mergeSort):
1881         (sort):
1882         (reduce):
1883         (reduceRight):
1884         (map):
1885         (filter):
1886         (toLocaleString):
1887         * runtime/ArrayPrototype.cpp:
1888         * runtime/ArrayPrototype.h:
1889         * runtime/CommonIdentifiers.h:
1890         * runtime/JSGenericTypedArrayView.h:
1891         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
1892         (JSC::JSGenericTypedArrayView::setRangeToValue):
1893         (JSC::JSGenericTypedArrayView::sort):
1894         (JSC::JSGenericTypedArrayView::purifyArray):
1895         (JSC::JSGenericTypedArrayView::sortComparison):
1896         (JSC::JSGenericTypedArrayView::sortFloat):
1897         * runtime/JSGenericTypedArrayViewInlines.h:
1898         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
1899         (JSC::argumentClampedIndexFromStartOrEnd):
1900         (JSC::genericTypedArrayViewProtoFuncSet):
1901         (JSC::genericTypedArrayViewProtoFuncEntries):
1902         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
1903         (JSC::genericTypedArrayViewProtoFuncFill):
1904         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1905         (JSC::genericTypedArrayViewProtoFuncJoin):
1906         (JSC::genericTypedArrayViewProtoFuncKeys):
1907         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1908         (JSC::genericTypedArrayViewProtoGetterFuncLength):
1909         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
1910         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
1911         (JSC::genericTypedArrayViewProtoFuncReverse):
1912         (JSC::genericTypedArrayViewPrivateFuncSort):
1913         (JSC::genericTypedArrayViewProtoFuncSlice):
1914         (JSC::genericTypedArrayViewProtoFuncSubarray):
1915         (JSC::typedArrayViewProtoFuncValues):
1916         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1917         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1918         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
1919         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
1920         * runtime/JSGlobalObject.cpp:
1921         (JSC::JSGlobalObject::init):
1922         * runtime/JSObject.h:
1923         * runtime/JSTypedArrayPrototypes.cpp:
1924         * runtime/JSTypedArrayPrototypes.h:
1925         * runtime/JSTypedArrayViewPrototype.cpp: Added.
1926         (JSC::typedArrayViewPrivateFuncLength):
1927         (JSC::typedArrayViewPrivateFuncSort):
1928         (JSC::typedArrayViewProtoFuncSet):
1929         (JSC::typedArrayViewProtoFuncEntries):
1930         (JSC::typedArrayViewProtoFuncCopyWithin):
1931         (JSC::typedArrayViewProtoFuncFill):
1932         (JSC::typedArrayViewProtoFuncLastIndexOf):
1933         (JSC::typedArrayViewProtoFuncIndexOf):
1934         (JSC::typedArrayViewProtoFuncJoin):
1935         (JSC::typedArrayViewProtoFuncKeys):
1936         (JSC::typedArrayViewProtoGetterFuncLength):
1937         (JSC::typedArrayViewProtoGetterFuncByteLength):
1938         (JSC::typedArrayViewProtoGetterFuncByteOffset):
1939         (JSC::typedArrayViewProtoFuncReverse):
1940         (JSC::typedArrayViewProtoFuncSubarray):
1941         (JSC::typedArrayViewProtoFuncSlice):
1942         (JSC::typedArrayViewProtoFuncValues):
1943         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
1944         (JSC::JSTypedArrayViewPrototype::finishCreation):
1945         (JSC::JSTypedArrayViewPrototype::create):
1946         (JSC::JSTypedArrayViewPrototype::createStructure):
1947         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
1948         * tests/stress/resources/standalone-pre.js: Added.
1949         (description):
1950         (debug):
1951         (escapeString):
1952         (testPassed):
1953         (testFailed):
1954         (areNumbersEqual):
1955         (areArraysEqual):
1956         (isMinusZero):
1957         (isTypedArray):
1958         (isResultCorrect):
1959         (stringify):
1960         (shouldBe):
1961         (dfgShouldBe):
1962         (shouldBeType):
1963         (shouldBeTrue):
1964         (shouldBeFalse):
1965         (shouldBeNaN):
1966         (shouldBeNull):
1967         (shouldBeEqualToString):
1968         (shouldBeUndefined):
1969         (shouldNotThrow):
1970         (shouldThrow):
1971         (dfgCompiled):
1972         (dfgIncrement):
1973         (noInline):
1974         (finishJSTest):
1975         * tests/stress/resources/typedarray-test-helper-functions.js: Added.
1976         (forEachTypedArray):
1977         (isSameFunctionForEachTypedArrayPrototype.eq):
1978         (isSameFunctionForEachTypedArrayPrototype):
1979         (hasSameValues):
1980         (.foo):
1981         (testPrototypeFunctionHelper):
1982         (testPrototypeFunctionOnSigned):
1983         (testPrototypeFunctionOnFloat):
1984         (testPrototypeFunction):
1985         (.tester):
1986         (testPrototypeReceivesArray):
1987         * tests/stress/typedarray-copyWithin.js: Added.
1988         * tests/stress/typedarray-every.js: Added.
1989         (isBigEnough):
1990         (isBigEnoughAndChange):
1991         (isBigEnoughAndException):
1992         * tests/stress/typedarray-fill.js: Added.
1993         * tests/stress/typedarray-filter.js: Added.
1994         (keepEven):
1995         (keepEvenAndChange):
1996         (isBigEnoughAndException):
1997         * tests/stress/typedarray-find.js: Added.
1998         (keepEven):
1999         (keepEvenAndChange):
2000         (isBigEnoughAndException):
2001         * tests/stress/typedarray-findIndex.js: Added.
2002         (keepEven):
2003         (keepEvenAndChange):
2004         (isBigEnoughAndException):
2005         * tests/stress/typedarray-forEach.js: Added.
2006         (.checkCorrect.let.list):
2007         (.checkCorrect):
2008         (createChecker):
2009         (foo):
2010         (changeArray):
2011         (isBigEnoughAndException):
2012         * tests/stress/typedarray-indexOf.js: Added.
2013         (keepEven):
2014         * tests/stress/typedarray-lastIndexOf.js: Added.
2015         * tests/stress/typedarray-map.js: Added.
2016         (even):
2017         (evenAndChange):
2018         (isBigEnoughAndException):
2019         * tests/stress/typedarray-reduce.js: Added.
2020         (createArray):
2021         (sum):
2022         (createArrayAndChange):
2023         (isBigEnoughAndException):
2024         * tests/stress/typedarray-reduceRight.js: Added.
2025         (createArray):
2026         (sum):
2027         (createArrayAndChange):
2028         (isBigEnoughAndException):
2029         * tests/stress/typedarray-slice.js: Added.
2030         * tests/stress/typedarray-some.js: Added.
2031         (isBigEnough):
2032         (isBigEnoughAndChange):
2033         (isBigEnoughAndException):
2034         * tests/stress/typedarray-sort.js: Added.
2035         (sortBackwards):
2036         (compareException):
2037
2038 2015-09-30  Commit Queue  <commit-queue@webkit.org>
2039
2040         Unreviewed, rolling out r190324.
2041         https://bugs.webkit.org/show_bug.cgi?id=149671
2042
2043         Caused flaky crashes, rdar://problem/22916304 (Requested by ap
2044         on #webkit).
2045
2046         Reverted changeset:
2047
2048         "ParallelHelperPool::runFunctionInParallel() shouldn't
2049         allocate, and ParallelHelperPool.h shouldn't be included
2050         everywhere"
2051         https://bugs.webkit.org/show_bug.cgi?id=149635
2052         http://trac.webkit.org/changeset/190324
2053
2054 2015-09-29  Commit Queue  <commit-queue@webkit.org>
2055
2056         Unreviewed, rolling out r190289.
2057         https://bugs.webkit.org/show_bug.cgi?id=149647
2058
2059         Crashing speedometer and some ARM32 tests (Requested by
2060         msaboff on #webkit).
2061
2062         Reverted changeset:
2063
2064         "[ES6] Implement tail calls in the FTL"
2065         https://bugs.webkit.org/show_bug.cgi?id=148664
2066         http://trac.webkit.org/changeset/190289
2067
2068 2015-09-29  Filip Pizlo  <fpizlo@apple.com>
2069
2070         ParallelHelperPool::runFunctionInParallel() shouldn't allocate, and ParallelHelperPool.h shouldn't be included everywhere
2071         https://bugs.webkit.org/show_bug.cgi?id=149635
2072
2073         Reviewed by Saam Barati.
2074
2075         It bugged me that this change caused a whole-world recompile. So, I changed the code so
2076         that ParallelHelperPool.h is only included by Heap.cpp and not by Heap.h.
2077
2078         * heap/Heap.cpp:
2079         (JSC::Heap::Heap):
2080         (JSC::Heap::markRoots):
2081         (JSC::Heap::copyBackingStores):
2082         * heap/Heap.h:
2083
2084 2015-09-29  Filip Pizlo  <fpizlo@apple.com>
2085
2086         GC copy phase spans too many files
2087         https://bugs.webkit.org/show_bug.cgi?id=149586
2088
2089         Reviewed by Andreas Kling.
2090
2091         This puts the core logic of the copy phase into Heap::copyBackingStores(). Now, instead of
2092         using many helpers in many places, the actual algorithm is all in one place.
2093
2094         This lets me do a lot of simplification.
2095
2096         - CopyVisitor no longer requires that you call startCopying() before, and doneCopying() and
2097           WTF::releaseFastMallocFreeMemoryForThisThread() after. The constructor and destructor now
2098           do this for you.
2099
2100         - CopyVisitor no longer contains the algorithm that drives copying. That's all in
2101           Heap::copyBackingStores() now. Basically, copyBackingStores() glues together the new
2102           WTF::ParallelVectorIterator with the copying algorithm that we used to have in
2103           CopyVisitor::copyFromShared().
2104
2105         - Lots of stuff that was in headers is now in .cpp files. That includes all non-hot-path
2106           code in CopyVisitor. Also, the code for copying in HeapInlines.h is now in
2107           ParallelVectorVisotor, and it's only included by Heap.cpp.
2108
2109         Overall, I like this direction for the GC. I don't think it's useful for Heap.cpp to have
2110         calls to algorithms in some other file, unless those algorithms are either reusable or just
2111         very dense. That's not actually true for the copy phase, and it's probably not true for
2112         some other stuff like marking. I'll probably do the same refactoring for marking in another
2113         bug.
2114
2115         This should have no effect on performance.
2116
2117         * heap/CopyVisitor.cpp:
2118         (JSC::CopyVisitor::CopyVisitor):
2119         (JSC::CopyVisitor::~CopyVisitor):
2120         (JSC::CopyVisitor::copyFromShared): Deleted.
2121         * heap/CopyVisitor.h:
2122         * heap/CopyVisitorInlines.h:
2123         (JSC::CopyVisitor::checkIfShouldCopy):
2124         (JSC::CopyVisitor::allocateNewSpaceSlow):
2125         (JSC::CopyVisitor::didCopy):
2126         (JSC::CopyVisitor::visitItem): Deleted.
2127         (JSC::CopyVisitor::startCopying): Deleted.
2128         (JSC::CopyVisitor::doneCopying): Deleted.
2129         * heap/Heap.cpp:
2130         (JSC::Heap::copyBackingStores):
2131         * heap/Heap.h:
2132         * heap/HeapInlines.h:
2133         (JSC::Heap::unregisterWeakGCMap):
2134         (JSC::Heap::getNextBlocksToCopy): Deleted.
2135
2136 2015-09-29  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2137
2138         Add support for WebIDL JSBuiltin attributes
2139         https://bugs.webkit.org/show_bug.cgi?id=149554
2140
2141         Reviewed by Darin Adler.
2142
2143         * runtime/Lookup.cpp:
2144         (JSC::reifyStaticAccessor): Adding support for creating attribute getter from JS builtin functions.
2145         * runtime/Lookup.h:
2146         (JSC::HashTableValue::builtinAccessorGetterGenerator):
2147         (JSC::HashTableValue::builtinAccessorSetterGenerator):
2148         (JSC::reifyStaticProperties): Ensuring that builtin attributes are not treated as Builtin functions.
2149
2150 2015-09-28  Joseph Pecoraro  <pecoraro@apple.com>
2151
2152         Remove unused parseMemoryAmount
2153         https://bugs.webkit.org/show_bug.cgi?id=149611
2154
2155         Reviewed by Mark Lam.
2156
2157         * heap/HeapStatistics.cpp:
2158         (JSC::HeapStatistics::parseMemoryAmount): Deleted.
2159         * heap/HeapStatistics.h:
2160
2161 2015-09-28  Joseph Pecoraro  <pecoraro@apple.com>
2162
2163         Web Inspector: JSGlobalRuntimeAgent unintentionally overrides InspectorRuntimeAgent destruction handling
2164         https://bugs.webkit.org/show_bug.cgi?id=149537
2165
2166         Reviewed by Darin Adler.
2167
2168         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
2169         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
2170         (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend): Deleted.
2171         Do not override method, super class implementation is sufficient.
2172
2173         * JavaScriptCore.xcodeproj/project.pbxproj:
2174         Fix file ordering.
2175
2176         * inspector/agents/InspectorDebuggerAgent.h:
2177         Remove unused member variable.
2178
2179 2015-09-28  basile_clement@apple.com  <basile_clement@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
2180
2181         [ES6] Implement tail calls in the FTL
2182         https://bugs.webkit.org/show_bug.cgi?id=148664
2183
2184         Reviewed by Filip Pizlo.
2185
2186         This patch implements the tail call opcodes in the FTL, making tail
2187         calls available through all tiers. The changes are relatively
2188         straightforward, although the frame shuffler had to be extended to
2189         handle the possibility of running out of stack when spilling or
2190         building a slow path frame. The other tiers always ensure that we have
2191         enough stack space to build the new frame at the bottom of the old one,
2192         but that is not true for the FTL.
2193
2194         Moreover, for efficiency, this adds to the shuffler the ability to
2195         record the state of the TagTypeNumber, and to re-use the same register
2196         when doing several consecutive integer boxings with no spilling in
2197         between.
2198
2199         * JavaScriptCore.xcodeproj/project.pbxproj:
2200         * bytecode/ValueRecovery.h:
2201         (JSC::ValueRecovery::inRegister):
2202         * dfg/DFGByteCodeParser.cpp:
2203         (JSC::DFG::ByteCodeParser::handleInlining):
2204         (JSC::DFG::ByteCodeParser::parseBlock):
2205         * dfg/DFGClobberize.h:
2206         (JSC::DFG::clobberize):
2207         * dfg/DFGNode.h:
2208         (JSC::DFG::Node::isFunctionTerminal):
2209         * dfg/DFGSpeculativeJIT64.cpp:
2210         (JSC::DFG::SpeculativeJIT::emitCall):
2211         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2212         (JSC::DFG::TierUpCheckInjectionPhase::run):
2213         * ftl/FTLCapabilities.cpp:
2214         (JSC::FTL::canCompile):
2215         * ftl/FTLCompile.cpp:
2216         (JSC::FTL::mmAllocateDataSection):
2217         * ftl/FTLInlineCacheSize.cpp:
2218         (JSC::FTL::sizeOfTailCallVarargs):
2219         (JSC::FTL::sizeOfTailCallForwardVarargs):
2220         (JSC::FTL::sizeOfICFor):
2221         * ftl/FTLInlineCacheSize.h:
2222         * ftl/FTLJSCall.cpp:
2223         (JSC::FTL::JSCall::JSCall):
2224         * ftl/FTLJSCallBase.cpp:
2225         (JSC::FTL::JSCallBase::emit):
2226         (JSC::FTL::JSCallBase::link):
2227         * ftl/FTLJSCallBase.h:
2228         * ftl/FTLJSCallVarargs.cpp:
2229         (JSC::FTL::JSCallVarargs::JSCallVarargs):
2230         (JSC::FTL::JSCallVarargs::emit):
2231         * ftl/FTLJSTailCall.cpp: Added.
2232         (JSC::FTL::getRegisterWithAddend):
2233         (JSC::FTL::recoveryFor):
2234         (JSC::FTL::sizeFor):
2235         (JSC::FTL::JSTailCall::JSTailCall):
2236         (JSC::FTL::m_instructionOffset):
2237         (JSC::FTL::JSTailCall::emit):
2238         * ftl/FTLJSTailCall.h: Copied from Source/JavaScriptCore/ftl/FTLJSCallBase.h.
2239         (JSC::FTL::JSTailCall::stackmapID):
2240         (JSC::FTL::JSTailCall::estimatedSize):
2241         (JSC::FTL::JSTailCall::numArguments):
2242         (JSC::FTL::JSTailCall::operator<):
2243         * ftl/FTLLocation.h:
2244         (JSC::FTL::Location::operator bool):
2245         (JSC::FTL::Location::operator!):
2246         * ftl/FTLLowerDFGToLLVM.cpp:
2247         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
2248         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2249         (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
2250         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
2251         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
2252         (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
2253         * ftl/FTLState.h:
2254         * jit/AssemblyHelpers.cpp:
2255         (JSC::AssemblyHelpers::emitExceptionCheck):
2256         * jit/CallFrameShuffleData.h:
2257         * jit/CallFrameShuffler.cpp:
2258         (JSC::CallFrameShuffler::CallFrameShuffler):
2259         (JSC::CallFrameShuffler::dump):
2260         (JSC::CallFrameShuffler::spill):
2261         (JSC::CallFrameShuffler::extendFrameIfNeeded):
2262         (JSC::CallFrameShuffler::prepareForSlowPath):
2263         (JSC::CallFrameShuffler::prepareAny):
2264         * jit/CallFrameShuffler.h:
2265         (JSC::CallFrameShuffler::restoreGPR):
2266         (JSC::CallFrameShuffler::getFreeRegister):
2267         (JSC::CallFrameShuffler::getFreeTempGPR):
2268         (JSC::CallFrameShuffler::ensureTempGPR):
2269         (JSC::CallFrameShuffler::addNew):
2270         * jit/CallFrameShuffler64.cpp:
2271         (JSC::CallFrameShuffler::emitBox):
2272         (JSC::CallFrameShuffler::tryAcquireTagTypeNumber):
2273         * jit/JITCall.cpp:
2274         (JSC::JIT::compileOpCall):
2275         * jit/Reg.h:
2276         (JSC::Reg::Reg):
2277         (JSC::Reg::isHashTableDeletedValue):
2278         (JSC::Reg::deleted):
2279         (JSC::RegHash::hash):
2280         (JSC::RegHash::equal):
2281         * test/es6.yaml:
2282
2283 2015-09-28  Keith Miller  <keith_miller@apple.com>
2284
2285         ObjectPropertyConditionSet::mergedWith does not produce a minimal intersection.
2286         https://bugs.webkit.org/show_bug.cgi?id=149598
2287
2288         Reviewed by Michael Saboff.
2289
2290         mergedWith sometimes creates duplicates of an ObjectPropertyCondition, which causes GetByIdVariant
2291         in believe that the condition has more than one slotBaseCondition when only one was necessary.
2292
2293         * bytecode/ObjectPropertyConditionSet.cpp:
2294         (JSC::ObjectPropertyConditionSet::mergedWith):
2295
2296 2015-09-26  Filip Pizlo  <fpizlo@apple.com>
2297
2298         Unreviewed, fix debug tests. Before marking, we need to call registerGCThreads().
2299
2300         * heap/Heap.cpp:
2301         (JSC::Heap::markRoots):
2302
2303 2015-09-24  Filip Pizlo  <fpizlo@apple.com>
2304
2305         VMs should share GC threads
2306         https://bugs.webkit.org/show_bug.cgi?id=149433
2307         rdar://problem/12859344
2308
2309         Reviewed by Geoffrey Garen.
2310
2311         This changes the GC to use a new WTF abstraction for parallelism called ParallelHelperPool.
2312         This allows us to remove GCThread and all of the GCPhase machinery. This kills a lot of
2313         code and also gives our GC magical thread sharing powers. If two GCs in two different VMs
2314         fire at the same time, then they will both get a random subset of the available shared GC
2315         threads. If one GC happens before the other, then it will probably get all of the available
2316         threads. If a GC happens while another VM already started GCing, then it will probably not
2317         get any helper threads. This is probably fine, since in multi-VM scenarios we have no
2318         reason to optimize for anything other than total throughput.
2319
2320         The GC has one static helper pool. This pool is available via JSC::heapHelperPool(). It
2321         would be OK for other parts of JSC to use it in the future for parallel tasks. Each Heap
2322         instance has a helper client attached to the pool.
2323
2324         The marking phase tells the ParallelHelperClient to asynchronously run a function that
2325         joins parallel marking and finishes once marking reaches termination. It uses the
2326         client.setFunction() idiom where the threads share work with each other using a specialized
2327         worklist. The ParallelHelperPool is not involved in deciding when threads should terminate.
2328
2329         The copying phase tells the ParallelHelperClient to run a copying function in parallel. It
2330         uses the client.runFunctionInParallel() idiom. The copying function gets work from the
2331         m_blocksToCopy worklist inside Heap.
2332
2333         To test that multiple VMs work properly, this adds a multi-VM test to testapi.mm. This test
2334         creates five concurrent VMs and has each of them allocate about 30MB of memory before doing
2335         a full GC. I've confirmed that this tests uses only 6 total GC threads on my 8-core
2336         computer (this is correct since we are currently configured for 7-way parallelism).
2337
2338         This shouldn't affect performance on benchmarks, but it will sure help apps with a lot of
2339         VM instances.
2340
2341         * CMakeLists.txt:
2342         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2343         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2344         * JavaScriptCore.xcodeproj/project.pbxproj:
2345         * assembler/AbstractMacroAssembler.h:
2346         * heap/GCThread.cpp: Removed.
2347         * heap/GCThread.h: Removed.
2348         * heap/Heap.cpp:
2349         (JSC::Heap::Heap):
2350         (JSC::Heap::~Heap):
2351         (JSC::Heap::isPagedOut):
2352         (JSC::Heap::markRoots):
2353         (JSC::Heap::copyBackingStores):
2354         (JSC::Heap::resetVisitors):
2355         (JSC::Heap::threadVisitCount):
2356         (JSC::Heap::threadBytesVisited):
2357         (JSC::Heap::threadBytesCopied):
2358         (JSC::Heap::startNextPhase): Deleted.
2359         (JSC::Heap::endCurrentPhase): Deleted.
2360         * heap/Heap.h:
2361         * heap/HeapHelperPool.cpp: Added.
2362         (JSC::heapHelperPool):
2363         * heap/HeapHelperPool.h: Added.
2364         * heap/MarkStack.cpp:
2365         (JSC::MarkStackArray::stealSomeCellsFrom):
2366         * heap/SlotVisitor.cpp:
2367         (JSC::SlotVisitor::didStartMarking):
2368         (JSC::SlotVisitor::reset):
2369         (JSC::SlotVisitor::drainFromShared):
2370         * jit/BinarySwitch.h:
2371         * runtime/CodeCache.h:
2372         * runtime/VM.h:
2373         * runtime/WeakRandom.h: Removed.
2374         * API/tests/testapi.mm:
2375
2376 2015-09-25  Saam barati  <sbarati@apple.com>
2377
2378         DFG should use PhantomLocal instead of Flush as liveness preservation mechanism in LiveCatchVariablesPreservationPhase
2379         https://bugs.webkit.org/show_bug.cgi?id=149575
2380
2381         Reviewed by Geoffrey Garen.
2382
2383         LiveCatchVariablesPreservationPhase is no longer forcing all live-at-catch 
2384         variables to be flushed to the stack. They are now kept alive to OSR exit 
2385         through PhantomLocal. This gives us a speed improvement for try-catch 
2386         programs (especially those that don't throw errors very often) because
2387         we can keep locals in registers instead of forcing them onto the stack.
2388
2389         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2390         (JSC::DFG::LiveCatchVariablePreservationPhase::LiveCatchVariablePreservationPhase):
2391         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
2392         (JSC::DFG::performLiveCatchVariablePreservationPhase):
2393         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase): Deleted.
2394         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock): Deleted.
2395
2396 2015-09-25  Michael Saboff  <msaboff@apple.com>
2397
2398         FTLOSRExitCompiler incorrectly excludes FPR registers in callee saves loop
2399         https://bugs.webkit.org/show_bug.cgi?id=149540
2400
2401         Reviewed by Saam Barati.
2402
2403         Eliminated the incorrect check that callee saves registers are only GPRs.
2404
2405         * ftl/FTLOSRExitCompiler.cpp:
2406         (JSC::FTL::compileStub):
2407
2408 2015-09-25  Alex Christensen  <achristensen@webkit.org>
2409
2410         [Win] Switch to CMake
2411         https://bugs.webkit.org/show_bug.cgi?id=148111
2412
2413         Reviewed by Brent Fulgham.
2414
2415         * JavaScriptCore.vcxproj/JavaScriptCore.proj:
2416
2417 2015-09-24  Mark Lam  <mark.lam@apple.com>
2418
2419         Remove the use of "Immediate" in JIT function names.
2420         https://bugs.webkit.org/show_bug.cgi?id=149542
2421
2422         Reviewed by Geoffrey Garen.
2423
2424         We will rename the following:
2425             isOperandConstantImmediateDouble => isOperandConstantDouble
2426             isOperandConstantImmediateInt => isOperandConstantInt
2427             isOperandConstantImmediateChar => isOperandConstantChar
2428
2429             getOperandConstantImmediateInt => getOperandConstantInt
2430             getConstantOperandImmediateInt => getOperandConstantInt
2431
2432             emitJumpIfImmediateInteger => emitJumpIfInt
2433             emitJumpIfNotImmediateInteger => emitJumpIfNotInt
2434             emitJumpIfNotImmediateIntegers => emitJumpIfNotInt
2435             emitPatchableJumpIfNotImmediateInteger => emitPatchableJumpIfNotInt
2436             emitJumpSlowCaseIfNotImmediateInteger => emitJumpSlowCaseIfNotInt
2437             emitJumpSlowCaseIfNotImmediateNumber => emitJumpSlowCaseIfNotNumber
2438             emitJumpSlowCaseIfNotImmediateIntegers => emitJumpSlowCaseIfNotInt
2439             emitFastArithReTagImmediate => emitTagInt
2440             emitTagAsBoolImmediate => emitTagBool
2441             emitJumpIfImmediateNumber => emitJumpIfNumber
2442             emitJumpIfNotImmediateNumber => emitJumpIfNotNumber
2443             emitFastArithImmToInt - Deleted because this is an empty function.
2444             emitFastArithIntToImmNoCheck => emitTagInt
2445             emitPutImmediateToCallFrameHeader => emitPutToCallFrameHeader
2446
2447         This is purely a refactoring patch to do the renaming.  There is no behavior
2448         change.
2449
2450         * dfg/DFGJITCompiler.cpp:
2451         (JSC::DFG::JITCompiler::compileEntry):
2452         (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
2453         * jit/AssemblyHelpers.h:
2454         (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
2455         (JSC::AssemblyHelpers::emitPutImmediateToCallFrameHeader): Deleted.
2456         * jit/JIT.cpp:
2457         (JSC::JIT::privateCompile):
2458         * jit/JIT.h:
2459         (JSC::JIT::emitStoreCell):
2460         (JSC::JIT::getSlowCase):
2461         * jit/JITArithmetic.cpp:
2462         (JSC::JIT::emit_op_negate):
2463         (JSC::JIT::emit_op_lshift):
2464         (JSC::JIT::emit_op_rshift):
2465         (JSC::JIT::emitSlow_op_rshift):
2466         (JSC::JIT::emit_op_urshift):
2467         (JSC::JIT::emitSlow_op_urshift):
2468         (JSC::JIT::emit_op_unsigned):
2469         (JSC::JIT::emit_compareAndJump):
2470         (JSC::JIT::emit_compareAndJumpSlow):
2471         (JSC::JIT::emit_op_bitand):
2472         (JSC::JIT::emit_op_inc):
2473         (JSC::JIT::emit_op_dec):
2474         (JSC::JIT::emit_op_mod):
2475         (JSC::JIT::compileBinaryArithOp):
2476         (JSC::JIT::compileBinaryArithOpSlowCase):
2477         (JSC::JIT::emit_op_add):
2478         (JSC::JIT::emitSlow_op_add):
2479         (JSC::JIT::emit_op_mul):
2480         (JSC::JIT::emitSlow_op_mul):
2481         (JSC::JIT::emit_op_div):
2482         (JSC::JIT::emitSlow_op_div):
2483         * jit/JITArithmetic32_64.cpp:
2484         (JSC::JIT::emit_compareAndJump):
2485         (JSC::JIT::emit_compareAndJumpSlow):
2486         (JSC::JIT::emit_op_lshift):
2487         (JSC::JIT::emitSlow_op_lshift):
2488         (JSC::JIT::emitRightShift):
2489         (JSC::JIT::emitRightShiftSlowCase):
2490         (JSC::JIT::emit_op_bitand):
2491         (JSC::JIT::emitSlow_op_bitand):
2492         (JSC::JIT::emit_op_bitor):
2493         (JSC::JIT::emitSlow_op_bitor):
2494         (JSC::JIT::emit_op_bitxor):
2495         (JSC::JIT::emitSlow_op_bitxor):
2496         (JSC::JIT::emit_op_add):
2497         (JSC::JIT::emitSlow_op_add):
2498         (JSC::JIT::emit_op_sub):
2499         (JSC::JIT::emitSlow_op_sub):
2500         * jit/JITInlines.h:
2501         (JSC::JIT::emitArrayStorageGetByVal):
2502         (JSC::JIT::isOperandConstantDouble):
2503         (JSC::JIT::isOperandConstantChar):
2504         (JSC::JIT::emitJumpSlowCaseIfNotJSCell):
2505         (JSC::JIT::isOperandConstantInt):
2506         (JSC::JIT::getOperandConstantInt):
2507         (JSC::JIT::emitGetVirtualRegisters):
2508         (JSC::JIT::emitLoadInt32ToDouble):
2509         (JSC::JIT::emitJumpIfInt):
2510         (JSC::JIT::emitJumpIfNotInt):
2511         (JSC::JIT::emitPatchableJumpIfNotInt):
2512         (JSC::JIT::emitJumpSlowCaseIfNotInt):
2513         (JSC::JIT::emitJumpSlowCaseIfNotNumber):
2514         (JSC::JIT::emitTagBool):
2515         (JSC::JIT::isOperandConstantImmediateDouble): Deleted.
2516         (JSC::JIT::isOperandConstantImmediateChar): Deleted.
2517         (JSC::JIT::isOperandConstantImmediateInt): Deleted.
2518         (JSC::JIT::getOperandConstantImmediateInt): Deleted.
2519         (JSC::JIT::getConstantOperandImmediateInt): Deleted.
2520         (JSC::JIT::emitJumpIfImmediateInteger): Deleted.
2521         (JSC::JIT::emitJumpIfNotImmediateInteger): Deleted.
2522         (JSC::JIT::emitPatchableJumpIfNotImmediateInteger): Deleted.
2523         (JSC::JIT::emitJumpIfNotImmediateIntegers): Deleted.
2524         (JSC::JIT::emitJumpSlowCaseIfNotImmediateInteger): Deleted.
2525         (JSC::JIT::emitJumpSlowCaseIfNotImmediateIntegers): Deleted.
2526         (JSC::JIT::emitJumpSlowCaseIfNotImmediateNumber): Deleted.
2527         (JSC::JIT::emitFastArithReTagImmediate): Deleted.
2528         (JSC::JIT::emitTagAsBoolImmediate): Deleted.
2529         * jit/JITOpcodes.cpp:
2530         (JSC::JIT::emit_op_is_undefined):
2531         (JSC::JIT::emit_op_is_boolean):
2532         (JSC::JIT::emit_op_is_number):
2533         (JSC::JIT::emit_op_is_string):
2534         (JSC::JIT::emit_op_is_object):
2535         (JSC::JIT::emit_op_jfalse):
2536         (JSC::JIT::emit_op_eq):
2537         (JSC::JIT::emit_op_jtrue):
2538         (JSC::JIT::emit_op_neq):
2539         (JSC::JIT::emit_op_bitxor):
2540         (JSC::JIT::emit_op_bitor):
2541         (JSC::JIT::compileOpStrictEq):
2542         (JSC::JIT::emit_op_to_number):
2543         (JSC::JIT::emit_op_eq_null):
2544         (JSC::JIT::emit_op_neq_null):
2545         (JSC::JIT::emitSlow_op_eq):
2546         (JSC::JIT::emitSlow_op_neq):
2547         (JSC::JIT::emit_op_profile_type):
2548         * jit/JITOpcodes32_64.cpp:
2549         (JSC::JIT::privateCompileCTINativeCall):
2550         * jit/JITPropertyAccess.cpp:
2551         (JSC::JIT::emit_op_get_by_val):
2552         (JSC::JIT::emit_op_put_by_val):
2553         (JSC::JIT::emitGenericContiguousPutByVal):
2554         (JSC::JIT::emit_op_put_by_id):
2555         (JSC::JIT::emitIntTypedArrayPutByVal):
2556         (JSC::JIT::emitFloatTypedArrayPutByVal):
2557         * jit/JSInterfaceJIT.h:
2558         (JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
2559         (JSC::JSInterfaceJIT::emitJumpIfNumber):
2560         (JSC::JSInterfaceJIT::emitJumpIfNotNumber):
2561         (JSC::JSInterfaceJIT::emitLoadDouble):
2562         (JSC::JSInterfaceJIT::emitTagInt):
2563         (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
2564         (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): Deleted.
2565         (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): Deleted.
2566         (JSC::JSInterfaceJIT::emitFastArithImmToInt): Deleted.
2567         (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck): Deleted.
2568         (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader): Deleted.
2569         * jit/ThunkGenerators.cpp:
2570         (JSC::nativeForGenerator):
2571         * wasm/WASMFunctionCompiler.h:
2572         (JSC::WASMFunctionCompiler::startFunction):
2573         (JSC::WASMFunctionCompiler::endFunction):
2574
2575 2015-09-24  Michael Saboff  <msaboff@apple.com>
2576
2577         [ES6] Implement tail calls in the DFG
2578         https://bugs.webkit.org/show_bug.cgi?id=148663
2579
2580         Reviewed by Filip Pizlo.
2581
2582         jsc-tailcall: Implement the tail call opcodes in the DFG
2583         https://bugs.webkit.org/show_bug.cgi?id=146850
2584
2585         This patch adds support for tail calls in the DFG. This requires a slightly high number of nodes:
2586
2587          - TailCall and TailCallVarargs are straightforward. They are terminal
2588            nodes and have the semantics of an actual tail call.
2589
2590          - TailCallInlinedCaller and TailCallVarargsInlinedCaller are here to perform a
2591            tail call inside an inlined function. They are non terminal nodes,
2592            and are performing the call as a regular call after popping an
2593            appropriate number of inlined tail call frames.
2594
2595          - TailCallForwardVarargs and TailCallForwardVarargsInlinedCaller are the
2596            extension of TailCallVarargs and TailCallVarargsInlinedCaller to enable
2597            the varargs forwarding optimization so that we don't lose
2598            performance with a tail call instead of a regular call.
2599
2600         This also required two broad kind of changes:
2601
2602          - Changes in the JIT itself (DFGSpeculativeJIT) are pretty
2603            straightforward since they are just an extension of the baseline JIT
2604            changes introduced previously.
2605
2606          - Changes in the runtime are mostly related with handling inline call
2607            frames. The idea here is that we have a special TailCall type for
2608            call frames that indicates to the various pieces of code walking the
2609            inline call frame that they should (recursively) skip the caller in
2610            their analysis.
2611
2612         * bytecode/CallMode.h:
2613         (JSC::specializationKindFor):
2614         * bytecode/CodeOrigin.cpp:
2615         (JSC::CodeOrigin::inlineDepthForCallFrame):
2616         (JSC::CodeOrigin::isApproximatelyEqualTo):
2617         (JSC::CodeOrigin::approximateHash):
2618         (JSC::CodeOrigin::inlineStack):
2619         * bytecode/CodeOrigin.h:
2620         * bytecode/InlineCallFrame.cpp:
2621         (JSC::InlineCallFrame::dumpInContext):
2622         (WTF::printInternal):
2623         * bytecode/InlineCallFrame.h:
2624         (JSC::InlineCallFrame::callModeFor):
2625         (JSC::InlineCallFrame::kindFor):
2626         (JSC::InlineCallFrame::varargsKindFor):
2627         (JSC::InlineCallFrame::specializationKindFor):
2628         (JSC::InlineCallFrame::isVarargs):
2629         (JSC::InlineCallFrame::isTail):
2630         (JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
2631         (JSC::InlineCallFrame::getCallerSkippingDeadFrames):
2632         (JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames):
2633         * dfg/DFGAbstractInterpreterInlines.h:
2634         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2635         * dfg/DFGArgumentsEliminationPhase.cpp:
2636         * dfg/DFGBasicBlock.h:
2637         (JSC::DFG::BasicBlock::findTerminal):
2638         * dfg/DFGByteCodeParser.cpp:
2639         (JSC::DFG::ByteCodeParser::inlineCallFrame):
2640         (JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
2641         (JSC::DFG::ByteCodeParser::currentCodeOrigin):
2642         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
2643         (JSC::DFG::ByteCodeParser::addCall):
2644         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2645         (JSC::DFG::ByteCodeParser::getPrediction):
2646         (JSC::DFG::ByteCodeParser::handleCall):
2647         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2648         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
2649         (JSC::DFG::ByteCodeParser::inliningCost):
2650         (JSC::DFG::ByteCodeParser::inlineCall):
2651         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2652         (JSC::DFG::ByteCodeParser::parseBlock):
2653         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2654         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2655         * dfg/DFGCapabilities.cpp:
2656         (JSC::DFG::capabilityLevel):
2657         * dfg/DFGClobberize.h:
2658         (JSC::DFG::clobberize):
2659         * dfg/DFGDoesGC.cpp:
2660         (JSC::DFG::doesGC):
2661         * dfg/DFGFixupPhase.cpp:
2662         (JSC::DFG::FixupPhase::fixupNode):
2663         * dfg/DFGGraph.cpp:
2664         (JSC::DFG::Graph::isLiveInBytecode):
2665         * dfg/DFGGraph.h:
2666         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2667         * dfg/DFGInPlaceAbstractState.cpp:
2668         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
2669         * dfg/DFGJITCompiler.cpp:
2670         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
2671         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2672         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
2673         * dfg/DFGNode.h:
2674         (JSC::DFG::Node::hasCallVarargsData):
2675         (JSC::DFG::Node::isTerminal):
2676         (JSC::DFG::Node::hasHeapPrediction):
2677         * dfg/DFGNodeType.h:
2678         * dfg/DFGOSRExitCompilerCommon.cpp:
2679         (JSC::DFG::handleExitCounts):
2680         (JSC::DFG::reifyInlinedCallFrames):
2681         (JSC::DFG::osrWriteBarrier):
2682         * dfg/DFGOSRExitPreparation.cpp:
2683         (JSC::DFG::prepareCodeOriginForOSRExit):
2684         * dfg/DFGOperations.cpp:
2685         * dfg/DFGPreciseLocalClobberize.h:
2686         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2687         * dfg/DFGPredictionPropagationPhase.cpp:
2688         (JSC::DFG::PredictionPropagationPhase::propagate):
2689         * dfg/DFGSafeToExecute.h:
2690         (JSC::DFG::safeToExecute):
2691         * dfg/DFGSpeculativeJIT32_64.cpp:
2692         (JSC::DFG::SpeculativeJIT::emitCall):
2693         (JSC::DFG::SpeculativeJIT::compile):
2694         * dfg/DFGSpeculativeJIT64.cpp:
2695         (JSC::DFG::SpeculativeJIT::emitCall):
2696         (JSC::DFG::SpeculativeJIT::compile):
2697         * dfg/DFGValidate.cpp:
2698         (JSC::DFG::Validate::validateSSA):
2699         * dfg/DFGVarargsForwardingPhase.cpp:
2700         * interpreter/CallFrame.cpp:
2701         (JSC::CallFrame::bytecodeOffset):
2702         * interpreter/StackVisitor.cpp:
2703         (JSC::StackVisitor::gotoNextFrame):
2704
2705 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
2706
2707         Remove special case code for the no-parallel-GC case
2708         https://bugs.webkit.org/show_bug.cgi?id=149512
2709
2710         Reviewed by Mark Lam.
2711
2712         Make serial GC just a parallel GC where the helper threads don't do anything. Also make the
2713         idle thread calculation a bit more explicit.
2714
2715         The main outcome is that we no longer use Options::numberOfGCMarkers() as much, so the code is
2716         resilient against the number of GC markers changing.
2717
2718         * heap/Heap.h:
2719         * heap/SlotVisitor.cpp:
2720         (JSC::SlotVisitor::donateKnownParallel):
2721         (JSC::SlotVisitor::drain):
2722         (JSC::SlotVisitor::drainFromShared):
2723
2724 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
2725
2726         PolymorphicAccess should remember that it checked an ObjectPropertyCondition with a check on some structure
2727         https://bugs.webkit.org/show_bug.cgi?id=149514
2728
2729         Reviewed by Oliver Hunt.
2730
2731         When we checked an ObjectPropertyCondition using an explicit structure check, we would forget to
2732         note the structure in any weak reference table and we would attempt to regenerate the condition
2733         check even if the condition became invalid.
2734
2735         We need to account for this better and we need to prune AccessCases that have an invalid condition
2736         set. This change does both.
2737
2738         * bytecode/PolymorphicAccess.cpp:
2739         (JSC::AccessGenerationState::addWatchpoint):
2740         (JSC::AccessCase::alternateBase):
2741         (JSC::AccessCase::couldStillSucceed):
2742         (JSC::AccessCase::canReplace):
2743         (JSC::AccessCase::generate):
2744         (JSC::PolymorphicAccess::regenerateWithCases):
2745         (JSC::PolymorphicAccess::visitWeak):
2746         (JSC::PolymorphicAccess::regenerate):
2747         * bytecode/PolymorphicAccess.h:
2748         (JSC::AccessCase::callLinkInfo):
2749         * tests/stress/make-dictionary-repatch.js: Added. This used to crash on a release assert. If we removed the release assert, this would return bad results.
2750
2751 2015-09-24  Mark Lam  <mark.lam@apple.com>
2752
2753         We should only expect a RareCaseProfile to exist if the rare case actually exists.
2754         https://bugs.webkit.org/show_bug.cgi?id=149531
2755
2756         Reviewed by Saam Barati.
2757
2758         The current code that calls rareCaseProfileForBytecodeOffset() assumes that it
2759         will always return a non-null RareCaseProfile.  As a result, op_add in the
2760         baseline JIT is forced to add a dummy slow case that will never be taken, only to
2761         ensure that the RareCaseProfile for that bytecode is created.  This profile will
2762         always produce a counter value of 0 (since that path will never be taken).
2763
2764         Instead, we'll make the callers of rareCaseProfileForBytecodeOffset() check if
2765         the profile actually exist before dereferencing it.
2766
2767         * bytecode/CodeBlock.cpp:
2768         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
2769         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
2770         (JSC::CodeBlock::capabilityLevel):
2771         * bytecode/CodeBlock.h:
2772         (JSC::CodeBlock::addRareCaseProfile):
2773         (JSC::CodeBlock::numberOfRareCaseProfiles):
2774         (JSC::CodeBlock::likelyToTakeSlowCase):
2775         (JSC::CodeBlock::couldTakeSlowCase):
2776         (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
2777         (JSC::CodeBlock::likelyToTakeAnySlowCase):
2778         (JSC::CodeBlock::rareCaseProfile): Deleted.
2779         * jit/JITArithmetic.cpp:
2780         (JSC::JIT::emit_op_add):
2781         (JSC::JIT::emitSlow_op_add):
2782         * jit/JITArithmetic32_64.cpp:
2783         (JSC::JIT::emit_op_add):
2784         (JSC::JIT::emitSlow_op_add):
2785
2786 2015-09-24  Ryosuke Niwa  <rniwa@webkit.org>
2787
2788         Ran sort-Xcode-project-file.
2789
2790         * JavaScriptCore.xcodeproj/project.pbxproj:
2791
2792 2015-09-24  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2793
2794         [Streams API] Add support for JS builtins constructor
2795         https://bugs.webkit.org/show_bug.cgi?id=149497
2796
2797         Reviewed by Darin Adler.
2798
2799         * runtime/JSFunction.h: exporting createBuiltinFunction.
2800
2801 2015-09-23  Saam barati  <sbarati@apple.com>
2802
2803         JSC allows invalid var declarations when the declared name is the same as a let/const variable
2804         https://bugs.webkit.org/show_bug.cgi?id=147600
2805
2806         Reviewed by Yusuke Suzuki.
2807
2808         We had an ordering bug where if you first declared a "let"
2809         variable then a "var" variable with the same name, you wouldn't
2810         get a syntax error. But, if you did it in the reverse order,
2811         you would. This patch fixes this syntax error to be order independent.
2812
2813         * parser/Parser.cpp:
2814         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2815         (JSC::Parser<LexerType>::createBindingPattern):
2816         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2817         * parser/Parser.h:
2818         (JSC::Scope::declareVariable):
2819
2820 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
2821
2822         Parallel copy phase synchronization should be simplified
2823         https://bugs.webkit.org/show_bug.cgi?id=149509
2824
2825         Reviewed by Mark Lam.
2826
2827         Before this change, we didn't wait for the copy phase to finish before starting to do things to
2828         copied space that presumed that copying was done. Copied space would "detect" that nobody was
2829         copying anymore by waiting for all loaned blocks to be returned. But that would succeed if some
2830         thread had not yet started copying. So, we had weird hacks to ensure that a block was loaned
2831         before any threads started. It also meant that we had two separate mechanisms for waiting for
2832         copying threads to finish - one mechanism in the Heap phase logic and another in the
2833         CopiedSpace::doneCopying() method.
2834
2835         We can get rid of a lot of the weirdness by just having a sound shutdown sequence:
2836
2837         1) Threads concur on when there is no more work. We already have this; once
2838            Heap::getNextBlocksToCopy() returns no work in any thread, it will also return no work in
2839            any other thread that asks for work.
2840         2) Main thread waits for the threads to not be copying anymore.
2841         3) Do whatever we need to do after copying finishes.
2842
2843         Currently, we do (3) before (2) and so we have weird problems. This just changes the code to do
2844         (3) after (2), and so we can get rid of the synchronization in doneCopying() and we can safely
2845         call startCopying() inside GCThread. This also means that we don't need to make CopyVisitor a
2846         property of GCThread. Instead, GCThread just instantiates its own CopyVisitor when it needs to.
2847
2848         * heap/CopiedSpace.cpp:
2849         (JSC::CopiedSpace::doneCopying):
2850         * heap/GCThread.cpp:
2851         (JSC::GCThread::GCThread):
2852         (JSC::GCThread::slotVisitor):
2853         (JSC::GCThread::waitForNextPhase):
2854         (JSC::GCThread::gcThreadMain):
2855         (JSC::GCThread::copyVisitor): Deleted.
2856         * heap/GCThread.h:
2857         * heap/Heap.cpp:
2858         (JSC::Heap::Heap):
2859         (JSC::Heap::copyBackingStores):
2860         (JSC::Heap::gatherStackRoots):
2861
2862 2015-09-23  Joseph Pecoraro  <pecoraro@apple.com>
2863
2864         Remove unimplemented method Heap::showStatistics
2865         https://bugs.webkit.org/show_bug.cgi?id=149507
2866
2867         Reviewed by Darin Adler.
2868
2869         * heap/Heap.h:
2870
2871 2015-09-23  Tim Horton  <timothy_horton@apple.com>
2872
2873         Hopefully fix the production build.
2874
2875         * JavaScriptCore.xcodeproj/project.pbxproj:
2876         * PlatformWin.cmake:
2877
2878 2015-09-23  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2879
2880         [Streams API] Implement ReadableStream pipeThrough
2881         https://bugs.webkit.org/show_bug.cgi?id=147556
2882
2883         Reviewed by Darin Adler.
2884
2885         Updating BuiltIns infrastructure to make it reusable from WebCore.
2886         Extracting macros from BuiltinNames and createBuiltinExecutable from BuiltinExecutables.
2887         Updated generate-js-builtins to allow generating builtin CPP/H files in WebCore namespace.
2888
2889         * JavaScriptCore.xcodeproj/project.pbxproj:
2890         * builtins/BuiltinExecutables.cpp:
2891         (JSC::BuiltinExecutables::createDefaultConstructor):
2892         (JSC::BuiltinExecutables::createBuiltinExecutable):
2893         (JSC::createBuiltinExecutable):
2894         (JSC::createExecutableInternal):
2895         * builtins/BuiltinExecutables.h:
2896         * builtins/BuiltinNames.h:
2897         (JSC::BuiltinNames::BuiltinNames): Deleted.
2898         * builtins/BuiltinUtils.h: Extracting code from BuiltinNames and BuiltinExecutables.h.
2899         * bytecode/UnlinkedFunctionExecutable.h:
2900         * generate-js-builtins:
2901         (getFunctions):
2902         (writeIncludeDirectives):
2903
2904 2015-09-22  Mark Lam  <mark.lam@apple.com>
2905
2906         Gardening: speculative non-JIT build fix after r189999.
2907
2908         Not reviewed.
2909
2910         * bytecode/ValueRecovery.h:
2911         (JSC::ValueRecovery::jsValueRegs):
2912
2913 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
2914
2915         GCThreadSharedData is just a bad way of saying Heap
2916         https://bugs.webkit.org/show_bug.cgi?id=149435
2917
2918         Reviewed by Mark Lam.
2919
2920         This removes the GCThreadSharedData class and moves its members into Heap. This is a net
2921         simplification since GCThreadSharedData had a 1-to-1 mapping to Heap and the two classes had a
2922         vast contract with a lot of interdependencies. Heap would call a lot of GCThreadSharedData
2923         methods; now a lot of those are inlined since they were only called from the one place in Heap.
2924         This makes it a lot easier to see what is going on. For example, you no longer have to look at
2925         code in two places (Heap and GCThreadSharedData) to figure out the timing and synchronization
2926         of GC phases - all of that code is in Heap now.
2927
2928         This also removes weird indirections in other places. It used to be that a lot of GC helper
2929         classes woud have a pointer to GCThreadSharedData, and then would use that to get to Heap, VM,
2930         and the visitors. Now these helpers just point to Heap.
2931
2932         I think that GCThreadSharedData was only useful for defining the set of things that we need to
2933         know to collect garbage. That's how we decided if something would go into GCThreadSharedData
2934         instead of Heap. But I think that separating things into multiple classes usually makes the
2935         code less hackable, so there should be a very high bar for doing this in a way that produces a
2936         1-to-1 mapping between two classes - where one instance of one of the classes is always paired
2937         with exactly one instance of the other class and vice-versa.
2938
2939         * CMakeLists.txt:
2940         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2941         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2942         * JavaScriptCore.xcodeproj/project.pbxproj:
2943         * heap/CopiedSpace.h:
2944         * heap/CopyVisitor.cpp:
2945         (JSC::CopyVisitor::CopyVisitor):
2946         (JSC::CopyVisitor::copyFromShared):
2947         * heap/CopyVisitor.h:
2948         * heap/CopyVisitorInlines.h:
2949         (JSC::CopyVisitor::allocateNewSpaceSlow):
2950         (JSC::CopyVisitor::startCopying):
2951         (JSC::CopyVisitor::doneCopying):
2952         (JSC::CopyVisitor::didCopy):
2953         * heap/GCThread.cpp:
2954         (JSC::GCThread::GCThread):
2955         (JSC::GCThread::waitForNextPhase):
2956         (JSC::GCThread::gcThreadMain):
2957         * heap/GCThread.h:
2958         * heap/GCThreadSharedData.cpp: Removed.
2959         * heap/GCThreadSharedData.h: Removed.
2960         * heap/Heap.cpp:
2961         (JSC::Heap::Heap):
2962         (JSC::Heap::~Heap):
2963         (JSC::Heap::isPagedOut):
2964         (JSC::Heap::markRoots):
2965         (JSC::Heap::copyBackingStores):
2966         (JSC::Heap::updateObjectCounts):
2967         (JSC::Heap::resetVisitors):
2968         (JSC::Heap::objectCount):
2969         (JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
2970         (JSC::Heap::threadVisitCount):
2971         (JSC::Heap::threadBytesVisited):
2972         (JSC::Heap::threadBytesCopied):
2973         (JSC::Heap::startNextPhase):
2974         (JSC::Heap::endCurrentPhase):
2975         * heap/Heap.h:
2976         * heap/HeapInlines.h:
2977         (JSC::Heap::unregisterWeakGCMap):
2978         (JSC::Heap::getNextBlocksToCopy):
2979         * heap/ListableHandler.h:
2980         * heap/SlotVisitor.cpp:
2981         (JSC::SlotVisitor::SlotVisitor):
2982         (JSC::SlotVisitor::didStartMarking):
2983         (JSC::SlotVisitor::reset):
2984         (JSC::SlotVisitor::donateKnownParallel):
2985         (JSC::SlotVisitor::drain):
2986         (JSC::SlotVisitor::drainFromShared):
2987         (JSC::SlotVisitor::mergeOpaqueRoots):
2988         (JSC::SlotVisitor::harvestWeakReferences):
2989         (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
2990         * heap/SlotVisitor.h:
2991         (JSC::SlotVisitor::markStack):
2992         (JSC::SlotVisitor::isEmpty):
2993         (JSC::SlotVisitor::sharedData): Deleted.
2994         * heap/SlotVisitorInlines.h:
2995         (JSC::SlotVisitor::addWeakReferenceHarvester):
2996         (JSC::SlotVisitor::addUnconditionalFinalizer):
2997         (JSC::SlotVisitor::addOpaqueRoot):
2998         (JSC::SlotVisitor::containsOpaqueRoot):
2999         (JSC::SlotVisitor::containsOpaqueRootTriState):
3000         (JSC::SlotVisitor::opaqueRootCount):
3001         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
3002         (JSC::SlotVisitor::copyLater):
3003         (JSC::SlotVisitor::heap):
3004         (JSC::SlotVisitor::vm):
3005
3006 2015-09-22  Saam barati  <sbarati@apple.com>
3007
3008         Web Inspector: [ES6] Improve Type Profiler Support for Arrow Functions
3009         https://bugs.webkit.org/show_bug.cgi?id=143171
3010
3011         Reviewed by Joseph Pecoraro.
3012
3013         We now need to take into account TypeProfilerSearchDescriptor when
3014         hashing results for type profiler queries. Before, we've gotten
3015         away with not doing this because before we would never have a text 
3016         collision between a return type text offset and a normal expression text
3017         offset. But, with arrow functions, we will have collisions when
3018         the arrow function doesn't have parens around its single parameter.
3019         I.e: "param => { ... };"
3020
3021         * runtime/TypeProfiler.cpp:
3022         (JSC::TypeProfiler::findLocation):
3023         * runtime/TypeProfiler.h:
3024         (JSC::QueryKey::QueryKey):
3025         (JSC::QueryKey::isHashTableDeletedValue):
3026         (JSC::QueryKey::operator==):
3027         (JSC::QueryKey::hash):
3028         * tests/typeProfiler/arrow-functions.js: Added.
3029
3030 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
3031
3032         Get rid of ENABLE(PARALLEL_GC)
3033         https://bugs.webkit.org/show_bug.cgi?id=149436
3034
3035         Reviewed by Mark Lam.
3036
3037         We always enable parallel GC everywhere but Windows, and it doesn't look like it was disabled
3038         there for any good reason. So, get rid of the flag.
3039
3040         The only effect of this change is that parallel GC will now be enabled on Windows, provided
3041         that the CPU detection finds more than one.
3042
3043         * heap/GCThread.cpp:
3044         (JSC::GCThread::gcThreadMain):
3045         * heap/GCThreadSharedData.cpp:
3046         (JSC::GCThreadSharedData::resetChildren):
3047         (JSC::GCThreadSharedData::childBytesCopied):
3048         (JSC::GCThreadSharedData::GCThreadSharedData):
3049         (JSC::GCThreadSharedData::~GCThreadSharedData):
3050         (JSC::GCThreadSharedData::reset):
3051         (JSC::GCThreadSharedData::didStartMarking):
3052         * heap/Heap.cpp:
3053         (JSC::Heap::converge):
3054         (JSC::Heap::visitWeakHandles):
3055         (JSC::Heap::updateObjectCounts):
3056         (JSC::Heap::resetVisitors):
3057         * heap/MarkedBlock.h:
3058         * heap/SlotVisitor.cpp:
3059         (JSC::SlotVisitor::didStartMarking):
3060         (JSC::SlotVisitor::reset):
3061         (JSC::SlotVisitor::drain):
3062         (JSC::SlotVisitor::drainFromShared):
3063         (JSC::SlotVisitor::mergeOpaqueRoots):
3064         (JSC::JSString::tryHashConsLock):
3065         (JSC::JSString::releaseHashConsLock):
3066         * heap/SlotVisitorInlines.h:
3067         (JSC::SlotVisitor::addOpaqueRoot):
3068         (JSC::SlotVisitor::containsOpaqueRoot):
3069         (JSC::SlotVisitor::containsOpaqueRootTriState):
3070         (JSC::SlotVisitor::opaqueRootCount):
3071         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
3072         * runtime/Options.cpp:
3073         (JSC::computeNumberOfGCMarkers):
3074
3075 2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3076
3077         Implement min and max instructions in WebAssembly
3078         https://bugs.webkit.org/show_bug.cgi?id=149454
3079
3080         Reviewed by Geoffrey Garen.
3081
3082         This patch implements min and max instructions in WebAssembly.
3083
3084         * tests/stress/wasm-arithmetic-float64.js:
3085         * tests/stress/wasm-arithmetic-int32.js:
3086         * tests/stress/wasm/arithmetic-float64.wasm:
3087         * tests/stress/wasm/arithmetic-int32.wasm:
3088         * wasm/WASMFunctionCompiler.h:
3089         (JSC::WASMFunctionCompiler::buildMinOrMaxI32):
3090         (JSC::WASMFunctionCompiler::buildMinOrMaxF64):
3091         * wasm/WASMFunctionParser.cpp:
3092         (JSC::WASMFunctionParser::parseExpressionI32):
3093         (JSC::WASMFunctionParser::parseMinOrMaxExpressionI32):
3094         (JSC::WASMFunctionParser::parseExpressionF64):
3095         (JSC::WASMFunctionParser::parseMinOrMaxExpressionF64):
3096         * wasm/WASMFunctionParser.h:
3097         * wasm/WASMFunctionSyntaxChecker.h:
3098         (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32):
3099         (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64):
3100
3101 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
3102
3103         Get rid of ENABLE(GGC)
3104         https://bugs.webkit.org/show_bug.cgi?id=149472
3105
3106         Reviewed by Mark Hahnenberg and Mark Lam.
3107
3108         Getting rid of this feature flag allows us to remove a lot of yuck.
3109
3110         * bytecode/CodeBlock.h:
3111         (JSC::CodeBlockSet::mark):
3112         (JSC::ScriptExecutable::forEachCodeBlock):
3113         * bytecode/PolymorphicAccess.cpp:
3114         (JSC::AccessCase::generate):
3115         * dfg/DFGOSRExitCompilerCommon.cpp:
3116         (JSC::DFG::reifyInlinedCallFrames):
3117         (JSC::DFG::osrWriteBarrier):
3118         (JSC::DFG::adjustAndJumpToTarget):
3119         * dfg/DFGSpeculativeJIT.cpp:
3120         (JSC::DFG::SpeculativeJIT::linkBranches):
3121         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
3122         (JSC::DFG::SpeculativeJIT::writeBarrier):
3123         * dfg/DFGSpeculativeJIT.h:
3124         (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
3125         (JSC::DFG::SpeculativeJIT::selectScratchGPR):
3126         * dfg/DFGSpeculativeJIT32_64.cpp:
3127         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
3128         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3129         (JSC::DFG::SpeculativeJIT::compile):
3130         (JSC::DFG::SpeculativeJIT::writeBarrier):
3131         (JSC::DFG::SpeculativeJIT::moveTrueTo):
3132         * dfg/DFGSpeculativeJIT64.cpp:
3133         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
3134         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3135         (JSC::DFG::SpeculativeJIT::compile):
3136         (JSC::DFG::SpeculativeJIT::writeBarrier):
3137         (JSC::DFG::SpeculativeJIT::moveTrueTo):
3138         * ftl/FTLLowerDFGToLLVM.cpp:
3139         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
3140         * heap/CodeBlockSet.cpp:
3141         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
3142         (JSC::CodeBlockSet::dump):
3143         * heap/Heap.cpp:
3144         (JSC::Heap::Heap):
3145         (JSC::Heap::markRoots):
3146         (JSC::Heap::clearRememberedSet):
3147         (JSC::Heap::updateObjectCounts):
3148         (JSC::Heap::flushWriteBarrierBuffer):
3149         (JSC::Heap::shouldDoFullCollection):
3150         (JSC::Heap::addLogicallyEmptyWeakBlock):
3151         * heap/HeapInlines.h:
3152         (JSC::Heap::isWriteBarrierEnabled):
3153         (JSC::Heap::writeBarrier):
3154         (JSC::Heap::reportExtraMemoryAllocated):
3155         (JSC::Heap::reportExtraMemoryVisited):
3156         * heap/MarkedBlock.cpp:
3157         (JSC::MarkedBlock::clearMarks):
3158         * heap/MarkedSpace.cpp:
3159         (JSC::MarkedSpace::resetAllocators):
3160         (JSC::MarkedSpace::visitWeakSets):
3161         * heap/MarkedSpace.h:
3162         (JSC::MarkedSpace::didAllocateInBlock):
3163         (JSC::MarkedSpace::objectCount):
3164         * jit/JITPropertyAccess.cpp:
3165         (JSC::JIT::emitWriteBarrier):
3166         (JSC::JIT::emitIdentifierCheck):
3167         (JSC::JIT::privateCompilePutByVal):
3168         * llint/LLIntOfflineAsmConfig.h:
3169         * llint/LowLevelInterpreter32_64.asm:
3170         * llint/LowLevelInterpreter64.asm:
3171
3172 2015-09-22  Saam barati  <sbarati@apple.com>
3173
3174         the toInt32 operation inside DFGSpeculativeJIT.cpp can't throw so we shouldn't emit an exceptionCheck after it.
3175         https://bugs.webkit.org/show_bug.cgi?id=149467
3176
3177         Reviewed by Mark Lam.
3178
3179         The callOperation for toInt32 won't store a call site index in the call frame.
3180         Therefore, if this is the first callOperation in the current compilation, 
3181         and we emit an exception check inside a try block, we will hit an assertion 
3182         saying that we must have DFGCommonData::codeOrigins.size() be > 0 inside
3183         DFGCommonData::lastCallSite(). Therefore, it is imperative that we don't 
3184         emit exception checks for callOperations that don't throw exceptions and 
3185         don't store a call site index in the call frame.
3186
3187         * dfg/DFGCommonData.cpp:
3188         (JSC::DFG::CommonData::lastCallSite):
3189         * dfg/DFGSpeculativeJIT.cpp:
3190         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3191         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
3192
3193 2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3194
3195         Implement the conditional instruction in WebAssembly
3196         https://bugs.webkit.org/show_bug.cgi?id=149451
3197
3198         Reviewed by Geoffrey Garen.
3199
3200         This patch implements the conditional (ternary) instruction in WebAssembly.
3201         This is basically "condition ? exp1 : exp2" in JavaScript.
3202         
3203         The use of context.discard() in WASMFunctionParser::parseConditional()
3204         is not ideal. We don't discard anything. We just use it to decrement the
3205         stack top in the WebAssembly baseline JIT. When we optimize the JIT by
3206         storing results directly into the destination like the JavaScript
3207         baseline JIT, the code will look like this:
3208
3209             ContextExpression temp = context.newTemporary();
3210             ContextExpression condition = parseExpressionI32(context);
3211             context.jumpToTargetIf(Context::JumpCondition::Zero, condition, elseTarget);
3212
3213             parseExpression(context, temp, expressionType);
3214             context.jumpToTarget(end);
3215
3216             context.linkTarget(elseTarget);
3217             parseExpression(context, temp, expressionType);
3218             context.linkTarget(end);
3219
3220             return temp;
3221
3222         which looks cleaner than using discard().
3223
3224         * tests/stress/wasm-control-flow.js:
3225         * tests/stress/wasm/control-flow.wasm:
3226         * wasm/WASMFunctionParser.cpp:
3227         (JSC::WASMFunctionParser::parseExpressionI32):
3228         (JSC::WASMFunctionParser::parseExpressionF32):
3229         (JSC::WASMFunctionParser::parseExpressionF64):
3230         (JSC::WASMFunctionParser::parseConditional):
3231         * wasm/WASMFunctionParser.h:
3232
3233 2015-09-22  Commit Queue  <commit-queue@webkit.org>
3234
3235         Unreviewed, rolling out r189616.
3236         https://bugs.webkit.org/show_bug.cgi?id=149456
3237
3238         suspected cause of multiple regressions (Requested by kling on
3239         #webkit).
3240
3241         Reverted changeset:
3242
3243         "[JSC] Weak should only accept cell pointees."
3244         https://bugs.webkit.org/show_bug.cgi?id=148955
3245         http://trac.webkit.org/changeset/189616
3246
3247 2015-09-22  Saam barati  <sbarati@apple.com>
3248
3249         Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
3250         https://bugs.webkit.org/show_bug.cgi?id=149248
3251
3252         Reviewed by Mark Lam.
3253
3254         We keep track of which functions have and have not
3255         executed so we can show visually, inside the inspector,
3256         which functions have and have not executed. With a default
3257         constructor, our parser parses code that isn't in the actual
3258         JavaScript source code of the user. Our parser would then
3259         give us a range of starting at "1" to "1 + default constructor length"
3260         as being the text range of a function. But, this would then pollute
3261         actual source code that was at these ranges.
3262
3263         Therefore, we should treat these default constructor source 
3264         codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
3265         as the invalid range. This range has the effect of not polluting 
3266         valid ranges inside the source code.
3267
3268         * bytecode/UnlinkedFunctionExecutable.cpp:
3269         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3270         (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
3271         * bytecode/UnlinkedFunctionExecutable.h:
3272         * bytecompiler/BytecodeGenerator.cpp:
3273         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
3274
3275 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3276
3277         Implement the comma instruction in WebAssembly
3278         https://bugs.webkit.org/show_bug.cgi?id=149425
3279
3280         Reviewed by Geoffrey Garen.
3281
3282         This patch implements the comma instruction in WebAssembly. The comma
3283         instruction evaluates the left operand and then the right operand and
3284         returns the value of the right operand.
3285
3286         * tests/stress/wasm-comma.js: Added.
3287         (shouldBe):
3288         * wasm/WASMFunctionCompiler.h:
3289         (JSC::WASMFunctionCompiler::discard):
3290         * wasm/WASMFunctionParser.cpp:
3291         (JSC::WASMFunctionParser::parseExpressionI32):
3292         (JSC::WASMFunctionParser::parseExpressionF32):
3293         (JSC::WASMFunctionParser::parseExpressionF64):
3294         (JSC::WASMFunctionParser::parseComma):
3295         * wasm/WASMFunctionParser.h:
3296         * wasm/WASMFunctionSyntaxChecker.h:
3297         (JSC::WASMFunctionSyntaxChecker::discard):
3298
3299 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
3300
3301         Always use the compiler's CAS implementation and get rid of ENABLE(COMPARE_AND_SWAP)
3302         https://bugs.webkit.org/show_bug.cgi?id=149438
3303
3304         Reviewed by Mark Lam.
3305
3306         * heap/HeapInlines.h:
3307         (JSC::Heap::reportExtraMemoryVisited):
3308         (JSC::Heap::deprecatedReportExtraMemory):
3309
3310 2015-09-21  Saam barati  <sbarati@apple.com>
3311
3312         functionProtoFuncToString should not rely on typeProfilingEndOffset()
3313         https://bugs.webkit.org/show_bug.cgi?id=149429
3314
3315         Reviewed by Geoffrey Garen.
3316
3317         We should be able to freely change typeProfilingEndOffset()
3318         without worrying we will break Function.prototype.toString.
3319
3320         * runtime/FunctionPrototype.cpp:
3321         (JSC::functionProtoFuncToString):
3322
3323 2015-09-21  Commit Queue  <commit-queue@webkit.org>
3324
3325         Unreviewed, rolling out r190086.
3326         https://bugs.webkit.org/show_bug.cgi?id=149427
3327
3328         Broke LayoutTests/inspector/model/remote-object.htm (Requested
3329         by saamyjoon on #webkit).
3330
3331         Reverted changeset:
3332
3333         "Web Inspector: Basic Block Annotations and Type Profiler
3334