Unreviewed, fix cloop build.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
2
3         Unreviewed, fix cloop build.
4
5         * runtime/VM.h:
6
7 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
8
9         Make MarkedBlock state tracking support overlapped allocation and marking state
10         https://bugs.webkit.org/show_bug.cgi?id=161581
11
12         Reviewed by Geoffrey Garen.
13         
14         Concurrent GCs must allow for mutation and allocation during collection. We already know
15         how to mutate during collection. We have a write barrier for that. Allocation during
16         collection is more involved: the collector modifies the the mark bits, as well as other
17         kinds of MarkedBlock state, in-place during a collection. The allocator uses that same
18         MarkedBlock state to decide which regions of memory are free. This works if the allocator
19         never runs while the collector is running, but if we want to allow them to run at the same
20         time, then we need to have two versions of the state: one version built up by the
21         collector and another consumed by the allocator. We clear the collector state at the
22         beginning of collection, and splat the collector state onto the allocator state after
23         collection.
24         
25         This could be super expensive, but we can make it cheap with some cleverness. The biggest
26         observation is just that most of the state is a handful of bits per block: is the block
27         free-listed? is it completely full? completely empty? in the incremental sweeper's
28         snapshot? is it retired? is it in eden? There is also state inside blocks, like the mark
29         bits, but I have a solid plan there and I'll save it for another patch. Once we view the
30         state of blocks as bits, we can put that state into bitvectors, so that if the collector
31         needs to transform the state of some blocks, it can do it with a single operation over
32         bitvectors. I like to think of this as 32-way parallelizing block operations, since
33         doing one operation on a 32-bit word in one of those bitvectors instantly affects 32
34         blocks.
35         
36         This change converts all previous collections of MarkedBlocks, along with the MarkedBlock
37         state, into 8 bitvectors (live, empty, allocated, canAllocateButNotEmpty, eden, unswept,
38         markingNotEmpty, and markingRetired). The bitvectors separate allocator state (empty,
39         allocated, canAllocateButNotEmpty) from marking state (markingNotEmpty, markingRetired).
40         
41         As a nice side-effect of switching to bitvectors, we get size class rebalancing for free.
42         It used to be that if a MarkedAllocator had an empty block, we would only allow that
43         memory to be reused by a different MarkedAllocator if we did an incremental sweep or a
44         full eager sweep. Now we hunt down all destructorless empty blocks before allocating new
45         MarkedBlocks. It would be relatively easy to also hunt down destructor empty blocks, but
46         the theory is that those might be expensive to sweep, so it might still be better to leave
47         those to the incremental sweeper.
48         
49         This change is perf-neutral all around. I did some tests with two different kinds of
50         allocation strategies - something that is somewhat easier to do now that you can look for
51         blocks that are candidates for allocation by just scanning some bitvectors. I tried two
52         variants:
53         
54         - Allocate out of non-empty blocks first, leaving empty blocks for last in case a
55           different allocator needed them. This is sort of a best-fit strategy. I tried this
56           first, and it can be expressed as:
57           
58           m_allocationCursor = m_canAllocateButNotEmpty.findBit(m_allocationCursor, true)
59         
60         - Allocate out of lower-indexed blocks first, treating empty and canAllocateButNotEmpty
61           blocks equally. This is sort of a first-fit strategy. This is what I ended up settling
62           on, and it can be expressed as:
63           
64           m_allocationCursor = (m_canAllocateButNotEmpty | m_empty).findBit(m_allocationCursor, true)
65         
66         The best-fit strategy meant 1% regressions in LongSpider and Octane overall, and a 11%
67         regression on Octane/earley. First-fit means perf-neutrality. Most great allocators skew
68         towards first-fit because it's empirically better, so this result is not surprising.
69         
70         Overall, the performance of this patch on my machine is as follows, where "neutral" means
71         less than 1% and not statistically significant.
72         
73         run-jsc-benchmarks:
74             SunSpider: neutral
75             LongSpider: 0.6% slower
76             V8Spider: neutral
77             Octane: neutral
78             Kraken: neutral
79             Microbenchmarks: 0.37% slower
80             AsmBench: neutral
81             CompressionBench: maybe 1% faster
82         
83         For browser benchmarks, I report the ratio of means (bigger / smaller) along with a T-test
84         from Mathematica reported as % chance of not [sic] the null hypothesis. Note that we
85         normally consider anything less than 95% confidence to be inconclusive.
86         
87         Browser benchmarks:
88             PLT3: 0.3% faster with 67% confidence
89             membuster:
90                 Snap2FinishedLoadingPost: 0.68% more memory with 50% confidence
91                 Snap3EndPost: 2.4% more memory with 61% confidence
92             JetStream: 0.2% slower with 32% confidence
93             Speedometer: 0.7% faster with 82% confidence
94         
95         Additionally, Octane/splay's heap capacity goes down to ~180KB from ~200KB, so about a 10%
96         progression. This is due to the allocator rebalancing feature.
97         
98         Finally, this breaks --useImmortalObjects. It was already broken as far as I can tell. I
99         filed a bug to reimplement it (bug 162296). Unless someone urgently needs this internal
100         tool, it's probably best to reimplement it after I'm done refactoring MarkedSpace. 
101
102         * JavaScriptCore.xcodeproj/project.pbxproj:
103         * debugger/Debugger.cpp:
104         * heap/CellContainer.h:
105         * heap/CellContainerInlines.h:
106         (JSC::CellContainer::vm):
107         (JSC::CellContainer::heap):
108         (JSC::CellContainer::isMarkedOrNewlyAllocated):
109         (JSC::CellContainer::aboutToMark):
110         (JSC::CellContainer::isMarked): Deleted.
111         (JSC::CellContainer::flipIfNecessary): Deleted.
112         * heap/ConservativeRoots.cpp:
113         * heap/Heap.cpp:
114         (JSC::Heap::beginMarking):
115         (JSC::Heap::endMarking):
116         (JSC::Heap::collectAllGarbage):
117         (JSC::Heap::collectImpl):
118         (JSC::Heap::snapshotMarkedSpace):
119         (JSC::Heap::prepareForAllocation):
120         (JSC::Heap::zombifyDeadObjects):
121         (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor): Deleted.
122         (JSC::MarkedBlockSnapshotFunctor::operator()): Deleted.
123         (JSC::Heap::resetAllocators): Deleted.
124         * heap/Heap.h:
125         * heap/HeapInlines.h:
126         (JSC::Heap::isMarked):
127         (JSC::Heap::isMarkedConcurrently):
128         (JSC::Heap::testAndSetMarked):
129         * heap/HeapStatistics.cpp:
130         * heap/HeapUtil.h:
131         (JSC::HeapUtil::findGCObjectPointersForMarking):
132         (JSC::HeapUtil::isPointerGCObjectJSCell):
133         * heap/HeapVerifier.cpp:
134         * heap/IncrementalSweeper.cpp:
135         (JSC::IncrementalSweeper::IncrementalSweeper):
136         (JSC::IncrementalSweeper::doSweep):
137         (JSC::IncrementalSweeper::sweepNextBlock):
138         (JSC::IncrementalSweeper::startSweeping):
139         (JSC::IncrementalSweeper::willFinishSweeping):
140         * heap/IncrementalSweeper.h:
141         * heap/LargeAllocation.h:
142         (JSC::LargeAllocation::isMarked):
143         (JSC::LargeAllocation::isMarkedConcurrently):
144         (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
145         (JSC::LargeAllocation::aboutToMark):
146         (JSC::LargeAllocation::isMarkedDuringWeakVisiting): Deleted.
147         (JSC::LargeAllocation::flipIfNecessary): Deleted.
148         (JSC::LargeAllocation::flipIfNecessaryDuringMarking): Deleted.
149         * heap/MarkedAllocator.cpp:
150         (JSC::MarkedAllocator::MarkedAllocator):
151         (JSC::MarkedAllocator::isPagedOut):
152         (JSC::MarkedAllocator::findEmptyBlock):
153         (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
154         (JSC::MarkedAllocator::allocateIn):
155         (JSC::MarkedAllocator::tryAllocateIn):
156         (JSC::MarkedAllocator::allocateSlowCaseImpl):
157         (JSC::MarkedAllocator::tryAllocateBlock):
158         (JSC::MarkedAllocator::addBlock):
159         (JSC::MarkedAllocator::removeBlock):
160         (JSC::MarkedAllocator::stopAllocating):
161         (JSC::MarkedAllocator::prepareForAllocation):
162         (JSC::MarkedAllocator::lastChanceToFinalize):
163         (JSC::MarkedAllocator::resumeAllocating):
164         (JSC::MarkedAllocator::beginMarkingForFullCollection):
165         (JSC::MarkedAllocator::endMarking):
166         (JSC::MarkedAllocator::snapshotForEdenCollection):
167         (JSC::MarkedAllocator::snapshotForFullCollection):
168         (JSC::MarkedAllocator::findBlockToSweep):
169         (JSC::MarkedAllocator::sweep):
170         (JSC::MarkedAllocator::shrink):
171         (JSC::MarkedAllocator::assertSnapshotEmpty):
172         (JSC::MarkedAllocator::dump):
173         (JSC::MarkedAllocator::dumpBits):
174         (JSC::MarkedAllocator::retire): Deleted.
175         (JSC::MarkedAllocator::filterNextBlock): Deleted.
176         (JSC::MarkedAllocator::setNextBlockToSweep): Deleted.
177         (JSC::MarkedAllocator::reset): Deleted.
178         * heap/MarkedAllocator.h:
179         (JSC::MarkedAllocator::forEachBitVector):
180         (JSC::MarkedAllocator::forEachBitVectorWithName):
181         (JSC::MarkedAllocator::nextAllocator):
182         (JSC::MarkedAllocator::setNextAllocator):
183         (JSC::MarkedAllocator::forEachBlock):
184         (JSC::MarkedAllocator::resumeAllocating): Deleted.
185         * heap/MarkedBlock.cpp:
186         (JSC::MarkedBlock::tryCreate):
187         (JSC::MarkedBlock::Handle::Handle):
188         (JSC::MarkedBlock::Handle::~Handle):
189         (JSC::MarkedBlock::MarkedBlock):
190         (JSC::MarkedBlock::Handle::specializedSweep):
191         (JSC::MarkedBlock::Handle::sweep):
192         (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
193         (JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode):
194         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
195         (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
196         (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode):
197         (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
198         (JSC::MarkedBlock::Handle::setIsFreeListed):
199         (JSC::MarkedBlock::Handle::stopAllocating):
200         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
201         (JSC::MarkedBlock::Handle::resumeAllocating):
202         (JSC::MarkedBlock::aboutToMarkSlow):
203         (JSC::MarkedBlock::clearMarks):
204         (JSC::MarkedBlock::isMarked):
205         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
206         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
207         (JSC::MarkedBlock::Handle::didConsumeFreeList):
208         (JSC::MarkedBlock::markCount):
209         (JSC::MarkedBlock::Handle::isEmpty):
210         (JSC::MarkedBlock::noteMarkedSlow):
211         (JSC::MarkedBlock::Handle::removeFromAllocator):
212         (JSC::MarkedBlock::Handle::didAddToAllocator):
213         (JSC::MarkedBlock::Handle::didRemoveFromAllocator):
214         (JSC::MarkedBlock::Handle::isLive):
215         (JSC::MarkedBlock::Handle::isLiveCell):
216         (JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode): Deleted.
217         (JSC::MarkedBlock::flipIfNecessary): Deleted.
218         (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
219         (JSC::MarkedBlock::flipIfNecessarySlow): Deleted.
220         (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow): Deleted.
221         (JSC::MarkedBlock::Handle::willRemoveBlock): Deleted.
222         (WTF::printInternal): Deleted.
223         * heap/MarkedBlock.h:
224         (JSC::MarkedBlock::Handle::isFreeListed):
225         (JSC::MarkedBlock::Handle::index):
226         (JSC::MarkedBlock::aboutToMark):
227         (JSC::MarkedBlock::isMarked):
228         (JSC::MarkedBlock::isMarkedConcurrently):
229         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
230         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
231         (JSC::MarkedBlock::Handle::isOnBlocksToSweep): Deleted.
232         (JSC::MarkedBlock::Handle::setIsOnBlocksToSweep): Deleted.
233         (JSC::MarkedBlock::Handle::state): Deleted.
234         (JSC::MarkedBlock::flipIfNecessary): Deleted.
235         (JSC::MarkedBlock::flipIfNecessaryDuringMarking): Deleted.
236         (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
237         (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking): Deleted.
238         (JSC::MarkedBlock::Handle::flipForEdenCollection): Deleted.
239         (JSC::MarkedBlock::isMarkedDuringWeakVisiting): Deleted.
240         (JSC::MarkedBlock::Handle::isLive): Deleted.
241         (JSC::MarkedBlock::Handle::isLiveCell): Deleted.
242         (JSC::MarkedBlock::Handle::forEachLiveCell): Deleted.
243         (JSC::MarkedBlock::Handle::forEachDeadCell): Deleted.
244         (JSC::MarkedBlock::Handle::needsSweeping): Deleted.
245         (JSC::MarkedBlock::Handle::isAllocated): Deleted.
246         (JSC::MarkedBlock::Handle::isMarked): Deleted.
247         * heap/MarkedBlockInlines.h: Added.
248         (JSC::MarkedBlock::Handle::isLive):
249         (JSC::MarkedBlock::Handle::isLiveCell):
250         (JSC::MarkedBlock::Handle::forEachLiveCell):
251         (JSC::MarkedBlock::Handle::forEachDeadCell):
252         (JSC::MarkedBlock::resetVersion):
253         * heap/MarkedSpace.cpp:
254         (JSC::MarkedSpace::MarkedSpace):
255         (JSC::MarkedSpace::allocate):
256         (JSC::MarkedSpace::tryAllocate):
257         (JSC::MarkedSpace::sweep):
258         (JSC::MarkedSpace::prepareForAllocation):
259         (JSC::MarkedSpace::shrink):
260         (JSC::MarkedSpace::clearNewlyAllocated):
261         (JSC::MarkedSpace::beginMarking):
262         (JSC::MarkedSpace::endMarking):
263         (JSC::MarkedSpace::didAllocateInBlock):
264         (JSC::MarkedSpace::findEmptyBlock):
265         (JSC::MarkedSpace::snapshot):
266         (JSC::MarkedSpace::assertSnapshotEmpty):
267         (JSC::MarkedSpace::dumpBits):
268         (JSC::MarkedSpace::zombifySweep): Deleted.
269         (JSC::MarkedSpace::resetAllocators): Deleted.
270         (JSC::VerifyMarked::operator()): Deleted.
271         (JSC::MarkedSpace::flip): Deleted.
272         * heap/MarkedSpace.h:
273         (JSC::MarkedSpace::nextVersion):
274         (JSC::MarkedSpace::firstAllocator):
275         (JSC::MarkedSpace::allocatorForEmptyAllocation):
276         (JSC::MarkedSpace::forEachAllocator):
277         (JSC::MarkedSpace::blocksWithNewObjects): Deleted.
278         (JSC::MarkedSpace::setIsMarking): Deleted.
279         (JSC::MarkedSpace::forEachLiveCell): Deleted.
280         (JSC::MarkedSpace::forEachDeadCell): Deleted.
281         * heap/MarkedSpaceInlines.h: Added.
282         (JSC::MarkedSpace::forEachLiveCell):
283         (JSC::MarkedSpace::forEachDeadCell):
284         * heap/SlotVisitor.cpp:
285         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
286         (JSC::SlotVisitor::markAuxiliary):
287         (JSC::SlotVisitor::visitChildren):
288         * heap/Weak.h:
289         (WTF::HashTraits<JSC::Weak<T>>::emptyValue):
290         (WTF::HashTraits<JSC::Weak<T>>::peek):
291         * heap/WeakBlock.cpp:
292         (JSC::WeakBlock::specializedVisit):
293         (JSC::WeakBlock::reap):
294         * heap/WeakInlines.h:
295         (WTF::HashTraits<JSC::Weak<T>>::emptyValue): Deleted.
296         (WTF::HashTraits<JSC::Weak<T>>::peek): Deleted.
297         * jit/JITThunks.h:
298         * runtime/JSGlobalObject.cpp:
299         * runtime/PrototypeMap.h:
300         * runtime/SamplingProfiler.cpp:
301         * runtime/WeakGCMap.h:
302         * tools/JSDollarVMPrototype.cpp:
303
304 2016-09-20  Jonathan Bedard  <jbedard@apple.com>
305
306         Undefined behavior: Left shift negative number
307         https://bugs.webkit.org/show_bug.cgi?id=161866
308
309         Reviewed by Keith Miller.
310
311         Left shifting a negative number is undefined behavior in C/C++, although most implementations do define it. Explicitly clarifying the intended behavior due to shifting negative number in some cases.
312
313         * dfg/DFGAbstractHeap.h:
314         (JSC::DFG::AbstractHeap::encode): Explicitly cast signed integer for left shift.
315
316 2016-09-20  Saam Barati  <sbarati@apple.com>
317
318         Unreviewed fix for 32-bit DFG x86 implementation of HasOwnProperty.
319
320         Fixup phase is always setting ObjectUse on child1() of HasOwnProperty.
321         However, on x86 32-bit, I omitted a call to speculateObject() on child1().
322
323         * dfg/DFGSpeculativeJIT32_64.cpp:
324         (JSC::DFG::SpeculativeJIT::compile):
325
326 2016-09-20  Yusuke Suzuki  <utatane.tea@gmail.com>
327
328         [JSC] Add `typeof value === "symbol"` handling to bytecode compiler
329         https://bugs.webkit.org/show_bug.cgi?id=162253
330
331         Reviewed by Sam Weinig.
332
333         Add `typeof value === "symbol"` handling to the bytecode compiler.
334         The effect is tiny, but it keeps consistency since the bytecode compiler
335         already has the similar optimization for "string" case.
336
337         * bytecode/SpeculatedType.cpp:
338         (JSC::speculationFromJSType):
339         * bytecompiler/BytecodeGenerator.cpp:
340         (JSC::BytecodeGenerator::emitEqualityOp):
341
342 2016-09-19  Saam Barati  <sbarati@apple.com>
343
344         Make HasOwnProperty faster
345         https://bugs.webkit.org/show_bug.cgi?id=161708
346
347         Reviewed by Geoffrey Garen.
348
349         This patch adds a cache for HasOwnProperty. The cache holds tuples
350         of {StructureID, UniquedStringImpl*, boolean} where the boolean indicates
351         the result of performing hasOwnProperty on an object with StructureID and
352         UniquedStringImpl*. If the cache contains an item, we can be guaranteed
353         that it contains the same result as performing hasOwnProperty on an
354         object O with a given structure and key. To guarantee this, we only add
355         items into the cache when the Structure of the given item is cacheable.
356
357         The caching strategy is simple: when adding new items into the cache,
358         we will evict any item that was in the location that the new item
359         is hashed into. We also clear the cache on every GC. This strategy
360         proves to be successful on speedometer, which sees a cache hit rate
361         over 90%. This caching strategy is now inlined into the DFG/FTL JITs
362         by now recognizing hasOwnProperty as an intrinsic with the corresponding
363         HasOwnProperty node. The goal of the node is to emit inlined code for
364         the cache lookup to prevent the overhead of the call for the common
365         case where we get a cache hit.
366
367         I'm seeing around a 1% to 1.5% percent improvement on Speedometer on
368         my machine. Hopefully the perf bots agree with my machine.
369
370         This patch also speeds up the microbenchmark I added by 2.5x.
371
372         * JavaScriptCore.xcodeproj/project.pbxproj:
373         * dfg/DFGAbstractInterpreterInlines.h:
374         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
375         * dfg/DFGByteCodeParser.cpp:
376         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
377         * dfg/DFGClobberize.h:
378         (JSC::DFG::clobberize):
379         * dfg/DFGDoesGC.cpp:
380         (JSC::DFG::doesGC):
381         * dfg/DFGFixupPhase.cpp:
382         (JSC::DFG::FixupPhase::fixupNode):
383         * dfg/DFGNodeType.h:
384         * dfg/DFGOperations.cpp:
385         * dfg/DFGOperations.h:
386         * dfg/DFGPredictionPropagationPhase.cpp:
387         * dfg/DFGSafeToExecute.h:
388         (JSC::DFG::safeToExecute):
389         * dfg/DFGSpeculativeJIT.h:
390         (JSC::DFG::SpeculativeJIT::callOperation):
391         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
392         * dfg/DFGSpeculativeJIT32_64.cpp:
393         (JSC::DFG::SpeculativeJIT::compile):
394         * dfg/DFGSpeculativeJIT64.cpp:
395         (JSC::DFG::SpeculativeJIT::compile):
396         * dfg/DFGValidate.cpp:
397         * ftl/FTLAbstractHeapRepository.h:
398         * ftl/FTLCapabilities.cpp:
399         (JSC::FTL::canCompile):
400         * ftl/FTLLowerDFGToB3.cpp:
401         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
402         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
403         * heap/Heap.cpp:
404         (JSC::Heap::collectImpl):
405         * jit/JITOperations.h:
406         * runtime/HasOwnPropertyCache.h: Added.
407         (JSC::HasOwnPropertyCache::Entry::offsetOfStructureID):
408         (JSC::HasOwnPropertyCache::Entry::offsetOfImpl):
409         (JSC::HasOwnPropertyCache::Entry::offsetOfResult):
410         (JSC::HasOwnPropertyCache::operator delete):
411         (JSC::HasOwnPropertyCache::create):
412         (JSC::HasOwnPropertyCache::hash):
413         (JSC::HasOwnPropertyCache::get):
414         (JSC::HasOwnPropertyCache::tryAdd):
415         (JSC::HasOwnPropertyCache::clear):
416         (JSC::VM::ensureHasOwnPropertyCache):
417         * runtime/Intrinsic.h:
418         * runtime/JSObject.h:
419         * runtime/JSObjectInlines.h:
420         (JSC::JSObject::hasOwnProperty):
421         * runtime/ObjectPrototype.cpp:
422         (JSC::ObjectPrototype::finishCreation):
423         (JSC::objectProtoFuncHasOwnProperty):
424         * runtime/Symbol.h:
425         * runtime/VM.cpp:
426         * runtime/VM.h:
427         (JSC::VM::hasOwnPropertyCache):
428
429 2016-09-19  Benjamin Poulain  <bpoulain@apple.com>
430
431         [JSC] Make the rounding-related nodes support any type
432         https://bugs.webkit.org/show_bug.cgi?id=161895
433
434         Reviewed by Geoffrey Garen.
435
436         This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
437         to support polymorphic input without exiting on entry.
438
439         * dfg/DFGAbstractInterpreterInlines.h:
440         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
441         * dfg/DFGByteCodeParser.cpp:
442         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
443         The 4 functions ignore any input past the first argument. It is okay
444         to use the nodes with the first argument and let the Phantoms keep
445         the remaining arguments live.
446
447         * dfg/DFGClobberize.h:
448         (JSC::DFG::clobberize):
449         * dfg/DFGFixupPhase.cpp:
450         (JSC::DFG::FixupPhase::fixupNode):
451         Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
452         prevents us from picking a good type if we do not see any double.
453
454         * dfg/DFGNodeType.h:
455         * dfg/DFGOperations.cpp:
456         * dfg/DFGOperations.h:
457         * dfg/DFGPredictionPropagationPhase.cpp:
458         Prediction propagation of those nodes are fully determined
459         from their flags and results's prediction. They are moved
460         to the invariant processing.
461
462         * dfg/DFGSpeculativeJIT.cpp:
463         (JSC::DFG::SpeculativeJIT::compileArithRounding):
464         * ftl/FTLLowerDFGToB3.cpp:
465         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
466         (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
467         (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
468         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
469
470 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
471
472         Unreviewed, build fix for Win64
473         https://bugs.webkit.org/show_bug.cgi?id=162132
474
475         In Windows 64bit, t3 register in LLInt is not r[a-d]x.
476         It means that this cannot be used for byte operation.
477
478         * llint/LowLevelInterpreter64.asm:
479
480 2016-09-19  Daniel Bates  <dabates@apple.com>
481
482         Remove ENABLE(TEXT_AUTOSIZING) automatic text size adjustment code
483         https://bugs.webkit.org/show_bug.cgi?id=162167
484
485         Reviewed by Simon Fraser.
486
487         * Configurations/FeatureDefines.xcconfig:
488
489 2016-09-19  Keith Miller  <keith_miller@apple.com>
490
491         Update WASM towards 0xc
492         https://bugs.webkit.org/show_bug.cgi?id=162067
493
494         Reviewed by Geoffrey Garen.
495
496         This patch updates some of the core parts of the WASM frontend to the 0xc standard.
497         First, it changes the section names from strings to bytecodes. It also adds support
498         for inline block signatures. This is a change from the old version that used to have
499         each branch indicate the arity. Finally, this patch updates all the tests and deletes
500         a duplicate test.
501
502         * CMakeLists.txt:
503         * JavaScriptCore.xcodeproj/project.pbxproj:
504         * testWASM.cpp:
505         (runWASMTests):
506         * wasm/WASMB3IRGenerator.cpp:
507         * wasm/WASMFormat.h:
508         * wasm/WASMFunctionParser.h:
509         (JSC::WASM::FunctionParser<Context>::FunctionParser):
510         (JSC::WASM::FunctionParser<Context>::parseBlock):
511         (JSC::WASM::FunctionParser<Context>::parseExpression):
512         * wasm/WASMModuleParser.cpp:
513         (JSC::WASM::ModuleParser::parse):
514         * wasm/WASMSections.cpp: Removed.
515         (JSC::WASM::Sections::lookup): Deleted.
516         * wasm/WASMSections.h:
517         (JSC::WASM::Sections::validateOrder):
518
519 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
520
521         [JSC] Use is_cell_with_type for @isRegExpObject, @isMap, and @isSet
522         https://bugs.webkit.org/show_bug.cgi?id=162142
523
524         Reviewed by Michael Saboff.
525
526         Use is_cell_with_type for @isRegExpObject, @isMap and @isSet.
527         Previously, they were implemented as functions and only @isRegExpObject was handled in the DFG and FTL.
528         The recently added op_is_cell_with_type bytecode and DFG IsCellWithType node allows us to simplify the above checks in all JIT tiers.
529         Changed these checks to bytecode intrinsics using op_is_cell_with_type.
530
531         * builtins/BuiltinNames.h:
532         * bytecode/BytecodeIntrinsicRegistry.h:
533         * bytecode/SpeculatedType.cpp:
534         (JSC::speculationFromJSType):
535         * bytecompiler/BytecodeGenerator.h:
536         (JSC::BytecodeGenerator::emitIsRegExpObject):
537         (JSC::BytecodeGenerator::emitIsMap):
538         (JSC::BytecodeGenerator::emitIsSet):
539         (JSC::BytecodeGenerator::emitIsProxyObject): Deleted.
540         * bytecompiler/NodesCodegen.cpp:
541         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isRegExpObject):
542         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isMap):
543         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isSet):
544         * dfg/DFGByteCodeParser.cpp:
545         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
546         * runtime/ECMAScriptSpecInternalFunctions.cpp:
547         (JSC::esSpecIsRegExpObject): Deleted.
548         * runtime/ECMAScriptSpecInternalFunctions.h:
549         * runtime/Intrinsic.h:
550         * runtime/JSGlobalObject.cpp:
551         (JSC::JSGlobalObject::init):
552         * runtime/MapPrototype.cpp:
553         (JSC::privateFuncIsMap): Deleted.
554         * runtime/MapPrototype.h:
555         * runtime/SetPrototype.cpp:
556         (JSC::privateFuncIsSet): Deleted.
557         * runtime/SetPrototype.h:
558
559 2016-09-19  Brian Burg  <bburg@apple.com>
560
561         Web Replay: teach the replay inputs generator to encode and decode OptionSet<T>
562         https://bugs.webkit.org/show_bug.cgi?id=162107
563
564         Reviewed by Anders Carlsson.
565
566         Add a new type flag OPTION_SET. This means that the type is a typechecked enum class
567         declaration, but it's stored in an OptionSet object and can contain multiple
568         distinct enumeration values like an untyped enum declaration.
569
570         Do some cleanup since the generator now supports three different enumerable types:
571         'enum', 'enum class', and 'OptionSet<T>' where T is an enum class.
572
573         Also clean up some sloppy variable names. Using an 'enum_' prefix is really confusing now.
574
575         * replay/scripts/CodeGeneratorReplayInputs.py:
576         (Type.is_enum_declaration):
577         (Type.is_enum_class_declaration):
578         (Type.is_option_set):
579         (Type):
580         (Type.is_enumerable):
581         When we want all enumerable types, this property includes all three variants.
582
583         (Type.declaration_kind): Forward-declare OptionSet's type parameter as an enum class.
584         (VectorType.is_enum_declaration): Renamed from is_enum().
585         (VectorType.is_enum_class_declaration): Renamed from is_enum_class().
586         (VectorType.is_option_set): Added.
587         (InputsModel.enumerable_types): Added.
588         (InputsModel.parse_type_with_framework):
589         (Generator.generate_header):
590         (Generator.generate_implementation):
591         (Generator.generate_includes):
592         (Generator.generate_type_forward_declarations):
593         (Generator.generate_enumerable_type_trait_declaration):
594         (Generator.generate_enum_trait_declaration): Renamed.
595         (Generator.generate_enum_trait_implementation): Renamed.
596
597         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
598         Add new templates for OptionSet types. Clean up parameter names and simplify the
599         enumerable type declaration template, which is the same for all enumerable type variants.
600
601         * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
602         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
603         (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::encodeValue):
604         (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::decodeValue):
605         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
606         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
607         Rebaseline test results.
608
609         * replay/scripts/tests/generate-enum-encoding-helpers.json:
610         Add a new type for OptionSet<PlatformEvent::Modifier> to capture generated encode/decode methods.
611
612 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
613
614         [JSC][LLInt] Introduce is_cell_with_type
615         https://bugs.webkit.org/show_bug.cgi?id=162132
616
617         Reviewed by Sam Weinig.
618
619         In this patch, we introduce is_cell_with_type bytecode. This bytecode can unify the following predicates,
620         op_is_string, op_is_jsarray, op_is_proxy_object, and op_is_derived_array!
621         And we now drop DFG node IsString since we can use IsCellWithType instead.
622         This automatically offers optimization to previous IsString node: dropping cell check by using CellUse edge filter.
623
624         Later, we are planning to use this is_cell_with_type to optimize @isRegExpObject, @isSet, and @isMap[1].
625
626         The performance results are neutral.
627
628         [1]: https://bugs.webkit.org/show_bug.cgi?id=162142
629
630         * bytecode/BytecodeList.json:
631         * bytecode/BytecodeUseDef.h:
632         (JSC::computeUsesForBytecodeOffset):
633         (JSC::computeDefsForBytecodeOffset):
634         * bytecode/CodeBlock.cpp:
635         (JSC::CodeBlock::dumpBytecode):
636         * bytecode/SpeculatedType.cpp:
637         (JSC::speculationFromJSType):
638         * bytecode/SpeculatedType.h:
639         * bytecompiler/BytecodeGenerator.cpp:
640         (JSC::BytecodeGenerator::emitEqualityOp):
641         (JSC::BytecodeGenerator::emitIsCellWithType):
642         * bytecompiler/BytecodeGenerator.h:
643         (JSC::BytecodeGenerator::emitIsJSArray):
644         (JSC::BytecodeGenerator::emitIsProxyObject):
645         (JSC::BytecodeGenerator::emitIsDerivedArray):
646         * dfg/DFGAbstractInterpreterInlines.h:
647         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
648         * dfg/DFGByteCodeParser.cpp:
649         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
650         (JSC::DFG::ByteCodeParser::parseBlock):
651         * dfg/DFGCapabilities.cpp:
652         (JSC::DFG::capabilityLevel):
653         * dfg/DFGClobberize.h:
654         (JSC::DFG::clobberize):
655         * dfg/DFGDoesGC.cpp:
656         (JSC::DFG::doesGC):
657         * dfg/DFGFixupPhase.cpp:
658         (JSC::DFG::FixupPhase::fixupNode):
659         (JSC::DFG::FixupPhase::fixupIsCellWithType):
660         * dfg/DFGNode.h:
661         (JSC::DFG::Node::speculatedTypeForQuery):
662         * dfg/DFGNodeType.h:
663         * dfg/DFGPredictionPropagationPhase.cpp:
664         * dfg/DFGSafeToExecute.h:
665         (JSC::DFG::safeToExecute):
666         * dfg/DFGSpeculativeJIT32_64.cpp:
667         (JSC::DFG::SpeculativeJIT::compile):
668         * dfg/DFGSpeculativeJIT64.cpp:
669         (JSC::DFG::SpeculativeJIT::compile):
670         * ftl/FTLCapabilities.cpp:
671         (JSC::FTL::canCompile):
672         * ftl/FTLLowerDFGToB3.cpp:
673         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
674         (JSC::FTL::DFG::LowerDFGToB3::compileIsString): Deleted.
675         * jit/JIT.cpp:
676         (JSC::JIT::privateCompileMainPass):
677         * jit/JIT.h:
678         * jit/JITOpcodes.cpp:
679         (JSC::JIT::emit_op_is_cell_with_type):
680         (JSC::JIT::emitIsCellWithType): Deleted.
681         (JSC::JIT::emit_op_is_string): Deleted.
682         (JSC::JIT::emit_op_is_jsarray): Deleted.
683         (JSC::JIT::emit_op_is_proxy_object): Deleted.
684         (JSC::JIT::emit_op_is_derived_array): Deleted.
685         * jit/JITOpcodes32_64.cpp:
686         (JSC::JIT::emit_op_is_cell_with_type):
687         (JSC::JIT::emitIsCellWithType): Deleted.
688         (JSC::JIT::emit_op_is_string): Deleted.
689         (JSC::JIT::emit_op_is_jsarray): Deleted.
690         (JSC::JIT::emit_op_is_proxy_object): Deleted.
691         (JSC::JIT::emit_op_is_derived_array): Deleted.
692         * llint/LLIntData.cpp:
693         (JSC::LLInt::Data::performAssertions):
694         * llint/LowLevelInterpreter32_64.asm:
695         * llint/LowLevelInterpreter64.asm:
696
697 2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
698
699         [JSC] Assert length of LLInt opcodes using isCellWithType is 3
700         https://bugs.webkit.org/show_bug.cgi?id=162134
701
702         Reviewed by Saam Barati.
703
704         * llint/LLIntData.cpp:
705         (JSC::LLInt::Data::performAssertions):
706
707 2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
708
709         [JSC] Do not need to use defineProperty to define methods for object literals
710         https://bugs.webkit.org/show_bug.cgi?id=162111
711
712         Reviewed by Saam Barati.
713
714         When we receive the following code,
715
716             var object = { method() { } };
717
718         currently, we use defineProperty to define "method" function for "object".
719         This patch replaces it with the ordinary put_by_id_direct / put_by_val_direct
720         because the following 2 conditions are met.
721
722         1. While methods in classes have special attributes ({configurable: true, writable: true, enumerable: false}),
723            the attributes of methods in object literals is just the same to the other normal properties ({configurable: true, writable: true, enumerable: true}).
724            This means that we can use the usual put_by_id_direct / put_by_val_direct to define method properties for object literals.
725
726         2. Furthermore, all the own properties that can reside in objects created by object literals have {configurable: true}.
727            So there is no need to check conflict by defineProperty. Always overwriting is OK.
728
729                 let name = 'method';
730                 var object = { get [name]() { }, method() { } };
731                 // Latter method wins.
732
733             On the other hand, in class syntax, conflict check is necessary since "prototype" own property is defined as {configurable: false}.
734
735                 class Hello { static prototype() { } }  // Should throw error by defineProperty's check.
736
737             This means that conflict check done in defneProperty is not necessary for object literals' properties.
738
739         * bytecompiler/NodesCodegen.cpp:
740         (JSC::PropertyListNode::emitPutConstantProperty):
741
742 2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>
743
744         [DFG] Introduce IsCellWithType node and unify IsJSArray, IsRegExpObject and newly added IsProxyObject
745         https://bugs.webkit.org/show_bug.cgi?id=162000
746
747         Reviewed by Filip Pizlo.
748
749         Sampling profiler tells that ES6SampleBench/Basic frequently calls Array.isArray(). This function is introduced in
750         ES5 and it is well-used to distinguish Array from the other objects. Moreover, this function is used in Array.prototype.xxx
751         methods as @isArray. So it's worth optimizing.
752
753         The difference between Array.isArray and @isJSArray is that Array.isArray need to consider about ProxyObject while
754         @isJSArray builtin intrinsic does not. So in this patch, we leverage the existing @isJSArray to implement Array.isArray.
755         Array.isArray is written in builtin JS code using @isJSArray and newly added @isProxyObject(). That allow us to inline
756         Array.isArray() code and the inlined code uses existing DFG nodes well.
757
758         Another problem is RuntimeArray and ArrayPrototype. They inherit JSArray and their JSType is ObjectType. But Array.isArray need
759         to return true for those types. While optimizing type checking in generic way by type display is nice, RuntimeArray and
760         ArrayPrototype are a bit tricky and it is super rare that these functions are passed to Array.isArray(). So instead of introducing
761         type display in this patch, we just introduce a new JSType, DerivedArrayType and use it in the above 2 use classes. Since
762         Array.isArray is specially handled in the spec (while we don't have any Date.isDate() like functions, only Array.isArray
763         is specified in the spec because we frequently want to distinguish Arrays from other Objects), optimizing Array.isArray specially
764         by introducing special DerivedArrayType is reasonable.
765
766         In LLInt level, we add a new opcode, op_is_proxy_object and op_is_derived_array. This works similar to op_is_jsarray.
767         And we also perform LLInt code cleanup by introducing a macro isCellWithType.
768
769         In baseline, we perform some clean up for op_is_proxy_object etc. Now duplicate code is reduced.
770
771         In DFG, we unify IsJSArray, IsRegExpObject, IsProxyObject, and IsDerivedArray into one IsCellWithType node. And we clean up
772         some AI code related to IsJSArray and IsRegExpObject since SpeculatedType now recognizes ProxyObject. IsJSArray and IsRegExpObject
773         does not do anything special for proxy objects.
774
775         The above change simplify things to create a new IsXXX DFG handling and paves the way for optimizing @isMap & @isSet in DFG.
776         Furthermore, introducing @isProxyObject() is nice for the first step to optimize ProxyObject handling.
777
778         Here is microbenchmark result. We can see stable performance improvement (Even if we use Proxies!).
779
780                                                     baseline                  patched
781
782             is-array-for-array                   2.5156+-0.0288     ^      2.0668+-0.0285        ^ definitely 1.2171x faster
783             is-array-for-mixed-case              4.7787+-0.0755     ^      4.4722+-0.0789        ^ definitely 1.0686x faster
784             is-array-for-non-array-object        2.3596+-0.0368     ^      1.8178+-0.0262        ^ definitely 1.2980x faster
785             is-array-for-proxy                   4.0469+-0.0437     ^      3.3845+-0.0404        ^ definitely 1.1957x faster
786
787         And ES6SampleBench/Basic reports 5.2% perf improvement. And now sampling result in ES6SampleBench/Basic does not pose Array.isArray.
788
789             Benchmark             First Iteration        Worst 2%               Steady State
790             baseline:Basic        28.59 ms +- 1.03 ms    15.08 ms +- 0.28 ms    1656.96 ms +- 18.02 ms
791             patched:Basic         27.82 ms +- 0.44 ms    14.59 ms +- 0.16 ms    1574.65 ms +- 8.44 ms
792
793         * builtins/ArrayConstructor.js:
794         (isArray):
795         (from): Deleted.
796         * builtins/BuiltinNames.h:
797         * bytecode/BytecodeIntrinsicRegistry.h:
798         * bytecode/BytecodeList.json:
799         * bytecode/BytecodeUseDef.h:
800         (JSC::computeUsesForBytecodeOffset):
801         (JSC::computeDefsForBytecodeOffset):
802         * bytecode/CodeBlock.cpp:
803         (JSC::CodeBlock::dumpBytecode):
804         * bytecode/SpeculatedType.cpp:
805         (JSC::dumpSpeculation):
806         (JSC::speculationFromClassInfo):
807         (JSC::speculationFromStructure):
808         * bytecode/SpeculatedType.h:
809         (JSC::isProxyObjectSpeculation):
810         (JSC::isDerivedArraySpeculation):
811         * bytecompiler/BytecodeGenerator.h:
812         (JSC::BytecodeGenerator::emitIsProxyObject):
813         (JSC::BytecodeGenerator::emitIsDerivedArray):
814         (JSC::BytecodeGenerator::emitIsJSArray): Deleted.
815         * bytecompiler/NodesCodegen.cpp:
816         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isProxyObject):
817         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isDerivedArray):
818         * dfg/DFGAbstractInterpreterInlines.h:
819         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
820         * dfg/DFGByteCodeParser.cpp:
821         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
822         (JSC::DFG::ByteCodeParser::parseBlock):
823         * dfg/DFGCapabilities.cpp:
824         (JSC::DFG::capabilityLevel):
825         * dfg/DFGClobberize.h:
826         (JSC::DFG::clobberize):
827         * dfg/DFGDoesGC.cpp:
828         (JSC::DFG::doesGC):
829         * dfg/DFGFixupPhase.cpp:
830         (JSC::DFG::FixupPhase::fixupNode):
831         (JSC::DFG::FixupPhase::fixupIsCellWithType):
832         * dfg/DFGGraph.cpp:
833         (JSC::DFG::Graph::dump):
834         * dfg/DFGNode.h:
835         (JSC::DFG::Node::hasQueriedType):
836         (JSC::DFG::Node::queriedType):
837         (JSC::DFG::Node::hasSpeculatedTypeForQuery):
838         (JSC::DFG::Node::speculatedTypeForQuery):
839         (JSC::DFG::Node::shouldSpeculateProxyObject):
840         (JSC::DFG::Node::shouldSpeculateDerivedArray):
841         (JSC::DFG::Node::loadVarargsData): Deleted.
842         (JSC::DFG::Node::shouldSpeculateArray): Deleted.
843         * dfg/DFGNodeType.h:
844         * dfg/DFGPredictionPropagationPhase.cpp:
845         * dfg/DFGSafeToExecute.h:
846         (JSC::DFG::SafeToExecuteEdge::operator()):
847         (JSC::DFG::safeToExecute):
848         * dfg/DFGSpeculativeJIT.cpp:
849         (JSC::DFG::SpeculativeJIT::compileIsCellWithType):
850         (JSC::DFG::SpeculativeJIT::speculateProxyObject):
851         (JSC::DFG::SpeculativeJIT::speculateDerivedArray):
852         (JSC::DFG::SpeculativeJIT::speculate):
853         (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
854         (JSC::DFG::SpeculativeJIT::compileIsRegExpObject): Deleted.
855         * dfg/DFGSpeculativeJIT.h:
856         * dfg/DFGSpeculativeJIT32_64.cpp:
857         (JSC::DFG::SpeculativeJIT::compile):
858         * dfg/DFGSpeculativeJIT64.cpp:
859         (JSC::DFG::SpeculativeJIT::compile):
860         * dfg/DFGUseKind.cpp:
861         (WTF::printInternal):
862         * dfg/DFGUseKind.h:
863         (JSC::DFG::typeFilterFor):
864         (JSC::DFG::isCell):
865         * ftl/FTLCapabilities.cpp:
866         (JSC::FTL::canCompile):
867         * ftl/FTLLowerDFGToB3.cpp:
868         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
869         (JSC::FTL::DFG::LowerDFGToB3::compileIsCellWithType):
870         (JSC::FTL::DFG::LowerDFGToB3::speculate):
871         (JSC::FTL::DFG::LowerDFGToB3::isCellWithType):
872         (JSC::FTL::DFG::LowerDFGToB3::speculateProxyObject):
873         (JSC::FTL::DFG::LowerDFGToB3::speculateDerivedArray):
874         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
875         (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): Deleted.
876         (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
877         (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject): Deleted.
878         * jit/JIT.cpp:
879         (JSC::JIT::privateCompileMainPass):
880         * jit/JIT.h:
881         * jit/JITOpcodes.cpp:
882         (JSC::JIT::emitIsCellWithType):
883         (JSC::JIT::emit_op_is_string):
884         (JSC::JIT::emit_op_is_jsarray):
885         (JSC::JIT::emit_op_is_proxy_object):
886         (JSC::JIT::emit_op_is_derived_array):
887         * jit/JITOpcodes32_64.cpp:
888         (JSC::JIT::emitIsCellWithType):
889         (JSC::JIT::emit_op_is_string):
890         (JSC::JIT::emit_op_is_jsarray):
891         (JSC::JIT::emit_op_is_proxy_object):
892         (JSC::JIT::emit_op_is_derived_array):
893         * jsc.cpp:
894         (WTF::RuntimeArray::createStructure):
895         * llint/LLIntData.cpp:
896         (JSC::LLInt::Data::performAssertions):
897         * llint/LowLevelInterpreter.asm:
898         * llint/LowLevelInterpreter32_64.asm:
899         * llint/LowLevelInterpreter64.asm:
900         * runtime/ArrayConstructor.cpp:
901         (JSC::ArrayConstructor::finishCreation):
902         (JSC::isArraySlowInline):
903         (JSC::isArraySlow):
904         (JSC::arrayConstructorPrivateFuncIsArraySlow):
905         (JSC::arrayConstructorIsArray): Deleted.
906         * runtime/ArrayConstructor.h:
907         (JSC::isArray):
908         * runtime/ArrayPrototype.h:
909         (JSC::ArrayPrototype::createStructure):
910         * runtime/JSArray.h:
911         (JSC::JSArray::finishCreation):
912         * runtime/JSGlobalObject.cpp:
913         (JSC::JSGlobalObject::init):
914         * runtime/JSType.h:
915
916 2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>
917
918         [DFG] Introduce ArrayUse
919         https://bugs.webkit.org/show_bug.cgi?id=162063
920
921         Reviewed by Keith Miller.
922
923         ArrayUse is particularly useful: for IsJSArray.
924         We can drop IsJSArray in fixup phase by setting ArrayUse edge filter.
925
926         Since @isJSArray user is limited (Array.prototype.concat), the effect of this patch is small.
927         But later, I'll update {@isArray, Array.isArray} to use @isJSArray[1]. In that patch, we are planning
928         to implement more aggressive optimization like, setting CellUse edge filter to avoid cell check in
929         SpeculativeJIT::compileIsJSArray.
930
931         In the benchmark using Array.prototype.concat, we can see perf improvement since we can drop IsJSArray in fixup phase.
932
933                                                      baseline                  patched
934
935             lazy-array-species-watchpoints       25.0911+-0.0516     ^     24.7687+-0.0767        ^ definitely 1.0130x faster
936
937         [1]: https://bugs.webkit.org/show_bug.cgi?id=162000
938
939         * dfg/DFGFixupPhase.cpp:
940         (JSC::DFG::FixupPhase::fixupNode):
941         * dfg/DFGSafeToExecute.h:
942         (JSC::DFG::SafeToExecuteEdge::operator()):
943         * dfg/DFGSpeculativeJIT.cpp:
944         (JSC::DFG::SpeculativeJIT::speculateArray):
945         (JSC::DFG::SpeculativeJIT::speculate):
946         * dfg/DFGSpeculativeJIT.h:
947         * dfg/DFGUseKind.cpp:
948         (WTF::printInternal):
949         * dfg/DFGUseKind.h:
950         (JSC::DFG::typeFilterFor):
951         (JSC::DFG::isCell):
952         * ftl/FTLCapabilities.cpp:
953         (JSC::FTL::canCompile):
954         * ftl/FTLLowerDFGToB3.cpp:
955         (JSC::FTL::DFG::LowerDFGToB3::speculate):
956         (JSC::FTL::DFG::LowerDFGToB3::speculateArray):
957         (JSC::FTL::DFG::LowerDFGToB3::speculateObject): Deleted.
958
959 2016-09-16  Joseph Pecoraro  <pecoraro@apple.com>
960
961         test262: Various Constructors length properties should be configurable
962         https://bugs.webkit.org/show_bug.cgi?id=161998
963
964         Reviewed by Saam Barati.
965
966         https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
967         Unless otherwise specified, the length property of a built-in Function
968         object has the attributes:
969         { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
970
971         * runtime/ErrorConstructor.cpp:
972         (JSC::ErrorConstructor::finishCreation):
973         * runtime/JSPromiseConstructor.cpp:
974         (JSC::JSPromiseConstructor::finishCreation):
975         * runtime/MapConstructor.cpp:
976         (JSC::MapConstructor::finishCreation):
977         * runtime/NativeErrorConstructor.cpp:
978         (JSC::NativeErrorConstructor::finishCreation):
979         * runtime/ProxyConstructor.cpp:
980         (JSC::ProxyConstructor::finishCreation):
981         * runtime/SetConstructor.cpp:
982         (JSC::SetConstructor::finishCreation):
983         * runtime/WeakMapConstructor.cpp:
984         (JSC::WeakMapConstructor::finishCreation):
985         * runtime/WeakSetConstructor.cpp:
986         (JSC::WeakSetConstructor::finishCreation):
987
988 2016-09-16  Youenn Fablet  <youenn@apple.com>
989
990         Custom promise-returning functions should not throw if callee has not the expected type
991         https://bugs.webkit.org/show_bug.cgi?id=162011
992
993         Reviewed by Sam Weinig.
994
995         * JavaScriptCore.xcodeproj/project.pbxproj: Making JSPromiseConstructor.h private
996
997 2016-09-15  Filip Pizlo  <fpizlo@apple.com>
998
999         REGRESSION (r205462): Lot of leaks
1000         https://bugs.webkit.org/show_bug.cgi?id=161946
1001
1002         Reviewed by Saam Barati.
1003         
1004         We were forgetting to delete LargeAllocations on VM exit!
1005
1006         * heap/MarkedSpace.cpp:
1007         (JSC::MarkedSpace::~MarkedSpace):
1008
1009 2016-09-15  Keith Miller  <keith_miller@apple.com>
1010
1011
1012         Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
1013         https://bugs.webkit.org/show_bug.cgi?id=161985
1014
1015         Reviewed by Alex Christensen.
1016
1017         I started a true fix for this in
1018         https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
1019         for this issue is not sustainable. Since the scope of this issue
1020         is just limited to the static const ClassInfo member it is
1021         simpler to just pragma out this warning. This works because
1022         COMDAT will, AFAIK, pick the actual specialization.  If, in the
1023         future, we want to expose these classes to WebCore we will need to
1024         do what we do for JSGenericTypedArrayViews and create a custom
1025         info() function with a switch.
1026
1027         This patch also fixes a bunch of weak external symbols due to one of:
1028         1) out of line template member definitions functions not being marked inline.
1029         2) inline member functions definitions being marked as exported.
1030         3) missing header file includes for forward function declarations.
1031
1032         * API/JSCallbackObject.h:
1033         * b3/B3ValueInlines.h:
1034         (JSC::B3::Value::as):
1035         * runtime/HashMapImpl.cpp:
1036         (JSC::getHashMapBucketKeyClassInfo):
1037         (JSC::getHashMapBucketKeyValueClassInfo):
1038         (JSC::getHashMapImplKeyClassInfo):
1039         (JSC::getHashMapImplKeyValueClassInfo):
1040         * runtime/HashMapImpl.h:
1041         (JSC::HashMapBucket::info):
1042         (JSC::HashMapImpl::info):
1043         * runtime/JSCJSValue.h:
1044         (JSC::toUInt32): Deleted.
1045         * runtime/JSGenericTypedArrayView.h:
1046         (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
1047         * runtime/JSGenericTypedArrayViewConstructor.h:
1048         * runtime/JSGenericTypedArrayViewPrototype.h:
1049         * runtime/MathCommon.h:
1050         (JSC::toUInt32):
1051         * runtime/TypedArrayAdaptors.h:
1052         * runtime/VM.h:
1053         (JSC::VM::watchdog):
1054         (JSC::VM::heapProfiler):
1055         (JSC::VM::samplingProfiler):
1056
1057 2016-09-14  Filip Pizlo  <fpizlo@apple.com>
1058
1059         There is no good reason for WeakBlock to care about newly allocated objects
1060         https://bugs.webkit.org/show_bug.cgi?id=162006
1061
1062         Reviewed by Geoffrey Garen.
1063
1064         WeakBlock scans itself in two modes:
1065
1066         visit: if a Weak in the block belongs to an unmarked object, ask the Weak to consider whether
1067             it should do things.
1068         
1069         reap: if a Weak in a block belongs to an unmarked object, delete the Weak.
1070
1071         Except that "unmarked" has a peculiar meaning: WeakBlock defines it as
1072         !markedOrNewlyAllocated. So, a newly allocated object will never be consulted about anything. 
1073         That sounds scary until you realize that newlyAllocated must have been cleared before we even
1074         got here.
1075
1076         So, we were paying the price of checking newlyAllocated for no reason. This switches the code
1077         to using isMarked(). I don't know why the code previously checked newlyAllocated, but I do
1078         trust my reasoning.
1079
1080         * heap/LargeAllocation.h:
1081         (JSC::LargeAllocation::isMarkedDuringWeakVisiting):
1082         (JSC::LargeAllocation::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
1083         * heap/MarkedBlock.h:
1084         (JSC::MarkedBlock::isMarkedDuringWeakVisiting):
1085         (JSC::MarkedBlock::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
1086         * heap/WeakBlock.cpp:
1087         (JSC::WeakBlock::specializedVisit):
1088         (JSC::WeakBlock::reap):
1089
1090 2016-09-15  Commit Queue  <commit-queue@webkit.org>
1091
1092         Unreviewed, rolling out r205931.
1093         https://bugs.webkit.org/show_bug.cgi?id=162021
1094
1095         Tests for this change fail on 32-bit JSC bots (Requested by
1096         ryanhaddad on #webkit).
1097
1098         Reverted changeset:
1099
1100         "[JSC] Make the rounding-related nodes support any type"
1101         https://bugs.webkit.org/show_bug.cgi?id=161895
1102         http://trac.webkit.org/changeset/205931
1103
1104 2016-09-15  Joseph Pecoraro  <pecoraro@apple.com>
1105
1106         test262: Should be a SyntaxError for duplicate parameter names in function with default parameters
1107         https://bugs.webkit.org/show_bug.cgi?id=162013
1108
1109         Reviewed by Saam Barati.
1110
1111         https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-early-errors
1112         It is a Syntax Error if IsSimpleParameterList of FormalParameterList is
1113         false and BoundNames of FormalParameterList contains any duplicate elements.
1114
1115         Non-simple parameter lists include rest parameters, destructuring,
1116         and default parameters.
1117
1118         * parser/Parser.cpp:
1119         (JSC::Parser<LexerType>::parseFormalParameters):
1120         Previously, we were not failing if there were default parameters
1121         early in the parameter list that were not yet identified as duplicates
1122         and simple parameters later were duplicates. Now, we fail if there
1123         are default parameters anywhere in the parameter list with a duplicate.
1124
1125 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1126
1127         ASSERT_NOT_REACHED when using spread inside an array literal with Function.prototype.apply
1128         https://bugs.webkit.org/show_bug.cgi?id=162003
1129
1130         Reviewed by Saam Barati.
1131
1132         * bytecompiler/NodesCodegen.cpp:
1133         (JSC::ArrayNode::isSimpleArray):
1134         Don't treat an Array that has a spread expression inside it as simple.
1135         This avoids a fast path for f.apply(x, simpleArray) that was not handling
1136         spread expressions within arrays, and instead taking a path that can
1137         handle the spreading.
1138
1139 2016-09-14  Commit Queue  <commit-queue@webkit.org>
1140
1141         Unreviewed, rolling out r205933 and r205936.
1142         https://bugs.webkit.org/show_bug.cgi?id=162002
1143
1144         broke the build (Requested by keith_miller on #webkit).
1145
1146         Reverted changesets:
1147
1148         "Pragma out undefined-var-template warnings in JSC for
1149         JSObjects that are templatized"
1150         https://bugs.webkit.org/show_bug.cgi?id=161985
1151         http://trac.webkit.org/changeset/205933
1152
1153         "Unreviewed, fix the Windows build."
1154         http://trac.webkit.org/changeset/205936
1155
1156 2016-09-14  Chris Dumez  <cdumez@apple.com>
1157
1158         REGRESSION (r205670): ASSERTION FAILED: methodTable(vm)->toThis(this, exec, NotStrictMode) == this
1159         https://bugs.webkit.org/show_bug.cgi?id=161982
1160
1161         Reviewed by Saam Barati.
1162
1163         Update JSProxy::setPrototype() to return false unconditionally instead
1164         of forwarding the call to its target. We used to forward to the target
1165         and then the JSDOMWindow's [[SetPrototypeOf]] would return false.
1166         However, the JSC tests use a different GlobalObject and forwarding
1167         the setPrototypeOf() call to the GlobalObject lead to hitting an
1168         assertion. This patch aligns the behavior of the GlobalObject used by
1169         the JSC tests with JSDOMWindow.
1170
1171         * runtime/JSProxy.cpp:
1172         (JSC::JSProxy::setPrototype):
1173
1174 2016-09-14  Michael Saboff  <msaboff@apple.com>
1175
1176         YARR doesn't check for invalid flags for literal regular expressions
1177         https://bugs.webkit.org/show_bug.cgi?id=161995
1178
1179         Reviewed by Mark Lam.
1180
1181         Added a new error and a check that the flags are valid when we create a
1182         literal regular expression.
1183
1184         * runtime/RegExp.cpp:
1185         (JSC::RegExp::finishCreation):
1186         * yarr/YarrPattern.cpp:
1187         (JSC::Yarr::YarrPattern::errorMessage):
1188         (JSC::Yarr::YarrPattern::compile):
1189         * yarr/YarrPattern.h:
1190
1191 2016-09-14  Keith Miller  <keith_miller@apple.com>
1192
1193         Unreviewed, fix the Windows build.
1194
1195         * runtime/HashMapImpl.cpp:
1196
1197 2016-09-14  Keith Miller  <keith_miller@apple.com>
1198
1199         Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
1200         https://bugs.webkit.org/show_bug.cgi?id=161985
1201
1202         Reviewed by Geoffrey Garen.
1203
1204         I started a true fix for this in
1205         https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
1206         for this issue is not sustainable. Since the scope of this issue
1207         is just limited to the static const ClassInfo member it is
1208         simpler to just pragma out this warning. This works because
1209         COMDAT will, AFAIK, pick the actual specialization.  If, in the
1210         future, we want to expose these classes to WebCore we will need to
1211         do what we do for JSGenericTypedArrayViews and create a custom
1212         info() function with a switch.
1213
1214         This patch also fixes a bunch of weak external symbols due to one of:
1215         1) out of line template member definitions functions not being marked inline.
1216         2) inline member functions definitions being marked as exported.
1217         3) missing header file includes for forward function declarations.
1218
1219         * API/JSCallbackObject.h:
1220         * b3/B3ValueInlines.h:
1221         (JSC::B3::Value::as):
1222         * runtime/HashMapImpl.h:
1223         * runtime/JSCJSValue.h:
1224         (JSC::toUInt32): Deleted.
1225         * runtime/JSGenericTypedArrayView.h:
1226         (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
1227         * runtime/JSGenericTypedArrayViewConstructor.h:
1228         * runtime/JSGenericTypedArrayViewPrototype.h:
1229         * runtime/MathCommon.h:
1230         (JSC::toUInt32):
1231         * runtime/TypedArrayAdaptors.h:
1232         * runtime/VM.h:
1233         (JSC::VM::watchdog):
1234         (JSC::VM::heapProfiler):
1235         (JSC::VM::samplingProfiler):
1236
1237 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1238
1239         test262: TypedArray constructors length should be 3 and configurable
1240         https://bugs.webkit.org/show_bug.cgi?id=161955
1241
1242         Reviewed by Mark Lam.
1243
1244         https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
1245         Unless otherwise specified, the length property of a built-in Function
1246         object has the attributes:
1247         { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
1248
1249         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1250         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1251
1252 2016-09-14  Benjamin Poulain  <bpoulain@apple.com>
1253
1254         [JSC] Make the rounding-related nodes support any type
1255         https://bugs.webkit.org/show_bug.cgi?id=161895
1256
1257         Reviewed by Geoffrey Garen.
1258
1259         This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
1260         to support polymorphic input without exiting on entry.
1261
1262         * dfg/DFGAbstractInterpreterInlines.h:
1263         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1264         * dfg/DFGByteCodeParser.cpp:
1265         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1266         The 4 functions ignore any input past the first argument. It is okay
1267         to use the nodes with the first argument and let the Phantoms keep
1268         the remaining arguments live.
1269
1270         * dfg/DFGClobberize.h:
1271         (JSC::DFG::clobberize):
1272         * dfg/DFGFixupPhase.cpp:
1273         (JSC::DFG::FixupPhase::fixupNode):
1274         Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
1275         prevents us from picking a good type if we do not see any double.
1276
1277         * dfg/DFGNodeType.h:
1278         * dfg/DFGOperations.cpp:
1279         * dfg/DFGOperations.h:
1280         * dfg/DFGPredictionPropagationPhase.cpp:
1281         Prediction propagation of those nodes are fully determined
1282         from their flags and results's prediction. They are moved
1283         to the invariant processing.
1284
1285         * dfg/DFGSpeculativeJIT.cpp:
1286         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1287         * ftl/FTLLowerDFGToB3.cpp:
1288         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
1289         (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
1290         (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
1291         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
1292
1293 2016-09-14  Filip Pizlo  <fpizlo@apple.com>
1294
1295         Remove Heap::setMarked()
1296
1297         Rubber stamped by Keith Miller.
1298         
1299         Nobody uses this function.
1300
1301         * heap/Heap.h:
1302         * heap/HeapInlines.h:
1303         (JSC::Heap::setMarked): Deleted.
1304         * heap/LargeAllocation.h:
1305         (JSC::LargeAllocation::testAndSetMarked):
1306         (JSC::LargeAllocation::setMarked): Deleted.
1307         * heap/MarkedBlock.h:
1308
1309 2016-09-14  Mark Lam  <mark.lam@apple.com>
1310
1311         Use Options::validateExceptionChecks() instead of VM::m_verifyExceptionEvents.
1312         https://bugs.webkit.org/show_bug.cgi?id=161975
1313
1314         Reviewed by Keith Miller.
1315
1316         This makes it less burdensome (no longer needs a rebuild to enable checks) to do
1317         incremental work towards enabling checks all the time.
1318
1319         * runtime/Options.h:
1320         * runtime/VM.cpp:
1321         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
1322         * runtime/VM.h:
1323
1324 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1325
1326         TaggedTemplateString function calls should emit tail position calls
1327         https://bugs.webkit.org/show_bug.cgi?id=161948
1328
1329         Reviewed by Yusuke Suzuki.
1330
1331         * bytecompiler/NodesCodegen.cpp:
1332         (JSC::TaggedTemplateNode::emitBytecode):
1333         The tagged template string function call can be a tail call:
1334         https://tc39.github.io/ecma262/#sec-tagged-templates-runtime-semantics-evaluation
1335
1336 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1337
1338         test262: Array.prototype.slice should always set length
1339         https://bugs.webkit.org/show_bug.cgi?id=161953
1340
1341         Reviewed by Mark Lam.
1342
1343         * runtime/ArrayPrototype.cpp:
1344         (JSC::arrayProtoFuncSplice):
1345
1346 2016-09-13  Michael Saboff  <msaboff@apple.com>
1347
1348         Promises aren't resolved properly when making a ObjC API callback
1349         https://bugs.webkit.org/show_bug.cgi?id=161929
1350
1351         Reviewed by Geoffrey Garen.
1352
1353         When we go to call out to an Objective C function registered via the API,
1354         we first drop all JSC locks to make the call.  As part of dropping the locks,
1355         we drain the microtask queue that is used among other things for handling deferred
1356         promise resolution.  The DropAllLocks scope class that drops the locks while in
1357         scope, resets the current thread's AtomicStringTable to the default table.  This
1358         is wrong for two reasons, first it happens before we drain the microtask queue and
1359         second it isn't needed as JSLock::willReleaseLock() restores the current thread's
1360         AtomicStringTable to the table before the lock was acquired.
1361
1362         In fact, the manipulation of the current thread's AtomicStringTable is already 
1363         properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock().
1364         Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor
1365         and destructor should be removed.
1366
1367         * API/tests/testapi.mm:
1368         (testObjectiveCAPIMain): Added a new test.
1369         * runtime/JSLock.cpp:
1370         (JSC::JSLock::DropAllLocks::DropAllLocks):
1371         (JSC::JSLock::DropAllLocks::~DropAllLocks):
1372
1373 2016-09-13  Filip Pizlo  <fpizlo@apple.com>
1374
1375         Remove Heap::isLive()
1376         https://bugs.webkit.org/show_bug.cgi?id=161933
1377
1378         Reviewed by Mark Lam.
1379         
1380         Before I put any more effort into maintaining this weird function, I decided to check how it
1381         was used. It turns out it's not.
1382
1383         * heap/Heap.h:
1384         * heap/HeapInlines.h:
1385         (JSC::Heap::isLive): Deleted.
1386
1387 2016-09-13  Mark Lam  <mark.lam@apple.com>
1388
1389         DFG NewArrayBuffer node should watch for "have a bad time" state change.
1390         https://bugs.webkit.org/show_bug.cgi?id=161927
1391         <rdar://problem/27995222>
1392
1393         Reviewed by Geoffrey Garen.
1394
1395         * dfg/DFGFixupPhase.cpp:
1396         (JSC::DFG::FixupPhase::fixupNode):
1397
1398 2016-09-13  JF Bastien  <jfbastien@apple.com>
1399
1400         Support jsc shell builtin `read`
1401         https://bugs.webkit.org/show_bug.cgi?id=161662
1402
1403         Reviewed by Keith Miller.
1404
1405         The jsc shell currently supports a `readFile` method which returns
1406         a string. SpiderMonkey's js shell and V8's d8 shell both support
1407         similar file-to-string functions, as well as a
1408         binary-file-to-Uint8Array function. jsc should support a similar
1409         binary file method to simplify testing, including testing of
1410         WebAssembly blobs.
1411
1412         Emscripten's shell.js (which is also used for some WebAssembly
1413         things) has a polyfill [1] for a builtin called `read`. jsc should
1414         therefore have a builtin with the same name if we want things to
1415         "Just Work".
1416
1417           [1]: https://github.com/kripken/emscripten/blob/5f0918409a1407dd168f57cfa34b109cd1770a8a/src/shell.js#L138
1418
1419         * jsc.cpp:
1420         (GlobalObject::finishCreation): add `read`, make `readFile` take up to 2 arguments.
1421         (functionReadFile): support binary files, as per SpiderMonkey.
1422         * runtime/Error.h:
1423         (JSC::throwVMError): convenience function, I'll add more uses in a follow-up
1424         * runtime/JSTypedArrays.cpp:
1425         (JSC::createUint8TypedArray): JS private export of JSUint8Array::create.
1426         * runtime/JSTypedArrays.h: expose private export.
1427
1428 2016-09-12  Skachkov Oleksandr  <gskachkov@gmail.com>
1429
1430         ES6: Classes: Should be allowed to create a static method with name "arguments"
1431         https://bugs.webkit.org/show_bug.cgi?id=152985
1432
1433         Reviewed by Keith Miller.
1434
1435         Current patch covered 16.2 Forbidden Extensions - first topic 
1436         (https://tc39.github.io/ecma262/#sec-forbidden-extensions) ECMAScript Functions 
1437         should not have own properties named "caller" or "arguments".
1438         Also added possibility to declare static methods and getters with 
1439         name 'arguments' and 'caller' for classes. i.e.:
1440         class A { static arguments() { return 'value'; } }
1441         A.arguments() === 'value';
1442         To implement this patch 'caller' and 'arguments' were put to the FunctionPrototype
1443         object. Also was changed approach to init throwTypeErrorArgumentsCalleeAndCallerGetterSetter
1444         property from Lazy to common because it necessary to use execState during init of the accessors 
1445         properties.
1446
1447         * runtime/Executable.h:
1448         * runtime/FunctionPrototype.cpp:
1449         (JSC::FunctionPrototype::initRestrictedProperties):
1450         (JSC::FunctionPrototype::addFunctionProperties): Deleted.
1451         * runtime/FunctionPrototype.h:
1452         * runtime/JSFunction.cpp:
1453         (JSC::JSFunction::getOwnPropertySlot):
1454         (JSC::JSFunction::getOwnNonIndexPropertyNames):
1455         (JSC::JSFunction::put):
1456         (JSC::JSFunction::deleteProperty):
1457         (JSC::JSFunction::defineOwnProperty):
1458         * runtime/JSGlobalObject.cpp:
1459         (JSC::JSGlobalObject::init):
1460         (JSC::JSGlobalObject::visitChildren):
1461         * runtime/JSGlobalObject.h:
1462         (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):
1463
1464 2016-09-12  Filip Pizlo  <fpizlo@apple.com>
1465
1466         MarkedBlock should be able to use flipIfNecessary() as the "I'm not empty" trigger
1467         https://bugs.webkit.org/show_bug.cgi?id=161869
1468
1469         Reviewed by Saam Barati.
1470         
1471         In bug 161581, I'm going to use flipIfNecessary() during marking to trigger the "I'm not
1472         empty" hook, which will set a bit in the markingNotEmpty bitvector.
1473         
1474         For this to work, we need to ensure that nobody else uses flipIfNecessary() during marking.
1475         If anyone else does it but they aren't marking new objects, then this prevents
1476         flipIfNecessary() from triggering when the first object is marked, which means we won't
1477         always detect when a block became non-empty.
1478         
1479         I addressed this by adding a isMarking flag, and asserting in flipIfNecessary() that the flag
1480         isn't set. flipIfNecessaryDuringMarking() is used only on the marking path, so that code
1481         knows that it can trigger something like noteMarked(). The only places that were using
1482         flipIfNecessary() should have been using needsFlip() anyway.
1483
1484         * heap/CellContainer.h:
1485         * heap/CellContainerInlines.h:
1486         (JSC::CellContainer::needsFlip):
1487         * heap/Heap.cpp:
1488         (JSC::Heap::markRoots):
1489         (JSC::Heap::beginMarking):
1490         (JSC::Heap::endMarking):
1491         (JSC::Heap::clearLivenessData): Deleted.
1492         (JSC::Heap::converge): Deleted.
1493         (JSC::Heap::resetVisitors): Deleted.
1494         * heap/Heap.h:
1495         * heap/HeapInlines.h:
1496         (JSC::Heap::testAndSetMarked):
1497         * heap/LargeAllocation.h:
1498         (JSC::LargeAllocation::flipIfNecessaryDuringMarking):
1499         (JSC::LargeAllocation::flipIfNecessaryConcurrently): Deleted.
1500         * heap/MarkedBlock.cpp:
1501         (JSC::MarkedBlock::flipIfNecessarySlow):
1502         (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow):
1503         (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow): Deleted.
1504         * heap/MarkedBlock.h:
1505         (JSC::MarkedBlock::flipIfNecessaryDuringMarking):
1506         (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking):
1507         (JSC::MarkedBlock::flipIfNecessaryConcurrently): Deleted.
1508         (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently): Deleted.
1509         * heap/MarkedSpace.h:
1510         (JSC::MarkedSpace::isMarking):
1511         (JSC::MarkedSpace::setIsMarking):
1512         (JSC::MarkedSpace::largeAllocationsForThisCollectionSize): Deleted.
1513         * heap/SlotVisitor.cpp:
1514         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
1515         * heap/WeakBlock.cpp:
1516         (JSC::WeakBlock::visit):
1517
1518 2016-09-12  Saam Barati  <sbarati@apple.com>
1519
1520         HashMapImpl should take into account m_deleteCount in its load factor and it should be able to rehash the table to be smaller
1521         https://bugs.webkit.org/show_bug.cgi?id=161640
1522
1523         Reviewed by Geoffrey Garen.
1524
1525         HashMapImpl now takes into account m_deleteCount in its load factor.
1526         It now knows how to rehash to either decrease its capacity, stay at
1527         the same capacity, or increase its capacity. The reason we can sometimes
1528         stay at the same capacity is that we can reduce the load factor enough
1529         by rehashing that growing isn't warranted. The reason for this is that
1530         anytime we rehash, we remove all deleted sentinels from the buffer.
1531         Therefore, staying at the same same capacity, when there are deleted entries,
1532         can still reduce the load factor because it removes all deleted sentinels.
1533
1534         * runtime/HashMapImpl.h:
1535         (JSC::HashMapBuffer::create):
1536         (JSC::HashMapBuffer::reset):
1537         (JSC::HashMapImpl::HashMapImpl):
1538         (JSC::HashMapImpl::add):
1539         (JSC::HashMapImpl::remove):
1540         (JSC::HashMapImpl::size):
1541         (JSC::HashMapImpl::clear):
1542         (JSC::HashMapImpl::approximateSize):
1543         (JSC::HashMapImpl::shouldRehashAfterAdd):
1544         (JSC::HashMapImpl::shouldShrink):
1545         (JSC::HashMapImpl::rehash):
1546         (JSC::HashMapImpl::checkConsistency):
1547         (JSC::HashMapImpl::makeAndSetNewBuffer):
1548         (JSC::HashMapImpl::assertBufferIsEmpty):
1549
1550 2016-09-12  Benjamin Poulain  <bpoulain@apple.com>
1551
1552         [JSC] Use GetArrayLength for JSArray.length even when the array type is undecided
1553         https://bugs.webkit.org/show_bug.cgi?id=161671
1554
1555         Reviewed by Geoffrey Garen.
1556
1557         UndecidedShape is a type with storage. When we allocate an uninitialized JSArray,
1558         it gets a butterfly with its length.
1559         When we were querying that length, we were generating a generic GetById with inline cache.
1560
1561         This patch adds the missing bits to treat Undecided like the other types with storage.
1562
1563         * dfg/DFGArrayMode.cpp:
1564         (JSC::DFG::canBecomeGetArrayLength):
1565         (JSC::DFG::ArrayMode::refine):
1566         * dfg/DFGArrayMode.h:
1567         (JSC::DFG::ArrayMode::usesButterfly):
1568         (JSC::DFG::ArrayMode::lengthNeedsStorage):
1569         * dfg/DFGClobberize.h:
1570         (JSC::DFG::clobberize):
1571         * dfg/DFGFixupPhase.cpp:
1572         (JSC::DFG::FixupPhase::checkArray):
1573         * dfg/DFGSpeculativeJIT.cpp:
1574         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
1575         * ftl/FTLCapabilities.cpp:
1576         (JSC::FTL::canCompile):
1577         * ftl/FTLLowerDFGToB3.cpp:
1578         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
1579
1580 2016-09-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1581
1582         [DFG][FTL] Add ArithTan
1583         https://bugs.webkit.org/show_bug.cgi?id=161857
1584
1585         Reviewed by Filip Pizlo.
1586
1587         While ArithSin and ArithCos are supported, ArithTan is not supported yet.
1588         And we also find that Math.tan is included in MotionMark's Multiply benchmark.
1589
1590         This patch adds ArithTan support in DFG and FTL. And it also cleans up the
1591         existing ArithSin, ArithCos, and ArithLog compilations by unifying them.
1592         The microbenchmark shows the 9% perf improvement.
1593
1594             tan    322.4819+-0.3766     ^    295.8700+-0.3094        ^ definitely 1.0899x faster
1595
1596         * dfg/DFGAbstractInterpreterInlines.h:
1597         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1598         * dfg/DFGByteCodeParser.cpp:
1599         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1600         * dfg/DFGClobberize.h:
1601         (JSC::DFG::clobberize):
1602         * dfg/DFGDoesGC.cpp:
1603         (JSC::DFG::doesGC):
1604         * dfg/DFGFixupPhase.cpp:
1605         (JSC::DFG::FixupPhase::fixupNode):
1606         * dfg/DFGNodeType.h:
1607         * dfg/DFGOperations.cpp:
1608         * dfg/DFGOperations.h:
1609         * dfg/DFGPredictionPropagationPhase.cpp:
1610         * dfg/DFGSafeToExecute.h:
1611         (JSC::DFG::safeToExecute):
1612         * dfg/DFGSpeculativeJIT.cpp:
1613         (JSC::DFG::SpeculativeJIT::compileArithDoubleUnaryOp):
1614         (JSC::DFG::SpeculativeJIT::compileArithCos):
1615         (JSC::DFG::SpeculativeJIT::compileArithTan):
1616         (JSC::DFG::SpeculativeJIT::compileArithSin):
1617         (JSC::DFG::SpeculativeJIT::compileArithLog):
1618         * dfg/DFGSpeculativeJIT.h:
1619         * dfg/DFGSpeculativeJIT32_64.cpp:
1620         (JSC::DFG::SpeculativeJIT::compile):
1621         * dfg/DFGSpeculativeJIT64.cpp:
1622         (JSC::DFG::SpeculativeJIT::compile):
1623         * ftl/FTLCapabilities.cpp:
1624         (JSC::FTL::canCompile):
1625         * ftl/FTLLowerDFGToB3.cpp:
1626         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1627         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan):
1628         * ftl/FTLOutput.cpp:
1629         (JSC::FTL::Output::doubleTan):
1630         * ftl/FTLOutput.h:
1631         * runtime/Intrinsic.h:
1632         * runtime/MathObject.cpp:
1633         (JSC::MathObject::finishCreation):
1634
1635 2016-09-12  Saam Barati  <sbarati@apple.com>
1636
1637         MapHash should do constant folding when it has a constant argument and its legal to hash that value
1638         https://bugs.webkit.org/show_bug.cgi?id=161639
1639
1640         Reviewed by Filip Pizlo.
1641
1642         We now constant fold the MapHash node. We're careful to not resolve
1643         ropes from the compiler thread, and to only hash strings if they're
1644         not too large. The microbenchmark I added runs about 12% faster with
1645         this patch.
1646
1647         * dfg/DFGAbstractInterpreterInlines.h:
1648         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1649         * runtime/HashMapImpl.h:
1650         (JSC::wangsInt64Hash):
1651         (JSC::jsMapHash):
1652         (JSC::concurrentJSMapHash):
1653
1654 2016-09-11  Filip Pizlo  <fpizlo@apple.com>
1655
1656         DFG::forAllKilledOperands() could use a faster bitvector scan in the same-inline-stack fast path
1657         https://bugs.webkit.org/show_bug.cgi?id=161849
1658
1659         Reviewed by Saam Barati.
1660         
1661         This is a fairly obvious change. This turns a loop that would query each bit individually
1662         into a loop that will process a word at a time. I would expect a very tiny progression in
1663         DFG compile times.
1664         
1665         This also gave me an opportunity to test and fix the new FastBitVector functionality.
1666
1667         * dfg/DFGForAllKills.h:
1668         (JSC::DFG::forAllKilledOperands):
1669
1670 2016-09-11  Filip Pizlo  <fpizlo@apple.com>
1671
1672         FastBitVector should have efficient and easy-to-use vector-vector operations
1673         https://bugs.webkit.org/show_bug.cgi?id=161847
1674
1675         Reviewed by Saam Barati.
1676         
1677         Adapt existing users of FastBitVector to the new API.
1678
1679         * bytecode/BytecodeLivenessAnalysis.cpp:
1680         (JSC::BytecodeLivenessAnalysis::computeKills):
1681         (JSC::BytecodeLivenessAnalysis::dumpResults):
1682         * bytecode/BytecodeLivenessAnalysisInlines.h:
1683         (JSC::operandThatIsNotAlwaysLiveIsLive):
1684         (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
1685         (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint):
1686         * bytecode/CodeBlock.cpp:
1687         (JSC::CodeBlock::validate):
1688         * dfg/DFGByteCodeParser.cpp:
1689         (JSC::DFG::ByteCodeParser::flushForTerminal):
1690         * dfg/DFGForAllKills.h:
1691         (JSC::DFG::forAllKilledOperands):
1692         * dfg/DFGGraph.h:
1693         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
1694         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
1695         (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException):
1696         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
1697         * dfg/DFGNaturalLoops.cpp:
1698         (JSC::DFG::NaturalLoops::NaturalLoops):
1699         * dfg/DFGPlan.cpp:
1700         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
1701
1702 2016-09-10  Chris Dumez  <cdumez@apple.com>
1703
1704         parseHTMLInteger() should take a StringView in parameter
1705         https://bugs.webkit.org/show_bug.cgi?id=161669
1706
1707         Reviewed by Ryosuke Niwa.
1708
1709         * runtime/DateConversion.cpp:
1710         (JSC::formatDateTime):
1711         Explicitly construct a String from the const WCHAR* on Windows because
1712         it is ambiguous otherwise now that there is a StringBuilder::append()
1713         overload taking an AtomicString in.
1714
1715 2016-09-08  Keith Miller  <keith_miller@apple.com>
1716
1717         WASM should support if-then-else
1718         https://bugs.webkit.org/show_bug.cgi?id=161778
1719
1720         Reviewed by Michael Saboff.
1721
1722         This patch makes some major changes to the way that the WASM
1723         function parser works. First, the control stack has been moved
1724         from the parser's context to the parser itself. This simplifies
1725         the way that the parser works and allows us to make the decoder
1726         iterative rather than recursive. Since the control stack has been
1727         moved to the parser, any context operation that refers to some
1728         block now receives that block by reference.
1729
1730         For any if block, regardless of whether or not it is an
1731         if-then-else or not, we will allocate both the entire control flow
1732         diamond. This is not a major issue in the if-then case since B3
1733         will immediately cleanup these blocks. In order to support if-then
1734         and if-then-else we needed to be able to distinguish what the type
1735         of the top block on the control stack is. This will be necessary
1736         when validating the else opcode in the future. In the B3 IR
1737         generator we decide to the type of the block strictly by the
1738         shape.
1739
1740         Currently, if blocks don't handle passed and returned stack values
1741         correctly. I plan to fix this when I add support for the block
1742         signatures. See: https://github.com/WebAssembly/design/pull/765
1743
1744         * testWASM.cpp:
1745         (runWASMTests):
1746         * wasm/WASMB3IRGenerator.cpp:
1747         (dumpProcedure):
1748         (JSC::WASM::parseAndCompile):
1749         * wasm/WASMB3IRGenerator.h:
1750         * wasm/WASMFunctionParser.h:
1751         (JSC::WASM::FunctionParser<Context>::parseBlock):
1752         (JSC::WASM::FunctionParser<Context>::parseExpression):
1753         (JSC::WASM::FunctionParser<Context>::parseUnreachableExpression):
1754         * wasm/WASMOps.h:
1755
1756 2016-09-09  Filip Pizlo  <fpizlo@apple.com>
1757
1758         jsc.cpp should call initializeMainThread() to make sure that GC thread assertions work
1759         https://bugs.webkit.org/show_bug.cgi?id=161801
1760
1761         Reviewed by Keith Miller.
1762         
1763         The GC has debug assertions that certain things don't happen on GC threads. Those assertions
1764         are no-ops unless initializeGCThreads() is called, and I think the most canonical way to do
1765         that is to call initializeMainThread().
1766
1767         * jsc.cpp:
1768         (jscmain):
1769
1770 2016-09-09  Saam Barati  <sbarati@apple.com>
1771
1772         Make hasOwnProperty ALWAYS_INLINE
1773         https://bugs.webkit.org/show_bug.cgi?id=161775
1774
1775         Reviewed by Ryosuke Niwa.
1776
1777         Speedometer spends around 2.5% of its time in hasOwnProperty.
1778         Let's reduce the overhead of calling that function by marking
1779         it as inline. Also, it's likely that the function will call into
1780         JSObject::getOwnPropertySlot. I added a check to see if that's
1781         the function we're calling, if it is, we do a direct call instead
1782         of an indirect call.
1783
1784         * runtime/JSObject.cpp:
1785         (JSC::JSObject::hasOwnProperty): Deleted.
1786         * runtime/JSObjectInlines.h:
1787         (JSC::JSObject::hasOwnProperty):
1788
1789 2016-09-09  Filip Pizlo  <fpizlo@apple.com>
1790
1791         HashMapImpl needs to m_buffer.clear() in its constructor
1792         https://bugs.webkit.org/show_bug.cgi?id=161796
1793
1794         Reviewed by Keith Miller.
1795         
1796         This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize
1797         itself. That seemed like a good idea because maybe sometimes the user knows better how to
1798         initialize it. But, it's not worth it if it's a constant source of bugs.
1799         
1800         So, I'm fixing it for good by making AuxiliaryBarrier::AuxiliaryBarrier() initialize its
1801         m_value.
1802
1803         * runtime/AuxiliaryBarrier.h:
1804         (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
1805         * runtime/DirectArguments.cpp:
1806         (JSC::DirectArguments::DirectArguments):
1807
1808 2016-09-09  Youenn Fablet  <youenn@apple.com>
1809
1810         ASSERTION FAILED: promise.inherits(JSPromise::info())
1811         https://bugs.webkit.org/show_bug.cgi?id=161632
1812         <rdar://problem/28184743>
1813
1814         Reviewed by Mark Lam.
1815
1816         * runtime/JSPromiseDeferred.cpp:
1817         (JSC::JSPromiseDeferred::create): Returning null if promise object is not created.
1818
1819 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
1820
1821         Heap::isMarked() shouldn't pay the price of concurrent lazy flipping
1822         https://bugs.webkit.org/show_bug.cgi?id=161760
1823
1824         Reviewed by Mark Lam.
1825         
1826         To fix a race condition in marking, I made Heap::isMarked() and Heap::isLive() atomic by
1827         using flipIfNecessaryConcurrently() instead of flipIfNecessary().
1828         
1829         This introduces three unnecessary overheads:
1830         
1831         - isLive() is not called by marking, so that change was not necessary.
1832         
1833         - isMarked() gets calls many times outside of marking, so it shouldn't always do the
1834           concurrent thing. This adds isMarkedConcurrently() for use in marking, and reverts
1835           isMarked().
1836         
1837         - isMarked() and isMarkedConcurrently() don't actually have to do the lazy flip. They can
1838           return false if the flip is necessary.
1839         
1840         I added a bunch of debug assertions to make sure that isLive() and isMarked() are not called
1841         during marking.
1842         
1843         If we needed to, we could remove most of the calls to isMarkedConcurrently(). As a kind of
1844         optimization, CodeBlock does an initial fixpoint iteration during marking, and so all of the
1845         code called from CodeBlock's fixpoint iterator needs to use isMarkedConcurrently(). But we
1846         could probably arrange for CodeBlock only do fixpoint iterating during the weak reference
1847         thing.
1848
1849         * bytecode/CodeBlock.cpp:
1850         (JSC::CodeBlock::visitWeakly):
1851         (JSC::CodeBlock::shouldJettisonDueToOldAge):
1852         (JSC::shouldMarkTransition):
1853         (JSC::CodeBlock::propagateTransitions):
1854         (JSC::CodeBlock::determineLiveness):
1855         * bytecode/PolymorphicAccess.cpp:
1856         (JSC::AccessCase::propagateTransitions):
1857         * heap/Heap.h:
1858         * heap/HeapInlines.h:
1859         (JSC::Heap::isLive):
1860         (JSC::Heap::isMarked):
1861         (JSC::Heap::isMarkedConcurrently):
1862         * heap/MarkedBlock.cpp:
1863         (JSC::MarkedBlock::flipIfNecessarySlow):
1864         (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
1865         (JSC::MarkedBlock::needsFlip):
1866         * heap/MarkedBlock.h:
1867         (JSC::MarkedBlock::needsFlip):
1868         (JSC::MarkedBlock::flipIfNecessary):
1869         (JSC::MarkedBlock::flipIfNecessaryConcurrently):
1870         * heap/SlotVisitor.cpp:
1871         (JSC::SlotVisitor::appendToMarkStack):
1872         (JSC::SlotVisitor::markAuxiliary):
1873         (JSC::SlotVisitor::visitChildren):
1874         * runtime/Structure.cpp:
1875         (JSC::Structure::isCheapDuringGC):
1876         (JSC::Structure::markIfCheap):
1877
1878 2016-09-08  Saam Barati  <sbarati@apple.com>
1879
1880         We should inline operationConvertJSValueToBoolean into JIT code
1881         https://bugs.webkit.org/show_bug.cgi?id=161729
1882
1883         Reviewed by Filip Pizlo.
1884
1885         This patch introduces an AssemblyHelpers emitter function
1886         that replaces operationConvertJSValueToBoolean. This operation
1887         was showing up when I was doing performance analysis for the
1888         speedometer benchmark. I saw that it was spending about 1% of
1889         its time in this function. Hopefully this patch can help us speedup
1890         up speedometer by a little bit.
1891
1892         * dfg/DFGSpeculativeJIT32_64.cpp:
1893         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
1894         (JSC::DFG::SpeculativeJIT::emitBranch):
1895         * dfg/DFGSpeculativeJIT64.cpp:
1896         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
1897         (JSC::DFG::SpeculativeJIT::emitBranch):
1898         * jit/AssemblyHelpers.cpp:
1899         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
1900         * jit/AssemblyHelpers.h:
1901         (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted.
1902         * jit/JIT.cpp:
1903         (JSC::JIT::privateCompileSlowCases):
1904         * jit/JIT.h:
1905         * jit/JITOpcodes.cpp:
1906         (JSC::JIT::emit_op_jfalse):
1907         (JSC::JIT::emit_op_jtrue):
1908         (JSC::JIT::emitSlow_op_jfalse): Deleted.
1909         (JSC::JIT::emitSlow_op_jtrue): Deleted.
1910         * jit/JITOpcodes32_64.cpp:
1911         (JSC::JIT::emit_op_jfalse):
1912         (JSC::JIT::emit_op_jtrue):
1913         (JSC::JIT::emitSlow_op_jfalse): Deleted.
1914         (JSC::JIT::emitSlow_op_jtrue): Deleted.
1915         * jit/JITOperations.cpp:
1916         * jit/JITOperations.h:
1917
1918 2016-09-08  Chris Dumez  <cdumez@apple.com>
1919
1920         Align proto getter / setter behavior with other browsers
1921         https://bugs.webkit.org/show_bug.cgi?id=161455
1922
1923         Reviewed by Saam Barati.
1924
1925         Drop allowsAccessFrom from the methodTable and delegate cross-origin
1926         checking to the DOM bindings for [[SetPrototypeOf]] / [[GetPrototypeOf]].
1927         This is more consistent with other operations (e.g. [[GetOwnProperty]]).
1928
1929         * jsc.cpp:
1930         * runtime/JSGlobalObject.cpp:
1931         * runtime/JSGlobalObject.h:
1932         * runtime/JSGlobalObjectFunctions.cpp:
1933         (JSC::globalFuncProtoGetter):
1934         (JSC::globalFuncProtoSetter):
1935         (JSC::globalFuncBuiltinLog): Deleted.
1936         * runtime/JSGlobalObjectFunctions.h:
1937         * runtime/JSObject.cpp:
1938         (JSC::JSObject::setPrototypeWithCycleCheck):
1939         Remove check added in r197648. This check was added to match
1940         the latest EcmaScript spec:
1941         - https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof (step 8)
1942         This check allowed for [[Prototype]] chain cycles if the prototype
1943         chain includes objects that do not use the ordinary object definitions
1944         for [[GetPrototypeOf]] and [[SetPrototypeOf]].
1945         The issue is that the rest of our code base does not properly handle
1946         such cycles and we can end up in infinite loops. This became obvious
1947         because this patch updates Window / Location so that they no longer
1948         use the default [[GetPrototypeOf]] / [[SetPrototypeOf]]. If I do not
1949         remove this check, I get an infinite loop in
1950         Structure::anyObjectInChainMayInterceptIndexedAccesses(), which is
1951         called from JSObject::setPrototypeDirect(), when running the following
1952         layout test:
1953         - html/browsers/history/the-location-interface/allow_prototype_cycle_through_location.sub.html
1954         I filed https://bugs.webkit.org/show_bug.cgi?id=161534 to track this
1955         issue.
1956
1957         * runtime/JSObject.h:
1958         (JSC::JSObject::getArrayLength): Deleted.
1959         * runtime/JSProxy.cpp:
1960         (JSC::JSProxy::setPrototype):
1961         (JSC::JSProxy::getPrototype):
1962         * runtime/JSProxy.h:
1963         * runtime/ObjectConstructor.cpp:
1964         (JSC::objectConstructorGetPrototypeOf):
1965         (JSC::objectConstructorSetPrototypeOf):
1966         (JSC::objectConstructorGetOwnPropertyDescriptor): Deleted.
1967         (JSC::objectConstructorGetOwnPropertyDescriptors): Deleted.
1968         * runtime/ObjectConstructor.h:
1969         * runtime/ReflectObject.cpp:
1970         (JSC::reflectObjectGetPrototypeOf):
1971         (JSC::reflectObjectSetPrototypeOf):
1972
1973 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
1974
1975         Remove CopiedSpace and use MarkedSpace instead
1976         https://bugs.webkit.org/show_bug.cgi?id=159658
1977
1978         Reviewed by Keith Miller.
1979         
1980         This removes the final client of CopiedSpace, the overrides array of DirectArguments. That
1981         is a simple change.
1982         
1983         Then this stubs out some remaining internal debugging code that referenced CopiedSpace in
1984         JSDollarVM and HeapVerifier. I filed FIXMEs to restore that debugging functionality.
1985         
1986         The rest of this patch is deleting CopiedSpace.
1987
1988         * API/JSObjectRef.cpp:
1989         * CMakeLists.txt:
1990         * JavaScriptCore.xcodeproj/project.pbxproj:
1991         * dfg/DFGOperations.cpp:
1992         * heap/ConservativeRoots.cpp:
1993         (JSC::ConservativeRoots::genericAddPointer):
1994         * heap/CopiedAllocator.h: Removed.
1995         * heap/CopiedBlock.cpp: Removed.
1996         * heap/CopiedBlock.h: Removed.
1997         * heap/CopiedBlockInlines.h: Removed.
1998         * heap/CopiedSpace.cpp: Removed.
1999         * heap/CopiedSpace.h: Removed.
2000         * heap/CopiedSpaceInlines.h: Removed.
2001         * heap/CopyBarrier.h: Removed.
2002         * heap/CopyToken.h: Removed.
2003         * heap/CopyVisitor.cpp: Removed.
2004         * heap/CopyVisitor.h: Removed.
2005         * heap/CopyVisitorInlines.h: Removed.
2006         * heap/CopyWorkList.h: Removed.
2007         * heap/Heap.cpp:
2008         (JSC::Heap::Heap):
2009         (JSC::Heap::isPagedOut):
2010         (JSC::Heap::updateObjectCounts):
2011         (JSC::Heap::size):
2012         (JSC::Heap::capacity):
2013         (JSC::Heap::collectImpl):
2014         (JSC::Heap::stopAllocation):
2015         (JSC::Heap::updateAllocationLimits):
2016         (JSC::Heap::copyBackingStores): Deleted.
2017         (JSC::Heap::threadBytesCopied): Deleted.
2018         * heap/Heap.h:
2019         (JSC::Heap::objectSpace):
2020         (JSC::Heap::allocatorForAuxiliaryData):
2021         (JSC::Heap::storageSpace): Deleted.
2022         (JSC::Heap::storageAllocator): Deleted.
2023         * heap/HeapCellInlines.h:
2024         * heap/HeapInlines.h:
2025         (JSC::Heap::tryAllocateStorage): Deleted.
2026         (JSC::Heap::tryReallocateStorage): Deleted.
2027         * heap/HeapVerifier.cpp:
2028         (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
2029         (JSC::HeapVerifier::reportObject):
2030         (JSC::getButterflyDetails): Deleted.
2031         * heap/SlotVisitor.cpp:
2032         (JSC::SlotVisitor::copyLater): Deleted.
2033         * heap/SlotVisitor.h:
2034         * jit/AssemblyHelpers.h:
2035         * jit/JITOpcodes.cpp:
2036         * jsc.cpp:
2037         * runtime/ArrayConstructor.cpp:
2038         * runtime/ArrayPrototype.cpp:
2039         * runtime/Butterfly.h:
2040         * runtime/ButterflyInlines.h:
2041         (JSC::Butterfly::createUninitializedDuringCollection): Deleted.
2042         * runtime/ClassInfo.h:
2043         * runtime/DirectArguments.cpp:
2044         (JSC::DirectArguments::visitChildren):
2045         (JSC::DirectArguments::overrideThings):
2046         (JSC::DirectArguments::copyBackingStore): Deleted.
2047         * runtime/DirectArguments.h:
2048         * runtime/JSArray.cpp:
2049         * runtime/JSCell.cpp:
2050         (JSC::JSCell::copyBackingStore): Deleted.
2051         * runtime/JSCell.h:
2052         * runtime/JSLexicalEnvironment.h:
2053         * runtime/JSObject.cpp:
2054         * runtime/JSTypedArrays.cpp:
2055         * runtime/LiteralParser.cpp:
2056         * runtime/ObjectConstructor.cpp:
2057         * runtime/RegExpObject.cpp:
2058         * runtime/StringPrototype.cpp:
2059         * runtime/WeakMapData.cpp:
2060         * tools/JSDollarVMPrototype.cpp:
2061         (JSC::JSDollarVMPrototype::isInStorageSpace):
2062
2063 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2064
2065         Heap version should be 32-bit
2066         https://bugs.webkit.org/show_bug.cgi?id=161751
2067
2068         Reviewed by Mark Lam.
2069         
2070         32-bit devices are probably getting hurt by the 64-bit version number. The reason why I made
2071         it 64-bit initially is so that I wouldn't have to worry about wrap-around. But wrap-around is
2072         easy to handle.
2073
2074         * heap/CellContainer.h:
2075         * heap/CellContainerInlines.h:
2076         (JSC::CellContainer::flipIfNecessary):
2077         * heap/ConservativeRoots.cpp:
2078         (JSC::ConservativeRoots::genericAddPointer):
2079         (JSC::ConservativeRoots::genericAddSpan):
2080         * heap/ConservativeRoots.h:
2081         * heap/Heap.h:
2082         * heap/HeapInlines.h:
2083         (JSC::Heap::testAndSetMarked):
2084         * heap/HeapUtil.h:
2085         (JSC::HeapUtil::findGCObjectPointersForMarking):
2086         * heap/MarkedBlock.cpp:
2087         (JSC::MarkedBlock::MarkedBlock):
2088         * heap/MarkedBlock.h:
2089         (JSC::MarkedBlock::flipIfNecessary):
2090         (JSC::MarkedBlock::flipIfNecessaryConcurrently):
2091         (JSC::MarkedBlock::Handle::flipIfNecessary):
2092         (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
2093         * heap/MarkedSpace.cpp:
2094         (JSC::MarkedSpace::flip):
2095         * heap/MarkedSpace.h:
2096         (JSC::MarkedSpace::version):
2097         * heap/SlotVisitor.cpp:
2098         (JSC::SlotVisitor::SlotVisitor):
2099         * heap/SlotVisitor.h:
2100
2101 2016-09-08  Mark Lam  <mark.lam@apple.com>
2102
2103         Add support for a ternary sub32 emitter for ARM64 and 32-bit ARM.
2104         https://bugs.webkit.org/show_bug.cgi?id=161724
2105
2106         Reviewed by Filip Pizlo.
2107
2108         ARM architectures support ternary sub instructions.  We should make use of them
2109         in emitAllocateWithNonNullAllocator().
2110
2111         * assembler/MacroAssemblerARM.h:
2112         (JSC::MacroAssemblerARM::sub32):
2113         * assembler/MacroAssemblerARM64.h:
2114         (JSC::MacroAssemblerARM64::sub32):
2115         * assembler/MacroAssemblerARMv7.h:
2116         (JSC::MacroAssemblerARMv7::sub32):
2117         * assembler/MacroAssemblerSH4.h:
2118         (JSC::MacroAssemblerSH4::sub32):
2119         * assembler/MacroAssemblerX86Common.h:
2120         (JSC::MacroAssemblerX86Common::sub32):
2121         * b3/air/AirOpcode.opcodes:
2122         * b3/testb3.cpp:
2123         (JSC::B3::testTernarySubInstructionSelection):
2124         (JSC::B3::run):
2125         * jit/AssemblyHelpers.h:
2126         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
2127
2128 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2129
2130         Move JSMap/JSSet over to Auxiliary MarkedSpace
2131         https://bugs.webkit.org/show_bug.cgi?id=161744
2132
2133         Reviewed by Saam Barati.
2134         
2135         This moves the buffer out of CopiedSpace and into Auxiliary MarkedSpace.
2136         
2137         Also removes MapData.h/MapDataInlines.h since they are not used anywhere, but they still
2138         speak of CopiedSpace.
2139         
2140         This is a purely mechanical change.
2141
2142         * JavaScriptCore.xcodeproj/project.pbxproj:
2143         * heap/CopyToken.h:
2144         * runtime/HashMapImpl.cpp:
2145         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
2146         (JSC::HashMapImpl<HashMapBucket>::copyBackingStore): Deleted.
2147         * runtime/HashMapImpl.h:
2148         (JSC::HashMapBuffer::create):
2149         * runtime/JSMapIterator.cpp:
2150         * runtime/JSMapIterator.h:
2151         * runtime/JSSetIterator.cpp:
2152         * runtime/JSSetIterator.h:
2153         * runtime/MapBase.cpp:
2154         * runtime/MapData.h: Removed.
2155         * runtime/MapDataInlines.h: Removed.
2156         * runtime/MapPrototype.cpp:
2157         * runtime/SetConstructor.cpp:
2158         * runtime/SetPrototype.cpp:
2159         * runtime/VM.cpp:
2160
2161 2016-09-06  Filip Pizlo  <fpizlo@apple.com>
2162
2163         Typed arrays should use MarkedSpace instead of CopiedSpace
2164         https://bugs.webkit.org/show_bug.cgi?id=161100
2165
2166         Reviewed by Geoffrey Garen.
2167         
2168         This moves typed array backing stores out of CopiedSpace and into Auxiliary MarkedSpace.
2169         
2170         This is a purely mechanical change since Auxiliary MarkedSpace already knows how to do
2171         everything that typed arrays want.
2172
2173         * dfg/DFGOperations.cpp:
2174         (JSC::DFG::newTypedArrayWithSize):
2175         * dfg/DFGOperations.h:
2176         (JSC::DFG::operationNewTypedArrayWithSizeForType):
2177         * dfg/DFGSpeculativeJIT.cpp:
2178         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
2179         * dfg/DFGSpeculativeJIT.h:
2180         (JSC::DFG::SpeculativeJIT::callOperation):
2181         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): Deleted.
2182         * ftl/FTLLowerDFGToB3.cpp:
2183         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2184         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2185         (JSC::FTL::DFG::LowerDFGToB3::splatWords):
2186         (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd): Deleted.
2187         (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorage): Deleted.
2188         * heap/CopyToken.h:
2189         * heap/SlotVisitor.cpp:
2190         (JSC::SlotVisitor::markAuxiliary):
2191         * jit/JITOperations.h:
2192         * runtime/JSArrayBufferView.cpp:
2193         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2194         (JSC::JSArrayBufferView::JSArrayBufferView):
2195         * runtime/JSArrayBufferView.h:
2196         * runtime/JSGenericTypedArrayView.h:
2197         * runtime/JSGenericTypedArrayViewInlines.h:
2198         (JSC::JSGenericTypedArrayView<Adaptor>::createWithFastVector):
2199         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2200         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
2201         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore): Deleted.
2202
2203 2016-09-08  Per Arne Vollan  <pvollan@apple.com>
2204
2205         [Win64] Compile fixes.
2206         https://bugs.webkit.org/show_bug.cgi?id=161682
2207
2208         Reviewed by Brent Fulgham.
2209
2210         * dfg/DFGSpeculativeJIT64.cpp:
2211         (JSC::DFG::SpeculativeJIT::emitCall):
2212         * jit/JITCall.cpp:
2213         (JSC::JIT::compileOpCall):
2214         * runtime/ArrayConventions.cpp:
2215         (JSC::clearArrayMemset):
2216
2217 2016-09-08  Per Arne Vollan  <pvollan@apple.com>
2218
2219         [Win] Exception fuzz tests fail
2220         https://bugs.webkit.org/show_bug.cgi?id=140928
2221
2222         Reviewed by Mark Lam.
2223
2224         Flush stdout when throwing the exception to make sure the output comes before output in the exception handler.
2225         The tests depend on the output to stdout being written in the correct order.
2226
2227         * runtime/ExceptionFuzz.cpp:
2228         (JSC::doExceptionFuzzing):
2229
2230 2016-09-07  Simon Fraser  <simon.fraser@apple.com>
2231
2232         Enable the <meter> element on iOS
2233         https://bugs.webkit.org/show_bug.cgi?id=161714
2234         rdar://problem/8978410
2235
2236         Reviewed by Tim Horton.
2237
2238         Define ENABLE_METER_ELEMENT unconditionally now.
2239
2240         * Configurations/FeatureDefines.xcconfig:
2241
2242 2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>
2243
2244         Modernize Debugger to use nullptr
2245         https://bugs.webkit.org/show_bug.cgi?id=161718
2246
2247         Reviewed by Mark Lam.
2248
2249         * debugger/Debugger.cpp:
2250         (JSC::Debugger::Debugger):
2251         (JSC::Debugger::~Debugger):
2252         (JSC::Debugger::detach):
2253         (JSC::Debugger::stepOutOfFunction):
2254         (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
2255         * debugger/Debugger.h:
2256
2257 2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>
2258
2259         Web Inspector: Remove always false case in Debugger
2260         https://bugs.webkit.org/show_bug.cgi?id=161717
2261
2262         Reviewed by Brian Burg.
2263
2264         * debugger/Debugger.cpp:
2265         (JSC::Debugger::didExecuteProgram):
2266         We would have earlier returned a few statements ago if this case was true.
2267         And we would have crashed in the previous statement if this case was true.
2268
2269 2016-09-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2270
2271         Unreviewed, build fix after r205569
2272
2273         Tweak CMakeLists.txt
2274
2275         * CMakeLists.txt:
2276
2277 2016-09-07  Mark Lam  <mark.lam@apple.com>
2278
2279         Add CatchScope and force all exception checks to be via ThrowScope or CatchScope.
2280         https://bugs.webkit.org/show_bug.cgi?id=161498
2281
2282         Reviewed by Geoffrey Garen.
2283
2284         This patch refactors the ThrowScope class, and introduces a base ExceptionScope
2285         that ThrowScope extends.  A CatchScope which extends the ExceptionScope is also
2286         introduced.
2287
2288         ENABLE(THROW_SCOPE_VERIFICATION) is now renamed to ENABLE(EXCEPTION_SCOPE_VERIFICATION)
2289         which is a more suitable name now.
2290
2291         Note: exception scope verification is still disabled by default.  There are still
2292         many places that need to be fixed up or re-expressed in a way that is friendly
2293         to the verification.  I'll address those in subsequent patches.
2294
2295         After this patch, the code will statically enforce that:
2296         1. all calls to throwException() go through a ThrowScope.
2297         2. all calls to clearException() go through a CatchScope.
2298         3. all exception checks go through an ExceptionScope in the form of a ThrowScope
2299            or CatchScope.
2300
2301         A Summary of how to use ExceptionScopes
2302         =======================================
2303         1. If a function can throw a JS exception, it should declare a ThrowScope at the
2304            top of the function (as early as possible).
2305
2306         2. If a function can clear JS exceptions, it should declare a CatchScope at the
2307            top of the function (as early as possible).
2308
2309         Declaring a ThrowScope in a function means that the function may throw an exception
2310         that its caller will have to handle.  Declaring a CatchScope in a function means
2311         that the function intends to clear pending exceptions before returning to its
2312         caller. 
2313
2314         For more details, see the notes below.
2315         
2316         Everything you may want to know about ExceptionScopes
2317         =====================================================
2318         ExceptionScope verification works to simulate exception throws and detect cases
2319         where exception checks are missing.  The notes below will cover:
2320
2321             1. The VM::m_needExceptionCheck bit
2322             2. ThrowScopes and CatchScopes
2323             3. Verification of needed exception checks
2324             3. Checking Exceptions
2325             4. Simulating throws
2326             5. Using ThrowScope::release()
2327             6. Checking exceptions with ThrowScope::exception() / CatchScope::exception()
2328             7. Checking exceptions by checking callee results
2329             8. Debugging verification errors
2330
2331         1. The VM::m_needExceptionCheck bit
2332
2333            The VM has a m_needExceptionCheck bit that indicates when an exception may be
2334            thrown.  You can think of the m_needExceptionCheck bit being set as a simulated
2335            throw.
2336
2337         2. ThrowScopes and CatchScopes
2338
2339            Only ThrowScopes may throwException.  Only CatchScopes may catchException.
2340
2341            Every throw site must declare a ThrowScope instance using DECLARE_THROW_SCOPE
2342            at the top of its function (as early as possible) e.g.
2343  
2344                 void foo(...)
2345                 {
2346                     auto scope = DECLARE_THROW_SCOPE(vm);
2347                     ...
2348                     throwException(exec, scope, ...);
2349                 }
2350
2351            Note: by convention, every throw helper function must take a ThrowScope argument
2352            instead of instantiating its own ThrowScope.  This allows the throw to be
2353            attributed to the client code rather than the throw helper itself.
2354
2355            Every catch site (i.e. a site that calls clearException()) must declare a
2356            CatchScope instance using DECLARE_CATCH_SCOPE at the top of its function.
2357
2358            If a function can both throw or clear exceptions, then the ThrowScope should
2359            be declared first so that it can simulate a throw to the function's caller.
2360
2361            Note: ThrowScope and CatchScope both extend ExceptionScope so that ThrowScopes
2362            can be aware if there's an enclosing CatchScope between it and the point where
2363            C++ code returns to JS code.  This is needed to determine if the ThrowScope
2364            should simulate a re-throw or not.  See (4) below for more details on returning
2365            to JS code.
2366
2367         3. Verification of needed exception checks
2368
2369            a. On construction, each ThrowScope and CatchScope will verify that
2370               VM::m_needExceptionCheck is not set.
2371  
2372               This ensures that the caller of the current function has checked for exceptions
2373               where needed before doing more work which lead to calling the current function.
2374
2375            b. On destruction, each ThrowScope and CatchScope will verify that
2376               VM::m_needExceptionCheck is not set. This verification will be skipped if
2377               the ThrowScope has been released (see (5) below).
2378
2379               This ensures that the function that owns this exception scope is not missing
2380               any exception checks before returning.
2381
2382            c. When throwing an exception, the ThrowScope will verify that VM::m_needExceptionCheck
2383               is not already set, unless it's been ask to rethrow the same Exception object.
2384
2385         4. Simulating throws
2386
2387            Throws are simulated by setting the m_needExceptionCheck bit.
2388
2389            The bit will only be set in the ThrowScope destructor except when the ThrowScope
2390            detects the caller is a LLInt or JIT function.  LLInt or JIT functions will always
2391            check for exceptions after a host C++ function returns to it.  However, they will
2392            not clear the m_needExceptionCheck bit.
2393
2394            Hence, if the ThrowScope destructor detects the caller is a LLInt or JIT function,
2395            it will just skip the setting of the bit.
2396
2397            Note: it is not needed nor correct to set the m_needExceptionCheck bit in the
2398            throwException methods.  This is because, in practice, we always return
2399            immediately after throwing an exception.  It doesn't make sense to set the bit in
2400            the throw just to have to clear it immediately after before we do verification in
2401            the ThrowScope destructor.
2402
2403         5. Using ThrowScope::release()
2404
2405            Calling release() means that the scope is released from its obligation to
2406            verify the VM::m_needExceptionCheck bit on destruction.
2407
2408            release() should only be used at the bottom of a function if:
2409
2410            a. This function is going to let its caller check and handle the exception, e.g.
2411
2412                 void foo(...)
2413                 {
2414                     auto scope = DECLARE_THROW_SCOPE(vm);
2415                     auto result = goo(); // may throw.
2416
2417                     ... // Code that will are not affected by a pending exceptions.
2418
2419                     scope.release(); // tell the ThrowScope that the caller will handle the exception.
2420                     return result;
2421                 }
2422
2423            b. This function is going to do a tail call that may throw.
2424
2425                 void foo(...)
2426                 {
2427                     auto scope = DECLARE_THROW_SCOPE(vm);
2428                     ...
2429                     scope.release(); // tell the ThrowScope that the caller will handle the exception.
2430                     return goo(); // may throw.
2431                 }
2432
2433               release() should not be used in code paths that branch. For example:
2434
2435                 void foo(...)
2436                 {
2437                     auto scope = DECLARE_THROW_SCOPE(vm);
2438
2439                     auto result = goo1(); // may throw.
2440                     scope.release(); // WRONG !!! Don't do this.
2441                     if (result)
2442                         return;
2443
2444                     result = goo2(); // may throw.
2445                     ...
2446                     return result;
2447                 }
2448
2449             The above will result in a verification error in goo2()'s ThrowScope.  The
2450             proper way to fix this verification is to do either (6) or (7) below.
2451
2452          6. Checking exceptions with ThrowScope::exception() / CatchScope::exception()
2453
2454             ThrowScope/CatchScope::exception() returns the thrown Exception object if
2455             there is one pending.  Else, it returns nullptr.
2456
2457             It also clears the m_needExceptionCheck bit thereby indicating that we've
2458             satisfied the needed exception check.  For example,
2459
2460                 void foo(...)
2461                 {
2462                     auto scope = DECLARE_THROW_SCOPE(vm);
2463
2464                     auto result = goo1(); // may throw.
2465                     if (scope.exception())
2466                         return;
2467
2468                     result = goo2(); // may throw.
2469                     ...
2470                     return result;
2471                 }
2472
2473             But sometimes, for optimization reasons, we may choose to test the result of
2474             the callee function instead doing a load of the VM exception value.  See (7)
2475             below.
2476
2477          7. Checking exceptions by checking callee results
2478
2479             This approach should only be applied when it makes a difference to performance.
2480             If we need to do this, we should add an ASSERT() that invokes the scope's
2481             exception() method to verify the result.  Since exception scope verification
2482             is only done on DEBUG builds, this ASSERT will satisfy the verification
2483             requirements without impacting performance.  For example,
2484
2485                 void foo(...)
2486                 {
2487                     auto scope = DECLARE_THROW_SCOPE(vm);
2488
2489                     bool failed = goo1(); // may throw.
2490                     ASSERT(!!scope.exception() == failed)
2491                     if (failed)
2492                         return;
2493
2494                     result = goo2(); // may throw.
2495                     ...
2496                     return result;
2497                 }
2498
2499          8. Debugging verification errors
2500
2501             a. When verification fails, you will see a message followed by an assertion
2502                failure.  For example:
2503
2504             ERROR: Unchecked JS exception:
2505                 This scope can throw a JS exception: setUpCall @ /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1245
2506                     (ExceptionScope::m_recursionDepth was ...)
2507                 But the exception was unchecked as of this scope: varargsSetup @ /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1398
2508                     (ExceptionScope::m_recursionDepth was ...)
2509                 [ backtrace here ]
2510
2511                The message tells you that failure was detected at in varargsSetup() at
2512                LLIntSlowPaths.cpp line 1398, and that the missing exception check should
2513                have happened somewhere between the call to setUpCall() at LLIntSlowPaths.cpp
2514                line 1245 and it.
2515
2516                If that is insufficient information, you can ...
2517
2518             b. Dump simulated throws
2519
2520                Re-run the test case with JSC_dumpSimulatedThrows=true.  You will also see
2521                back traces at each simulated throw.
2522
2523             c. Narrowing down the source of a simulated throw
2524
2525                Another technique for narrowing down the source of simulated throws is by
2526                further dividing a function to smaller regions by separating each region
2527                with additional local throw scopes.  For example,
2528
2529                 ... // Region 1
2530                 { auto scope = DECLARE_THROW_SCOPE(vm); }
2531                 ... // Region 2
2532                 { auto scope = DECLARE_THROW_SCOPE(vm); }
2533                 ... // Region 3
2534
2535         * API/APIUtils.h:
2536         (handleExceptionIfNeeded):
2537         * CMakeLists.txt:
2538         * JavaScriptCore.xcodeproj/project.pbxproj:
2539         * bindings/ScriptFunctionCall.cpp:
2540         (Deprecated::ScriptFunctionCall::call):
2541         * bindings/ScriptValue.cpp:
2542         (Deprecated::ScriptValue::toString):
2543         * debugger/Debugger.cpp:
2544         (JSC::Debugger::pauseIfNeeded):
2545         * debugger/DebuggerCallFrame.cpp:
2546         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
2547         * dfg/DFGOSRExitCompiler.cpp:
2548         * dfg/DFGOperations.cpp:
2549         (JSC::DFG::operationPutByValInternal):
2550         * inspector/InjectedScriptManager.cpp:
2551         (Inspector::InjectedScriptManager::createInjectedScript):
2552         * inspector/JSGlobalObjectInspectorController.cpp:
2553         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
2554         * inspector/JSInjectedScriptHost.cpp:
2555         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
2556         (Inspector::JSInjectedScriptHost::getInternalProperties):
2557         (Inspector::JSInjectedScriptHost::weakMapEntries):
2558         (Inspector::JSInjectedScriptHost::weakSetEntries):
2559         (Inspector::JSInjectedScriptHost::iteratorEntries):
2560         * inspector/JSJavaScriptCallFrame.cpp:
2561         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
2562         * inspector/ScriptCallStackFactory.cpp:
2563         (Inspector::extractSourceInformationFromException):
2564         * interpreter/CachedCall.h:
2565         (JSC::CachedCall::CachedCall):
2566         * interpreter/CallFrame.h:
2567         (JSC::ExecState::clearException): Deleted.
2568         (JSC::ExecState::exception): Deleted.
2569         (JSC::ExecState::hadException): Deleted.
2570         (JSC::ExecState::lastException): Deleted.
2571         (JSC::ExecState::clearLastException): Deleted.
2572         * interpreter/Interpreter.cpp:
2573         (JSC::eval):
2574         (JSC::sizeOfVarargs):
2575         (JSC::notifyDebuggerOfUnwinding):
2576         (JSC::Interpreter::unwind):
2577         (JSC::Interpreter::execute):
2578         (JSC::Interpreter::executeCall):
2579         (JSC::Interpreter::executeConstruct):
2580         (JSC::Interpreter::prepareForRepeatCall):
2581         (JSC::Interpreter::debug):
2582         * interpreter/Interpreter.h:
2583         (JSC::SuspendExceptionScope::SuspendExceptionScope):
2584         * interpreter/ShadowChicken.cpp:
2585         (JSC::ShadowChicken::functionsOnStack):
2586         * jit/JITCode.cpp:
2587         (JSC::JITCode::execute):
2588         * jit/JITExceptions.cpp:
2589         (JSC::genericUnwind):
2590         * jit/JITOperations.cpp:
2591         (JSC::getByVal):
2592         * jsc.cpp:
2593         (WTF::ImpureGetter::getOwnPropertySlot):
2594         (GlobalObject::moduleLoaderResolve):
2595         (GlobalObject::moduleLoaderFetch):
2596         (functionCreateElement):
2597         (functionRun):
2598         (functionRunString):
2599         (functionLoad):
2600         (functionLoadString):
2601         (functionReadFile):
2602         (functionCheckSyntax):
2603         (functionSetRandomSeed):
2604         (functionLoadModule):
2605         (functionCreateBuiltin):
2606         (functionCheckModuleSyntax):
2607         (functionGenerateHeapSnapshot):
2608         (functionSamplingProfilerStackTraces):
2609         (dumpException):
2610         (checkUncaughtException):
2611         (runWithScripts):
2612         (runInteractive):
2613         * llint/LLIntExceptions.cpp:
2614         (JSC::LLInt::returnToThrow):
2615         (JSC::LLInt::callToThrow):
2616         * llint/LLIntSlowPaths.cpp:
2617         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2618         * profiler/ProfilerBytecodeSequence.cpp:
2619         (JSC::Profiler::BytecodeSequence::addSequenceProperties):
2620         * profiler/ProfilerCompilation.cpp:
2621         (JSC::Profiler::Compilation::toJS):
2622         * profiler/ProfilerDatabase.cpp:
2623         (JSC::Profiler::Database::toJS):
2624         * profiler/ProfilerOSRExitSite.cpp:
2625         (JSC::Profiler::OSRExitSite::toJS):
2626         * profiler/ProfilerOriginStack.cpp:
2627         (JSC::Profiler::OriginStack::toJS):
2628         * runtime/ArrayPrototype.cpp:
2629         (JSC::speciesConstructArray):
2630         (JSC::shift):
2631         (JSC::unshift):
2632         (JSC::arrayProtoFuncToString):
2633         (JSC::arrayProtoFuncToLocaleString):
2634         (JSC::slowJoin):
2635         (JSC::fastJoin):
2636         (JSC::arrayProtoFuncJoin):
2637         (JSC::arrayProtoFuncPop):
2638         (JSC::arrayProtoFuncPush):
2639         (JSC::arrayProtoFuncReverse):
2640         (JSC::arrayProtoFuncShift):
2641         (JSC::arrayProtoFuncSlice):
2642         (JSC::arrayProtoFuncSplice):
2643         (JSC::arrayProtoFuncUnShift):
2644         (JSC::arrayProtoFuncIndexOf):
2645         (JSC::arrayProtoFuncLastIndexOf):
2646         (JSC::moveElements):
2647         (JSC::concatAppendOne):
2648         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2649         * runtime/BooleanConstructor.cpp:
2650         (JSC::constructWithBooleanConstructor):
2651         * runtime/CallData.cpp:
2652         (JSC::call):
2653         * runtime/CatchScope.cpp: Added.
2654         (JSC::CatchScope::CatchScope):
2655         (JSC::CatchScope::~CatchScope):
2656         * runtime/CatchScope.h: Added.
2657         (JSC::CatchScope::clearException):
2658         (JSC::CatchScope::CatchScope):
2659         * runtime/CommonSlowPaths.cpp:
2660         (JSC::SLOW_PATH_DECL):
2661         * runtime/CommonSlowPaths.h:
2662         (JSC::CommonSlowPaths::opIn):
2663         * runtime/CommonSlowPathsExceptions.cpp:
2664         (JSC::CommonSlowPaths::interpreterThrowInCaller):
2665         * runtime/Completion.cpp:
2666         (JSC::evaluate):
2667         (JSC::rejectPromise):
2668         (JSC::loadAndEvaluateModule):
2669         (JSC::loadModule):
2670         * runtime/ConsoleObject.cpp:
2671         (JSC::consoleProtoFuncAssert):
2672         (JSC::consoleProtoFuncProfile):
2673         (JSC::consoleProtoFuncProfileEnd):
2674         (JSC::consoleProtoFuncTakeHeapSnapshot):
2675         (JSC::consoleProtoFuncTime):
2676         (JSC::consoleProtoFuncTimeEnd):
2677         * runtime/DateConstructor.cpp:
2678         (JSC::constructDate):
2679         (JSC::dateParse):
2680         * runtime/DatePrototype.cpp:
2681         (JSC::dateProtoFuncToPrimitiveSymbol):
2682         (JSC::dateProtoFuncToJSON):
2683         * runtime/ErrorConstructor.cpp:
2684         (JSC::Interpreter::constructWithErrorConstructor):
2685         * runtime/ErrorInstance.cpp:
2686         (JSC::ErrorInstance::sanitizedToString):
2687         * runtime/ErrorPrototype.cpp:
2688         (JSC::errorProtoFuncToString):
2689         * runtime/ExceptionEventLocation.cpp: Added.
2690         (WTF::printInternal):
2691         * runtime/ExceptionEventLocation.h: Copied from Source/JavaScriptCore/runtime/ThrowScopeLocation.h.
2692         (JSC::ExceptionEventLocation::ExceptionEventLocation):
2693         (JSC::ThrowScopeLocation::ThrowScopeLocation): Deleted.
2694         * runtime/ExceptionHelpers.h:
2695         * runtime/ExceptionScope.cpp: Added.
2696         (JSC::ExceptionScope::ExceptionScope):
2697         (JSC::ExceptionScope::~ExceptionScope):
2698         * runtime/ExceptionScope.h: Added.
2699         (JSC::ExceptionScope::vm):
2700         (JSC::ExceptionScope::recursionDepth):
2701         (JSC::ExceptionScope::exception):
2702         (JSC::ExceptionScope::ExceptionScope):
2703         * runtime/FunctionConstructor.cpp:
2704         (JSC::constructFunctionSkippingEvalEnabledCheck):
2705         * runtime/FunctionPrototype.cpp:
2706         (JSC::functionProtoFuncBind):
2707         * runtime/GenericArgumentsInlines.h:
2708         (JSC::GenericArguments<Type>::copyToArguments):
2709         * runtime/GetterSetter.cpp:
2710         (JSC::callGetter):
2711         * runtime/InspectorInstrumentationObject.cpp:
2712         (JSC::inspectorInstrumentationObjectLog):
2713         * runtime/InternalFunction.cpp:
2714         (JSC::InternalFunction::createSubclassStructure):
2715         * runtime/IntlCollator.cpp:
2716         (JSC::IntlCollator::initializeCollator):
2717         (JSC::IntlCollator::createCollator):
2718         (JSC::IntlCollator::resolvedOptions):
2719         * runtime/IntlCollatorConstructor.cpp:
2720         (JSC::constructIntlCollator):
2721         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
2722         * runtime/IntlCollatorPrototype.cpp:
2723         (JSC::IntlCollatorFuncCompare):
2724         (JSC::IntlCollatorPrototypeGetterCompare):
2725         * runtime/IntlDateTimeFormat.cpp:
2726         (JSC::toDateTimeOptionsAnyDate):
2727         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
2728         (JSC::IntlDateTimeFormat::resolvedOptions):
2729         (JSC::IntlDateTimeFormat::format):
2730         * runtime/IntlDateTimeFormatConstructor.cpp:
2731         (JSC::constructIntlDateTimeFormat):
2732         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
2733         * runtime/IntlDateTimeFormatPrototype.cpp:
2734         (JSC::IntlDateTimeFormatFuncFormatDateTime):
2735         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
2736         * runtime/IntlNumberFormat.cpp:
2737         (JSC::IntlNumberFormat::initializeNumberFormat):
2738         (JSC::IntlNumberFormat::createNumberFormat):
2739         (JSC::IntlNumberFormat::resolvedOptions):
2740         * runtime/IntlNumberFormatConstructor.cpp:
2741         (JSC::constructIntlNumberFormat):
2742         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
2743         * runtime/IntlNumberFormatPrototype.cpp:
2744         (JSC::IntlNumberFormatFuncFormatNumber):
2745         (JSC::IntlNumberFormatPrototypeGetterFormat):
2746         * runtime/IntlObject.cpp:
2747         (JSC::intlBooleanOption):
2748         (JSC::intlStringOption):
2749         (JSC::intlNumberOption):
2750         (JSC::canonicalizeLocaleList):
2751         (JSC::supportedLocales):
2752         * runtime/IntlObjectInlines.h:
2753         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
2754         * runtime/IteratorOperations.cpp:
2755         (JSC::iteratorNext):
2756         (JSC::iteratorStep):
2757         (JSC::iteratorClose):
2758         (JSC::iteratorForIterable):
2759         * runtime/IteratorOperations.h:
2760         (JSC::forEachInIterable):
2761         * runtime/JSArray.cpp:
2762         (JSC::JSArray::pop):
2763         (JSC::JSArray::push):
2764         (JSC::JSArray::copyToArguments):
2765         * runtime/JSArrayBufferConstructor.cpp:
2766         (JSC::constructArrayBuffer):
2767         * runtime/JSArrayBufferPrototype.cpp:
2768         (JSC::arrayBufferProtoFuncSlice):
2769         * runtime/JSArrayInlines.h:
2770         (JSC::getLength):
2771         (JSC::toLength):
2772         * runtime/JSBoundFunction.cpp:
2773         (JSC::getBoundFunctionStructure):
2774         (JSC::JSBoundFunction::create):
2775         * runtime/JSCJSValue.cpp:
2776         (JSC::JSValue::putToPrimitive):
2777         (JSC::JSValue::putToPrimitiveByIndex):
2778         (JSC::JSValue::toStringSlowCase):
2779         * runtime/JSCJSValueInlines.h:
2780         (JSC::toPreferredPrimitiveType):
2781         (JSC::JSValue::getPropertySlot):
2782         (JSC::JSValue::equalSlowCaseInline):
2783         * runtime/JSDataViewPrototype.cpp:
2784         (JSC::getData):
2785         (JSC::setData):
2786         * runtime/JSFunction.cpp:
2787         (JSC::JSFunction::setFunctionName):
2788         * runtime/JSGenericTypedArrayView.h:
2789         (JSC::JSGenericTypedArrayView::setIndex):
2790         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2791         (JSC::constructGenericTypedArrayViewFromIterator):
2792         (JSC::constructGenericTypedArrayViewWithArguments):
2793         (JSC::constructGenericTypedArrayView):
2794         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2795         (JSC::speciesConstruct):
2796         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
2797         (JSC::genericTypedArrayViewProtoFuncIncludes):
2798         (JSC::genericTypedArrayViewProtoFuncIndexOf):
2799         (JSC::genericTypedArrayViewProtoFuncJoin):
2800         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
2801         (JSC::genericTypedArrayViewProtoFuncSlice):
2802         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
2803         * runtime/JSGlobalObject.h:
2804         (JSC::constructEmptyArray):
2805         (JSC::constructArray):
2806         (JSC::constructArrayNegativeIndexed):
2807         * runtime/JSGlobalObjectFunctions.cpp:
2808         (JSC::globalFuncEval):
2809         * runtime/JSJob.cpp:
2810         (JSC::JSJobMicrotask::run):
2811         * runtime/JSModuleEnvironment.cpp:
2812         (JSC::JSModuleEnvironment::getOwnPropertySlot):
2813         * runtime/JSModuleLoader.cpp:
2814         (JSC::JSModuleLoader::fetch):
2815         * runtime/JSModuleNamespaceObject.cpp:
2816         (JSC::JSModuleNamespaceObject::finishCreation):
2817         (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
2818         * runtime/JSModuleRecord.cpp:
2819         (JSC::JSModuleRecord::instantiateDeclarations):
2820         * runtime/JSONObject.cpp:
2821         (JSC::Stringifier::Stringifier):
2822         (JSC::Stringifier::stringify):
2823         (JSC::Stringifier::toJSON):
2824         (JSC::Stringifier::appendStringifiedValue):
2825         (JSC::Stringifier::Holder::appendNextProperty):
2826         (JSC::Walker::walk):
2827         (JSC::JSONProtoFuncParse):
2828         * runtime/JSObject.cpp:
2829         (JSC::ordinarySetSlow):
2830         (JSC::JSObject::setPrototypeWithCycleCheck):
2831         (JSC::callToPrimitiveFunction):
2832         (JSC::JSObject::ordinaryToPrimitive):
2833         (JSC::JSObject::defaultHasInstance):
2834         (JSC::JSObject::getPropertyNames):
2835         (JSC::JSObject::toNumber):
2836         (JSC::JSObject::toString):
2837         (JSC::JSObject::defineOwnNonIndexProperty):
2838         (JSC::JSObject::getGenericPropertyNames):
2839         (JSC::JSObject::getMethod):
2840         * runtime/JSObjectInlines.h:
2841         (JSC::createListFromArrayLike):
2842         (JSC::JSObject::getPropertySlot):
2843         (JSC::JSObject::getNonIndexPropertySlot):
2844         * runtime/JSPromiseConstructor.cpp:
2845         (JSC::constructPromise):
2846         * runtime/JSPropertyNameEnumerator.h:
2847         (JSC::propertyNameEnumerator):
2848         * runtime/JSPropertyNameIterator.cpp:
2849         (JSC::JSPropertyNameIterator::create):
2850         * runtime/JSScope.cpp:
2851         (JSC::isUnscopable):
2852         (JSC::JSScope::resolve):
2853         * runtime/JSString.cpp:
2854         (JSC::JSString::equalSlowCase):
2855         * runtime/JSStringJoiner.cpp:
2856         (JSC::JSStringJoiner::join):
2857         * runtime/LiteralParser.cpp:
2858         (JSC::LiteralParser<CharType>::parse):
2859         * runtime/MapConstructor.cpp:
2860         (JSC::constructMap):
2861         * runtime/MathObject.cpp:
2862         (JSC::mathProtoFuncClz32):
2863         (JSC::mathProtoFuncHypot):
2864         (JSC::mathProtoFuncIMul):
2865         * runtime/ModuleLoaderPrototype.cpp:
2866         (JSC::moduleLoaderPrototypeParseModule):
2867         (JSC::moduleLoaderPrototypeRequestedModules):
2868         (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
2869         * runtime/NativeErrorConstructor.cpp:
2870         (JSC::Interpreter::constructWithNativeErrorConstructor):
2871         * runtime/NumberConstructor.cpp:
2872         (JSC::constructWithNumberConstructor):
2873         * runtime/ObjectConstructor.cpp:
2874         (JSC::constructObject):
2875         (JSC::objectConstructorGetPrototypeOf):
2876         (JSC::objectConstructorSetPrototypeOf):
2877         (JSC::objectConstructorGetOwnPropertyDescriptor):
2878         (JSC::objectConstructorGetOwnPropertyDescriptors):
2879         (JSC::objectConstructorGetOwnPropertyNames):
2880         (JSC::objectConstructorGetOwnPropertySymbols):
2881         (JSC::objectConstructorKeys):
2882         (JSC::ownEnumerablePropertyKeys):
2883         (JSC::toPropertyDescriptor):
2884         (JSC::objectConstructorDefineProperty):
2885         (JSC::defineProperties):
2886         (JSC::objectConstructorSeal):
2887         (JSC::objectConstructorFreeze):
2888         (JSC::objectConstructorIsSealed):
2889         (JSC::objectConstructorIsFrozen):
2890         (JSC::objectConstructorIsExtensible):
2891         (JSC::ownPropertyKeys):
2892         * runtime/ObjectConstructor.h:
2893         (JSC::constructObjectFromPropertyDescriptor):
2894         * runtime/ObjectPrototype.cpp:
2895         (JSC::objectProtoFuncHasOwnProperty):
2896         (JSC::objectProtoFuncIsPrototypeOf):
2897         (JSC::objectProtoFuncDefineGetter):
2898         (JSC::objectProtoFuncDefineSetter):
2899         (JSC::objectProtoFuncLookupGetter):
2900         (JSC::objectProtoFuncLookupSetter):
2901         (JSC::objectProtoFuncPropertyIsEnumerable):
2902         (JSC::objectProtoFuncToLocaleString):
2903         (JSC::objectProtoFuncToString):
2904         * runtime/Operations.cpp:
2905         (JSC::jsAddSlowCase):
2906         * runtime/Options.h:
2907         * runtime/PropertyDescriptor.cpp:
2908         (JSC::PropertyDescriptor::slowGetterSetter):
2909         * runtime/ProxyConstructor.cpp:
2910         (JSC::makeRevocableProxy):
2911         * runtime/ProxyObject.cpp:
2912         (JSC::ProxyObject::toStringName):
2913         (JSC::performProxyGet):
2914         (JSC::ProxyObject::performGet):
2915         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2916         (JSC::ProxyObject::performHasProperty):
2917         (JSC::ProxyObject::performPut):
2918         (JSC::ProxyObject::putByIndexCommon):
2919         (JSC::performProxyCall):
2920         (JSC::performProxyConstruct):
2921         (JSC::ProxyObject::performDelete):
2922         (JSC::ProxyObject::performPreventExtensions):
2923         (JSC::ProxyObject::performIsExtensible):
2924         (JSC::ProxyObject::performDefineOwnProperty):
2925         (JSC::ProxyObject::performGetOwnPropertyNames):
2926         (JSC::ProxyObject::performSetPrototype):
2927         (JSC::ProxyObject::performGetPrototype):
2928         * runtime/ReflectObject.cpp:
2929         (JSC::reflectObjectConstruct):
2930         (JSC::reflectObjectDefineProperty):
2931         (JSC::reflectObjectGet):
2932         (JSC::reflectObjectGetOwnPropertyDescriptor):
2933         (JSC::reflectObjectIsExtensible):
2934         (JSC::reflectObjectPreventExtensions):
2935         (JSC::reflectObjectSet):
2936         (JSC::reflectObjectSetPrototypeOf):
2937         * runtime/RegExpConstructor.cpp:
2938         (JSC::toFlags):
2939         (JSC::regExpCreate):
2940         (JSC::constructRegExp):
2941         * runtime/RegExpConstructor.h:
2942         (JSC::isRegExp):
2943         * runtime/RegExpObject.cpp:
2944         (JSC::collectMatches):
2945         (JSC::RegExpObject::matchGlobal):
2946         * runtime/RegExpPrototype.cpp:
2947         (JSC::regExpProtoFuncCompile):
2948         (JSC::flagsString):
2949         (JSC::regExpProtoFuncToString):
2950         (JSC::regExpProtoGetterFlags):
2951         (JSC::regExpProtoFuncSearchFast):
2952         (JSC::regExpProtoFuncSplitFast):
2953         * runtime/SetConstructor.cpp:
2954         (JSC::constructSet):
2955         * runtime/StringConstructor.cpp:
2956         (JSC::stringFromCodePoint):
2957         (JSC::constructWithStringConstructor):
2958         * runtime/StringObject.cpp:
2959         (JSC::StringObject::defineOwnProperty):
2960         * runtime/StringPrototype.cpp:
2961         (JSC::replaceUsingRegExpSearch):
2962         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2963         (JSC::replaceUsingStringSearch):
2964         (JSC::replace):
2965         (JSC::stringProtoFuncReplaceUsingRegExp):
2966         (JSC::stringProtoFuncReplaceUsingStringSearch):
2967         (JSC::stringProtoFuncCodePointAt):
2968         (JSC::stringProtoFuncSlice):
2969         (JSC::stringProtoFuncSplitFast):
2970         (JSC::stringProtoFuncSubstr):
2971         (JSC::stringProtoFuncSubstring):
2972         (JSC::stringProtoFuncLocaleCompare):
2973         (JSC::toLocaleCase):
2974         (JSC::stringProtoFuncBig):
2975         (JSC::stringProtoFuncSmall):
2976         (JSC::stringProtoFuncBlink):
2977         (JSC::stringProtoFuncBold):
2978         (JSC::stringProtoFuncFixed):
2979         (JSC::stringProtoFuncItalics):
2980         (JSC::stringProtoFuncStrike):
2981         (JSC::stringProtoFuncSub):
2982         (JSC::stringProtoFuncSup):
2983         (JSC::stringProtoFuncFontcolor):
2984         (JSC::stringProtoFuncFontsize):
2985         (JSC::stringProtoFuncAnchor):
2986         (JSC::stringProtoFuncLink):
2987         (JSC::trimString):
2988         (JSC::stringProtoFuncStartsWith):
2989         (JSC::stringProtoFuncEndsWith):
2990         (JSC::stringIncludesImpl):
2991         (JSC::stringProtoFuncIncludes):
2992         (JSC::builtinStringIncludesInternal):
2993         (JSC::stringProtoFuncNormalize):
2994         * runtime/SymbolConstructor.cpp:
2995         (JSC::symbolConstructorFor):
2996         * runtime/TemplateRegistry.cpp:
2997         (JSC::TemplateRegistry::getTemplateObject):
2998         * runtime/ThrowScope.cpp:
2999         (JSC::ThrowScope::ThrowScope):
3000         (JSC::ThrowScope::~ThrowScope):
3001         (JSC::ThrowScope::throwException):
3002         (JSC::ThrowScope::simulateThrow):
3003         (JSC::ThrowScope::printIfNeedCheck): Deleted.
3004         (JSC::ThrowScope::verifyExceptionCheckNeedIsSatisfied): Deleted.
3005         * runtime/ThrowScope.h:
3006         (JSC::ThrowScope::release):
3007         (JSC::ThrowScope::ThrowScope):
3008         (JSC::ThrowScope::throwException):
3009         (JSC::ThrowScope::vm): Deleted.
3010         (JSC::ThrowScope::exception): Deleted.
3011         * runtime/ThrowScopeLocation.h: Removed.
3012         * runtime/VM.cpp:
3013         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
3014         * runtime/VM.h:
3015         (JSC::VM::exception):
3016         (JSC::VM::clearException):
3017         (JSC::VM::setException): Deleted.
3018         * runtime/WeakMapConstructor.cpp:
3019         (JSC::constructWeakMap):
3020         * runtime/WeakSetConstructor.cpp:
3021         (JSC::constructWeakSet):
3022         * tools/JSDollarVMPrototype.cpp:
3023         (JSC::functionPrint):
3024
3025 2016-09-07  Andy VanWagoner  <thetalecrafter@gmail.com>
3026
3027         [INTL] some valid language tags cause errors in Intl constructors
3028         https://bugs.webkit.org/show_bug.cgi?id=161672
3029
3030         Reviewed by Mark Lam.
3031
3032         Fix private use tag parsing to match spec, allowing single character parts.
3033         https://www.rfc-editor.org/rfc/bcp/bcp47.txt
3034
3035         ```
3036         privateuse    = "x" 1*("-" (1*8alphanum))
3037         ```
3038
3039         * runtime/IntlObject.cpp:
3040         (JSC::privateUseLangTag): Allow singleton parts in private use tag.
3041
3042 2016-09-07  Benjamin Poulain  <bpoulain@apple.com>
3043
3044         [JSC] Remove a couple of useless forward declaration
3045         https://bugs.webkit.org/show_bug.cgi?id=161676
3046
3047         Reviewed by Mark Lam.
3048
3049         JITMathICForwards.h should take care of declarating the Math ICs.
3050
3051         * bytecode/CodeBlock.h:
3052         * jit/JITOperations.h:
3053
3054 2016-09-07  Filip Pizlo  <fpizlo@apple.com>
3055
3056         Make emitAllocateWithNonNullAllocator's sub32() disallow-scratch-friendly
3057         https://bugs.webkit.org/show_bug.cgi?id=161706
3058
3059         Reviewed by Geoffrey Garen.
3060         
3061         You can't sub32(Addr, Reg) on not-x86 without using a scratch register. So, on those CPUs, we
3062         have to do something different.
3063
3064         * jit/AssemblyHelpers.h:
3065         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
3066
3067 2016-09-07  Michael Catanzaro  <mcatanzaro@igalia.com>
3068
3069         Unreviewed CMake build fix after r205552
3070
3071         * CMakeLists.txt:
3072
3073 2016-09-03  Keith Miller  <keith_miller@apple.com>
3074
3075         Add support for WASM Loops and Branches
3076         https://bugs.webkit.org/show_bug.cgi?id=161569
3077
3078         Reviewed by Benjamin Poulain.
3079
3080         This patch adds support for loops and branches to WASM. In order
3081         to support loops, we needed to change the way the B3IRGenerator
3082         tracked control information. Now, the control data holds three
3083         pieces of information: The continuation block, the loop branch
3084         target, and variables exiting the block. Whenever we branch to
3085         some control point we first check if it is a loop by checking that
3086         the loop branch target is non-null. If the branch is not targeting
3087         a loop, we map the stack values to the associated B3 variables for
3088         that stack slot.
3089
3090         Another interesting thing of note is that we now only allocate the
3091         continuation basic block lazily. This is beneficial when the
3092         continuation would just fall through to another block anyway. For
3093         example, in code like: (block ... (block (add 1 2) end) end) the
3094         continuation for the inner block just falls through to the outer
3095         block's continuation so we don't need an extra block.
3096
3097         * B3CallingConventions.cpp:
3098         (JSC::B3::jscCallingConvention): Deleted.
3099         * B3CallingConventions.h:
3100         (JSC::B3::CallingConvention::CallingConvention): Deleted.
3101         (JSC::B3::CallingConvention::iterate): Deleted.
3102         (JSC::B3::nextJSCOffset): Deleted.
3103         * JavaScriptCore.xcodeproj/project.pbxproj:
3104         * b3/B3Type.h:
3105         * testWASM.cpp:
3106         (runWASMTests):
3107         * wasm/WASMB3IRGenerator.cpp:
3108         (JSC::WASM::B3IRGenerator::LazyBlock::LazyBlock):
3109         (JSC::WASM::B3IRGenerator::LazyBlock::operator bool):
3110         (JSC::WASM::B3IRGenerator::LazyBlock::get):
3111         (JSC::WASM::B3IRGenerator::LazyBlock::dump):
3112         (JSC::WASM::B3IRGenerator::ControlData::ControlData):
3113         (JSC::WASM::B3IRGenerator::ControlData::dump):
3114         (JSC::WASM::B3IRGenerator::ControlData::targetBlockForBranch):
3115         (JSC::WASM::B3IRGenerator::ControlData::isLoop):
3116         (JSC::WASM::B3IRGenerator::addLocal):
3117         (JSC::WASM::B3IRGenerator::addArguments):
3118         (JSC::WASM::B3IRGenerator::setLocal):
3119         (JSC::WASM::B3IRGenerator::addBlock):
3120         (JSC::WASM::B3IRGenerator::addLoop):
3121         (JSC::WASM::B3IRGenerator::endBlock):
3122         (JSC::WASM::B3IRGenerator::addReturn):
3123         (JSC::WASM::B3IRGenerator::addBranch):
3124         (JSC::WASM::B3IRGenerator::initializeIncommingTypes):
3125         (JSC::WASM::B3IRGenerator::unifyValuesWithBlock):
3126         (JSC::WASM::B3IRGenerator::controlDataForLevel):
3127         (JSC::WASM::B3IRGenerator::dumpGraphAndControlStack):
3128         (JSC::WASM::parseAndCompile):
3129         (JSC::WASM::B3IRGenerator::unifyValuesWithLevel): Deleted.
3130         (JSC::WASM::B3IRGenerator::stackForControlLevel): Deleted.
3131         (JSC::WASM::B3IRGenerator::blockForControlLevel): Deleted.
3132         * wasm/WASMCallingConvention.cpp: Renamed from Source/JavaScriptCore/B3CallingConventions.cpp.
3133         (JSC::WASM::jscCallingConvention):
3134         * wasm/WASMCallingConvention.h: Renamed from Source/JavaScriptCore/B3CallingConventions.h.
3135         (JSC::WASM::CallingConvention::CallingConvention):
3136         (JSC::WASM::CallingConvention::iterate):
3137         (JSC::WASM::nextJSCOffset):
3138         * wasm/WASMFormat.h:
3139         (JSC::WASM::toB3Type):
3140         (JSC::WASM::isValueType):
3141         * wasm/WASMFunctionParser.h:
3142         (JSC::WASM::FunctionParser<Context>::parse):
3143         (JSC::WASM::FunctionParser<Context>::parseExpression):
3144         * wasm/WASMModuleParser.cpp:
3145         (JSC::WASM::ModuleParser::parseFunctionTypes):
3146         * wasm/WASMOps.h:
3147
3148 2016-09-07  Youenn Fablet  <youenn@apple.com>
3149
3150         [Streams API] Separate compile flag for ReadableStream and WritableStream
3151         https://bugs.webkit.org/show_bug.cgi?id=161044
3152
3153         Reviewed by Alex Christensen.
3154
3155         Moving from STREAMS_API to READABLE_STREAM_API and WRITABLE_STREAM_API compilation flags.
3156         Updated builtin test to cover the case of @conditional taking ENABLE(XX) || ENABLE(YY) flag.
3157
3158         * Configurations/FeatureDefines.xcconfig:
3159         * Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js:
3160         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
3161         * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
3162
3163 2016-09-07  Csaba OsztrogonĂ¡c  <ossy@webkit.org>
3164
3165         Fix the ENABLE(WEBASSEMBLY) build on Linux
3166         https://bugs.webkit.org/show_bug.cgi?id=161685
3167
3168         Unreviewed buildfix.
3169
3170         * wasm/JSWASMModule.cpp:
3171
3172 2016-09-06  Saam Barati  <sbarati@apple.com>
3173
3174         ProxyObject's structure should not have ObjectPrototype as its prototype and it should not have special behavior for intercepting "__proto__"
3175         https://bugs.webkit.org/show_bug.cgi?id=161558
3176
3177         Reviewed by Benjamin Poulain.
3178
3179         ProxyObject had ObjectPrototype as its direct prototype.
3180         This could lead to infinite loops when doing a getDirectPrototype()
3181         loop.
3182
3183         Fixing this bug revealed another bug, which I made when implementing Proxy.
3184         We should not special case "__proto__" in get and set for Proxy Object's
3185         hooks. "__proto__" should just go through the normal set and get path.
3186
3187         * runtime/JSGlobalObject.cpp:
3188         (JSC::JSGlobalObject::init):
3189         * runtime/ProxyObject.cpp:
3190         (JSC::performProxyGet):
3191         (JSC::ProxyObject::put):
3192
3193 2016-09-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3194
3195         Make JSC::PrivateName copyable
3196         https://bugs.webkit.org/show_bug.cgi?id=161666
3197
3198         Reviewed by Ryosuke Niwa.
3199
3200         Define the custom copy constructor to make PrivateName copyable while using Ref<SymbolImpl>.
3201         And since the custom copy constructor deletes the default move constructor, we explcitly define
3202         it by `= default;`.
3203
3204         * runtime/PrivateName.h:
3205         (JSC::PrivateName::PrivateName):
3206
3207 2016-09-06  Daniel Bates  <dabates@apple.com>
3208
3209         [iOS] Build fails in JSCLLIntOffsetsExtractor - Ad Hoc code signing is not allowed with SDK 'Simulator - iOS 10.0'
3210         https://bugs.webkit.org/show_bug.cgi?id=161296
3211
3212         Reviewed by Dan Bernstein.
3213
3214         Allow ad-hoc code signing when building JavaScriptCore command line tools for simulator
3215         with the iOS 10 beta SDK.
3216
3217         * Configurations/Base.xcconfig:
3218
3219 2016-09-06  Saam Barati  <sbarati@apple.com>
3220
3221         Unreviewed build fix for 32-bit platforms after r205520.
3222
3223         * dfg/DFGSpeculativeJIT.h:
3224         (JSC::DFG::SpeculativeJIT::callOperation): Deleted.
3225
3226 2016-09-06  Saam Barati  <sbarati@apple.com>
3227
3228         Member call on NULL pointer in JavaScriptCore/dfg/DFGAbstractInterpretterInlines.h
3229         https://bugs.webkit.org/show_bug.cgi?id=160870
3230
3231         Reviewed by Darin Adler.
3232
3233         Credit goes to Jonathan Bedard for finding this bug using the undefined
3234         behavior sanitizer.
3235
3236         The rule for MaterializeNewObject inside AI was assuming that the graph
3237         is in SSA form. This used to be true when MaterializeNewObject was only
3238         inserted by the allocation sinking phase. However, Filip added more uses
3239         of MaterializeNewObject in his RegExp constant folding patch. This fixes
3240         the bug by using the structure set inside the Node's OpInfo rather than
3241         generating it from m_phiChildren inside AI.
3242
3243         * dfg/DFGAbstractInterpreterInlines.h:
3244         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3245
3246 2016-09-06  Saam Barati  <sbarati@apple.com>
3247
3248         Make JSMap and JSSet faster
3249         https://bugs.webkit.org/show_bug.cgi?id=160989
3250
3251         Reviewed by Filip Pizlo.
3252
3253         This patch revamps how we implement Map and Set. It uses
3254         a new hash map implementation. The hash map uses linear
3255         probing and it uses Wang's 64 bit hash function for JSValues
3256         that aren't strings. Strings use StringImpl's hash function.
3257         The reason I wanted to roll our own HashTable is twofold:
3258         I didn't want to inline WTF::HashMap's implementation into our
3259         JIT, since that seems error prone and unmaintainable. Also, I wanted
3260         a different structure for hash map buckets where buckets also exist in
3261         a linked list.
3262
3263         The reason for making buckets part of a linked list is that iteration
3264         is now simple. Iteration works by just traversing a linked list.
3265         This design also allows for a simple implementation when doing iteration
3266         while the hash table is mutating. Whenever we remove a bucket from
3267         the hash table, it is removed from the list, meaning items in the
3268         list don't point to it. However, the removed bucket will still point
3269         to things that are either in the list, or have also been removed.
3270         e.g, from a removed bucket, you can always follow pointers until you
3271         either find an item in the list, or you find the tail of the list.
3272         This is a really nice property because it means that a Map or Set
3273         does not need to reason about the all the iterators that point
3274         into its list. Also, whenever we add items to the Map or Set, we
3275         hijack the tail as the new item, and make the new item point to a newly
3276         created tail. This means that any iterator that pointed to the "tail" now
3277         points to non-tail items. This makes the implementation of adding things
3278         to the Map/Set while iterating easy.
3279
3280         I also made Map.prototype.get, Map.prototype.has, and Set.prototype.has
3281         into intrinsics in the DFG. The IR can now reason about hash map
3282         operations and can even do CSE over Wang's hash function, hash map
3283         bucket lookups, hash map bucket loads, and testing if a key is in
3284         the hash table. This makes code patterns for Map like so, super fast
3285         in the FTL, since we will only be doing a single hash and hash bucket lookup:
3286
3287         ```
3288         function getKeyIfPresent(map, key) {
3289             if (map.has(key))
3290                 return map.get(key);
3291         }
3292         ```
3293
3294         This patch is roughly an 8% speedup on ES6SampleBench.
3295
3296
3297         * CMakeLists.txt:
3298         * JavaScriptCore.xcodeproj/project.pbxproj:
3299         * assembler/MacroAssemblerARM64.h:
3300         (JSC::MacroAssemblerARM64::not64):
3301         * bytecode/SpeculatedType.cpp:
3302         (JSC::speculationFromClassInfo):
3303         * bytecode/SpeculatedType.h:
3304         * dfg/DFGAbstractInterpreterInlines.h:
3305         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3306         (JSC::DFG::AbstractInterpreter<AbstractStateType>::execute):
3307         * dfg/DFGByteCodeParser.cpp:
3308         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3309         * dfg/DFGClobberize.h:
3310         (JSC::DFG::clobberize):
3311         * dfg/DFGDoesGC.cpp:
3312         (JSC::DFG::doesGC):
3313         * dfg/DFGEdge.h:
3314         (JSC::DFG::Edge::shift):
3315         (JSC::DFG::Edge::makeWord):
3316         * dfg/DFGFixupPhase.cpp:
3317         (JSC::DFG::FixupPhase::fixupNode):
3318         * dfg/DFGHeapLocation.cpp:
3319         (WTF::printInternal):
3320         * dfg/DFGHeapLocation.h:
3321         * dfg/DFGNode.h:
3322         (JSC::DFG::Node::hasHeapPrediction):
3323         * dfg/DFGNodeType.h:
3324         * dfg/DFGOperations.cpp:
3325         * dfg/DFGOperations.h: