Allow one sync GC per gcTimer interval on critical memory pressure warning
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-06-09  Chris Dumez  <cdumez@apple.com>
2
3         Allow one sync GC per gcTimer interval on critical memory pressure warning
4         https://bugs.webkit.org/show_bug.cgi?id=145773
5
6         Reviewed by Geoffrey Garen.
7
8         On critical memory pressure warning, we were calling GCController::garbageCollectSoon(),
9         which does not offer any guarantee on when the garbage collection will actually take
10         place.
11
12         On critical memory pressure, we need to free up memory as soon as possible to avoid
13         getting killed so this is an issue. Also, the fact that we clear the PageCache on
14         critical memory pressure means a GC would likely be useful, even if the last
15         collection did not free much memory.
16
17         This patch adds a new GCController::garbageCollectNowIfNotDoneRecently() API that allows
18         one synchronous GC per gcTimer interval on critical memory pressure warning. This makes
19         us more responsive to critical memory pressure and avoids doing synchronous GCs too
20         often.
21
22         * heap/FullGCActivityCallback.cpp:
23         (JSC::FullGCActivityCallback::doCollection):
24         * heap/FullGCActivityCallback.h:
25         (JSC::GCActivityCallback::createFullTimer):
26         * heap/GCActivityCallback.h:
27         * heap/Heap.cpp:
28         (JSC::Heap::collectAllGarbageIfNotDoneRecently):
29         * heap/Heap.h:
30
31         * heap/IncrementalSweeper.cpp:
32         (JSC::IncrementalSweeper::doWork): Deleted.
33         * heap/IncrementalSweeper.h:
34
35         Drop fullSweep() API as it no longer seems useful. garbageCollectNow()
36         already does a sweep after the full collection.
37
38 2015-06-09  Andreas Kling  <akling@apple.com>
39
40         [JSC] CodeBlock::m_constantRegisters should be sized-to-fit.
41         <https://webkit.org/b/145784>
42
43         Reviewed by Darin Adler.
44
45         Spotted this Vector looking chubby on cnet.com, with 1.23 MB of memory
46         allocated below CodeBlock::setConstantRegisters().
47
48         Use resizeToFit() instead since we know the final size up front.
49         Also removed some unused functions that operated on this constants vector
50         and the corresponding one in UnlinkedCodeBlock.
51
52         * bytecode/CodeBlock.cpp:
53         (JSC::CodeBlock::addOrFindConstant): Deleted.
54         (JSC::CodeBlock::findConstant): Deleted.
55         * bytecode/CodeBlock.h:
56         (JSC::CodeBlock::setConstantRegisters):
57         (JSC::CodeBlock::numberOfConstantRegisters): Deleted.
58         * bytecode/UnlinkedCodeBlock.cpp:
59         (JSC::UnlinkedCodeBlock::addOrFindConstant): Deleted.
60         * bytecode/UnlinkedCodeBlock.h:
61         (JSC::UnlinkedCodeBlock::numberOfConstantRegisters): Deleted.
62         (JSC::UnlinkedCodeBlock::getConstant): Deleted.
63
64 2015-06-09  Andreas Kling  <akling@apple.com>
65
66         [JSC] Polymorphic{Get,Put}ByIdList::addAccess() should optimize for size, not speed.
67         <https://webkit.org/b/145786>
68
69         Reviewed by Darin Adler.
70
71         These functions already contained comments saying they optimize for size over speed,
72         but they were using Vector::resize() which adds the usual slack for faster append().
73
74         Switch them over to using Vector::resizeToFit() instead, which makes the Vector
75         allocate a perfectly sized backing store.
76
77         Spotted 670 kB of the GetById ones, and 165 kB of PutById on cnet.com, so these
78         Vectors are definitely worth shrink-wrapping.
79
80         * bytecode/PolymorphicGetByIdList.cpp:
81         (JSC::PolymorphicGetByIdList::addAccess):
82         * bytecode/PolymorphicPutByIdList.cpp:
83         (JSC::PolymorphicPutByIdList::addAccess):
84
85 2015-06-09  Andreas Kling  <akling@apple.com>
86
87         [JSC] JSPropertyNameEnumerator's property name vector should be sized-to-fit.
88         <https://webkit.org/b/145787>
89
90         Reviewed by Darin Adler.
91
92         Saw 108 kB worth of JSPropertyNameEnumerator backing store Vectors on cnet.com.
93         Use Vector::resizeToFit() since we know the perfect size up front.
94
95         * runtime/JSPropertyNameEnumerator.cpp:
96         (JSC::JSPropertyNameEnumerator::finishCreation):
97
98 2015-06-09  Andreas Kling  <akling@apple.com>
99
100         FunctionExecutable::isCompiling() is weird and wrong.
101         <https://webkit.org/b/145689>
102
103         Reviewed by Geoffrey Garen.
104
105         Remove FunctionExecutable::isCompiling() and the clearCodeIfNotCompiling() style
106         functions that called it before throwing away code.
107
108         isCompiling() would consider the executable to be "compiling" if it had a CodeBlock
109         but no JITCode. In practice, every executable gets a JITCode at the same time as it
110         gets a CodeBlock, by way of prepareForExecutionImpl().
111
112         * debugger/Debugger.cpp:
113         * heap/Heap.cpp:
114         (JSC::Heap::deleteAllCompiledCode):
115         (JSC::Heap::deleteAllUnlinkedFunctionCode):
116         * inspector/agents/InspectorRuntimeAgent.cpp:
117         (Inspector::TypeRecompiler::visit):
118         * runtime/Executable.cpp:
119         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
120         (JSC::FunctionExecutable::clearCodeIfNotCompiling): Deleted.
121         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling): Deleted.
122         * runtime/Executable.h:
123         * runtime/VM.cpp:
124         (JSC::StackPreservingRecompiler::visit):
125
126 2015-06-09  Yusuke Suzuki  <utatane.tea@gmail.com>
127
128         Introduce getter definition into static hash tables and use it for getters in RegExp.prototype.
129         https://bugs.webkit.org/show_bug.cgi?id=145705
130
131         Reviewed by Darin Adler.
132
133         In this patch, we introduce Accessor type into property tables.
134         With Accessor type, create_hash_table creates a static getter property.
135         This getter property is reified as the same to the static functions.
136
137         In the mean time, we only support getter because `putEntry` and `lookupPut`
138         only work with null setter currently. However, in the spec, there's
139         no need to add static setter properties. So we will add it if it becomes
140         necessary in the future.
141
142         And at the same time, this patch fixes the issue 145738. Before this patch,
143         `putEntry` in `JSObject::deleteProperty` adds `undefined` property if
144         `isValidOffset(...)` is false (deleted). As the result, deleting twice
145         revives the property with `undefined` value.
146
147         If the static functions are reified and the entry is
148         `BuiltinOrFunctionOrAccessor`, there's no need to execute `putEntry` with
149         static hash table entry. They should be handled in the normal structure's
150         looking up because they should be already reified. So added guard for this.
151
152         * CMakeLists.txt:
153         * DerivedSources.make:
154         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
155         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
156         * JavaScriptCore.xcodeproj/project.pbxproj:
157         * create_hash_table:
158         * runtime/JSObject.cpp:
159         (JSC::getClassPropertyNames):
160         (JSC::JSObject::put):
161         (JSC::JSObject::deleteProperty):
162         (JSC::JSObject::reifyStaticFunctionsForDelete):
163         * runtime/Lookup.cpp:
164         (JSC::reifyStaticAccessor):
165         (JSC::setUpStaticFunctionSlot):
166         * runtime/Lookup.h:
167         (JSC::HashTableValue::propertyGetter):
168         (JSC::HashTableValue::propertyPutter):
169         (JSC::HashTableValue::accessorGetter):
170         (JSC::HashTableValue::accessorSetter):
171         (JSC::getStaticPropertySlot):
172         (JSC::getStaticValueSlot):
173         (JSC::putEntry):
174         (JSC::reifyStaticProperties):
175         * runtime/PropertySlot.h:
176         * runtime/RegExpObject.cpp:
177         (JSC::RegExpObject::getOwnPropertySlot):
178         (JSC::regExpObjectGlobal): Deleted.
179         (JSC::regExpObjectIgnoreCase): Deleted.
180         (JSC::regExpObjectMultiline): Deleted.
181         (JSC::appendLineTerminatorEscape<LChar>): Deleted.
182         (JSC::appendLineTerminatorEscape<UChar>): Deleted.
183         (JSC::regExpObjectSourceInternal): Deleted.
184         (JSC::regExpObjectSource): Deleted.
185         * runtime/RegExpPrototype.cpp:
186         (JSC::RegExpPrototype::getOwnPropertySlot):
187         (JSC::regExpProtoGetterGlobal):
188         (JSC::regExpProtoGetterIgnoreCase):
189         (JSC::regExpProtoGetterMultiline):
190         (JSC::appendLineTerminatorEscape<LChar>):
191         (JSC::appendLineTerminatorEscape<UChar>):
192         (JSC::regExpProtoGetterSourceInternal):
193         (JSC::regExpProtoGetterSource):
194         * tests/stress/static-function-delete.js: Added.
195         (shouldBe):
196         * tests/stress/static-function-put.js: Added.
197         (shouldBe):
198         * tests/stress/static-getter-delete.js: Added.
199         (shouldBe):
200         (shouldThrow):
201         * tests/stress/static-getter-descriptors.js: Added.
202         (shouldBe):
203         * tests/stress/static-getter-enumeration.js: Added.
204         (shouldBe):
205         * tests/stress/static-getter-get.js: Added.
206         (shouldBe):
207         * tests/stress/static-getter-in-names.js: Added.
208         (shouldBe):
209         * tests/stress/static-getter-names.js: Added.
210         (shouldBe):
211         * tests/stress/static-getter-put.js: Added.
212         (shouldBe):
213         (shouldThrow):
214
215 2015-06-09  Andreas Kling  <akling@apple.com>
216
217         [JSC] JSString::getIndex() should avoid reifying substrings.
218         <https://webkit.org/b/145803>
219
220         Reviewed by Darin Adler.
221
222         Implement getIndex() using JSString::view(), which cuts it down to a one-liner
223         and also avoids reifying substrings.
224
225         I saw 178 kB of reified substrings below operationGetByVal -> getIndex()
226         on cnet.com, so this should help.
227
228         * runtime/JSString.cpp:
229         (JSC::JSRopeString::getIndexSlowCase): Deleted.
230         * runtime/JSString.h:
231         (JSC::JSString::getIndex):
232
233 2015-06-09  Andreas Kling  <akling@apple.com>
234
235         [JSC] String.prototype.indexOf() should use StringView.
236         <https://webkit.org/b/145351>
237
238         Reviewed by Darin Adler.
239
240         Use StringView::find() to implement String.prototype.indexOf().
241         This avoids reifying the needle and haystack JSStrings in case they
242         are substrings.
243
244         Reduces malloc memory by ~190 kB on cnet.com.
245
246         * runtime/StringPrototype.cpp:
247         (JSC::stringProtoFuncIndexOf):
248
249 2015-06-09  Csaba Osztrogonác  <ossy@webkit.org>
250
251         [cmake] Fix the style issues in cmake project files
252         https://bugs.webkit.org/show_bug.cgi?id=145755
253
254         Reviewed by Darin Adler.
255
256         * CMakeLists.txt:
257
258 2015-06-08  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
259
260         Purge PassRefPtr in JavaScriptCore
261         https://bugs.webkit.org/show_bug.cgi?id=145750
262
263         As a step to purge PassRefPtr, this patch replaces PassRefPtr with Ref or RefPtr.
264
265         Reviewed by Darin Adler.
266
267         * API/JSClassRef.cpp:
268         (OpaqueJSClass::createNoAutomaticPrototype):
269         * API/JSClassRef.h:
270         * API/JSContextRef.cpp:
271         * API/JSScriptRef.cpp:
272         (OpaqueJSScript::create):
273         * API/JSStringRef.cpp:
274         (JSStringCreateWithCharacters):
275         (JSStringCreateWithUTF8CString):
276         * API/OpaqueJSString.cpp:
277         (OpaqueJSString::create):
278         * API/OpaqueJSString.h:
279         (OpaqueJSString::create):
280         * bytecompiler/StaticPropertyAnalysis.h:
281         (JSC::StaticPropertyAnalysis::create):
282         * debugger/DebuggerCallFrame.h:
283         (JSC::DebuggerCallFrame::create):
284         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
285         (JSC::DFG::ToFTLDeferredCompilationCallback::create):
286         * dfg/DFGToFTLDeferredCompilationCallback.h:
287         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
288         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
289         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create): Deleted.
290         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
291         * dfg/DFGWorklist.cpp:
292         (JSC::DFG::Worklist::create):
293         (JSC::DFG::ensureGlobalDFGWorklist):
294         (JSC::DFG::ensureGlobalFTLWorklist):
295         * dfg/DFGWorklist.h:
296         * heap/EdenGCActivityCallback.h:
297         (JSC::GCActivityCallback::createEdenTimer):
298         * heap/FullGCActivityCallback.h:
299         (JSC::GCActivityCallback::createFullTimer):
300         * heap/GCActivityCallback.h:
301         * inspector/InjectedScriptHost.h:
302         * inspector/JavaScriptCallFrame.h:
303         (Inspector::JavaScriptCallFrame::create):
304         * inspector/ScriptArguments.cpp:
305         (Inspector::ScriptArguments::create):
306         * inspector/ScriptArguments.h:
307         * jit/JITStubRoutine.h:
308         (JSC::JITStubRoutine::createSelfManagedRoutine):
309         * jit/JITToDFGDeferredCompilationCallback.cpp:
310         (JSC::JITToDFGDeferredCompilationCallback::create):
311         * jit/JITToDFGDeferredCompilationCallback.h:
312         * jsc.cpp:
313         (jscmain):
314         * parser/NodeConstructors.h:
315         (JSC::ArrayPatternNode::create):
316         (JSC::ObjectPatternNode::create):
317         (JSC::BindingNode::create):
318         * parser/Nodes.cpp:
319         (JSC::FunctionParameters::create):
320         * parser/Nodes.h:
321         * parser/SourceProvider.h:
322         (JSC::StringSourceProvider::create):
323         * profiler/Profile.cpp:
324         (JSC::Profile::create):
325         * profiler/Profile.h:
326         * profiler/ProfileGenerator.cpp:
327         (JSC::ProfileGenerator::create):
328         * profiler/ProfileGenerator.h:
329         * profiler/ProfileNode.h:
330         (JSC::ProfileNode::create):
331         * runtime/DataView.cpp:
332         (JSC::DataView::create):
333         * runtime/DataView.h:
334         * runtime/DateInstanceCache.h:
335         (JSC::DateInstanceData::create):
336         * runtime/JSPromiseReaction.cpp:
337         (JSC::createExecutePromiseReactionMicrotask):
338         * runtime/JSPromiseReaction.h:
339         * runtime/PropertyNameArray.h:
340         (JSC::PropertyNameArrayData::create):
341         * runtime/TypeSet.h:
342         (JSC::StructureShape::create):
343         (JSC::TypeSet::create):
344         * runtime/TypedArrayBase.h:
345         (JSC::TypedArrayBase::create):
346         (JSC::TypedArrayBase::createUninitialized):
347         (JSC::TypedArrayBase::subarrayImpl):
348         * runtime/VM.cpp:
349         (JSC::VM::createContextGroup):
350         (JSC::VM::create):
351         (JSC::VM::createLeaked):
352         * runtime/VM.h:
353         * yarr/RegularExpression.cpp:
354         (JSC::Yarr::RegularExpression::Private::create):
355
356 2015-06-08  Filip Pizlo  <fpizlo@apple.com>
357
358         It should be possible to hoist all constants in DFG SSA
359         https://bugs.webkit.org/show_bug.cgi?id=145769
360
361         Reviewed by Geoffrey Garen.
362         
363         It's sometimes somewhat more efficient, and convenient, to have all constants at the
364         top of the root block. We don't require this as an IR invariant because too many phases
365         want to be able to insert constants in weird places. But, this phase will be great for
366         preparing for https://bugs.webkit.org/show_bug.cgi?id=145768.
367
368         * CMakeLists.txt:
369         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
370         * JavaScriptCore.xcodeproj/project.pbxproj:
371         * dfg/DFGConstantHoistingPhase.cpp: Added.
372         (JSC::DFG::performConstantHoisting):
373         * dfg/DFGConstantHoistingPhase.h: Added.
374         * dfg/DFGPlan.cpp:
375         (JSC::DFG::Plan::compileInThreadImpl):
376
377 2015-06-07  Filip Pizlo  <fpizlo@apple.com>
378
379         The tiny set magic in StructureSet should be available in WTF
380         https://bugs.webkit.org/show_bug.cgi?id=145722
381
382         Reviewed by Geoffrey Garen.
383         
384         I moved the generic logic of small sets of pointers and moved it into WTF. Now,
385         StructureSet is a subclass of TinyPtrSet<Structure*>. There shouldn't be any functional
386         change.
387
388         * bytecode/StructureSet.cpp:
389         (JSC::StructureSet::filter):
390         (JSC::StructureSet::filterArrayModes):
391         (JSC::StructureSet::speculationFromStructures):
392         (JSC::StructureSet::arrayModesFromStructures):
393         (JSC::StructureSet::dumpInContext):
394         (JSC::StructureSet::dump):
395         (JSC::StructureSet::clear): Deleted.
396         (JSC::StructureSet::add): Deleted.
397         (JSC::StructureSet::remove): Deleted.
398         (JSC::StructureSet::contains): Deleted.
399         (JSC::StructureSet::merge): Deleted.
400         (JSC::StructureSet::exclude): Deleted.
401         (JSC::StructureSet::isSubsetOf): Deleted.
402         (JSC::StructureSet::overlaps): Deleted.
403         (JSC::StructureSet::operator==): Deleted.
404         (JSC::StructureSet::addOutOfLine): Deleted.
405         (JSC::StructureSet::containsOutOfLine): Deleted.
406         (JSC::StructureSet::copyFromOutOfLine): Deleted.
407         (JSC::StructureSet::OutOfLineList::create): Deleted.
408         (JSC::StructureSet::OutOfLineList::destroy): Deleted.
409         * bytecode/StructureSet.h:
410         (JSC::StructureSet::onlyStructure):
411         (JSC::StructureSet::StructureSet): Deleted.
412         (JSC::StructureSet::operator=): Deleted.
413         (JSC::StructureSet::~StructureSet): Deleted.
414         (JSC::StructureSet::isEmpty): Deleted.
415         (JSC::StructureSet::genericFilter): Deleted.
416         (JSC::StructureSet::isSupersetOf): Deleted.
417         (JSC::StructureSet::size): Deleted.
418         (JSC::StructureSet::at): Deleted.
419         (JSC::StructureSet::operator[]): Deleted.
420         (JSC::StructureSet::last): Deleted.
421         (JSC::StructureSet::iterator::iterator): Deleted.
422         (JSC::StructureSet::iterator::operator*): Deleted.
423         (JSC::StructureSet::iterator::operator++): Deleted.
424         (JSC::StructureSet::iterator::operator==): Deleted.
425         (JSC::StructureSet::iterator::operator!=): Deleted.
426         (JSC::StructureSet::begin): Deleted.
427         (JSC::StructureSet::end): Deleted.
428         (JSC::StructureSet::ContainsOutOfLine::ContainsOutOfLine): Deleted.
429         (JSC::StructureSet::ContainsOutOfLine::operator()): Deleted.
430         (JSC::StructureSet::copyFrom): Deleted.
431         (JSC::StructureSet::OutOfLineList::list): Deleted.
432         (JSC::StructureSet::OutOfLineList::OutOfLineList): Deleted.
433         (JSC::StructureSet::deleteStructureListIfNecessary): Deleted.
434         (JSC::StructureSet::isThin): Deleted.
435         (JSC::StructureSet::pointer): Deleted.
436         (JSC::StructureSet::singleStructure): Deleted.
437         (JSC::StructureSet::structureList): Deleted.
438         (JSC::StructureSet::set): Deleted.
439         (JSC::StructureSet::setEmpty): Deleted.
440         (JSC::StructureSet::getReservedFlag): Deleted.
441         (JSC::StructureSet::setReservedFlag): Deleted.
442         * dfg/DFGStructureAbstractValue.cpp:
443         (JSC::DFG::StructureAbstractValue::clobber):
444         (JSC::DFG::StructureAbstractValue::filter):
445         (JSC::DFG::StructureAbstractValue::filterSlow):
446         (JSC::DFG::StructureAbstractValue::contains):
447         * dfg/DFGStructureAbstractValue.h:
448         (JSC::DFG::StructureAbstractValue::makeTop):
449
450 2015-06-08  Csaba Osztrogonác  <ossy@webkit.org>
451
452         [ARM] Add the missing setupArgumentsWithExecState functions after r185240
453         https://bugs.webkit.org/show_bug.cgi?id=145754
454
455         Reviewed by Benjamin Poulain.
456
457         * jit/CCallHelpers.h:
458         (JSC::CCallHelpers::setupArgumentsWithExecState):
459
460 2015-06-08  Brady Eidson  <beidson@apple.com>
461
462         Completely remove all IDB properties/constructors when it is disabled at runtime.
463         rdar://problem/18429374 and https://bugs.webkit.org/show_bug.cgi?id=137034
464
465         Reviewed by Geoffrey Garen.
466
467         * runtime/CommonIdentifiers.h:
468
469 2015-06-06  Mark Lam  <mark.lam@apple.com>
470
471         Returned Exception* values need to be initialized to nullptr when no exceptions are thrown.
472         https://bugs.webkit.org/show_bug.cgi?id=145720
473
474         Reviewed by Dan Bernstein.
475
476         * debugger/DebuggerCallFrame.cpp:
477         (JSC::DebuggerCallFrame::evaluate):
478
479 2015-06-05  Mark Lam  <mark.lam@apple.com>
480
481         Subclasses of JSNonFinalObject with gc'able children need to implement visitChildren().
482         https://bugs.webkit.org/show_bug.cgi?id=145709
483
484         Reviewed by Geoffrey Garen.
485
486         * jsc.cpp:
487         (functionSetElementRoot):
488         - The Element class has a member of type Root which extends JSDestructibleObject.
489           It should be stored in a WriteBarrier, and visited by visitChildren().  
490
491         * runtime/ClonedArguments.cpp:
492         (JSC::ClonedArguments::materializeSpecialsIfNecessary):
493         (JSC::ClonedArguments::visitChildren):
494         * runtime/ClonedArguments.h:
495         - Add missing visitChildren().
496
497         * tests/stress/cloned-arguments-should-visit-callee-during-gc.js: Added.
498         (makeTransientFunction.transientFunc):
499         (makeTransientFunction):
500
501 2015-06-05  Geoffrey Garen  <ggaren@apple.com>
502
503         DropAllLocks RELEASE_ASSERT on iOS
504         https://bugs.webkit.org/show_bug.cgi?id=139654
505
506         Reviewed by Mark Lam.
507
508         * runtime/JSLock.cpp:
509         (JSC::JSLock::dropAllLocks): Removed a comment because it duplicated
510         the code beneath it. Removed a FIXME because we can't ASSERT that
511         we're holding the lock. WebKit1 on iOS drops the lock before calling to
512         delegates, not knowing whether it holds the lock or not.
513
514         (JSC::JSLock::DropAllLocks::DropAllLocks): Only ASSERT that we are not
515         GC'ing if we hold the lock. If we do not hold the lock, it is perfectly
516         valid for some other thread, which does hold the lock, to be GC'ing.
517         What is not valid is to drop the lock in the middle of GC, since GC
518         must be atomic.
519
520 2015-06-05  Filip Pizlo  <fpizlo@apple.com>
521
522         speculateRealNumber() should early exit if you're already a real number, not if you're already a real double.
523
524         Rubber stamped by Mark Lam.
525         
526         This was causing: https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r185261%20(5180)/webaudio/note-grain-on-timing-crash-log.txt
527
528         * dfg/DFGSpeculativeJIT.cpp:
529         (JSC::DFG::SpeculativeJIT::speculateRealNumber):
530
531 2015-06-05  Mark Lam  <mark.lam@apple.com>
532
533         finally blocks should not set the exception stack trace when re-throwing the exception.
534         https://bugs.webkit.org/show_bug.cgi?id=145525
535
536         Reviewed by Geoffrey Garen.
537
538         How exceptions presently work:
539         =============================
540         1. op_throw can throw any JSValue.
541         2. the VM tries to capture the stack at the throw point and propagate that as needed.
542         3. finally blocks are implemented using op_catch to catch the thrown value, and throws it again using op_throw.
543
544         What's wrong with how it presently works:
545         ========================================
546         1. finally's makes for bad exception throw line numbers in the Inspector console.
547
548            The op_throw in finally will throw the value anew i.e. it captures a stack from the re-throw point.
549            As a result, the Inspector sees the finally block as the throw point.  The original stack is lost.
550
551         2. finally's breaks the Inspector's "Breaks on Uncaught Exception"
552
553            This is because finally blocks are indistinguishable from catch blocks.  As a result, a try-finally,
554            which should break in the Inspector on the throw, does not because the Inspector thought the
555            exception was "caught".
556
557         3. finally's yields confusing break points when the Inspector "Breaks on All Exceptions"
558
559            a. In a try-finally scenario, the Inspector breaks 2 times: 1 at the throw, 1 at the finally.
560            b. In a for-of loop (which has synthesized finallys), the Inspector will do another break.
561               Similarly for other cases of JS code which synthesize finallys.
562            c. At VM re-entry boundaries (e.g. js throws & returns to native code, which returns to js),
563               the Inspector will do another break if there's an uncaught exception.
564
565         How this patch fixes the issues:
566         ===============================
567         1. We introduce an Exception object that wraps the thrown value and the exception stack.
568
569            When throwing an exception, the VM will check if the thrown value is an Exception
570            object or not.  If it is not an Exception object, then we must be throwing a new
571            exception.  The VM will create an Exception object to wrap the thrown value and
572            capture the current stack for it.
573
574            If the thrown value is already an Exception object, then the requested throw operation
575            must be a re-throw.  The VM will not capture a new stack for it.
576
577         2. op_catch will now populate 2 locals: 1 for the Exception, 1 for the thrown JSValue.
578
579            The VM is aware of the Exception object and uses it for rethrows in finally blocks.
580            JS source code is never aware of the Exception object.
581
582            JS code is aware of the thrown value.  If it throws the caught thrown value, that
583            constitutes a new throw, and a new Exception object will be created for it.
584
585         3. The VM no longer tracks the thrown JSValue and the exception stack.  It will only
586            track a m_exception field which is an Exception*.
587
588         4. The BytecodeGenerator has already been updated in a prior patch to distinguish
589            between Catch, Finally, and SynthesizedFinally blocks.  The interpreter runtime will
590            now report to the debugger whether we have a Catch handler, not just any handlers.
591
592            The debugger will use this detail to determine whether to break or not.  "Break on
593            uncaught exceptions" will only break if no Catch handler was found.
594
595            This solves the issue of the debugger breaking at finally blocks, and for-of statements.
596
597         5. The Exception object will also have a flag to indicate whether the debugger has been
598            notified of the Exception being thrown.  Once the Interpreter notifies the debugger
599            of the Exception object, it will mark this flag and not repeat the notify the debugger
600            again of the same Exception.
601
602            This solves the issue of the debugger breaking at VM re-entry points due to uncaught
603            exceptions.
604
605         6. The life-cycle of the captured exception stack trace will now follow the life-cycle
606            of the Exception object.
607
608         Other changes:
609         7. Change all clients of the VM::exception() to expect an Exception* instead of JSValue.
610
611         8. Fixed a few bugs where thrown exceptions are not cleared before exiting the VM.
612
613         9. Also renamed some variables and classes to better describe what they are.
614
615         * API/JSBase.cpp:
616         (JSEvaluateScript):
617         (JSCheckScriptSyntax):
618
619         * API/JSObjectRef.cpp:
620         (handleExceptionIfNeeded):
621         - The functions below all do the same exception check.  Added this helper
622           to simplify the code.
623         (JSClassCreate):
624         (JSObjectMakeFunction):
625         (JSObjectMakeArray):
626         (JSObjectMakeDate):
627         (JSObjectMakeError):
628         (JSObjectMakeRegExp):
629         (JSObjectGetProperty):
630         (JSObjectSetProperty):
631         (JSObjectGetPropertyAtIndex):
632         (JSObjectSetPropertyAtIndex):
633         (JSObjectDeleteProperty):
634         (JSObjectCallAsFunction):
635         (JSObjectCallAsConstructor):
636
637         * API/JSScriptRef.cpp:
638         * API/JSValue.mm:
639         (JSContainerConvertor::take):
640         (reportExceptionToInspector):
641
642         * API/JSValueRef.cpp:
643         (handleExceptionIfNeeded):
644         - The functions below all do the same exception check.  Added this helper
645           to simplify the code.
646         (evernoteHackNeeded):
647         (JSValueIsEqual):
648         (JSValueIsInstanceOfConstructor):
649         (JSValueCreateJSONString):
650         (JSValueToNumber):
651         (JSValueToStringCopy):
652         (JSValueToObject):
653
654         * CMakeLists.txt:
655         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
656         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
657         * JavaScriptCore.xcodeproj/project.pbxproj:
658         - Added new files Exception.h and Exception.cpp.
659
660         * bindings/ScriptFunctionCall.cpp:
661         (Deprecated::ScriptFunctionCall::call):
662         * bindings/ScriptFunctionCall.h:
663
664         * bytecode/BytecodeList.json:
665         - op_catch now had 2 operands: the exception register, and the thrown value register.
666
667         * bytecode/BytecodeUseDef.h:
668         (JSC::computeDefsForBytecodeOffset):
669         * bytecode/CodeBlock.cpp:
670         (JSC::CodeBlock::dumpBytecode):
671         (JSC::CodeBlock::handlerForBytecodeOffset):
672         * bytecode/CodeBlock.h:
673         - handlerForBytecodeOffset() now can look for just Catch handlers only.
674
675         * bytecode/HandlerInfo.h:
676         - Cleaned up some white space I accidentally added in a previous patch.
677
678         * bytecompiler/BytecodeGenerator.cpp:
679         (JSC::BytecodeGenerator::pushTry):
680         (JSC::BytecodeGenerator::popTryAndEmitCatch):
681         (JSC::BytecodeGenerator::emitThrowReferenceError):
682         (JSC::BytecodeGenerator::emitEnumeration):
683         * bytecompiler/BytecodeGenerator.h:
684         (JSC::BytecodeGenerator::emitThrow):
685         * bytecompiler/NodesCodegen.cpp:
686         (JSC::TryNode::emitBytecode):
687         - Adding support for op_catch's 2 operands.
688
689         * debugger/Debugger.cpp:
690         (JSC::Debugger::hasBreakpoint):
691         (JSC::Debugger::pauseIfNeeded):
692         (JSC::Debugger::exception):
693         * debugger/Debugger.h:
694         * debugger/DebuggerCallFrame.cpp:
695         (JSC::DebuggerCallFrame::thisValue):
696         (JSC::DebuggerCallFrame::evaluate):
697         * debugger/DebuggerCallFrame.h:
698         (JSC::DebuggerCallFrame::isValid):
699         * inspector/InjectedScriptManager.cpp:
700         (Inspector::InjectedScriptManager::createInjectedScript):
701         * inspector/InspectorEnvironment.h:
702         * inspector/JSGlobalObjectInspectorController.cpp:
703         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
704         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
705         * inspector/JSGlobalObjectInspectorController.h:
706         * inspector/JSGlobalObjectScriptDebugServer.h:
707         * inspector/JSJavaScriptCallFrame.cpp:
708         (Inspector::JSJavaScriptCallFrame::evaluate):
709         * inspector/JavaScriptCallFrame.h:
710         (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
711         (Inspector::JavaScriptCallFrame::thisValue):
712         (Inspector::JavaScriptCallFrame::evaluate):
713         * inspector/ScriptCallStackFactory.cpp:
714         (Inspector::extractSourceInformationFromException):
715         (Inspector::createScriptCallStackFromException):
716         * inspector/ScriptCallStackFactory.h:
717         * inspector/ScriptDebugServer.cpp:
718         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
719         (Inspector::ScriptDebugServer::handleBreakpointHit):
720         (Inspector::ScriptDebugServer::handleExceptionInBreakpointCondition):
721         * inspector/ScriptDebugServer.h:
722         * interpreter/CallFrame.h:
723         (JSC::ExecState::clearException):
724         (JSC::ExecState::exception):
725         (JSC::ExecState::hadException):
726         (JSC::ExecState::atomicStringTable):
727         (JSC::ExecState::propertyNames):
728         (JSC::ExecState::clearSupplementaryExceptionInfo): Deleted.
729
730         * interpreter/Interpreter.cpp:
731         (JSC::unwindCallFrame):
732         (JSC::Interpreter::stackTraceAsString):
733         (JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
734         (JSC::GetCatchHandlerFunctor::operator()):
735         (JSC::Interpreter::unwind):
736         - Added a check for didNotifyInspectorOfThrow() here to prevent duplicate reports
737           of the same Exception to the debugger.
738
739         (JSC::GetExceptionHandlerFunctor::GetExceptionHandlerFunctor): Deleted.
740         (JSC::GetExceptionHandlerFunctor::operator()): Deleted.
741         - Renamed GetExceptionHandlerFunctor to GetCatchHandlerFunctor since the debugger
742           is only interested in knowing whether we have Catch handlers.
743
744         * interpreter/Interpreter.h:
745         (JSC::SuspendExceptionScope::SuspendExceptionScope):
746         (JSC::SuspendExceptionScope::~SuspendExceptionScope):
747         (JSC::Interpreter::sampler):
748         (JSC::ClearExceptionScope::ClearExceptionScope): Deleted.
749         (JSC::ClearExceptionScope::~ClearExceptionScope): Deleted.
750         - Renamed ClearExceptionScope to SuspendExceptionScope because "clear" implies that
751           we're purging the exception.  Instead, we're merely suspending any handling of
752           that exception for a period defined by the scope.
753
754         * jit/AssemblyHelpers.cpp:
755         (JSC::AssemblyHelpers::emitExceptionCheck):
756
757         * jit/JITExceptions.cpp:
758         (JSC::genericUnwind):
759         - Removed the exception argument.  It is always the value in VM::exception() anyway.
760           genericUnwind() can just get it from the VM, and save everyone some work.
761
762         * jit/JITExceptions.h:
763         * jit/JITOpcodes.cpp:
764         (JSC::JIT::emit_op_catch):
765         * jit/JITOpcodes32_64.cpp:
766         (JSC::JIT::privateCompileCTINativeCall):
767         (JSC::JIT::emit_op_catch):
768         - Add support for the new op_catch operands.
769
770         * jit/JITOperations.cpp:
771         * jit/ThunkGenerators.cpp:
772         (JSC::nativeForGenerator):
773         * jsc.cpp:
774         (functionRun):
775         (functionLoad):
776         (runWithScripts):
777         (runInteractive):
778         * llint/LLIntOffsetsExtractor.cpp:
779         * llint/LLIntSlowPaths.cpp:
780         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
781
782         * llint/LowLevelInterpreter32_64.asm:
783         * llint/LowLevelInterpreter64.asm:
784         - Add support for the new op_catch operands.  Also update the code to handle
785           VM::m_exception being an Exception pointer, not a JSValue.
786
787         * parser/NodeConstructors.h:
788         (JSC::TryNode::TryNode):
789         * parser/Nodes.h:
790         * runtime/CallData.cpp:
791         (JSC::call):
792         * runtime/CallData.h:
793
794         * runtime/Completion.cpp:
795         (JSC::evaluate):
796         * runtime/Completion.h:
797         (JSC::evaluate):
798         - Change evaluate() to take a reference to the returned exception value instead
799           of a pointer.  In all but 2 or 3 cases, we want the returned exception anyway.
800           Might as well simplify the code by requiring the reference.
801
802         * runtime/Error.h:
803         (JSC::throwVMError):
804         (JSC::throwVMTypeError):
805
806         * runtime/Exception.cpp: Added.
807         (JSC::Exception::create):
808         (JSC::Exception::destroy):
809         (JSC::Exception::createStructure):
810         (JSC::Exception::visitChildren):
811         (JSC::Exception::Exception):
812         (JSC::Exception::~Exception):
813         * runtime/Exception.h: Added.
814         (JSC::Exception::valueOffset):
815         (JSC::Exception::cast):
816         (JSC::Exception::value):
817         (JSC::Exception::stack):
818         (JSC::Exception::didNotifyInspectorOfThrow):
819         (JSC::Exception::setDidNotifyInspectorOfThrow):
820
821         * runtime/ExceptionHelpers.cpp:
822         (JSC::createTerminatedExecutionException):
823         (JSC::isTerminatedExecutionException):
824         (JSC::createStackOverflowError):
825         * runtime/ExceptionHelpers.h:
826         * runtime/GetterSetter.cpp:
827         (JSC::callGetter):
828         * runtime/IteratorOperations.cpp:
829         (JSC::iteratorClose):
830         * runtime/JSObject.cpp:
831         * runtime/JSPromiseConstructor.cpp:
832         (JSC::constructPromise):
833         * runtime/JSPromiseDeferred.cpp:
834         (JSC::updateDeferredFromPotentialThenable):
835         (JSC::abruptRejection):
836         * runtime/JSPromiseReaction.cpp:
837         (JSC::ExecutePromiseReactionMicrotask::run):
838
839         * runtime/VM.cpp:
840         (JSC::VM::VM):
841         (JSC::VM::releaseExecutableMemory):
842         (JSC::VM::throwException):
843         (JSC::VM::setStackPointerAtVMEntry):
844         (JSC::VM::getExceptionInfo): Deleted.
845         (JSC::VM::setExceptionInfo): Deleted.
846         (JSC::VM::clearException): Deleted.
847         (JSC::clearExceptionStack): Deleted.
848         * runtime/VM.h:
849         (JSC::VM::targetMachinePCForThrowOffset):
850         (JSC::VM::clearException):
851         (JSC::VM::setException):
852         (JSC::VM::exception):
853         (JSC::VM::addressOfException):
854         (JSC::VM::exceptionStack): Deleted.
855         * runtime/VMEntryScope.cpp:
856         (JSC::VMEntryScope::VMEntryScope):
857         (JSC::VMEntryScope::setEntryScopeDidPopListener):
858
859 2015-06-04  Benjamin Poulain  <bpoulain@apple.com>
860
861         [JSC] Always track out-of-bounds array access explicitly instead of relying on the slow case
862         https://bugs.webkit.org/show_bug.cgi?id=145673
863
864         Reviewed by Geoffrey Garen.
865
866         Previously, we were deciding to use out-of-bounds speculation based on two informations:
867         -Explicitly detected out-of-bounds accesses tracked on ArrayProfile.
868         -The number of time we took the slow cases in the baseline JIT.
869
870         The heuristic based on slow cases was a little too fragile.
871
872         In some cases, we were running into that limit just because the indexing type changes between
873         two values (typically Int32Array and DoubleArray). Sometimes we were just unlucky on what
874         we used for the inline cache.
875
876         In Kraken, this was hurting us on "audio-beat-detection" and "audio-fft". The array types we see
877         change between Int32 and Double. We run into the slow path a bit but never hit
878         out-of-bounds.
879
880         By the time we compile in DFG, we have stable Double Arrays but we speculate out-of-bounds based
881         on the number of slow cases we took. Because of that, we start boxing the double on GetByVal,
882         using DoubleRep, etc. adding a ton of overhead over otherwise very simple operations.
883
884         WebXPRT was also suffering from this problem but the other way arround: we were missing
885         the out-of-bounds accesses due to changes in indexing types, we were below the threshold
886         of slow-path access, thus we predicted in-bounds accesses for code that was doing plenty
887         of out-of-bands.
888
889
890         This patch fixes the problem by tracking the out-of-bounds access explicitly any time we go
891         into the slow path in baseline JIT. Since we no longer miss any out-of-bounds, we can remove
892         the slow-path heuristic.
893
894         There is new additional special case in the C code regarding out-of-bounds: Arguments access.
895         Mispredicting out-of-bounds accesses on arguments is a disaster for performance, so those are
896         tracked in the way DFG expect it.
897
898
899         There are a few important cases that are still not covered optimally:
900         -PutByVal on Arguments.
901         -Get/Put ByVal on TypedArray.
902         Those are simply not used by DFG in any way. TypedArrays should probably be looked at in the future.
903
904         * bytecode/ArrayProfile.cpp:
905         (JSC::ArrayProfile::computeUpdatedPrediction):
906         The inline-cache repatch cases now update the ArrayProfile information. This has no value in baseline
907         JIT but it helps avoiding one recompile in DFG for the missing ArrayProfile information.
908
909         * bytecode/ArrayProfile.h:
910         (JSC::ArrayProfile::setOutOfBounds):
911         * dfg/DFGByteCodeParser.cpp:
912         (JSC::DFG::ByteCodeParser::getArrayMode):
913         (JSC::DFG::ByteCodeParser::parseBlock):
914         (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): Deleted.
915         * jit/CCallHelpers.h:
916         (JSC::CCallHelpers::setupArgumentsWithExecState):
917         * jit/JIT.h:
918         * jit/JITInlines.h:
919         (JSC::JIT::callOperation):
920         * jit/JITOpcodes.cpp:
921         (JSC::JIT::emitSlow_op_has_indexed_property):
922         * jit/JITOpcodes32_64.cpp:
923         (JSC::JIT::emitSlow_op_has_indexed_property):
924         * jit/JITOperations.cpp:
925         (JSC::canUseFastArgumentAccess):
926         This is not my favorite part of this patch.
927
928         I tried having JSObject::canGetIndexQuickly() handle arguments which would put everything
929         on the generic path. Unfortunately, that code is very performance sensitive and some benchmarks were
930         impacted by over 10%
931
932         I left JSObject::canGetIndexQuickly() alone, and I added the canUseFastArgumentAccess() mirroring
933         how DFG uses out-of-bounds for Arguments.
934
935         (JSC::getByVal):
936         * jit/JITOperations.h:
937         * jit/JITPropertyAccess.cpp:
938         (JSC::JIT::emitSlow_op_get_by_val):
939         (JSC::JIT::emitSlow_op_put_by_val):
940         * jit/JITPropertyAccess32_64.cpp:
941         (JSC::JIT::emitSlow_op_get_by_val):
942         (JSC::JIT::emitSlow_op_put_by_val):
943         * runtime/JSPromiseFunctions.cpp:
944         * tests/stress/get-by-val-out-of-bounds-basics.js: Added.
945         (opaqueGetByValOnInt32ArrayEarlyOutOfBounds):
946         (testInt32ArrayEarlyOutOfBounds):
947         (testIndexingTypeChangesOnInt32Array):
948         (opaqueGetByValOnStringArrayHotOutOfBounds):
949         (testStringArrayHotOutOfBounds):
950         (testIndexingTypeChangesOnStringArray):
951         (opaqueGetByValOnStringAndInt32ArrayHotOutOfBounds):
952         (testStringAndInt32ArrayHotOutOfBounds):
953         (opaqueGetByValOnDoubleArrayHotOutOfBounds):
954         * tests/stress/put-by-val-out-of-bounds-basics.js: Added.
955         (opaquePutByValOnInt32ArrayEarlyOutOfBounds):
956         (testInt32ArrayEarlyOutOfBounds):
957         (opaquePutByValOnStringArrayHotOutOfBounds):
958         (testStringArrayHotOutOfBounds):
959
960 2015-06-03  Filip Pizlo  <fpizlo@apple.com>
961
962         Simplify unboxing of double JSValues known to be not NaN and not Int32
963         https://bugs.webkit.org/show_bug.cgi?id=145618
964
965         Reviewed by Geoffrey Garen.
966         
967         In many cases we know that we most likely loaded a non-NaN double value from the heap.
968         Prior to this patch, we would do two branches before unboxing the double. This patch
969         reduces this to one branch in the common case. Before:
970         
971             if (is int32)
972                 unbox int32 and convert to double
973             else if (is number)
974                 unbox double
975             else
976                 exit
977         
978         After:
979
980             tmp = unbox double
981             if (tmp == tmp)
982                 done
983             else if (is int32)
984                 unbox int32 and convert to double
985             else
986                 exit
987         
988         We only use the new style if we have profiling that tells us that we are unlikely to see
989         either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
990         
991         This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
992         
993         Rolling this back in after I made DFG::SpeculativeJIT call a new version of unboxDouble()
994         that doesn't assert that the JSValue is a double, since we are intentionally using it
995         before doing the "is a double" test. This wasn't a problem on 32-bit since unboxDouble()
996         does no such assertion on 32-bit.
997
998         * dfg/DFGAbstractInterpreterInlines.h:
999         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1000         * dfg/DFGFixupPhase.cpp:
1001         (JSC::DFG::FixupPhase::observeUseKindOnNode):
1002         (JSC::DFG::FixupPhase::fixEdgeRepresentation):
1003         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1004         * dfg/DFGNode.h:
1005         (JSC::DFG::Node::shouldSpeculateDouble):
1006         (JSC::DFG::Node::shouldSpeculateDoubleReal):
1007         (JSC::DFG::Node::shouldSpeculateNumber):
1008         * dfg/DFGSafeToExecute.h:
1009         (JSC::DFG::SafeToExecuteEdge::operator()):
1010         * dfg/DFGSpeculativeJIT.cpp:
1011         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
1012         (JSC::DFG::SpeculativeJIT::speculateNumber):
1013         (JSC::DFG::SpeculativeJIT::speculateRealNumber):
1014         (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
1015         (JSC::DFG::SpeculativeJIT::speculate):
1016         (JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
1017         * dfg/DFGSpeculativeJIT.h:
1018         * dfg/DFGUseKind.cpp:
1019         (WTF::printInternal):
1020         * dfg/DFGUseKind.h:
1021         (JSC::DFG::typeFilterFor):
1022         (JSC::DFG::isNumerical):
1023         * ftl/FTLCapabilities.cpp:
1024         (JSC::FTL::canCompile):
1025         * ftl/FTLLowerDFGToLLVM.cpp:
1026         (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
1027         (JSC::FTL::LowerDFGToLLVM::boxDouble):
1028         (JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
1029         (JSC::FTL::LowerDFGToLLVM::speculate):
1030         (JSC::FTL::LowerDFGToLLVM::speculateNumber):
1031         (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
1032         (JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
1033         (JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
1034         (JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
1035         * jit/AssemblyHelpers.h:
1036         (JSC::AssemblyHelpers::branchIfNotOther):
1037         (JSC::AssemblyHelpers::branchIfInt32):
1038         (JSC::AssemblyHelpers::branchIfNotInt32):
1039         (JSC::AssemblyHelpers::branchIfNumber):
1040
1041 2015-06-04  Joseph Pecoraro  <pecoraro@apple.com>
1042
1043         Web Inspector: Class constructor appearing as Object Tree property does not include parameters
1044         https://bugs.webkit.org/show_bug.cgi?id=145661
1045
1046         Reviewed by Timothy Hatcher.
1047
1048         * inspector/InjectedScriptSource.js:
1049         (InjectedScript.prototype._classPreview):
1050         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
1051         The string we will return for previews of class constructor functions.
1052
1053         (InjectedScript.RemoteObject):
1054         (InjectedScript.RemoteObject.prototype._describe):
1055         No longer return the class name as the description string.
1056         Instead return the class name for the RemoteObject.className.
1057
1058 2015-06-04  Commit Queue  <commit-queue@webkit.org>
1059
1060         Unreviewed, rolling out r185216.
1061         https://bugs.webkit.org/show_bug.cgi?id=145666
1062
1063         it caused a bunch of debug crashes (Requested by pizlo on
1064         #webkit).
1065
1066         Reverted changeset:
1067
1068         "Simplify unboxing of double JSValues known to be not NaN and
1069         not Int32"
1070         https://bugs.webkit.org/show_bug.cgi?id=145618
1071         http://trac.webkit.org/changeset/185216
1072
1073 2015-06-03  Filip Pizlo  <fpizlo@apple.com>
1074
1075         Simplify unboxing of double JSValues known to be not NaN and not Int32
1076         https://bugs.webkit.org/show_bug.cgi?id=145618
1077
1078         Reviewed by Geoffrey Garen.
1079         
1080         In many cases we know that we most likely loaded a non-NaN double value from the heap.
1081         Prior to this patch, we would do two branches before unboxing the double. This patch
1082         reduces this to one branch in the common case. Before:
1083         
1084             if (is int32)
1085                 unbox int32 and convert to double
1086             else if (is number)
1087                 unbox double
1088             else
1089                 exit
1090         
1091         After:
1092
1093             tmp = unbox double
1094             if (tmp == tmp)
1095                 done
1096             else if (is int32)
1097                 unbox int32 and convert to double
1098             else
1099                 exit
1100         
1101         We only use the new style if we have profiling that tells us that we are unlikely to see
1102         either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
1103         
1104         This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
1105
1106         * dfg/DFGAbstractInterpreterInlines.h:
1107         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1108         * dfg/DFGFixupPhase.cpp:
1109         (JSC::DFG::FixupPhase::observeUseKindOnNode):
1110         (JSC::DFG::FixupPhase::fixEdgeRepresentation):
1111         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1112         * dfg/DFGNode.h:
1113         (JSC::DFG::Node::shouldSpeculateDouble):
1114         (JSC::DFG::Node::shouldSpeculateDoubleReal):
1115         (JSC::DFG::Node::shouldSpeculateNumber):
1116         * dfg/DFGSafeToExecute.h:
1117         (JSC::DFG::SafeToExecuteEdge::operator()):
1118         * dfg/DFGSpeculativeJIT.cpp:
1119         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
1120         (JSC::DFG::SpeculativeJIT::speculateNumber):
1121         (JSC::DFG::SpeculativeJIT::speculateRealNumber):
1122         (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
1123         (JSC::DFG::SpeculativeJIT::speculate):
1124         (JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
1125         * dfg/DFGSpeculativeJIT.h:
1126         * dfg/DFGUseKind.cpp:
1127         (WTF::printInternal):
1128         * dfg/DFGUseKind.h:
1129         (JSC::DFG::typeFilterFor):
1130         (JSC::DFG::isNumerical):
1131         * ftl/FTLCapabilities.cpp:
1132         (JSC::FTL::canCompile):
1133         * ftl/FTLLowerDFGToLLVM.cpp:
1134         (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
1135         (JSC::FTL::LowerDFGToLLVM::boxDouble):
1136         (JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
1137         (JSC::FTL::LowerDFGToLLVM::speculate):
1138         (JSC::FTL::LowerDFGToLLVM::speculateNumber):
1139         (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
1140         (JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
1141         (JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
1142         (JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
1143         * jit/AssemblyHelpers.h:
1144         (JSC::AssemblyHelpers::branchIfNotOther):
1145         (JSC::AssemblyHelpers::branchIfInt32):
1146         (JSC::AssemblyHelpers::branchIfNotInt32):
1147         (JSC::AssemblyHelpers::branchIfNumber):
1148
1149 2015-06-04  Filip Pizlo  <fpizlo@apple.com>
1150
1151         SideState should be a distinct abstract heap from Heap and Stack
1152         https://bugs.webkit.org/show_bug.cgi?id=145653
1153
1154         Reviewed by Geoffrey Garen.
1155         
1156         Before, SideState fit into the hierarchy like so:
1157         
1158         World
1159            |
1160            +-- Stack
1161            |
1162            +-- Heap
1163                  |
1164                  +-- SideState
1165         
1166         Now we will have:
1167         
1168         World
1169            |
1170            +-- Stack
1171            |
1172            +-- Heap
1173            |
1174            +-- SideState
1175         
1176         This makes it easy to ask if a writing operation wrote to anything that is observable even
1177         if we don't exit. SideState is only observable if we exit.
1178
1179         * dfg/DFGAbstractHeap.h:
1180         (JSC::DFG::AbstractHeap::AbstractHeap):
1181         (JSC::DFG::AbstractHeap::supertype):
1182
1183 2015-06-04  Chris Dumez  <cdumez@apple.com>
1184
1185         [WK2] Prune more resources from the MemoryCache before process suspension
1186         https://bugs.webkit.org/show_bug.cgi?id=145633
1187
1188         Reviewed by Andreas Kling.
1189
1190         No longer move protect IncrementalSweeper::fullSweep() behind
1191         USE(CF) so we don't need #ifdefs at call sites, similarly to what is
1192         done for the rest of the IncrementalSweeper API.
1193
1194         * heap/IncrementalSweeper.cpp:
1195         (JSC::IncrementalSweeper::fullSweep):
1196         * heap/IncrementalSweeper.h:
1197
1198 2015-06-01  Filip Pizlo  <fpizlo@apple.com>
1199
1200         CallLinkStatus should return takesSlowPath if the GC often cleared the IC
1201         https://bugs.webkit.org/show_bug.cgi?id=145502
1202
1203         Reviewed by Geoffrey Garen.
1204         
1205         CallLinkInfo now remembers when it has been cleared by GC. This has some safeguards for when
1206         a call gets cleared by GC only because we hadn't converted it into a closure call; in that
1207         case the GC will just tell us that it should be a closure call. The DFG will not optimize
1208         a call that was cleared by GC, and the DFG will always prefer a closure call if the GC told
1209         us that the specific callee was dead but the executable wasn't.
1210         
1211         This guards us from some scenarios that came up in Speedometer. It's neutral on the pure JS
1212         benchmarks, most likely just because those benchmarks aren't real enough to have interesting
1213         GC of code.
1214
1215         * bytecode/CallLinkInfo.cpp:
1216         (JSC::CallLinkInfo::visitWeak):
1217         (JSC::CallLinkInfo::dummy):
1218         * bytecode/CallLinkInfo.h:
1219         (JSC::CallLinkInfo::CallLinkInfo):
1220         * bytecode/CallLinkStatus.cpp:
1221         (JSC::CallLinkStatus::computeFromCallLinkInfo):
1222
1223 2015-06-02  Filip Pizlo  <fpizlo@apple.com>
1224
1225         GetById and PutById profiling should be more precise about it takes slow path
1226         https://bugs.webkit.org/show_bug.cgi?id=145590
1227
1228         Reviewed by Geoffrey Garen.
1229         
1230         If a ById access ever takes slow path, we want the DFG and FTL to know this. Previously we
1231         were relying on slow path counts, which conflate slow paths taken due to a megamorphic
1232         access and slow paths taken due to IC building.
1233
1234         * bytecode/GetByIdStatus.cpp:
1235         (JSC::GetByIdStatus::computeFor):
1236         (JSC::GetByIdStatus::computeForStubInfo):
1237         * bytecode/PutByIdStatus.cpp:
1238         (JSC::PutByIdStatus::computeFor):
1239         (JSC::PutByIdStatus::computeForStubInfo):
1240         * bytecode/StructureStubInfo.h:
1241         (JSC::StructureStubInfo::StructureStubInfo):
1242         * ftl/FTLIntrinsicRepository.h:
1243         * ftl/FTLLowerDFGToLLVM.cpp:
1244         (JSC::FTL::LowerDFGToLLVM::compileGetById):
1245         * jit/JITOperations.cpp:
1246         * jit/JITOperations.h:
1247
1248 2015-06-03  Michael Saboff  <msaboff@apple.com>
1249
1250         Improve test coverage for changes made in 145527
1251         https://bugs.webkit.org/show_bug.cgi?id=145578
1252
1253         Reviewed by Geoffrey Garen.
1254
1255         Added more complexity to poly-setter-combo.js stress test to create more turmoil in the
1256         polymorphic get-by-id / put-by-id with getters and setters to exercise the code change in
1257         https://bugs.webkit.org/show_bug.cgi?id=145527.  By changing the objects that the main test
1258         function sees, we are able to test those paths.  Verified with temporary logging code.
1259
1260         * tests/stress/poly-setter-combo.js:
1261         (Cons2):
1262         (Cons3):
1263         (Cons4):
1264         (foo):
1265         (test):
1266         (runTestWithConstructors):
1267
1268 2015-06-02  Mark Lam  <mark.lam@apple.com>
1269
1270         Gardening: fix broken CLoop build.
1271
1272         Not reviewed.
1273
1274         * bytecode/CallLinkStatus.cpp:
1275         (JSC::CallLinkStatus::computeExitSiteData):
1276
1277 2015-06-02  Keith Miller  <keith_miller@apple.com>
1278
1279         JavaScriptCore: JSExport protocol with an NSInteger property converts negative values to 18446744073709552000
1280         https://bugs.webkit.org/show_bug.cgi?id=145563
1281
1282         Reviewed by Darin Adler.
1283
1284         The Objective-C bindings were improperly converting negative
1285         long long/NSIntegers to 18446744073709552000 because they
1286         were converted to unsigned numbers.
1287
1288         * API/ObjcRuntimeExtras.h:
1289         (parseObjCType):
1290         * API/tests/testapi.mm:
1291         (testObjectiveCAPIMain):
1292         (checkNegativeNSIntegers):
1293         (testObjectiveCAPI):
1294
1295 2015-06-02  Yusuke Suzuki  <utatane.tea@gmail.com>
1296
1297         Heap-use-after-free read of size 4 in JavaScriptCore: WTF::StringImpl::isSymbol() (StringImpl.h:496)
1298         https://bugs.webkit.org/show_bug.cgi?id=145532
1299
1300         Reviewed by Geoffrey Garen.
1301
1302         AtomicStringImpl::lookUp returns AtomicStringImpl*,
1303         it doesn't give any ownership to the caller.
1304         Originally, this is ok because the ownership is taken
1305         by AtomicStringImpl's table (& the register side).
1306
1307         But if we would like to use this returned AtomicStringImpl*,
1308         we should take its ownership immediately.
1309         Because if the register side releases its ownership (ref count),
1310         it will be destroyed.
1311
1312         In JSString::toExistingAtomicString, it returns AtomicStringImpl*.
1313         But it's not appropriate.
1314         If the owner of AtomicStringImpl* is always JSString*, it is ok.
1315         But it looks up the table-registered AtomicStringImpl* from
1316         the AtomicStringImpl table. So JSString* may not have the ownership
1317         of the returned AtomicStringImpl*.
1318
1319         The failure situation is the following.
1320
1321         1. A creates AtomicStringImpl. A has its ownership.
1322            And A registers it to AtomicStringImpl table.
1323         2. JSString looks up the AtomicStringImpl from the table.
1324            It gets AtomicStringImpl*. And JSString doesn't have its ownership.
1325            It returns the raw pointer immediately to the users
1326         3. A is released. There's no owner for AtomicStringImpl*.
1327            So it's also destroyed.
1328         4. Use looked up AtomicStringImpl in (2). It becomes use-after-free.
1329
1330         This patch fixes it by the following changes.
1331
1332         1. Change the signature of `AtomicStringImpl* AtomicStringImpl::lookUp(...)`
1333            to `RefPtr<AtomicStringImpl> AtomicStringImpl::lookUp(..)`.
1334            Use `RefPtr` because it may return `nullptr`.
1335         2. Change the signature of `AtomicStringImpl* JSString::toExistingAtomicString(...)`
1336            to `RefPtr<AtomicStringImpl> JSString::toExistingAtomicString(...)`.
1337            Using `RefPtr` is the same reason.
1338         3. Receive the result with `RefPtr<AtomicStringImpl>` in the caller side.
1339
1340         * dfg/DFGOperations.cpp:
1341         * jit/JITOperations.cpp:
1342         (JSC::getByVal):
1343         * llint/LLIntSlowPaths.cpp:
1344         (JSC::LLInt::getByVal):
1345         * runtime/JSString.cpp:
1346         (JSC::JSRopeString::resolveRopeToExistingAtomicString):
1347         * runtime/JSString.h:
1348         (JSC::JSString::toExistingAtomicString):
1349
1350 2015-05-30  Filip Pizlo  <fpizlo@apple.com>
1351
1352         Any exit from any JIT due to profiling for an inline cache should force all future compilations to be wary
1353         https://bugs.webkit.org/show_bug.cgi?id=145496
1354
1355         Reviewed by Geoffrey Garen.
1356         
1357         This pessimizes compilation a bit, but it reduces the likelihood of exiting from FTL. I
1358         couldn't find any convincing reason not to do this, and we know from Speedometer that this
1359         change is necessary for weirder code.
1360
1361         * bytecode/CallLinkStatus.cpp:
1362         (JSC::CallLinkStatus::computeFor):
1363         (JSC::CallLinkStatus::computeExitSiteData):
1364         (JSC::CallLinkStatus::computeDFGStatuses):
1365         * bytecode/CallLinkStatus.h:
1366         * bytecode/GetByIdStatus.cpp:
1367         (JSC::GetByIdStatus::appendVariant):
1368         (JSC::GetByIdStatus::hasExitSite):
1369         (JSC::GetByIdStatus::computeFor):
1370         * bytecode/GetByIdStatus.h:
1371         * bytecode/PutByIdStatus.cpp:
1372         (JSC::PutByIdStatus::appendVariant):
1373         (JSC::PutByIdStatus::hasExitSite):
1374         (JSC::PutByIdStatus::computeFor):
1375         * bytecode/PutByIdStatus.h:
1376
1377 2015-05-31  Filip Pizlo  <fpizlo@apple.com>
1378
1379         If a call has ever taken the virtual slow path, make sure that the DFG knows this
1380         https://bugs.webkit.org/show_bug.cgi?id=145501
1381
1382         Reviewed by Geoffrey Garen.
1383         
1384         Now now return higher fidelity information in the case of no polymorphic call stub. If the
1385         virtual slow path was ever taken, we note this, and we note either zero or one call variant
1386         based on the IC's last callee.
1387
1388         * bytecode/CallLinkStatus.cpp:
1389         (JSC::CallLinkStatus::computeFromCallLinkInfo):
1390         (JSC::CallLinkStatus::computeFor):
1391
1392 2015-06-01  Michael Saboff  <msaboff@apple.com>
1393
1394         Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::revertCall + 24
1395         https://bugs.webkit.org/show_bug.cgi?id=145527
1396
1397         Reviewed by Filip Pizlo.
1398
1399         If a CallLinkInfo is GC'ed, we need to notify any PolymorphicCallNode's that reference it.
1400         Added plumbling to clear the m_callLinkInfo of a PolymorphicCallNode when that CallLinkInfo
1401         is going away.
1402
1403         * bytecode/CallLinkInfo.h:
1404         (JSC::CallLinkInfo::~CallLinkInfo):
1405         * jit/PolymorphicCallStubRoutine.cpp:
1406         (JSC::PolymorphicCallNode::unlink):
1407         (JSC::PolymorphicCallNode::clearCallLinkInfo):
1408         (JSC::PolymorphicCallCase::dump):
1409         (JSC::PolymorphicCallStubRoutine::edges):
1410         (JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
1411         (JSC::PolymorphicCallStubRoutine::visitWeak):
1412         * jit/PolymorphicCallStubRoutine.h:
1413         (JSC::PolymorphicCallNode::hasCallLinkInfo):
1414
1415 2015-06-01  Mark Lam  <mark.lam@apple.com>
1416
1417         Add the ability to tell between Catch and Finally blocks.
1418         https://bugs.webkit.org/show_bug.cgi?id=145524 
1419
1420         Reviewed by Michael Saboff.
1421
1422         ... and also SynthesizedFinally blocks too.  A SynthesizedFinally block
1423         is a finally block that is synthesized by the bytecode generator but
1424         does not actually correspond to any exception handling construct at the
1425         JS source code level.  An example of this is the "for ... of" statement
1426         where it needs to do some "final" clean up before passing on the
1427         exception.
1428
1429         Manually tested by inspecting the bytecode dump of functions with
1430         try-catch-finally blocks as well as for of statements which have
1431         synthesized finally blocks.  The bytecode dumps contains the exception
1432         handlers table which has these blocks labelled with their newly added
1433         types.  No automatic test because this type info is not visible to JS
1434         code.
1435
1436         * bytecode/CodeBlock.cpp:
1437         (JSC::CodeBlock::dumpBytecode):
1438         * bytecode/HandlerInfo.h:
1439         (JSC::HandlerInfoBase::type):
1440         (JSC::HandlerInfoBase::setType):
1441         (JSC::HandlerInfoBase::typeName):
1442         (JSC::HandlerInfoBase::isCatchHandler):
1443         (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
1444         (JSC::HandlerInfo::initialize):
1445         * bytecompiler/BytecodeGenerator.cpp:
1446         (JSC::BytecodeGenerator::generate):
1447         (JSC::BytecodeGenerator::pushTry):
1448         (JSC::BytecodeGenerator::popTryAndEmitCatch):
1449         (JSC::BytecodeGenerator::emitEnumeration):
1450         * bytecompiler/BytecodeGenerator.h:
1451         (JSC::BytecodeGenerator::emitThrow):
1452         * bytecompiler/NodesCodegen.cpp:
1453         (JSC::TryNode::emitBytecode):
1454
1455 2015-05-29  Geoffrey Garen  <ggaren@apple.com>
1456
1457         REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
1458         https://bugs.webkit.org/show_bug.cgi?id=145412
1459
1460         Reviewed by Darin Adler.
1461
1462         Moar speedup.
1463
1464         Added a bucket sort for string sorting.
1465
1466         * builtins/Array.prototype.js:
1467         (sort.compactSparse):
1468         (sort.compactSlow):
1469         (sort.compact): Split out a compaction fast path for dense arrays. Without
1470         it, compaction can increase sort time by 2X for simple sorts.
1471
1472         (sort.bucketSort):
1473         (sort.stringSort): Use a bucket sorting algorithm if we know we're sorting
1474         strings. This makes average case string sorting O(N) with O(N) additional
1475         memory use.
1476
1477         The worst case bucket sort can require O(M * N) additional
1478         space. We avoid this by falling back to merge sort when things are
1479         simple or overly duplicative. These are the two cases that accumulate
1480         excessive -- and potentially pathological -- bucketing overhead.
1481
1482 2015-06-01  Mark Lam  <mark.lam@apple.com>
1483
1484         HandlerInfo::initialize() should not assume that CodeLocationLabel is available.
1485         https://bugs.webkit.org/show_bug.cgi?id=145515
1486
1487         Reviewed by Csaba Osztrogonác.
1488
1489         CodeLocationLabel is only defined for ENABLE(ASSEMBLER) builds.  r185022's
1490         attempt at simplifying code to increase readability failed to take this into
1491         account.  This patch fixes it.
1492
1493         * bytecode/CodeBlock.cpp:
1494         (JSC::CodeBlock::CodeBlock):
1495         * bytecode/HandlerInfo.h:
1496         (JSC::HandlerInfo::initialize):
1497
1498 2015-05-31  Filip Pizlo  <fpizlo@apple.com>
1499
1500         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=145503.
1501
1502         * dfg/DFGByteCodeParser.cpp:
1503         (JSC::DFG::ByteCodeParser::inliningCost):
1504
1505 2015-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
1506
1507         [ES6] Drop WeakMap#clear
1508         https://bugs.webkit.org/show_bug.cgi?id=145489
1509
1510         Reviewed by Mark Lam.
1511
1512         ES6 spec intentionally drops the WeakMap#clear
1513         to allow engine to implement WeakMap as a per-object table.
1514
1515         This patch drops WeakMap.prototype.clear.
1516
1517         * runtime/WeakMapPrototype.cpp:
1518         (JSC::WeakMapPrototype::finishCreation): Deleted.
1519         (JSC::protoFuncWeakMapClear): Deleted.
1520
1521 2015-05-31  Jordan Harband  <ljharb@gmail.com>
1522
1523         Array#reduce and reduceRight don't follow ToLength
1524         https://bugs.webkit.org/show_bug.cgi?id=145364
1525         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
1526
1527         Reviewed by Yusuke Suzuki.
1528
1529         * builtins/Array.prototype.js:
1530         (reduce):
1531         (reduceRight):
1532         * runtime/ArrayPrototype.cpp:
1533         (JSC::ArrayPrototype::finishCreation):
1534         (JSC::arrayProtoFuncReduce): Deleted.
1535         (JSC::arrayProtoFuncReduceRight): Deleted.
1536
1537 2015-05-29  Filip Pizlo  <fpizlo@apple.com>
1538
1539         FTL codegen for MultiGetByOffset and MultiPutByOffset where the structure set is already proved should have an unreachable default case instead of an exit
1540         https://bugs.webkit.org/show_bug.cgi?id=145469
1541
1542         Reviewed by Geoffrey Garen.
1543         
1544         Omitting the speculation on the fail path when the speculation is guaranteed not to be
1545         taken hints to LLVM that the default case is impossible. This enables some useful
1546         optimizations.
1547
1548         * ftl/FTLLowerDFGToLLVM.cpp:
1549         (JSC::FTL::LowerDFGToLLVM::compileMultiGetByOffset):
1550         (JSC::FTL::LowerDFGToLLVM::compileMultiPutByOffset):
1551
1552 2015-05-29  Mark Lam  <mark.lam@apple.com>
1553
1554         Refactoring HandlerInfo and UnlinkedHandlerInfo.
1555         https://bugs.webkit.org/show_bug.cgi?id=145480
1556
1557         Reviewed by Benjamin Poulain.
1558
1559         HandlerInfo and UnlinkedHandlerInfo have common parts, but are not currently
1560         expressed as 2 unrelated structs that happen to have near identical fields.
1561         We can refactor them to better express their relationship.  We can also add
1562         some convenience functions to make the code that uses them a little more
1563         readable.
1564
1565         * bytecode/CodeBlock.cpp:
1566         (JSC::CodeBlock::dumpBytecode):
1567         (JSC::CodeBlock::CodeBlock):
1568         (JSC::CodeBlock::handlerForBytecodeOffset):
1569         * bytecode/HandlerInfo.h:
1570         (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
1571         (JSC::HandlerInfo::initialize):
1572         - I chose to include CodeLocationLabel arg even though it is unused by
1573           by non-JIT builds.  This makes the call site cleaner to read.
1574
1575         * bytecode/UnlinkedCodeBlock.h:
1576         (JSC::UnlinkedSimpleJumpTable::add):
1577         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1578         (JSC::UnlinkedCodeBlock::numberOfExceptionHandlers):
1579         (JSC::UnlinkedCodeBlock::addExceptionHandler):
1580         (JSC::UnlinkedCodeBlock::exceptionHandler):
1581         (JSC::UnlinkedCodeBlock::symbolTable):
1582         * bytecompiler/BytecodeGenerator.cpp:
1583         (JSC::BytecodeGenerator::generate):
1584
1585 2015-05-28  Filip Pizlo  <fpizlo@apple.com>
1586
1587         Non-speculative Branch should be fast in the FTL
1588         https://bugs.webkit.org/show_bug.cgi?id=145452
1589
1590         Reviewed by Andreas Kling.
1591         
1592         Inlines the code for convertJSValueToBoolean into the FTL. This also includes some other
1593         clean-ups that I found along the way.
1594         
1595         I found this by looking at the hottest functions in DeltaBlue. Despite having so many
1596         Branch specializations, apparently there was still a hot one that we missed that was going
1597         down the untyped path. It was either Int32 or Other. Maybe we could specialize for that
1598         combo, but it makes so much sense to just make all of this nonsense fast.
1599
1600         * dfg/DFGWatchpointCollectionPhase.cpp:
1601         (JSC::DFG::WatchpointCollectionPhase::handle): Need to watch the masquerades watchpoint on UntypedUse: forms of Branch now.
1602         * ftl/FTLLowerDFGToLLVM.cpp:
1603         (JSC::FTL::LowerDFGToLLVM::boolify): The actual fix.
1604         (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52):
1605         (JSC::FTL::LowerDFGToLLVM::isInt32):
1606         (JSC::FTL::LowerDFGToLLVM::isNotInt32):
1607         (JSC::FTL::LowerDFGToLLVM::unboxInt32):
1608         * runtime/JSCellInlines.h:
1609         (JSC::JSCell::toBoolean): Symbol is always true.
1610         (JSC::JSCell::pureToBoolean): Symbol is always true.
1611         * runtime/JSString.cpp:
1612         (JSC::JSString::getPrimitiveNumber):
1613         (JSC::JSString::toNumber):
1614         (JSC::JSString::toBoolean): Deleted. This is a tiny method. It doesn't need to be out-of-line.
1615         * runtime/JSString.h:
1616         (JSC::JSString::length):
1617         (JSC::JSString::toBoolean): This method shouldbe inline.
1618         * runtime/Symbol.cpp:
1619         (JSC::Symbol::toPrimitive):
1620         (JSC::Symbol::getPrimitiveNumber):
1621         (JSC::Symbol::toBoolean): Deleted. A Symbol is always true, so we don't need a method for this.
1622         * runtime/Symbol.h:
1623
1624 2015-05-29  Commit Queue  <commit-queue@webkit.org>
1625
1626         Unreviewed, rolling out r184860.
1627         https://bugs.webkit.org/show_bug.cgi?id=145456
1628
1629         May have caused ~1% Octane regression (Requested by kling on
1630         #webkit).
1631
1632         Reverted changeset:
1633
1634         "Try to use StringView when comparing JSStrings for equality."
1635         https://bugs.webkit.org/show_bug.cgi?id=145379
1636         http://trac.webkit.org/changeset/184860
1637
1638 2015-05-28  Michael Saboff  <msaboff@apple.com>
1639
1640         mozilla/js1_5/Array/regress-154338.js test causes ARM 32 bit iOS devices to run out of memory
1641         https://bugs.webkit.org/show_bug.cgi?id=145444
1642
1643         Reviewed by Geoffrey Garen.
1644
1645         Disabled mozilla/js1_5/Array/regress-154338.js when run on iOS ARM 32 bit devices and
1646         the --memory-limited option is passed to run-jsc-stress-tests.
1647
1648         * tests/mozilla/mozilla-tests.yaml:
1649
1650 2015-05-28  Benjamin Poulain  <benjamin@webkit.org>
1651
1652         [iOS8][ARMv7(s)] Optimized Object.create in 'use strict' context sometimes breaks.
1653         https://bugs.webkit.org/show_bug.cgi?id=138038
1654
1655         Reviewed by Michael Saboff.
1656
1657         TL;DR: sometimes the baseline JIT could accidentally nuke the tag before calling
1658                to C++, making put_by_id behave erratically.
1659
1660         The bug was that put_by_id would randomly not work correctly in 32bits. It happened
1661         in the baseline JIT if we were unlucky enough:
1662         -The code get hot enough and the structure is stable so we get a fast path for
1663          put_by_id.
1664         -We repatch the fast-path branch with a stub generated by
1665          emitPutTransitionStubAndGetOldStructure().
1666         -In emitPutTransitionStubAndGetOldStructure(), we only preserve the payload of the base
1667          register, the tag register is ignored.
1668         -emitPutTransitionStubAndGetOldStructure() allocate 2 to 3 registers. Any of those
1669          could be the one used for the base's tag before the fast path and the value is trashed.
1670         -If we hit one of the failure case, we fallback to the slow path, but we destroyed
1671          the tag pointer.
1672         -We now have unrelated bits in the tag, the most likely value type is now "double"
1673          and we fail the put_by_id because we try to set a property on a number.
1674
1675         The most obvious solution would be to change emitPutTransitionStubAndGetOldStructure()
1676         to preserve the tag register in addition to the value register.
1677         I decided against that option because of the added complexity. The DFG does not need
1678         that case, so I would have to add branches everywhere to distinguish the cases
1679         were we need to preserve the tag or not.
1680
1681         Instead, I just load the tag back from memory in the slow path. The function in the slow
1682         path is several order of magnitude slower than a load, it is not worth eliminating it,
1683         especially in baseline JIT.
1684
1685         I also discovered 4 useless loads in the fast path, so even with my extra load, this patch
1686         makes the baseline faster :)
1687
1688         * jit/JITPropertyAccess32_64.cpp:
1689         (JSC::JIT::emitSlow_op_put_by_id):
1690         (JSC::JIT::emit_op_put_by_id): Deleted.
1691         * tests/stress/put-by-id-on-new-object-after-prototype-transition-non-strict.js: Added.
1692         (opaqueNewObject):
1693         (putValueOnNewObject):
1694         * tests/stress/put-by-id-on-new-object-after-prototype-transition-strict.js: Added.
1695         (string_appeared_here.opaqueNewObject):
1696         (putValueOnNewObject):
1697
1698 2015-05-28  Benjamin Poulain  <benjamin@webkit.org>
1699
1700         [JSC] reduction the iteration count of the DoubleRep stress tests
1701
1702         Once again, I used big numbers for manual testing and I forgot to fix them before landing.
1703
1704         * tests/stress/double-rep-with-non-cell.js:
1705         * tests/stress/double-rep-with-null.js:
1706         * tests/stress/double-rep-with-undefined.js:
1707
1708 2015-05-28  Basile Clement  <basile_clement@apple.com>
1709
1710         Add debug mode assertions for accessors casting JSC::DFG::Node.m_opInfo
1711         https://bugs.webkit.org/show_bug.cgi?id=145441
1712
1713         Reviewed by Filip Pizlo.
1714
1715         Most accessor functions casting m_opInfo in JSC::DFG::Node are
1716         performing debug checks that they are only accessed for node types that
1717         should have them. This patch adds similar checks for the accessors that
1718         were missing them.
1719
1720         * dfg/DFGNode.h:
1721         (JSC::DFG::Node::watchpointSet):
1722         (JSC::DFG::Node::storagePointer):
1723         (JSC::DFG::Node::multiGetByOffsetData):
1724         (JSC::DFG::Node::multiPutByOffsetData):
1725         (JSC::DFG::Node::hasTypeLocation):
1726         (JSC::DFG::Node::typeLocation):
1727         (JSC::DFG::Node::hasBasicBlockLocation):
1728         (JSC::DFG::Node::basicBlockLocation):
1729
1730 2015-05-28  Matt Rajca  <mrajca@apple.com>
1731
1732         Add ENABLE_MEDIA_SESSION feature flag (which is off by default).
1733         https://bugs.webkit.org/show_bug.cgi?id=145415
1734
1735         Reviewed by Eric Carlson.
1736
1737         * Configurations/FeatureDefines.xcconfig:
1738
1739 2015-05-27  Jordan Harband  <ljharb@gmail.com>
1740
1741         Array.of should work with other constructors
1742         https://bugs.webkit.org/show_bug.cgi?id=145365
1743         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of
1744         step 4
1745
1746         Reviewed by Yusuke Suzuki.
1747
1748         * builtins/ArrayConstructor.js:
1749         (of):
1750         * runtime/ArrayConstructor.cpp:
1751         (JSC::arrayConstructorOf): Deleted.
1752
1753 2015-05-27  Benjamin Poulain  <bpoulain@apple.com>
1754
1755         [JSC] Add undefined->double conversion to DoubleRep
1756         https://bugs.webkit.org/show_bug.cgi?id=145293
1757
1758         Reviewed by Filip Pizlo.
1759
1760         This patch adds undefined to double conversion to the DoubleRep
1761         node for the cases were we speculate "undefined" as part of the types
1762         processed.
1763
1764         The use case is doing math with accidental out-of-bounds access. For example,
1765         something like:
1766             for (var i = 0; i <= length; ++i)
1767                 ouptput += array[i];
1768
1769         would cause us to OSR exit every time i === length.
1770
1771         When hitting one of those cases, we would already speculate double math,
1772         but the DoubleRep node was unable to convert the undefined and would exit.
1773
1774         With this patch the use kind NotCellUse cover this conversion for DoubleRep.
1775         I have been quite conservative so in general we will not find "undefined"
1776         until a few recompile but being optimistic seems better since this is a corner case.
1777
1778         This patch is a 80% progression on WebXPRT's DNA Sequencing test.
1779
1780         * dfg/DFGAbstractInterpreterInlines.h:
1781         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1782         * dfg/DFGFixupPhase.cpp:
1783         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1784         * dfg/DFGNode.h:
1785         (JSC::DFG::Node::sawUndefined):
1786         * dfg/DFGPredictionPropagationPhase.cpp:
1787         (JSC::DFG::PredictionPropagationPhase::propagate):
1788         * dfg/DFGSafeToExecute.h:
1789         (JSC::DFG::SafeToExecuteEdge::operator()):
1790         * dfg/DFGSpeculativeJIT.cpp:
1791         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
1792         * dfg/DFGUseKind.cpp:
1793         (WTF::printInternal):
1794         * dfg/DFGUseKind.h:
1795         (JSC::DFG::typeFilterFor):
1796         * ftl/FTLCapabilities.cpp:
1797         (JSC::FTL::canCompile):
1798         * ftl/FTLLowerDFGToLLVM.cpp:
1799         (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
1800         (JSC::FTL::LowerDFGToLLVM::jsValueToDouble):
1801         * tests/stress/double-rep-with-undefined.js: Added.
1802         (addArgsNumberAndUndefined):
1803         (addArgsInt32AndUndefined):
1804         (testFallbackWithDouble):
1805         (addArgsDoubleAndUndefined):
1806         (testFallbackWithObject.):
1807         (testFallbackWithObject):
1808         (addArgsOnlyUndefined):
1809         (testFallbackWithString):
1810
1811 2015-05-27  Dean Jackson  <dino@apple.com>
1812
1813         img.currentSrc problem in strict mode with old picturefill
1814         https://bugs.webkit.org/show_bug.cgi?id=144095
1815         <rdar://problem/21087013>
1816
1817         Reviewed by Simon Fraser.
1818
1819         Add a PICTURE_SIZES flag.
1820
1821         * Configurations/FeatureDefines.xcconfig:
1822
1823 2015-05-27  Basile Clement  <basile_clement@apple.com>
1824
1825         LazyNode comparison can return incorrect results when comparing an empty value
1826         https://bugs.webkit.org/show_bug.cgi?id=145421
1827
1828         Reviewed by Geoffrey Garen.
1829
1830         When comparing a LazyNode to another, we compare the value pointers if
1831         we have one, and otherwise compare the nodes.
1832         We should be comparing value pointers if the other LazyNode has one as
1833         well, otherwise we risk an incoherency when we are a empty LazyNode
1834         being compared to a FrozenValue without node.
1835
1836         Note that this is not a problem in any other case because if we don't
1837         have a FrozenValue and we are not an empty LazyNode, we are a
1838         non-constant node, and comparing the node pointers is correct.
1839
1840         * dfg/DFGLazyNode.h:
1841         (JSC::DFG::LazyNode::operator==):
1842
1843 2015-05-27  Geoffrey Garen  <ggaren@apple.com>
1844
1845         REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
1846         https://bugs.webkit.org/show_bug.cgi?id=145412
1847
1848         Reviewed by Benjamin Poulain.
1849
1850         Cache strings when doing a string-converting sort.
1851
1852         This is a 21% speedup.
1853
1854         * builtins/Array.prototype.js:
1855         (sort.stringComparator): Use subtraction instead of branching because
1856         it's slightly faster.
1857
1858         (sort.comparatorSort):
1859         (sort.stringSort):
1860         (sort): Add a special case for string sorting to avoid redundant string
1861         conversion.
1862
1863         * parser/Parser.cpp:
1864         (JSC::Parser<LexerType>::createBindingPattern): Names can be empty if
1865         they are private names.
1866
1867 2015-05-26  Filip Pizlo  <fpizlo@apple.com>
1868
1869         JIT-generated store barrier code should assume the buffer pointer and capacity to be compile-time constants
1870         https://bugs.webkit.org/show_bug.cgi?id=145404
1871
1872         Reviewed by Andreas Kling.
1873         
1874         We never change the capacity of a write barrier buffer. We never repoint the buffer
1875         pointer. So, the JIT shouldn't load those from memory; it should take advantage of the
1876         fact that these are compile-time constants.
1877
1878         * dfg/DFGSpeculativeJIT.cpp:
1879         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer):
1880         * ftl/FTLLowerDFGToLLVM.cpp:
1881         (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
1882         * heap/WriteBarrierBuffer.h:
1883         (JSC::WriteBarrierBuffer::currentIndexAddress):
1884         (JSC::WriteBarrierBuffer::capacity):
1885         (JSC::WriteBarrierBuffer::buffer):
1886         (JSC::WriteBarrierBuffer::currentIndexOffset): Deleted.
1887         (JSC::WriteBarrierBuffer::capacityOffset): Deleted.
1888         (JSC::WriteBarrierBuffer::bufferOffset): Deleted.
1889         * jit/Repatch.cpp:
1890         (JSC::emitPutTransitionStubAndGetOldStructure):
1891
1892 2015-05-27  Geoffrey Garen  <ggaren@apple.com>
1893
1894         REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
1895         https://bugs.webkit.org/show_bug.cgi?id=145412
1896
1897         Reviewed by Darin Adler.
1898
1899         Use @toString instead of the String constructor because calls to the
1900         String constructor are never optimized. (See
1901         https://bugs.webkit.org/show_bug.cgi?id=144458.)
1902
1903         This is a ~2X speedup.
1904
1905         * builtins/Array.prototype.js:
1906         (sort.stringComparator):
1907
1908 2015-05-27  Dan Bernstein  <mitz@apple.com>
1909
1910         Remove JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080
1911         https://bugs.webkit.org/show_bug.cgi?id=145403
1912
1913         Reviewed by Anders Carlsson.
1914
1915         JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 was used to enable the JavaScriptCore Objective-C API
1916         for WebKit and Safari projects building with JavaScriptCore targeting OS X 10.8. We don’t
1917         need it anymore.
1918
1919         * API/JSBase.h:
1920         * API/JSContext.h:
1921         * API/JSManagedValue.h:
1922         * API/JSValue.h:
1923         * API/JSVirtualMachine.h:
1924         * Configurations/Base.xcconfig:
1925         * postprocess-headers.sh:
1926
1927 2015-05-26  Geoffrey Garen  <ggaren@apple.com>
1928
1929         Photo Booth hangs under JSC::MachineThreads::tryCopyOtherThreadStacks
1930         https://bugs.webkit.org/show_bug.cgi?id=145395
1931
1932         Reviewed by Mark Hahnenberg.
1933
1934         No test case because we already have --threaded mode, which runs lots of
1935         parallel GC, but it (and the original in-app test case) can't reproduce
1936         this bug.
1937
1938         * heap/MachineStackMarker.cpp:
1939         (JSC::MachineThreads::tryCopyOtherThreadStacks): Use a lock to prevent
1940         two threads from mutually suspending each other.
1941
1942 2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1943
1944         Add Array.prototype.copyWithin to JSC features.json
1945         https://bugs.webkit.org/show_bug.cgi?id=145387
1946
1947         Reviewed by Darin Adler.
1948
1949         * features.json:
1950
1951 2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1952
1953         Reflect nits for r184863
1954         https://bugs.webkit.org/show_bug.cgi?id=145107
1955
1956         Reviewed by Darin Adler.
1957
1958         1. Added the copyright line.
1959         2. Added an optional argument (/*, end */). To do so, fixed generate-js-builtins.
1960         3. Dropped the unnecessary variable `thisValue`.
1961         4. Fix the type error messages. This is also found in StringIterator.prototype.js.
1962         5. Added tests for 0 arguments.
1963
1964         * builtins/Array.prototype.js:
1965         (copyWithin):
1966         * builtins/StringIterator.prototype.js:
1967         (next):
1968         * generate-js-builtins:
1969         * tests/stress/array-copywithin.js:
1970         * tests/stress/string-iterators.js:
1971
1972 2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1973
1974         Inline @Array / @Object callsites
1975         https://bugs.webkit.org/show_bug.cgi?id=145382
1976
1977         Reviewed by Geoffrey Garen.
1978
1979         As the same to Array/Object callsite inlining, @Array/@Object also
1980         should be inlined in bytecode level.
1981         While `new @Object` style is not encouraged in the builtins,
1982         `@Array(len)` is already used at least in Array.from code.
1983
1984         * bytecompiler/BytecodeGenerator.cpp:
1985         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
1986
1987 2015-05-26  Andreas Kling  <akling@apple.com>
1988
1989         String.prototype.charCodeAt() should use StringView.
1990         <https://webkit.org/b/145353>
1991
1992         Reviewed by Darin Adler.
1993
1994         Use JSString::view() in charCodeAt() to avoid reifying the JSString if it's
1995         a substring. This avoids StringImpl allocation in some cases and ref churn
1996         in all cases.
1997
1998         * runtime/StringPrototype.cpp:
1999         (JSC::stringProtoFuncCharCodeAt):
2000
2001 2015-05-26  Andreas Kling  <akling@apple.com>
2002
2003         String.prototype.charAt() should use StringView.
2004         <https://webkit.org/b/145352>
2005
2006         Reviewed by Darin Adler.
2007
2008         Remove the jsSingleCharacterSubstring() function since it's actually completely
2009         counter-productive: it could create a single-character string that would retain
2010         a much larger string for the duration of its lifetime.
2011
2012         This made sense before StringImpl learned to put its characters at the tail end
2013         of its own allocation. Now that it does, it's far better to just create a new
2014         single-character StringImpl.
2015
2016         With that out of the way, we can make String.prototype.charAt() use StringView
2017         to avoid reifying substring JSStrings (and avoid some ref churn too.)
2018
2019         * runtime/JSString.cpp:
2020         (JSC::JSRopeString::getIndexSlowCase):
2021         * runtime/JSString.h:
2022         (JSC::JSString::getIndex):
2023         (JSC::jsSingleCharacterSubstring): Deleted.
2024         * runtime/StringPrototype.cpp:
2025         (JSC::stringProtoFuncCharAt):
2026         (JSC::stringProtoFuncSplit):
2027
2028 2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
2029
2030         [ES6] Implement Array.prototype.copyWithin
2031         https://bugs.webkit.org/show_bug.cgi?id=145107
2032
2033         Reviewed by Darin Adler.
2034
2035         This patch implements ES6 Array.prototype.copyWithin.
2036         It is intended to be used for copying the region to the other region
2037         in the callee array itself safely (like memmove, not memcpy).
2038         This function is proposed in the context of WebGL.
2039
2040         * builtins/Array.prototype.js:
2041         (.maxWithPositives):
2042         (.minWithMaybeNegativeZeroAndPositive):
2043         (copyWithin):
2044         * runtime/ArrayPrototype.cpp:
2045         (JSC::ArrayPrototype::finishCreation):
2046         * tests/stress/array-copywithin.js: Added.
2047         (shouldBe):
2048         (shouldBeArray):
2049         (shouldThrow):
2050         (arrayToObject):
2051         (valueOf):
2052
2053 2015-05-26  Dan Bernstein  <mitz@apple.com>
2054
2055         <rdar://problem/21104551> Update build settings
2056
2057         Reviewed by Anders Carlsson.
2058
2059         * Configurations/DebugRelease.xcconfig:
2060         * Configurations/FeatureDefines.xcconfig:
2061         * Configurations/Version.xcconfig:
2062
2063 2015-05-26  Andreas Kling  <akling@apple.com>
2064
2065         Try to use StringView when comparing JSStrings for equality.
2066         <https://webkit.org/b/145379>
2067
2068         Reviewed by Darin Adler.
2069
2070         Use JSString::view() when sending two JSStrings to WTF::equal()
2071         for comparison. This avoids creating new objects in the case where
2072         the strings are actually substrings.
2073
2074         * jit/JITOperations.cpp:
2075         * runtime/JSCJSValueInlines.h:
2076         (JSC::JSValue::equalSlowCaseInline):
2077         (JSC::JSValue::strictEqualSlowCaseInline):
2078
2079 2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
2080
2081         [JSC] Generate put_by_val_direct for indexed identifiers instead of put_by_id with direct postfix
2082         https://bugs.webkit.org/show_bug.cgi?id=145360
2083
2084         Reviewed by Darin Adler.
2085
2086         JSObject::putDirect only accepts non-indexed properties.
2087         So when generating put_by_id (with direct postfix) for indexed property,
2088         we should generate put_by_val_direct instead.
2089
2090         * bytecompiler/BytecodeGenerator.cpp:
2091         (JSC::BytecodeGenerator::emitDirectPutById):
2092         * bytecompiler/NodesCodegen.cpp:
2093         (JSC::PropertyListNode::emitPutConstantProperty):
2094         * tests/stress/put-by-id-direct-should-be-done-for-non-index-property.js: Added.
2095
2096 2015-05-24  Jordan Harband  <ljharb@gmail.com>
2097
2098         Array#findIndex/find should not skip holes
2099         https://bugs.webkit.org/show_bug.cgi?id=145361
2100         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.findindex
2101         and https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.find
2102
2103         Reviewed by Yusuke Suzuki.
2104
2105         * builtins/Array.prototype.js:
2106         (find): Deleted.
2107         (findIndex): Deleted.
2108
2109 2015-05-24  Brian J. Burg  <burg@cs.washington.edu>
2110
2111         Web Inspector: Uncaught exception when using Inspect tool on SVG elements
2112         https://bugs.webkit.org/show_bug.cgi?id=145363
2113
2114         Reviewed by Joseph Pecoraro.
2115
2116         The injected script failed by chaining a call to String.prototype.trim to the result of
2117         SVG*Element.className, which is an SVGAnimatedString and lacks useful methods. So, obtain
2118         the class name using Node.getAttribute, which always returns a DOMString.
2119
2120         * inspector/InjectedScriptSource.js:
2121         (InjectedScriptSource.prototype._getDescription): use getAttribute instead of className.
2122
2123 2015-05-23  Dan Bernstein  <mitz@apple.com>
2124
2125         Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
2126         https://bugs.webkit.org/show_bug.cgi?id=145345
2127
2128         Reviewed by Sam Weinig.
2129
2130         * Configurations/Base.xcconfig: Also changed to use $(inherited).
2131
2132 2015-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>
2133
2134         Introduce UniquedStringImpl and SymbolImpl to separate symbolic strings from AtomicStringImpl
2135         https://bugs.webkit.org/show_bug.cgi?id=144848
2136
2137         Reviewed by Darin Adler.
2138
2139         Use UniquedStringImpl, SymbolImpl and AtomicStringImpl.
2140
2141         * API/JSCallbackObject.h:
2142         * builtins/BuiltinNames.h:
2143         (JSC::BuiltinNames::isPrivateName):
2144         * bytecode/BytecodeIntrinsicRegistry.h:
2145         * bytecode/CodeBlock.cpp:
2146         (JSC::CodeBlock::CodeBlock):
2147         * bytecode/ComplexGetStatus.cpp:
2148         (JSC::ComplexGetStatus::computeFor):
2149         * bytecode/ComplexGetStatus.h:
2150         * bytecode/GetByIdStatus.cpp:
2151         (JSC::GetByIdStatus::computeFromLLInt):
2152         (JSC::GetByIdStatus::computeFor):
2153         (JSC::GetByIdStatus::computeForStubInfo):
2154         * bytecode/GetByIdStatus.h:
2155         * bytecode/Instruction.h:
2156         (JSC::Instruction::Instruction):
2157         * bytecode/PutByIdStatus.cpp:
2158         (JSC::PutByIdStatus::computeFromLLInt):
2159         (JSC::PutByIdStatus::computeFor):
2160         (JSC::PutByIdStatus::computeForStubInfo):
2161         * bytecode/PutByIdStatus.h:
2162         * bytecompiler/BytecodeGenerator.cpp:
2163         (JSC::BytecodeGenerator::BytecodeGenerator):
2164         (JSC::BytecodeGenerator::visibleNameForParameter):
2165         (JSC::BytecodeGenerator::hasConstant):
2166         (JSC::BytecodeGenerator::addConstant):
2167         * bytecompiler/BytecodeGenerator.h:
2168         * bytecompiler/NodesCodegen.cpp:
2169         (JSC::PropertyListNode::emitBytecode):
2170         * dfg/DFGByteCodeParser.cpp:
2171         (JSC::DFG::ByteCodeParser::parseBlock):
2172         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2173         * dfg/DFGDesiredIdentifiers.cpp:
2174         (JSC::DFG::DesiredIdentifiers::addLazily):
2175         (JSC::DFG::DesiredIdentifiers::at):
2176         (JSC::DFG::DesiredIdentifiers::reallyAdd):
2177         * dfg/DFGDesiredIdentifiers.h:
2178         (JSC::DFG::DesiredIdentifiers::operator[]):
2179         * dfg/DFGFixupPhase.cpp:
2180         (JSC::DFG::FixupPhase::fixupNode):
2181         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
2182         * dfg/DFGSpeculativeJIT.cpp:
2183         (JSC::DFG::SpeculativeJIT::compileIn):
2184         * dfg/DFGSpeculativeJIT.h:
2185         (JSC::DFG::SpeculativeJIT::identifierUID):
2186         (JSC::DFG::SpeculativeJIT::callOperation):
2187         * ftl/FTLCompile.cpp:
2188         (JSC::FTL::mmAllocateDataSection):
2189         * ftl/FTLInlineCacheDescriptor.h:
2190         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
2191         (JSC::FTL::InlineCacheDescriptor::uid):
2192         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
2193         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
2194         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
2195         * ftl/FTLIntrinsicRepository.h:
2196         * ftl/FTLLowerDFGToLLVM.cpp:
2197         (JSC::FTL::LowerDFGToLLVM::compilePutById):
2198         (JSC::FTL::LowerDFGToLLVM::compileIn):
2199         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
2200         (JSC::FTL::LowerDFGToLLVM::getById):
2201         * ftl/FTLOperations.cpp:
2202         (JSC::FTL::operationMaterializeObjectInOSR):
2203         * ftl/FTLSlowPathCall.cpp:
2204         (JSC::FTL::callOperation):
2205         * ftl/FTLSlowPathCall.h:
2206         * jit/JIT.h:
2207         * jit/JITInlines.h:
2208         (JSC::JIT::callOperation):
2209         * jit/JITOperations.cpp:
2210         * jit/JITOperations.h:
2211         * parser/Nodes.cpp:
2212         (JSC::ProgramNode::setClosedVariables):
2213         * parser/Nodes.h:
2214         (JSC::ScopeNode::captures):
2215         (JSC::ScopeNode::setClosedVariables):
2216         (JSC::ProgramNode::closedVariables):
2217         * parser/Parser.cpp:
2218         (JSC::Parser<LexerType>::parseInner):
2219         (JSC::Parser<LexerType>::didFinishParsing):
2220         (JSC::Parser<LexerType>::parseContinueStatement):
2221         * parser/Parser.h:
2222         (JSC::Scope::Scope):
2223         (JSC::Scope::pushLabel):
2224         (JSC::Scope::getLabel):
2225         (JSC::Scope::declareCallee):
2226         (JSC::Scope::declareVariable):
2227         (JSC::Scope::declareParameter):
2228         (JSC::Scope::declareBoundParameter):
2229         (JSC::Scope::useVariable):
2230         (JSC::Scope::copyCapturedVariablesToVector):
2231         (JSC::Parser::closedVariables):
2232         (JSC::ScopeLabelInfo::ScopeLabelInfo): Deleted.
2233         * parser/SourceProviderCacheItem.h:
2234         (JSC::SourceProviderCacheItem::usedVariables):
2235         (JSC::SourceProviderCacheItem::writtenVariables):
2236         (JSC::SourceProviderCacheItem::create):
2237         * runtime/CommonIdentifiers.cpp:
2238         (JSC::CommonIdentifiers::isPrivateName):
2239         * runtime/CommonIdentifiers.h:
2240         * runtime/Identifier.h:
2241         (JSC::Identifier::impl):
2242         (JSC::Identifier::Identifier):
2243         (JSC::parseIndex):
2244         (JSC::IdentifierRepHash::hash):
2245         * runtime/IdentifierInlines.h:
2246         (JSC::Identifier::fromUid):
2247         * runtime/IntendedStructureChain.cpp:
2248         (JSC::IntendedStructureChain::mayInterceptStoreTo):
2249         * runtime/IntendedStructureChain.h:
2250         * runtime/JSGlobalObject.cpp:
2251         (JSC::JSGlobalObject::init):
2252         * runtime/Lookup.h:
2253         (JSC::HashTable::entry):
2254         * runtime/MapData.h:
2255         * runtime/ObjectConstructor.cpp:
2256         (JSC::objectConstructorGetOwnPropertySymbols):
2257         * runtime/PrivateName.h:
2258         (JSC::PrivateName::PrivateName):
2259         (JSC::PrivateName::uid):
2260         * runtime/PropertyMapHashTable.h:
2261         * runtime/PropertyName.h:
2262         (JSC::PropertyName::PropertyName):
2263         (JSC::PropertyName::uid):
2264         (JSC::PropertyName::publicName):
2265         (JSC::parseIndex):
2266         * runtime/PropertyNameArray.h:
2267         (JSC::PropertyNameArray::addKnownUnique):
2268         (JSC::PropertyNameArray::add):
2269         * runtime/Structure.cpp:
2270         (JSC::StructureTransitionTable::contains):
2271         (JSC::StructureTransitionTable::get):
2272         (JSC::StructureTransitionTable::add):
2273         (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
2274         (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
2275         (JSC::Structure::getConcurrently):
2276         (JSC::Structure::add):
2277         (JSC::Structure::remove):
2278         (JSC::Structure::toStructureShape):
2279         * runtime/Structure.h:
2280         (JSC::PropertyMapEntry::PropertyMapEntry):
2281         * runtime/StructureInlines.h:
2282         (JSC::Structure::getConcurrently):
2283         * runtime/StructureTransitionTable.h:
2284         (JSC::StructureTransitionTable::Hash::hash):
2285         * runtime/Symbol.cpp:
2286         (JSC::Symbol::Symbol):
2287         * runtime/Symbol.h:
2288         * runtime/SymbolConstructor.cpp:
2289         (JSC::symbolConstructorFor):
2290         (JSC::symbolConstructorKeyFor):
2291         * runtime/SymbolTable.cpp:
2292         (JSC::SymbolTable::uniqueIDForVariable):
2293         (JSC::SymbolTable::globalTypeSetForVariable):
2294         * runtime/SymbolTable.h:
2295         * runtime/TypeSet.cpp:
2296         (JSC::StructureShape::addProperty):
2297         (JSC::StructureShape::propertyHash):
2298         * runtime/TypeSet.h:
2299
2300 2015-05-21  Filip Pizlo  <fpizlo@apple.com>
2301
2302         Arguments elimination phase mishandles arity check failure in its reduction of LoadVarargs to GetStack/PutStacks
2303         https://bugs.webkit.org/show_bug.cgi?id=145298
2304
2305         Reviewed by Geoffrey Garen.
2306
2307         * dfg/DFGArgumentsEliminationPhase.cpp: Fix the bug. I restructured the loop to make it more obvious that we're initializing everything that we're supposed to initialize.
2308         * dfg/DFGNode.h: Add a comment to clarify something I was confused about while writing this code.
2309         * dfg/DFGPutStackSinkingPhase.cpp: Hacking on PutStacks made me think deep thoughts, and I added some FIXMEs.
2310         * tests/stress/fold-load-varargs-arity-check-fail-barely.js: Added. This test crashes or fails before this patch.
2311         * tests/stress/fold-load-varargs-arity-check-fail.js: Added. This is even more sure to crash or fail.
2312         * tests/stress/simplify-varargs-mandatory-minimum-smaller-than-limit.js: Added. Not sure if we had coverage for this case before.
2313
2314 2015-05-22  Basile Clement  <basile_clement@apple.com>
2315
2316         Allow DFGClobberize to return non-node constants that must be later created
2317         https://bugs.webkit.org/show_bug.cgi?id=145272
2318
2319         Reviewed by Filip Pizlo.
2320
2321         This adds a new LazyNode class in DFG that represents either a Node*,
2322         or a FrozenValue* with a way to convert it to a Node* provided a block
2323         to insert it into. DFGClobberize is converted to use LazyNode instead
2324         of Node* when def()'ing values, which allows to now define the array's
2325         length as well as the value of its various fields in NewArray and
2326         NewArrayBuffer nodes.
2327
2328         We also introduce a Vector<uint32_t> in DFG::Graph to collect all the
2329         values that can be used as index, in order to avoid def()'ing too many
2330         values at once for big NewArrayBuffers.
2331
2332         HeapLocation had to be updated to use a LazyNode as its index to be
2333         able to define array values.
2334
2335         * CMakeLists.txt:
2336         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2337         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2338         * JavaScriptCore.xcodeproj/project.pbxproj:
2339         * dfg/DFGCSEPhase.cpp:
2340         * dfg/DFGClobberize.h:
2341         (JSC::DFG::clobberize):
2342         (JSC::DFG::DefMethodClobberize::operator()):
2343         * dfg/DFGGraph.cpp:
2344         (JSC::DFG::Graph::freezeFragile):
2345         * dfg/DFGGraph.h:
2346         * dfg/DFGHeapLocation.h:
2347         (JSC::DFG::HeapLocation::HeapLocation):
2348         (JSC::DFG::HeapLocation::index):
2349         (JSC::DFG::HeapLocation::hash):
2350         * dfg/DFGLazyNode.cpp: Added.
2351         (JSC::DFG::LazyNode::dump):
2352         * dfg/DFGLazyNode.h: Added.
2353         (JSC::DFG::LazyNode::LazyNode):
2354         (JSC::DFG::LazyNode::setNode):
2355         (JSC::DFG::LazyNode::isHashTableDeletedValue):
2356         (JSC::DFG::LazyNode::isNode):
2357         (JSC::DFG::LazyNode::op):
2358         (JSC::DFG::LazyNode::asNode):
2359         (JSC::DFG::LazyNode::asValue):
2360         (JSC::DFG::LazyNode::hash):
2361         (JSC::DFG::LazyNode::operator==):
2362         (JSC::DFG::LazyNode::operator!=):
2363         (JSC::DFG::LazyNode::ensureIsNode):
2364         (JSC::DFG::LazyNode::operator->):
2365         (JSC::DFG::LazyNode::operator*):
2366         (JSC::DFG::LazyNode::operator!):
2367         (JSC::DFG::LazyNode::operator UnspecifiedBoolType*):
2368         (JSC::DFG::LazyNode::setFrozenValue):
2369         * dfg/DFGPreciseLocalClobberize.h:
2370         (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
2371         * dfg/DFGPutStackSinkingPhase.cpp:
2372
2373 2015-05-22  Andreas Kling  <akling@apple.com>
2374
2375         [JSC] Speed up new array construction in Array.prototype.splice().
2376         <https://webkit.org/b/145303>
2377
2378         Reviewed by Benjamin Poulain.
2379
2380         Give splice() a fast path just like slice(), for indexing types where the backing
2381         store can be memcpy'd. I generalized JSArray::fastSlice() a little bit so it works
2382         for this optimization as well.
2383
2384         7% progression on Kraken/stanford-crypto-pbkdf2.
2385
2386         * runtime/JSArray.h:
2387         * runtime/JSArray.cpp:
2388         (JSC::JSArray::fastSlice): Tweak this to return JSArray*, and don't bother throwing
2389         out-of-memory exceptions. Let the caller worry about that.
2390
2391         * runtime/ArrayPrototype.cpp:
2392         (JSC::arrayProtoFuncSlice): Update for fastSlice() changes.
2393         (JSC::arrayProtoFuncSplice): If the object we're splicing out of is a bona fide
2394         JSArray, use fastSlice() to create the returned array instead of doing a generic
2395         get/put loop.
2396
2397 2015-05-21  Filip Pizlo  <fpizlo@apple.com>
2398
2399         CPS rethreading should really get rid of GetLocals
2400         https://bugs.webkit.org/show_bug.cgi?id=145290
2401
2402         Reviewed by Benjamin Poulain.
2403         
2404         CPS rethreading is intended to get rid of redundant GetLocals. CSE can also do it, but
2405         the idea is that you should be able to disable CSE and everything would still work. This
2406         fixes a bug in CPS rethreading's GetLocal elimination: we should be calling replaceWith
2407         rather than setReplacement, since setReplacement still leaves the original node.
2408
2409         * dfg/DFGCPSRethreadingPhase.cpp:
2410         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): Fix the bug.
2411         * dfg/DFGFixupPhase.cpp:
2412         (JSC::DFG::FixupPhase::fixupNode): Eliminating GetLocals means that they turn into Check. We should handle Checks that have zero inputs.
2413         * dfg/DFGValidate.cpp:
2414         (JSC::DFG::Validate::validateCPS): Add a validation for what a GetLocal should look like in ThreadedCPS.
2415         * tests/stress/get-local-elimination.js: Added.
2416         (foo):
2417
2418 2015-05-21  Saam Barati  <saambarati1@gmail.com>
2419
2420         Object allocation sinking phase should explicitly create bottom values for CreateActivation sink candidates and CreateActivation should have SymbolTable as a child node
2421         https://bugs.webkit.org/show_bug.cgi?id=145192
2422
2423         Reviewed by Filip Pizlo.
2424
2425         When we sink CreateActivation and generate MaterializeCreateActivation
2426         in the object allocation sinking phase, we now explictly add PutHints for 
2427         all variables on the activation setting those variables to their default value 
2428         (undefined for Function activations and soon to be JS Empty Value for block scope activations). 
2429         This allows us to remove code that fills FTL fast activation allocations with Undefined.
2430
2431         This patch also adds the constant SymbolTable as an OpInfo of CreateActivation and MaterializeCreateActivation
2432         nodes. This is in preparation for ES6 block scoping which will introduce a new 
2433         op code that gets lowered to CreateActivation.
2434
2435         * dfg/DFGByteCodeParser.cpp:
2436         (JSC::DFG::ByteCodeParser::parseBlock):
2437         * dfg/DFGClobberize.h:
2438         (JSC::DFG::clobberize):
2439         * dfg/DFGNode.h:
2440         (JSC::DFG::Node::hasCellOperand):
2441         (JSC::DFG::Node::cellOperand):
2442         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2443         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2444         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2445         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2446         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2447         * dfg/DFGPromotedHeapLocation.cpp:
2448         (WTF::printInternal):
2449         * dfg/DFGPromotedHeapLocation.h:
2450         * dfg/DFGSpeculativeJIT.cpp:
2451         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
2452         * ftl/FTLLowerDFGToLLVM.cpp:
2453         (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
2454         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
2455         * ftl/FTLOperations.cpp:
2456         (JSC::FTL::operationMaterializeObjectInOSR):
2457         * tests/stress/activation-sink-default-value.js: Added.
2458         (bar):
2459         * tests/stress/activation-sink-osrexit-default-value.js: Added.
2460         (foo.set result):
2461
2462 2015-05-21  Per Arne Vollan  <peavo@outlook.com>
2463
2464         MSVC internal compiler error when compiling TemplateRegistryKey class.
2465         https://bugs.webkit.org/show_bug.cgi?id=145259
2466
2467         Reviewed by Alex Christensen.
2468
2469         MSVC is not able to handle the brace initialization of a class member in this case.
2470
2471         * runtime/TemplateRegistryKey.h:
2472
2473 2015-05-21  Csaba Osztrogonác  <ossy@webkit.org>
2474
2475         Fix the !ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) build after r184337
2476         https://bugs.webkit.org/show_bug.cgi?id=145248
2477
2478         Reviewed by Yusuke Suzuki.
2479
2480         * bytecompiler/BytecodeGenerator.cpp:
2481         * bytecompiler/BytecodeGenerator.h:
2482         * parser/Parser.cpp:
2483         (JSC::Parser<LexerType>::parseMemberExpression):
2484
2485 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
2486
2487         Web Inspector: array previews should have a much smaller cap on values
2488         https://bugs.webkit.org/show_bug.cgi?id=145195
2489
2490         Reviewed by Timothy Hatcher.
2491
2492         * inspector/InjectedScriptSource.js:
2493         (InjectedScript.RemoteObject.prototype._generatePreview):
2494         Reduce the indexes threshold for previews.
2495
2496 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
2497
2498         Web Inspector: Use native Arguments detection instead of using toString
2499         https://bugs.webkit.org/show_bug.cgi?id=145235
2500
2501         Reviewed by Timothy Hatcher.
2502
2503         * inspector/InjectedScriptSource.js:
2504         (InjectedScript.prototype._subtype):
2505         Deleted the old string code.
2506
2507         * inspector/JSInjectedScriptHost.cpp:
2508         (Inspector::JSInjectedScriptHost::subtype):
2509         Replaced with a stricter, more accurate check.
2510
2511 2015-05-20  Andreas Kling  <akling@apple.com>
2512
2513         Remove unused MarkedBlock::m_rememberedSet.
2514         <https://webkit.org/b/145224>
2515
2516         Reviewed by Mark Hahnenberg.
2517
2518         The MarkedBlock had a copy of the remembered bit for each of its cells,
2519         and we were maintaining that bitmap despite no one actually ever consulting it.
2520
2521         This patch removes MarkedBlock::m_rememberedSet, freeing up 128 bytes in each
2522         block and making write barriers a little faster.
2523
2524         * heap/Heap.cpp:
2525         (JSC::Heap::clearRememberedSet):
2526         (JSC::Heap::addToRememberedSet):
2527         * heap/HeapInlines.h:
2528         (JSC::Heap::isRemembered):
2529         * heap/MarkedBlock.cpp:
2530         (JSC::MarkedBlock::clearRememberedSet): Deleted.
2531         (JSC::MarkedBlock::clearMarksWithCollectionType):
2532         * heap/MarkedBlock.h:
2533         (JSC::MarkedBlock::setRemembered): Deleted.
2534         (JSC::MarkedBlock::clearRemembered): Deleted.
2535         (JSC::MarkedBlock::atomicClearRemembered): Deleted.
2536         (JSC::MarkedBlock::isRemembered): Deleted.
2537         * heap/MarkedSpace.h:
2538         (JSC::ClearRememberedSet::operator()): Deleted.
2539         (JSC::MarkedSpace::clearRememberedSet): Deleted.
2540
2541 2015-05-20  Andreas Kling  <akling@apple.com>
2542
2543         Eden collections should extend the IncrementalSweeper work list, not replace it.
2544         <https://webkit.org/b/145213>
2545         <rdar://problem/21002666>
2546
2547         Reviewed by Geoffrey Garen.
2548
2549         After an eden collection, the garbage collector was adding all MarkedBlocks containing
2550         new objects to the IncrementalSweeper's work list, to make sure they didn't have to
2551         wait until the next full collection before getting swept.
2552
2553         Or at least, that's what it thought it was doing. It turns out that IncrementalSweeper's
2554         internal work list is really just a reference to Heap::m_blockSnapshot. I didn't realize
2555         this when writing the post-eden sweep code, and instead made eden collections cancel
2556         all pending sweeps and *replace* them with the list of blocks with new objects.
2557
2558         This made it so that rapidly occurring eden collections could prevent large numbers of
2559         heap blocks from ever getting swept. This would manifest as accumulation of MarkedBlocks
2560         when a system under heavy load was also allocating short lived objects at a high rate.
2561         Things would eventually get cleaned up when there was a lull and a full collection was
2562         allowed to run its heap sweep to completion.
2563
2564         Fix this by moving all management of the block snapshot to Heap. snapshotMarkedSpace()
2565         now handles eden collections by merging the list of blocks with new objects into the
2566         existing block snapshot.
2567
2568         * heap/Heap.cpp:
2569         (JSC::Heap::snapshotMarkedSpace):
2570         (JSC::Heap::notifyIncrementalSweeper):
2571         * heap/IncrementalSweeper.cpp:
2572         (JSC::IncrementalSweeper::startSweeping):
2573         (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Deleted.
2574         * heap/IncrementalSweeper.h:
2575
2576 2015-05-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2577
2578         AudioContext resume/close/suspend should reject promises with a DOM exception in lieu of throwing exceptions
2579         https://bugs.webkit.org/show_bug.cgi?id=145064
2580
2581         Reviewed by Darin Adler.
2582
2583         Added default message for TypeError.
2584
2585         * runtime/Error.cpp:
2586         (JSC::throwTypeError):
2587         * runtime/Error.h:
2588
2589 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
2590
2591         No LLInt Test Failure: jsc-layout-tests.yaml/js/script-tests/object-literal-duplicate-properties.js.layout-no-llint
2592         https://bugs.webkit.org/show_bug.cgi?id=145219
2593
2594         Reviewed by Mark Lam.
2595
2596         * jit/JITOperations.cpp:
2597         Throw the error we just got, instead of a stack overflow exception.
2598         This matches other error handling for callers of prepareForExecution.
2599
2600 2015-05-19  Filip Pizlo  <fpizlo@apple.com>
2601
2602         Add some assertions about the CFG in the loop pre-header creation phase
2603         https://bugs.webkit.org/show_bug.cgi?id=145205
2604
2605         Reviewed by Geoffrey Garen.
2606         
2607         * dfg/DFGByteCodeParser.cpp:
2608         (JSC::DFG::ByteCodeParser::currentNodeOrigin): Add a FIXME.
2609         * dfg/DFGLICMPhase.cpp:
2610         (JSC::DFG::LICMPhase::run): Add a FIXME.
2611         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
2612         (JSC::DFG::LoopPreHeaderCreationPhase::run): Add the assertions.
2613
2614 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
2615
2616         ES6: Implement Object.setPrototypeOf
2617         https://bugs.webkit.org/show_bug.cgi?id=145202
2618
2619         Reviewed by Darin Adler.
2620
2621         * runtime/JSGlobalObjectFunctions.h:
2622         * runtime/JSGlobalObjectFunctions.cpp:
2623         (JSC::globalFuncProtoSetter):
2624         (JSC::checkProtoSetterAccessAllowed):
2625         Extract a helper to share this code between __proto__ setter and setPrototypeOf.
2626
2627         * runtime/ObjectConstructor.cpp:
2628         (JSC::objectConstructorSetPrototypeOf):
2629         Implementation is very similiar to __proto__ setter.
2630
2631 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
2632
2633         ES6: Should not allow duplicate basic __proto__ properties in Object Literals
2634         https://bugs.webkit.org/show_bug.cgi?id=145138
2635
2636         Reviewed by Darin Adler.
2637
2638         Implement ES6 Annex B.3.1, which disallows duplicate basic __proto__
2639         properties in object literals. This doesn't affect computed properties,
2640         shorthand properties, or getters/setters all of which avoid setting
2641         the actual prototype of the object anyway.
2642
2643         * interpreter/Interpreter.cpp:
2644         (JSC::eval):
2645         Remove out of date comment. Duplicate property names are allowed
2646         now in ES6, they were not in ES5 strict mode.
2647
2648         * parser/ASTBuilder.h:
2649         (JSC::ASTBuilder::getName):
2650         (JSC::ASTBuilder::getType):
2651         * parser/SyntaxChecker.h:
2652         (JSC::SyntaxChecker::getName):
2653         Add back getName to get the property name depending on the tree builder.
2654         Also tighten up the parameter types.
2655
2656         * runtime/LiteralParser.cpp:
2657         (JSC::LiteralParser<CharType>::parse):
2658         In quick JSON literal parsing for eval, we actually need to evaluate
2659         the __proto__ property assignment, instead of just building up a list
2660         of direct properties. Only do this when not doing a strict JSON parse.
2661
2662         * parser/Nodes.h:
2663         Add "Shorthand" to the list of PropertyNode types to allow it to
2664         be distinguished without relying on other information.
2665
2666         * parser/Parser.h:
2667         * parser/Parser.cpp:
2668         (JSC::Parser<LexerType>::parseProperty):
2669         Add the Shorthand type when parsing a shorthand property.
2670
2671         (JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
2672         (JSC::Parser<LexerType>::parseObjectLiteral):
2673         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
2674         Check for duplicate __proto__ properties, and throw a SyntaxError
2675         if that was the case.
2676
2677 2015-05-20  Csaba Osztrogonác  <ossy@webkit.org>
2678
2679         [JSC] Add missing copyrights and licenses for some scripts
2680         https://bugs.webkit.org/show_bug.cgi?id=145044
2681
2682         Reviewed by Darin Adler.
2683
2684         * build-symbol-table-index.py:
2685         * create-llvm-ir-from-source-file.py:
2686         * create-symbol-table-index.py:
2687
2688 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
2689
2690         Web Inspector: Slightly better node previews in arrays
2691         https://bugs.webkit.org/show_bug.cgi?id=145188
2692
2693         Reviewed by Timothy Hatcher.
2694
2695         * inspector/InjectedScriptSource.js:
2696         (InjectedScript.prototype._nodeDescription):
2697         (InjectedScript.prototype._nodePreview):
2698         Different stringified representations for a basic object description or in a preview.
2699
2700         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
2701         Use the node preview string representation inside previews.
2702
2703 2015-05-19  Commit Queue  <commit-queue@webkit.org>
2704
2705         Unreviewed, rolling out r184613 and r184614.
2706         https://bugs.webkit.org/show_bug.cgi?id=145206
2707
2708         Broke 10 tests :| (Requested by kling on #webkit).
2709
2710         Reverted changesets:
2711
2712         "[JSC] Speed up URL encode/decode by using bitmaps instead of
2713         strchr()."
2714         https://bugs.webkit.org/show_bug.cgi?id=145115
2715         http://trac.webkit.org/changeset/184613
2716
2717         "[JSC] Speed up URL encode/decode by using bitmaps instead of
2718         strchr()."
2719         https://bugs.webkit.org/show_bug.cgi?id=145115
2720         http://trac.webkit.org/changeset/184614
2721
2722 2015-05-19  Andreas Kling  <akling@apple.com>
2723
2724         Give StringView a utf8() API.
2725         <https://webkit.org/b/145201>
2726
2727         Reviewed by Anders Carlsson.
2728
2729         Use JSString::view() in a few places where we couldn't before due to StringView
2730         lacking a utf8() API. This is a minor speed-up on Kraken's crypto subtests,
2731         which like to call encode() with substring JSStrings.
2732
2733         * jsc.cpp:
2734         (functionPrint):
2735         (functionDebug):
2736         * runtime/JSGlobalObjectFunctions.cpp:
2737         (JSC::encode):
2738
2739 2015-05-19  Andreas Kling  <akling@apple.com>
2740
2741         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
2742         <https://webkit.org/b/145115>
2743
2744         Incorporate review feedback from Darin, removing some unnecessary zero checks.
2745
2746         * runtime/JSGlobalObjectFunctions.cpp:
2747         (JSC::encode):
2748         (JSC::decode):
2749         (JSC::globalFuncEscape):
2750
2751 2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
2752
2753         Move AtomicStringImpl table related operations from AtomicString to AtomicStringImpl
2754         https://bugs.webkit.org/show_bug.cgi?id=145109
2755
2756         Reviewed by Darin Adler.
2757
2758         * bytecode/CodeBlock.cpp:
2759         (JSC::CodeBlock::nameForRegister):
2760         * runtime/Identifier.cpp:
2761         (JSC::Identifier::add):
2762         (JSC::Identifier::add8):
2763         * runtime/Identifier.h:
2764         (JSC::Identifier::add):
2765         * runtime/IdentifierInlines.h:
2766         (JSC::Identifier::Identifier):
2767         (JSC::Identifier::add):
2768         * runtime/JSString.cpp:
2769         (JSC::JSRopeString::resolveRopeToExistingAtomicString):
2770         * runtime/JSString.h:
2771         (JSC::JSString::toExistingAtomicString):
2772         * runtime/SmallStrings.cpp:
2773         (JSC::SmallStringsStorage::SmallStringsStorage):
2774         * runtime/TypeSet.cpp:
2775         (JSC::StructureShape::propertyHash):
2776
2777 2015-05-19  Joseph Pecoraro  <pecoraro@apple.com>
2778
2779         Web Inspector: Improve Preview for NodeList / array like collections
2780         https://bugs.webkit.org/show_bug.cgi?id=145177
2781
2782         Reviewed by Timothy Hatcher.
2783
2784         * inspector/InjectedScriptSource.js:
2785         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
2786         For "array" like object previews skip over non-index properties.
2787         We are not marking the object as lossless by choice, but we
2788         may return to this decision later.
2789
2790 2015-05-19  Michael Saboff  <msaboff@apple.com>
2791
2792         REGRESSION(183787): JIT is enabled for all builds
2793         https://bugs.webkit.org/show_bug.cgi?id=145179
2794
2795         Reviewed by Geoffrey Garen.
2796
2797         Eliminated the setting of ENABLE_JIT, as wtf/Platform.h has appropriate logic to
2798         set it depending on OS and CPU type.
2799
2800         * Configurations/FeatureDefines.xcconfig:
2801
2802 2015-05-19  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2803
2804         Rename createIterResultObject as createIteratorResultObject
2805         https://bugs.webkit.org/show_bug.cgi?id=145116
2806
2807         Reviewed by Darin Adler.
2808
2809         Renamed createIterResultObject as createIteratorResultObject.
2810         Made this function exportable for future use by streams API.
2811
2812         * runtime/IteratorOperations.cpp:
2813         (JSC::createIteratorResultObject):
2814         * runtime/IteratorOperations.h:
2815         * runtime/MapIteratorPrototype.cpp:
2816         (JSC::MapIteratorPrototypeFuncNext):
2817         * runtime/SetIteratorPrototype.cpp:
2818         (JSC::SetIteratorPrototypeFuncNext):
2819
2820 2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
2821
2822         Array.prototype methods must use ToLength
2823         https://bugs.webkit.org/show_bug.cgi?id=144128
2824
2825         Reviewed by Oliver Hunt.
2826
2827         Patch by Jordan Harband  <ljharb@gmail.com> and Yusuke Suzuki <utatane.tea@gmail.com>
2828
2829         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
2830
2831         This patch introduces ToLength and ToInteger JS implementation to encourage the DFG/FTL's inlining.
2832         These implementations are located in GlobalObject.js.
2833         And set to the JSGlobalObject with the private symbols @ToLength and @ToInteger manually.
2834
2835         * builtins/Array.prototype.js:
2836         (every):
2837         (forEach):
2838         (filter):
2839         (map):
2840         (some):
2841         (fill):
2842         (find):
2843         (findIndex):
2844         (includes):
2845         * builtins/ArrayConstructor.js:
2846         (from):
2847         * builtins/GlobalObject.js: Copied from Source/JavaScriptCore/builtins/StringConstructor.js.
2848         (ToInteger):
2849         (ToLength):
2850         * builtins/StringConstructor.js:
2851         (raw):
2852         * runtime/JSGlobalObject.cpp:
2853         (JSC::JSGlobalObject::init):
2854         * runtime/JSGlobalObjectFunctions.h:
2855
2856 2015-05-19  Mark Lam  <mark.lam@apple.com>
2857
2858         Fix the build of a universal binary with ARMv7k of JavaScriptCore.
2859         https://bugs.webkit.org/show_bug.cgi?id=145143
2860
2861         Reviewed by Geoffrey Garen.
2862
2863         The offlineasm works in 3 phases:
2864
2865         Phase 1:
2866            Parse the llint asm files for config options and desired offsets.
2867            Let's say the offlineasm discovers C unique options and O unique offsets.
2868            The offlineasm will then generate a LLIntDesiredOffsets.h file with
2869            C x C build configurations, each with a set of O offsets.
2870
2871            Each of these build configurations is given a unique configuration index number.
2872
2873         Phase 2: 
2874            Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.
2875
2876            If we're building a fat binary with 2 configurations: armv7, and armv7k,
2877            then the fat binary will contain 2 blobs of offsets, one for each of these
2878            build configurations.
2879
2880         Phase 3:
2881            Parse the llint asm files and emit asm code using the offsets that are
2882            extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
2883            configuration index number.
2884
2885         In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
2886         source.  As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
2887         the set of C unique options.
2888
2889         For armv7k builds, OFFLINE_ASM_ARMv7 is also true.  As a result, for an armv7k
2890         target, we will end up building armv7 source.  In general, this is fine except:
2891
2892         1. armv7k has different alignment requirements from armv7.  Hence, their offset
2893            values (in JSCLLIntOffsetsExtractor) will be different.
2894
2895         2. The offlineasm was never told that it needed to make a different configuration
2896            for armv7k builds.  Hence, the armv7k build of LLIntDesiredOffsets.h will
2897            build the armv7 configuration, and consequently, the armv7k blob of offsets in
2898            JSCLLIntOffsetsExtractor will have the same configuration index number as
2899            the armv7 blob of offsets.
2900
2901         In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
2902         looking for the armv7 build's configuration index number, it discovers the
2903         armv7k blob which has the same configuration number.  As a result, it
2904         erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
2905         Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
2906         and all round badness.
2907
2908         The fix is to add a simple "if ARMv7k" statement to the llint asm files.  While
2909         the if statement has no body, it does make the offlineasm aware of the need for
2910         ARMv7k as a configuration option.  As a result, it will generate an armv7k
2911         variant configuration in the LLIntDesiredOffsets.h file with its own unique
2912         configuration index number.  With that, the JSCLLIntOffsetsExtractor fat binary
2913         will no longer have duplicate configuration index numbers for the armv7 and
2914         armv7k blobs of offsets, and the issue is resolved.
2915
2916         * llint/LLIntOfflineAsmConfig.h:
2917         * llint/LowLevelInterpreter.asm:
2918
2919 2015-05-19  Andreas Kling  <akling@apple.com>
2920
2921         Give JSString a StringView getter and start using it.
2922         <https://webkit.org/b/145131>
2923
2924         Reviewed by Anders Carlsson.
2925
2926         When JSString is a substring internally, calling value(ExecState*) on it
2927         will reify the baseString/start/length tuple into a new StringImpl.
2928
2929         For clients that only want to look at the characters of a JSString, but
2930         don't actually need a reffable StringImpl, adding a light-weight StringView
2931         getter lets them avoid constructing anything.
2932
2933         This patch adds JSString::view(ExecState*) and uses it in a few places.
2934         There are many more opportunities to use this API, but let's do a few things
2935         at a time.
2936
2937         * runtime/FunctionConstructor.cpp:
2938         (JSC::constructFunctionSkippingEvalEnabledCheck):
2939         * runtime/JSGlobalObjectFunctions.cpp:
2940         (JSC::decode):
2941         (JSC::parseInt):
2942         (JSC::jsToNumber):
2943         (JSC::parseFloat):
2944         (JSC::globalFuncParseInt):
2945         (JSC::globalFuncParseFloat):
2946         (JSC::globalFuncEscape):
2947         (JSC::globalFuncUnescape):
2948         * runtime/JSGlobalObjectFunctions.h:
2949         * runtime/JSONObject.cpp:
2950         (JSC::JSONProtoFuncParse):
2951         * runtime/JSString.cpp:
2952         (JSC::JSString::getPrimitiveNumber):
2953         (JSC::JSString::toNumber):
2954         * runtime/JSString.h:
2955         (JSC::JSRopeString::view):
2956         (JSC::JSString::view):
2957
2958 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
2959
2960         Better optimize 'if' with ternaries conditional tests.
2961         https://bugs.webkit.org/show_bug.cgi?id=144136
2962
2963         Reviewed by Benjamin Poulain.
2964         
2965         This is the last fix I'll do for this for now. BooleanToNumber(Untyped:) where the input
2966         is proved to be either BoolInt32 or Boolean should be optimized to just masking the
2967         lowest bit.
2968         
2969         This is another 37% speed-up on JSRegress/slow-ternaries.
2970
2971         * dfg/DFGSpeculativeJIT32_64.cpp:
2972         (JSC::DFG::SpeculativeJIT::compile):
2973         * dfg/DFGSpeculativeJIT64.cpp:
2974         (JSC::DFG::SpeculativeJIT::compile):
2975         * ftl/FTLLowerDFGToLLVM.cpp:
2976         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
2977
2978 2015-05-18  Benjamin Poulain  <bpoulain@apple.com>
2979
2980         <rdar://problem/21003555> cloberrize() is wrong for ArithRound because it doesn't account for the arith mode
2981         https://bugs.webkit.org/show_bug.cgi?id=145147
2982
2983         Reviewed by Filip Pizlo.
2984
2985         Really stupid bug: ArithRound nodes with different rounding modes
2986         were not distinguished and CSE would happily unify with a node of
2987         a different rounding mode.
2988
2989         DFG::clobberize() already support additional data but I was not using it.
2990
2991         * dfg/DFGClobberize.h:
2992         (JSC::DFG::clobberize):
2993         * tests/stress/math-round-arith-rounding-mode.js: Added.
2994         (firstCareAboutZeroSecondDoesNot):
2995         (firstDoNotCareAboutZeroSecondDoes):
2996         (warmup):
2997         (verifyNegativeZeroIsPreserved):
2998
2999 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
3000
3001         Add SpecBoolInt32 type that means "I'm an int and I'm either 0 or 1"
3002         https://bugs.webkit.org/show_bug.cgi?id=145137
3003
3004         Reviewed by Benjamin Poulain.
3005         
3006         It's super useful to know if an integer value could be either zero or one. We have an
3007         immediate need for this because of Int32|Boolean uses, where knowing that the Int32 is
3008         either 0 or 1 means that there is no actual polymorphism if you just look at the low bit
3009         (1 behaves like true, 0 behaves like false, and the low bit of 1|true is 1, and the low
3010         bit of 0|false is 0).
3011         
3012         We do this by splitting the SpecInt32 type into SpecBoolInt32 and SpecNonBoolInt32. This
3013         change doesn't have any effect on behavior, yet. But it does give us the ability to
3014         predict and prove when values are SpecBoolInt32; it's just we don't leverage this yet.
3015         
3016         This is perf-neutral.
3017
3018         * bytecode/SpeculatedType.cpp:
3019         (JSC::dumpSpeculation):
3020         (JSC::speculationToAbbreviatedString):
3021         (JSC::speculationFromValue):
3022         * bytecode/SpeculatedType.h:
3023         (JSC::isStringOrStringObjectSpeculation):
3024         (JSC::isBoolInt32Speculation):
3025         (JSC::isInt32Speculation):
3026         (JSC::isInt32OrBooleanSpeculation):
3027         * dfg/DFGAbstractInterpreterInlines.h:
3028         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3029
3030 2015-05-18  Michael Catanzaro  <mcatanzaro@igalia.com>
3031
3032         [CMake] Ignore warnings in system headers
3033         https://bugs.webkit.org/show_bug.cgi?id=144747
3034
3035         Reviewed by Darin Adler.
3036
3037         Separate include directories into WebKit project includes and system includes. Suppress all
3038         warnings from headers in system include directories using the SYSTEM argument to
3039         the include_directories command.
3040
3041         * CMakeLists.txt:
3042         * PlatformGTK.cmake:
3043
3044 2015-05-18  Skachkov Alexandr  <gskachkov@gmail.com>
3045
3046         [ES6] Arrow function syntax. Feature flag for arrow function
3047         https://bugs.webkit.org/show_bug.cgi?id=145108
3048
3049         Reviewed by Ryosuke Niwa.
3050
3051         Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function
3052
3053         * Configurations/FeatureDefines.xcconfig:
3054         
3055 2015-05-18  Benjamin Poulain  <benjamin@webkit.org>
3056
3057         [JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
3058         https://bugs.webkit.org/show_bug.cgi?id=145092
3059
3060         Reviewed by Filip Pizlo.
3061
3062         When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
3063         we get the inside loop driving the tierUpCounter and we have very little chance of
3064         doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
3065         up in the outer loop and OSR Enter there.
3066
3067         This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.
3068
3069         To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
3070         enter their CheckTierUp regardless of the tier-up counter.
3071
3072         * bytecode/ExecutionCounter.cpp:
3073         (JSC::ExecutionCounter<countingVariant>::setThreshold):
3074         This is somewhat unrelated. This assertion is incorrect because it relies on
3075         m_counter, which changes on an other thread.
3076
3077         I have hit it a couple of times with this patch because we are a bit more aggressive
3078         on CheckTierUp. What happens is:
3079         1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
3080            hasCrossedThreshold(), and it is false.
3081         2) On the main thread, the hot loops keeps running and the counter becomes large
3082            enough to cross the threshold.
3083         3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
3084            test, setThreshold(), where the assertion is. Since the counter is now large enough,
3085            the assertion fails.
3086
3087         * dfg/DFGAbstractInterpreterInlines.h:
3088         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3089         * dfg/DFGClobberize.h:
3090         (JSC::DFG::clobberize):
3091         * dfg/DFGDoesGC.cpp:
3092         (JSC::DFG::doesGC):
3093         * dfg/DFGFixupPhase.cpp:
3094         (JSC::DFG::FixupPhase::fixupNode):
3095
3096         * dfg/DFGJITCode.h:
3097         I used a uint8_t instead of a boolean to make the code generation clearer
3098         in DFGSpeculativeJIT64.
3099
3100         * dfg/DFGNodeType.h:
3101         * dfg/DFGOperations.cpp:
3102         * dfg/DFGOperations.h:
3103
3104         * dfg/DFGPredictionPropagationPhase.cpp:
3105         (JSC::DFG::PredictionPropagationPhase::propagate):
3106         This is a bit annoying: we have the NaturalLoops analysis that provides us
3107         everything we need to know about loops, but the TierUpCheck are conservative
3108         and set on LoopHint.
3109
3110         To make the two work together, we first find all the CheckTierUp that cannot
3111         OSR enter and we keep a list of all the natural loops containing them.
3112
3113         Then we do a second pass over the LoopHints, get their NaturalLoop, and check
3114         if it contains a loop that cannot OSR enter.
3115
3116         * dfg/DFGSafeToExecute.h:
3117         (JSC::DFG::safeToExecute):
3118         * dfg/DFGSpeculativeJIT32_64.cpp:
3119         (JSC::DFG::SpeculativeJIT::compile):
3120         * dfg/DFGSpeculativeJIT64.cpp:
3121         (JSC::DFG::SpeculativeJIT::compile):
3122         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3123         (JSC::DFG::TierUpCheckInjectionPhase::run):
3124         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
3125
3126 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
3127
3128         Add a Int-or-Boolean speculation to Branch
3129         https://bugs.webkit.org/show_bug.cgi?id=145134
3130
3131         Reviewed by Benjamin Poulain.
3132         
3133         After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
3134         int-or-boolean optimization that we already do everywhere else.
3135
3136         * dfg/DFGFixupPhase.cpp:
3137         (JSC::DFG::FixupPhase::fixupNode):
3138
3139 2015-05-18  Andreas Kling  <akling@apple.com>
3140
3141         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
3142         <https://webkit.org/b/145115>
3143
3144         Reviewed by Anders Carlsson.
3145
3146         We were calling strchr() for every character when doing URL encoding/decoding and it stood out
3147         like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
3148
3149         5.5% progression on Kraken/stanford-crypto-sha256-iterative.
3150
3151         * runtime/JSGlobalObjectFunctions.cpp:
3152         (JSC::makeCharacterBitmap):
3153         (JSC::encode):
3154         (JSC::decode):
3155         (JSC::globalFuncDecodeURI):
3156         (JSC::globalFuncDecodeURIComponent):
3157         (JSC::globalFuncEncodeURI):
3158         (JSC::globalFuncEncodeURIComponent):
3159         (JSC::globalFuncEscape):
3160
3161 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
3162
3163         Do not use fastMallocGoodSize anywhere
3164         https://bugs.webkit.org/show_bug.cgi?id=145103
3165
3166         Reviewed by Michael Saboff.
3167
3168         * assembler/AssemblerBuffer.h:
3169         (JSC::AssemblerData::AssemblerData):
3170         (JSC::AssemblerData::grow):
3171
3172 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
3173
3174         [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
3175         https://bugs.webkit.org/show_bug.cgi?id=145102
3176
3177         Reviewed by Darin Adler.
3178
3179         In general, the array targeted by Array.toString() or Array.join() are pretty
3180         simple. In those simple cases, we spend as much time in StringRecursionChecker
3181         as we do on the actual operation.
3182
3183         The reason for this is the HashSet stringRecursionCheckVisitedObjects used
3184         to detect recursion. We are constantly adding and removing objects which
3185         dirty buckets and force constant rehash.
3186
3187         This patch adds a simple shortcut for those simple case: in addition to the HashSet,
3188         we keep a pointer to the root object of the recursion.
3189         In the vast majority of cases, we no longer touch the HashSet at all.
3190
3191         This patch is a 12% progression on the overall score of ArrayWeighted.
3192
3193         * runtime/StringRecursionChecker.h:
3194         (JSC::StringRecursionChecker::performCheck):
3195         (JSC::StringRecursionChecker::~StringRecursionChecker):
3196         * runtime/VM.h:
3197
3198 2015-05-17  Filip Pizlo  <fpizlo@apple.com>
3199
3200         Insert store barriers late so that IR transformations don't have to worry about them
3201         https://bugs.webkit.org/show_bug.cgi?id=145015
3202
3203         Reviewed by Geoffrey Garen.
3204         
3205         We have had three kinds of bugs with store barriers. For the sake of discussion we say
3206         that a store barrier is needed when we have something like:
3207         
3208             base.field = value
3209         
3210         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
3211           This might happen if we prove value to be a non-cell even though in the FixupPhase it
3212           wasn't predicted non-cell.
3213         
3214         - We sometimes have a barrier in the wrong place after object allocation sinking. We
3215           might sink an allocation to just above the store, but that puts it just after the
3216           StoreBarrier that FixupPhase inserted.
3217         
3218         - We don't remove redundant barriers across basic blocks.
3219         
3220         This comprehensively fixes these issues by doing store barrier insertion late, and
3221         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
3222         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
3223         base is in the current GC epoch (i.e. was the last object that we allocated or had a
3224         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
3225         always been allocated before base). We do conservative things when merging epoch state
3226         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
3227         queries AI to determine what type we've proved about value, and avoids barriers when
3228         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
3229         the likelihood that this AI-based removal is effective.
3230         
3231         Rolling back in after fixing some debug build test failures.
3232
3233         * CMakeLists.txt:
3234         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3235         * JavaScriptCore.xcodeproj/project.pbxproj:
3236         * dfg/DFGBlockMap.h:
3237         (JSC::DFG::BlockMap::at):
3238         * dfg/DFGConstantFoldingPhase.cpp:
3239         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
3240         * dfg/DFGEpoch.h:
3241         (JSC::DFG::Epoch::operator<):
3242         (JSC::DFG::Epoch::operator>):
3243         (JSC::DFG::Epoch::operator<=):
3244         (JSC::DFG::Epoch::operator>=):
3245         * dfg/DFGFixupPhase.cpp:
3246         (JSC::DFG::FixupPhase::fixupNode):
3247         (JSC::DFG::FixupPhase::speculateForBarrier):
3248         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
3249         * dfg/DFGPlan.cpp:
3250         (JSC::DFG::Plan::compileInThreadImpl):
3251         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
3252         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
3253         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
3254         (JSC::DFG::performFastStoreBarrierInsertion):
3255         (JSC::DFG::performGlobalStoreBarrierInsertion):
3256         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
3257         * ftl/FTLOperations.cpp:
3258         (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
3259         * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
3260         * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
3261
3262 2015-05-16  Commit Queue  <commit-queue@webkit.org>
3263
3264         Unreviewed, rolling out r184415.
3265         https://bugs.webkit.org/show_bug.cgi?id=145096
3266
3267         Broke several tests (Requested by msaboff on #webkit).
3268
3269         Reverted changeset:
3270
3271         "Insert store barriers late so that IR transformations don't
3272         have to worry about them"
3273         https://bugs.webkit.org/show_bug.cgi?id=145015
3274         http://trac.webkit.org/changeset/184415
3275
3276 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
3277
3278         Insert store barriers late so that IR transformations don't have to worry about them
3279         https://bugs.webkit.org/show_bug.cgi?id=145015
3280
3281         Reviewed by Geoffrey Garen.
3282         
3283         We have had three kinds of bugs with store barriers. For the sake of discussion we say
3284         that a store barrier is needed when we have something like:
3285         
3286             base.field = value
3287         
3288         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
3289           This might happen if we prove value to be a non-cell even though in the FixupPhase it
3290           wasn't predicted non-cell.
3291         
3292         - We sometimes have a barrier in the wrong place after object allocation sinking. We
3293           might sink an allocation to just above the store, but that puts it just after the
3294           StoreBarrier that FixupPhase inserted.
3295         
3296         - We don't remove redundant barriers across basic blocks.
3297         
3298         This comprehensively fixes these issues by doing store barrier insertion late, and
3299         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
3300         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
3301         base is in the current GC epoch (i.e. was the last object that we allocated or had a
3302         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
3303         always been allocated before base). We do conservative things when merging epoch state
3304         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
3305         queries AI to determine what type we've proved about value, and avoids barriers when
3306         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
3307         the likelihood that this AI-based removal is effective.
3308
3309         * CMakeLists.txt:
3310         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3311         * JavaScriptCore.xcodeproj/project.pbxproj:
3312         * dfg/DFGBlockMap.h:
3313         (JSC::DFG::BlockMap::at):
3314         * dfg/DFGConstantFoldingPhase.cpp:
3315         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
3316         * dfg/DFGEpoch.h:
3317         (JSC::DFG::Epoch::operator<):
3318         (JSC::DFG::Epoch::operator>):
3319         (JSC::DFG::Epoch::operator<=):
3320         (JSC::DFG::Epoch::operator>=):
3321         * dfg/DFGFixupPhase.cpp:
3322         (JSC::DFG::FixupPhase::fixupNode):
3323         (JSC::DFG::FixupPhase::speculateForBarrier):
3324         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
3325         * dfg/DFGPlan.cpp:
3326         (JSC::DFG::Plan::compileInThreadImpl):
3327         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
3328         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
3329         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
3330         (JSC::DFG::performFastStoreBarrierInsertion):
3331         (JSC::DFG::performGlobalStoreBarrierInsertion):
3332         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
3333
3334 2015-05-15  Benjamin Poulain  <bpoulain@apple.com>
3335
3336         [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
3337         https://bugs.webkit.org/show_bug.cgi?id=144976
3338
3339         Reviewed by Michael Saboff.
3340
3341         Failing the conversion on zero is pretty dangerous as we discovered on x86.
3342
3343         This patch does not really impact performance significantly because
3344         r184220 removed the zero checks from Kraken. This patch is just to be
3345         on the safe side for cases not covered by existing benchmarks.
3346
3347         * assembler/MacroAssemblerARM64.h:
3348         (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
3349
3350 2015-05-15  Sungmann Cho  <sungmann.cho@navercorp.com>
3351
3352         Remove unnecessary forward declarations in PropertyNameArray.h.
3353         https://bugs.webkit.org/show_bug.cgi?id=145058
3354
3355         Reviewed by Andreas Kling.
3356
3357         No new tests, no behavior change.
3358
3359         * runtime/PropertyNameArray.h:
3360
3361 2015-05-15  Mark Lam  <mark.lam@apple.com>
3362
3363         JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
3364         https://bugs.webkit.org/show_bug.cgi?id=144622
3365
3366         Reviewed by Geoffrey Garen.
3367
3368         When setting the array to a new length that is shorter, we now check if it is worth
3369         just making a new butterfly instead of clearing out the slots in the old butterfly
3370         that resides beyond the new length.  If so, we will make a new butterfly instead.
3371
3372         There is no perf differences in the benchmark results.