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