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