JSRopeString should use release asserts, not debug asserts, about substring bounds
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-06-28  Filip Pizlo  <fpizlo@apple.com>
2
3         JSRopeString should use release asserts, not debug asserts, about substring bounds
4         https://bugs.webkit.org/show_bug.cgi?id=159227
5
6         Reviewed by Saam Barati.
7         
8         According to my experiments this change costs nothing.  That's not surprising since the
9         most common way to construct a rope these days is inlined into the JIT, which does its own
10         safety checks.  This makes us crash sooner rather than corrupting memory.
11
12         * runtime/JSString.h:
13
14 2016-06-28  Brian Burg  <bburg@apple.com>
15
16         RunLoop::Timer should use constructor templates instead of class templates
17         https://bugs.webkit.org/show_bug.cgi?id=159153
18
19         Reviewed by Alex Christensen.
20
21         Remove the RunLoop::Timer class template argument, and pass its constructor
22         a reference to `this` instead of a pointer to `this`.
23
24         * inspector/agents/InspectorHeapAgent.cpp:
25         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
26
27 2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>
28
29         Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
30         https://bugs.webkit.org/show_bug.cgi?id=159192
31
32         Reviewed by Timothy Hatcher.
33
34         * inspector/InjectedScriptSource.js:
35         (InjectedScript.prototype.arrayIndexPropertyNames):
36         Start with an empty array because we just push valid indexes.
37
38         (InjectedScript.prototype._propertyDescriptors):
39         Avoid the >100 length requirement, and always treat the
40         array-like objects the same. The frontend currently
41         doesn't show named indexes for arrays anyways, so they
42         would have been unused.
43
44 2016-06-28  Per Arne Vollan  <pvollan@apple.com>
45
46         [Win] Skip failing INTL test.
47         https://bugs.webkit.org/show_bug.cgi?id=159141
48
49         Reviewed by Brent Fulgham.
50
51         INTL is not enabled on Windows.
52
53         * tests/stress/intl-constructors-with-proxy.js:
54         (shouldBe):
55
56 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
57
58         [JSC] Fix build break since r202502 - 2
59         https://bugs.webkit.org/show_bug.cgi?id=159194
60
61         Reviewed by Gyuyoung Kim.
62
63         Fix about the error message below.
64         error: control reaches end of non-void function [-Werror=return-type]
65
66         * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".
67
68 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
69
70         [JSC] Fix build break since r202502
71         https://bugs.webkit.org/show_bug.cgi?id=159194
72
73         Reviewed by Alex Christensen.
74
75         Fix about the error message below.
76         error: control reaches end of non-void function [-Werror=return-type]
77
78         * b3/B3TypeMap.h:
79         (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().
80
81 2016-06-27  Keith Miller  <keith_miller@apple.com>
82
83         Fix bad assert in StructureRareData::setObjectToStringValue
84         https://bugs.webkit.org/show_bug.cgi?id=159171
85         <rdar://problem/26987355>
86
87         Reviewed by Mark Lam.
88
89         We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
90         There are many reasons it might fail including that there is a proxy somewhere on the
91         prototype chain of the object.
92
93         * runtime/StructureRareData.cpp:
94         (JSC::StructureRareData::setObjectToStringValue):
95         * tests/stress/object-toString-with-proxy.js: Added.
96         (get target):
97
98 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
99
100         Crashing at an unreachable code trap in FTL should give more information
101         https://bugs.webkit.org/show_bug.cgi?id=159177
102
103         Reviewed by Saam Barati.
104         
105         This stuffs information into registers so that we have some chance of seeing what happened
106         by looking at the register dumps.
107
108         * assembler/AbortReason.h:
109         * ftl/FTLLowerDFGToB3.cpp:
110         (JSC::FTL::DFG::ftlUnreachable):
111         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
112         (JSC::FTL::DFG::LowerDFGToB3::crash):
113
114 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
115
116         Clean up resetting reachability in B3/Air
117         https://bugs.webkit.org/show_bug.cgi?id=159170
118
119         Reviewed by Geoffrey Garen.
120         
121         When I fixed bug 159165, I took the brute force approach. I still used the
122         B3::resetReachability() method, and changed the callback to record the set of deleted values
123         instead of deleting them eagerly. But this means tracking the set of deleted values, even
124         though resetReachability() already internally tracks the set of deleted blocks. You can find
125         out if a value is deleted by asking if its owning block was deleted.
126         
127         So, this change refactors B3::resetReachability() into a new helper called
128         B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
129         client delete blocks. This lets Air delete blocks the same way that it did before, and it
130         lets B3 use the isBlockDead() method (which is a glorified proxy for
131         block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
132         Upsilons that point to dead Phis into Nops before deleting the blocks.
133         
134         This shouldn't affect performance or anything real. It just makes the code cleaner.
135
136         * b3/B3BasicBlockUtils.h:
137         (JSC::B3::updatePredecessorsAfter):
138         (JSC::B3::recomputePredecessors):
139         (JSC::B3::isBlockDead):
140         (JSC::B3::resetReachability): Deleted.
141         * b3/B3Procedure.cpp:
142         (JSC::B3::Procedure::resetReachability):
143         (JSC::B3::Procedure::invalidateCFG):
144         * b3/air/AirCode.cpp:
145         (JSC::B3::Air::Code::resetReachability):
146         (JSC::B3::Air::Code::dump):
147
148 2016-06-27  Brian Burg  <bburg@apple.com>
149
150         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
151         https://bugs.webkit.org/show_bug.cgi?id=159075
152         <rdar://problem/26094341>
153
154         Reviewed by Filip Pizlo.
155
156         This change caused JSC stress tests to all hit an assertion in RunLoop.
157         We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
158         clients like testapi and jsc don't ever call initializeMainRunLoop().
159
160         * inspector/agents/InspectorHeapAgent.cpp:
161         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
162
163 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
164
165         B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
166         https://bugs.webkit.org/show_bug.cgi?id=159165
167
168         Reviewed by Mark Lam.
169         
170         You can delete an unreachable block that has a Phi but some prior block may still have an
171         Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
172         exits or it can happen if we remove some successor of a block and this block had an Upsilon
173         for one of the removed successors. These things are valid IR even if they are not canonical.
174         Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
175         in the end.
176         
177         The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.
178
179         * b3/B3Procedure.cpp:
180         (JSC::B3::Procedure::resetReachability): Fix the bug.
181         * b3/B3Validate.h:
182         * b3/testb3.cpp:
183         (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
184         * dfg/DFGGraph.cpp:
185         (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.
186
187 2016-06-27  Keith Miller  <keith_miller@apple.com>
188
189         Add comment to Module feature in features.json
190         https://bugs.webkit.org/show_bug.cgi?id=159159
191
192         Reviewed by Saam Barati.
193
194         * features.json:
195
196 2016-06-27  Keith Miller  <keith_miller@apple.com>
197
198         Update features.json for ES6 completed features.
199         https://bugs.webkit.org/show_bug.cgi?id=159152
200
201         Reviewed by Mark Lam.
202
203         * features.json:
204
205 2016-06-25  Filip Pizlo  <fpizlo@apple.com>
206
207         B3 should not use Nops when deleting unreachable code
208         https://bugs.webkit.org/show_bug.cgi?id=159120
209         rdar://problem/26500743
210
211         Reviewed by Michael Saboff.
212         
213         Prior to this change, transformations that obviated the need for some value could choose
214         from these ways to kill it:
215         
216         - replaceWithIdentity() if we're replacing with another value.
217         - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
218           value.
219         - deleteValue() if the code is unreachable.
220         
221         The bug here is that reduceStrength() was being clever about how to get rid of a value.
222         reduceStrength() may find a Check that must always exit. The goal is to remove any code
223         dominated by the Check. But it would be awkward to eagerly delete all of the blocks
224         dominated by this one. So this code took a much simpler approach: it would
225         replaceWithNop() for all of the values in this block after the Check and it would replace
226         the terminal with Oops.
227         
228         But this corrupts the IR in a subtle way: some of those values may have been non-Void but
229         now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
230         dominated by the one with the Check are unreachable, so it will run all sorts of
231         optimizations on those blocks. This could have probably manifested as many different kinds
232         of badness, but the way I found out about this issue was through a crash in
233         IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
234         statement over a child's type.
235         
236         We could fix this by making rangeFor() tolerate Void. But I think that this would be
237         dangerous. There could easily be other places in reduceStrength() that assume that value's
238         children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
239         prevent other optimizations from breaking the children-are-not-Void rule.
240         
241         This introduces two high-level changes:
242         
243         - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
244           would cause reduceStrength() to instacrash in its Check optimization. Almost all other
245           uses of replaceWithNop() were already following this rule, so they were fine. One other
246           place was using replaceWithNop() on non-Void values after arranging for them to no
247           longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
248           doesn't have any type assertions.
249         
250         - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
251           Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
252           that the code is unreachable then it produces something that is guaranteed to be deleted
253           by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
254           to something harmless and cheap. This means replacing the value with an identity that
255           points to a bottom constant (the 0 for whatever type we have), or just replacing it with
256           Nop if it's Void.
257         
258         This also adds a test case for the reason why we do this: we may have two blocks, where
259         the first block unconditionally exits while dominating the second block. The second block
260         references values in the part of the first block that is unreachable. In trunk, this test
261         would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
262         reference a Nop in the first block.
263         
264         This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
265         confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
266         statement in IntRange::top(Type), clang was merging that trap with the trap it used for
267         Vector OOB. The top of the stack in crash dumps looked like:
268         
269             JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
270         
271         Where Vector.h:655 is:
272         
273             OverflowHandler::overflowed();
274
275         But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
276         are both traps, so they got merged despite differences in debug info. This bug would have
277         been so much easier to fix if I had the right line number.
278
279         * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
280         (JSC::B3::BottomProvider::BottomProvider):
281         (JSC::B3::BottomProvider::operator()):
282         * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
283         (JSC::B3::InsertionSet::insertBottom):
284         (JSC::B3::InsertionSet::execute):
285         (JSC::B3::InsertionSet::bottomForType):
286         * b3/B3InsertionSet.h:
287         * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
288         * b3/B3Procedure.h:
289         * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
290         * b3/B3ReduceStrength.h:
291         * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
292         * b3/B3Value.cpp:
293         (JSC::B3::Value::replaceWithIdentity):
294         (JSC::B3::Value::replaceWithNop):
295         (JSC::B3::Value::replaceWithNopIgnoringType):
296         * b3/B3Value.h:
297         * b3/B3ValueInlines.h:
298         (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
299         (JSC::B3::Value::as):
300         * b3/testb3.cpp: Add new tests!
301         (JSC::B3::testLateRegister):
302         (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
303         (JSC::B3::zero):
304         (JSC::B3::run):
305
306 2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>
307
308         REGRESSION: Web Inspector: Text search broken in resources with <CR>
309         https://bugs.webkit.org/show_bug.cgi?id=159110
310         <rdar://problem/27008485>
311
312         Reviewed by Brian Burg.
313
314         * inspector/ContentSearchUtilities.cpp:
315         (Inspector::ContentSearchUtilities::lineEndings):
316         The frontend moved to only treated newlines as line endings in
317         the TextEditor. The backend however was looking for many
318         different types of line endings (\r\n, \r, \n). This caused
319         the line endings to ultimately differ between the frontend
320         and the backend, so the frontend couldn't find the lines that
321         the backend was claiming search results were on. Change the
322         backend to only look for \n line endings.
323
324 2016-06-27  Brian Burg  <bburg@apple.com>
325
326         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
327         https://bugs.webkit.org/show_bug.cgi?id=159075
328         <rdar://problem/26094341>
329
330         Reviewed by Timothy Hatcher.
331
332         Move the asynchronous work to a task class that can be cancelled when the
333         heap agent is reset, disabled or destroyed.
334
335         * inspector/agents/InspectorHeapAgent.cpp:
336         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
337         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
338         (Inspector::SendGarbageCollectionEventsTask::reset):
339         (Inspector::SendGarbageCollectionEventsTask::timerFired):
340         Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
341         It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
342         The data vector is guarded with a lock so that garbageCollected() can safely add
343         collection data from a non-main thread while the main thread sends out events.
344
345         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
346         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
347         (Inspector::InspectorHeapAgent::disable):
348         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
349
350         (Inspector::InspectorHeapAgent::didGarbageCollect):
351         Add the collection data to the task, which will dispatch an event for it asynchronously.
352
353         * inspector/agents/InspectorHeapAgent.h:
354
355 2016-06-27  Michael Saboff  <msaboff@apple.com>
356
357         ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
358         https://bugs.webkit.org/show_bug.cgi?id=158505
359
360         Reviewed by Geoffrey Garen.
361
362         This change makes it so that the CharacterClassEscape \w matches the inverse of
363         \W and vice versa for unicode, ignore case RegExp's.
364
365         Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
366         k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
367         This was due to how the ES6 standard defined matching of character classes
368         specifically that the abstract operation "Canonicalize()" is called for the
369         character to be matched AND for the characters in the character class we are
370         matching against.  This change is to make \W always be the inverse of \w.
371         It is still the case that the characters that match against \w changes
372         depending on a regular expression's flags.
373
374         The only real changes occur for regular expressions with both the unicode and
375         ignore case flags set.  Updated the character class generator to make 
376         nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
377         Changed BytecodePattern.wordcharCharacterClass to use the correct
378         word character class for the flags.  Simplfied character class set up in
379         in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
380         invert as appropriate when unicode and ignore case are both set.
381
382         * create_regex_tables:
383         * yarr/YarrInterpreter.h:
384         (JSC::Yarr::BytecodePattern::BytecodePattern):
385         * yarr/YarrPattern.cpp:
386         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
387
388 2016-06-25  Keith Miller  <keith_miller@apple.com>
389
390         DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
391         https://bugs.webkit.org/show_bug.cgi?id=159117
392         <rdar://problem/26996781>
393
394         Reviewed by Saam Barati.
395
396         DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
397         This is clearly not always the case and we should be able to handle it.
398
399         * dfg/DFGByteCodeParser.cpp:
400         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
401         * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
402         (let.foo.Object.test):
403
404 2016-06-24  Filip Pizlo  <fpizlo@apple.com>
405
406         B3 should die sooner if a Value has the wrong number of children
407         https://bugs.webkit.org/show_bug.cgi?id=159108
408
409         Reviewed by Mark Lam.
410         
411         I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
412         ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
413         the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
414         Clearly those should never go out-of-bounds.
415         
416         Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
417         wrong number of children, and that path is not tested by any of our tests. This patch adds
418         release assertions that will catch the latter.
419         
420         I've tested this a lot. It's not a regression on our benchmarks.
421
422         * b3/B3Opcode.h:
423         * b3/B3Value.cpp:
424         (JSC::B3::Value::dumpMeta):
425         (JSC::B3::Value::typeFor):
426         (JSC::B3::Value::badOpcode):
427         (JSC::B3::Value::checkOpcode): Deleted.
428         * b3/B3Value.h:
429
430 2016-06-24  Mark Lam  <mark.lam@apple.com>
431
432         [JSC] Error prototypes are called on remote scripts.
433         https://bugs.webkit.org/show_bug.cgi?id=52192
434
435         Reviewed by Keith Miller.
436
437         Added a sanitizedToString() to the Error instance object so that it can be used
438         to get an error string without invoking getters and proxies.
439
440         * runtime/ErrorInstance.cpp:
441         (JSC::ErrorInstance::finishCreation):
442         (JSC::ErrorInstance::sanitizedToString):
443         * runtime/ErrorInstance.h:
444         (JSC::ErrorInstance::createStructure):
445         (JSC::ErrorInstance::runtimeTypeForCause):
446         (JSC::ErrorInstance::clearRuntimeTypeForCause):
447
448 2016-06-24  Commit Queue  <commit-queue@webkit.org>
449
450         Unreviewed, rolling out r202443.
451         https://bugs.webkit.org/show_bug.cgi?id=159105
452
453         Introduced memory corruption crashes (Requested by ap on
454         #webkit).
455
456         Reverted changeset:
457
458         "Web Inspector: CRASH in backend at
459         Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
460         closing frontend/inspected page"
461         https://bugs.webkit.org/show_bug.cgi?id=159075
462         http://trac.webkit.org/changeset/202443
463
464 2016-06-24  Brian Burg  <bburg@apple.com>
465
466         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
467         https://bugs.webkit.org/show_bug.cgi?id=159075
468         <rdar://problem/26094341>
469
470         Reviewed by Joseph Pecoraro.
471
472         Move the asynchronous work to a task class that can be cancelled when the
473         heap agent is reset, disabled or destroyed.
474
475         * inspector/agents/InspectorHeapAgent.cpp:
476         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
477         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
478         (Inspector::SendGarbageCollectionEventsTask::reset):
479         (Inspector::SendGarbageCollectionEventsTask::timerFired):
480         Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
481         It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.
482
483         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
484         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
485         (Inspector::InspectorHeapAgent::disable):
486         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
487
488         (Inspector::InspectorHeapAgent::didGarbageCollect):
489         Send the object to the task to be dispatched asynchronously.
490
491         * inspector/agents/InspectorHeapAgent.h:
492
493 2016-06-24  Commit Queue  <commit-queue@webkit.org>
494
495         Unreviewed, rolling out r202413.
496         https://bugs.webkit.org/show_bug.cgi?id=159097
497
498         Broke many JSC tests (Requested by ap on #webkit).
499
500         Reverted changeset:
501
502         "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
503         accept non number values"
504         https://bugs.webkit.org/show_bug.cgi?id=154022
505         http://trac.webkit.org/changeset/202413
506
507 2016-06-23  Benjamin Poulain  <bpoulain@apple.com>
508
509         OOM Assertion failure in Array.prototype.toString
510         https://bugs.webkit.org/show_bug.cgi?id=158793
511
512         Reviewed by Saam Barati.
513
514         JSString::create() taking a StringImpl was using a signed integer
515         for the length of the string.
516         The problem is StringImpl uses an unsigned integer. When a large string
517         was passed to JSString, the signed integer would be negative and crash
518         JSString.
519
520         * runtime/JSString.h:
521         (JSC::JSString::create):
522
523 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>
524
525         [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
526         https://bugs.webkit.org/show_bug.cgi?id=154022
527
528         Reviewed by Filip Pizlo.
529
530         We aim at optimizing @toInteger operation.
531         While it still has an unoptimized part[1], this patch should be a first step.
532
533         We introduce the @toNumber builtin intrinsic operation.
534         This converts the given value to the JS number by emitting op_to_number bytecode.
535         Previously @toInteger called C++ @Number constructor for that purpose.
536
537         And in DFG, op_to_number is converted to DFG ToNumber node.
538         During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
539         we just fall back to calling the C++ function.
540
541         To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
542         to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.
543
544         Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
545         But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.
546
547         By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.
548
549         ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
550         This value profiling is provided from either NumberConstructor's call operation or op_to_number.
551
552         The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
553         And ASMBench/n-body.c also shows stable ~2% progression.
554
555         [1]: https://bugs.webkit.org/show_bug.cgi?id=153738
556
557         * CMakeLists.txt:
558         * DerivedSources.make:
559         * JavaScriptCore.xcodeproj/project.pbxproj:
560         * builtins/BuiltinNames.h:
561         * builtins/GlobalObject.js:
562         (globalPrivate.isFinite):
563         (globalPrivate.isNaN):
564         (globalPrivate.toInteger): Deleted.
565         (globalPrivate.toLength): Deleted.
566         (globalPrivate.isDictionary): Deleted.
567         (globalPrivate.speciesGetter): Deleted.
568         (globalPrivate.speciesConstructor): Deleted.
569         * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
570         (globalPrivate.toInteger):
571         (globalPrivate.toLength):
572         (globalPrivate.isDictionary):
573         (globalPrivate.speciesGetter):
574         (globalPrivate.speciesConstructor):
575         * builtins/NumberConstructor.js: Added.
576         (isFinite):
577         (isNaN):
578         * bytecode/BytecodeIntrinsicRegistry.cpp:
579         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
580         * bytecode/BytecodeIntrinsicRegistry.h:
581         * bytecode/BytecodeList.json:
582         * bytecode/CodeBlock.cpp:
583         (JSC::CodeBlock::dumpBytecode):
584         (JSC::CodeBlock::finishCreation):
585         * bytecompiler/BytecodeGenerator.cpp:
586         (JSC::BytecodeGenerator::emitUnaryOp):
587         (JSC::BytecodeGenerator::emitUnaryOpProfiled):
588         * bytecompiler/BytecodeGenerator.h:
589         (JSC::BytecodeGenerator::emitToNumber):
590         * bytecompiler/NodesCodegen.cpp:
591         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
592         (JSC::UnaryPlusNode::emitBytecode):
593         * dfg/DFGAbstractInterpreterInlines.h:
594         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
595         * dfg/DFGByteCodeParser.cpp:
596         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
597         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
598         (JSC::DFG::ByteCodeParser::parseBlock):
599         We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
600         According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.
601
602         * dfg/DFGClobberize.h:
603         (JSC::DFG::clobberize):
604         * dfg/DFGConstantFoldingPhase.cpp:
605         (JSC::DFG::ConstantFoldingPhase::foldConstants):
606         * dfg/DFGDoesGC.cpp:
607         (JSC::DFG::doesGC):
608         * dfg/DFGFixupPhase.cpp:
609         (JSC::DFG::FixupPhase::fixupNode):
610         (JSC::DFG::FixupPhase::fixupToNumber):
611         * dfg/DFGNode.h:
612         (JSC::DFG::Node::hasHeapPrediction):
613         * dfg/DFGNodeType.h:
614         * dfg/DFGOperations.cpp:
615         * dfg/DFGOperations.h:
616         * dfg/DFGPredictionPropagationPhase.cpp:
617         Alway rely on the heap prediction.
618
619         * dfg/DFGSafeToExecute.h:
620         (JSC::DFG::safeToExecute):
621         * dfg/DFGSpeculativeJIT32_64.cpp:
622         (JSC::DFG::SpeculativeJIT::compile):
623         As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
624         `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
625         it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
626         Currently, we allocate the additional temporary register for that scratch register.
627
628         * dfg/DFGSpeculativeJIT64.cpp:
629         (JSC::DFG::SpeculativeJIT::compile):
630         Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
631         This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
632         we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
633         the spills to call the operation. The example of the actually emitted code is the following.
634
635         76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
636             0x7f986d5fe693: test %rax, %r14
637             0x7f986d5fe696: jz 0x7f986d5fe6a1
638             0x7f986d5fe69c: jmp 0x7f986d5fe6d1
639             0x7f986d5fe6a1: mov %rax, %rsi
640             0x7f986d5fe6a4: mov %rbp, %rdi
641             0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
642             0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
643             0x7f986d5fe6b8: call *%r11
644             0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
645             0x7f986d5fe6c5: mov (%r11), %r11
646             0x7f986d5fe6c8: test %r11, %r11
647             0x7f986d5fe6cb: jnz 0x7f986d5fe88c
648
649         It effectively removes the unnecessary spill to call the operation!
650
651         * ftl/FTLCapabilities.cpp:
652         (JSC::FTL::canCompile):
653         * ftl/FTLLowerDFGToB3.cpp:
654         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
655         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
656         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
657         * jit/AssemblyHelpers.h:
658         (JSC::AssemblyHelpers::branchIfNumber):
659         (JSC::AssemblyHelpers::branchIfNotNumber):
660         * jit/JITOpcodes.cpp:
661         (JSC::JIT::emit_op_to_number):
662         * jit/JITOpcodes32_64.cpp:
663         (JSC::JIT::emit_op_to_number):
664         * llint/LowLevelInterpreter32_64.asm:
665         * llint/LowLevelInterpreter64.asm:
666         * parser/Nodes.h:
667         (JSC::UnaryOpNode::opcodeID):
668         * runtime/CommonSlowPaths.cpp:
669         (JSC::SLOW_PATH_DECL):
670         * runtime/JSGlobalObject.cpp:
671         (JSC::JSGlobalObject::init):
672         * runtime/JSGlobalObjectFunctions.cpp:
673         (JSC::globalFuncIsNaN): Deleted.
674         (JSC::globalFuncIsFinite): Deleted.
675         * runtime/JSGlobalObjectFunctions.h:
676         * runtime/MathCommon.h:
677         (JSC::maxSafeInteger):
678         (JSC::minSafeInteger):
679         * runtime/NumberConstructor.cpp:
680         (JSC::NumberConstructor::finishCreation):
681         (JSC::numberConstructorFuncIsFinite): Deleted.
682         (JSC::numberConstructorFuncIsNaN): Deleted.
683         * runtime/NumberConstructor.h:
684         * tests/stress/Number-isNaN-basics.js: Added.
685         (numberIsNaNOnInteger):
686         (testNumberIsNaNOnIntegers):
687         (verifyNumberIsNaNOnIntegerWithOtherTypes):
688         (numberIsNaNOnDouble):
689         (testNumberIsNaNOnDoubles):
690         (verifyNumberIsNaNOnDoublesWithOtherTypes):
691         (numberIsNaNNoArguments):
692         (numberIsNaNTooManyArguments):
693         (testNumberIsNaNOnConstants):
694         (numberIsNaNStructTransition):
695         (Number.isNaN):
696         * tests/stress/global-is-finite.js: Added.
697         (shouldBe):
698         * tests/stress/global-is-nan.js: Added.
699         (shouldBe):
700         * tests/stress/global-isNaN-basics.js: Added.
701         (isNaNOnInteger):
702         (testIsNaNOnIntegers):
703         (verifyIsNaNOnIntegerWithOtherTypes):
704         (isNaNOnDouble):
705         (testIsNaNOnDoubles):
706         (verifyIsNaNOnDoublesWithOtherTypes):
707         (verifyIsNaNOnCoercedTypes):
708         (isNaNNoArguments):
709         (isNaNTooManyArguments):
710         (testIsNaNOnConstants):
711         (isNaNTypeCoercionSideEffects):
712         (i.value.isNaNTypeCoercionSideEffects.valueOf):
713         (isNaNStructTransition):
714         (isNaN):
715         * tests/stress/number-is-finite.js: Added.
716         (shouldBe):
717         (test2):
718         (test3):
719         * tests/stress/number-is-nan.js: Added.
720         (shouldBe):
721         (test2):
722         (test3):
723         * tests/stress/to-number-basics.js: Added.
724         (shouldBe):
725         * tests/stress/to-number-convert-identity-without-execution.js: Added.
726         (shouldBe):
727         (object.valueOf):
728         (valueOf):
729         * tests/stress/to-number-int52.js: Added.
730         (shouldBe):
731         (object.valueOf):
732         * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
733         (shouldBe):
734         (object.valueOf):
735         (valueOf):
736         * tests/stress/to-number-intrinsic-int52.js: Added.
737         (shouldBe):
738         (object.valueOf):
739         * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
740         (shouldBe):
741         (object.valueOf):
742         * tests/stress/to-number-intrinsic-value-profiling.js: Added.
743         (shouldBe):
744         (object.valueOf):
745         * tests/stress/to-number-object-without-execution.js: Added.
746         (shouldBe):
747         (object.valueOf):
748         * tests/stress/to-number-object.js: Added.
749         (shouldBe):
750         (test12):
751         (object1.valueOf):
752         (test2):
753         (test22):
754         (object2.valueOf):
755         (test3):
756         (test32):
757         (object3.valueOf):
758         * tests/stress/to-number-value-profiling.js: Added.
759         (shouldBe):
760         (object.valueOf):
761
762 2016-06-23  Saam Barati  <sbarati@apple.com>
763
764         DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
765         https://bugs.webkit.org/show_bug.cgi?id=159064
766         <rdar://problem/26599119>
767
768         Reviewed by Filip Pizlo.
769
770         The DFG has a list of m_slowPathLambdas that are code generators it emits
771         amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
772         This caused us to use whatever Node happened to be used as the currentNode at the time
773         we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
774         frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
775         the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
776         a calleeRecovery that will not be in sync with the current stack state. Trying
777         to recover that callee will often lead to a crash. The solution is to update
778         m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.
779
780         I found this bug because we were inside this bad state when calling an operation
781         that happened to have a DeferGC. When this DeferGC actually GCed, it would
782         take a StackTrace, which would lead to a crash because we were updating
783         ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
784         in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
785         However, this CallSiteIndex didn't correspond to the actual state of execution
786         of the program. I'm adding new options to make reproducing DeferGC related
787         bugs easier by making DeferGC force a GC according to some probability. To
788         always have DeferGC force a GC, you can set that probability to 1.
789
790         There is a second bug that I discovered after solving the above bug. We were
791         using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
792         in the DFG. This would cause us to take a stack trace when the call frame was
793         in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
794         which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
795         However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
796         This would lead to a crash when taking a stack trace. The solution is to prevent
797         stack traces from being taken when the program is in this state by using
798         DeferGCForAWhie instead of DeferGC.
799
800         * dfg/DFGOperations.cpp:
801         * dfg/DFGSpeculativeJIT.cpp:
802         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
803         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
804         * dfg/DFGSpeculativeJIT.h:
805         * heap/Heap.h:
806         * heap/HeapInlines.h:
807         (JSC::Heap::collectIfNecessaryOrDefer):
808         (JSC::Heap::collectAccordingToDeferGCProbability):
809         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
810         (JSC::Heap::markListSet):
811         * runtime/Options.cpp:
812         (JSC::recomputeDependentOptions):
813         (JSC::Options::initialize):
814         * runtime/Options.h:
815         * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
816         (foo):
817         (bar):
818
819 2016-06-23  Filip Pizlo  <fpizlo@apple.com>
820
821         Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
822         https://bugs.webkit.org/show_bug.cgi?id=158806
823
824         Reviewed by Saam Barati.
825         
826         If we try to compile a CodeBlock that we already tried compiling in the past then we need
827         to clean up the data structures that were partly filled in by the failed compile. That
828         causes some races, since the DFG may be trying to parse those data structures while we are
829         clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
830         the races.
831
832         * bytecode/CodeBlock.cpp:
833         (JSC::CodeBlock::dumpBytecode):
834         (JSC::CodeBlock::getStubInfoMap):
835         (JSC::CodeBlock::getCallLinkInfoMap):
836         (JSC::CodeBlock::getByValInfoMap):
837         (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
838         (JSC::CodeBlock::resetJITData):
839         (JSC::CodeBlock::visitOSRExitTargets):
840         (JSC::CodeBlock::setSteppingMode):
841         (JSC::CodeBlock::addRareCaseProfile):
842         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
843         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
844         (JSC::CodeBlock::resultProfileForBytecodeOffset):
845         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
846         (JSC::CodeBlock::couldTakeSpecialFastCase):
847         (JSC::CodeBlock::ensureResultProfile):
848         * bytecode/CodeBlock.h:
849         (JSC::CodeBlock::getFromAllValueProfiles):
850         (JSC::CodeBlock::numberOfRareCaseProfiles):
851         (JSC::CodeBlock::numberOfResultProfiles):
852         (JSC::CodeBlock::numberOfArrayProfiles):
853         (JSC::CodeBlock::arrayProfiles):
854         (JSC::CodeBlock::addRareCaseProfile): Deleted.
855         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
856         (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
857         * dfg/DFGByteCodeParser.cpp:
858         (JSC::DFG::ByteCodeParser::makeSafe):
859         * dfg/DFGGraph.cpp:
860         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
861         * jit/JIT.cpp:
862         (JSC::JIT::link):
863         * jit/JITWorklist.cpp:
864         (JSC::JITWorklist::compileNow):
865
866 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
867
868         Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
869         https://bugs.webkit.org/show_bug.cgi?id=158110
870         <rdar://problem/26498584>
871
872         Reviewed by Andreas Kling.
873
874         * heap/Heap.cpp:
875         (JSC::Heap::willStartCollection):
876         (JSC::Heap::didFinishCollection):
877         * heap/Heap.h:
878         (JSC::Heap::externalMemorySize):
879         * heap/HeapInlines.h:
880         (JSC::Heap::reportExternalMemoryVisited):
881         Keep count of external memory we visit.
882
883         * heap/SlotVisitor.h:
884         * heap/SlotVisitorInlines.h:
885         (JSC::SlotVisitor::reportExternalMemoryVisited):
886         Report external memory visited like we do extra memory, since
887         it will be some subset of extra memory that is external.
888
889 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
890
891         Web Inspector: Snapshots should be cleared at some point
892         https://bugs.webkit.org/show_bug.cgi?id=157907
893         <rdar://problem/26373610>
894
895         Reviewed by Timothy Hatcher.
896
897         * heap/HeapSnapshotBuilder.h:
898         * heap/HeapSnapshotBuilder.cpp:
899         (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
900         Provide a way to reset the object identifier counter.
901
902         * inspector/agents/InspectorHeapAgent.h:
903         * inspector/agents/InspectorHeapAgent.cpp:
904         (Inspector::InspectorHeapAgent::clearHeapSnapshots):
905         Make clearHeapSnapshots protected, so it can be called from a
906         a PageHeapAgent on page navigations.
907
908 2016-06-22  Saam barati  <sbarati@apple.com>
909
910         TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
911         https://bugs.webkit.org/show_bug.cgi?id=159037
912         <rdar://problem/26935349>
913
914         Reviewed by Benjamin Poulain.
915
916         The primary focus of this patch is to make the concurrent
917         baseline JIT work with the type profiler. We were clearing
918         the type profiler log on the background baseline compiler
919         thread which lead to bad things happening. This patch fixes
920         this by processing the log before we launch the compile on
921         a background thread.
922
923         Secondly, I audited the type profiler code inside the DFG,
924         and found that we were doing some racy things. I haven't
925         seen any crashes because of these things, but it is possible
926         that they exist. We were grabbing a RefPtr to a TypeSet,
927         even though TypeSet was RefCounted and not ThreadSafeRefCounted.
928         This patch makes TypeSet ThreadSafeRefCounted. We were
929         also copying a StructureSet while the execution thread could
930         be augmenting the StructureSet. This patch puts changes to 
931         TypeSet's StructureSet behind a ConcurrentJITLock.
932
933         I've also added two more large running tests that run with the
934         type profiler enabled. These are here just to catch any major bugs
935         in the type profiler implementation.
936
937         * jit/JIT.cpp:
938         (JSC::JIT::compileWithoutLinking):
939         (JSC::JIT::privateCompile):
940         (JSC::JIT::privateCompileExceptionHandlers):
941         (JSC::JIT::doMainThreadPreparationBeforeCompile):
942         (JSC::JIT::frameRegisterCountFor):
943         * jit/JIT.h:
944         (JSC::JIT::compile):
945         * jit/JITWorklist.cpp:
946         (JSC::JITWorklist::Plan::Plan):
947         (JSC::JITWorklist::Plan::compileInThread):
948         * runtime/TypeSet.cpp:
949         (JSC::TypeSet::addTypeInformation):
950         (JSC::TypeSet::invalidateCache):
951         * runtime/TypeSet.h:
952         (JSC::TypeSet::create):
953         (JSC::TypeSet::isEmpty):
954         (JSC::TypeSet::seenTypes):
955         (JSC::TypeSet::structureSet):
956         * tests/typeProfiler/deltablue-for-of.js: Added.
957         * tests/typeProfiler/getter-richards.js: Added.
958
959 2016-06-22  Keith Miller  <keith_miller@apple.com>
960
961         We should have a DFG intrinsic that checks if a value is a TypedArrayView
962         https://bugs.webkit.org/show_bug.cgi?id=159048
963
964         Reviewed by Saam Barati.
965
966         This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
967         The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
968         DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
969         These changes are needed to fix regressions in %TypedArray%.prototype.subarray.
970
971         * builtins/BuiltinNames.h:
972         * dfg/DFGAbstractInterpreterInlines.h:
973         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
974         * dfg/DFGByteCodeParser.cpp:
975         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
976         * dfg/DFGClobberize.h:
977         (JSC::DFG::clobberize):
978         * dfg/DFGDoesGC.cpp:
979         (JSC::DFG::doesGC):
980         * dfg/DFGFixupPhase.cpp:
981         (JSC::DFG::FixupPhase::fixupNode):
982         * dfg/DFGNodeType.h:
983         * dfg/DFGPredictionPropagationPhase.cpp:
984         * dfg/DFGSafeToExecute.h:
985         (JSC::DFG::safeToExecute):
986         * dfg/DFGSpeculativeJIT.cpp:
987         (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
988         * dfg/DFGSpeculativeJIT.h:
989         * dfg/DFGSpeculativeJIT32_64.cpp:
990         (JSC::DFG::SpeculativeJIT::compile):
991         * dfg/DFGSpeculativeJIT64.cpp:
992         (JSC::DFG::SpeculativeJIT::compile):
993         * ftl/FTLCapabilities.cpp:
994         (JSC::FTL::canCompile):
995         * ftl/FTLLowerDFGToB3.cpp:
996         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
997         (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
998         (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
999         * runtime/Intrinsic.h:
1000         * runtime/JSGlobalObject.cpp:
1001         (JSC::JSGlobalObject::init):
1002         * runtime/JSTypedArrayViewPrototype.cpp:
1003         (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
1004         * runtime/JSTypedArrayViewPrototype.h:
1005         * tests/stress/istypedarrayview-intrinsic.js: Added.
1006         (makeFn):
1007         (typedArrays.forEach):
1008         (let.test):
1009         (test):
1010
1011 2016-06-21  Anders Carlsson  <andersca@apple.com>
1012
1013         Fix build.
1014
1015         * Configurations/FeatureDefines.xcconfig:
1016
1017 2016-06-21  Geoffrey Garen  <ggaren@apple.com>
1018
1019         Options::useImmortalObjects is not safe for conservative GC
1020         https://bugs.webkit.org/show_bug.cgi?id=158999
1021
1022         Reviewed by Geoffrey Garen.
1023
1024         useImmortalObjects set the mark bit to keep an object from being
1025         reallocated. This had the negative side-effect of convincing the
1026         conservative marker that the object was a valid and live cell, which
1027         would cause us to visit garbage.
1028
1029         * heap/Heap.cpp:
1030         (JSC::Heap::didFinishCollection):
1031         (JSC::Heap::resumeCompilerThreads):
1032         (JSC::Heap::setFullActivityCallback):
1033         (JSC::Heap::markDeadObjects): Deleted.
1034         * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
1035         a conservative GC.
1036
1037         * heap/MarkedAllocator.cpp:
1038         (JSC::MarkedAllocator::retire): New helper.
1039
1040         (JSC::MarkedAllocator::reset): Automatically retire old blocks when
1041         we're doing the immortal objects thing. This has the effect of
1042         preserving memory for debugging because we never recycle a previously
1043         allocated block.
1044
1045 2016-06-21  Anders Carlsson  <andersca@apple.com>
1046
1047         Begin moving the Apple Pay code to the open source repository
1048         https://bugs.webkit.org/show_bug.cgi?id=158998
1049
1050         Reviewed by Tim Horton.
1051
1052         * Configurations/FeatureDefines.xcconfig:
1053         Add ENABLE_APPLE_PAY.
1054
1055 2016-06-21  Saam Barati  <sbarati@apple.com>
1056
1057         CodeBlock::shrinkToFit is racy
1058         https://bugs.webkit.org/show_bug.cgi?id=158994
1059         <rdar://problem/26920212>
1060
1061         Reviewed by Filip Pizlo.
1062
1063         To see why this is racy, consider the following scenario:
1064         - CodeBlock A is link()ing its baseline compile.
1065         - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
1066         - The race occurs when the link() step of the baseline compile calls shrinkToFit
1067           on its m_resultProfiles field without grabbing a lock. This leads to a bad
1068           time because the DFG compile will be reading from that vector as it's getting
1069           changed by the baseline link() method.
1070
1071         This race has always existed, though the move to a concurrent baseline
1072         JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
1073         grab its lock before shrinking the vector.
1074
1075         * bytecode/CodeBlock.cpp:
1076         (JSC::CodeBlock::shrinkToFit):
1077
1078 2016-06-21  David Kilzer  <ddkilzer@apple.com>
1079
1080         Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
1081         <https://webkit.org/b/158989>
1082
1083         Reviewed by Andy Estes.
1084
1085         * Configurations/ToolExecutable.xcconfig:
1086         (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
1087         * JavaScriptCore.xcodeproj/project.pbxproj:
1088         (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
1089         ToolExecutable.xcconfig.
1090         (PRODUCT_NAME): Remove.  This variable is already set for both
1091         testair and testb3 since those build configurations use
1092         ToolExecutable.xcconfig as a base.
1093
1094 2016-06-21  Saam Barati  <sbarati@apple.com>
1095
1096         LLInt doesn't throw stack exception overflow from parent frame
1097         https://bugs.webkit.org/show_bug.cgi?id=158962
1098         <rdar://problem/26902188>
1099
1100         Reviewed by Filip Pizlo.
1101
1102         All JIT tiers will throw stack overflow exceptions from the parent frame.
1103         The LLInt, on the other hand, did not use to. I've changed the LLInt to be
1104         consistent with the JITs. The reason I found this bug is because we had a
1105         test that would give different results depending on if the function was compiled
1106         in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
1107         JIT patch, this otherwise deterministic test became dependent on it being compiled
1108         in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
1109         because it runs the test with --useJIT=false.
1110
1111         * llint/LLIntSlowPaths.cpp:
1112         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1113         * tests/stress/llint-stack-overflow-location.js: Added.
1114         (stackTraceDescription):
1115         (foo):
1116         (catch):
1117
1118 2016-06-21  David Kilzer  <ddkilzer@apple.com>
1119
1120         CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
1121         <https://webkit.org/b/158990>
1122         <rdar://problem/26906273>
1123
1124         Reviewed by Dan Bernstein.
1125
1126         * Configurations/JSC.xcconfig:
1127         (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
1128         [sdk=iphone*] to apply setting to iOS Simulator as well.
1129         * Configurations/ToolExecutable.xcconfig:
1130         (CODE_SIGN_ENTITLEMENTS): Ditto.
1131
1132 2016-06-21  Keith Miller  <keith_miller@apple.com>
1133
1134         It should be easy to add a private global helper function for builtins
1135         https://bugs.webkit.org/show_bug.cgi?id=158893
1136
1137         Reviewed by Mark Lam.
1138
1139         This patch does two things. First it moves all the builtin names
1140         out of CommonIdentifiers and into BuiltinNames. This means that
1141         adding a new function to the Builtins does not require rebuilding
1142         all of JavaScriptCore. This patch also adds a new decorator to our
1143         builtins @privateGlobal that will automatically put the function
1144         on the global object. The name of the property will be the same as
1145         the private name of the function.
1146
1147         This patch, also, removes the JSArrayIterator.h/.cpp files
1148         as they no longer appear to be used in any real way. Finally,
1149         the builtins tests have been rebaselined. It appears this has
1150         not been done for a while so the expected files contain other
1151         changes.
1152
1153         * CMakeLists.txt:
1154         * JavaScriptCore.xcodeproj/project.pbxproj:
1155         * Scripts/builtins/builtins_generate_combined_header.py:
1156         (BuiltinsCombinedHeaderGenerator.generate_output):
1157         (generate_section_for_code_name_macro):
1158         (generate_section_for_global_private_code_name_macro):
1159         * Scripts/builtins/builtins_model.py:
1160         (BuiltinFunction.__init__):
1161         (BuiltinFunction.fromString):
1162         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
1163         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
1164         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
1165         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
1166         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
1167         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
1168         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
1169         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
1170         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
1171         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
1172         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
1173         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
1174         * builtins/ArrayIteratorPrototype.js:
1175         * builtins/ArrayPrototype.js:
1176         * builtins/BuiltinNames.h:
1177         * builtins/GeneratorPrototype.js:
1178         * builtins/GlobalObject.js:
1179         * builtins/PromiseOperations.js:
1180         * builtins/RegExpPrototype.js:
1181         * builtins/StringPrototype.js:
1182         * bytecode/BytecodeIntrinsicRegistry.cpp:
1183         * bytecompiler/BytecodeGenerator.cpp:
1184         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1185         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
1186         (JSC::BytecodeGenerator::emitGetTemplateObject):
1187         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
1188         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
1189         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
1190         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
1191         (JSC::BytecodeGenerator::emitGeneratorStateChange):
1192         * bytecompiler/NodesCodegen.cpp:
1193         (JSC::emitHomeObjectForCallee):
1194         (JSC::emitPutHomeObject):
1195         (JSC::FunctionNode::emitBytecode):
1196         * dfg/DFGOperations.cpp:
1197         * inspector/JSInjectedScriptHost.cpp:
1198         (Inspector::JSInjectedScriptHost::subtype):
1199         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
1200         * parser/Lexer.cpp:
1201         (JSC::Lexer<LChar>::parseIdentifier):
1202         (JSC::Lexer<UChar>::parseIdentifier):
1203         * parser/Nodes.h:
1204         * parser/Parser.cpp:
1205         (JSC::Parser<LexerType>::createGeneratorParameters):
1206         (JSC::Parser<LexerType>::parseExportDeclaration):
1207         * runtime/ArrayIteratorPrototype.cpp:
1208         * runtime/ArrayIteratorPrototype.h:
1209         * runtime/ArrayPrototype.cpp:
1210         * runtime/CommonIdentifiers.cpp:
1211         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
1212         * runtime/CommonIdentifiers.h:
1213         * runtime/CommonSlowPaths.cpp:
1214         (JSC::SLOW_PATH_DECL):
1215         * runtime/IntlDateTimeFormat.cpp:
1216         * runtime/IntlDateTimeFormatPrototype.cpp:
1217         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1218         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
1219         * runtime/IntlNumberFormatPrototype.cpp:
1220         (JSC::IntlNumberFormatPrototypeGetterFormat):
1221         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
1222         * runtime/IntlObjectInlines.h:
1223         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
1224         * runtime/JSArrayIterator.cpp: Removed.
1225         (JSC::JSArrayIterator::finishCreation): Deleted.
1226         (JSC::JSArrayIterator::kind): Deleted.
1227         (JSC::JSArrayIterator::iteratedValue): Deleted.
1228         * runtime/JSArrayIterator.h: Removed.
1229         (JSC::JSArrayIterator::createStructure): Deleted.
1230         (JSC::JSArrayIterator::create): Deleted.
1231         (JSC::JSArrayIterator::JSArrayIterator): Deleted.
1232         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1233         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1234         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1235         * runtime/JSGlobalObject.cpp:
1236         (JSC::JSGlobalObject::init):
1237         * runtime/JSInternalPromise.cpp:
1238         * runtime/JSInternalPromiseDeferred.cpp:
1239         (JSC::JSInternalPromiseDeferred::create):
1240         * runtime/JSPromise.cpp:
1241         (JSC::JSPromise::finishCreation):
1242         (JSC::JSPromise::result):
1243         * runtime/JSPromiseDeferred.cpp:
1244         (JSC::JSPromiseDeferred::create):
1245         * runtime/JSStringIterator.cpp:
1246         (JSC::JSStringIterator::finishCreation):
1247         (JSC::JSStringIterator::iteratedValue):
1248         (JSC::JSStringIterator::clone):
1249         * runtime/MapPrototype.cpp:
1250         (JSC::MapPrototype::finishCreation):
1251         * runtime/ObjectConstructor.cpp:
1252         (JSC::ObjectConstructor::finishCreation):
1253         * runtime/ReflectObject.cpp:
1254         (JSC::ReflectObject::finishCreation):
1255         * runtime/StringPrototype.cpp:
1256         (JSC::StringPrototype::finishCreation):
1257         * runtime/TypedArrayInlines.h:
1258
1259 2016-06-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1260
1261         [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS
1262         https://bugs.webkit.org/show_bug.cgi?id=158871
1263
1264         Reviewed by Sam Weinig.
1265
1266         Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties.
1267
1268         * builtins/ModuleLoaderObject.js:
1269         (newRegistryEntry):
1270         (fulfillFetch):
1271         (fulfillTranslate):
1272         (commitInstantiated):
1273         (requestFetch):
1274         (requestTranslate):
1275         (requestInstantiate):
1276         (requestResolveDependencies.):
1277         (requestResolveDependencies):
1278         (requestLink):
1279         (link):
1280         (provide):
1281         * bytecode/BytecodeIntrinsicRegistry.cpp:
1282         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1283         * bytecode/BytecodeIntrinsicRegistry.h:
1284         * runtime/ModuleLoaderObject.cpp:
1285         (JSC::ModuleLoaderObject::finishCreation): Deleted.
1286
1287 2016-06-20  Commit Queue  <commit-queue@webkit.org>
1288
1289         Unreviewed, rolling out r202248.
1290         https://bugs.webkit.org/show_bug.cgi?id=158960
1291
1292         breaks builds on the simulator (Requested by keith_mi_ on
1293         #webkit).
1294
1295         Reverted changeset:
1296
1297         "It should be easy to add a private global helper function for
1298         builtins"
1299         https://bugs.webkit.org/show_bug.cgi?id=158893
1300         http://trac.webkit.org/changeset/202248
1301
1302 2016-06-20  Keith Miller  <keith_miller@apple.com>
1303
1304         It should be easy to add a private global helper function for builtins
1305         https://bugs.webkit.org/show_bug.cgi?id=158893
1306
1307         Reviewed by Mark Lam.
1308
1309         This patch does two things. First it moves all the builtin names
1310         out of CommonIdentifiers and into BuiltinNames. This means that
1311         adding a new function to the Builtins does not require rebuilding
1312         all of JavaScriptCore. This patch also adds a new decorator to our
1313         builtins @privateGlobal that will automatically put the function
1314         on the global object. The name of the property will be the same as
1315         the private name of the function.
1316
1317         This patch, also, removes the JSArrayIterator.h/.cpp files
1318         as they no longer appear to be used in any real way. Finally,
1319         the builtins tests have been rebaselined. It appears this has
1320         not been done for a while so the expected files contain other
1321         changes.
1322
1323         * CMakeLists.txt:
1324         * JavaScriptCore.xcodeproj/project.pbxproj:
1325         * Scripts/builtins/builtins_generate_combined_header.py:
1326         (BuiltinsCombinedHeaderGenerator.generate_output):
1327         (generate_section_for_code_name_macro):
1328         (generate_section_for_global_private_code_name_macro):
1329         * Scripts/builtins/builtins_model.py:
1330         (BuiltinFunction.__init__):
1331         (BuiltinFunction.fromString):
1332         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
1333         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
1334         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
1335         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
1336         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
1337         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
1338         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
1339         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
1340         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
1341         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
1342         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
1343         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
1344         * builtins/ArrayIteratorPrototype.js:
1345         * builtins/ArrayPrototype.js:
1346         * builtins/BuiltinNames.h:
1347         * builtins/GeneratorPrototype.js:
1348         * builtins/GlobalObject.js:
1349         * builtins/PromiseOperations.js:
1350         * builtins/RegExpPrototype.js:
1351         * builtins/StringPrototype.js:
1352         * bytecode/BytecodeIntrinsicRegistry.cpp:
1353         * bytecompiler/BytecodeGenerator.cpp:
1354         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1355         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
1356         (JSC::BytecodeGenerator::emitGetTemplateObject):
1357         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
1358         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
1359         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
1360         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
1361         (JSC::BytecodeGenerator::emitGeneratorStateChange):
1362         * bytecompiler/NodesCodegen.cpp:
1363         (JSC::emitHomeObjectForCallee):
1364         (JSC::emitPutHomeObject):
1365         (JSC::FunctionNode::emitBytecode):
1366         * dfg/DFGOperations.cpp:
1367         * inspector/JSInjectedScriptHost.cpp:
1368         (Inspector::JSInjectedScriptHost::subtype):
1369         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
1370         * parser/Lexer.cpp:
1371         (JSC::Lexer<LChar>::parseIdentifier):
1372         (JSC::Lexer<UChar>::parseIdentifier):
1373         * parser/Nodes.h:
1374         * parser/Parser.cpp:
1375         (JSC::Parser<LexerType>::createGeneratorParameters):
1376         (JSC::Parser<LexerType>::parseExportDeclaration):
1377         * runtime/ArrayIteratorPrototype.cpp:
1378         * runtime/ArrayIteratorPrototype.h:
1379         * runtime/ArrayPrototype.cpp:
1380         * runtime/CommonIdentifiers.cpp:
1381         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
1382         * runtime/CommonIdentifiers.h:
1383         * runtime/CommonSlowPaths.cpp:
1384         (JSC::SLOW_PATH_DECL):
1385         * runtime/IntlDateTimeFormat.cpp:
1386         * runtime/IntlDateTimeFormatPrototype.cpp:
1387         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1388         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
1389         * runtime/IntlNumberFormatPrototype.cpp:
1390         (JSC::IntlNumberFormatPrototypeGetterFormat):
1391         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
1392         * runtime/IntlObjectInlines.h:
1393         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
1394         * runtime/JSArrayIterator.cpp: Removed.
1395         (JSC::JSArrayIterator::finishCreation): Deleted.
1396         (JSC::JSArrayIterator::kind): Deleted.
1397         (JSC::JSArrayIterator::iteratedValue): Deleted.
1398         * runtime/JSArrayIterator.h: Removed.
1399         (JSC::JSArrayIterator::createStructure): Deleted.
1400         (JSC::JSArrayIterator::create): Deleted.
1401         (JSC::JSArrayIterator::JSArrayIterator): Deleted.
1402         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1403         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1404         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1405         * runtime/JSGlobalObject.cpp:
1406         (JSC::JSGlobalObject::init):
1407         * runtime/JSInternalPromise.cpp:
1408         * runtime/JSInternalPromiseDeferred.cpp:
1409         (JSC::JSInternalPromiseDeferred::create):
1410         * runtime/JSPromise.cpp:
1411         (JSC::JSPromise::finishCreation):
1412         (JSC::JSPromise::result):
1413         * runtime/JSPromiseDeferred.cpp:
1414         (JSC::JSPromiseDeferred::create):
1415         * runtime/JSStringIterator.cpp:
1416         (JSC::JSStringIterator::finishCreation):
1417         (JSC::JSStringIterator::iteratedValue):
1418         (JSC::JSStringIterator::clone):
1419         * runtime/MapPrototype.cpp:
1420         (JSC::MapPrototype::finishCreation):
1421         * runtime/ObjectConstructor.cpp:
1422         (JSC::ObjectConstructor::finishCreation):
1423         * runtime/ReflectObject.cpp:
1424         (JSC::ReflectObject::finishCreation):
1425         * runtime/StringPrototype.cpp:
1426         (JSC::StringPrototype::finishCreation):
1427         * runtime/TypedArrayInlines.h:
1428
1429 2016-06-20  Filip Pizlo  <fpizlo@apple.com>
1430
1431         LLInt64 Float64 get_by_val doesn't purify NaN
1432         https://bugs.webkit.org/show_bug.cgi?id=158956
1433
1434         Reviewed by Michael Saboff.
1435
1436         * llint/LowLevelInterpreter64.asm: Fix the bug.
1437         * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug.
1438
1439 2016-06-20  Keith Rollin  <krollin@apple.com>
1440
1441         Remove RefPtr::release() and change calls sites to use WTFMove()
1442         https://bugs.webkit.org/show_bug.cgi?id=158369
1443
1444         Reviewed by Chris Dumez.
1445
1446         RefPtr::release() releases its managed pointer awkwardly. It's more
1447         direct and clearer to use WTFMove to transfer ownership of the managed
1448         pointer.
1449
1450         As part of this cleanup, also change a lot of explicit data types to
1451         'auto'.
1452
1453         * API/JSObjectRef.cpp:
1454         (JSClassCreate):
1455         * API/JSScriptRef.cpp:
1456         * API/JSValueRef.cpp:
1457         (JSValueToStringCopy):
1458         * bytecompiler/StaticPropertyAnalyzer.h:
1459         (JSC::StaticPropertyAnalyzer::newObject):
1460         (JSC::StaticPropertyAnalyzer::mov):
1461         * debugger/DebuggerCallFrame.cpp:
1462         (JSC::DebuggerCallFrame::invalidate):
1463         * dfg/DFGJITCompiler.cpp:
1464         (JSC::DFG::JITCompiler::compile):
1465         (JSC::DFG::JITCompiler::compileFunction):
1466         * inspector/InspectorValues.cpp:
1467         (Inspector::InspectorValue::parseJSON):
1468         * inspector/agents/InspectorAgent.cpp:
1469         (Inspector::InspectorAgent::activateExtraDomain):
1470         (Inspector::InspectorAgent::activateExtraDomains):
1471         * inspector/agents/InspectorDebuggerAgent.cpp:
1472         (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
1473         * inspector/remote/RemoteInspector.mm:
1474         (Inspector::RemoteInspector::receivedSetupMessage):
1475         * jit/Repatch.cpp:
1476         (JSC::linkPolymorphicCall):
1477         * runtime/GenericTypedArrayViewInlines.h:
1478         (JSC::GenericTypedArrayView<Adaptor>::create):
1479         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
1480         * runtime/JSArrayBufferConstructor.cpp:
1481         (JSC::constructArrayBuffer):
1482         * runtime/PropertyNameArray.h:
1483         (JSC::PropertyNameArray::releaseData):
1484         * runtime/Structure.cpp:
1485         (JSC::Structure::toStructureShape):
1486         * runtime/TypeSet.cpp:
1487         (JSC::StructureShape::merge):
1488         * tools/FunctionOverrides.cpp:
1489         (JSC::initializeOverrideInfo):
1490
1491 2016-06-20  Joseph Pecoraro  <pecoraro@apple.com>
1492
1493         Web Inspector: console.profile should use the new Sampling Profiler
1494         https://bugs.webkit.org/show_bug.cgi?id=153499
1495         <rdar://problem/24352431>
1496
1497         Reviewed by Timothy Hatcher.
1498
1499         Currently console.profile/profileEnd behave slightly differently
1500         between JSContext and Web inspection. Unifying will be part of:
1501         <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend
1502
1503         Both JSContext and Web inspection keep track of active
1504         profiles started and stopped via console.profile/profileEnd.
1505
1506         JSContext inspection sends its programmatic start/stop
1507         via the ScriptProfiler domain.
1508
1509         Web inspection sends its programmatic start/stop
1510         via the Timeline domain, and also will start/stop backend
1511         list of Instruments.
1512
1513         The functional differences between these is that for JSContext
1514         inspection, console.profile only starts/stops the ScriptProfiler
1515         domain, and does not auto-start other instruments. This isn't really
1516         a problem right now given the instruments available for JSContext
1517         inspection; but it will be nice to unify as we add more instruments.
1518         Also, JSContext inspection won't have "Profile (name)" records in
1519         its Events view, since those are currently generated only by the
1520         Web's Timeline domain.
1521
1522         * inspector/protocol/ScriptProfiler.json:
1523         * inspector/protocol/Timeline.json:
1524         Events to inform the frontend of programmatic start/stop.
1525
1526         * debugger/Debugger.h:
1527         * inspector/agents/InspectorDebuggerAgent.cpp:
1528         (Inspector::InspectorDebuggerAgent::breakpointsActive):
1529         (Inspector::InspectorDebuggerAgent::isPaused):
1530         * inspector/agents/InspectorDebuggerAgent.h:
1531         Expose breakpoints active state, since programmatic recording
1532         will temporarily disabled breakpoints if needed.
1533
1534         * inspector/JSGlobalObjectConsoleClient.cpp:
1535         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1536         (Inspector::JSGlobalObjectConsoleClient::profile):
1537         (Inspector::JSGlobalObjectConsoleClient::profileEnd):
1538         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1539         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1540         * inspector/JSGlobalObjectConsoleClient.h:
1541         * inspector/JSGlobalObjectInspectorController.cpp:
1542         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1543         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1544         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
1545         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
1546         * inspector/agents/InspectorScriptProfilerAgent.h:
1547         JSContext implementation of console.profile/profileEnd.
1548
1549 2016-06-19  Saam Barati  <sbarati@apple.com>
1550
1551         We should be able to generate more types of ICs inline
1552         https://bugs.webkit.org/show_bug.cgi?id=158719
1553         <rdar://problem/26825641>
1554
1555         Reviewed by Filip Pizlo.
1556
1557         This patch changes how we emit code for *byId ICs inline.
1558         We no longer keep data labels to patch structure checks, etc.
1559         Instead, we just regenerate the entire IC into a designated
1560         region of code that the Baseline/DFG/FTL JIT will emit inline.
1561         This makes it much simpler to patch inline ICs. All that's
1562         needed to patch an inline IC is to memcpy the code from
1563         a macro assembler inline using LinkBuffer. This architecture
1564         will be easy to extend into other forms of ICs, such as one
1565         for add, in the future.
1566
1567         To support this change, I've reworked the fields inside
1568         StructureStubInfo. It now has one field that is the CodeLocationLabel 
1569         of the start of the inline IC. Then it has a few ints that track deltas
1570         to other locations in the IC such as the slow path start, slow path call, the
1571         ICs 'done' location. We used to perform math on these ints in a bunch of different
1572         places. I've consolidated that math into methods inside StructureStubInfo.
1573
1574         To generate inline ICs, I've implemented a new class called InlineAccess.
1575         InlineAccess is stateless: it just has a bunch of static methods for
1576         generating code into the inline region specified by StructureStubInfo.
1577         Repatch will now decide when it wants to generate such an inline
1578         IC, and it will ask InlineAccess to do so.
1579
1580         I've implemented three types of inline ICs to begin with (extending
1581         this in the future should be easy):
1582         - Self property loads (both inline and out of line offsets).
1583         - Self property replace (both inline and out of line offsets).
1584         - Array length on specific array types.
1585         (An easy extension would be to implement JSString length.)
1586
1587         To know how much inline space to reserve, I've implemented a
1588         method that stubs out the various inline cache shapes and 
1589         dumps their size. This is used to determine how much space
1590         to save inline. When InlineAccess ends up generating more
1591         code than can fit inline, we will fall back to generating
1592         code with PolymorphicAccess instead.
1593
1594         To make generating code into already allocated executable memory
1595         efficient, I've made AssemblerData have 128 bytes of inline storage.
1596         This saves us a malloc when splatting code into the inline region.
1597
1598         This patch also tidies up LinkBuffer's API for generating
1599         into already allocated executable memory. Now, when generating
1600         code that has less size than the already allocated space, LinkBuffer
1601         will fill the extra space with nops. Also, if branch compaction shrinks
1602         the code, LinkBuffer will add a nop sled at the end of the shrunken
1603         code to take up the entire allocated size.
1604
1605         This looks like it could be a 1% octane progression.
1606
1607         * CMakeLists.txt:
1608         * JavaScriptCore.xcodeproj/project.pbxproj:
1609         * assembler/ARM64Assembler.h:
1610         (JSC::ARM64Assembler::nop):
1611         (JSC::ARM64Assembler::fillNops):
1612         * assembler/ARMv7Assembler.h:
1613         (JSC::ARMv7Assembler::nopw):
1614         (JSC::ARMv7Assembler::nopPseudo16):
1615         (JSC::ARMv7Assembler::nopPseudo32):
1616         (JSC::ARMv7Assembler::fillNops):
1617         (JSC::ARMv7Assembler::dmbSY):
1618         * assembler/AbstractMacroAssembler.h:
1619         (JSC::AbstractMacroAssembler::addLinkTask):
1620         (JSC::AbstractMacroAssembler::emitNops):
1621         (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
1622         * assembler/AssemblerBuffer.h:
1623         (JSC::AssemblerData::AssemblerData):
1624         (JSC::AssemblerData::operator=):
1625         (JSC::AssemblerData::~AssemblerData):
1626         (JSC::AssemblerData::buffer):
1627         (JSC::AssemblerData::grow):
1628         (JSC::AssemblerData::isInlineBuffer):
1629         (JSC::AssemblerBuffer::AssemblerBuffer):
1630         (JSC::AssemblerBuffer::ensureSpace):
1631         (JSC::AssemblerBuffer::codeSize):
1632         (JSC::AssemblerBuffer::setCodeSize):
1633         (JSC::AssemblerBuffer::label):
1634         (JSC::AssemblerBuffer::debugOffset):
1635         (JSC::AssemblerBuffer::releaseAssemblerData):
1636         * assembler/LinkBuffer.cpp:
1637         (JSC::LinkBuffer::copyCompactAndLinkCode):
1638         (JSC::LinkBuffer::linkCode):
1639         (JSC::LinkBuffer::allocate):
1640         (JSC::LinkBuffer::performFinalization):
1641         (JSC::LinkBuffer::shrink): Deleted.
1642         * assembler/LinkBuffer.h:
1643         (JSC::LinkBuffer::LinkBuffer):
1644         (JSC::LinkBuffer::debugAddress):
1645         (JSC::LinkBuffer::size):
1646         (JSC::LinkBuffer::wasAlreadyDisassembled):
1647         (JSC::LinkBuffer::didAlreadyDisassemble):
1648         (JSC::LinkBuffer::applyOffset):
1649         (JSC::LinkBuffer::code):
1650         * assembler/MacroAssemblerARM64.h:
1651         (JSC::MacroAssemblerARM64::patchableBranch32):
1652         (JSC::MacroAssemblerARM64::patchableBranch64):
1653         * assembler/MacroAssemblerARMv7.h:
1654         (JSC::MacroAssemblerARMv7::patchableBranch32):
1655         (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch):
1656         * assembler/X86Assembler.h:
1657         (JSC::X86Assembler::nop):
1658         (JSC::X86Assembler::fillNops):
1659         * bytecode/CodeBlock.cpp:
1660         (JSC::CodeBlock::printGetByIdCacheStatus):
1661         * bytecode/InlineAccess.cpp: Added.
1662         (JSC::InlineAccess::dumpCacheSizesAndCrash):
1663         (JSC::linkCodeInline):
1664         (JSC::InlineAccess::generateSelfPropertyAccess):
1665         (JSC::getScratchRegister):
1666         (JSC::hasFreeRegister):
1667         (JSC::InlineAccess::canGenerateSelfPropertyReplace):
1668         (JSC::InlineAccess::generateSelfPropertyReplace):
1669         (JSC::InlineAccess::isCacheableArrayLength):
1670         (JSC::InlineAccess::generateArrayLength):
1671         (JSC::InlineAccess::rewireStubAsJump):
1672         * bytecode/InlineAccess.h: Added.
1673         (JSC::InlineAccess::sizeForPropertyAccess):
1674         (JSC::InlineAccess::sizeForPropertyReplace):
1675         (JSC::InlineAccess::sizeForLengthAccess):
1676         * bytecode/PolymorphicAccess.cpp:
1677         (JSC::PolymorphicAccess::regenerate):
1678         * bytecode/StructureStubInfo.cpp:
1679         (JSC::StructureStubInfo::initGetByIdSelf):
1680         (JSC::StructureStubInfo::initArrayLength):
1681         (JSC::StructureStubInfo::initPutByIdReplace):
1682         (JSC::StructureStubInfo::deref):
1683         (JSC::StructureStubInfo::aboutToDie):
1684         (JSC::StructureStubInfo::propagateTransitions):
1685         (JSC::StructureStubInfo::containsPC):
1686         * bytecode/StructureStubInfo.h:
1687         (JSC::StructureStubInfo::considerCaching):
1688         (JSC::StructureStubInfo::slowPathCallLocation):
1689         (JSC::StructureStubInfo::doneLocation):
1690         (JSC::StructureStubInfo::slowPathStartLocation):
1691         (JSC::StructureStubInfo::patchableJumpForIn):
1692         (JSC::StructureStubInfo::valueRegs):
1693         * dfg/DFGJITCompiler.cpp:
1694         (JSC::DFG::JITCompiler::link):
1695         * dfg/DFGOSRExitCompilerCommon.cpp:
1696         (JSC::DFG::reifyInlinedCallFrames):
1697         * dfg/DFGSpeculativeJIT32_64.cpp:
1698         (JSC::DFG::SpeculativeJIT::cachedGetById):
1699         * dfg/DFGSpeculativeJIT64.cpp:
1700         (JSC::DFG::SpeculativeJIT::cachedGetById):
1701         * ftl/FTLLowerDFGToB3.cpp:
1702         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
1703         (JSC::FTL::DFG::LowerDFGToB3::getById):
1704         * jit/JITInlineCacheGenerator.cpp:
1705         (JSC::JITByIdGenerator::finalize):
1706         (JSC::JITByIdGenerator::generateFastCommon):
1707         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1708         (JSC::JITGetByIdGenerator::generateFastPath):
1709         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
1710         (JSC::JITPutByIdGenerator::generateFastPath):
1711         (JSC::JITPutByIdGenerator::slowPathFunction):
1712         (JSC::JITByIdGenerator::generateFastPathChecks): Deleted.
1713         * jit/JITInlineCacheGenerator.h:
1714         (JSC::JITByIdGenerator::reportSlowPathCall):
1715         (JSC::JITByIdGenerator::slowPathBegin):
1716         (JSC::JITByIdGenerator::slowPathJump):
1717         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1718         * jit/JITPropertyAccess.cpp:
1719         (JSC::JIT::emitGetByValWithCachedId):
1720         (JSC::JIT::emit_op_try_get_by_id):
1721         (JSC::JIT::emit_op_get_by_id):
1722         * jit/JITPropertyAccess32_64.cpp:
1723         (JSC::JIT::emitGetByValWithCachedId):
1724         (JSC::JIT::emit_op_try_get_by_id):
1725         (JSC::JIT::emit_op_get_by_id):
1726         * jit/Repatch.cpp:
1727         (JSC::repatchCall):
1728         (JSC::tryCacheGetByID):
1729         (JSC::repatchGetByID):
1730         (JSC::appropriateGenericPutByIdFunction):
1731         (JSC::tryCachePutByID):
1732         (JSC::repatchPutByID):
1733         (JSC::tryRepatchIn):
1734         (JSC::repatchIn):
1735         (JSC::linkSlowFor):
1736         (JSC::resetGetByID):
1737         (JSC::resetPutByID):
1738         (JSC::resetIn):
1739         (JSC::repatchByIdSelfAccess): Deleted.
1740         (JSC::resetGetByIDCheckAndLoad): Deleted.
1741         (JSC::resetPutByIDCheckAndLoad): Deleted.
1742         (JSC::replaceWithJump): Deleted.
1743
1744 2016-06-19  Filip Pizlo  <fpizlo@apple.com>
1745
1746         REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower
1747         https://bugs.webkit.org/show_bug.cgi?id=158906
1748
1749         Reviewed by Benjamin Poulain.
1750         
1751         The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression
1752         on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without
1753         affecting the other tests.
1754         
1755         The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init
1756         code that took about 16ms to compile in baseline. There's no good way to avoid letting it
1757         tier-up into baseline since it has a compute loop. The time it takes to run this code is
1758         never measured. The concurrent baseline JIT caused us to schedule the compilation of this
1759         huge code rather than doing it eagerly. This meant that after initialization was done and
1760         we started actually running real stuff, all of the real stuff's compiles would be convoyed
1761         behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind
1762         baseline compiles, since you can't schedule a DFG compile for a code block until that code
1763         block is in baseline.
1764         
1765         This uses the simplest fix: if we are thinking about scheduling some compile and the
1766         thread is busy, do the compile on the main thread instead. This doesn't completely
1767         eliminate the ai-astar regression (we still have a 4% regression on that test) but it now
1768         results in concurrent baseline JIT being an overall progression on Kraken as a whole (1%
1769         on my machine). This is because concurrent baseline appears to help on other tests.
1770
1771         In the future, we could fix this even better by allowing the JITWorklist to spawn more
1772         threads or by being smarter about baseline compilation. I think it's nasty that if a giant
1773         piece of initialization code ends in a compute loop, we compile all of the code instead of
1774         just the loop. It's also gross that a constant-like object creation expression will result
1775         in so much code. It would result in less code if we allowed ourselves to do a bit more
1776         static reasoning about object literals.
1777         
1778         But for now, I think that this is a great way to recover the Kraken regression while still
1779         keeping the other progressions from concurrent baseline.
1780
1781         * jit/JITWorklist.cpp:
1782         (JSC::JITWorklist::Plan::Plan):
1783         (JSC::JITWorklist::Plan::compileInThread):
1784         (JSC::JITWorklist::Plan::finalize):
1785         (JSC::JITWorklist::Plan::codeBlock):
1786         (JSC::JITWorklist::Plan::isFinishedCompiling):
1787         (JSC::JITWorklist::Plan::compileNow):
1788         (JSC::JITWorklist::JITWorklist):
1789         (JSC::JITWorklist::compileLater):
1790         (JSC::JITWorklist::compileNow):
1791         (JSC::JITWorklist::runThread):
1792         (JSC::JITWorklist::Plan::isFinalized): Deleted.
1793         * jit/JITWorklist.h:
1794
1795 2016-06-17  Commit Queue  <commit-queue@webkit.org>
1796
1797         Unreviewed, rolling out r202152.
1798         https://bugs.webkit.org/show_bug.cgi?id=158897
1799
1800         The new test is very unstable, timing out frequently
1801         (Requested by ap on #webkit).
1802
1803         Reverted changeset:
1804
1805         "Web Inspector: console.profile should use the new Sampling
1806         Profiler"
1807         https://bugs.webkit.org/show_bug.cgi?id=153499
1808         http://trac.webkit.org/changeset/202152
1809
1810 2016-06-14  Filip Pizlo  <fpizlo@apple.com>
1811
1812         Baseline JIT should be concurrent
1813         https://bugs.webkit.org/show_bug.cgi?id=158755
1814
1815         Reviewed by Geoffrey Garen.
1816         
1817         This makes the baseline JIT concurrent. We want it to be concurrent because it takes up
1818         about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent
1819         optimizations).
1820         
1821         The idea is really simple: I separated the compile and link phases of JIT::privateCompile(),
1822         and arranged to call the compile phase from another thread. This doesn't reuse the old
1823         DFG::Worklist code, because that code does things we don't need (like compilation plan
1824         cancellation to allow GC to interleave with compilations) and is structured in a way that
1825         would have required more changes to the baseline JIT. Also, I think that code uses the wrong
1826         API, and as a result, clients of that API have a bad time. For example, it's never clear who
1827         has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great
1828         lengths to try to help its client set those things correctly, but since it doesn't set them
1829         directly, the client then has to have additional complex logic to combine what it learned
1830         from the Worklist and what it knows to set the thresholds. This patch takes a simpler
1831         approach: the JITWorklist takes complete control over scheduling compilations. It's like a
1832         combination of DFG::Worklist and operationOptimize().
1833         
1834         Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires
1835         that all of its plans complete before a GC begins. This ensures that we don't have to worry
1836         about interactions between the concurrent baseline JIT and the GC.
1837         
1838         I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For
1839         example, I needed to do things to opcodes that read profiling both in the main path code
1840         generator and the slow path one. One trick I used was to create a copy of the instruction
1841         stream and provide that for anyone interested in the original value of the profiles. Most
1842         code still uses the CodeBlock's instruction stream because it may emit JIT code that points
1843         at the stream.
1844         
1845         This also fixes a LLInt bug in prototype caching. This bug was revealed by this change
1846         because more of our LayoutTests now run in LLInt.
1847         
1848         This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3
1849         speed-up. This also looks like a ~2% JSBench speed-up.
1850
1851         * CMakeLists.txt:
1852         * JavaScriptCore.xcodeproj/project.pbxproj:
1853         * debugger/Debugger.cpp:
1854         (JSC::Debugger::setSteppingMode):
1855         (JSC::Debugger::toggleBreakpoint):
1856         (JSC::Debugger::clearBreakpoints):
1857         (JSC::Debugger::clearDebuggerRequests):
1858         * dfg/DFGOSRExitPreparation.cpp:
1859         (JSC::DFG::prepareCodeOriginForOSRExit):
1860         * heap/Heap.cpp:
1861         (JSC::Heap::didFinishIterating):
1862         (JSC::Heap::completeAllJITPlans):
1863         (JSC::Heap::deleteAllCodeBlocks):
1864         (JSC::Heap::collectImpl):
1865         (JSC::Heap::completeAllDFGPlans): Deleted.
1866         * heap/Heap.h:
1867         * heap/HeapInlines.h:
1868         (JSC::Heap::forEachCodeBlock):
1869         * jit/JIT.cpp:
1870         (JSC::JIT::emitNotifyWrite):
1871         (JSC::JIT::privateCompileMainPass):
1872         (JSC::JIT::privateCompileSlowCases):
1873         (JSC::JIT::compileWithoutLinking):
1874         (JSC::JIT::link):
1875         (JSC::JIT::privateCompile):
1876         (JSC::JIT::privateCompileExceptionHandlers):
1877         * jit/JIT.h:
1878         (JSC::JIT::compile):
1879         (JSC::JIT::getSlowCase):
1880         (JSC::JIT::linkSlowCase):
1881         (JSC::JIT::linkDummySlowCase):
1882         * jit/JITInlines.h:
1883         (JSC::JIT::emitTagBool):
1884         (JSC::JIT::originalInstruction):
1885         * jit/JITPropertyAccess32_64.cpp:
1886         (JSC::JIT::emitSlow_op_put_to_scope):
1887         * jit/JITPropertyAccess.cpp:
1888         (JSC::JIT::emitSlow_op_put_by_val):
1889         (JSC::JIT::emit_op_resolve_scope):
1890         (JSC::JIT::emitSlow_op_resolve_scope):
1891         (JSC::JIT::emit_op_get_from_scope):
1892         (JSC::JIT::emitSlow_op_get_from_scope):
1893         (JSC::JIT::emit_op_put_to_scope):
1894         (JSC::JIT::emitSlow_op_put_to_scope):
1895         * jit/JITWorklist.cpp: Added.
1896         (JSC::JITWorklist::Plan::Plan):
1897         (JSC::JITWorklist::Plan::compileInThread):
1898         (JSC::JITWorklist::Plan::finalize):
1899         (JSC::JITWorklist::Plan::codeBlock):
1900         (JSC::JITWorklist::Plan::vm):
1901         (JSC::JITWorklist::Plan::isFinishedCompiling):
1902         (JSC::JITWorklist::Plan::isFinalized):
1903         (JSC::JITWorklist::JITWorklist):
1904         (JSC::JITWorklist::~JITWorklist):
1905         (JSC::JITWorklist::completeAllForVM):
1906         (JSC::JITWorklist::poll):
1907         (JSC::JITWorklist::compileLater):
1908         (JSC::JITWorklist::compileNow):
1909         (JSC::JITWorklist::runThread):
1910         (JSC::JITWorklist::finalizePlans):
1911         (JSC::JITWorklist::instance):
1912         * jit/JITWorklist.h: Added.
1913         * llint/LLIntSlowPaths.cpp:
1914         (JSC::LLInt::jitCompileAndSetHeuristics):
1915         * runtime/CommonSlowPaths.cpp:
1916         (JSC::SLOW_PATH_DECL):
1917         * runtime/CommonSlowPaths.h:
1918         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
1919         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
1920         * runtime/VM.cpp:
1921         (JSC::VM::~VM):
1922
1923 2016-06-16  Joseph Pecoraro  <pecoraro@apple.com>
1924
1925         Web Inspector: console.profile should use the new Sampling Profiler
1926         https://bugs.webkit.org/show_bug.cgi?id=153499
1927         <rdar://problem/24352431>
1928
1929         Reviewed by Timothy Hatcher.
1930
1931         Currently console.profile/profileEnd behave slightly differently
1932         between JSContext and Web inspection. Unifying will be part of:
1933         <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend
1934
1935         Both JSContext and Web inspection keep track of active
1936         profiles started and stopped via console.profile/profileEnd.
1937
1938         JSContext inspection sends its programmatic start/stop
1939         via the ScriptProfiler domain.
1940
1941         Web inspection sends its programmatic start/stop
1942         via the Timeline domain, and also will start/stop backend
1943         list of Instruments.
1944
1945         The functional differences between these is that for JSContext
1946         inspection, console.profile only starts/stops the ScriptProfiler
1947         domain, and does not auto-start other instruments. This isn't really
1948         a problem right now given the instruments available for JSContext
1949         inspection; but it will be nice to unify as we add more instruments.
1950         Also, JSContext inspection won't have "Profile (name)" records in
1951         its Events view, since those are currently generated only by the
1952         Web's Timeline domain.
1953
1954         * inspector/protocol/ScriptProfiler.json:
1955         * inspector/protocol/Timeline.json:
1956         Events to inform the frontend of programmatic start/stop.
1957
1958         * debugger/Debugger.h:
1959         * inspector/agents/InspectorDebuggerAgent.cpp:
1960         (Inspector::InspectorDebuggerAgent::breakpointsActive):
1961         (Inspector::InspectorDebuggerAgent::isPaused):
1962         * inspector/agents/InspectorDebuggerAgent.h:
1963         Expose breakpoints active state, since programmatic recording
1964         will temporarily disabled breakpoints if needed.
1965
1966         * inspector/JSGlobalObjectConsoleClient.cpp:
1967         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1968         (Inspector::JSGlobalObjectConsoleClient::profile):
1969         (Inspector::JSGlobalObjectConsoleClient::profileEnd):
1970         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1971         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1972         * inspector/JSGlobalObjectConsoleClient.h:
1973         * inspector/JSGlobalObjectInspectorController.cpp:
1974         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1975         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1976         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
1977         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
1978         * inspector/agents/InspectorScriptProfilerAgent.h:
1979         JSContext implementation of console.profile/profileEnd.
1980
1981 2016-06-16  Filip Pizlo  <fpizlo@apple.com>
1982
1983         Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL
1984         https://bugs.webkit.org/show_bug.cgi?id=158850
1985
1986         Reviewed by Keith Miller.
1987         
1988         Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's
1989         crazy! We never noticed this because extending OSR liveness is usually not a showstopper and
1990         until recently we didn't have a lot of tail-call test cases to play with. Well, we do now,
1991         thanks to the increasing reliance on tail calls in our builtins.
1992
1993         * dfg/DFGGraph.cpp:
1994         (JSC::DFG::Graph::localsLiveInBytecode): Fix the bug and add some optional tracing. Also restructure the code so that we don't break to return true, since that's counterintuitive.
1995         * ftl/FTLLowerDFGToB3.cpp:
1996         (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information.
1997
1998 2016-06-16  Mark Lam  <mark.lam@apple.com>
1999
2000         Add collecting of LLINT slow path stats.
2001         https://bugs.webkit.org/show_bug.cgi?id=158829
2002
2003         Reviewed by Keith Miller.
2004
2005         * llint/LLIntData.cpp:
2006         (JSC::LLInt::Data::dumpStats):
2007         * llint/LLIntData.h:
2008         * llint/LLIntSlowPaths.cpp:
2009         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2010         * llint/LLIntSlowPaths.h:
2011         * llint/LowLevelInterpreter.asm:
2012         * llint/LowLevelInterpreter32_64.asm:
2013         * llint/LowLevelInterpreter64.asm:
2014
2015 2016-06-15  Keith Miller  <keith_miller@apple.com>
2016
2017         Add support for Symbol.isConcatSpreadable (round 2)
2018         https://bugs.webkit.org/show_bug.cgi?id=158769
2019
2020         Reviewed by Mark Lam.
2021
2022         This patch adds support for Symbol.isConcatSpreadable. In order to
2023         do so, it was necessary to move the Array.prototype.concat function
2024         to JS. A number of different optimizations were needed to make
2025         such the move to a builtin performant. First, this patch adds a
2026         new Bytecode intrinsic, isJSArray, that checks if the value is a
2027         JSArray object. Specifically, isJSArray checks that the array
2028         object is a normal instance of JSArray and not a RuntimeArray or
2029         Array.prototype. isJSArray can also be converted into a constant
2030         by the DFG if we are able to prove that the incomming value is
2031         already a JSArray.
2032
2033         In order to further improve the perfomance we also now cover more
2034         indexing types in our fast path memcpy code. Before we would only
2035         memcpy Arrays if they had the same indexing type and did not have
2036         Array storage or were undecided. Now the memcpy code covers the
2037         following additional three cases:
2038
2039         1) One array is undecided and the other does not have array storage
2040
2041         2) One array is Int32 and the other is contiguous (we map this
2042         into a contiguous array).
2043
2044         3) The this value is an array and first argument is a non-array
2045         that does not have Symbol.isConcatSpreadable set.
2046
2047         This patch also adds a new fast path for concat with more than one
2048         array argument by using memcpy to append values onto the result
2049         array. This works roughly the same as the two array fast path
2050         using the same methodology to decide if we can memcpy the other
2051         butterfly into the result butterfly.
2052
2053         * JavaScriptCore.xcodeproj/project.pbxproj:
2054         * builtins/ArrayPrototype.js:
2055         (concatSlowPath):
2056         (concat):
2057         * bytecode/BytecodeIntrinsicRegistry.cpp:
2058         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2059         * bytecode/BytecodeIntrinsicRegistry.h:
2060         * bytecode/BytecodeList.json:
2061         * bytecode/BytecodeUseDef.h:
2062         (JSC::computeUsesForBytecodeOffset):
2063         (JSC::computeDefsForBytecodeOffset):
2064         * bytecode/CodeBlock.cpp:
2065         (JSC::CodeBlock::dumpBytecode):
2066         * bytecompiler/BytecodeGenerator.h:
2067         (JSC::BytecodeGenerator::emitIsJSArray):
2068         * bytecompiler/NodesCodegen.cpp:
2069         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray):
2070         * dfg/DFGAbstractInterpreterInlines.h:
2071         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2072         * dfg/DFGByteCodeParser.cpp:
2073         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2074         (JSC::DFG::ByteCodeParser::parseBlock):
2075         * dfg/DFGCapabilities.cpp:
2076         (JSC::DFG::capabilityLevel):
2077         * dfg/DFGClobberize.h:
2078         (JSC::DFG::clobberize):
2079         * dfg/DFGDoesGC.cpp:
2080         (JSC::DFG::doesGC):
2081         * dfg/DFGFixupPhase.cpp:
2082         (JSC::DFG::FixupPhase::fixupNode):
2083         * dfg/DFGNodeType.h:
2084         * dfg/DFGOperations.cpp:
2085         * dfg/DFGOperations.h:
2086         * dfg/DFGPredictionPropagationPhase.cpp:
2087         * dfg/DFGSafeToExecute.h:
2088         (JSC::DFG::safeToExecute):
2089         * dfg/DFGSpeculativeJIT.cpp:
2090         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2091         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
2092         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
2093         * dfg/DFGSpeculativeJIT.h:
2094         (JSC::DFG::SpeculativeJIT::callOperation):
2095         * dfg/DFGSpeculativeJIT32_64.cpp:
2096         (JSC::DFG::SpeculativeJIT::compile):
2097         * dfg/DFGSpeculativeJIT64.cpp:
2098         (JSC::DFG::SpeculativeJIT::compile):
2099         * ftl/FTLCapabilities.cpp:
2100         (JSC::FTL::canCompile):
2101         * ftl/FTLLowerDFGToB3.cpp:
2102         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2103         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
2104         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
2105         (JSC::FTL::DFG::LowerDFGToB3::isArray):
2106         * jit/JIT.cpp:
2107         (JSC::JIT::privateCompileMainPass):
2108         * jit/JIT.h:
2109         * jit/JITOpcodes.cpp:
2110         (JSC::JIT::emit_op_is_jsarray):
2111         * jit/JITOpcodes32_64.cpp:
2112         (JSC::JIT::emit_op_is_jsarray):
2113         * jit/JITOperations.h:
2114         * llint/LLIntData.cpp:
2115         (JSC::LLInt::Data::performAssertions):
2116         * llint/LowLevelInterpreter.asm:
2117         * llint/LowLevelInterpreter32_64.asm:
2118         * llint/LowLevelInterpreter64.asm:
2119         * runtime/ArrayConstructor.h:
2120         (JSC::isArrayConstructor):
2121         * runtime/ArrayPrototype.cpp:
2122         (JSC::ArrayPrototype::finishCreation):
2123         (JSC::speciesWatchpointsValid):
2124         (JSC::speciesConstructArray):
2125         (JSC::moveElements):
2126         (JSC::concatAppendOne):
2127         (JSC::arrayProtoFuncConcat): Deleted.
2128         * runtime/ArrayPrototype.h:
2129         * runtime/CommonIdentifiers.h:
2130         * runtime/CommonSlowPaths.cpp:
2131         (JSC::SLOW_PATH_DECL):
2132         * runtime/IndexingType.h:
2133         (JSC::indexingTypeForValue):
2134         * runtime/JSArray.cpp:
2135         (JSC::JSArray::appendMemcpy):
2136         (JSC::JSArray::fastConcatWith): Deleted.
2137         * runtime/JSArray.h:
2138         (JSC::JSArray::createStructure):
2139         (JSC::isJSArray):
2140         (JSC::JSArray::fastConcatType): Deleted.
2141         * runtime/JSArrayInlines.h: Added.
2142         (JSC::JSArray::mergeIndexingTypeForCopying):
2143         (JSC::JSArray::canFastCopy):
2144         * runtime/JSGlobalObject.cpp:
2145         (JSC::JSGlobalObject::init):
2146         * runtime/JSObject.cpp:
2147         (JSC::JSObject::convertUndecidedForValue):
2148         * runtime/JSType.h:
2149         * runtime/ObjectConstructor.h:
2150         (JSC::constructObject):
2151         * tests/es6.yaml:
2152         * tests/stress/array-concat-spread-object.js: Added.
2153         (arrayEq):
2154         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
2155         (arrayEq):
2156         * tests/stress/array-concat-spread-proxy.js: Added.
2157         (arrayEq):
2158         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
2159         (arrayEq):
2160         * tests/stress/array-species-config-array-constructor.js:
2161
2162 2016-06-15  Mark Lam  <mark.lam@apple.com>
2163
2164         Assertion failure when returning incomplete property descriptor from proxy trap.
2165         https://bugs.webkit.org/show_bug.cgi?id=157078
2166
2167         Reviewed by Saam Barati.
2168
2169         If the proxy returns a descriptor that expects a value but does not specify one,
2170         we should use undefined for the value.
2171
2172         * runtime/ProxyObject.cpp:
2173         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2174         * tests/stress/proxy-returning-incomplete-property-descriptor.js: Added.
2175         (truthiness):
2176         (compare):
2177         (shouldBe):
2178         (test):
2179         (get test):
2180
2181 2016-06-15  Keith Miller  <keith_miller@apple.com>
2182
2183         Unreviewed, fix typo in test and move tests to the correct files.
2184
2185         * tests/stress/multi-get-by-offset-proto-or-unset.js:
2186         * tests/stress/multi-get-by-offset-proto-self-or-unset.js:
2187
2188 2016-06-15  Keith Miller  <keith_miller@apple.com>
2189
2190         DFGByteCodeParser should be able to infer the value of unset properties in MultiGetByOffset
2191         https://bugs.webkit.org/show_bug.cgi?id=158802
2192
2193         Reviewed by Filip Pizlo.
2194
2195         This patch adds support for unset properties in MultiGetByOffset. Since MultiGetByOffset
2196         already supports constant values this patch just adds a constant case where the fetched
2197         value is undefined. Fortunately (or unfortunately) we don't support object allocation
2198         sinking for constant cases of MultiGetByOffset, which means we don't need to adjust any
2199         in that phase.
2200
2201         * dfg/DFGByteCodeParser.cpp:
2202         (JSC::DFG::ByteCodeParser::planLoad):
2203         (JSC::DFG::ByteCodeParser::handleGetById):
2204         * dfg/DFGMultiGetByOffsetData.h:
2205         * tests/stress/multi-get-by-offset-proto-or-unset.js: Added.
2206         (foo):
2207         * tests/stress/multi-get-by-offset-proto-self-or-unset.js: Added.
2208         (foo):
2209         * tests/stress/multi-get-by-offset-self-or-unset.js: Added.
2210         (foo):
2211
2212 2016-06-15  Chris Dumez  <cdumez@apple.com>
2213
2214         Unreviewed GCC build fix after r202098.
2215
2216         * bytecode/CodeBlock.cpp:
2217         (JSC::CodeBlock::thresholdForJIT):
2218
2219 2016-06-14  Geoffrey Garen  <ggaren@apple.com>
2220
2221         compilation policy should adapt to past behavior
2222         https://bugs.webkit.org/show_bug.cgi?id=158759
2223
2224         Reviewed by Saam Barati.
2225
2226         This looks like a ~9% speedup on JSBench.
2227
2228         * bytecode/CodeBlock.cpp:
2229         (JSC::CodeBlock::~CodeBlock): Record when a CodeBlock dies without ever
2230         making it to DFG.
2231
2232         (JSC::CodeBlock::thresholdForJIT): CodeBlocks that make it to DFG should
2233         compile sooner; CodeBlocks that don't should compile later. The goal is
2234         to use past behavior, in addition to execution counts, to determine
2235         whether compilation is profitable.
2236
2237         (JSC::CodeBlock::jitAfterWarmUp):
2238         (JSC::CodeBlock::jitSoon): Apply the thresholdForJIT rule.
2239
2240         * bytecode/CodeBlock.h: Moved some code into the .cpp file so I could
2241         change stuff without recompiling.
2242         (JSC::CodeBlock::jitAfterWarmUp): Deleted.
2243         (JSC::CodeBlock::jitSoon): Deleted.
2244
2245         * bytecode/UnlinkedCodeBlock.cpp:
2246         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2247         * bytecode/UnlinkedCodeBlock.h:
2248         (JSC::UnlinkedCodeBlock::didOptimize):
2249         (JSC::UnlinkedCodeBlock::setDidOptimize): Added a piece of data to track
2250         whether we made it to DFG.
2251
2252         * jit/JITOperations.cpp: Record when we make it to DFG.
2253
2254 2016-06-15  Konstantin Tokarev  <annulen@yandex.ru>
2255
2256         Only Mac port needs ObjC API for JSC.
2257         https://bugs.webkit.org/show_bug.cgi?id=158780
2258
2259         Reviewed by Philippe Normand.
2260
2261         * API/JSBase.h: Removed !defined(BUILDING_GTK__)
2262
2263 2016-06-15  Keith Miller  <keith_miller@apple.com>
2264
2265         DFGByteCodeParser should be able to infer a property is unset from the Baseline inline cache.
2266         https://bugs.webkit.org/show_bug.cgi?id=158774
2267
2268         Reviewed by Filip Pizlo.
2269
2270         This patch allows the DFGByteCodeParser to speculatively convert a property access into a
2271         constant if that access was always a miss in the Baseline inline cache. This patch does
2272         not add support for MultiGetByOffset and unset properties. That functionality will come
2273         a future patch.
2274
2275         * bytecode/ComplexGetStatus.cpp:
2276         (JSC::ComplexGetStatus::computeFor):
2277         * bytecode/GetByIdStatus.cpp:
2278         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2279         * bytecode/GetByIdVariant.h:
2280         (JSC::GetByIdVariant::isPropertyUnset):
2281         * bytecode/PutByIdVariant.h:
2282         (JSC::PutByIdVariant::isPropertyUnset):
2283         * dfg/DFGByteCodeParser.cpp:
2284         (JSC::DFG::ByteCodeParser::load):
2285         (JSC::DFG::ByteCodeParser::handleGetById):
2286         * tests/stress/undefined-access-then-self-change.js: Added.
2287         (foo):
2288
2289 2016-06-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2290
2291         [JSC] Move calling convention flags to WTF
2292         https://bugs.webkit.org/show_bug.cgi?id=158661
2293
2294         Reviewed by Keith Miller.
2295
2296         Due to some calling convention flags and JIT_OPERATION flags, MathCommon.h includes MacroAssemblerCodeRef and JITOperations.h.
2297         But MacroAssembler and JIT part should not be necessary for the MathCommon component.
2298         As with other calling convention flags like JSC_HOST_CALL, these flags should be in WTF.
2299
2300         * assembler/MacroAssemblerCodeRef.h:
2301         * jit/JITOperations.h:
2302         Add wtf/Platform.h inclusion driven by the Windows port build failure.
2303
2304         * runtime/MathCommon.h:
2305
2306 2016-06-15  Romain Bellessort  <romain.bellessort@crf.canon.fr>
2307
2308         Enabling Shadow DOM for all platforms
2309         https://bugs.webkit.org/show_bug.cgi?id=158738
2310
2311         Reviewed by Ryosuke Niwa.
2312
2313         Removed Shadow DOM from options (enabled by default)
2314
2315         * Configurations/FeatureDefines.xcconfig:
2316
2317 2016-06-14  Caio Lima  <ticaiolima@gmail.com>
2318
2319         The parser doesn't properly parse "super" when default parameter is an
2320         arrow function.
2321         https://bugs.webkit.org/show_bug.cgi?id=157872.
2322
2323         Reviewed by Saam Barati.
2324
2325         The "super" member or "super()" could not be used when default parameter is an
2326         arrow function, resuling in sytax error. It happened because the
2327         "closestOrdinaryFunctionScope" was not being initialized properly
2328         before "parseFunctionParameters" step and the condition
2329         "functionSuperBinding == SuperBinding::NotNeeded" or
2330         "functionConstructorKind != ConstructorKind::Derived" on
2331         "Parser<LexerType>::parseMemberExpression" step were being true
2332         resulting in SyntaxError.
2333
2334         * parser/Parser.cpp: 
2335         (JSC::Parser<LexerType>::parseFunctionInfo): setting
2336         "functionScope->setExpectedSuperBinding(expectedSuperBinding)" and
2337         "functionScope->setConstructorKind(constructorKind)" before
2338         "parseFunctionParameters" step.
2339
2340 2016-06-14  Joseph Pecoraro  <pecoraro@apple.com>
2341
2342         Web Inspector: Rename Timeline.setAutoCaptureInstruments to Timeline.setInstruments
2343         https://bugs.webkit.org/show_bug.cgi?id=158762
2344
2345         Reviewed by Timothy Hatcher.
2346
2347         Rename the protocol methods since the backend may use the instruments
2348         for purposes other then auto-capture, such as programmatic capture
2349         via console.profile.
2350
2351         * inspector/protocol/Timeline.json:
2352
2353 2016-06-14  David Kilzer  <ddkilzer@apple.com>
2354
2355         Document the native format of JSChar type
2356         <http://webkit.org/b/156137>
2357
2358         Reviewed by Darin Adler.
2359
2360         * API/JSStringRef.h:
2361         (typedef JSChar): Update documentation.
2362
2363 2016-06-14  Keith Miller  <keith_miller@apple.com>
2364
2365         The Array species constructor watchpoints should be created the first time they are needed rather than on creation
2366         https://bugs.webkit.org/show_bug.cgi?id=158754
2367
2368         Reviewed by Benjamin Poulain.
2369
2370         We use adaptive watchpoints for some Array prototype functions to
2371         ensure that the user has not overridden the value of the
2372         Array.prototype.constructor or Array[Symbol.species]. This patch
2373         changes when the Array species constructor watchpoints are
2374         initialized. Before, those watchpoints would be created when the
2375         global object is initialized. This had the advantage that it did
2376         not require validating the constructor and Symbol.species
2377         properties. On the other hand, it also meant that if the user were
2378         to reconfigure properties Array.prototype, which would cause the
2379         structure of the property to become an uncachable dictionary,
2380         prior to running code that the watchpoints would be
2381         invalidated. It turns out that JSBench amazon, for instance, does
2382         reconfigure some of Array.prototype's properties. This patch
2383         initializes the watchpoints the first time they are needed. Since
2384         we only initialize once we also flatten the structure of Array and
2385         Array.prototype.
2386
2387         * runtime/ArrayPrototype.cpp:
2388         (JSC::speciesConstructArray):
2389         (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):
2390         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
2391         (JSC::ArrayPrototype::setConstructor): Deleted.
2392         * runtime/ArrayPrototype.h:
2393         (JSC::ArrayPrototype::speciesWatchpointStatus):
2394         (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): Deleted.
2395         * runtime/JSGlobalObject.cpp:
2396         (JSC::JSGlobalObject::init):
2397         * runtime/JSGlobalObject.h:
2398         (JSC::JSGlobalObject::speciesGetterSetter):
2399         (JSC::JSGlobalObject::arrayConstructor):
2400         * tests/stress/array-symbol-species-lazy-watchpoints.js: Added.
2401         (test):
2402         (arrayEq):
2403         (A):
2404
2405 2016-06-14  Keith Miller  <keith_miller@apple.com>
2406
2407         REGRESSION(202002-202014): 845 32-bit JSC Stress Test failures
2408         https://bugs.webkit.org/show_bug.cgi?id=158737
2409
2410         Reviewed by Filip Pizlo.
2411
2412         When the this child and arguments child for the varargs nodes was switched I missed one
2413         case in the 32-bit build.
2414
2415         * dfg/DFGSpeculativeJIT32_64.cpp:
2416         (JSC::DFG::SpeculativeJIT::emitCall):
2417
2418 2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>
2419
2420         setUpStaticFunctionSlot does not handle Builtin|Accessor properties
2421         https://bugs.webkit.org/show_bug.cgi?id=158637
2422
2423         Reviewed by Geoff Garen.
2424
2425         setUpStaticFunctionSlot contains a duplicate copy of the body of the function reifyStaticProperty
2426         - however it is missing handling for Accessor type under Builtin functions.
2427         Fix the bug by de-duplicating - setUpStaticFunctionSlot should just call reifyStaticProperty.
2428
2429         * runtime/Lookup.cpp:
2430         (JSC::setUpStaticFunctionSlot):
2431             - should just call reifyStaticProperty.
2432         * runtime/Lookup.h:
2433         (JSC::lookupPut):
2434         (JSC::reifyStaticProperty):
2435             - changed reifyStaticProperty to take PropertyName.
2436
2437 2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>
2438
2439         JSBoundSlotBaseFunction no longer binds slot base
2440         https://bugs.webkit.org/show_bug.cgi?id=157978
2441
2442         Reviewed by Geoff Garen.
2443
2444         This class is basically currently named after a bug. We should never have
2445         been binding function to slot bases - this was not ever correct behavior.
2446         This was fixed earlier in the year, but there is still some cruft including
2447         the class name to clean up.
2448
2449             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
2450             - removed m_boundSlotBase - don't retain the original slot base
2451               (we were not really using it anyway).
2452             - ASSERT customGetterSetter->getter/setter are non-null, rather than checking.
2453             - Store the PropertyName such that we can pass this to the getter
2454               (we're currently reperforming the String->Identifier conversion every time).
2455             - Removed JSFunction::lookUpOrCreateNativeExecutable - this is just overhead,
2456               and not used consistently.
2457
2458         * CMakeLists.txt:
2459         * JavaScriptCore.xcodeproj/project.pbxproj:
2460         * runtime/JSBoundSlotBaseFunction.cpp: Removed.
2461         * runtime/JSBoundSlotBaseFunction.h: Removed.
2462             - JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
2463         * runtime/JSCustomGetterSetterFunction.cpp: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.cpp.
2464         (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
2465             - made a static function on JSCustomGetterSetterFunction such that accessor
2466               to member properties could be made private. Call variant of callCustomSetter
2467               that does not require slotBase, ASSERT getter/setter present, pass stored
2468               PropertyName to getter.
2469         (JSC::JSCustomGetterSetterFunction::JSCustomGetterSetterFunction):
2470             - renamed, store propertyName.
2471         (JSC::JSCustomGetterSetterFunction::create):
2472             - use same function name to Executable as is being passed to Function::finishCreation.
2473         (JSC::JSCustomGetterSetterFunction::visitChildren):
2474         (JSC::JSCustomGetterSetterFunction::finishCreation):
2475             - removed m_boundSlotBase.
2476         * runtime/JSCustomGetterSetterFunction.h: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.h.
2477         (JSC::JSCustomGetterSetterFunction::customGetterSetter):
2478         (JSC::JSCustomGetterSetterFunction::isSetter):
2479             - made private.
2480         (JSC::JSCustomGetterSetterFunction::propertyName):
2481             - new accessor.
2482         (JSC::JSBoundSlotBaseFunction::boundSlotBase): Deleted.
2483             - removed.
2484         * runtime/JSFunction.cpp:
2485         (JSC::JSFunction::create):
2486         (JSC::JSFunction::lookUpOrCreateNativeExecutable): Deleted.
2487             - removed lookUpOrCreateNativeExecutable. This inconsistently used wrapper was providing no value, only bloat.
2488         * runtime/JSFunction.h:
2489         * runtime/JSGlobalObject.cpp:
2490         (JSC::JSGlobalObject::init):
2491         (JSC::JSGlobalObject::visitChildren):
2492             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2493         * runtime/JSGlobalObject.h:
2494         (JSC::JSGlobalObject::customGetterSetterFunctionStructure):
2495         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
2496             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2497         * runtime/JSNativeStdFunction.cpp:
2498         (JSC::JSNativeStdFunction::create):
2499             - removed lookUpOrCreateNativeExecutable.
2500         * runtime/JSObject.cpp:
2501         (JSC::getCustomGetterSetterFunctionForGetterSetter):
2502         (JSC::JSObject::getOwnPropertyDescriptor):
2503         (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
2504             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2505         * runtime/VM.h:
2506             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2507
2508 2016-06-13  Saam Barati  <sbarati@apple.com>
2509
2510         The sampling profiler should further protect itself against certain forms of sampling bias that arise due to the sampling interval being in sync with some other system process
2511         https://bugs.webkit.org/show_bug.cgi?id=158678
2512
2513         Reviewed by Benjamin Poulain.
2514
2515         I first became aware of this problem when I read this paper:
2516         http://plv.colorado.edu/papers/mytkowicz-pldi10.pdf
2517
2518         To provide background for this change, I'll quote a paragraph
2519         from section 6.2:
2520         "One statically sound method for collecting random samples is to collect a
2521         sample at every t + r milliseconds, where t is the desired sampling interval
2522         and r is a random number between −t and t. One might think that sampling every
2523         t seconds is enough (i.e., drop the r component) but it is not: specifically,
2524         if a profiler samples every t seconds, the sampling rate would be synchronized
2525         with any program or system activity that occurs at regular time intervals [17].
2526         For example, if the thread scheduler switches between threads every 10ms and our
2527         sampling interval was also 10ms, then we may always take samples immediately after
2528         a thread switch. Because performance is often different immediately after a thread
2529         switch than at other points (e.g., due to cache and TLB warm-up effects) we would
2530         get biased data. The random component, r, guards against such situations."
2531
2532         * runtime/SamplingProfiler.cpp:
2533         (JSC::SamplingProfiler::timerLoop):
2534
2535 2016-06-13  Oliver Hunt  <oliver@apple.com>
2536
2537         DFG Validation fails when performing a concatenation with only a single entry
2538         https://bugs.webkit.org/show_bug.cgi?id=158699
2539
2540         Reviewed by Saam Barati.
2541
2542         Fairly simple short circuiting of a single replacement template string
2543         without any padding to be planted as a simple to string rather than
2544         op_strcat.
2545
2546         * bytecompiler/NodesCodegen.cpp:
2547         (JSC::TemplateLiteralNode::emitBytecode):
2548         * tests/stress/template-literal.js:
2549         (testSingleNode):
2550
2551 2016-06-13  Filip Pizlo  <fpizlo@apple.com>
2552
2553         FTL::Output methods should be out-of-line whenever possible
2554         https://bugs.webkit.org/show_bug.cgi?id=158704
2555
2556         Reviewed by Benjamin Poulain.
2557         
2558         These methods turn into a non-trivial amount of code because of the template-based B3 API.
2559         Inlining them didn't achieve any performance advantages for the FTL, but it did make the
2560         code larger. This outlines most methods in FTL::Output. It makes FTL::LowerDFGToB3 smaller
2561         and it doesn't change performance.
2562
2563         * ftl/FTLOutput.cpp:
2564         (JSC::FTL::Output::appendTo):
2565         (JSC::FTL::Output::framePointer):
2566         (JSC::FTL::Output::lockedStackSlot):
2567         (JSC::FTL::Output::constBool):
2568         (JSC::FTL::Output::constInt32):
2569         (JSC::FTL::Output::constInt64):
2570         (JSC::FTL::Output::constDouble):
2571         (JSC::FTL::Output::phi):
2572         (JSC::FTL::Output::add):
2573         (JSC::FTL::Output::sub):
2574         (JSC::FTL::Output::mul):
2575         (JSC::FTL::Output::div):
2576         (JSC::FTL::Output::chillDiv):
2577         (JSC::FTL::Output::mod):
2578         (JSC::FTL::Output::chillMod):
2579         (JSC::FTL::Output::neg):
2580         (JSC::FTL::Output::doubleAdd):
2581         (JSC::FTL::Output::doubleSub):
2582         (JSC::FTL::Output::doubleMul):
2583         (JSC::FTL::Output::doubleDiv):
2584         (JSC::FTL::Output::doubleMod):
2585         (JSC::FTL::Output::bitAnd):
2586         (JSC::FTL::Output::bitOr):
2587         (JSC::FTL::Output::bitXor):
2588         (JSC::FTL::Output::shl):
2589         (JSC::FTL::Output::aShr):
2590         (JSC::FTL::Output::lShr):
2591         (JSC::FTL::Output::bitNot):
2592         (JSC::FTL::Output::logicalNot):
2593         (JSC::FTL::Output::ctlz32):
2594         (JSC::FTL::Output::doubleAbs):
2595         (JSC::FTL::Output::doubleCeil):
2596         (JSC::FTL::Output::doubleFloor):
2597         (JSC::FTL::Output::doubleTrunc):
2598         (JSC::FTL::Output::doubleSin):
2599         (JSC::FTL::Output::doubleCos):
2600         (JSC::FTL::Output::doublePow):
2601         (JSC::FTL::Output::doublePowi):
2602         (JSC::FTL::Output::doubleSqrt):
2603         (JSC::FTL::Output::doubleLog):
2604         (JSC::FTL::Output::hasSensibleDoubleToInt):
2605         (JSC::FTL::Output::doubleToUInt):
2606         (JSC::FTL::Output::signExt32To64):
2607         (JSC::FTL::Output::zeroExt):
2608         (JSC::FTL::Output::intToDouble):
2609         (JSC::FTL::Output::unsignedToDouble):
2610         (JSC::FTL::Output::castToInt32):
2611         (JSC::FTL::Output::doubleToFloat):
2612         (JSC::FTL::Output::floatToDouble):
2613         (JSC::FTL::Output::load):
2614         (JSC::FTL::Output::load8SignExt32):
2615         (JSC::FTL::Output::baseIndex):
2616         (JSC::FTL::Output::equal):
2617         (JSC::FTL::Output::notEqual):
2618         (JSC::FTL::Output::above):
2619         (JSC::FTL::Output::aboveOrEqual):
2620         (JSC::FTL::Output::below):
2621         (JSC::FTL::Output::belowOrEqual):
2622         (JSC::FTL::Output::greaterThan):
2623         (JSC::FTL::Output::greaterThanOrEqual):
2624         (JSC::FTL::Output::lessThan):
2625         (JSC::FTL::Output::lessThanOrEqual):
2626         (JSC::FTL::Output::doubleEqual):
2627         (JSC::FTL::Output::doubleEqualOrUnordered):
2628         (JSC::FTL::Output::doubleNotEqualOrUnordered):
2629         (JSC::FTL::Output::doubleLessThan):
2630         (JSC::FTL::Output::doubleLessThanOrEqual):
2631         (JSC::FTL::Output::doubleGreaterThan):
2632         (JSC::FTL::Output::doubleGreaterThanOrEqual):
2633         (JSC::FTL::Output::doubleNotEqualAndOrdered):
2634         (JSC::FTL::Output::doubleLessThanOrUnordered):
2635         (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
2636         (JSC::FTL::Output::doubleGreaterThanOrUnordered):
2637         (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
2638         (JSC::FTL::Output::isZero32):
2639         (JSC::FTL::Output::notZero32):
2640         (JSC::FTL::Output::isZero64):
2641         (JSC::FTL::Output::notZero64):
2642         (JSC::FTL::Output::select):
2643         (JSC::FTL::Output::jump):
2644         (JSC::FTL::Output::branch):
2645         (JSC::FTL::Output::check):
2646         (JSC::FTL::Output::ret):
2647         (JSC::FTL::Output::unreachable):
2648         (JSC::FTL::Output::speculate):
2649         (JSC::FTL::Output::speculateAdd):
2650         (JSC::FTL::Output::speculateSub):
2651         (JSC::FTL::Output::speculateMul):
2652         (JSC::FTL::Output::patchpoint):
2653         (JSC::FTL::Output::trap):
2654         (JSC::FTL::Output::anchor):
2655         (JSC::FTL::Output::bitCast):
2656         (JSC::FTL::Output::fround):
2657         * ftl/FTLOutput.h:
2658         (JSC::FTL::Output::setOrigin):
2659         (JSC::FTL::Output::origin):
2660         (JSC::FTL::Output::constIntPtr):
2661         (JSC::FTL::Output::doubleNeg):
2662         (JSC::FTL::Output::zeroExtPtr):
2663         (JSC::FTL::Output::load32NonNegative):
2664         (JSC::FTL::Output::isNull):
2665         (JSC::FTL::Output::notNull):
2666         (JSC::FTL::Output::testIsZeroPtr):
2667         (JSC::FTL::Output::testNonZeroPtr):
2668         (JSC::FTL::Output::call):
2669         (JSC::FTL::Output::operation):
2670         (JSC::FTL::Output::branch):
2671         (JSC::FTL::Output::switchInstruction):
2672         (JSC::FTL::Output::addIncomingToPhi):
2673         (JSC::FTL::Output::framePointer): Deleted.
2674         (JSC::FTL::Output::constBool): Deleted.
2675         (JSC::FTL::Output::constInt32): Deleted.
2676         (JSC::FTL::Output::constInt64): Deleted.
2677         (JSC::FTL::Output::constDouble): Deleted.
2678         (JSC::FTL::Output::phi): Deleted.
2679         (JSC::FTL::Output::add): Deleted.
2680         (JSC::FTL::Output::sub): Deleted.
2681         (JSC::FTL::Output::mul): Deleted.
2682         (JSC::FTL::Output::div): Deleted.
2683         (JSC::FTL::Output::chillDiv): Deleted.
2684         (JSC::FTL::Output::mod): Deleted.
2685         (JSC::FTL::Output::chillMod): Deleted.
2686         (JSC::FTL::Output::doubleAdd): Deleted.
2687         (JSC::FTL::Output::doubleSub): Deleted.
2688         (JSC::FTL::Output::doubleMul): Deleted.
2689         (JSC::FTL::Output::doubleDiv): Deleted.
2690         (JSC::FTL::Output::doubleMod): Deleted.
2691         (JSC::FTL::Output::bitAnd): Deleted.
2692         (JSC::FTL::Output::bitOr): Deleted.
2693         (JSC::FTL::Output::bitXor): Deleted.
2694         (JSC::FTL::Output::shl): Deleted.
2695         (JSC::FTL::Output::aShr): Deleted.
2696         (JSC::FTL::Output::lShr): Deleted.
2697         (JSC::FTL::Output::ctlz32): Deleted.
2698         (JSC::FTL::Output::addWithOverflow32): Deleted.
2699         (JSC::FTL::Output::subWithOverflow32): Deleted.
2700         (JSC::FTL::Output::mulWithOverflow32): Deleted.
2701         (JSC::FTL::Output::addWithOverflow64): Deleted.
2702         (JSC::FTL::Output::subWithOverflow64): Deleted.
2703         (JSC::FTL::Output::mulWithOverflow64): Deleted.
2704         (JSC::FTL::Output::doubleAbs): Deleted.
2705         (JSC::FTL::Output::doubleCeil): Deleted.
2706         (JSC::FTL::Output::doubleFloor): Deleted.
2707         (JSC::FTL::Output::doubleSin): Deleted.
2708         (JSC::FTL::Output::doubleCos): Deleted.
2709         (JSC::FTL::Output::doublePow): Deleted.
2710         (JSC::FTL::Output::doubleSqrt): Deleted.
2711         (JSC::FTL::Output::doubleLog): Deleted.
2712         (JSC::FTL::Output::signExt32To64): Deleted.
2713         (JSC::FTL::Output::zeroExt): Deleted.
2714         (JSC::FTL::Output::intToDouble): Deleted.
2715         (JSC::FTL::Output::castToInt32): Deleted.
2716         (JSC::FTL::Output::doubleToFloat): Deleted.
2717         (JSC::FTL::Output::floatToDouble): Deleted.
2718         (JSC::FTL::Output::equal): Deleted.
2719         (JSC::FTL::Output::notEqual): Deleted.
2720         (JSC::FTL::Output::above): Deleted.
2721         (JSC::FTL::Output::aboveOrEqual): Deleted.
2722         (JSC::FTL::Output::below): Deleted.
2723         (JSC::FTL::Output::belowOrEqual): Deleted.
2724         (JSC::FTL::Output::greaterThan): Deleted.
2725         (JSC::FTL::Output::greaterThanOrEqual): Deleted.
2726         (JSC::FTL::Output::lessThan): Deleted.
2727         (JSC::FTL::Output::lessThanOrEqual): Deleted.
2728         (JSC::FTL::Output::doubleEqual): Deleted.
2729         (JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
2730         (JSC::FTL::Output::doubleNotEqualOrUnordered): Deleted.
2731         (JSC::FTL::Output::doubleLessThan): Deleted.
2732         (JSC::FTL::Output::doubleLessThanOrEqual): Deleted.
2733         (JSC::FTL::Output::doubleGreaterThan): Deleted.
2734         (JSC::FTL::Output::doubleGreaterThanOrEqual): Deleted.
2735         (JSC::FTL::Output::doubleNotEqualAndOrdered): Deleted.
2736         (JSC::FTL::Output::doubleLessThanOrUnordered): Deleted.
2737         (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): Deleted.
2738         (JSC::FTL::Output::doubleGreaterThanOrUnordered): Deleted.
2739         (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): Deleted.
2740         (JSC::FTL::Output::isZero32): Deleted.
2741         (JSC::FTL::Output::notZero32): Deleted.
2742         (JSC::FTL::Output::isZero64): Deleted.
2743         (JSC::FTL::Output::notZero64): Deleted.
2744         (JSC::FTL::Output::select): Deleted.
2745         (JSC::FTL::Output::extractValue): Deleted.
2746         (JSC::FTL::Output::jump): Deleted.
2747         (JSC::FTL::Output::ret): Deleted.
2748         (JSC::FTL::Output::unreachable): Deleted.
2749         (JSC::FTL::Output::speculate): Deleted.
2750         (JSC::FTL::Output::speculateAdd): Deleted.
2751         (JSC::FTL::Output::speculateSub): Deleted.
2752         (JSC::FTL::Output::speculateMul): Deleted.
2753         (JSC::FTL::Output::patchpoint): Deleted.
2754         (JSC::FTL::Output::trap): Deleted.
2755         (JSC::FTL::Output::anchor): Deleted.
2756         (JSC::FTL::Output::bitCast): Deleted.
2757         (JSC::FTL::Output::fround): Deleted.
2758
2759 2016-06-13  Keith Miller  <keith_miller@apple.com>
2760
2761         Unreviewed, Cloop build fix.
2762
2763         * bytecode/BytecodeList.json:
2764
2765 2016-06-12  Keith Miller  <keith_miller@apple.com>
2766
2767         Add new builtin opcode tailCallForwardArguments
2768         https://bugs.webkit.org/show_bug.cgi?id=158666
2769
2770         Reviewed by Filip Pizlo.
2771
2772         We should support the ability to have a builtin forward its
2773         arguments to a helper without allocating an arguments object. This
2774         patch adds a new bytecode intrinsic @tailCallForwardArguments that
2775         takes two values. The first is the target of the call and the
2776         second is the new this value. This opcode will tail call to the
2777         passed function without triggering an allocation of an arguments
2778         object for the caller function.
2779
2780         In the LLInt and Baseline this function acts the same way a normal
2781         tail call does.  The bytecode will allocate a new stack frame
2782         copying all the arguments of the caller function into the new
2783         frame, along with the new this. Then when the actual call happens
2784         the new frame is copied over the caller frame. While this is not
2785         necessary, it allows the target function to have more arguments
2786         than the caller function via arity fixup.
2787
2788         Once we get to the DFG we reuse existing DFG Nodes for forwarding
2789         arguments, although there were some minor changes. This patch
2790         swaps the meaning of the second and third children for each DFG
2791         varargs node, exchanging the argmuments and this child,
2792         respectively. It also makes the arguments child for each varargs
2793         node, as well as the ForwardVarargs node optional. If the optional
2794         child is missing, then forwarding node assumes that the arguments
2795         for the node's inlineCallFrame should be used instead. Finally,
2796         when inlining the target of an inlined
2797         op_tail_call_forward_arguments we make sure the arguments of the
2798         forwarding function are marked as non-unboxable since this would
2799         normally be done by the caller's create arguments object node,
2800         which does not exist in this case.
2801
2802         * bytecode/BytecodeIntrinsicRegistry.h:
2803         * bytecode/BytecodeList.json:
2804         * bytecode/BytecodeUseDef.h:
2805         (JSC::computeUsesForBytecodeOffset):
2806         (JSC::computeDefsForBytecodeOffset):
2807         * bytecode/CallLinkInfo.h:
2808         (JSC::CallLinkInfo::callTypeFor):
2809         * bytecode/CodeBlock.cpp:
2810         (JSC::CodeBlock::dumpBytecode):
2811         (JSC::CodeBlock::finishCreation):
2812         * bytecompiler/BytecodeGenerator.cpp:
2813         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
2814         (JSC::BytecodeGenerator::emitCallVarargs):
2815         * bytecompiler/BytecodeGenerator.h:
2816         * bytecompiler/NodesCodegen.cpp:
2817         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
2818         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
2819         * dfg/DFGArgumentsEliminationPhase.cpp:
2820         * dfg/DFGByteCodeParser.cpp:
2821         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2822         (JSC::DFG::ByteCodeParser::handleCall):
2823         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2824         (JSC::DFG::ByteCodeParser::handleInlining):
2825         (JSC::DFG::ByteCodeParser::parseBlock):
2826         * dfg/DFGCapabilities.cpp:
2827         (JSC::DFG::capabilityLevel):
2828         * dfg/DFGFixupPhase.cpp:
2829         (JSC::DFG::FixupPhase::fixupNode):
2830         * dfg/DFGNode.h:
2831         (JSC::DFG::Node::hasArgumentsChild):
2832         (JSC::DFG::Node::argumentsChild):
2833         * dfg/DFGPreciseLocalClobberize.h:
2834         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2835         * dfg/DFGPredictionPropagationPhase.cpp:
2836         * dfg/DFGSpeculativeJIT.cpp:
2837         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
2838         * dfg/DFGSpeculativeJIT32_64.cpp:
2839         (JSC::DFG::SpeculativeJIT::emitCall):
2840         * dfg/DFGSpeculativeJIT64.cpp:
2841         (JSC::DFG::SpeculativeJIT::emitCall):
2842         * dfg/DFGVarargsForwardingPhase.cpp:
2843         * ftl/FTLLowerDFGToB3.cpp:
2844         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
2845         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
2846         * interpreter/Interpreter.cpp:
2847         (JSC::sizeFrameForForwardArguments):
2848         (JSC::setupForwardArgumentsFrame):
2849         (JSC::setupForwardArgumentsFrameAndSetThis):
2850         * interpreter/Interpreter.h:
2851         * jit/JIT.cpp:
2852         (JSC::JIT::privateCompileMainPass):
2853         (JSC::JIT::privateCompileSlowCases):
2854         * jit/JIT.h:
2855         * jit/JITCall.cpp:
2856         (JSC::JIT::compileSetupVarargsFrame):
2857         (JSC::JIT::compileOpCall):
2858         (JSC::JIT::compileOpCallSlowCase):
2859         (JSC::JIT::emit_op_tail_call_forward_arguments):
2860         (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
2861         * jit/JITCall32_64.cpp:
2862         (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
2863         (JSC::JIT::emit_op_tail_call_forward_arguments):
2864         (JSC::JIT::compileSetupVarargsFrame):
2865         (JSC::JIT::compileOpCall):
2866         * jit/JITOperations.cpp:
2867         * jit/JITOperations.h:
2868         * llint/LLIntSlowPaths.cpp:
2869         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2870         (JSC::LLInt::varargsSetup):
2871         * llint/LLIntSlowPaths.h:
2872         * llint/LowLevelInterpreter.asm:
2873         * tests/stress/tailCallForwardArguments.js: Added.
2874         (putFuncToPrivateName.createBuiltin):
2875         (putFuncToPrivateName):
2876         (createTailCallForwardingFuncWith):
2877         (baz):
2878         (baz2):
2879         (baz3):
2880         (let.bodyText):
2881         (baz4):
2882         (baz5):
2883         (arrayEq):
2884
2885 2016-06-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2886
2887         Unreviewed, follow up patch for r201964
2888         https://bugs.webkit.org/show_bug.cgi?id=158619
2889
2890         Fix typo in the comment.
2891
2892         * runtime/MathCommon.h:
2893         (JSC::toInt32):
2894
2895 2016-06-13  Mark Lam  <mark.lam@apple.com>
2896
2897         Add a mechanism for collecting LLINT stats.
2898         https://bugs.webkit.org/show_bug.cgi?id=158668
2899
2900         Reviewed by Filip Pizlo.
2901
2902         This patch will add a mechanism for collecting the stats on LLINT opcode
2903         execution counts.  The changes made to enable this are:
2904
2905         1. Refactored how Options availability work so that we can add a new category:
2906            Configurable (in addition to the pre-existing Normal and Restricted
2907            availability).
2908                Normal options - always available.
2909                Restricted options - only available on debug builds.
2910                Configurable options - depends on #define flag options.
2911
2912            This change is necessary so that:
2913            a. we won't have to rebuild the world when we want to enable that #define flag
2914               to make that Configurable option available.
2915            b. when the #define flag is disabled, the option will be invisible to the user.
2916
2917            With this, we add our first configurable option, JSC_reportLLIntStats, which
2918            is dependent on the ENABLE_LLINT_STATS flag.  See next.
2919
2920         2. Added the ENABLE_LLINT_STATS flag in LLIntCommon.h.  To enable LLINT stats
2921            collection, we'll need to set this flag to a non-zero value, and rebuilding
2922            the project.  By design, this will only require a minimal set of files to
2923            be rebuilt.
2924
2925            ENABLE_LLINT_STATS is 0 (i.e. disabled) by default.
2926
2927         3. Added a slow path callback to the LLINT's traceExecution() macro, to call
2928            _llint_count_opcode(), which in turns counts the opcode.  This callback will
2929            only be built into the LLINT if ENABLE_LLINT_STATS is non-zero.
2930
2931         4. Added s_opcodeStatsArray to LLInt::Data.  This is where the stats are
2932            recorded and stored.
2933
2934         5. Added calls to LLInt::Data::dumpStats() in jsc.cpp and DumpRenderTree.mm
2935            to dump the LLINT stats if enabled.  If enabled, the LLINT stats will be
2936            sorted and dumped (via dataLog) before the programs terminate.
2937
2938         * interpreter/Interpreter.h:
2939         * jsc.cpp:
2940         (main):
2941         * llint/LLIntCommon.h:
2942         * llint/LLIntData.cpp:
2943         (JSC::LLInt::initialize):
2944         (JSC::LLInt::Data::dumpStats):
2945         * llint/LLIntData.h:
2946         (JSC::LLInt::Data::opcodeStats):
2947         * llint/LLIntOfflineAsmConfig.h:
2948         * llint/LLIntSlowPaths.cpp:
2949         (JSC::LLInt::llint_crash):
2950         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2951         * llint/LLIntSlowPaths.h:
2952         * llint/LowLevelInterpreter.asm:
2953         * runtime/Options.cpp:
2954         (JSC::parse):
2955         (JSC::Options::isAvailable):
2956         (JSC::overrideOptionWithHeuristic):
2957         (JSC::scaleJITPolicy):
2958         (JSC::Options::initialize):
2959         (JSC::Options::setOptionWithoutAlias):
2960         (JSC::Options::dumpAllOptions):
2961         (JSC::Options::dumpOption):
2962         * runtime/Options.h:
2963         (JSC::Option::Option):
2964         (JSC::Option::operator!=):
2965         (JSC::Option::id):
2966
2967 2016-06-11  Mark Lam  <mark.lam@apple.com>
2968
2969         Minimize the amount of memcpy done for allocating Error stacks.
2970         https://bugs.webkit.org/show_bug.cgi?id=158664
2971
2972         Reviewed by Darin Adler.
2973
2974         Currently, Vector<StackFrame> are being copied around multiple times in the
2975         process of creating Error stacks.
2976
2977         This patch avoids this unnecessary copying by:
2978         1. Sizing the StackFrame vector correctly to begin with, and skipping
2979            undesirable top frames before filling in the vector.
2980         2. Using perfect forwarding or passing by reference to pass the vector data around
2981            instead of copying the vectors.
2982         3. Changing the Exception object to take a Vector<StackFrame> instead of a
2983            RefCountedArray<StackFrame>.
2984
2985         This patch has passed the JSC and layout tests.  Benchmarks show that perf is
2986         neutral.
2987
2988         * API/tests/testapi.mm:
2989         (testObjectiveCAPI):
2990         * inspector/ScriptCallStackFactory.cpp:
2991         (Inspector::createScriptCallStackFromException):
2992         * interpreter/Interpreter.cpp:
2993         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
2994         (JSC::GetStackTraceFunctor::operator()):
2995         (JSC::Interpreter::getStackTrace):
2996         (JSC::Interpreter::stackTraceAsString):
2997         (JSC::findExceptionHandler):
2998         * interpreter/Interpreter.h:
2999         * runtime/Error.cpp:
3000         (JSC::addErrorInfoAndGetBytecodeOffset):
3001         * runtime/Exception.cpp:
3002         (JSC::Exception::finishCreation):
3003         * runtime/Exception.h:
3004         (JSC::Exception::valueOffset):
3005         (JSC::Exception::value):
3006         (JSC::Exception::stack):
3007         (JSC::Exception::didNotifyInspectorOfThrow):
3008         (JSC::Exception::setDidNotifyInspectorOfThrow):
3009
3010 2016-06-11  Mark Lam  <mark.lam@apple.com>
3011
3012         Tests that overflows the stack should not be run with the sampling profiler.
3013         https://bugs.webkit.org/show_bug.cgi?id=158663
3014
3015         Reviewed by Saam Barati.
3016
3017         The sampling profiler will be sampling the whole stack, and the amount of memory
3018         churn will make this tests time out, especially with debug builds.  Hence,
3019         let's not run the test with the sampling profiler configuration.
3020
3021         * tests/stress/mutual-tail-call-no-stack-overflow.js:
3022         (shouldThrow):
3023
3024 2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3025
3026         Unreviewed, attempt to fix r201964 failure on Apple ports
3027         https://bugs.webkit.org/show_bug.cgi?id=158619
3028
3029         Reviewed by Mark Lam.
3030
3031         Add Private attributes to MathCommon.h.
3032
3033         * JavaScriptCore.xcodeproj/project.pbxproj:
3034
3035 2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3036
3037         [JSC] Inline JSC::toInt32 to improve kraken
3038         https://bugs.webkit.org/show_bug.cgi?id=158619
3039
3040         Reviewed by Mark Lam.
3041
3042         Several kraken benchmarks show that JSC::toInt32 is frequently called.
3043         For example, stanford-crypto-pbkdf2 reports that the hottest runtime function is JSC::toInt32.
3044
3045         The data is below (taken by Linux perf tools).
3046         5.50%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC7toInt32Ed
3047         3.96%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC20arrayProtoFuncConcatEPNS_9ExecStateE
3048         2.48%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC19arrayProtoFuncSliceEPNS_9ExecStateE
3049         1.69%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZNK3JSC9Structure27holesMustForwardToPrototypeERNS_2VME
3050
3051         This is because of CommonSlowPaths' bit operations's JSValue::toInt32.
3052         Due to the slow path, in `value | 0`, `value` may be a double number value. In that case, JSC::toInt32 is called.
3053
3054         While JSC::toIn32 is hot, the function itself is very small. It's worth inlining.
3055
3056         This change offers the following kraken improvements.
3057
3058                                                          baseline                  patched
3059         Kraken:
3060            audio-beat-detection                       47.492+-1.701             46.657+-1.232           might be 1.0179x faster
3061            stanford-crypto-aes                        43.669+-0.210      ^      42.862+-0.115         ^ definitely 1.0188x faster
3062            stanford-crypto-ccm                        45.213+-1.424             44.490+-1.290           might be 1.0162x faster
3063            stanford-crypto-pbkdf2                    107.665+-0.581      ^     106.229+-0.807         ^ definitely 1.0135x faster
3064
3065         This patch only focused on the call to toInt32 from the runtime functions.
3066         So JSC::toInt32 calls from the baseline / DFG remain.
3067         We ensure that JIT code uses operationToInt32 instead of JSC::toInt32 since JSC::toInt32 is now marked as ALWAYS_INLINE.
3068         Linux perf profiler also finds that this `operationToInt32` is frequently called in the above benchmarks.
3069         It may be good to introduce asm emit for that instead of calling JSC::toInt32 operation in the separated patch.
3070
3071         * dfg/DFGSpeculativeJIT.cpp:
3072         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3073         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
3074         * ftl/FTLLowerDFGToB3.cpp:
3075         (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
3076         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
3077         * runtime/JSCJSValue.cpp:
3078         (JSC::toInt32): Deleted.
3079         * runtime/JSCJSValueInlines.h:
3080         * runtime/MathCommon.cpp:
3081         (JSC::operationToInt32):
3082         * runtime/MathCommon.h:
3083         (JSC::toInt32):
3084
3085 2016-06-10  Filip Pizlo  <fpizlo@apple.com>
3086
3087         The backend should be happy to compile Unreachable even if AI didn't prove it to be unreachable
3088         https://bugs.webkit.org/show_bug.cgi?id=158631
3089
3090         Reviewed by Keith Miller.
3091         
3092         We've been slowly making the DFG Unreachable opcode behave like a grown-up. When we first
3093         added it, it was a hack for Throw, and we could always rely on AI proving that Unreachable
3094         was not reachable. But then we started using Unreachable as a proper Unreachable opcode,
3095         like Oops in B3 for example, which has a more nuanced meaning: you use it whenever you
3096         emit code that *you* know will not return, and you need some way of terminating the basic
3097         block. The DFG is not a proof-carrying compiler, and it never will be. So, when you have
3098         proved that something is not reachable, you should be able to use Unreachable even if
3099         there is no guarantee that the compiler will later be able to replicate your proof. This
3100         means that the backend may find itself compiling Unreachable because AI did not prove that
3101         it was unreachable.
3102         
3103         Prior to this change, we would crash compiling Unreachable because we would rely on AI
3104         preventing us from reaching Unreachable in the backend. But that's silly! We don't want
3105         users of Unreachable to have to also convince AI that their Unreachable is really
3106         Unreachable.
3107         
3108         This fixes crashes on real websites. I couldn't work out how to turn them into a reduced
3109         test.
3110
3111         * assembler/AbortReason.h:
3112         * dfg/DFGSpeculativeJIT.cpp:
3113         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
3114         (JSC::DFG::SpeculativeJIT::unreachable):
3115         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
3116         * dfg/DFGSpeculativeJIT.h:
3117         * dfg/DFGSpeculativeJIT32_64.cpp:
3118         (JSC::DFG::SpeculativeJIT::compile):
3119         * dfg/DFGSpeculativeJIT64.cpp:
3120         (JSC::DFG::SpeculativeJIT::compile):
3121         * ftl/FTLLowerDFGToB3.cpp:
3122         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3123         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
3124         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable):
3125         (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
3126
3127 2016-06-09  Alex Christensen  <achristensen@webkit.org>
3128
3129         Clean up JavaScriptCore.vcxproj directory after switching to CMake.
3130
3131         * JavaScriptCore.vcxproj/LLInt: Removed.
3132         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly: Removed.
3133         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: Removed.
3134         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Removed.
3135         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Removed.
3136         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets: Removed.
3137         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
3138         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed.
3139         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Removed.
3140         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor: Removed.
3141         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed.
3142         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed.
3143         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed.
3144         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Removed.
3145         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed.
3146         * JavaScriptCore.vcxproj/jsc: Removed.
3147         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Removed.
3148         * JavaScriptCore.vcxproj/jsc/DLLLauncherWinCairo.props: Removed.
3149         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Removed.
3150         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Removed.
3151         * JavaScriptCore.vcxproj/jsc/jscCommon.props: Removed.
3152         * JavaScriptCore.vcxproj/jsc/jscDebug.props: Removed.
3153         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj: Removed.
3154         * JavaScriptCore.vcxproj/jsc/jscLauncherPostBuild.cmd: Removed.
3155         * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd: Removed.
3156         * JavaScriptCore.vcxproj/jsc/jscLauncherPreLink.cmd: Removed.
3157         * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Removed.
3158         * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Removed.
3159         * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Removed.
3160         * JavaScriptCore.vcxproj/jsc/jscProduction.props: Removed.
3161         * JavaScriptCore.vcxproj/jsc/jscRelease.props: Removed.
3162         * JavaScriptCore.vcxproj/testRegExp: Removed.
3163         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Removed.
3164         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Removed.
3165         * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Removed.
3166         * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Removed.
3167         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj: Removed.
3168         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPostBuild.cmd: Removed.
3169         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd: Removed.
3170         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreLink.cmd: Removed.
3171         * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Removed.
3172         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Removed.
3173         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Removed.
3174         * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Removed.
3175         * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Removed.
3176         * JavaScriptCore.vcxproj/testapi: Removed.
3177         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Removed.
3178         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Removed.
3179         * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Removed.
3180         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Removed.
3181         * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Removed.
3182         * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Removed.
3183         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj: Removed.
3184         * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd: Removed.
3185         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd: Removed.
3186         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreLink.cmd: Removed.
3187         * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Removed.
3188         * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Removed.
3189         * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Removed.
3190         * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Removed.
3191         * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Removed.
3192         * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Removed.
3193         * shell/DLLLauncherMain.cpp: Copied from JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp.
3194         * shell/PlatformWin.cmake:
3195
3196 2016-06-09  Filip Pizlo  <fpizlo@apple.com>
3197
3198         Rare failure in stress/v8-deltablue-strict.js.ftl-eager
3199         https://bugs.webkit.org/show_bug.cgi?id=158591
3200
3201         Reviewed by Saam Barati.
3202         
3203         This is a simple and sensible fix to an amazing compiler bug that previously only
3204         manifested rarely in the v8-deltablue-strict test. It required on average 1000 runs while
3205         the system was under load for the bug to manifest. Fortunately, the bug is 100% repro with
3206         concurrent JIT disabled in the new "constant-fold-multi-get-by-offset-to-get-by-offset-on-
3207         prototype-and-sink-allocation.js" test.
3208         
3209         The problem here is that we were allowing ourselves to be super sloppy with the meaning of
3210         the two children of GetByOffset, and to a lesser extent, PutByOffset. The first two
3211         children of these nodes have these meanings:
3212         
3213         child1: the storage from which to load (or to which to store)
3214         child2: the logical object base
3215         
3216         Normally, child1 == child2, but child1 may point to a node that vends the storage pointer
3217         in case we are using multiple indirections to get to the property. That's fairly common.
3218         
3219         Where this gets nutty is that we don't validate the behavior of child1. Previously, the
3220         DFG::Validate phase would accept code that had child1 point to one object and child2 point
3221         to another object. That's bad because then, analyses will assume that we're loading from
3222         one object while we are actually loading from another. One of the fixes is to make
3223         Validate smarter about this, so that future problems with this get caught sooner.
3224         
3225         The actual bug was in ConstantFoldingPhase. When we first wrote ConstantFoldingPhase's
3226         logic for converting GetByIds and MultiGetByOffsets to GetByOffset, we assumed that this
3227         was only for non-prototype loads. This was becuase the logic was originally written based
3228         on a static GetByIdStatus analysis, which does not handle prototypes. So, as a shortcut,
3229         we would convert the GetById (or MultiGetByOffset) to a GetByOffset by doing this
3230         shuffling of children:
3231         
3232         child1 got the storage pointer, which might be a new GetButterfly node that we created.
3233         child2 got the old value of child1.
3234         
3235         The bug was introduced when I later made it possible for a monomorphic prototype
3236         MultiGetByOffset to be converted to a GetByOffset. Then this algorithm would mean that:
3237         
3238         child1 got either a pointer to the prototype or a storage pointer derived from the
3239             prototype.
3240         child2 got the old value of child1, which was a pointer to the base object (i.e. not the
3241             prototype).
3242         
3243         This happens super rarely because most prototype loads that we can statically reason about
3244         also happen to load constants, so we don't convert to GetByOffset at all. You need the
3245         strange combination of a MultiGetByOffset (not GetById or GetByOffset) on some prototypes
3246         and some static reasoning about the base so that we can convert it to a GetByOffset, but
3247         not enough static reasoning that we can convert it to a constant.
3248         
3249         Even if the bad thing happened, then this is not enough for it to cause symptons. If we
3250         did nothing else - like none of the other optimizations succeeded - then this would
3251         be OK because the backend will emit code based on child1, which is right. But disaster
3252         strikes when the code otherwise looks sane enough for ObjectAllocationSinkingPhase to kick
3253         in. This phase operates on child2, as any good phase should: child1 is only interesting
3254         for knowing *how* to load, not *what* we are loading. The phase is right to ignore child1.
3255
3256         So the phase would assume that we are loading the prototype property ("f" in the new test
3257         or "addToGraph" in deltablue) from the sunken base object allocation in the inlined
3258         constructor. The base object has no such property, but the phase conservatively assumes
3259         that it does indeed have such a property. That's just how the phase does things: it is
3260         very abstract and general, so it assumes that the set of properties on an allocation is
3261         the set of properties that accesses to the allocation speak of. Clearly, this GetByOffset
3262         was speaking of the property as being on the allocation. When sinking completed, it would
3263         convert the GetByOffset to the sunken (a.k.a. promoted) property. But nobody stored to
3264         this property on the allocation, so we'd get the bottom value, which is 1927. Why 1927? I
3265         don't remember anymore, but apparently I chose it. It helped here - when I started seeing
3266         that value come up, it took a quick grep to realize that this was the object allocation
3267         sinking phase's bottom value.
3268         
3269         The real fix to the bug is to make Node::convertToGetByOffset() take an explicit new base
3270         since its clients will use it to potentially create a load on a different object than the
3271         base of the original operation, as in the relatively new
3272         MultiGetByOffset(prototype)->GetByOffset optimization. As far as I know, the PutByOffset
3273         code did not have the same bug because we don't have any optimizations that turn a PutById
3274         or MultiPutByOffset into a PutByOffset on anything but the base object. But the logical