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