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