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