DFG::LazyJSValue::tryGetStringImpl() crashes for empty values
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-05-27  Filip Pizlo  <fpizlo@apple.com>
2
3         DFG::LazyJSValue::tryGetStringImpl() crashes for empty values
4         https://bugs.webkit.org/show_bug.cgi?id=158170
5
6         Reviewed by Michael Saboff.
7
8         The problem here is that jsDynamicCast<>() is evil! It avoids checking for the empty
9         value, presumably because this makes it soooper fast. In DFG IR, empty values can appear
10         anywhere because of TDZ.
11         
12         This patch doesn't change jsDynamicCast<>(), but it hardens our wrappers for it in the DFG
13         and it has the affected code use one of those wrappers.
14         
15         * dfg/DFGFrozenValue.h:
16         (JSC::DFG::FrozenValue::dynamicCast): Harden this.
17         (JSC::DFG::FrozenValue::cast):
18         * dfg/DFGLazyJSValue.cpp:
19         (JSC::DFG::LazyJSValue::tryGetStringImpl): Use the hardened wrapper.
20         * tests/stress/strcat-emtpy.js: Added. This used to crash every time.
21         (foo):
22         (i.catch):
23
24 2016-05-27  Filip Pizlo  <fpizlo@apple.com>
25
26         regExpProtoFuncSplitFast should OOM before it swaps
27         https://bugs.webkit.org/show_bug.cgi?id=158157
28
29         Reviewed by Mark Lam.
30         
31         This is a huge speed-up on some jsfunfuzz test cases because it makes us realize much
32         sooner that running a regexp split will result in swapping. It uses the same basic
33         approach as http://trac.webkit.org/changeset/201451: if the result array crosses a certain
34         size threshold, we proceed with a dry run to see how big the array will get before
35         allocating anything else. This way, bogus uses of split that would have OOMed only after
36         killing the user's machine will now OOM before killing the user's machine.
37         
38         This is an enormous speed-up on some jsfunfuzz tests: they go from running for a long
39         time to running instantly.
40
41         * runtime/RegExpPrototype.cpp:
42         (JSC::advanceStringIndex):
43         (JSC::genericSplit):
44         (JSC::regExpProtoFuncSplitFast):
45         * runtime/StringObject.h:
46         (JSC::jsStringWithReuse):
47         (JSC::jsSubstring):
48         * tests/stress/big-split-captures.js: Added.
49         * tests/stress/big-split.js: Added.
50
51 2016-05-27  Saam barati  <sbarati@apple.com>
52
53         ShadowChicken/DebuggerCallFrame don't properly handle when the entry stack frame is a tail deleted frame
54         https://bugs.webkit.org/show_bug.cgi?id=158131
55
56         Reviewed by Yusuke Suzuki.
57
58         There were bugs both in DebuggerCallFrame and ShadowChicken when the entry stack
59         frame(s) are tail deleted.
60
61         DebuggerCallFrame had an assertion saying that the entry frame shouldn't be
62         tail deleted. This is clearly wrong. The following program proves that this assertion
63         was misguided:
64         ```
65         "use strict";
66         setTimeout(function foo() { return bar(); }, 0);
67         ```
68
69         ShadowChicken had a very subtle bug when creating the shadow stack when 
70         the entry frames of the stack were tail deleted. Because it places frames into its shadow
71         stack by walking the machine frame and looking up entries in the log,
72         the machine frame doesn't have any notion of those tail deleted frames
73         at the entry of execution. ShadowChicken would never find those frames
74         because it would look for tail deleted frames *before* consulting the
75         current machine frame. This is wrong because if the entry frames
76         are tail deleted, then there is no machine frame for them because there
77         is no machine frame before them! Therefore, we must search for tail deleted
78         frames *after* consulting a machine frame. This is sound because we will always
79         have at least one machine frame on the stack (when we are using StackVisitor on a valid ExecState).
80         So when we consult the machine frame that is the entry frame on the machine stack,
81         we will search for tail deleted frames that come before it in the shadow stack.
82         This will allow us to find those tail deleted frames that are the entry frames
83         for the shadow stack.
84
85         * debugger/DebuggerCallFrame.cpp:
86         (JSC::DebuggerCallFrame::create):
87         * interpreter/ShadowChicken.cpp:
88         (JSC::ShadowChicken::Packet::dump):
89         (JSC::ShadowChicken::update):
90         (JSC::ShadowChicken::dump):
91
92 2016-05-27  Chris Dumez  <cdumez@apple.com>
93
94         WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables
95         https://bugs.webkit.org/show_bug.cgi?id=158111
96
97         Reviewed by Darin Adler.
98
99         WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables.
100         These are often used cross-thread and copying the captured lambda variables can be
101         dangerous (e.g. we do not want to copy a String after calling isolatedCopy() upon
102         capture).
103
104         * runtime/Watchdog.cpp:
105         (JSC::Watchdog::startTimer):
106         (JSC::Watchdog::Watchdog): Deleted.
107         (JSC::Watchdog::setTimeLimit): Deleted.
108         * runtime/Watchdog.h:
109
110 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
111
112         Removed unused headers from ExecutableAllocatorFixedVMPool.cpp.
113         https://bugs.webkit.org/show_bug.cgi?id=158159
114
115         Reviewed by Darin Adler.
116
117         * jit/ExecutableAllocatorFixedVMPool.cpp:
118
119 2016-05-27  Keith Miller  <keith_miller@apple.com>
120
121         get_by_id should support caching unset properties in the LLInt
122         https://bugs.webkit.org/show_bug.cgi?id=158136
123
124         Reviewed by Benjamin Poulain.
125
126         Recently, we started supporting prototype load caching for get_by_id
127         in the LLInt. This patch extends that to caching unset properties.
128         While it is uncommon in general for a program to see a single structure
129         without a given property, the Array.prototype.concat function needs to
130         lookup the Symbol.isConcatSpreadable property. For any existing code
131         That property will never be set as it did not exist prior to ES6.
132
133         Similarly to the get_by_id_proto_load bytecode, this patch adds a new
134         bytecode, get_by_id_unset that checks the structureID of the base and
135         assigns undefined to the result.
136
137         There are no new tests here since we already have many tests that
138         incidentally cover this change.
139
140         * bytecode/BytecodeList.json:
141         * bytecode/BytecodeUseDef.h:
142         (JSC::computeUsesForBytecodeOffset):
143         (JSC::computeDefsForBytecodeOffset):
144         * bytecode/CodeBlock.cpp:
145         (JSC::CodeBlock::printGetByIdOp):
146         (JSC::CodeBlock::dumpBytecode):
147         (JSC::CodeBlock::finalizeLLIntInlineCaches):
148         * bytecode/GetByIdStatus.cpp:
149         (JSC::GetByIdStatus::computeFromLLInt):
150         * dfg/DFGByteCodeParser.cpp:
151         (JSC::DFG::ByteCodeParser::parseBlock):
152         * dfg/DFGCapabilities.cpp:
153         (JSC::DFG::capabilityLevel):
154         * jit/JIT.cpp:
155         (JSC::JIT::privateCompileMainPass):
156         (JSC::JIT::privateCompileSlowCases):
157         * llint/LLIntSlowPaths.cpp:
158         (JSC::LLInt::setupGetByIdPrototypeCache):
159         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
160         * llint/LLIntSlowPaths.h:
161         * llint/LowLevelInterpreter32_64.asm:
162         * llint/LowLevelInterpreter64.asm:
163
164 2016-05-26  Filip Pizlo  <fpizlo@apple.com>
165
166         Bogus uses of regexp matching should realize that they will OOM before they start swapping
167         https://bugs.webkit.org/show_bug.cgi?id=158142
168
169         Reviewed by Michael Saboff.
170         
171         Refactored the RegExpObject::matchGlobal() code so that there is less duplication. Took
172         advantage of this to make the code more resilient in case of absurd situations: if the
173         result array gets large, it proceeds with a dry run to detect how many matches there will
174         be. This allows it to OOM before it starts swapping.
175         
176         This also improves the overall performance of the code by using lightweight substrings and
177         skipping the whole intermediate argument array.
178         
179         This makes some jsfunfuzz tests run a lot faster and use a lot less memory.
180         
181         * builtins/RegExpPrototype.js:
182         * CMakeLists.txt:
183         * JavaScriptCore.xcodeproj/project.pbxproj:
184         * runtime/MatchResult.cpp: Added.
185         (JSC::MatchResult::dump):
186         * runtime/MatchResult.h:
187         (JSC::MatchResult::empty):
188         (MatchResult::empty): Deleted.
189         * runtime/RegExpObject.cpp:
190         (JSC::RegExpObject::match):
191         (JSC::collectMatches):
192         (JSC::RegExpObject::matchGlobal):
193         * runtime/StringObject.h:
194         (JSC::jsStringWithReuse):
195         (JSC::jsSubstring):
196         * tests/stress/big-match.js: Added. Make sure that this optimization doesn't break big matches.
197
198 2016-05-26  Gavin & Ellie Barraclough  <barraclough@apple.com>
199
200         Static table property lookup should not require getOwnPropertySlot override.
201         https://bugs.webkit.org/show_bug.cgi?id=158059
202
203         Reviewed by Darin Adler.
204
205         Currently JSObject does not handle property lookup of entries in the static
206         table. Each subclass with static properties mut override getOwnPropertySlot,
207         and explicitly call the lookup functions. This has the following drawbacks:
208
209         - Performance: for any class with static properties, property acces becomes
210           virtual (via method table).
211         - Poor encapsulation: implementation detail of static property access is
212           spread throughout & cross projects, rather than being contained in JSObject.
213         - Code size: this results in a great many additional functions.
214         - Inconsistency: static table presence has to be be taken into account in many
215           other operations, e.g. presence of read-only properties for put.
216         - Memory: in order to avoid the virtual lookup, DOM prototypes eagerly reify
217           all properties. This is likely suboptimal.
218
219         Instead, JSObject::getPropertySlot / JSObject::getOwnPropertySlot should be
220         able to handle static properties.
221
222         This is actually a fairly small & simple change.
223
224         The common pattern is for subclasses of JObject to override getOwnPropertySlot
225         to first defer to JSObject for property storage lookup, and only if this fails
226         consult the static table. They just want the static tables to be consulted after
227         regular property storgae lookup. So just add a fast flag in TypeInfo for JSObject
228         to check, and where it is set, do so. Then it's just a question of switching
229         classes over to start setting this flag, and drop the override.
230
231         The new mechanism does change static table lookup order from oldest-ancestor
232         first to most-derived first. The new ordering makes more sense (means derived
233         class static tables can now override entries from parents), and shoudn't affect
234         any existing code (since overriding didn't previously work, there likely aren't
235         shadowing properties in more derived types).
236
237         This patch changes all classes in JavaScriptCore over to using the new mechanism,
238         except JSGlobalObject. I'll move classes in WebCore over as a separate patch
239         (this is also why I've not moved JSGlobalObject in this patch - doing so would
240         move JSDOMWindow, and I'd rather handle that separately).
241
242         * runtime/JSTypeInfo.h:
243         (JSC::TypeInfo::hasStaticPropertyTable):
244             - Add HasStaticPropertyTable flag.
245         * runtime/Lookup.cpp:
246         (JSC::setUpStaticFunctionSlot):
247             - Change setUpStaticFunctionSlot to take a VM&.
248         * runtime/Lookup.h:
249         (JSC::getStaticPropertySlotFromTable):
250             - Added helper function to perform static lookup alone.
251         (JSC::getStaticPropertySlot):
252         (JSC::getStaticFunctionSlot):
253             - setUpStaticFunctionSlot changed to take a VM&.
254         * runtime/JSObject.cpp:
255         (JSC::JSObject::getOwnStaticPropertySlot):
256             - Added, walks ClassInfo chain looking for static properties.
257         * runtime/JSObject.h:
258         (JSC::JSObject::getOwnNonIndexPropertySlot):
259             - getOwnNonIndexPropertySlot is used internally by getPropertySlot
260               & getOwnPropertySlot. If property is not present in storage array
261               then check the static table.
262         * runtime/ArrayConstructor.cpp:
263         (JSC::ArrayConstructor::finishCreation):
264         (JSC::constructArrayWithSizeQuirk):
265         (JSC::ArrayConstructor::getOwnPropertySlot): Deleted.
266         * runtime/ArrayConstructor.h:
267         (JSC::ArrayConstructor::create):
268         * runtime/ArrayIteratorPrototype.cpp:
269         (JSC::ArrayIteratorPrototype::finishCreation):
270         (JSC::ArrayIteratorPrototype::getOwnPropertySlot): Deleted.
271         * runtime/ArrayIteratorPrototype.h:
272         (JSC::ArrayIteratorPrototype::create):
273         (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype):
274         * runtime/BooleanPrototype.cpp:
275         (JSC::BooleanPrototype::finishCreation):
276         (JSC::booleanProtoFuncToString):
277         (JSC::BooleanPrototype::getOwnPropertySlot): Deleted.
278         * runtime/BooleanPrototype.h:
279         (JSC::BooleanPrototype::create):
280         * runtime/DateConstructor.cpp:
281         (JSC::DateConstructor::finishCreation):
282         (JSC::millisecondsFromComponents):
283         (JSC::DateConstructor::getOwnPropertySlot): Deleted.
284         * runtime/DateConstructor.h:
285         (JSC::DateConstructor::create):
286         * runtime/DatePrototype.cpp:
287         (JSC::DatePrototype::finishCreation):
288         (JSC::dateProtoFuncToString):
289         (JSC::DatePrototype::getOwnPropertySlot): Deleted.
290         * runtime/DatePrototype.h:
291         (JSC::DatePrototype::create):
292         * runtime/ErrorPrototype.cpp:
293         (JSC::ErrorPrototype::finishCreation):
294         (JSC::ErrorPrototype::getOwnPropertySlot): Deleted.
295         * runtime/ErrorPrototype.h:
296         (JSC::ErrorPrototype::create):
297         * runtime/GeneratorPrototype.cpp:
298         (JSC::GeneratorPrototype::finishCreation):
299         (JSC::GeneratorPrototype::getOwnPropertySlot): Deleted.
300         * runtime/GeneratorPrototype.h:
301         (JSC::GeneratorPrototype::create):
302         (JSC::GeneratorPrototype::createStructure):
303         (JSC::GeneratorPrototype::GeneratorPrototype):
304         * runtime/InspectorInstrumentationObject.cpp:
305         (JSC::InspectorInstrumentationObject::finishCreation):
306         (JSC::InspectorInstrumentationObject::isEnabled):
307         (JSC::InspectorInstrumentationObject::getOwnPropertySlot): Deleted.
308         * runtime/InspectorInstrumentationObject.h:
309         (JSC::InspectorInstrumentationObject::create):
310         (JSC::InspectorInstrumentationObject::createStructure):
311         * runtime/IntlCollatorConstructor.cpp:
312         (JSC::IntlCollatorConstructor::getCallData):
313         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
314         (JSC::IntlCollatorConstructor::getOwnPropertySlot): Deleted.
315         * runtime/IntlCollatorConstructor.h:
316         * runtime/IntlCollatorPrototype.cpp:
317         (JSC::IntlCollatorPrototype::finishCreation):
318         (JSC::IntlCollatorFuncCompare):
319         (JSC::IntlCollatorPrototype::getOwnPropertySlot): Deleted.
320         * runtime/IntlCollatorPrototype.h:
321         * runtime/IntlDateTimeFormatConstructor.cpp:
322         (JSC::IntlDateTimeFormatConstructor::getCallData):
323         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
324         (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): Deleted.
325         * runtime/IntlDateTimeFormatConstructor.h:
326         * runtime/IntlDateTimeFormatPrototype.cpp:
327         (JSC::IntlDateTimeFormatPrototype::finishCreation):
328         (JSC::IntlDateTimeFormatFuncFormatDateTime):
329         (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): Deleted.
330         * runtime/IntlDateTimeFormatPrototype.h:
331         * runtime/IntlNumberFormatConstructor.cpp:
332         (JSC::IntlNumberFormatConstructor::getCallData):
333         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
334         (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): Deleted.
335         * runtime/IntlNumberFormatConstructor.h:
336         * runtime/IntlNumberFormatPrototype.cpp:
337         (JSC::IntlNumberFormatPrototype::finishCreation):
338         (JSC::IntlNumberFormatFuncFormatNumber):
339         (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): Deleted.
340         * runtime/IntlNumberFormatPrototype.h:
341         * runtime/JSDataViewPrototype.cpp:
342         (JSC::JSDataViewPrototype::createStructure):
343         (JSC::getData):
344         (JSC::JSDataViewPrototype::getOwnPropertySlot): Deleted.
345         * runtime/JSDataViewPrototype.h:
346         * runtime/JSInternalPromiseConstructor.cpp:
347         (JSC::JSInternalPromiseConstructor::getCallData):
348         (JSC::JSInternalPromiseConstructor::getOwnPropertySlot): Deleted.
349         * runtime/JSInternalPromiseConstructor.h:
350         * runtime/JSONObject.cpp:
351         (JSC::Walker::Walker):
352         (JSC::JSONObject::getOwnPropertySlot): Deleted.
353         * runtime/JSONObject.h:
354         (JSC::JSONObject::create):
355         * runtime/JSPromiseConstructor.cpp:
356         (JSC::JSPromiseConstructor::getCallData):
357         (JSC::JSPromiseConstructor::getOwnPropertySlot): Deleted.
358         * runtime/JSPromiseConstructor.h:
359         * runtime/JSPromisePrototype.cpp:
360         (JSC::JSPromisePrototype::addOwnInternalSlots):
361         (JSC::JSPromisePrototype::getOwnPropertySlot): Deleted.
362         * runtime/JSPromisePrototype.h:
363         * runtime/MapPrototype.cpp:
364         (JSC::MapPrototype::finishCreation):
365         (JSC::getMap):
366         (JSC::MapPrototype::getOwnPropertySlot): Deleted.
367         * runtime/MapPrototype.h:
368         (JSC::MapPrototype::create):
369         (JSC::MapPrototype::MapPrototype):
370         * runtime/ModuleLoaderObject.cpp:
371         (JSC::ModuleLoaderObject::finishCreation):
372         (JSC::printableModuleKey):
373         (JSC::ModuleLoaderObject::getOwnPropertySlot): Deleted.
374         * runtime/ModuleLoaderObject.h:
375         * runtime/NumberPrototype.cpp:
376         (JSC::NumberPrototype::finishCreation):
377         (JSC::toThisNumber):
378         (JSC::NumberPrototype::getOwnPropertySlot): Deleted.
379         * runtime/NumberPrototype.h:
380         (JSC::NumberPrototype::create):
381         * runtime/ObjectConstructor.cpp:
382         (JSC::ObjectConstructor::addDefineProperty):
383         (JSC::constructObject):
384         (JSC::ObjectConstructor::getOwnPropertySlot): Deleted.
385         * runtime/ObjectConstructor.h:
386         (JSC::ObjectConstructor::create):
387         (JSC::ObjectConstructor::createStructure):
388         * runtime/ReflectObject.cpp:
389         (JSC::ReflectObject::finishCreation):
390         (JSC::ReflectObject::getOwnPropertySlot): Deleted.
391         * runtime/ReflectObject.h:
392         (JSC::ReflectObject::create):
393         (JSC::ReflectObject::createStructure):
394         * runtime/RegExpConstructor.cpp:
395         (JSC::RegExpConstructor::getRightContext):
396         (JSC::regExpConstructorDollar):
397         (JSC::RegExpConstructor::getOwnPropertySlot): Deleted.
398         * runtime/RegExpConstructor.h:
399         (JSC::RegExpConstructor::create):
400         (JSC::RegExpConstructor::createStructure):
401         * runtime/SetPrototype.cpp:
402         (JSC::SetPrototype::finishCreation):
403         (JSC::getSet):
404         (JSC::SetPrototype::getOwnPropertySlot): Deleted.
405         * runtime/SetPrototype.h:
406         (JSC::SetPrototype::create):
407         (JSC::SetPrototype::SetPrototype):
408         * runtime/StringConstructor.cpp:
409         (JSC::StringConstructor::finishCreation):
410         (JSC::stringFromCharCodeSlowCase):
411         (JSC::StringConstructor::getOwnPropertySlot): Deleted.
412         * runtime/StringConstructor.h:
413         (JSC::StringConstructor::create):
414         * runtime/StringIteratorPrototype.cpp:
415         (JSC::StringIteratorPrototype::finishCreation):
416         (JSC::StringIteratorPrototype::getOwnPropertySlot): Deleted.
417         * runtime/StringIteratorPrototype.h:
418         (JSC::StringIteratorPrototype::create):
419         (JSC::StringIteratorPrototype::StringIteratorPrototype):
420         * runtime/StringPrototype.cpp:
421         (JSC::StringPrototype::create):
422         (JSC::substituteBackreferencesSlow):
423         (JSC::StringPrototype::getOwnPropertySlot): Deleted.
424         * runtime/StringPrototype.h:
425         * runtime/SymbolConstructor.cpp:
426         (JSC::SymbolConstructor::finishCreation):
427         (JSC::callSymbol):
428         (JSC::SymbolConstructor::getOwnPropertySlot): Deleted.
429         * runtime/SymbolConstructor.h:
430         (JSC::SymbolConstructor::create):
431         * runtime/SymbolPrototype.cpp:
432         (JSC::SymbolPrototype::finishCreation):
433         (JSC::SymbolPrototype::getOwnPropertySlot): Deleted.
434         * runtime/SymbolPrototype.h:
435         (JSC::SymbolPrototype::create):
436             - remove getOwnPropertySlot, replace OverridesGetOwnPropertySlot flag with HasStaticPropertyTable.
437
438 2016-05-26  Commit Queue  <commit-queue@webkit.org>
439
440         Unreviewed, rolling out r201436.
441         https://bugs.webkit.org/show_bug.cgi?id=158143
442
443         Caused 30% regression on Dromaeo DOM core tests (Requested by
444         rniwa on #webkit).
445
446         Reverted changeset:
447
448         "REGRESSION: JSBench spends a lot of time transitioning
449         to/from dictionary"
450         https://bugs.webkit.org/show_bug.cgi?id=158045
451         http://trac.webkit.org/changeset/201436
452
453 2016-05-26  Geoffrey Garen  <ggaren@apple.com>
454
455         REGRESSION: JSBench spends a lot of time transitioning to/from dictionary
456         https://bugs.webkit.org/show_bug.cgi?id=158045
457
458         Reviewed by Saam Barati.
459
460         15% speedup on jsbench-amazon-firefox, possibly 5% speedup overall on jsbench.
461
462         This regression seems to have two parts:
463
464         (1) Transitioning the window object to/from dictionary is more expensive
465         than it used to be to because the window object has lots more properties.
466         The window object has more properties because, for WebIDL compatibility,
467         we reify DOM APIs as properties when you delete.
468
469         (2) DOM prototypes transition to/from dictionary upon creation
470         because, once again for WebIDL compatibility, we reify their static
471         APIs eagerly.
472
473         The solution is to chill out a bit on dictionary transitions.
474
475         * bytecode/ObjectPropertyConditionSet.cpp: Don't flatten a dictionary
476         if we've already done so before. This avoids pathological churn, and it
477         is our idiom in other places.
478
479         * interpreter/Interpreter.cpp:
480         (JSC::Interpreter::execute): Do flatten the global object unconditionally
481         if it is an uncacheable dictionary because the global object is super
482         important.
483
484         * runtime/BatchedTransitionOptimizer.h:
485         (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer):
486         (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): Deleted.
487         Don't transition away from dictionary after a batched set of property
488         puts because normal dictionaries are cacheable and that's a perfectly
489         fine state to be in -- and the transition is expensive.
490
491         * runtime/JSGlobalObject.cpp:
492         (JSC::JSGlobalObject::init): Do start the global object out as a cacheable
493         dictionary because it will inevitably have enough properties to become
494         a dictionary.
495
496         * runtime/Operations.h:
497         (JSC::normalizePrototypeChain): Same as ObjectPropertyConditionSet.cpp.
498
499 2016-05-25  Geoffrey Garen  <ggaren@apple.com>
500
501         replaceable own properties seem to ignore replacement after property caching
502         https://bugs.webkit.org/show_bug.cgi?id=158091
503
504         Reviewed by Darin Adler.
505
506         * runtime/Lookup.h:
507         (JSC::replaceStaticPropertySlot): New helper function for replacing a
508         static property with a direct property. We need to do an attribute changed
509         transition because client code might have cached our static property.
510
511 2016-05-25  Benjamin Poulain  <benjamin@webkit.org>
512
513         [JSC] RegExp with deeply nested subexpressions overflow the stack in Yarr
514         https://bugs.webkit.org/show_bug.cgi?id=158011
515         rdar://problem/25946592
516
517         Reviewed by Saam Barati.
518
519         When generating the meta-data required for compilation,
520         Yarr uses a recursive function over the various expression in the pattern.
521
522         If you have many nested expressions, you can run out of stack
523         and crash the WebProcess.
524         This patch changes that into a soft failure. The expression is just
525         considered invalid.
526
527         * runtime/RegExp.cpp:
528         (JSC::RegExp::finishCreation):
529         (JSC::RegExp::compile):
530         (JSC::RegExp::compileMatchOnly):
531         * yarr/YarrPattern.cpp:
532         (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
533         (JSC::Yarr::YarrPatternConstructor::setupOffsets):
534         (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):
535         (JSC::Yarr::YarrPattern::compile):
536         (JSC::Yarr::YarrPattern::YarrPattern):
537         (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): Deleted.
538         (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): Deleted.
539         * yarr/YarrPattern.h:
540
541 2016-05-25  Alex Christensen  <achristensen@webkit.org>
542
543         Fix Win64 build after r201335
544         https://bugs.webkit.org/show_bug.cgi?id=158078
545
546         Reviewed by Mark Lam.
547
548         * offlineasm/x86.rb:
549         Add intel implementations for loadbs and loadhs
550
551 2016-05-25  Carlos Garcia Campos  <cgarcia@igalia.com>
552
553         REGRESSION(r201066): [GTK] Several intl tests started to fail in GTK+ bot after r201066
554         https://bugs.webkit.org/show_bug.cgi?id=158066
555
556         Reviewed by Darin Adler.
557
558         run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment
559         variables at all when using jsc binary. We are using setlocale() with a nullptr locale to get the current one, but
560         the current one is always "C", because to set the locale according to the environment variables we need to call
561         setlocale with an empty string as locale. That's done by gtk_init(), which is called by all our binaries (web
562         process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has
563         always worked for EFL is because they call ecore_init() in jsc that calls setlocale.
564
565         * jsc.cpp:
566         (main): Call setlocale(LC_ALL, "") on GTK+.
567
568 2016-05-25  Csaba Osztrogonác  <ossy@webkit.org>
569
570         [ARM] Fix the Wcast-align warning in LinkBuffer.cpp
571         https://bugs.webkit.org/show_bug.cgi?id=157889
572
573         Reviewed by Darin Adler.
574
575         * assembler/LinkBuffer.cpp:
576         (JSC::recordLinkOffsets):
577
578 2016-05-24  Keith Miller  <keith_miller@apple.com>
579
580         TypedArray.prototype.slice should not throw if no arguments are provided
581         https://bugs.webkit.org/show_bug.cgi?id=158044
582         <rdar://problem/26433280>
583
584         Reviewed by Geoffrey Garen.
585
586         We were throwing an exception if the TypedArray.prototype.slice function
587         was not provided arguments. This was wrong. Instead we should just assume
588         the first argument was 0.
589
590         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
591         (JSC::genericTypedArrayViewProtoFuncSlice): Deleted.
592         * tests/stress/typedarray-slice.js:
593
594 2016-05-24  Keith Miller  <keith_miller@apple.com>
595
596         LLInt should be able to cache prototype loads for values in GetById
597         https://bugs.webkit.org/show_bug.cgi?id=158032
598
599         Reviewed by Filip Pizlo.
600
601         This patch adds prototype value caching to the LLInt for op_get_by_id.
602         Two previously unused words in the op_get_by_id bytecode have been
603         repurposed to hold extra information for the cache. The first is a
604         counter that records the number of get_by_ids that hit a cacheable value
605         on a prototype. When the counter is decremented from one to zero we
606         attempt to cache the prototype load, which will be discussed further
607         below. The second word is used to hold the prototype object when we have
608         started caching.
609
610         When the counter is decremented to zero we first attempt to generate and
611         watch the property conditions needed to ensure the validity of prototype
612         load. If the watchpoints are successfully created and installed we
613         replace the op_get_by_id opcode with the new op_get_by_id_proto_load
614         opcode, which tells the LLInt to use the cache prototype object for the
615         load rather than the base value.
616
617         Prior to this patch there was not LLInt specific data onCodeBlocks.
618         Since the CodeBlock needs to own the Watchpoints for the cache, a weak
619         map from each base structure to a bag of Watchpoints created for that
620         structure by some op_get_by_id has been added to the CodeBlock. During
621         GC, if we find that the a structure in the map has not been marked we
622         free the associated bag on the CodeBlock.
623
624         * JavaScriptCore.xcodeproj/project.pbxproj:
625         * bytecode/BytecodeList.json:
626         * bytecode/BytecodeUseDef.h:
627         (JSC::computeUsesForBytecodeOffset):
628         (JSC::computeDefsForBytecodeOffset):
629         * bytecode/CodeBlock.cpp:
630         (JSC::CodeBlock::printGetByIdOp):
631         (JSC::CodeBlock::printGetByIdCacheStatus):
632         (JSC::CodeBlock::dumpBytecode):
633         (JSC::CodeBlock::finalizeLLIntInlineCaches):
634         * bytecode/CodeBlock.h:
635         (JSC::CodeBlock::llintGetByIdWatchpointMap):
636         (JSC::clearLLIntGetByIdCache):
637         * bytecode/GetByIdStatus.cpp:
638         (JSC::GetByIdStatus::computeFromLLInt):
639         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: Added.
640         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
641         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::install):
642         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
643         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: Added.
644         * bytecode/ObjectPropertyConditionSet.cpp:
645         (JSC::ObjectPropertyConditionSet::isValidAndWatchable):
646         * bytecode/ObjectPropertyConditionSet.h:
647         * bytecompiler/BytecodeGenerator.cpp:
648         (JSC::BytecodeGenerator::emitGetById):
649         * dfg/DFGByteCodeParser.cpp:
650         (JSC::DFG::ByteCodeParser::parseBlock):
651         * dfg/DFGCapabilities.cpp:
652         (JSC::DFG::capabilityLevel):
653         * jit/JIT.cpp:
654         (JSC::JIT::privateCompileMainPass):
655         (JSC::JIT::privateCompileSlowCases):
656         * llint/LLIntSlowPaths.cpp:
657         (JSC::LLInt::setupGetByIdPrototypeCache):
658         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
659         * llint/LLIntSlowPaths.h:
660         * llint/LowLevelInterpreter32_64.asm:
661         * llint/LowLevelInterpreter64.asm:
662         * runtime/Options.h:
663         * tests/stress/llint-get-by-id-cache-prototype-load-from-dictionary.js: Added.
664         (test):
665
666 2016-05-24  Keith Miller  <keith_miller@apple.com>
667
668         We should be able to use the sampling profiler with DRT/WTR.
669         https://bugs.webkit.org/show_bug.cgi?id=158041
670
671         Reviewed by Saam Barati.
672
673         This patch makes the sampling profiler use a new option, samplingProfilerPath, which
674         specifies the path to a directory to output sampling profiler data when the program
675         terminates or the VM is destroyed. Additionally, it fixes some other issues with the
676         bytecode profiler that would cause crashes on debug builds.
677
678         * profiler/ProfilerDatabase.cpp:
679         (JSC::Profiler::Database::ensureBytecodesFor):
680         (JSC::Profiler::Database::performAtExitSave):
681         * runtime/Options.h:
682         * runtime/SamplingProfiler.cpp:
683         (JSC::SamplingProfiler::registerForReportAtExit):
684         (JSC::SamplingProfiler::reportDataToOptionFile):
685         (JSC::SamplingProfiler::reportTopFunctions):
686         (JSC::SamplingProfiler::reportTopBytecodes):
687         * runtime/SamplingProfiler.h:
688         * runtime/VM.cpp:
689         (JSC::VM::VM):
690         (JSC::VM::~VM):
691
692 2016-05-24  Saam barati  <sbarati@apple.com>
693
694         We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation
695         https://bugs.webkit.org/show_bug.cgi?id=158036
696
697         Reviewed by Geoffrey Garen.
698
699         This patch implements a 1 item cache for JSScope::abstractResolve. I also tried
700         implementing the cache as a HashMap, but it seemed either less profitable on some
701         benchmarks or just as profitable on others. Therefore, it's cleaner to just
702         use a 1 item cache.
703
704         * bytecode/CodeBlock.cpp:
705         (JSC::CodeBlock::CodeBlock):
706         (JSC::AbstractResolveKey::AbstractResolveKey):
707         (JSC::AbstractResolveKey::operator==):
708         (JSC::AbstractResolveKey::isEmptyValue):
709         (JSC::CodeBlock::finishCreation):
710         * runtime/GetPutInfo.h:
711         (JSC::needsVarInjectionChecks):
712         (JSC::ResolveOp::ResolveOp):
713
714 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
715
716         Unreviwed, add a comment to describe the test's failure mode. Suggested by mlam.
717
718         * tests/stress/override-map-constructor.js:
719         (Map):
720
721 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
722
723         Map should not be in JSGlobalObject's static hashtable because it's initialized eagerly via FOR_EACH_SIMPLE_BUILTIN_TYPE_WITH_CONSTRUCTOR
724         https://bugs.webkit.org/show_bug.cgi?id=158031
725         rdar://problem/26353661
726
727         Reviewed by Geoffrey Garen.
728         
729         We were listing Map as being a lazy class structure. It's not. m_mapStructure is a WriteBarrier<>
730         not a LazyClassStructure<> and there is nothing lazy about it.
731
732         * runtime/JSGlobalObject.cpp: The fix is to remove Map here.
733         * runtime/Lookup.cpp: Add some dumping on the assert path.
734         (JSC::setUpStaticFunctionSlot):
735         * tests/stress/override-map-constructor.js: Added. This test used to crash.
736         (Map):
737
738 2016-05-24  Filip Pizlo  <fpizlo@apple.com>
739
740         LLInt64 should have typed array fast paths for get_by_val
741         https://bugs.webkit.org/show_bug.cgi?id=157931
742
743         Reviewed by Keith Miller.
744
745         I think that the LLInt should be able to access typed arrays more quickly than it does now.
746         Ideally we would have fast paths for every major typed array operation and we would use
747         inline cache optimizations. I don't want to do this all in one go, so my plan is to
748         incrementally add support for this as time allows.
749         
750         This change just adds the easy typed array fast paths for get_by_val in the 64-bit version
751         of LLInt.
752         
753         Another bug, https://bugs.webkit.org/show_bug.cgi?id=157922, tracks the overall task of
754         adding all typed array fast paths to both versions of the LLInt.
755         
756         This is a 30% speed-up on typed array benchmarks in LLInt. This is not a speed-up when the
757         JITs are enabled.
758
759         * llint/LLIntData.cpp:
760         (JSC::LLInt::Data::performAssertions):
761         * llint/LLIntOffsetsExtractor.cpp:
762         * llint/LowLevelInterpreter.asm:
763         * llint/LowLevelInterpreter64.asm:
764         * offlineasm/backends.rb:
765         * runtime/JSArrayBufferView.h:
766         * runtime/JSType.h:
767
768 2016-05-24  Saam barati  <sbarati@apple.com> and Yusuke Suzuki <utatane.tea@gmail.com>
769
770         ThisTDZMode is no longer needed
771         https://bugs.webkit.org/show_bug.cgi?id=157209
772
773         Reviewed by Saam Barati.
774
775         ThisTDZMode is no longer needed because we have ConstructorKind
776         and DerivedContextType. The value of ThisTDZMode is strictly less
777         expressive than the combination of those two values. We were
778         using those values anyways, and this patch just makes it official
779         by removing ThisTDZMode.
780
781         This patch also cleans up caching keys. We extract SourceCodeFlags
782         from SourceCodeKey and use it in EvalCodeCache. It correctly
783         contains needed cache attributes: EvalContextType, DerivedContextType,
784         etc. Here, we still use specialized keys for EvalCodeCache instead
785         of SourceCodeKey for performance; it does not include name String and
786         does not allocate SourceCode.
787
788         * bytecode/EvalCodeCache.h:
789         (JSC::EvalCodeCache::CacheKey::CacheKey):
790         (JSC::EvalCodeCache::CacheKey::operator==):
791         (JSC::EvalCodeCache::CacheKey::Hash::equal):
792         (JSC::EvalCodeCache::tryGet):
793         (JSC::EvalCodeCache::getSlow):
794         * bytecompiler/NodesCodegen.cpp:
795         (JSC::ThisNode::emitBytecode): Deleted.
796         * debugger/DebuggerCallFrame.cpp:
797         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
798         * interpreter/Interpreter.cpp:
799         (JSC::eval):
800         * parser/ASTBuilder.h:
801         (JSC::ASTBuilder::createThisExpr):
802         * parser/NodeConstructors.h:
803         (JSC::ThisNode::ThisNode):
804         * parser/Nodes.h:
805         * parser/Parser.cpp:
806         (JSC::Parser<LexerType>::Parser):
807         (JSC::Parser<LexerType>::parsePrimaryExpression):
808         * parser/Parser.h:
809         (JSC::parse):
810         * parser/ParserModes.h:
811         * parser/SourceCodeKey.h:
812         (JSC::SourceCodeFlags::SourceCodeFlags):
813         (JSC::SourceCodeFlags::operator==):
814         (JSC::SourceCodeKey::SourceCodeKey):
815         (JSC::SourceCodeKey::Hash::hash):
816         (JSC::SourceCodeKey::Hash::equal):
817         (JSC::SourceCodeKey::HashTraits::isEmptyValue):
818         (JSC::SourceCodeKeyHash::hash): Deleted.
819         (JSC::SourceCodeKeyHash::equal): Deleted.
820         (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
821         * parser/SyntaxChecker.h:
822         (JSC::SyntaxChecker::createThisExpr):
823         * runtime/CodeCache.cpp:
824         (JSC::CodeCache::getGlobalCodeBlock):
825         (JSC::CodeCache::getProgramCodeBlock):
826         (JSC::CodeCache::getEvalCodeBlock):
827         (JSC::CodeCache::getModuleProgramCodeBlock):
828         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
829         * runtime/CodeCache.h:
830         * runtime/Executable.cpp:
831         (JSC::EvalExecutable::create):
832         * runtime/Executable.h:
833         * runtime/JSGlobalObject.cpp:
834         (JSC::JSGlobalObject::createEvalCodeBlock):
835         * runtime/JSGlobalObject.h:
836         * runtime/JSGlobalObjectFunctions.cpp:
837         (JSC::globalFuncEval):
838         * tests/stress/code-cache-incorrect-caching.js: Added.
839         (shouldBe):
840         (hello):
841         (catch):
842         (shouldBe.test.hello):
843         (globalEval.ok):
844         (global.hello.hello):
845
846 2016-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>
847
848         Assertion failure for Reflect.get with Proxy and primitive value as explicit receiver
849         https://bugs.webkit.org/show_bug.cgi?id=157080
850
851         Reviewed by Saam Barati.
852
853         In custom accessor getter, the argument "thisValue" can be altered by using `Reflect.get`.
854         In this patch, we add a new parameter, "slotBase". This represents the base value offering
855         this custom getter. And use it in ProxyObject's performGet custom accessor getter.
856
857         * API/JSCallbackObject.h:
858         * API/JSCallbackObjectFunctions.h:
859         (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
860         (JSC::JSCallbackObject<Parent>::callbackGetter):
861         * bytecode/PolymorphicAccess.cpp:
862         (JSC::AccessCase::generateImpl):
863         In PolymorphicAccess case, the thisValue and the slotBase are always cells.
864         This is because IC is enabled in the case that the base value is a cell.
865         And slotBase is always on the prototype chain from this base value.
866
867         * jit/CCallHelpers.h:
868         (JSC::CCallHelpers::setupArgumentsWithExecState):
869         * jsc.cpp:
870         (WTF::CustomGetter::customGetter):
871         (WTF::RuntimeArray::lengthGetter):
872         * runtime/CustomGetterSetter.cpp:
873         (JSC::callCustomSetter):
874         * runtime/JSBoundSlotBaseFunction.cpp:
875         (JSC::boundSlotBaseFunctionCall):
876         * runtime/JSFunction.cpp:
877         (JSC::JSFunction::argumentsGetter):
878         (JSC::JSFunction::callerGetter):
879         * runtime/JSFunction.h:
880         * runtime/JSModuleNamespaceObject.cpp:
881         (JSC::callbackGetter):
882         * runtime/PropertySlot.cpp:
883         (JSC::PropertySlot::customGetter):
884         * runtime/PropertySlot.h:
885         * runtime/ProxyObject.cpp:
886         (JSC::performProxyGet):
887         * runtime/RegExpConstructor.cpp:
888         (JSC::regExpConstructorDollar):
889         (JSC::regExpConstructorInput):
890         (JSC::regExpConstructorMultiline):
891         (JSC::regExpConstructorLastMatch):
892         (JSC::regExpConstructorLastParen):
893         (JSC::regExpConstructorLeftContext):
894         (JSC::regExpConstructorRightContext):
895         (JSC::regExpConstructorDollar1): Deleted.
896         (JSC::regExpConstructorDollar2): Deleted.
897         (JSC::regExpConstructorDollar3): Deleted.
898         (JSC::regExpConstructorDollar4): Deleted.
899         (JSC::regExpConstructorDollar5): Deleted.
900         (JSC::regExpConstructorDollar6): Deleted.
901         (JSC::regExpConstructorDollar7): Deleted.
902         (JSC::regExpConstructorDollar8): Deleted.
903         (JSC::regExpConstructorDollar9): Deleted.
904         * tests/stress/proxy-get-with-primitive-receiver.js: Added.
905         (shouldBe):
906
907 2016-05-23  Geoffrey Garen  <ggaren@apple.com>
908
909         REGRESSION (196374): deleting a global property is expensive
910         https://bugs.webkit.org/show_bug.cgi?id=158005
911
912         Reviewed by Chris Dumez.
913
914         * runtime/JSObject.cpp:
915         (JSC::JSObject::deleteProperty): We only need to reify static properties
916         if the name being deleted matches a static property. Otherwise, we can
917         be sure that delete won't observe any static properties.
918
919 2016-05-23  Saam barati  <sbarati@apple.com>
920
921         The baseline JIT crashes when compiling "(1,1)/1"
922         https://bugs.webkit.org/show_bug.cgi?id=157933
923
924         Reviewed by Benjamin Poulain.
925
926         op_div in the baseline JIT needed to better handle when both the lhs
927         and rhs are constants. It needs to make sure to load either the lhs or
928         the rhs into a register since the div generator can't handle both
929         the lhs and rhs being constants.
930
931         * jit/JITArithmetic.cpp:
932         (JSC::JIT::emit_op_div):
933         * tests/stress/jit-gracefully-handle-double-constants-in-math-operators.js: Added.
934         (assert):
935         (test):
936
937 2016-05-23  Saam barati  <sbarati@apple.com>
938
939         String template don't handle let initialization properly inside eval
940         https://bugs.webkit.org/show_bug.cgi?id=157991
941
942         Reviewed by Oliver Hunt.
943
944         The fix is to make sure we emit TDZ checks. 
945
946         * bytecompiler/NodesCodegen.cpp:
947         (JSC::TaggedTemplateNode::emitBytecode):
948         * tests/stress/tagged-template-tdz.js: Added.
949         (shouldThrowTDZ):
950         (test):
951
952 2016-05-22  Saam barati  <sbarati@apple.com>
953
954         Unreviewed. Fixed debug assertion failures from r201235.
955
956         * runtime/JSScope.cpp:
957         (JSC::abstractAccess):
958
959 2016-05-22  Brady Eidson  <beidson@apple.com>
960
961         Attempted Yosemite build fix after http://trac.webkit.org/changeset/201255
962
963         Suggested by and reviewed by Anders Carlsson.
964
965         * b3/B3CCallValue.h: Initialize the effects member more conventionally.
966
967 2016-05-22  Brady Eidson  <beidson@apple.com>
968
969         Move to C++14.
970         https://bugs.webkit.org/show_bug.cgi?id=157948
971
972         Reviewed by Michael Catanzaro.
973
974         * Configurations/Base.xcconfig:
975
976 2016-05-22  Saam barati  <sbarati@apple.com>
977
978         REGRESSION(r199075): String.prototype.replace fails after being used many times with different replace values
979         https://bugs.webkit.org/show_bug.cgi?id=157968
980         <rdar://problem/26404735>
981
982         Reviewed by Ryosuke Niwa and Filip Pizlo.
983
984         There was a bug in the DFG where we were checking a condition
985         on the wrong variable.
986
987         * dfg/DFGStrengthReductionPhase.cpp:
988         (JSC::DFG::StrengthReductionPhase::handleNode):
989
990 2016-05-22  Chris Dumez  <cdumez@apple.com>
991
992         Remove uses of PassRefPtr in JS bindings code
993         https://bugs.webkit.org/show_bug.cgi?id=157949
994
995         Reviewed by Andreas Kling.
996
997         Remove uses of PassRefPtr in JS bindings code.
998
999         * runtime/JSGlobalObject.cpp:
1000         (JSC::JSGlobalObject::queueMicrotask):
1001         * runtime/JSGlobalObject.h:
1002
1003 2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>
1004
1005         Remove LegacyProfiler
1006         https://bugs.webkit.org/show_bug.cgi?id=153565
1007
1008         Reviewed by Mark Lam.
1009
1010         JavaScriptCore now provides a sampling profiler and it is enabled
1011         by all ports. Web Inspector switched months ago to using the
1012         sampling profiler and displaying its data. Remove the legacy
1013         profiler, as it is no longer being used by anything other then
1014         console.profile and tests. We will update console.profile's
1015         behavior soon to have new behavior and use the sampling data.
1016
1017         * API/JSProfilerPrivate.cpp: Removed.
1018         * API/JSProfilerPrivate.h: Removed.
1019         * CMakeLists.txt:
1020         * JavaScriptCore.xcodeproj/project.pbxproj:
1021         * bytecode/BytecodeList.json:
1022         * bytecode/BytecodeUseDef.h:
1023         (JSC::computeUsesForBytecodeOffset): Deleted.
1024         (JSC::computeDefsForBytecodeOffset): Deleted.
1025         * bytecode/CodeBlock.cpp:
1026         (JSC::CodeBlock::dumpBytecode): Deleted.
1027         * bytecode/UnlinkedFunctionExecutable.cpp:
1028         (JSC::generateUnlinkedFunctionCodeBlock):
1029         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1030         * bytecode/UnlinkedFunctionExecutable.h:
1031         * bytecompiler/BytecodeGenerator.cpp:
1032         (JSC::BytecodeGenerator::BytecodeGenerator):
1033         (JSC::BytecodeGenerator::emitCall):
1034         (JSC::BytecodeGenerator::emitCallVarargs):
1035         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
1036         (JSC::BytecodeGenerator::emitConstructVarargs):
1037         (JSC::BytecodeGenerator::emitConstruct):
1038         * bytecompiler/BytecodeGenerator.h:
1039         (JSC::CallArguments::profileHookRegister): Deleted.
1040         (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
1041         * bytecompiler/NodesCodegen.cpp:
1042         (JSC::CallFunctionCallDotNode::emitBytecode):
1043         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1044         (JSC::CallArguments::CallArguments): Deleted.
1045         * dfg/DFGAbstractInterpreterInlines.h:
1046         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
1047         * dfg/DFGByteCodeParser.cpp:
1048         (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
1049         * dfg/DFGCapabilities.cpp:
1050         (JSC::DFG::capabilityLevel): Deleted.
1051         * dfg/DFGClobberize.h:
1052         (JSC::DFG::clobberize): Deleted.
1053         * dfg/DFGDoesGC.cpp:
1054         (JSC::DFG::doesGC): Deleted.
1055         * dfg/DFGFixupPhase.cpp:
1056         (JSC::DFG::FixupPhase::fixupNode): Deleted.
1057         * dfg/DFGNodeType.h:
1058         * dfg/DFGPredictionPropagationPhase.cpp:
1059         * dfg/DFGSafeToExecute.h:
1060         (JSC::DFG::safeToExecute): Deleted.
1061         * dfg/DFGSpeculativeJIT32_64.cpp:
1062         (JSC::DFG::SpeculativeJIT::compile): Deleted.
1063         * dfg/DFGSpeculativeJIT64.cpp:
1064         (JSC::DFG::SpeculativeJIT::compile): Deleted.
1065         * inspector/InjectedScriptBase.cpp:
1066         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
1067         * interpreter/Interpreter.cpp:
1068         (JSC::UnwindFunctor::operator()): Deleted.
1069         (JSC::Interpreter::execute): Deleted.
1070         (JSC::Interpreter::executeCall): Deleted.
1071         (JSC::Interpreter::executeConstruct): Deleted.
1072         * jit/JIT.cpp:
1073         (JSC::JIT::privateCompileMainPass): Deleted.
1074         * jit/JIT.h:
1075         * jit/JITOpcodes.cpp:
1076         (JSC::JIT::emit_op_profile_will_call): Deleted.
1077         (JSC::JIT::emit_op_profile_did_call): Deleted.
1078         * jit/JITOpcodes32_64.cpp:
1079         (JSC::JIT::emit_op_profile_will_call): Deleted.
1080         (JSC::JIT::emit_op_profile_did_call): Deleted.
1081         * jit/JITOperations.cpp:
1082         * jit/JITOperations.h:
1083         * llint/LLIntSlowPaths.cpp:
1084         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
1085         * llint/LLIntSlowPaths.h:
1086         * llint/LowLevelInterpreter.asm:
1087         * parser/ParserModes.h:
1088         * profiler/CallIdentifier.h: Removed.
1089         * profiler/LegacyProfiler.cpp: Removed.
1090         * profiler/LegacyProfiler.h: Removed.
1091         * profiler/Profile.cpp: Removed.
1092         * profiler/Profile.h: Removed.
1093         * profiler/ProfileGenerator.cpp: Removed.
1094         * profiler/ProfileGenerator.h: Removed.
1095         * profiler/ProfileNode.cpp: Removed.
1096         * profiler/ProfileNode.h: Removed.
1097         * profiler/ProfilerJettisonReason.cpp:
1098         (WTF::printInternal): Deleted.
1099         * profiler/ProfilerJettisonReason.h:
1100         * runtime/CodeCache.cpp:
1101         (JSC::CodeCache::getGlobalCodeBlock):
1102         (JSC::CodeCache::getProgramCodeBlock):
1103         (JSC::CodeCache::getEvalCodeBlock):
1104         (JSC::CodeCache::getModuleProgramCodeBlock):
1105         * runtime/CodeCache.h:
1106         * runtime/Executable.cpp:
1107         (JSC::ScriptExecutable::newCodeBlockFor):
1108         * runtime/JSGlobalObject.cpp:
1109         (JSC::JSGlobalObject::createProgramCodeBlock):
1110         (JSC::JSGlobalObject::createEvalCodeBlock):
1111         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
1112         (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
1113         (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
1114         * runtime/JSGlobalObject.h:
1115         * runtime/Options.h:
1116         * runtime/VM.cpp:
1117         (JSC::VM::VM): Deleted.
1118         (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
1119         (JSC::VM::setEnabledProfiler): Deleted.
1120         * runtime/VM.h:
1121         (JSC::VM::enabledProfiler): Deleted.
1122         (JSC::VM::enabledProfilerAddress): Deleted.
1123
1124 2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>
1125
1126         Remove LegacyProfiler
1127         https://bugs.webkit.org/show_bug.cgi?id=153565
1128
1129         Reviewed by Saam Barati.
1130
1131         * inspector/protocol/Timeline.json:
1132         * jsc.cpp:
1133         * runtime/JSGlobalObject.cpp:
1134         (JSC::JSGlobalObject::hasLegacyProfiler):
1135         * runtime/JSGlobalObject.h:
1136         (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
1137
1138 2016-05-20  Saam barati  <sbarati@apple.com>
1139
1140         JSScope::abstractAccess doesn't need to copy the SymbolTableEntry, it can use it by reference
1141         https://bugs.webkit.org/show_bug.cgi?id=157956
1142
1143         Reviewed by Geoffrey Garen.
1144
1145         A SymbolTableEntry may be a FatEntry. Copying a FatEntry is slow because we have to
1146         malloc memory for it, then free the malloced memory once the entry goes out of
1147         scope. abstractAccess uses a SymbolTableEntry temporarily when performing scope
1148         accesses during bytecode linking. It copies out the SymbolTableEntry every time
1149         it does a SymbolTable lookup. This is not cheap when the entry happens to be a
1150         FatEntry. We should really just be using a reference to the entry because
1151         there is no need to copy it in such a scenario.
1152
1153         * runtime/JSScope.cpp:
1154         (JSC::abstractAccess):
1155
1156 2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>
1157
1158         Web Inspector: retained size for typed arrays does not count native backing store
1159         https://bugs.webkit.org/show_bug.cgi?id=157945
1160         <rdar://problem/26392238>
1161
1162         Reviewed by Geoffrey Garen.
1163
1164         * runtime/JSArrayBuffer.h:
1165         * runtime/JSArrayBuffer.cpp:
1166         (JSC::JSArrayBuffer::estimatedSize):
1167         Include an estimatedSize implementation for JSArrayBuffer.
1168         ArrayBuffer has a unique path, different from other data
1169         stored in the Heap.
1170
1171         * tests/heapProfiler/typed-array-sizes.js: Added.
1172         Test sizes of TypedArray with and without an ArrayBuffer.
1173         When the TypedArray is a view wrapping an ArrayBuffer, the
1174         ArrayBuffer has the size.
1175
1176 2016-05-20  Geoffrey Garen  <ggaren@apple.com>
1177
1178         reifyAllStaticProperties makes two copies of every string
1179         https://bugs.webkit.org/show_bug.cgi?id=157953
1180
1181         Reviewed by Mark Lam.
1182
1183         Let's not do that.
1184
1185         * runtime/JSObject.cpp:
1186         (JSC::JSObject::reifyAllStaticProperties): Pass our Identifier to
1187         reifyStaticProperty so it doesn't have to make its own.
1188
1189         * runtime/Lookup.h:
1190         (JSC::reifyStaticProperty): No need to null check because callers never
1191         pass null anymore. No need to make an identifier because callers pass
1192         us one.
1193
1194         (JSC::reifyStaticProperties): Honor new interface.
1195
1196 2016-05-20  Geoffrey Garen  <ggaren@apple.com>
1197
1198         JSBench regression: CodeBlock linking always copies the symbol table
1199         https://bugs.webkit.org/show_bug.cgi?id=157951
1200
1201         Reviewed by Saam Barati.
1202
1203         We always put a SymbolTable into the constant pool, even in simple
1204         functions in which it won't be used -- i.e., there's on eval and there
1205         are no captured variables and so on.
1206
1207         This is costly because linking must copy any provided symbol tables.
1208
1209         * bytecompiler/BytecodeGenerator.cpp:
1210         (JSC::BytecodeGenerator::BytecodeGenerator):
1211         (JSC::BytecodeGenerator::emitProfileType): Only add the symbol table
1212         as a constant if we will use it at runtime.
1213
1214 2016-05-19  Benjamin Poulain  <bpoulain@apple.com>
1215
1216         [JSC] Improve int->float conversion in FTL
1217         https://bugs.webkit.org/show_bug.cgi?id=157936
1218
1219         Reviewed by Filip Pizlo.
1220
1221         The integer -> floating point lowering was very barebone.
1222
1223         For example, converting a constant integer to double
1224         was doing:
1225             mov #const, %eax
1226             xor %xmm0, %xmm0
1227             cvtsi2sd %eax, %xmm0
1228
1229         Conversion from integer to float was also missing.
1230         We were always converting to double then rounding the double
1231         to float.
1232
1233         This patch adds the basics:
1234         -Constant folding.
1235         -Integer to Float opcode.
1236         -Reducing int->double to int->float when used by DoubleToFloat.
1237
1238         * assembler/MacroAssemblerX86Common.h:
1239         (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
1240         * assembler/MacroAssemblerX86_64.h:
1241         (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
1242         (JSC::MacroAssemblerX86_64::convertInt64ToFloat):
1243         * assembler/X86Assembler.h:
1244         (JSC::X86Assembler::cvtsi2ss_rr):
1245         (JSC::X86Assembler::cvtsi2ssq_rr):
1246         (JSC::X86Assembler::cvtsi2sdq_mr):
1247         (JSC::X86Assembler::cvtsi2ssq_mr):
1248         (JSC::X86Assembler::cvtsi2ss_mr):
1249         * assembler/MacroAssemblerARM64.h:
1250         * b3/B3Const32Value.cpp:
1251         (JSC::B3::Const32Value::iToDConstant):
1252         (JSC::B3::Const32Value::iToFConstant):
1253         * b3/B3Const32Value.h:
1254         * b3/B3Const64Value.cpp:
1255         (JSC::B3::Const64Value::iToDConstant):
1256         (JSC::B3::Const64Value::iToFConstant):
1257         * b3/B3Const64Value.h:
1258         * b3/B3LowerToAir.cpp:
1259         (JSC::B3::Air::LowerToAir::lower):
1260         * b3/B3Opcode.cpp:
1261         (WTF::printInternal):
1262         * b3/B3Opcode.h:
1263         * b3/B3ReduceDoubleToFloat.cpp:
1264         * b3/B3ReduceStrength.cpp:
1265         * b3/B3Validate.cpp:
1266         * b3/B3Value.cpp:
1267         (JSC::B3::Value::iToDConstant):
1268         (JSC::B3::Value::iToFConstant):
1269         (JSC::B3::Value::isRounded):
1270         (JSC::B3::Value::effects):
1271         (JSC::B3::Value::key):
1272         (JSC::B3::Value::typeFor):
1273         * b3/B3Value.h:
1274         * b3/B3ValueKey.cpp:
1275         (JSC::B3::ValueKey::materialize):
1276         * b3/air/AirFixPartialRegisterStalls.cpp:
1277         * b3/air/AirOpcode.opcodes:
1278         * b3/testb3.cpp:
1279         (JSC::B3::int64Operands):
1280         (JSC::B3::testIToD64Arg):
1281         (JSC::B3::testIToF64Arg):
1282         (JSC::B3::testIToD32Arg):
1283         (JSC::B3::testIToF32Arg):
1284         (JSC::B3::testIToD64Mem):
1285         (JSC::B3::testIToF64Mem):
1286         (JSC::B3::testIToD32Mem):
1287         (JSC::B3::testIToF32Mem):
1288         (JSC::B3::testIToD64Imm):
1289         (JSC::B3::testIToF64Imm):
1290         (JSC::B3::testIToD32Imm):
1291         (JSC::B3::testIToF32Imm):
1292         (JSC::B3::testIToDReducedToIToF64Arg):
1293         (JSC::B3::testIToDReducedToIToF32Arg):
1294         (JSC::B3::run):
1295
1296 2016-05-19  Benjamin Poulain  <bpoulain@apple.com>
1297
1298         [JSC] FTL can crash on stack overflow
1299         https://bugs.webkit.org/show_bug.cgi?id=157881
1300         rdar://problem/24665964
1301
1302         Reviewed by Michael Saboff.
1303
1304         The VM's m_largestFTLStackSize was never set anywhere (updateFTLLargestStackSize()
1305         was never called). We forgot to change that when implementing B3.
1306
1307         Even when it is set, we still have a problem on OSR Exit.
1308         If the last frame is a FTL frame and it OSR Exits, the space required for
1309         that frame becomes significantly larger. What happens is we crash in the OSR Exit
1310         instead of the FTL frame (this is what happens in rdar://problem/24665964).
1311
1312         This patch changes the stack boundary checks in FTL to be the same as DFG:
1313         we verify that we have enough space for the current optimized function but
1314         also for the baseline version (including inlining) in case of exit.
1315
1316         * ftl/FTLLowerDFGToB3.cpp:
1317         (JSC::FTL::DFG::LowerDFGToB3::lower):
1318         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): Deleted.
1319         * runtime/VM.cpp:
1320         (JSC::VM::VM): Deleted.
1321         (JSC::VM::updateStackLimit): Deleted.
1322         (JSC::VM::updateFTLLargestStackSize): Deleted.
1323         * runtime/VM.h:
1324         (JSC::VM::addressOfFTLStackLimit): Deleted.
1325
1326 2016-05-18  Filip Pizlo  <fpizlo@apple.com>
1327
1328         DFG::LICMPhase shouldn't hoist type checks unless it knows that the check will succeed at the loop pre-header
1329         https://bugs.webkit.org/show_bug.cgi?id=144527
1330
1331         Reviewed by Saam Barati.
1332         
1333         This adds a control flow equivalence analysis (called ControlEquivalenceAnalysis) based on
1334         dominator analysis over the backwards CFG. Two basic blocks are control flow equivalent if
1335         the execution of one implies that the other one must also execute. It means that the two
1336         blocks' forward and backward dominance are reciprocated: (A dom B and B backdom A) or (B dom
1337         A and A backdom B). LICM now uses it to become more conservative about hoisting checks, if
1338         this has caused problems in the past. If we hoist something that may exit from a block that
1339         was not control equivalent to the pre-header then it's possible that the node's speculation
1340         will fail even though it wouldn't have if it wasn't hoisted. So, we flag these nodes'
1341         origins as being "wasHoisted" and we track all of their exits as "HoistingFailed". LICM will
1342         turn off such speculative hoisting if the CodeBlock from which we are hoisting had the
1343         HoistingFailed exit kind.
1344         
1345         Note that this deliberately still allows us to hoist things that may exit even if they are
1346         not control equivalent to the pre-header. This is necessary because the profitability of
1347         hoisting is so huge in all of the cases that we're aware of that it's worth giving it a
1348         shot.
1349         
1350         This is neutral on macrobenchmarks since none of the benchmarks we track have a hoistable
1351         operation that would exit only if hoisted. I added microbenchmarks to illustrate the problem
1352         and two of them speed up by ~40% while one of them is neutral (Int52 saves us from having
1353         problems on that program even though LICM previously did the wrong thing).
1354
1355         * JavaScriptCore.xcodeproj/project.pbxproj:
1356         * bytecode/ExitKind.cpp:
1357         (JSC::exitKindToString):
1358         * bytecode/ExitKind.h:
1359         * dfg/DFGAtTailAbstractState.h:
1360         (JSC::DFG::AtTailAbstractState::operator bool):
1361         (JSC::DFG::AtTailAbstractState::initializeTo):
1362         * dfg/DFGBackwardsCFG.h: Added.
1363         (JSC::DFG::BackwardsCFG::BackwardsCFG):
1364         * dfg/DFGBackwardsDominators.h: Added.
1365         (JSC::DFG::BackwardsDominators::BackwardsDominators):
1366         * dfg/DFGCommon.h:
1367         (JSC::DFG::checkAndSet): Deleted.
1368         * dfg/DFGControlEquivalenceAnalysis.h: Added.
1369         (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis):
1370         (JSC::DFG::ControlEquivalenceAnalysis::dominatesEquivalently):
1371         (JSC::DFG::ControlEquivalenceAnalysis::areEquivalent):
1372         * dfg/DFGGraph.cpp:
1373         (JSC::DFG::Graph::dump):
1374         (JSC::DFG::Graph::dumpBlockHeader):
1375         (JSC::DFG::Graph::invalidateCFG):
1376         (JSC::DFG::Graph::substituteGetLocal):
1377         (JSC::DFG::Graph::handleAssertionFailure):
1378         (JSC::DFG::Graph::ensureDominators):
1379         (JSC::DFG::Graph::ensurePrePostNumbering):
1380         (JSC::DFG::Graph::ensureNaturalLoops):
1381         (JSC::DFG::Graph::ensureBackwardsCFG):
1382         (JSC::DFG::Graph::ensureBackwardsDominators):
1383         (JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
1384         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1385         * dfg/DFGGraph.h:
1386         (JSC::DFG::Graph::hasDebuggerEnabled):
1387         * dfg/DFGInPlaceAbstractState.h:
1388         (JSC::DFG::InPlaceAbstractState::operator bool):
1389         (JSC::DFG::InPlaceAbstractState::createValueForNode):
1390         (JSC::DFG::InPlaceAbstractState::forNode):
1391         * dfg/DFGLICMPhase.cpp:
1392         (JSC::DFG::LICMPhase::run):
1393         (JSC::DFG::LICMPhase::attemptHoist):
1394         * dfg/DFGMayExit.cpp:
1395         (JSC::DFG::mayExit):
1396         * dfg/DFGMayExit.h:
1397         * dfg/DFGNode.h:
1398         * dfg/DFGNodeOrigin.cpp:
1399         (JSC::DFG::NodeOrigin::dump):
1400         * dfg/DFGNodeOrigin.h:
1401         (JSC::DFG::NodeOrigin::takeValidExit):
1402         (JSC::DFG::NodeOrigin::withWasHoisted):
1403         (JSC::DFG::NodeOrigin::forInsertingAfter):
1404         * dfg/DFGNullAbstractState.h: Added.
1405         (JSC::DFG::NullAbstractState::NullAbstractState):
1406         (JSC::DFG::NullAbstractState::operator bool):
1407         (JSC::DFG::NullAbstractState::forNode):
1408         * dfg/DFGOSRExit.cpp:
1409         (JSC::DFG::OSRExit::OSRExit):
1410         * dfg/DFGOSRExitBase.cpp:
1411         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
1412         * dfg/DFGOSRExitBase.h:
1413         (JSC::DFG::OSRExitBase::OSRExitBase):
1414         * dfg/DFGTypeCheckHoistingPhase.cpp:
1415         (JSC::DFG::TypeCheckHoistingPhase::run):
1416         * ftl/FTLOSRExit.cpp:
1417         (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
1418         (JSC::FTL::OSRExit::OSRExit):
1419         * ftl/FTLOSRExit.h:
1420
1421 2016-05-19  Mark Lam  <mark.lam@apple.com>
1422
1423         Code that null checks the VM pointer before any use should ref the VM.
1424         https://bugs.webkit.org/show_bug.cgi?id=157864
1425
1426         Reviewed by Filip Pizlo and Keith Miller.
1427
1428         JSLock::willReleaseLock() and HeapTimer::timerDidFire() need to reference the VM
1429         through a RefPtr.  Otherwise, there's no guarantee that the VM won't be deleted
1430         after their null checks.
1431
1432         * bytecode/CodeBlock.h:
1433         (JSC::CodeBlock::vm):
1434         (JSC::CodeBlock::setVM): Deleted.
1435         - Not used, and suggests that it can be changed during the lifetime of the
1436           CodeBlock (which should not be).
1437
1438         * heap/HeapTimer.cpp:
1439         (JSC::HeapTimer::timerDidFire):
1440         * runtime/JSLock.cpp:
1441         (JSC::JSLock::willReleaseLock):
1442         - Store the VM pointer in a RefPtr first, and null check the RefPtr instead of
1443           the raw VM pointer.  This makes the null check a strong guarantee that the
1444           VM pointer is valid while these functions are using it.
1445
1446 2016-05-19  Saam barati  <sbarati@apple.com>
1447
1448         arrow function lexical environment should reuse the same environment as the function's lexical environment where possible
1449         https://bugs.webkit.org/show_bug.cgi?id=157908
1450
1451         Reviewed by Filip Pizlo.
1452
1453         We can safely combine these two environment when we have
1454         a simple parameter list (no default parameters, no destructring parameters).
1455
1456         * bytecompiler/BytecodeGenerator.cpp:
1457         (JSC::BytecodeGenerator::BytecodeGenerator):
1458         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
1459         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1460         * bytecompiler/BytecodeGenerator.h:
1461
1462 2016-05-19  Michael Saboff  <msaboff@apple.com>
1463
1464         Unreviewed build fix.
1465
1466         Skipping this new test as it times out on the bots.
1467
1468         Issue tracked in https://bugs.webkit.org/show_bug.cgi?id=157903
1469
1470         * tests/stress/regress-157595.js:
1471         (MyRegExp):
1472
1473 2016-05-19  Guillaume Emont  <guijemont@igalia.com>
1474
1475         JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis
1476         https://bugs.webkit.org/show_bug.cgi?id=157741
1477
1478         Reviewed by Saam Barati.
1479
1480         The PutByValWithThis case needs a special case for MIPS because we
1481         don't have enough registers. The special case needs to be different
1482         from the x86 one because we have a different ABI.
1483
1484         * dfg/DFGSpeculativeJIT32_64.cpp:
1485         (JSC::DFG::SpeculativeJIT::compile):
1486
1487 2016-05-19  Brian Burg  <bburg@apple.com>
1488
1489         Web Inspector: use a consistent prefix for injected scripts
1490         https://bugs.webkit.org/show_bug.cgi?id=157715
1491         <rdar://problem/26287188>
1492
1493         Reviewed by Timothy Hatcher.
1494
1495         * CMakeLists.txt:
1496         * DerivedSources.make:
1497         * inspector/InjectedScriptSource.js:
1498
1499 2016-05-19  Csaba Osztrogonác  <ossy@webkit.org>
1500
1501         [ARM] Remove redefined macro after r200606
1502         https://bugs.webkit.org/show_bug.cgi?id=157890
1503
1504         Reviewed by Michael Saboff.
1505
1506         * bytecode/PolymorphicAccess.cpp:
1507         * jit/CCallHelpers.h:
1508
1509 2016-05-18  Saam barati  <sbarati@apple.com>
1510
1511         Function with default parameter values that are arrow functions that capture this isn't working
1512         https://bugs.webkit.org/show_bug.cgi?id=157786
1513         <rdar://problem/26327329>
1514
1515         Reviewed by Geoffrey Garen.
1516
1517         To make the scopes ordered properly, I needed to initialize the arrow 
1518         function lexical environment before initializing default parameter values.
1519         I also made the code easier to reason about by never reusing the function's
1520         var lexical environment for the arrow function lexical environment. The
1521         reason for this is that that code was wrong, and we just didn't have code to
1522         that properly tested it. It was easy for that code to be wrong because
1523         sometimes the function's lexical environment isn't the top-most scope
1524         (namely, when a function's parameter list is non-simple) and sometimes
1525         it is (when the function's parameter list is simple).
1526
1527         Also, because a function's default parameter values may capture the
1528         'arguments' variable inside an arrow function, I needed to take care
1529         to initialize the 'arguments' variable as part of whichever scope
1530         is the top-most scope. It's either the function's var environment
1531         if the parameter list is simple, or it's the function's parameter
1532         environment if the parameter list is non-simple.
1533
1534         * bytecompiler/BytecodeGenerator.cpp:
1535         (JSC::BytecodeGenerator::BytecodeGenerator):
1536         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
1537         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1538         (JSC::BytecodeGenerator::initializeParameters):
1539         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
1540         (JSC::BytecodeGenerator::visibleNameForParameter):
1541         * bytecompiler/BytecodeGenerator.h:
1542         * tests/stress/arrow-functions-as-default-parameter-values.js: Added.
1543         (assert):
1544         (test):
1545         (test.foo):
1546         * tests/stress/op-push-name-scope-crashes-profiler.js:
1547         (test):
1548
1549 2016-05-18  Michael Saboff  <msaboff@apple.com>
1550
1551         r199812 broke test262
1552         https://bugs.webkit.org/show_bug.cgi?id=157595
1553
1554         Reviewed by Filip Pizlo.
1555
1556         Added a reasonable limit to the size of the match result array to catch possible
1557         infinite loops when matching.
1558         Added a new tests that creates an infinite loop in RegExp.prototype.[Symbol.match]
1559         by creating a subclass of RegExp where the base RegExp's global flag is false and
1560         the subclass overrides .global with a getter that always returns true.
1561
1562         * builtins/RegExpPrototype.js:
1563         (match):
1564         * tests/stress/regress-157595.js: Added.
1565         (MyRegExp):
1566         (MyRegExp.prototype.get global):
1567         (test):
1568         (catch):
1569
1570 2016-05-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1571
1572         [ES6] Namespace object re-export should be handled as local export
1573         https://bugs.webkit.org/show_bug.cgi?id=157806
1574
1575         Reviewed by Mark Lam.
1576
1577         We align the implementation of ExportEntry to the spec; remove Type::Namespace.
1578         This Type::Namespace is used for re-exported namespace object binding. For example,
1579
1580             import * as namespace from "namespace.js"
1581             export { namespace }
1582
1583         In the above case, we used ExportEntry(Type::Namespace). In this patch, we drop this
1584         and use normal local export (Type::Local) instead because namespace object actually has
1585         the local binding in the above module environment. And this handling strictly meets the
1586         spec (Sec 15.2.1.16.1 step 11-a-ii-2-b).
1587
1588         And we also clean up the ExportEntry implementation; dropping unnecessary information.
1589         This change fixes the test262/test/language/module-code/instn-star-equality.js crash.
1590
1591         * parser/ModuleAnalyzer.cpp:
1592         (JSC::ModuleAnalyzer::exportVariable):
1593         * runtime/JSModuleRecord.cpp:
1594         (JSC::getExportedNames):
1595         (JSC::JSModuleRecord::dump): Deleted.
1596         * runtime/JSModuleRecord.h:
1597         * tests/modules/namespace-re-export.js: Added.
1598         * tests/modules/namespace-re-export/namespace-re-export-fixture.js: Added.
1599         * tests/modules/namespace-re-export/namespace-re-export.js: Added.
1600         * tests/modules/resources/assert.js:
1601         (export.shouldNotBe):
1602
1603 2016-05-17  Filip Pizlo  <fpizlo@apple.com>
1604
1605         JSC should detect the right default locale even when it's not embedded in WebCore
1606         https://bugs.webkit.org/show_bug.cgi?id=157755
1607         rdar://problem/24665424
1608
1609         Reviewed by Keith Miller.
1610         
1611         This makes JSC try to use WTF's platform user preferred language detection if the DOM did
1612         not register a defaultLanguage callback. The result is that when JSC runs standalone it
1613         will detect the platform user preferred language almost the same way as when it's embedded
1614         in WebCore. The only difference is that WebCore may have its own additional overrides via
1615         the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls
1616         back to.
1617         
1618         We first found this bug because on iOS, the intl tests would fail because ICU would report
1619         a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall
1620         back to ICU's locale detection. It turns out that the ICU default locale is also bogus on
1621         OS X, just less so. For example, setting things to Poland did not result in the jsc shell
1622         printing dates Polish-style. Now it will print them Polish-style if your system preferences
1623         say so. Also, the tests don't fail on iOS anymore.
1624         
1625         * runtime/IntlObject.cpp:
1626         (JSC::defaultLocale):
1627
1628 2016-05-17  Dean Jackson  <dino@apple.com>
1629
1630         Remove ES6_GENERATORS flag
1631         https://bugs.webkit.org/show_bug.cgi?id=157815
1632         <rdar://problem/26332894>
1633
1634         Reviewed by Geoffrey Garen.
1635
1636         This flag isn't needed. Generators are enabled everywhere and
1637         part of a stable specification.
1638
1639         * Configurations/FeatureDefines.xcconfig:
1640         * parser/Parser.cpp:
1641         (JSC::Parser<LexerType>::parseFunctionDeclaration): Deleted.
1642         (JSC::Parser<LexerType>::parseClass): Deleted.
1643         (JSC::Parser<LexerType>::parseExportDeclaration): Deleted.
1644         (JSC::Parser<LexerType>::parseAssignmentExpression): Deleted.
1645         (JSC::Parser<LexerType>::parseProperty): Deleted.
1646         (JSC::Parser<LexerType>::parseFunctionExpression): Deleted.
1647
1648 2016-05-17  Keith Miller  <keith_miller@apple.com>
1649
1650         Rollout r200426 since it causes PLT regressions.
1651         https://bugs.webkit.org/show_bug.cgi?id=157812
1652
1653         Unreviewed rollout of r200426 since the bots see a ~.6% PLT regression from the patch.
1654
1655 2016-05-17  Keith Miller  <keith_miller@apple.com>
1656
1657         Add test262 harness support code
1658         https://bugs.webkit.org/show_bug.cgi?id=157797
1659
1660         Reviewed by Filip Pizlo.
1661
1662         This patch adds some new tooling needed to run Test262 with the jsc
1663         CLI. There were three options that needed to be added for Test262:
1664
1665         1) "--test262-async" This option overrides the print function in the test runner to look for
1666         'Test262:AsyncTestComplete' instead of printing the passed text. If test262-async mode is on
1667         and that string is not passed then the test is marked as failing.
1668
1669         2) "--strict-file=<file>" This option appends `"use strict";\n` to the beginning of the
1670         passed file before passing the source code to the VM. This option can, in theory, be passed
1671         multiple times.
1672
1673         3) "--exception=<name>" This option asserts that at the end of the last script file passed
1674         the VM has an uncaught exception with its name property equal to the passed name.
1675
1676         * jsc.cpp:
1677         (Script::Script):
1678         (fillBufferWithContentsOfFile):
1679         (functionPrint):
1680         (checkUncaughtException):
1681         (runWithScripts):
1682         (printUsageStatement):
1683         (CommandLine::parseArguments):
1684         (runJSC):
1685
1686 2016-05-17  Filip Pizlo  <fpizlo@apple.com>
1687
1688         WTF should know about Language
1689         https://bugs.webkit.org/show_bug.cgi?id=157756
1690
1691         Reviewed by Geoffrey Garen.
1692
1693         Teach our scripts that a ObjC class beginning with WTF is totally cool.
1694
1695         * JavaScriptCore.xcodeproj/project.pbxproj:
1696
1697 2016-05-17  Joseph Pecoraro  <pecoraro@apple.com>
1698
1699         console namespace breaks putting properties on console.__proto__
1700         https://bugs.webkit.org/show_bug.cgi?id=157782
1701         <rdar://problem/26250526>
1702
1703         Reviewed by Geoffrey Garen.
1704
1705         Some websites currently depend on console.__proto__ existing and being
1706         a separate object from Object.prototype. This patch adds back a basic
1707         console.__proto__ object, but all the console functions are left on
1708         the ConsoleObject itself.
1709
1710         * runtime/JSGlobalObject.cpp:
1711         (JSC::createConsoleProperty):
1712
1713 2016-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1714
1715         Unreviewed, dump more information when math-pow-stable-results.js failed
1716         https://bugs.webkit.org/show_bug.cgi?id=157168
1717
1718         * tests/stress/math-pow-stable-results.js:
1719
1720 2016-05-16  Saam barati  <sbarati@apple.com>
1721
1722         ShadowChicken crashes when reading a scope from the frame during a stack overflow exception
1723         https://bugs.webkit.org/show_bug.cgi?id=157770
1724
1725         Reviewed by Filip Pizlo.
1726
1727         ShadowChicken was reading the scope from a half formed
1728         frame as it threw a stack overflow exception. The frame had
1729         a valid CodeBlock pointer, but it did not have a valid scope.
1730         The code in ShadowChicken's throw packet logging mechanism didn't
1731         account for this. The fix is to respect whether genericUnwind wants
1732         to unwind from the current frame or the caller's frame. For stack
1733         overflow errors, we always unwind the caller's frame.
1734
1735         * jit/JITExceptions.cpp:
1736         (JSC::genericUnwind):
1737
1738 2016-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1739
1740         REGRESSION(r200208): It made 2 JSC stress tests fail on x86
1741         https://bugs.webkit.org/show_bug.cgi?id=157168
1742
1743         Reviewed by Benjamin Poulain.
1744
1745         The fast path in operationMathPow produces different results between x87 and the other environments.
1746         This is because x87 calculates the double value in 80bit precision.
1747         The situation is the following: in x86 32bit environment, floating point operations are compiled to
1748         x87 operations by default even if we can use SSE2. But in DFG environment, we aggressively use SSE2
1749         if the cpuid reports SSE2 is available. As a result, the implementations differ between C runtime
1750         and DFG JIT code. The C runtime uses x87 while DFG JIT code uses SSE2. This causes a precision
1751         problem since x87 has 80bit precision while SSE2 has 64bit precision.
1752
1753         In this patch, in x86 32bit environment, we use `volatile double` if the `-mfpmath=sse and -msse2 (or later)`
1754         is not specified. This will round the x87 value into 64bit per multiplying. Note that this problem does not
1755         occur in OS X clang 32bit environment. This is because `-mfpmath=sse` is enabled by default in OS X clang 32bit.
1756
1757         * b3/B3MathExtras.cpp:
1758         (JSC::B3::powDoubleInt32):
1759         * runtime/MathCommon.cpp:
1760         (JSC::operationMathPow):
1761
1762 2016-05-16  Benjamin Poulain  <bpoulain@apple.com>
1763
1764         [JSC] "return this" in a constructor does not need a branch on isObject(this)
1765         https://bugs.webkit.org/show_bug.cgi?id=157775
1766
1767         Reviewed by Saam Barati and Ryosuke Niwa.
1768
1769         When returning "this" in a constructor, the bytecode generator was generating:
1770             is_object         locX, this
1771             jtrue             locX, 5(->second ret)
1772             ret               this
1773             ret               this
1774
1775         That code is eliminated in DFG but it is pretty costly lower tiers.
1776
1777         This patch changes bytecode generation to avoid the is_object test
1778         when possible and not generate two ret if they encode the same thing.
1779
1780         * bytecompiler/BytecodeGenerator.cpp:
1781         (JSC::BytecodeGenerator::emitReturn):
1782
1783 2016-05-16  Benjamin Poulain  <bpoulain@apple.com>
1784
1785         [JSC] Remove the index check from op_get_by_val/op_put_by_val when the index is constant
1786         https://bugs.webkit.org/show_bug.cgi?id=157766
1787
1788         Reviewed by Geoffrey Garen.
1789
1790         If the index is an integer constant, do not generate the index check.
1791
1792         * jit/JITPropertyAccess.cpp:
1793         (JSC::JIT::emit_op_get_by_val):
1794         (JSC::JIT::emitSlow_op_get_by_val):
1795         (JSC::JIT::emit_op_put_by_val):
1796         (JSC::JIT::emitSlow_op_put_by_val):
1797
1798 2016-05-16  Benjamin Poulain  <bpoulain@apple.com>
1799
1800         [JSC][DFG] Fill spilled Int32 as Int32 instead of JSInt32
1801         https://bugs.webkit.org/show_bug.cgi?id=157700
1802
1803         Reviewed by Michael Saboff.
1804
1805         In general, fillSpeculateInt32() originate from SpeculateInt32
1806         and the user does not care about the tag.
1807
1808         This is particularily obvious on Sunspider's math-spectral-norm.js.
1809         In that test, registers are frequently spilled because of x86's DIV.
1810
1811         When they are re-filled, they were always tagged.
1812         Since the loops are small, all the tagging adds up.
1813
1814         * dfg/DFGSpeculativeJIT64.cpp:
1815         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
1816
1817 2016-05-16  Saam barati  <sbarati@apple.com>
1818
1819         Unreviewed Cloop build fix.
1820
1821         * bytecode/CodeBlock.cpp:
1822         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
1823
1824 2016-05-16  Saam barati  <sbarati@apple.com>
1825
1826         Hook up ShadowChicken to the debugger to show tail deleted frames
1827         https://bugs.webkit.org/show_bug.cgi?id=156685
1828         <rdar://problem/25770521>
1829
1830         Reviewed by Filip Pizlo and Mark Lam and Joseph Pecoraro.
1831
1832         The heart of this patch hooks up ShadowChicken to DebuggerCallFrame to
1833         allow the Web Inspector to display the ShadowChicken's shadow stack.
1834         This means the Web Inspector can now display tail deleted frames.
1835         To make this work, I made the necessary changes to ShadowChicken and
1836         DebuggerCallFrame to allow DebuggerCallFrame to keep the same API
1837         when representing both machine frames and tail deleted frames.
1838
1839         - ShadowChicken prologue packets now log the current scope. Tail packets
1840           log the current scope, the 'this' value, the CodeBlock, and the
1841           CallSiteIndex. This allows the inspector to not only show the
1842           tail deleted frame, but also show exactly where the tail call happened (line and column numbers),
1843           with which scope it executed, and with which 'this' value. This
1844           patch also allows DebuggerCallFrame to execute console statements
1845           in a tail deleted frame.
1846
1847         - I changed ShadowChicken's stack resizing algorithm. ShadowChicken
1848           now only keeps a maximum number of tail deleted frames in its shadow stack.
1849           It will happily represent all machine frames without limit. Right now, the
1850           maximum number of tail deleted frames I chose to keep alive is 128.
1851           We will keep frames alive starting from the top of the stack. This
1852           allows us to have a strong defense against runaway memory usage. We will only
1853           keep around at most 128 "shadow" frames that wouldn't have naturally been kept
1854           alive by the executing program. We can play around with this number
1855           if we find that 128 is either too many or too few frames.
1856
1857         - DebuggerCallFrame is no longer a cheap class to create. When it is created,
1858           we will eagerly create the entire virtual debugger stack. So I modified the
1859           existing code to lazily create DebuggerCallFrames only when necessary. We
1860           used to eagerly create them at each op_debug statement even though we would
1861           just throw them away if we didn't hit a breakpoint.
1862
1863         - A valid DebuggerCallFrame will always have a valid CallFrame* pointer
1864           into the stack. This pointer won't always refer to the logical frame
1865           that the DebuggerCallFrame represents because a DebuggerCallFrame can
1866           now represent a tail deleted frame. To do this, DebuggerCallFrame now
1867           has a ShadowChicken::Frame member variable. This allows DebuggerCallFrame
1868           to know when it represents a tail deleted frame and gives DebuggerCallFrame
1869           a mechanism to ask the tail deleted frame for interesting information
1870           (like its 'this' value, scope, CodeBlock, etc). A tail deleted frame's
1871           machine frame pointer will be the machine caller of the tail deleted frame
1872           (or the machine caller of the first of a series of consecutive tail calls).
1873
1874         - I added a new flag to UnlinkedCodeBlock to indicate when it is compiled
1875           with debugging opcodes. I did this because ShadowChicken may read a JSScope
1876           from the machine stack. This is only safe if the machine CodeBlock was
1877           compiled with debugging opcodes. This is safer than asking if the
1878           CodeBlock's global object has an interactive debugger enabled because
1879           it's theoretically possible for the debugger to be enabled while code
1880           compiled without a debugger is still live on the stack. This field is
1881           also now used to indicate to the DFGGraph that the interactive debugger
1882           is enabled.
1883
1884         - Finally, this patch adds a new field to the Inspector's CallFrame protocol
1885           object called 'isTailDeleted' to allow the Inspector to know when a
1886           CallFrame represents a tail deleted frame.
1887
1888         * JavaScriptCore.xcodeproj/project.pbxproj:
1889         * bytecode/BytecodeList.json:
1890         * bytecode/BytecodeUseDef.h:
1891         (JSC::computeUsesForBytecodeOffset):
1892         * bytecode/CodeBlock.cpp:
1893         (JSC::CodeBlock::dumpBytecode):
1894         (JSC::CodeBlock::findPC):
1895         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
1896         * bytecode/CodeBlock.h:
1897         (JSC::CodeBlock::clearDebuggerRequests):
1898         (JSC::CodeBlock::wasCompiledWithDebuggingOpcodes):
1899         * bytecode/UnlinkedCodeBlock.cpp:
1900         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1901         * bytecode/UnlinkedCodeBlock.h:
1902         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes):
1903         (JSC::UnlinkedCodeBlock::finishCreation):
1904         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
1905         * bytecode/UnlinkedFunctionExecutable.cpp:
1906         (JSC::generateUnlinkedFunctionCodeBlock):
1907         * bytecompiler/BytecodeGenerator.cpp:
1908         (JSC::BytecodeGenerator::generate):
1909         (JSC::BytecodeGenerator::BytecodeGenerator):
1910         (JSC::BytecodeGenerator::emitEnter):
1911         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
1912         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
1913         (JSC::BytecodeGenerator::emitCallDefineProperty):
1914         * debugger/Debugger.cpp:
1915         (JSC::DebuggerPausedScope::DebuggerPausedScope):
1916         (JSC::DebuggerPausedScope::~DebuggerPausedScope):
1917         (JSC::Debugger::didReachBreakpoint):
1918         (JSC::Debugger::currentDebuggerCallFrame):
1919         * debugger/Debugger.h:
1920         * debugger/DebuggerCallFrame.cpp:
1921         (JSC::LineAndColumnFunctor::operator()):
1922         (JSC::DebuggerCallFrame::create):
1923         (JSC::DebuggerCallFrame::DebuggerCallFrame):
1924         (JSC::DebuggerCallFrame::callerFrame):
1925         (JSC::DebuggerCallFrame::globalExec):
1926         (JSC::DebuggerCallFrame::vmEntryGlobalObject):
1927         (JSC::DebuggerCallFrame::sourceID):
1928         (JSC::DebuggerCallFrame::functionName):
1929         (JSC::DebuggerCallFrame::scope):
1930         (JSC::DebuggerCallFrame::type):
1931         (JSC::DebuggerCallFrame::thisValue):
1932         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
1933         (JSC::DebuggerCallFrame::invalidate):
1934         (JSC::DebuggerCallFrame::currentPosition):
1935         (JSC::DebuggerCallFrame::positionForCallFrame):
1936         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
1937         (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor): Deleted.
1938         (JSC::FindCallerMidStackFunctor::operator()): Deleted.
1939         (JSC::FindCallerMidStackFunctor::getCallerFrame): Deleted.
1940         (JSC::DebuggerCallFrame::thisValueForCallFrame): Deleted.
1941         * debugger/DebuggerCallFrame.h:
1942         (JSC::DebuggerCallFrame::isValid):
1943         (JSC::DebuggerCallFrame::isTailDeleted):
1944         (JSC::DebuggerCallFrame::create): Deleted.
1945         (JSC::DebuggerCallFrame::exec): Deleted.
1946         * dfg/DFGByteCodeParser.cpp:
1947         (JSC::DFG::ByteCodeParser::parseBlock):
1948         * dfg/DFGFixupPhase.cpp:
1949         (JSC::DFG::FixupPhase::fixupNode):
1950         * dfg/DFGGraph.cpp:
1951         (JSC::DFG::Graph::Graph):
1952         (JSC::DFG::Graph::~Graph):
1953         * dfg/DFGJITCompiler.h:
1954         (JSC::DFG::JITCompiler::addCallSite):
1955         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
1956         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
1957         * dfg/DFGSpeculativeJIT32_64.cpp:
1958         (JSC::DFG::SpeculativeJIT::compile):
1959         * dfg/DFGSpeculativeJIT64.cpp:
1960         (JSC::DFG::SpeculativeJIT::compile):
1961         * ftl/FTLAbstractHeapRepository.h:
1962         * ftl/FTLLowerDFGToB3.cpp:
1963         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
1964         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
1965         (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
1966         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
1967         (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
1968         (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket): Deleted.
1969         * inspector/InjectedScriptSource.js:
1970         (InjectedScript.CallFrameProxy):
1971         * inspector/JSJavaScriptCallFrame.cpp:
1972         (Inspector::JSJavaScriptCallFrame::thisObject):
1973         (Inspector::JSJavaScriptCallFrame::isTailDeleted):
1974         (Inspector::JSJavaScriptCallFrame::type):
1975         * inspector/JSJavaScriptCallFrame.h:
1976         * inspector/JSJavaScriptCallFramePrototype.cpp:
1977         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
1978         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
1979         (Inspector::jsJavaScriptCallFrameAttributeType):
1980         (Inspector::jsJavaScriptCallFrameIsTailDeleted):
1981         * inspector/JavaScriptCallFrame.h:
1982         (Inspector::JavaScriptCallFrame::type):
1983         (Inspector::JavaScriptCallFrame::scopeChain):
1984         (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
1985         (Inspector::JavaScriptCallFrame::isTailDeleted):
1986         (Inspector::JavaScriptCallFrame::thisValue):
1987         (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
1988         * inspector/ScriptDebugServer.cpp:
1989         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
1990         * inspector/protocol/Debugger.json:
1991         * interpreter/ShadowChicken.cpp:
1992         (JSC::ShadowChicken::update):
1993         (JSC::ShadowChicken::visitChildren):
1994         (JSC::ShadowChicken::reset):
1995         * interpreter/ShadowChicken.h:
1996         (JSC::ShadowChicken::Packet::throwMarker):
1997         (JSC::ShadowChicken::Packet::prologue):
1998         (JSC::ShadowChicken::Packet::tail):
1999         (JSC::ShadowChicken::Frame::Frame):
2000         (JSC::ShadowChicken::Frame::operator==):
2001         * jit/CCallHelpers.cpp:
2002         (JSC::CCallHelpers::logShadowChickenProloguePacket):
2003         (JSC::CCallHelpers::logShadowChickenTailPacket):
2004         (JSC::CCallHelpers::ensureShadowChickenPacket):
2005         (JSC::CCallHelpers::setupShadowChickenPacket): Deleted.
2006         * jit/CCallHelpers.h:
2007         * jit/JITOpcodes.cpp:
2008         (JSC::JIT::emit_op_profile_type):
2009         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2010         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2011         (JSC::JIT::emit_op_get_enumerable_length):
2012         (JSC::JIT::emit_op_resume):
2013         * jit/JITOpcodes32_64.cpp:
2014         (JSC::JIT::emit_op_profile_type):
2015         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2016         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2017         * jit/RegisterSet.cpp:
2018         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
2019         (JSC::RegisterSet::argumentGPRS):
2020         (JSC::RegisterSet::registersToNotSaveForJSCall):
2021         * jit/RegisterSet.h:
2022         * llint/LLIntData.cpp:
2023         (JSC::LLInt::Data::performAssertions):
2024         * llint/LLIntSlowPaths.cpp:
2025         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2026         * llint/LowLevelInterpreter.asm:
2027         * llint/LowLevelInterpreter32_64.asm:
2028         * llint/LowLevelInterpreter64.asm:
2029         * runtime/CodeCache.cpp:
2030         (JSC::CodeCache::getGlobalCodeBlock):
2031         * runtime/Options.h:
2032         * tests/stress/shadow-chicken-enabled.js:
2033         (test5a.foo):
2034         (test5a):
2035         (test5b.foo):
2036         (test5b):
2037         (test6.foo):
2038         (test6):
2039
2040 2016-05-16  Saam barati  <sbarati@apple.com>
2041
2042         TypeSet/StructureShape have a flawed sense of JS prototype chains
2043         https://bugs.webkit.org/show_bug.cgi?id=157760
2044
2045         Reviewed by Joseph Pecoraro.
2046
2047         There was an assumption that we would bottom out in "Object". This is
2048         not true for many reasons. JS objects may not end in Object.prototype.
2049         Also, our mechanism of grabbing an Object's class name may also not
2050         bottom out in "Object". We were seeing this in the JS objects we use
2051         in the InjectedScriptSource.js inspector script.
2052
2053         * runtime/TypeSet.cpp:
2054         (JSC::StructureShape::leastCommonAncestor):
2055         * tests/typeProfiler/weird-prototype-chain.js: Added.
2056         (wrapper.foo):
2057         (wrapper.let.o2):
2058         (wrapper):
2059
2060 2016-05-16  Joseph Pecoraro  <pecoraro@apple.com>
2061
2062         Unreviewed rollout r200924. Caused js/regress/string-replace-generic.html to fail.
2063
2064         * API/JSProfilerPrivate.cpp: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
2065         (JSStartProfiling):
2066         (JSEndProfiling):
2067         * API/JSProfilerPrivate.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
2068         * CMakeLists.txt:
2069         * JavaScriptCore.xcodeproj/project.pbxproj:
2070         * bytecode/BytecodeList.json:
2071         * bytecode/BytecodeUseDef.h:
2072         (JSC::computeUsesForBytecodeOffset):
2073         (JSC::computeDefsForBytecodeOffset):
2074         * bytecode/CodeBlock.cpp:
2075         (JSC::CodeBlock::dumpBytecode):
2076         * bytecode/UnlinkedFunctionExecutable.cpp:
2077         (JSC::generateUnlinkedFunctionCodeBlock):
2078         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2079         * bytecode/UnlinkedFunctionExecutable.h:
2080         * bytecompiler/BytecodeGenerator.cpp:
2081         (JSC::BytecodeGenerator::BytecodeGenerator):
2082         (JSC::BytecodeGenerator::emitCall):
2083         (JSC::BytecodeGenerator::emitCallVarargs):
2084         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2085         (JSC::BytecodeGenerator::emitConstructVarargs):
2086         (JSC::BytecodeGenerator::emitConstruct):
2087         * bytecompiler/BytecodeGenerator.h:
2088         (JSC::CallArguments::profileHookRegister):
2089         (JSC::BytecodeGenerator::shouldEmitProfileHooks):
2090         * bytecompiler/NodesCodegen.cpp:
2091         (JSC::CallArguments::CallArguments):
2092         (JSC::CallFunctionCallDotNode::emitBytecode):
2093         (JSC::ApplyFunctionCallDotNode::emitBytecode):
2094         * dfg/DFGAbstractInterpreterInlines.h:
2095         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2096         * dfg/DFGByteCodeParser.cpp:
2097         (JSC::DFG::ByteCodeParser::parseBlock):
2098         * dfg/DFGCapabilities.cpp:
2099         (JSC::DFG::capabilityLevel):
2100         * dfg/DFGClobberize.h:
2101         (JSC::DFG::clobberize):
2102         * dfg/DFGDoesGC.cpp:
2103         (JSC::DFG::doesGC):
2104         * dfg/DFGFixupPhase.cpp:
2105         (JSC::DFG::FixupPhase::fixupNode):
2106         * dfg/DFGNodeType.h:
2107         * dfg/DFGPredictionPropagationPhase.cpp:
2108         * dfg/DFGSafeToExecute.h:
2109         (JSC::DFG::safeToExecute):
2110         * dfg/DFGSpeculativeJIT32_64.cpp:
2111         (JSC::DFG::SpeculativeJIT::compile):
2112         * dfg/DFGSpeculativeJIT64.cpp:
2113         (JSC::DFG::SpeculativeJIT::compile):
2114         * inspector/InjectedScriptBase.cpp:
2115         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
2116         * inspector/protocol/Timeline.json:
2117         * interpreter/Interpreter.cpp:
2118         (JSC::UnwindFunctor::operator()):
2119         (JSC::Interpreter::execute):
2120         (JSC::Interpreter::executeCall):
2121         (JSC::Interpreter::executeConstruct):
2122         * jit/JIT.cpp:
2123         (JSC::JIT::privateCompileMainPass):
2124         * jit/JIT.h:
2125         * jit/JITOpcodes.cpp:
2126         (JSC::JIT::emit_op_profile_will_call):
2127         (JSC::JIT::emit_op_profile_did_call):
2128         * jit/JITOpcodes32_64.cpp:
2129         (JSC::JIT::emit_op_profile_will_call):
2130         (JSC::JIT::emit_op_profile_did_call):
2131         * jit/JITOperations.cpp:
2132         * jit/JITOperations.h:
2133         * jsc.cpp:
2134         * llint/LLIntSlowPaths.cpp:
2135         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2136         * llint/LLIntSlowPaths.h:
2137         * llint/LowLevelInterpreter.asm:
2138         * parser/ParserModes.h:
2139         * profiler/CallIdentifier.h: Added.
2140         (JSC::CallIdentifier::CallIdentifier):
2141         (JSC::CallIdentifier::functionName):
2142         (JSC::CallIdentifier::url):
2143         (JSC::CallIdentifier::lineNumber):
2144         (JSC::CallIdentifier::columnNumber):
2145         (JSC::CallIdentifier::operator==):
2146         (JSC::CallIdentifier::operator!=):
2147         (JSC::CallIdentifier::Hash::hash):
2148         (JSC::CallIdentifier::Hash::equal):
2149         (JSC::CallIdentifier::hash):
2150         (JSC::CallIdentifier::operator const char*):
2151         (JSC::CallIdentifier::c_str):
2152         (WTF::HashTraits<JSC::CallIdentifier>::constructDeletedValue):
2153         (WTF::HashTraits<JSC::CallIdentifier>::isDeletedValue):
2154         * profiler/LegacyProfiler.cpp: Added.
2155         (JSC::LegacyProfiler::profiler):
2156         (JSC::LegacyProfiler::startProfiling):
2157         (JSC::LegacyProfiler::stopProfiling):
2158         (JSC::callFunctionForProfilesWithGroup):
2159         (JSC::LegacyProfiler::suspendProfiling):
2160         (JSC::LegacyProfiler::unsuspendProfiling):
2161         (JSC::LegacyProfiler::willExecute):
2162         (JSC::LegacyProfiler::didExecute):
2163         (JSC::LegacyProfiler::exceptionUnwind):
2164         (JSC::LegacyProfiler::createCallIdentifier):
2165         (JSC::createCallIdentifierFromFunctionImp):
2166         * profiler/LegacyProfiler.h: Added.
2167         (JSC::LegacyProfiler::currentProfiles):
2168         * profiler/Profile.cpp: Added.
2169         (JSC::Profile::create):
2170         (JSC::Profile::Profile):
2171         (JSC::Profile::~Profile):
2172         (JSC::Profile::debugPrint):
2173         (JSC::functionNameCountPairComparator):
2174         (JSC::Profile::debugPrintSampleStyle):
2175         * profiler/Profile.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
2176         * profiler/ProfileGenerator.cpp: Added.
2177         (JSC::ProfileGenerator::create):
2178         (JSC::ProfileGenerator::ProfileGenerator):
2179         (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor):
2180         (JSC::AddParentForConsoleStartFunctor::foundParent):
2181         (JSC::AddParentForConsoleStartFunctor::operator()):
2182         (JSC::ProfileGenerator::addParentForConsoleStart):
2183         (JSC::ProfileGenerator::title):
2184         (JSC::ProfileGenerator::beginCallEntry):
2185         (JSC::ProfileGenerator::endCallEntry):
2186         (JSC::ProfileGenerator::willExecute):
2187         (JSC::ProfileGenerator::didExecute):
2188         (JSC::ProfileGenerator::exceptionUnwind):
2189         (JSC::ProfileGenerator::stopProfiling):
2190         (JSC::ProfileGenerator::removeProfileStart):
2191         (JSC::ProfileGenerator::removeProfileEnd):
2192         * profiler/ProfileGenerator.h: Added.
2193         (JSC::ProfileGenerator::profile):
2194         (JSC::ProfileGenerator::origin):
2195         (JSC::ProfileGenerator::profileGroup):
2196         (JSC::ProfileGenerator::setIsSuspended):
2197         * profiler/ProfileNode.cpp: Added.
2198         (JSC::ProfileNode::ProfileNode):
2199         (JSC::ProfileNode::addChild):
2200         (JSC::ProfileNode::removeChild):
2201         (JSC::ProfileNode::spliceNode):
2202         (JSC::ProfileNode::traverseNextNodePostOrder):
2203         (JSC::ProfileNode::debugPrint):
2204         (JSC::ProfileNode::debugPrintSampleStyle):
2205         (JSC::ProfileNode::debugPrintRecursively):
2206         (JSC::ProfileNode::debugPrintSampleStyleRecursively):
2207         * profiler/ProfileNode.h: Added.
2208         (JSC::ProfileNode::create):
2209         (JSC::ProfileNode::Call::Call):
2210         (JSC::ProfileNode::Call::startTime):
2211         (JSC::ProfileNode::Call::setStartTime):
2212         (JSC::ProfileNode::Call::elapsedTime):
2213         (JSC::ProfileNode::Call::setElapsedTime):
2214         (JSC::ProfileNode::operator==):
2215         (JSC::ProfileNode::callerCallFrame):
2216         (JSC::ProfileNode::callIdentifier):
2217         (JSC::ProfileNode::id):
2218         (JSC::ProfileNode::functionName):
2219         (JSC::ProfileNode::url):
2220         (JSC::ProfileNode::lineNumber):
2221         (JSC::ProfileNode::columnNumber):
2222         (JSC::ProfileNode::parent):
2223         (JSC::ProfileNode::setParent):
2224         (JSC::ProfileNode::calls):
2225         (JSC::ProfileNode::lastCall):
2226         (JSC::ProfileNode::appendCall):
2227         (JSC::ProfileNode::children):
2228         (JSC::ProfileNode::firstChild):
2229         (JSC::ProfileNode::lastChild):
2230         (JSC::ProfileNode::nextSibling):
2231         (JSC::ProfileNode::setNextSibling):
2232         (JSC::ProfileNode::forEachNodePostorder):
2233         (JSC::CalculateProfileSubtreeDataFunctor::operator()):
2234         (JSC::CalculateProfileSubtreeDataFunctor::returnValue):
2235         * profiler/ProfilerJettisonReason.cpp:
2236         (WTF::printInternal):
2237         * profiler/ProfilerJettisonReason.h:
2238         * runtime/CodeCache.cpp:
2239         (JSC::CodeCache::getGlobalCodeBlock):
2240         (JSC::CodeCache::getProgramCodeBlock):
2241         (JSC::CodeCache::getEvalCodeBlock):
2242         (JSC::CodeCache::getModuleProgramCodeBlock):
2243         * runtime/CodeCache.h:
2244         * runtime/Executable.cpp:
2245         (JSC::ScriptExecutable::newCodeBlockFor):
2246         * runtime/JSGlobalObject.cpp:
2247         (JSC::JSGlobalObject::~JSGlobalObject):
2248         (JSC::JSGlobalObject::hasLegacyProfiler):
2249         (JSC::JSGlobalObject::createProgramCodeBlock):
2250         (JSC::JSGlobalObject::createEvalCodeBlock):
2251         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
2252         * runtime/JSGlobalObject.h:
2253         (JSC::JSGlobalObject::supportsLegacyProfiling):
2254         * runtime/Options.h:
2255         * runtime/VM.cpp:
2256         (JSC::VM::VM):
2257         (JSC::SetEnabledProfilerFunctor::operator()):
2258         (JSC::VM::setEnabledProfiler):
2259         * runtime/VM.h:
2260         (JSC::VM::enabledProfiler):
2261         (JSC::VM::enabledProfilerAddress):
2262
2263 2016-05-16  Konstantin Tokarev  <annulen@yandex.ru>
2264
2265         Unreviewed, fixed typo in a comment.
2266
2267         * assembler/MacroAssembler.h: Replaced "onvenience" with
2268         "convenience".
2269
2270 2016-05-16  Filip Pizlo  <fpizlo@apple.com>
2271
2272         FixupPhase should be more eager to demote bit math to untyped
2273         https://bugs.webkit.org/show_bug.cgi?id=157746
2274
2275         Reviewed by Mark Lam.
2276         
2277         This just makes the logic for how we fixup bit math match the way we do it in other places.
2278         This doesn't affect performance on any major benchmark but it's a big win on new
2279         microbenchmarks added in this change.
2280         
2281         Details:
2282
2283         object-and                                     11.1610+-0.7602     ^      4.8105+-0.1690        ^ definitely 2.3201x faster
2284         object-or                                      11.0845+-0.2487     ^      4.7146+-0.0374        ^ definitely 2.3511x faster
2285         object-xor                                     10.2946+-0.9946     ^      4.7278+-0.0814        ^ definitely 2.1775x faster
2286         object-lshift                                  10.4896+-1.0867     ^      4.7699+-0.0721        ^ definitely 2.1991x faster
2287         object-rshift                                  11.1239+-0.5010     ^      4.7194+-0.0445        ^ definitely 2.3570x faster
2288         object-urshift                                 10.9745+-0.1315     ^      4.7848+-0.0479        ^ definitely 2.2936x faster
2289
2290         * dfg/DFGFixupPhase.cpp:
2291         (JSC::DFG::FixupPhase::fixupNode):
2292
2293 2016-05-15  Michael Saboff  <msaboff@apple.com>
2294
2295         RegExp /y flag incorrect handling of mixed-length alternation
2296         https://bugs.webkit.org/show_bug.cgi?id=157723
2297
2298         Reviewed by Filip Pizlo.
2299
2300         Previously for sticky patterns, we were bailing out and exiting when backtracking
2301         alternatives with dissimilar match lengths.  Deleted that code.  Instead, for
2302         sticky patterns we need to process the backtracking except for advancing to the
2303         next input index.
2304
2305         * yarr/YarrJIT.cpp:
2306         (JSC::Yarr::YarrGenerator::backtrack):
2307
2308 2016-05-15  Filip Pizlo  <fpizlo@apple.com>
2309
2310         DFG::Plan shouldn't read from its VM once it's been cancelled
2311         https://bugs.webkit.org/show_bug.cgi?id=157726
2312
2313         Reviewed by Saam Barati.
2314         
2315         Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a
2316         cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling
2317         the plan.
2318         
2319         Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody
2320         would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard
2321         regression to spot because usually a cancelled plan will still refer to a valid VM.
2322         
2323         This change fixes the regression and makes it a lot easier to spot the regression in the
2324         future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this
2325         mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is
2326         cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to
2327         use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst.
2328         
2329         Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the
2330         plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the
2331         safepoint's VM to determine whether this is one of our safepoints *after* the plan is
2332         already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled
2333         when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's
2334         vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one
2335         loop and a cancel path for Safepoints in the loop after it).
2336
2337         * dfg/DFGJITFinalizer.cpp:
2338         (JSC::DFG::JITFinalizer::finalizeCommon):
2339         * dfg/DFGPlan.cpp:
2340         (JSC::DFG::Plan::Plan):
2341         (JSC::DFG::Plan::computeCompileTimes):
2342         (JSC::DFG::Plan::reportCompileTimes):
2343         (JSC::DFG::Plan::compileInThreadImpl):
2344         (JSC::DFG::Plan::reallyAdd):
2345         (JSC::DFG::Plan::notifyCompiling):
2346         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2347         (JSC::DFG::Plan::cancel):
2348         * dfg/DFGPlan.h:
2349         (JSC::DFG::Plan::canTierUpAndOSREnter):
2350         * dfg/DFGSafepoint.cpp:
2351         (JSC::DFG::Safepoint::cancel):
2352         (JSC::DFG::Safepoint::vm):
2353         * dfg/DFGSafepoint.h:
2354         * dfg/DFGWorklist.cpp:
2355         (JSC::DFG::Worklist::isActiveForVM):
2356         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
2357         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
2358         (JSC::DFG::Worklist::rememberCodeBlocks):
2359         (JSC::DFG::Worklist::visitWeakReferences):
2360         (JSC::DFG::Worklist::removeDeadPlans):
2361         (JSC::DFG::Worklist::runThread):
2362         * ftl/FTLJITFinalizer.cpp:
2363         (JSC::FTL::JITFinalizer::finalizeFunction):
2364
2365 2016-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2366
2367         Modernize Intl constructors; using InternalFunction::createSubclassStructure
2368         https://bugs.webkit.org/show_bug.cgi?id=157082
2369
2370         Reviewed by Darin Adler.
2371
2372         Previously, Intl constructors retrieve "prototype" to inherit the "new.target".
2373         At that time, this mis-assumed that getDirect() always returns meaningful JS value.
2374         Actually, it returns an empty value if a property does not exist.
2375
2376         Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure
2377         in Intl constructors. It is modern and preferable way since it can cache the derived
2378         structures in InternalFunction.
2379
2380         This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat.
2381         Those code are largely duplicate. This is now extracted into
2382         constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not
2383         have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat
2384         and LayoutTests/js/intl-numberformat.
2385
2386         * JavaScriptCore.xcodeproj/project.pbxproj:
2387         * runtime/IntlCollator.cpp:
2388         (JSC::IntlCollator::create):
2389         * runtime/IntlCollator.h:
2390         * runtime/IntlCollatorConstructor.cpp:
2391         (JSC::constructIntlCollator):
2392         (JSC::callIntlCollator):
2393         * runtime/IntlDateTimeFormat.cpp:
2394         (JSC::IntlDateTimeFormat::create):
2395         * runtime/IntlDateTimeFormat.h:
2396         * runtime/IntlDateTimeFormatConstructor.cpp:
2397         (JSC::constructIntlDateTimeFormat):
2398         (JSC::callIntlDateTimeFormat):
2399         * runtime/IntlDateTimeFormatPrototype.cpp:
2400         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
2401         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
2402         * runtime/IntlNumberFormat.cpp:
2403         (JSC::IntlNumberFormat::create):
2404         * runtime/IntlNumberFormat.h:
2405         * runtime/IntlNumberFormatConstructor.cpp:
2406         (JSC::constructIntlNumberFormat):
2407         (JSC::callIntlNumberFormat):
2408         * runtime/IntlNumberFormatPrototype.cpp:
2409         (JSC::IntlNumberFormatPrototypeGetterFormat):
2410         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
2411         * runtime/IntlObjectInlines.h: Added.
2412         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
2413         * tests/stress/intl-constructors-with-proxy.js: Added.
2414         (shouldBe):
2415         (throw.new.Error.Empty):
2416         (throw.new.Error):
2417         (shouldBe.Empty):
2418
2419 2016-05-14  Joseph Pecoraro  <pecoraro@apple.com>
2420
2421         Remove LegacyProfiler
2422         https://bugs.webkit.org/show_bug.cgi?id=153565
2423
2424         Reviewed by Mark Lam.
2425
2426         JavaScriptCore now provides a sampling profiler and it is enabled
2427         by all ports. Web Inspector switched months ago to using the
2428         sampling profiler and displaying its data. Remove the legacy
2429         profiler, as it is no longer being used by anything other then
2430         console.profile and tests. We will update console.profile's
2431         behavior soon to have new behavior and use the sampling data.
2432
2433         * API/JSProfilerPrivate.cpp: Removed.
2434         * API/JSProfilerPrivate.h: Removed.
2435         * CMakeLists.txt:
2436         * JavaScriptCore.xcodeproj/project.pbxproj:
2437         * bytecode/BytecodeList.json:
2438         * bytecode/BytecodeUseDef.h:
2439         (JSC::computeUsesForBytecodeOffset): Deleted.
2440         (JSC::computeDefsForBytecodeOffset): Deleted.
2441         * bytecode/CodeBlock.cpp:
2442         (JSC::CodeBlock::dumpBytecode): Deleted.
2443         * bytecode/UnlinkedFunctionExecutable.cpp:
2444         (JSC::generateUnlinkedFunctionCodeBlock):
2445         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2446         * bytecode/UnlinkedFunctionExecutable.h:
2447         * bytecompiler/BytecodeGenerator.cpp:
2448         (JSC::BytecodeGenerator::BytecodeGenerator):
2449         (JSC::BytecodeGenerator::emitCall):
2450         (JSC::BytecodeGenerator::emitCallVarargs):
2451         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2452         (JSC::BytecodeGenerator::emitConstructVarargs):
2453         (JSC::BytecodeGenerator::emitConstruct):
2454         * bytecompiler/BytecodeGenerator.h:
2455         (JSC::CallArguments::profileHookRegister): Deleted.
2456         (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
2457         * bytecompiler/NodesCodegen.cpp:
2458         (JSC::CallFunctionCallDotNode::emitBytecode):
2459         (JSC::ApplyFunctionCallDotNode::emitBytecode):
2460         (JSC::CallArguments::CallArguments): Deleted.
2461         * dfg/DFGAbstractInterpreterInlines.h:
2462         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
2463         * dfg/DFGByteCodeParser.cpp:
2464         (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
2465         * dfg/DFGCapabilities.cpp:
2466         (JSC::DFG::capabilityLevel): Deleted.
2467         * dfg/DFGClobberize.h:
2468         (JSC::DFG::clobberize): Deleted.
2469         * dfg/DFGDoesGC.cpp:
2470         (JSC::DFG::doesGC): Deleted.
2471         * dfg/DFGFixupPhase.cpp:
2472         (JSC::DFG::FixupPhase::fixupNode): Deleted.
2473         * dfg/DFGNodeType.h:
2474         * dfg/DFGPredictionPropagationPhase.cpp:
2475         * dfg/DFGSafeToExecute.h:
2476         (JSC::DFG::safeToExecute): Deleted.
2477         * dfg/DFGSpeculativeJIT32_64.cpp:
2478         (JSC::DFG::SpeculativeJIT::compile): Deleted.
2479         * dfg/DFGSpeculativeJIT64.cpp:
2480         (JSC::DFG::SpeculativeJIT::compile): Deleted.
2481         * inspector/InjectedScriptBase.cpp:
2482         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
2483         * inspector/protocol/Timeline.json:
2484         * interpreter/Interpreter.cpp:
2485         (JSC::UnwindFunctor::operator()): Deleted.
2486         (JSC::Interpreter::execute): Deleted.
2487         (JSC::Interpreter::executeCall): Deleted.
2488         (JSC::Interpreter::executeConstruct): Deleted.
2489         * jit/JIT.cpp:
2490         (JSC::JIT::privateCompileMainPass): Deleted.
2491         * jit/JIT.h:
2492         * jit/JITOpcodes.cpp:
2493         (JSC::JIT::emit_op_profile_will_call): Deleted.
2494         (JSC::JIT::emit_op_profile_did_call): Deleted.
2495         * jit/JITOpcodes32_64.cpp:
2496         (JSC::JIT::emit_op_profile_will_call): Deleted.
2497         (JSC::JIT::emit_op_profile_did_call): Deleted.
2498         * jit/JITOperations.cpp:
2499         * jit/JITOperations.h:
2500         * jsc.cpp:
2501         * llint/LLIntSlowPaths.cpp:
2502         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
2503         * llint/LLIntSlowPaths.h:
2504         * llint/LowLevelInterpreter.asm:
2505         * parser/ParserModes.h:
2506         * profiler/CallIdentifier.h: Removed.
2507         * profiler/LegacyProfiler.cpp: Removed.
2508         * profiler/LegacyProfiler.h: Removed.
2509         * profiler/Profile.cpp: Removed.
2510         * profiler/Profile.h: Removed.
2511         * profiler/ProfileGenerator.cpp: Removed.
2512         * profiler/ProfileGenerator.h: Removed.
2513         * profiler/ProfileNode.cpp: Removed.
2514         * profiler/ProfileNode.h: Removed.
2515         * profiler/ProfilerJettisonReason.cpp:
2516         (WTF::printInternal): Deleted.
2517         * profiler/ProfilerJettisonReason.h:
2518         * runtime/CodeCache.cpp:
2519         (JSC::CodeCache::getGlobalCodeBlock):
2520         (JSC::CodeCache::getProgramCodeBlock):
2521         (JSC::CodeCache::getEvalCodeBlock):
2522         (JSC::CodeCache::getModuleProgramCodeBlock):
2523         * runtime/CodeCache.h:
2524         * runtime/Executable.cpp:
2525         (JSC::ScriptExecutable::newCodeBlockFor):
2526         * runtime/JSGlobalObject.cpp:
2527         (JSC::JSGlobalObject::createProgramCodeBlock):
2528         (JSC::JSGlobalObject::createEvalCodeBlock):
2529         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
2530         (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
2531         (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
2532         * runtime/JSGlobalObject.h:
2533         (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
2534         * runtime/Options.h:
2535         * runtime/VM.cpp:
2536         (JSC::VM::VM): Deleted.
2537         (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
2538         (JSC::VM::setEnabledProfiler): Deleted.
2539         * runtime/VM.h:
2540         (JSC::VM::enabledProfiler): Deleted.
2541         (JSC::VM::enabledProfilerAddress): Deleted.
2542
2543 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
2544
2545         jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash
2546         https://bugs.webkit.org/show_bug.cgi?id=157704
2547
2548         Reviewed by Saam Barati.
2549
2550         * jsc.cpp:
2551         (functionStartSamplingProfiler):
2552         (functionSamplingProfilerStackTraces):
2553         Throw an exception instead of crashing if we haven't started sampling.
2554
2555         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2556         (Inspector::InspectorScriptProfilerAgent::startTracking):
2557         * runtime/VM.h:
2558         * runtime/VM.cpp:
2559         (JSC::VM::ensureSamplingProfiler):
2560         Switch ensure to returning a reference, like most other ensures.
2561
2562 2016-05-13  Saam barati  <sbarati@apple.com>
2563
2564         DFG/FTL have a few bugs in their reasoning about the scope
2565         https://bugs.webkit.org/show_bug.cgi?id=157696
2566
2567         Reviewed by Benjamin Poulain.
2568
2569         1. When the debugger is enabled, it is easier for the DFG to reason
2570         about the scope register by simply claiming all nodes read the scope
2571         register. This prevents us from ever entering the runtime where we
2572         may take a stack trace but there isn't a scope on the stack.
2573
2574         2. This patch fixes a bug where the FTL compilation wasn't properly
2575         setting the CodeBlock register. It was only doing this when there
2576         was inline data, but when the debugger is enabled, we never inline.
2577         So this code just needed to be removed from that loop. It was never
2578         right for it to be inside the loop.
2579
2580         * dfg/DFGClobberize.h:
2581         (JSC::DFG::clobberize):
2582         * ftl/FTLCompile.cpp:
2583         (JSC::FTL::compile):
2584
2585 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
2586
2587         [JSC] SetLocal without exit do not need phantoms
2588         https://bugs.webkit.org/show_bug.cgi?id=157653
2589
2590         Reviewed by Filip Pizlo.
2591
2592         I made a mistake in r200498.
2593
2594         If a SetLocal cannot possibly exit, we were not clearing
2595         the source of the operand. As a result, we sometime kept
2596         a value alive up to the end of the block.
2597
2598         That's uncommon because SetLocal typically appear
2599         toward the end of blocks. That's probably why there was
2600         no perf impact with that fix.
2601
2602         * dfg/DFGPhantomInsertionPhase.cpp:
2603
2604 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
2605
2606         [JSC] Move the CheckTierUp function calls out of the main path
2607         https://bugs.webkit.org/show_bug.cgi?id=157668
2608
2609         Reviewed by Mark Lam.
2610
2611         If you have a tiny tiny loop (for example, Sunspider's bits-in-byte),
2612         the size of CheckTierUp is a problem.
2613
2614         On multi-issue CPUs, the node is so big that we do not
2615         get to run anything from the loop in the instruction fetch.
2616
2617         On x86, having a bigger loop also pushes us out of the LSD.
2618
2619         This is a 6% improvement on bits-in-byte. Other Sunspider tests
2620         only improves marginally.
2621
2622         * dfg/DFGSpeculativeJIT.cpp:
2623         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
2624         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
2625         * dfg/DFGSpeculativeJIT.h:
2626         (JSC::DFG::SpeculativeJIT::silentSpill):
2627         (JSC::DFG::SpeculativeJIT::silentFill):
2628         * dfg/DFGSpeculativeJIT64.cpp:
2629         (JSC::DFG::SpeculativeJIT::compile):
2630
2631 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
2632
2633         [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used
2634         https://bugs.webkit.org/show_bug.cgi?id=157671
2635
2636         Reviewed by Mark Lam.
2637
2638         This improves the chances of having a value
2639         when issuing the TEST.
2640
2641         * jit/JITPropertyAccess.cpp:
2642         (JSC::JIT::emitLoadWithStructureCheck):
2643
2644 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
2645
2646         Web Inspector: Inform augmenting client when inspector controller is destroyed
2647         https://bugs.webkit.org/show_bug.cgi?id=157688
2648         <rdar://problem/25832724>
2649
2650         Reviewed by Timothy Hatcher.
2651
2652         * inspector/JSGlobalObjectInspectorController.cpp:
2653         (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
2654         * inspector/augmentable/AugmentableInspectorControllerClient.h:
2655         There is a weak relationship between the InspectorController and the
2656         AugmentingClient. Let the augmenting client know when the controller
2657         is destroyed so it doesn't try to use us anymore.
2658
2659 2016-05-13  Geoffrey Garen  <ggaren@apple.com>
2660
2661         Runaway malloc memory usage in this simple JSC program
2662         https://bugs.webkit.org/show_bug.cgi?id=157682
2663
2664         Reviewed by Mark Lam.
2665
2666         * heap/WeakSet.cpp:
2667         (JSC::WeakSet::sweep): Whenever we might add a block to
2668         m_logicallyEmptyWeakBlocks, be sure also to sweep a block in
2669         m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals
2670         even when all memory is freed.
2671
2672         We do this whenever we *might* add a block and not just whenever we *do*
2673         add a block because we'd like to sweep the entries in
2674         m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this
2675         is a reasonably rate-limited opportunity to do so.
2676
2677 2016-05-13  Mark Lam  <mark.lam@apple.com>
2678
2679         We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM.
2680         https://bugs.webkit.org/show_bug.cgi?id=157537
2681         <rdar://problem/24794845>
2682
2683         Reviewed by Michael Saboff.
2684
2685         The pre-existing code behaves this way:
2686
2687         1. When JS code throws an exception, it saves callee save registers in
2688            the VM calleeSaveRegistersBuffer.  These values are meant to be restored
2689            to the callee save registers later either at the catch handler or at the
2690            uncaught exception handler.
2691
2692         2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect
2693            the exception.  That C++ code can change the values of the callee save
2694            registers.
2695
2696            The inspector code in turn re-enters the VM to execute JS inspector code.
2697
2698            The JS inspector code can run hot enough that we do an enterOptimizationCheck
2699            on it.  The enterOptimizationCheck first saves all callee save registers
2700            into the VM calleeSaveRegistersBuffer.
2701
2702            This effectively overwrites the values in the VM calleeSaveRegistersBuffer
2703            from (1).
2704
2705         3. Eventually, execution returns to the catch handler or the uncaught exception
2706            handler which restores the overwritten values in the VM
2707            calleeSaveRegistersBuffer to the callee save registers.
2708
2709            When execution returns to the C++ code that entered the VM before (1), the
2710            values in the callee registers are not what that code expects, and badness
2711            and/or crashes ensues.
2712
2713         This patch applies the following fix:
2714         
2715         1. Allocate space in the VMEntryFrame for the calleeSaveRegistersBuffer.
2716            This ensures that each VM entry session has its own buffer to use, and will
2717            not corrupt the one from the previous VM entry session.
2718
2719            Delete the VM calleeSaveRegistersBuffer.
2720
2721         2. Change all locations that uses the VM calleeSaveRegistersBuffer to use the
2722            calleeSaveRegistersBuffer in the current VMEntryFrame.
2723
2724         3. Renamed all uses of the term "VMCalleeSavesBuffer" to
2725            "VMEntryFrameCalleeSavesBuffer".
2726
2727         This fix has been tested on the following configurations:
2728         1. JSC and layout tests on a debug ASan build for 64-bit x86_64.
2729         2. JSC tests on a release ASan build for 32-bit x86.
2730         3. JSC tests on a release normal (non-ASan) build for ARM64.
2731         4. JSC tests on a release normal (non-ASan) build for ARMv7 and ARMv7s.
2732         5. JSC tests on a release ASan CLOOP build for x86_64.
2733
2734         These test runs did not produce any new crashes.  The ASan CLOOP has some
2735         pre-existing crashes which are not due to this patch.
2736
2737         This bug can be tested by running the inspector/debugger/regress-133182.html test
2738         on an ASan build.
2739
2740         * bytecode/PolymorphicAccess.cpp:
2741         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
2742         * dfg/DFGJITCompiler.cpp:
2743         (JSC::DFG::JITCompiler::compileExceptionHandlers):
2744         * dfg/DFGOSREntry.cpp:
2745         (JSC::DFG::prepareOSREntry):
2746         * dfg/DFGOSRExitCompiler.cpp:
2747         * dfg/DFGOSRExitCompiler32_64.cpp:
2748         (JSC::DFG::OSRExitCompiler::compileExit):
2749         * dfg/DFGOSRExitCompiler64.cpp:
2750         (JSC::DFG::OSRExitCompiler::compileExit):
2751         * dfg/DFGThunks.cpp:
2752         (JSC::DFG::osrEntryThunkGenerator):
2753         * ftl/FTLCompile.cpp:
2754         (JSC::FTL::compile):
2755         * ftl/FTLLowerDFGToB3.cpp:
2756         (JSC::FTL::DFG::LowerDFGToB3::lower):
2757         * ftl/FTLOSRExitCompiler.cpp:
2758         (JSC::FTL::compileStub):
2759         * interpreter/Interpreter.cpp:
2760         (JSC::UnwindFunctor::operator()):
2761         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2762         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
2763         * interpreter/Interpreter.h:
2764         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
2765         * interpreter/VMEntryRecord.h:
2766         (JSC::VMEntryRecord::calleeSaveRegistersBufferOffset):
2767         (JSC::VMEntryRecord::prevTopCallFrame):
2768         (JSC::VMEntryRecord::unsafePrevTopCallFrame):
2769         (JSC::VMEntryFrame::vmEntryRecordOffset):
2770         (JSC::VMEntryFrame::calleeSaveRegistersBufferOffset):
2771         * jit/AssemblyHelpers.cpp:
2772         (JSC::AssemblyHelpers::emitRandomThunk):
2773         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2774         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
2775         * jit/AssemblyHelpers.h:
2776         (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
2777         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2778         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
2779         (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
2780         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer): Deleted.
2781         * jit/JIT.cpp:
2782         (JSC::JIT::emitEnterOptimizationCheck):
2783         (JSC::JIT::privateCompileExceptionHandlers):
2784         * jit/JITOpcodes.cpp:
2785         (JSC::JIT::emit_op_throw):
2786         (JSC::JIT::emit_op_catch):
2787         (JSC::JIT::emitSlow_op_loop_hint):
2788         * jit/JITOpcodes32_64.cpp:
2789         (JSC::JIT::emit_op_throw):
2790         (JSC::JIT::emit_op_catch):
2791         * jit/ThunkGenerators.cpp:
2792         (JSC::throwExceptionFromCallSlowPathGenerator):
2793         (JSC::nativeForGenerator):
2794         * llint/LLIntThunks.cpp:
2795         (JSC::vmEntryRecord):
2796         * llint/LowLevelInterpreter.asm:
2797         * llint/LowLevelInterpreter32_64.asm:
2798         * llint/LowLevelInterpreter64.asm:
2799         * runtime/VM.h:
2800         (JSC::VM::getCTIStub):
2801         (JSC::VM::calleeSaveRegistersBufferOffset): Deleted.
2802         * wasm/WASMFunctionCompiler.h:
2803         (JSC::WASMFunctionCompiler::endFunction):
2804
2805 2016-05-13  Beth Dakin  <bdakin@apple.com>
2806
2807         Add dyldSPI.h for linked on or after checks, and add one for link preview
2808         https://bugs.webkit.org/show_bug.cgi?id=157401
2809         -and corresponding-
2810         rdar://problem/26253396
2811
2812         Reviewed by Darin Adler.
2813
2814         Import #import <wtf/spi/darwin/dyldSPI.h> which now declares all of the 
2815         needed dyld code.
2816         * API/JSWrapperMap.mm:
2817
2818 2016-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2819
2820         Assertion failure for direct eval in non-class method
2821         https://bugs.webkit.org/show_bug.cgi?id=157138
2822
2823         Reviewed by Saam Barati.
2824
2825         This assertion was incorrect. In method definitions in object literals,
2826         it can be sloppy mode, but its DerivedContextType may not be DerivedContextType::None.
2827
2828         * bytecode/EvalCodeCache.h:
2829         (JSC::EvalCodeCache::CacheKey::CacheKey):
2830         (JSC::EvalCodeCache::CacheKey::operator==):
2831         (JSC::EvalCodeCache::CacheKey::Hash::equal):
2832         (JSC::EvalCodeCache::tryGet):
2833         (JSC::EvalCodeCache::getSlow):
2834         * interpreter/Interpreter.cpp:
2835         (JSC::eval):
2836         * tests/stress/direct-eval-in-object-literal-methods.js: Added.
2837         (shouldBe):
2838         (throw.new.Error):
2839         (shouldBe.Parent.prototype.l):
2840         (shouldBe.Parent):
2841         (shouldBe.Derived.prototype.m):
2842         (shouldBe.Derived):
2843
2844 2016-05-13  Skachkov Oleksandr  <gskachkov@gmail.com>
2845
2846         Assertion failure for super() call in arrow function default parameters
2847         https://bugs.webkit.org/show_bug.cgi?id=157079
2848
2849         Reviewed by Saam Barati.
2850
2851         Root of the issue that in arrow function we load bounded variables this/super/new.target just after 
2852         input parameters were initialized, and did not covered case of default values for 
2853         function parameters. 
2854         Current patch tried to fix issue and allow to load bounded variables earlier, before the input 
2855         parameters are assigned by default values.
2856
2857         * bytecompiler/BytecodeGenerator.cpp:
2858         (JSC::BytecodeGenerator::BytecodeGenerator):
2859         * tests/stress/arrowfunction-lexical-bind-this-2.js:
2860
2861 2016-05-12  Mark Lam  <mark.lam@apple.com>
2862
2863         Baseline and DFG's JSC_report...CompileTimes needs CodeBlock hashes.
2864         https://bugs.webkit.org/show_bug.cgi?id=157643
2865
2866         Reviewed by Keith Miller.
2867
2868         * runtime/Options.cpp:
2869         (JSC::recomputeDependentOptions):
2870
2871 2016-05-12  Csaba Osztrogonác  <ossy@webkit.org>
2872
2873         Remove ENABLE(ES6_ARROWFUNCTION_SYNTAX) guards
2874         https://bugs.webkit.org/show_bug.cgi?id=157564
2875
2876         Reviewed by Darin Adler.
2877
2878         * Configurations/FeatureDefines.xcconfig:
2879         * parser/Parser.cpp:
2880
2881 2016-05-12  Joseph Pecoraro  <pecoraro@apple.com>
2882
2883         Web Inspector: CRASH getting internal properties of function with no bound arguments causes
2884         https://bugs.webkit.org/show_bug.cgi?id=157613
2885         <rdar://problem/26238754>
2886
2887         Reviewed by Timothy Hatcher.
2888
2889         * inspector/JSInjectedScriptHost.cpp:
2890         (Inspector::JSInjectedScriptHost::getInternalProperties):
2891         Gracefully handle a JSBoundFunction with no bound arguments.
2892         In this case boundArgs is JSValue() which we don't want to
2893         expose as the value of the internal property.
2894
2895 2016-05-11  Benjamin Poulain  <bpoulain@apple.com>
2896
2897         [JSC] Make sure StringRange is passed to Vector by register
2898         https://bugs.webkit.org/show_bug.cgi?id=157603
2899
2900         Reviewed by Darin Adler.
2901
2902         This is bizarre, but on my SDK, Vector::append(StringRange)
2903         is passing the values on the stack.
2904         The two integers are written to the stack, the address given
2905         to append(), then append() reads it back and store it.
2906
2907         This patch changes the code to use constructAndAppend(), ensuring
2908         the values are used directly.
2909
2910         On my machine, this helps Sunspider and Octane.
2911         This might be something wrong with my SDK but the fix is so easy
2912         that we might as well do this.
2913
2914         * runtime/StringPrototype.cpp:
2915         (JSC::removeUsingRegExpSearch):
2916         (JSC::replaceUsingRegExpSearch):
2917
2918 2016-05-11  Zan Dobersek  <zdobersek@igalia.com>
2919
2920         ARMv7Assembler: suppress a -Wnarrowing warning when compiling with GCC
2921         https://bugs.webkit.org/show_bug.cgi?id=157576
2922
2923         Reviewed by Csaba Osztrogonác.
2924
2925         * assembler/ARMv7Assembler.h:
2926         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): Explicitly cast the
2927         `OP_CMP_reg_T2 | left` value to uint16_t, avoiding a narrowing conversion
2928         warning that's being reported when compiling with GCC. The warning is sprung
2929         due to RegisterID (which is the type of `left`) being an enum based on int,
2930         even when the enum itself only declares 23 values.
2931
2932 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
2933
2934         Web Inspector: `this` in Scope Chain Sidebar does not have preview, looks poor
2935         https://bugs.webkit.org/show_bug.cgi?id=157602
2936
2937         Reviewed by Timothy Hatcher.
2938
2939         * inspector/InjectedScriptSource.js:
2940         (InjectedScript.CallFrameProxy):
2941         Include a preview when creating the RemoteObject for `this`.
2942
2943 2016-05-11  Keith Miller  <keith_miller@apple.com>
2944
2945         Unreviewed, correct the title of the ChangeLog for r200667.
2946
2947 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
2948
2949         JSC test stress/reflect-set.js failing after 200694
2950         https://bugs.webkit.org/show_bug.cgi?id=157586
2951
2952         Unreviewed test rebaseline.
2953
2954         * tests/stress/reflect-set.js:
2955         Update the expected error message. We are in strict mode, so the
2956         improved error message makes sense.
2957
2958 2016-05-11  Filip Pizlo  <fpizlo@apple.com>
2959
2960         Beef up JSC profiler event log
2961         https://bugs.webkit.org/show_bug.cgi?id=157584
2962
2963         Reviewed by Saam Barati.
2964         
2965         Also log more about compilation.
2966
2967         * bytecode/ExecutionCounter.cpp: Changed the meaning of codeBlock to be the codeBlock that is doing the profiling. This will now get the baseline version if it needs it. This is needed for logging the threshold checking event.
2968         (JSC::applyMemoryUsageHeuristics):
2969         (JSC::ExecutionCounter<countingVariant>::hasCrossedThreshold):
2970         * dfg/DFGJITCode.cpp: Pass the right codeBlock.
2971         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
2972         (JSC::DFG::JITCode::optimizeNextInvocation):
2973         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
2974         (JSC::DFG::JITCode::optimizeSoon):
2975         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
2976         * dfg/DFGPlan.cpp: Log things about compile times and whether the compiler succeeded or failed.
2977         (JSC::DFG::Plan::computeCompileTimes):
2978         (JSC::DFG::Plan::reportCompileTimes):
2979         (JSC::DFG::Plan::compileInThread):
2980         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2981         * jit/ExecutableAllocatorFixedVMPool.cpp: Make it possible to look at memory usage, though separately from the log, for now.
2982         (JSC::ExecutableAllocator::allocate):
2983         * runtime/Options.h:
2984
2985 2016-05-11  Saam barati  <sbarati@apple.com>
2986
2987         Air may decide to put the result register of an arithmetic snippet in the tag register
2988         https://bugs.webkit.org/show_bug.cgi?id=157548
2989
2990         Reviewed by Filip Pizlo.
2991
2992         This patch adds a new ValueRep to B3 called LateRegister. The semantics
2993         are similar to Register in that it can be used to pin an argument to
2994         a particular register. It differs from ValueRep::Register in that the semantics of
2995         LateRegister are that it is used after the result of the node its an argument to
2996         is computed. This means that a LateRegister argument will interfere with the result
2997         of a node. LateRegister is not a valid result ValueRep.
2998
2999         This was needed because there was a bug where B3/Air would assign the
3000         result of a patchpoint to the TagTypeNumber register. This broke our
3001         code when we would box a double into a JSValue in a snippet when the
3002         result is the same as the TagTypeNumber register. To fix the issue,
3003         we pass TagMaskRegister and TagTypeNumberRegister as ValueRep::LateRegister
3004         arguments to various patchpoints.
3005
3006         * b3/B3LowerToAir.cpp:
3007         (JSC::B3::Air::LowerToAir::fillStackmap):
3008         * b3/B3PatchpointSpecial.cpp:
3009         (JSC::B3::PatchpointSpecial::admitsStack):
3010         * b3/B3StackmapSpecial.cpp:
3011         (JSC::B3::StackmapSpecial::forEachArgImpl):
3012         (JSC::B3::StackmapSpecial::isArgValidForRep):
3013         * b3/B3Validate.cpp:
3014         * b3/B3ValueRep.cpp:
3015         (JSC::B3::ValueRep::addUsedRegistersTo):
3016         (JSC::B3::ValueRep::dump):
3017         (JSC::B3::ValueRep::emitRestore):
3018         (JSC::B3::ValueRep::recoveryForJSValue):
3019         (WTF::printInternal):
3020         * b3/B3ValueRep.h:
3021         (JSC::B3::ValueRep::reg):
3022         (JSC::B3::ValueRep::lateReg):
3023         (JSC::B3::ValueRep::stack):
3024         (JSC::B3::ValueRep::operator==):
3025         (JSC::B3::ValueRep::isSomeRegister):
3026         (JSC::B3::ValueRep::isReg):
3027         * b3/testb3.cpp:
3028         (JSC::B3::testSpillUseLargerThanDef):
3029         (JSC::B3::testLateRegister):
3030         (JSC::B3::zero):
3031         (JSC::B3::run):
3032         * ftl/FTLLowerDFGToB3.cpp:
3033         (JSC::FTL::DFG::LowerDFGToB3::lower):
3034         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
3035         (JSC::FTL::DFG::LowerDFGToB3::getById):
3036         (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
3037         (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
3038         (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
3039
3040 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
3041
3042         Improve error messages for accessing arguments.callee and similar getters in strict mode
3043         https://bugs.webkit.org/show_bug.cgi?id=157545
3044
3045         Reviewed by Mark Lam.
3046
3047         * runtime/ClonedArguments.cpp:
3048         (JSC::ClonedArguments::getOwnPropertySlot):
3049         (JSC::ClonedArguments::materializeSpecials):
3050         Provide better error GetterSetter in strict mode.
3051
3052         * runtime/JSFunction.cpp:
3053         (JSC::getThrowTypeErrorGetterSetter):
3054         (JSC::JSFunction::defineOwnProperty):
3055         Provide better error GetterSetter in strict mode.
3056
3057         * runtime/JSGlobalObject.cpp:
3058         (JSC::JSGlobalObject::init):
3059         (JSC::JSGlobalObject::visitChildren):
3060         * runtime/JSGlobalObject.h:
3061         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
3062         (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter):
3063         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter):
3064         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter):
3065         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): Deleted.
3066         * runtime/JSGlobalObjectFunctions.cpp:
3067         (JSC::globalFuncThrowTypeErrorCalleeAndCaller):
3068         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode):
3069         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext):
3070         (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): Deleted.
3071         * runtime/JSGlobalObjectFunctions.h:
3072         Rename and expose new handles for new error getter setter native functions.
3073
3074 2016-05-11  Commit Queue  <commit-queue@webkit.org>
3075
3076         Unreviewed, rolling out r200481.
3077         https://bugs.webkit.org/show_bug.cgi?id=157573
3078
3079         it's bad news for asm.js (Requested by pizlo on #webkit).
3080
3081         Reverted changeset:
3082
3083         "Reduce maximum JIT pool size on X86_64."
3084         http://trac.webkit.org/changeset/200481
3085
3086 2016-05-10  Keith Miller  <keith_miller@apple.com>
3087
3088         TypedArray.prototype.slice should not use the byteLength of the passed array for memmove
3089         https://bugs.webkit.org/show_bug.cgi?id=157551
3090         <rdar://problem/26179914>
3091
3092         Reviewed by Michael Saboff.
3093
3094         The TypedArray.prototype.slice function would use the byteLength of the passed array
3095         to determine the amount of data to copy. It should have been using the passed length
3096         times the size of each element. This fixes a crash on JavaPoly.com
3097
3098         * runtime/JSGenericTypedArrayViewInlines.h:
3099         (JSC::JSGenericTypedArrayView<Adaptor>::set):
3100         * tests/stress/typedarray-slice.js:
3101
3102 2016-05-10  Michael Saboff  <msaboff@apple.com>
3103
3104         REGRESSION(r200447): Unable to build C_LOOP with clang version 800.0.12 or higher
3105         https://bugs.webkit.org/show_bug.cgi?id=157549
3106
3107         Reviewed by Keith Miller.
3108
3109         Disable debug annotations for C_LOOP builds.  They are inline assembly directives,
3110         unnecessary and they cause syntax errors.
3111
3112         * offlineasm/asm.rb:
3113
3114 2016-05-10  Filip Pizlo  <fpizlo@apple.com>
3115
3116         Internal JSC profiler should have a timestamped log of events for each code block
3117         https://bugs.webkit.org/show_bug.cgi?id=157538
3118
3119         Reviewed by Benjamin Poulain.
3120         
3121         For example, in 3d-cube, I can query the events for MMulti and I get:
3122
3123         1462917476.17083  MMulti#DTZ7qc                          installCode        
3124         1462917476.179663 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
3125         1462917476.179664 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline osrEntry           at bc#49
3126         1462917476.185651 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1011.214233/1717.000000, -707
3127         1462917476.187913 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      installCode        
3128         1462917476.187917 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      osrEntry           at bc#49
3129         1462917476.205365 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      jettison           due to OSRExit, counting = true, detail = (null)
3130         1462917476.205368 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#65: BadCache/FromDFG
3131         1462917476.205369 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
3132         1462917476.205482 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/3434.000000, -1000
3133         1462917476.211547 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/3434.000000, -1000
3134         1462917476.213721 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      installCode        
3135         1462917476.213726 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      osrEntry           at bc#49
3136         1462917476.223976 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      jettison           due to OSRExit, counting = true, detail = (null)
3137         1462917476.223981 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#77: BadCache/FromDFG
3138         1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#94: BadCache/FromDFG
3139         1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
3140         1462917476.224064 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/6868.000000, -1000
3141         1462917476.224151 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/6868.000000, -1000
3142         1462917476.224258 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 3013.000000/6868.000000, -1000
3143         1462917476.224337 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 4023.000000/6868.000000, -1000
3144         1462917476.224425 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 5023.000000/6868.000000, -1000
3145         1462917476.224785 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 6023.396484/6868.000000, -862
3146         1462917476.227669 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      installCode        
3147         1462917476.227675 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      osrEntry           at bc#0
3148         
3149         The output is ugly but useful. We can make it less ugly later.
3150
3151         * CMakeLists.txt:
3152         * JavaScriptCore.xcodeproj/project.pbxproj:
3153         * bytecode/CodeBlock.cpp:
3154         (JSC::CodeBlock::jettison):
3155         * bytecode/CodeBlock.h:
3156         (JSC::ScriptExecutable::forEachCodeBlock):
3157         * bytecode/DFGExitProfile.cpp:
3158         (JSC::DFG::ExitProfile::add):
3159         * dfg/DFGJITFinalizer.cpp:
3160         (JSC::DFG::JITFinalizer::finalizeCommon):
3161         * dfg/DFGOperations.cpp:
3162         * ftl/FTLJITFinalizer.cpp:
3163         (JSC::FTL::JITFinalizer::finalizeFunction):
3164         * jit/JIT.cpp:
3165         (JSC::JIT::privateCompile):
3166         * jit/JITOperations.cpp:
3167         * llint/LLIntSlowPaths.cpp:
3168         (JSC::LLInt::jitCompileAndSetHeuristics):
3169         (JSC::LLInt::entryOSR):
3170         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3171         * profiler/ProfilerCompilation.cpp:
3172         (JSC::Profiler::Compilation::Compilation):
3173         (JSC::Profiler::Compilation::setJettisonReason):
3174         (JSC::Profiler::Compilation::dump):
3175         (JSC::Profiler::Compilation::toJS):
3176         * profiler/ProfilerCompilation.h:
3177         (JSC::Profiler::Compilation::uid):
3178         * profiler/ProfilerDatabase.cpp:
3179         (JSC::Profiler::Database::ensureBytecodesFor):
3180         (JSC::Profiler::Database::notifyDestruction):
3181         (JSC::Profiler::Database::addCompilation):
3182         (JSC::Profiler::Database::toJS):
3183         (JSC::Profiler::Database::registerToSaveAtExit):
3184         (JSC::Profiler::Database::logEvent):
3185         (JSC::Profiler::Database::addDatabaseToAtExit):
3186         * profiler/ProfilerDatabase.h:
3187         * profiler/ProfilerEvent.cpp: Added.
3188         (JSC::Profiler::Event::dump):
3189         (JSC::Profiler::Event::toJS):
3190         * profiler/ProfilerEvent.h: Added.
3191         (JSC::Profiler::Event::Event):
3192         (JSC::Profiler::Event::operator bool):
3193         (JSC::Profiler::Event::time):
3194         (JSC::Profiler::Event::bytecodes):
3195         (JSC::Profiler::Event::compilation):
3196         (JSC::Profiler::Event::summary):
3197         (JSC::Profiler::Event::detail):
3198         * profiler/ProfilerUID.cpp: Added.
3199         (JSC::Profiler::UID::create):
3200         (JSC::Profiler::UID::dump):
3201         (JSC::Profiler::UID::toJS):
3202         * profiler/ProfilerUID.h: Added.
3203         (JSC::Profiler::UID::UID):
3204         (JSC::Profiler::UID::fromInt):
3205         (JSC::Profiler::UID::toInt):
3206         (JSC::Profiler::UID::operator==):
3207         (JSC::Profiler::UID::operator!=):
3208         (JSC::Profiler::UID::operator bool):
3209         (JSC::Profiler::UID::isHashTableDeletedValue):
3210         (JSC::Profiler::UID::hash):
3211         (JSC::Profiler::UIDHash::hash):
3212         (JSC::Profiler::UIDHash::equal):
3213         * runtime/CommonIdentifiers.h:
3214         * runtime/Executable.cpp:
3215         (JSC::ScriptExecutable::installCode):
3216         * runtime/VM.h:
3217         (JSC::VM::bytecodeIntrinsicRegistry):
3218         (JSC::VM::shadowChicken):
3219         * runtime/VMInlines.h:
3220         (JSC::VM::shouldTriggerTermination):
3221         (JSC::VM::logEvent):
3222
3223 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
3224
3225         Web Inspector: Backend should initiate timeline recordings on page navigations to ensure nothing is missed
3226         https://bugs.webkit.org/show_bug.cgi?id=157504
3227         <rdar://problem/26188642>
3228
3229         Reviewed by Brian Burg.
3230
3231         * inspector/protocol/Timeline.json:
3232         Add protocol commands to enable/disable auto capture and list the
3233         instruments that should be enabled when auto capture starts.
3234         Add protocol event for when the backend starts an auto capture.
3235
3236 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
3237
3238         Make the different evaluateWithScopeExtension implementations more consistent
3239         https://bugs.webkit.org/show_bug.cgi?id=157536
3240
3241         Reviewed by Timothy Hatcher.
3242
3243         * inspector/JSInjectedScriptHost.cpp:
3244         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3245         Throw the exception consistent with JSJavaScriptCallFrame.
3246
3247         * inspector/JSJavaScriptCallFrame.cpp:
3248         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3249         Better error message consistent with InjectedScriptHost.
3250
3251         * runtime/Completion.h:
3252         * runtime/Completion.cpp:
3253         (JSC::evaluateWithScopeExtension):
3254         Give this an Exception out parameter like other evaluations
3255         so the caller can decide what to do with it.
3256
3257 2016-05-10  Benjamin Poulain  <bpoulain@apple.com>
3258
3259         [JSC] FTL can produce GetByVal nodes without proper bounds checking
3260         https://bugs.webkit.org/show_bug.cgi?id=157502
3261         rdar://problem/26027027
3262
3263         Reviewed by Filip Pizlo.
3264
3265         It was possible for FTL to generates GetByVal on arbitrary offsets
3266         without any bounds checking.
3267
3268         The bug is caused by the order of optimization phases:
3269         -First, the Integer Range Optimization proves that a CheckInBounds
3270          test can never fail.
3271          This proof is based on control flow or preceeding instructions
3272          inside a loop.
3273         -The Loop Invariant Code Motion phase finds that the GetByVal does not
3274          depend on anything in the loop and hoist it out of the loop.
3275         -> As a result, the conditions that were necessary to eliminate
3276            the CheckInBounds are no longer met before the GetByVal.
3277
3278         This patch just moves the Integer Range Optimization phase after
3279         Loop Invariant Code Motion to make sure no code is moved after
3280         its integer ranges bounds proofs have been used.
3281
3282         * dfg/DFGPlan.cpp:
3283         (JSC::DFG::Plan::compileInThreadImpl):
3284         * tests/stress/bounds-check-not-eliminated-by-licm.js: Added.
3285         (testInLoopTests):
3286
3287 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
3288
3289         Web Inspector: Eliminate the crazy code for evaluateOnCallFrame
3290         https://bugs.webkit.org/show_bug.cgi?id=157510
3291         <rdar://problem/26191332>
3292
3293         Reviewed by Timothy Hatcher.
3294
3295         * debugger/DebuggerCallFrame.cpp:
3296         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
3297         Set and clear an optional scope extension object.
3298
3299         * inspector/InjectedScriptSource.js:
3300         (InjectedScript.prototype.evaluate):
3301         (InjectedScript.prototype._evaluateOn):
3302         (InjectedScript.prototype.evaluateOnCallFrame):
3303         Unify the code to use the passed in evaluate function and object.
3304         When evaluating on a call frame the evaluate function ends up being
3305         DebuggerCallFrame::evaluateWithScopeExtension. When evaluating globally
3306         this ends up being JSInjectedScriptHost::evaluateWithScopeExtension.
3307         In both cases "object" is the preferred this object to use.
3308
3309         * debugger/DebuggerCallFrame.h:
3310         * inspector/JSJavaScriptCallFrame.cpp:
3311         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3312         (Inspector::JSJavaScriptCallFrame::evaluate): Deleted.
3313         * inspector/JSJavaScriptCallFrame.h:
3314         * inspector/JSJavaScriptCallFramePrototype.cpp:
3315         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
3316         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
3317         * inspector/JavaScriptCallFrame.h:
3318         (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
3319         (Inspector::JavaScriptCallFrame::evaluate): Deleted.
3320         Pass through to DebuggerCallFrame with the proper arguments.
3321
3322         * debugger/Debugger.cpp:
3323         (JSC::Debugger::hasBreakpoint):
3324         * inspector/ScriptDebugServer.cpp:
3325         (Inspector::ScriptDebugServer::evaluateBreakpointAction):