Web Inspector: Array/Collection Sizes should be visible and distinct
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-03-04  Joseph Pecoraro  <pecoraro@apple.com>
2
3         Web Inspector: Array/Collection Sizes should be visible and distinct
4         https://bugs.webkit.org/show_bug.cgi?id=142254
5
6         Reviewed by Timothy Hatcher.
7
8         * runtime/WeakMapData.h:
9         (JSC::WeakMapData::size):
10         * inspector/JSInjectedScriptHost.cpp:
11         (Inspector::JSInjectedScriptHost::weakMapSize):
12         * inspector/JSInjectedScriptHost.h:
13         * inspector/JSInjectedScriptHostPrototype.cpp:
14         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
15         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
16         Add a way to get a WeakMap's size.
17
18         * inspector/protocol/Runtime.json:
19         Include size in RemoteObject and ObjectPreview.
20
21         * inspector/InjectedScriptSource.js:
22         Set the size of RemoteObjects and previews if they
23         are array/collection types.
24
25 2015-03-04  Andreas Kling  <akling@apple.com>
26
27         GC should compute stack bounds and dump registers at the earliest opportunity.
28         <https://webkit.org/b/142310>
29         <rdar://problem/20045624>
30
31         Reviewed by Geoffrey Garen.
32
33         Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
34         The wrapper function that grabs a snapshot of the current stack boundaries and register values
35         on entry, and sanitizes the stack on exit.
36
37         This is a speculative fix for what appears to be overly conservative behavior in the garbage
38         collector following r178364 which caused a measurable regression in memory usage on Membuster.
39         The theory being that we were putting pointers to dead things on the stack before scanning it,
40         and by doing that ended up marking things that we'd otherwise discover to be garbage.
41
42         * heap/Heap.cpp:
43         (JSC::Heap::markRoots):
44         (JSC::Heap::gatherStackRoots):
45         (JSC::Heap::collect):
46         (JSC::Heap::collectImpl):
47         * heap/Heap.h:
48         * heap/MachineStackMarker.cpp:
49         (JSC::MachineThreads::gatherFromCurrentThread):
50         (JSC::MachineThreads::gatherConservativeRoots):
51         * heap/MachineStackMarker.h:
52
53 2015-03-04  Debarshi Ray  <debarshir@gnome.org>
54
55         Silence GCC's -Wstrict-prototypes
56         https://bugs.webkit.org/show_bug.cgi?id=142278
57
58         Reviewed by Alexey Proskuryakov.
59
60         * API/JSContextRef.h:
61
62 2015-03-04  Benjamin Poulain  <bpoulain@apple.com>
63
64         [JSC] Add a node for Math.log()
65         https://bugs.webkit.org/show_bug.cgi?id=142126
66
67         Reviewed by Geoffrey Garen.
68
69         This patch adds the DFG node ArithLog for LogIntrinsic.
70
71         Having a direct call to log has very little value by itself, the implementation
72         in DFG and FTL is a simple function call.
73
74         What is useful in ArithLog is that we know the operation is pure.
75         This allow us to hoist it out of loops when the argument is independent
76         is an invariant of the loop.
77
78         Perf wise, this patch gives:
79         -Kraken's imaging-darkroom: definitely 1.2372x faster.
80         -AsmBench's Towers.c: definitely 1.0261x faster.
81
82         * dfg/DFGAbstractInterpreterInlines.h:
83         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
84         * dfg/DFGByteCodeParser.cpp:
85         (JSC::DFG::ByteCodeParser::handleIntrinsic):
86         * dfg/DFGClobberize.h:
87         (JSC::DFG::clobberize):
88         * dfg/DFGDoesGC.cpp:
89         (JSC::DFG::doesGC):
90         * dfg/DFGFixupPhase.cpp:
91         (JSC::DFG::FixupPhase::fixupNode):
92         * dfg/DFGNodeType.h:
93         * dfg/DFGPredictionPropagationPhase.cpp:
94         (JSC::DFG::PredictionPropagationPhase::propagate):
95         (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
96         * dfg/DFGSafeToExecute.h:
97         (JSC::DFG::safeToExecute):
98         * dfg/DFGSpeculativeJIT.cpp:
99         (JSC::DFG::SpeculativeJIT::compileArithLog):
100         * dfg/DFGSpeculativeJIT.h:
101         * dfg/DFGSpeculativeJIT32_64.cpp:
102         (JSC::DFG::SpeculativeJIT::compile):
103         * dfg/DFGSpeculativeJIT64.cpp:
104         (JSC::DFG::SpeculativeJIT::compile):
105         * ftl/FTLCapabilities.cpp:
106         (JSC::FTL::canCompile):
107         * ftl/FTLIntrinsicRepository.h:
108         * ftl/FTLLowerDFGToLLVM.cpp:
109         (JSC::FTL::LowerDFGToLLVM::compileNode):
110         (JSC::FTL::LowerDFGToLLVM::compileArithLog):
111         * ftl/FTLOutput.h:
112         (JSC::FTL::Output::doubleLog):
113         * tests/stress/math-log-basics.js: Added.
114         * tests/stress/math-log-with-constants.js: Added.
115
116 2015-03-04  Filip Pizlo  <fpizlo@apple.com>
117
118         Only Heap should be in charge of deciding how to select a subspace for a type
119         https://bugs.webkit.org/show_bug.cgi?id=142304
120
121         Reviewed by Mark Lam.
122         
123         This slightly reduces the code duplication for selecting subspace based on type, and what
124         duplication is left is at least localized in HeapInlines.h. The immediate effect is that
125         the DFG and FTL don't have to duplicate this pattern.
126
127         * dfg/DFGSpeculativeJIT.h:
128         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
129         (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
130         * ftl/FTLLowerDFGToLLVM.cpp:
131         (JSC::FTL::LowerDFGToLLVM::allocateObject):
132         * heap/Heap.h:
133         * heap/HeapInlines.h:
134         (JSC::Heap::allocateObjectOfType):
135         (JSC::Heap::subspaceForObjectOfType):
136         (JSC::Heap::allocatorForObjectOfType):
137         * runtime/JSCellInlines.h:
138         (JSC::allocateCell):
139
140 2015-03-04  Andreas Kling  <akling@apple.com>
141
142         Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
143         <https://webkit.org/b/142115>
144         <rdar://problem/19992268>
145
146         Reviewed by Geoffrey Garen.
147
148         Prune stale entries from WeakGCMaps as part of every full garbage collection.
149         This frees up tons of previously-stuck WeakBlocks that were only sitting around
150         with finalized handles waiting to die.
151
152         Note that WeakGCMaps register/unregister themselves with the GC heap in their
153         ctor/dtor, so creating one now requires passing the VM.
154
155         Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
156         to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
157         It seems somewhat excessive to do this on every Eden collection, so it's only
158         doing work in full collections for now.
159
160         * API/JSWeakObjectMapRefInternal.h:
161         (OpaqueJSWeakObjectMap::create):
162         (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
163         * API/JSWeakObjectMapRefPrivate.cpp:
164         * API/JSWrapperMap.mm:
165         (-[JSWrapperMap initWithContext:]):
166         (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
167
168         * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
169         it project-private so WebCore clients can access it.
170
171         * heap/Heap.cpp:
172         (JSC::Heap::collect):
173         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
174         stale entries from WeakGCMaps. This is only executed during full collections.
175
176         * heap/Heap.h:
177         * heap/HeapInlines.h:
178         (JSC::Heap::registerWeakGCMap):
179         (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
180         themselves with the Heap and provide a pruning callback.
181
182         * runtime/PrototypeMap.h:
183         (JSC::PrototypeMap::PrototypeMap):
184         * runtime/Structure.cpp:
185         (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
186
187         * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
188
189         * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
190
191         * runtime/VM.cpp:
192         (JSC::VM::VM): Pass VM to WeakGCMap constructor.
193
194         * runtime/WeakGCMap.h:
195         (JSC::WeakGCMap::set):
196         (JSC::WeakGCMap::add):
197         (JSC::WeakGCMap::WeakGCMap): Deleted.
198         (JSC::WeakGCMap::gcMap): Deleted.
199         (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
200         * runtime/WeakGCMapInlines.h: Added.
201         (JSC::WeakGCMap::WeakGCMap):
202         (JSC::WeakGCMap::~WeakGCMap):
203         (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
204         to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
205         prunes WeakGCMap at certain growth milestones and instead rely on the GC
206         callback for housekeeping.
207
208 2015-03-03  Filip Pizlo  <fpizlo@apple.com>
209
210         DFG IR should refer to FunctionExecutables directly and not via the CodeBlock
211         https://bugs.webkit.org/show_bug.cgi?id=142229
212
213         Reviewed by Mark Lam and Benjamin Poulain.
214         
215         Anytime a DFG IR node refers to something in CodeBlock, it has three effects:
216
217         - Cumbersome API for accessing the thing that the node refers to.
218         
219         - Not obvious how to create a new such node after bytecode parsing, especially if the
220           thing it refers to isn't already in the CodeBlock. We have done this in the past, but
221           it usually involves subtle changes to CodeBlock.
222         
223         - Not obvious how to inline code that ends up using such nodes. Again, when we have done
224           this, it involved subtle changes to CodeBlock.
225         
226         Prior to this change, the NewFunction* node types used an index into tables in CodeBlock.
227         For this reason, those operations were not inlineable. But the functin tables in CodeBlock
228         just point to FunctionExecutables, which are cells; this means that we can just abstract
229         these operands in DFG IR as cellOperands. cellOperands use DFG::FrozenValue, which means
230         that GC registration happens automagically. Even better, our dumping for cellOperand
231         already did FunctionExecutable dumping - so that functionality gets to be deduplicated.
232         
233         Because this change increases the number of users of cellOperand, it also adds some
234         convenience methods for using it. For example, whereas before you'd say things like:
235         
236             jsCast<Foo*>(node->cellOperand()->value())
237         
238         you can now just say:
239         
240             node->castOperand<Foo*>()
241         
242         This change also changes existing cellOperand users to use the new conveniance API when
243         applicable.
244
245         * bytecode/CodeBlock.cpp:
246         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs):
247         * bytecode/CodeBlock.h:
248         * dfg/DFGByteCodeParser.cpp:
249         (JSC::DFG::ByteCodeParser::parseBlock):
250         * dfg/DFGCapabilities.cpp:
251         (JSC::DFG::capabilityLevel):
252         * dfg/DFGFrozenValue.h:
253         (JSC::DFG::FrozenValue::cell):
254         (JSC::DFG::FrozenValue::dynamicCast):
255         (JSC::DFG::FrozenValue::cast):
256         * dfg/DFGGraph.cpp:
257         (JSC::DFG::Graph::dump):
258         (JSC::DFG::Graph::registerFrozenValues):
259         * dfg/DFGNode.h:
260         (JSC::DFG::Node::hasCellOperand):
261         (JSC::DFG::Node::castOperand):
262         (JSC::DFG::Node::hasFunctionDeclIndex): Deleted.
263         (JSC::DFG::Node::functionDeclIndex): Deleted.
264         (JSC::DFG::Node::hasFunctionExprIndex): Deleted.
265         (JSC::DFG::Node::functionExprIndex): Deleted.
266         * dfg/DFGSpeculativeJIT.cpp:
267         (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
268         (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
269         * dfg/DFGSpeculativeJIT32_64.cpp:
270         (JSC::DFG::SpeculativeJIT::compile):
271         * dfg/DFGSpeculativeJIT64.cpp:
272         (JSC::DFG::SpeculativeJIT::compile):
273         * dfg/DFGWatchpointCollectionPhase.cpp:
274         (JSC::DFG::WatchpointCollectionPhase::handle):
275         * ftl/FTLLowerDFGToLLVM.cpp:
276         (JSC::FTL::LowerDFGToLLVM::compileCheckCell):
277         (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
278
279 2015-03-03  Michael Saboff  <msaboff@apple.com>
280
281         DelayedReleaseScope drops locks during GC which can cause a thread switch and code reentry
282         https://bugs.webkit.org/show_bug.cgi?id=141275
283
284         Reviewed by Geoffrey Garen.
285
286         The original issue is that the CodeCache uses an unsafe method to add new UnlinkedCodeBlocks.
287         It basically adds a null UnlinkedCodeBlock if there isn't a cached entry and then later
288         updates the null entry to the result of the compilation.  If during that compilation and
289         related processing we need to garbage collect, the DelayedReleaseScope would drop locks
290         possibly allowing another thread to try to get the same source out of the CodeCache.
291         This second thread would find the null entry and crash.  The fix is to move the processing of
292         DelayedReleaseScope to when we drop locks and not drop locks during GC.  That was done in
293         the original patch with the new function releaseDelayedReleasedObjects().
294
295         Updated releaseDelayedReleasedObjects() so that objects are released with all locks
296         dropped.  Now its processing follows these steps
297             Increment recursion counter and do recursion check and exit if recursing
298             While there are objects to release
299                 ASSERT that lock is held by current thread
300                 Take all items from delayed release Vector and put into temporary Vector
301                 Release API lock
302                 Release and clear items from temporary vector
303                 Reaquire API lock
304         This meets the requirement that we release while the API lock is released and it is
305         safer processing of the delayed release Vector.
306
307         Added new regression test to testapi.
308
309         Also added comment describing how recursion into releaseDelayedReleasedObjects() is
310         prevented.
311
312         * API/tests/Regress141275.h: Added.
313         * API/tests/Regress141275.mm: Added.
314         (+[JSTEvaluatorTask evaluatorTaskWithEvaluateBlock:completionHandler:]):
315         (-[JSTEvaluator init]):
316         (-[JSTEvaluator initWithScript:]):
317         (-[JSTEvaluator _accessPendingTasksWithBlock:]):
318         (-[JSTEvaluator insertSignPostWithCompletion:]):
319         (-[JSTEvaluator evaluateScript:completion:]):
320         (-[JSTEvaluator evaluateBlock:completion:]):
321         (-[JSTEvaluator waitForTasksDoneAndReportResults]):
322         (__JSTRunLoopSourceScheduleCallBack):
323         (__JSTRunLoopSourcePerformCallBack):
324         (__JSTRunLoopSourceCancelCallBack):
325         (-[JSTEvaluator _jsThreadMain]):
326         (-[JSTEvaluator _sourceScheduledOnRunLoop:]):
327         (-[JSTEvaluator _setupEvaluatorThreadContextIfNeeded]):
328         (-[JSTEvaluator _callCompletionHandler:ifNeededWithError:]):
329         (-[JSTEvaluator _sourcePerform]):
330         (-[JSTEvaluator _sourceCanceledOnRunLoop:]):
331         (runRegress141275):
332         * API/tests/testapi.mm:
333         (testObjectiveCAPI):
334         * JavaScriptCore.xcodeproj/project.pbxproj:
335         * heap/Heap.cpp:
336         (JSC::Heap::releaseDelayedReleasedObjects):
337         * runtime/JSLock.cpp:
338         (JSC::JSLock::unlock):
339
340 2015-03-03  Filip Pizlo  <fpizlo@apple.com>
341
342         DFG should constant fold GetScope, and accesses to the scope register in the ByteCodeParser should not pretend that it's a constant as that breaks OSR exit liveness tracking
343         https://bugs.webkit.org/show_bug.cgi?id=106202
344
345         Rubber stamped by Benjamin Poulain.
346         
347         This fixes a bug discovered by working on https://bugs.webkit.org/show_bug.cgi?id=142229,
348         which was in turn discovered by working on https://bugs.webkit.org/show_bug.cgi?id=141174.
349         Our way of dealing with scopes known to be constant is very sketchy, and only really works
350         when a function is inlined. When it is, we pretend that every load of the scopeRegister sees
351         a constant. But this breaks the DFG's tracking of the liveness of the scopeRegister. The way
352         this worked made us miss oppportunities for optimizing based on a constant scope, and it also
353         meant that in some cases - particularly like when we inline code that uses NewFuction and
354         friends, as I do in bug 142229 - it makes OSR exit think that the scope is dead even though
355         it's most definitely alive and it's a constant.
356         
357         The problem here is that we were doing too many optimizations in the ByteCodeParser, and not
358         later. Later optimization phases know how to preserve OSR exit liveness. They're actually
359         really good at it. Also, later phases know how to infer that any variable is a constant no
360         matter how that constant arose - rather than the inlining-specific thing in ByteCodeParser.
361         
362         This changes the ByteCodeParser to largely avoid doing constant folding on the scope, except
363         making the GetScope operation itself a constant. This is a compilation-time hack for small
364         functions, and it doesn't break the loads of local variables - so OSR exit liveness still
365         sees that the scopeRegister is in use. This then adds a vastly more powerful GetScope and
366         GetClosureVar constant folder in the AbstractInterpreter. This handles most general cases
367         including those that arise in complex control flow. This will catch cases where the scope
368         is constant for any number of reasons. Basically anytime that the callee is inferred constant
369         this will give us a constant scope. Also, we still have the parse-time constant folding of
370         ResolveScope based on the reentry watchpoint, which luckily did the right thing with respect
371         to OSR exit liveness (it splats a Phantom on its inputs, and it produces a constant result
372         which is then set() normally).
373         
374         This appears to be a broad speed-up, albeit a small one. But mainly it unblocks bug 142229,
375         which then should unblock bug 141174.
376
377         * dfg/DFGAbstractInterpreterInlines.h:
378         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
379         * dfg/DFGByteCodeParser.cpp:
380         (JSC::DFG::ByteCodeParser::get):
381         (JSC::DFG::ByteCodeParser::getLocal):
382         (JSC::DFG::ByteCodeParser::parseBlock):
383         (JSC::DFG::ByteCodeParser::parse):
384         * dfg/DFGClobberize.h:
385         (JSC::DFG::clobberize):
386         * dfg/DFGDoesGC.cpp:
387         (JSC::DFG::doesGC):
388         * dfg/DFGFixupPhase.cpp:
389         (JSC::DFG::FixupPhase::fixupNode):
390         * dfg/DFGGraph.cpp:
391         (JSC::DFG::Graph::tryGetConstantClosureVar):
392         (JSC::DFG::Graph::tryGetRegisters):
393         (JSC::DFG::Graph::tryGetActivation): Deleted.
394         * dfg/DFGGraph.h:
395         * dfg/DFGNode.h:
396         (JSC::DFG::Node::hasVariableWatchpointSet):
397         (JSC::DFG::Node::hasSymbolTable): Deleted.
398         (JSC::DFG::Node::symbolTable): Deleted.
399         * dfg/DFGNodeType.h:
400         * dfg/DFGPredictionPropagationPhase.cpp:
401         (JSC::DFG::PredictionPropagationPhase::propagate):
402         * dfg/DFGSafeToExecute.h:
403         (JSC::DFG::safeToExecute):
404         * dfg/DFGSpeculativeJIT32_64.cpp:
405         (JSC::DFG::SpeculativeJIT::compile):
406         * dfg/DFGSpeculativeJIT64.cpp:
407         (JSC::DFG::SpeculativeJIT::compile):
408         * dfg/DFGWatchpointCollectionPhase.cpp:
409         (JSC::DFG::WatchpointCollectionPhase::handle):
410         * ftl/FTLCapabilities.cpp:
411         (JSC::FTL::canCompile):
412         * ftl/FTLLowerDFGToLLVM.cpp:
413         (JSC::FTL::LowerDFGToLLVM::compileNode):
414         (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
415         * runtime/SymbolTable.cpp:
416         (JSC::SymbolTable::visitChildren):
417         (JSC::SymbolTable::localToEntry):
418         (JSC::SymbolTable::entryFor):
419         * runtime/SymbolTable.h:
420         (JSC::SymbolTable::add):
421         (JSC::SymbolTable::set):
422         * tests/stress/function-expression-exit.js: Added.
423         * tests/stress/function-reentry-infer-on-self.js: Added.
424         (thingy):
425         * tests/stress/goofy-function-reentry-incorrect-inference.js: Added.
426
427 2015-03-03  Anders Carlsson  <andersca@apple.com>
428
429         Remove unused compression code
430         https://bugs.webkit.org/show_bug.cgi?id=142237
431
432         Reviewed by Geoffrey Garen.
433
434         * bytecode/UnlinkedCodeBlock.h:
435
436 2015-03-03  Filip Pizlo  <fpizlo@apple.com>
437
438         JIT debugging features that selectively disable the JITs for code blocks need to stay out of the way of the critical path of JIT management
439         https://bugs.webkit.org/show_bug.cgi?id=142234
440
441         Reviewed by Mark Lam and Benjamin Poulain.
442         
443         Long ago, we used to selectively disable compilation of CodeBlocks for debugging purposes by
444         adding hacks to DFGDriver.cpp.  This was all well and good.  It used the existing
445         CompilationFailed mode of the DFG driver to signal failure of CodeBlocks that we didn't want
446         to compile.  That's great because CompilationFailed is a well-supported return value on the
447         critical path, usually used for when we run out of JIT memory.
448
449         Later, this was moved into DFGCapabilities. This was basically incorrect. It introduced a bug
450         where disabling compiling of a CodeBlock meant that we stopped inlining it as well.  So if
451         you had a compiler bug that arose if foo was inlined into bar, and you bisected down to bar,
452         then foo would no longer get inlined and you wouldn't see the bug.  That's busted.
453
454         So then we changed the code in DFGCapabilities to mark bar as CanCompile and foo as
455         CanInline. Now, foo wouldn't get compiled alone but it would get inlined.
456
457         But then we removed CanCompile because that capability mode only existed for the purpose of
458         our old varargs hacks.  After that removal, "CanInline" became CannotCompile.  This means
459         that if you bisect down on bar in the "foo inlined into bar" case, you'll crash in the DFG
460         because the baseline JIT wouldn't have known to insert profiling on foo.
461
462         We could fix this by bringing back CanInline.
463
464         But this is all a pile of nonsense.  The debug support to selectively disable compilation of
465         some CodeBlocks shouldn't cross-cut our entire engine and should most certainly never involve
466         adding new capability modes.  This support is a hack at best and is for use by JSC hackers
467         only.  It should be as unintrusive as possible.
468
469         So, as in the ancient times, the only proper place to put this hack is in DFGDriver.cpp, and
470         return CompilationFailed.  This is correct not just because it takes capability modes out of
471         the picture (and obviates the need to introduce new ones), but also because it means that
472         disabling compilation doesn't change the profiling mode of other CodeBlocks in the Baseline
473         JIT.  Capability mode influences profiling mode which in turn influences code generation in
474         the Baseline JIT, sometimes in very significant ways - like, we sometimes do additional
475         double-to-int conversions in Baseline if we know that we might tier-up into the DFG, since
476         this buys us more precise profiling.
477         
478         This change reduces the intrusiveness of debugging hacks by making them use the very simple
479         CompilationFailed mechanism rather than trying to influence capability modes. Capability
480         modes have very subtle effects on the whole engine, while CompilationFailed just makes the
481         engine pretend like the DFG compilation will happen at timelike infinity. That makes these
482         hacks much more likely to continue working as we make other changes to the system.
483         
484         This brings back the ability to bisect down onto a function bar when bar inlines foo. Prior
485         to this change, we would crash in that case.
486
487         * dfg/DFGCapabilities.cpp:
488         (JSC::DFG::isSupported):
489         (JSC::DFG::mightCompileEval):
490         (JSC::DFG::mightCompileProgram):
491         (JSC::DFG::mightCompileFunctionForCall):
492         (JSC::DFG::mightCompileFunctionForConstruct):
493         * dfg/DFGCapabilities.h:
494         * dfg/DFGDriver.cpp:
495         (JSC::DFG::compileImpl):
496
497 2015-03-03  peavo@outlook.com  <peavo@outlook.com>
498
499         [Win64] JSC compile error.
500         https://bugs.webkit.org/show_bug.cgi?id=142216
501
502         Reviewed by Mark Lam.
503
504         There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.
505
506         * jit/CCallHelpers.h:
507         (JSC::CCallHelpers::setupArgumentsWithExecState):
508
509 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
510
511         DFG compile time measurements should really report milliseconds
512         https://bugs.webkit.org/show_bug.cgi?id=142209
513
514         Reviewed by Benjamin Poulain.
515         
516         Fix this to record milliseconds instead of seconds.
517
518         * dfg/DFGPlan.cpp:
519         (JSC::DFG::Plan::compileInThread):
520         (JSC::DFG::Plan::compileInThreadImpl):
521
522 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
523
524         Remove op_get_callee, it's unused
525         https://bugs.webkit.org/show_bug.cgi?id=142206
526
527         Reviewed by Andreas Kling.
528         
529         It's a bit of a shame that we stopped using this opcode since it gives us same-callee
530         profiling. But, if we were to add this functionality back in, we would almost certainly do
531         it by adding a JSFunction allocation watchpoint on FunctionExecutable.
532
533         * bytecode/BytecodeList.json:
534         * bytecode/BytecodeUseDef.h:
535         (JSC::computeUsesForBytecodeOffset):
536         (JSC::computeDefsForBytecodeOffset):
537         * bytecode/CodeBlock.cpp:
538         (JSC::CodeBlock::dumpBytecode):
539         (JSC::CodeBlock::finalizeUnconditionally):
540         * dfg/DFGByteCodeParser.cpp:
541         (JSC::DFG::ByteCodeParser::parseBlock):
542         * dfg/DFGCapabilities.cpp:
543         (JSC::DFG::capabilityLevel):
544         * jit/JIT.cpp:
545         (JSC::JIT::privateCompileMainPass):
546         (JSC::JIT::privateCompileSlowCases):
547         * jit/JIT.h:
548         * jit/JITOpcodes.cpp:
549         (JSC::JIT::emit_op_get_callee): Deleted.
550         (JSC::JIT::emitSlow_op_get_callee): Deleted.
551         * jit/JITOpcodes32_64.cpp:
552         (JSC::JIT::emit_op_get_callee): Deleted.
553         (JSC::JIT::emitSlow_op_get_callee): Deleted.
554         * llint/LowLevelInterpreter32_64.asm:
555         * llint/LowLevelInterpreter64.asm:
556         * runtime/CommonSlowPaths.cpp:
557         (JSC::SLOW_PATH_DECL): Deleted.
558
559 2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>
560
561         Web Inspector: Context Menu to Log a Particular Object
562         https://bugs.webkit.org/show_bug.cgi?id=142198
563
564         Reviewed by Timothy Hatcher.
565
566         Add a protocol method to assign a $n index to a value. For an object
567         use the injected script context for that object. For a value, use
568         the execution context to know where to save the value.
569
570         * inspector/InjectedScript.cpp:
571         (Inspector::InjectedScript::saveResult):
572         * inspector/InjectedScript.h:
573         * inspector/InjectedScriptSource.js:
574         * inspector/agents/InspectorRuntimeAgent.cpp:
575         (Inspector::InspectorRuntimeAgent::saveResult):
576         * inspector/agents/InspectorRuntimeAgent.h:
577         * inspector/protocol/Debugger.json:
578         * inspector/protocol/Runtime.json:
579
580 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
581
582         SpeculativeJIT::emitAllocateArguments() should be a bit faster, and shouldn't do destructor initialization
583         https://bugs.webkit.org/show_bug.cgi?id=142197
584
585         Reviewed by Geoffrey Garen.
586
587         * dfg/DFGSpeculativeJIT.cpp:
588         (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Use shift instead of mul, since mul doesn't automatically strength-reduce to shift. Also pass the structure as a TrustedImmPtr.
589         * dfg/DFGSpeculativeJIT.h:
590         (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): Rationalize this a bit. The other emitAllocate... methods take a templated structure so that it can be either a TrustedImmPtr or a register. Also don't do destructor initialization, since its one client doesn't need it, and it's actually probably wrong.
591
592 2015-03-02  Mark Lam  <mark.lam@apple.com>
593
594         Exception stack unwinding in JSC hangs while the Timeline Profiler is enabled.
595         <https://webkit.org/b/142191>
596
597         Reviewed by Geoffrey Garen.
598
599         Imagine a scenario where the Inspector is paused / suspended at a breakpoint or
600         while the user is stepping through JS code. The user then tries to evaluate an
601         expression in the console, and that evaluation results in an exception being
602         thrown. Currently, if the Timeline Profiler is enabled while this exception is
603         being thrown, the WebProcess will hang while trying to handle that exception.
604
605         The issue is that the Timeline Profiler's ProfileGenerator::didExecute() will
606         return early and decline to process ProfileNodes if the Inspector is paused.
607         This is proper because it does not want to count work done for injected scripts
608         (e.g. from the console) towards the timeline profile of the webpage being run.
609         However, this is in conflict with ProfileGenerator::exceptionUnwind()'s
610         expectation that didExecute() will process ProfileNodes in order to do the stack
611         unwinding for the exception handling. As a result,
612         ProfileGenerator::exceptionUnwind() hangs.
613
614         ProfileGenerator::exceptionUnwind() is in error. While the Inspector is paused,
615         there will not be any ProfileNodes that it needs to "unwind". Hence, the fix is
616         simply to return early also in ProfileGenerator::exceptionUnwind() if the
617         Inspector is paused.
618
619         * profiler/ProfileGenerator.cpp:
620         (JSC::ProfileGenerator::exceptionUnwind):
621
622 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
623
624         FTL should correctly document where it puts the argument count for inlined varargs frames
625         https://bugs.webkit.org/show_bug.cgi?id=142187
626
627         Reviewed by Geoffrey Garn.
628         
629         After LLVM tells us where the captured variables alloca landed in the frame, we need to
630         tell all of our meta-data about it. We were forgetting to do so for the argument count
631         register, which is used by inlined varargs calls.
632
633         * ftl/FTLCompile.cpp:
634         (JSC::FTL::mmAllocateDataSection):
635         * tests/stress/inline-varargs-get-arguments.js: Added.
636         (foo):
637         (bar):
638         (baz):
639
640 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
641
642         Deduplicate slow path calling code in JITOpcodes.cpp/JITOpcodes32_64.cpp
643         https://bugs.webkit.org/show_bug.cgi?id=142184
644
645         Reviewed by Michael Saboff.
646
647         * jit/JITOpcodes.cpp:
648         (JSC::JIT::emit_op_get_enumerable_length):
649         (JSC::JIT::emitSlow_op_has_structure_property):
650         (JSC::JIT::emit_op_has_generic_property):
651         (JSC::JIT::emit_op_get_structure_property_enumerator):
652         (JSC::JIT::emit_op_get_generic_property_enumerator):
653         (JSC::JIT::emit_op_to_index_string):
654         * jit/JITOpcodes32_64.cpp:
655         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
656         (JSC::JIT::emitSlow_op_has_structure_property): Deleted.
657         (JSC::JIT::emit_op_has_generic_property): Deleted.
658         (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
659         (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
660         (JSC::JIT::emit_op_to_index_string): Deleted.
661         (JSC::JIT::emit_op_profile_control_flow): Deleted.
662
663 2015-03-02  Antti Koivisto  <antti@apple.com>
664
665         Add way to dump cache meta data to file
666         https://bugs.webkit.org/show_bug.cgi?id=142183
667
668         Reviewed by Andreas Kling.
669
670         Export appendQuotedJSONStringToBuilder.
671
672         * bytecompiler/NodesCodegen.cpp:
673         (JSC::ObjectPatternNode::toString):
674         * runtime/JSONObject.cpp:
675         (JSC::appendQuotedJSONStringToBuilder):
676         (JSC::Stringifier::appendQuotedString):
677         (JSC::escapeStringToBuilder): Deleted.
678         * runtime/JSONObject.h:
679
680 2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>
681
682         Web Inspector: Add Context Menus to Object Tree properties
683         https://bugs.webkit.org/show_bug.cgi?id=142125
684
685         Reviewed by Timothy Hatcher.
686
687         * inspector/JSInjectedScriptHost.cpp:
688         (Inspector::JSInjectedScriptHost::functionDetails):
689         Update to include columnNumber.
690
691 2015-03-01  Filip Pizlo  <fpizlo@apple.com>
692
693         BytecodeGenerator shouldn't emit op_resolve_scope as a roundabout way of returning the scopeRegister
694         https://bugs.webkit.org/show_bug.cgi?id=142153
695
696         Reviewed by Michael Saboff.
697         
698         We don't need a op_resolve_scope if we know that it will simply return the scope register.
699         This changes the BytecodeGenerator to use the scope register directly in those cases where
700         we know statically that we would just have returned that from op_resolve_scope.
701         
702         This doesn't appear to have a significant impact on performance.
703
704         * bytecode/CodeBlock.cpp:
705         (JSC::CodeBlock::CodeBlock):
706         * bytecompiler/BytecodeGenerator.cpp:
707         (JSC::BytecodeGenerator::emitResolveScope):
708         (JSC::BytecodeGenerator::emitReturn):
709         (JSC::BytecodeGenerator::emitGetOwnScope): Deleted.
710         * bytecompiler/BytecodeGenerator.h:
711         * bytecompiler/NodesCodegen.cpp:
712         (JSC::ResolveNode::emitBytecode):
713         (JSC::EvalFunctionCallNode::emitBytecode):
714         (JSC::FunctionCallResolveNode::emitBytecode):
715         (JSC::PostfixNode::emitResolve):
716         (JSC::DeleteResolveNode::emitBytecode):
717         (JSC::TypeOfResolveNode::emitBytecode):
718         (JSC::PrefixNode::emitResolve):
719         (JSC::ReadModifyResolveNode::emitBytecode):
720         (JSC::AssignResolveNode::emitBytecode):
721         (JSC::ConstDeclNode::emitCodeSingle):
722         (JSC::EmptyVarExpression::emitBytecode):
723         (JSC::ForInNode::emitLoopHeader):
724         (JSC::ForOfNode::emitBytecode):
725         (JSC::BindingNode::bindValue):
726
727 2015-02-27  Benjamin Poulain  <bpoulain@apple.com>
728
729         [JSC] Use the way number constants are written to help type speculation
730         https://bugs.webkit.org/show_bug.cgi?id=142072
731
732         Reviewed by Filip Pizlo.
733
734         This patch changes how we interpret numeric constant based on how they appear
735         in the source.
736
737         Constants that are integers but written with a decimal point now carry that information
738         to the optimizating tiers. From there, we use that to be more aggressive about typing
739         math operations toward double operations.
740
741         For example, in:
742             var a = x + 1.0;
743             var b = y + 1;
744         The Add for a would be biased toward doubles, the Add for b would speculate
745         integer as usual.
746
747
748         The gains are tiny but this is a prerequisite to make my next patch useful:
749         -SunSpider's access-fannkuch: definitely 1.0661x faster
750         -SunSpider's math-cordic: definitely 1.0266x slower
751             overal: might be 1.0066x slower.
752         -Kraken's imaging-darkroom: definitely 1.0333x faster.
753
754         * parser/Lexer.cpp:
755         (JSC::tokenTypeForIntegerLikeToken):
756         (JSC::Lexer<T>::lex):
757         The lexer now create two types of tokens for number: INTEGER and DOUBLE.
758         Those token types only carry information about how the values were
759         entered, an INTEGER does not have to be an integer, it is only written like one.
760         Large integer still end up represented as double in memory.
761
762         One trap I fell into was typing numbers like 12e3 as double. This kind of literal
763         is frequently used in integer-typed code, while 12.e3 would appear in double-typed
764         code.
765         Because of that, the only signals for double are: decimal point, negative zero,
766         and ridiculously large values.
767
768         * parser/NodeConstructors.h:
769         (JSC::DoubleNode::DoubleNode):
770         (JSC::IntegerNode::IntegerNode):
771         * parser/Nodes.h:
772         (JSC::NumberNode::value):
773         (JSC::NumberNode::setValue): Deleted.
774         Number get specialized in two new kind of nodes in the AST: IntegerNode and DoubleNode.
775
776         * bytecompiler/NodesCodegen.cpp:
777         (JSC::NumberNode::emitBytecode):
778
779         * parser/ASTBuilder.h:
780         (JSC::ASTBuilder::createDoubleExpr):
781         (JSC::ASTBuilder::createIntegerExpr):
782         (JSC::ASTBuilder::createIntegerLikeNumber):
783         (JSC::ASTBuilder::createDoubleLikeNumber):
784         (JSC::ASTBuilder::createNumberFromBinaryOperation):
785         (JSC::ASTBuilder::createNumberFromUnaryOperation):
786         (JSC::ASTBuilder::makeNegateNode):
787         (JSC::ASTBuilder::makeBitwiseNotNode):
788         (JSC::ASTBuilder::makeMultNode):
789         (JSC::ASTBuilder::makeDivNode):
790         (JSC::ASTBuilder::makeModNode):
791         (JSC::ASTBuilder::makeAddNode):
792         (JSC::ASTBuilder::makeSubNode):
793         (JSC::ASTBuilder::makeLeftShiftNode):
794         (JSC::ASTBuilder::makeRightShiftNode):
795         (JSC::ASTBuilder::makeURightShiftNode):
796         (JSC::ASTBuilder::makeBitOrNode):
797         (JSC::ASTBuilder::makeBitAndNode):
798         (JSC::ASTBuilder::makeBitXOrNode):
799         (JSC::ASTBuilder::createNumberExpr): Deleted.
800         (JSC::ASTBuilder::createNumber): Deleted.
801         The AST has some optimization to resolve constants before emitting bytecode.
802         In the new code, the intger representation is kept if both operands where
803         also represented as integers.
804
805         * parser/Parser.cpp:
806         (JSC::Parser<LexerType>::parseDeconstructionPattern):
807         (JSC::Parser<LexerType>::parseProperty):
808         (JSC::Parser<LexerType>::parseGetterSetter):
809         (JSC::Parser<LexerType>::parsePrimaryExpression):
810         (JSC::Parser<LexerType>::printUnexpectedTokenText):
811         * parser/ParserTokens.h:
812         * parser/SyntaxChecker.h:
813         (JSC::SyntaxChecker::createDoubleExpr):
814         (JSC::SyntaxChecker::createIntegerExpr):
815         (JSC::SyntaxChecker::createNumberExpr): Deleted.
816
817         * bytecode/CodeBlock.cpp:
818         (JSC::CodeBlock::registerName):
819         (JSC::CodeBlock::constantName):
820         Change constantName(r, getConstant(r)) -> constantName(r) to simplify
821         the dump code.
822
823         (JSC::CodeBlock::dumpBytecode):
824         Dump thre soure representation information we have with each constant.
825
826         (JSC::CodeBlock::CodeBlock):
827         (JSC::CodeBlock::shrinkToFit):
828         (JSC::constantName): Deleted.
829         * bytecode/CodeBlock.h:
830         (JSC::CodeBlock::constantsSourceCodeRepresentation):
831         (JSC::CodeBlock::addConstant):
832         (JSC::CodeBlock::addConstantLazily):
833         (JSC::CodeBlock::constantSourceCodeRepresentation):
834         (JSC::CodeBlock::setConstantRegisters):
835
836         * bytecode/UnlinkedCodeBlock.h:
837         (JSC::UnlinkedCodeBlock::addConstant):
838         (JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
839         (JSC::UnlinkedCodeBlock::shrinkToFit):
840
841         * bytecompiler/BytecodeGenerator.cpp:
842         (JSC::BytecodeGenerator::addConstantValue):
843         (JSC::BytecodeGenerator::emitLoad):
844         * bytecompiler/BytecodeGenerator.h:
845         We have to differentiate between constants that have the same values but are
846         represented differently in the source. Values like 1.0 and 1 now end up
847         as different constants.
848
849         * dfg/DFGByteCodeParser.cpp:
850         (JSC::DFG::ByteCodeParser::get):
851         (JSC::DFG::ByteCodeParser::addConstantToGraph):
852         * dfg/DFGGraph.cpp:
853         (JSC::DFG::Graph::registerFrozenValues):
854         * dfg/DFGGraph.h:
855         (JSC::DFG::Graph::addSpeculationMode):
856         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
857         ArithAdd is very aggressive toward using Int52, which is quite useful
858         in many benchmarks.
859
860         Here we need to specialize to make sure we don't force our literals
861         to Int52 if there were represented as double.
862
863         There is one exception to that rule: when the other operand is guaranteed
864         to come from a NodeResultInt32. This is because there is some weird code
865         doing stuff like:
866             var b = a|0;
867             var c = b*2.0;
868
869         * dfg/DFGNode.h:
870         (JSC::DFG::Node::Node):
871         (JSC::DFG::Node::setOpAndDefaultFlags):
872         (JSC::DFG::Node::sourceCodeRepresentation):
873         * dfg/DFGPredictionPropagationPhase.cpp:
874         (JSC::DFG::PredictionPropagationPhase::propagate):
875         * runtime/JSCJSValue.h:
876         (JSC::EncodedJSValueWithRepresentationHashTraits::emptyValue):
877         (JSC::EncodedJSValueWithRepresentationHashTraits::constructDeletedValue):
878         (JSC::EncodedJSValueWithRepresentationHashTraits::isDeletedValue):
879         (JSC::EncodedJSValueWithRepresentationHash::hash):
880         (JSC::EncodedJSValueWithRepresentationHash::equal):
881         * tests/stress/arith-add-with-constants.js: Added.
882         * tests/stress/arith-mul-with-constants.js: Added.
883
884 2015-02-26  Filip Pizlo  <fpizlo@apple.com>
885
886         Unreviewed, roll out r180723. It broke a bunch of tests.
887
888         * bytecompiler/BytecodeGenerator.cpp:
889         (JSC::BytecodeGenerator::constLocal):
890         * bytecompiler/BytecodeGenerator.h:
891         * bytecompiler/NodesCodegen.cpp:
892         (JSC::ConstDeclNode::emitCodeSingle):
893         * tests/stress/const-arguments.js: Removed.
894
895 2015-02-26  Mark Lam  <mark.lam@apple.com>
896
897         Assertion fix for r180711: The bool returning form of BytecodeGenerator::addVar() can be removed.
898         <https://webkit.org/b/142064>
899
900         Reviewed by Joseph Pecoraro.
901
902         * bytecompiler/BytecodeGenerator.cpp:
903         (JSC::BytecodeGenerator::addVar):
904
905 2015-02-26  Mark Lam  <mark.lam@apple.com>
906
907         MachineThreads::Thread clean up has a use after free race condition.
908         <https://webkit.org/b/141990>
909
910         Reviewed by Filip Pizlo.
911
912         MachineThreads::Thread clean up relies on the clean up mechanism
913         implemented in _pthread_tsd_cleanup_key(), which looks like this:
914
915         void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
916         {
917             void (*destructor)(void *);
918             if (_pthread_key_get_destructor(key, &destructor)) {
919                 void **ptr = &self->tsd[key];
920                 void *value = *ptr;
921
922             // === Start of window for the bug to manifest =================
923
924                 // At this point, this thread has cached "destructor" and "value"
925                 // (which is a MachineThreads*).  If the VM gets destructed (along
926                 // with its MachineThreads registry) by another thread, then this
927                 // thread will have no way of knowing that the MachineThreads* is
928                 // now pointing to freed memory.  Calling the destructor below will
929                 // therefore result in a use after free scenario when it tries to
930                 // access the MachineThreads' data members.
931
932                 if (value) {
933                     *ptr = NULL;
934                     if (destructor) {
935
936             // === End of window for the bug to manifest ==================
937
938                         destructor(value);
939                     }
940                 }
941             }
942         }
943
944         The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
945         and always check if the manager still contains that MachineThreads object
946         before we call removeCurrentThread() on it.  When MachineThreads is destructed,
947         it will remove itself from the manager.  The add, remove, and checking
948         operations are all synchronized on the manager's lock, thereby ensuring that
949         the MachineThreads object, if found in the manager, will remain alive for the
950         duration of time we call removeCurrentThread() on it.
951
952         There's also possible for the MachineThreads object to already be destructed
953         and another one happened to have been instantiated at the same address.
954         Hence, we should only remove the exiting thread if it is found in the
955         MachineThreads object.
956
957         There is no test for this issue because this bug requires a race condition
958         between 2 threads where:
959         1. Thread B, which had previously used the VM, exiting and
960            getting to the bug window shown in _pthread_tsd_cleanup_key() above.
961         2. Thread A destructing the VM (and its MachineThreads object)
962            within that window of time before Thread B calls the destructor.
963
964         It is not possible to get a reliable test case without invasively
965         instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
966         to significantly increase that window of opportunity.
967
968         * heap/MachineStackMarker.cpp:
969         (JSC::ActiveMachineThreadsManager::Locker::Locker):
970         (JSC::ActiveMachineThreadsManager::add):
971         (JSC::ActiveMachineThreadsManager::remove):
972         (JSC::ActiveMachineThreadsManager::contains):
973         (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
974         (JSC::activeMachineThreadsManager):
975         (JSC::MachineThreads::MachineThreads):
976         (JSC::MachineThreads::~MachineThreads):
977         (JSC::MachineThreads::removeThread):
978         (JSC::MachineThreads::removeThreadIfFound):
979         (JSC::MachineThreads::removeCurrentThread): Deleted.
980         * heap/MachineStackMarker.h:
981
982 2015-02-26  Joseph Pecoraro  <pecoraro@apple.com>
983
984         Web Inspector: Save Console Evaluations into Command Line variables $1-$99 ($n)
985         https://bugs.webkit.org/show_bug.cgi?id=142061
986
987         Reviewed by Timothy Hatcher.
988
989         * inspector/protocol/Debugger.json:
990         * inspector/protocol/Runtime.json:
991         Input flag "saveResult" on whether we should try to save a result.
992         Output int "savedResultIndex" to tell the frontend the saved state.
993
994         * inspector/InjectedScriptSource.js:
995         Handle saving and clearing $1-$99 values.
996         Include in BasicCommandLineAPI for JSContext inspection.
997
998         * inspector/InjectedScriptBase.cpp:
999         (Inspector::InjectedScriptBase::makeEvalCall):
1000         * inspector/InjectedScriptBase.h:
1001         Allow an optional "savedResultIndex" out value on evals.
1002
1003         * inspector/InjectedScript.cpp:
1004         (Inspector::InjectedScript::evaluate):
1005         (Inspector::InjectedScript::evaluateOnCallFrame):
1006         * inspector/InjectedScript.h:
1007         * inspector/agents/InspectorDebuggerAgent.cpp:
1008         (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
1009         * inspector/agents/InspectorDebuggerAgent.h:
1010         * inspector/agents/InspectorRuntimeAgent.cpp:
1011         (Inspector::InspectorRuntimeAgent::evaluate):
1012         * inspector/agents/InspectorRuntimeAgent.h:
1013         Plumbing for new in and out parameters.
1014
1015 2015-02-26  Filip Pizlo  <fpizlo@apple.com>
1016
1017         The bool returning form of BytecodeGenerator::addVar() can be removed
1018         https://bugs.webkit.org/show_bug.cgi?id=142064
1019
1020         Reviewed by Mark Lam.
1021         
1022         It's easier to implement addVar() when you don't have to return whether it's a new
1023         variable or not.
1024
1025         * bytecompiler/BytecodeGenerator.cpp:
1026         (JSC::BytecodeGenerator::addVar):
1027         * bytecompiler/BytecodeGenerator.h:
1028         (JSC::BytecodeGenerator::addVar): Deleted.
1029
1030 2015-02-26  Filip Pizlo  <fpizlo@apple.com>
1031
1032         Various array access corner cases should take OSR exit feedback
1033         https://bugs.webkit.org/show_bug.cgi?id=142056
1034
1035         Reviewed by Geoffrey Garen.
1036         
1037         Two major changes here:
1038         
1039         - Don't keep converting GetById into GetArrayLength if we exited due to any kind of array
1040           type check.
1041         
1042         - Use a generic form of GetByVal/PutByVal if we exited due to any kind of exotic checks,
1043           like the Arguments safety checks. We use the "ExoticObjectMode" for out-of-bounds on
1044           arguments for now, since it's a convenient way of forcing out-of-bounds to be handled by
1045           the Generic array mode.
1046
1047         * bytecode/ExitKind.cpp:
1048         (JSC::exitKindToString):
1049         * bytecode/ExitKind.h:
1050         * dfg/DFGArrayMode.cpp:
1051         (JSC::DFG::ArrayMode::refine):
1052         * dfg/DFGFixupPhase.cpp:
1053         (JSC::DFG::FixupPhase::fixupNode):
1054         * dfg/DFGSpeculativeJIT.cpp:
1055         (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
1056         (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
1057         * tests/stress/array-length-array-storage-plain-object.js: Added.
1058         (foo):
1059         * tests/stress/array-length-plain-object.js: Added.
1060         (foo):
1061
1062 2015-02-25  Filip Pizlo  <fpizlo@apple.com>
1063
1064         DFG SSA stack accesses shouldn't speak of VariableAccessDatas
1065         https://bugs.webkit.org/show_bug.cgi?id=142036
1066
1067         Reviewed by Michael Saboff.
1068         
1069         VariableAccessData is a useful thing in LoadStore and ThreadedCPS, but it's purely harmful in
1070         SSA because you can't cook up new VariableAccessDatas. So, if you know that you want to load
1071         or store to the stack, and you know what format to use as well as the location, then prior to
1072         this patch you couldn't do it unless you found some existing VariableAccessData that matched
1073         your requirements. That can be a hard task.
1074         
1075         It's better if SSA doesn't speak of VariableAccessDatas but instead just has stack accesses
1076         that speak of the things that a stack access needs: local, machineLocal, and format. This
1077         patch changes the SSA way of accessing the stack to do just that.
1078         
1079         Also add more IR validation.
1080
1081         * CMakeLists.txt:
1082         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1083         * JavaScriptCore.xcodeproj/project.pbxproj:
1084         * dfg/DFGAbstractInterpreterInlines.h:
1085         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1086         * dfg/DFGClobberize.h:
1087         (JSC::DFG::clobberize):
1088         * dfg/DFGConstantFoldingPhase.cpp:
1089         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1090         * dfg/DFGDoesGC.cpp:
1091         (JSC::DFG::doesGC):
1092         * dfg/DFGFixupPhase.cpp:
1093         (JSC::DFG::FixupPhase::fixupNode):
1094         * dfg/DFGFlushFormat.h:
1095         (JSC::DFG::isConcrete):
1096         * dfg/DFGGraph.cpp:
1097         (JSC::DFG::Graph::dump):
1098         * dfg/DFGGraph.h:
1099         * dfg/DFGMayExit.cpp:
1100         (JSC::DFG::mayExit):
1101         * dfg/DFGNode.cpp:
1102         (JSC::DFG::Node::hasVariableAccessData):
1103         * dfg/DFGNode.h:
1104         (JSC::DFG::StackAccessData::StackAccessData):
1105         (JSC::DFG::StackAccessData::flushedAt):
1106         (JSC::DFG::Node::convertToPutStack):
1107         (JSC::DFG::Node::convertToGetStack):
1108         (JSC::DFG::Node::hasUnlinkedLocal):
1109         (JSC::DFG::Node::hasStackAccessData):
1110         (JSC::DFG::Node::stackAccessData):
1111         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1112         * dfg/DFGNodeType.h:
1113         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1114         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
1115         * dfg/DFGPlan.cpp:
1116         (JSC::DFG::Plan::compileInThreadImpl):
1117         * dfg/DFGPredictionPropagationPhase.cpp:
1118         (JSC::DFG::PredictionPropagationPhase::propagate):
1119         * dfg/DFGPutLocalSinkingPhase.cpp: Removed.
1120         * dfg/DFGPutLocalSinkingPhase.h: Removed.
1121         * dfg/DFGPutStackSinkingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.cpp.
1122         (JSC::DFG::performPutStackSinking):
1123         (JSC::DFG::performPutLocalSinking): Deleted.
1124         * dfg/DFGPutStackSinkingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.h.
1125         * dfg/DFGSSAConversionPhase.cpp:
1126         (JSC::DFG::SSAConversionPhase::run):
1127         * dfg/DFGSafeToExecute.h:
1128         (JSC::DFG::safeToExecute):
1129         * dfg/DFGSpeculativeJIT32_64.cpp:
1130         (JSC::DFG::SpeculativeJIT::compile):
1131         * dfg/DFGSpeculativeJIT64.cpp:
1132         (JSC::DFG::SpeculativeJIT::compile):
1133         * dfg/DFGStackLayoutPhase.cpp:
1134         (JSC::DFG::StackLayoutPhase::run):
1135         * dfg/DFGValidate.cpp:
1136         (JSC::DFG::Validate::validate):
1137         (JSC::DFG::Validate::validateCPS):
1138         (JSC::DFG::Validate::validateSSA):
1139         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
1140         (JSC::DFG::VirtualRegisterAllocationPhase::run):
1141         * ftl/FTLCapabilities.cpp:
1142         (JSC::FTL::canCompile):
1143         * ftl/FTLLowerDFGToLLVM.cpp:
1144         (JSC::FTL::LowerDFGToLLVM::lower):
1145         (JSC::FTL::LowerDFGToLLVM::compileNode):
1146         (JSC::FTL::LowerDFGToLLVM::compileGetStack):
1147         (JSC::FTL::LowerDFGToLLVM::compilePutStack):
1148         (JSC::FTL::LowerDFGToLLVM::compileGetLocal): Deleted.
1149         (JSC::FTL::LowerDFGToLLVM::compilePutLocal): Deleted.
1150         * ftl/FTLOSRExit.h:
1151         * tests/stress/many-sunken-locals.js: Added. This failure mode was caught by some miscellaneous test, so I figured I should write an explicit test for it.
1152         (foo):
1153         (bar):
1154         (baz):
1155         (fuzz):
1156         (buzz):
1157
1158 2015-02-26  Mark Lam  <mark.lam@apple.com>
1159
1160         Rolling out r180602, r180608, r180613, r180617, r180671.
1161         <https://webkit.org/b/141990>
1162
1163         Not reviewed.
1164
1165         The r180602 solution does result in more work for GC when worker
1166         threads are in use.  Filip is uncomfortable with that.
1167         The EFL and GTK ports also seem to be unhappy with this change.
1168         Rolling out while we investigate.
1169
1170         * heap/Heap.cpp:
1171         (JSC::Heap::Heap):
1172         (JSC::Heap::gatherStackRoots):
1173         (JSC::Heap::machineThreads): Deleted.
1174         * heap/Heap.h:
1175         (JSC::Heap::machineThreads):
1176         * heap/MachineStackMarker.cpp:
1177         (JSC::MachineThreads::MachineThreads):
1178         (JSC::MachineThreads::~MachineThreads):
1179         (JSC::MachineThreads::addCurrentThread):
1180         * heap/MachineStackMarker.h:
1181         * runtime/JSLock.cpp:
1182         (JSC::JSLock::didAcquireLock):
1183
1184 2015-02-26  Myles C. Maxfield  <mmaxfield@apple.com>
1185
1186         [Mac] [iOS] Parsing support for -apple-trailing-word
1187         https://bugs.webkit.org/show_bug.cgi?id=141939
1188
1189         Reviewed by Andreas Kling.
1190
1191         * Configurations/FeatureDefines.xcconfig:
1192
1193 2015-02-26  Michael Saboff  <msaboff@apple.com>
1194
1195         [Win] Debug-only JavaScriptCore failures
1196         https://bugs.webkit.org/show_bug.cgi?id=142045
1197
1198         Rubber stamped by Filip Pizlo.
1199
1200         Reduced loop count to a more reasonable value of 10,000.  This still gets us to tier up
1201         to the FTL, but doesn't take too long to run.
1202
1203         * tests/stress/repeated-arity-check-fail.js:
1204
1205 2015-02-26  Brent Fulgham  <bfulgham@apple.com>
1206
1207         [Win] Make build logs more legible by reducing noise
1208         https://bugs.webkit.org/show_bug.cgi?id=142034
1209
1210         Reviewed by Alexey Proskuryakov.
1211
1212         Modify batch files, makefiles, and DOS commands to remove
1213         uninteresting/unhelpful output.
1214
1215         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
1216         * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:
1217         * JavaScriptCore.vcxproj/copy-files.cmd:
1218         * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd:
1219         * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:
1220         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd:
1221         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:
1222         * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd:
1223         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd:
1224         * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd:
1225         * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:
1226
1227 2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>
1228
1229         Add calleeSaveRegisters() implementation for ARM Traditional
1230         https://bugs.webkit.org/show_bug.cgi?id=141903
1231
1232         Reviewed by Darin Adler.
1233
1234         * jit/RegisterSet.cpp:
1235         (JSC::RegisterSet::calleeSaveRegisters):
1236
1237 2015-02-25  Michael Saboff  <msaboff@apple.com>
1238
1239         Web Inspector: CRASH when debugger pauses inside a Promise handler
1240         https://bugs.webkit.org/show_bug.cgi?id=141396
1241
1242         Reviewed by Mark Lam.
1243
1244         For frames that don't have a scope, typically native frames, use the lexicalGlobalObject to
1245         create the DebuggerScope for that frame.
1246
1247         * debugger/DebuggerCallFrame.cpp:
1248         (JSC::DebuggerCallFrame::scope):
1249
1250 2015-02-25  Filip Pizlo  <fpizlo@apple.com>
1251
1252         DFG abstract heaps should respect the difference between heap and stack
1253         https://bugs.webkit.org/show_bug.cgi?id=142022
1254
1255         Reviewed by Geoffrey Garen.
1256         
1257         We will soon (https://bugs.webkit.org/show_bug.cgi?id=141174) be in a world where a "world
1258         clobbering" operation cannot write to our stack, but may be able to read from it. This
1259         means that we need to change the DFG abstract heap hierarchy to have a notion of Heap that
1260         subsumes all that World previously subsumed, and a new notion of Stack that is a subtype
1261         of World and a sibling of Heap.
1262
1263         So, henceforth "clobbering the world" means reading World and writing Heap.
1264         
1265         This makes a bunch of changes to make this work, including changing the implementation of
1266         disjointness in AbstractHeap to make it support a more general hierarchy. I was expecting
1267         a slow-down, but I measured the heck out of this and found no perf difference.
1268
1269         * dfg/DFGAbstractHeap.cpp:
1270         (JSC::DFG::AbstractHeap::dump):
1271         * dfg/DFGAbstractHeap.h:
1272         (JSC::DFG::AbstractHeap::supertype):
1273         (JSC::DFG::AbstractHeap::isStrictSubtypeOf):
1274         (JSC::DFG::AbstractHeap::isSubtypeOf):
1275         (JSC::DFG::AbstractHeap::overlaps):
1276         (JSC::DFG::AbstractHeap::isDisjoint):
1277         * dfg/DFGClobberize.cpp:
1278         (JSC::DFG::clobbersHeap):
1279         (JSC::DFG::clobbersWorld): Deleted.
1280         * dfg/DFGClobberize.h:
1281         (JSC::DFG::clobberize):
1282         * dfg/DFGDoesGC.cpp:
1283         (JSC::DFG::doesGC):
1284
1285 2015-02-25  Ryosuke Niwa  <rniwa@webkit.org>
1286
1287         REGRESSION(r180595): construct varargs fails in FTL
1288         https://bugs.webkit.org/show_bug.cgi?id=142030
1289
1290         Reviewed by Geoffrey Garen.
1291
1292         The bug was caused by IC size being too small for construct_varargs even though we've added a new argument.
1293         Fixed the bug by increasing the IC size to match call_varargs.
1294
1295         * ftl/FTLInlineCacheSize.cpp:
1296         (JSC::FTL::sizeOfConstructVarargs):
1297
1298 2015-02-25  Mark Lam  <mark.lam@apple.com>
1299
1300         ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
1301         <https://webkit.org/b/141672>
1302
1303         Reviewed by Alexey Proskuryakov.
1304
1305         ASan does not like the fact that we memcpy the stack for GC scans.  So,
1306         we're working around this by using our own memcpy (asanUnsafeMemcpy)
1307         implementation that we can tell ASan to ignore.
1308
1309         * heap/MachineStackMarker.cpp:
1310         (JSC::asanUnsafeMemcpy):
1311
1312 2015-02-25  Benjamin Poulain  <bpoulain@apple.com>
1313
1314         CodeBlock crashes when dumping op_push_name_scope
1315         https://bugs.webkit.org/show_bug.cgi?id=141953
1316
1317         Reviewed by Filip Pizlo and Csaba Osztrogonác.
1318
1319         * bytecode/CodeBlock.cpp:
1320         (JSC::CodeBlock::dumpBytecode):
1321         * tests/stress/op-push-name-scope-crashes-profiler.js: Added.
1322
1323 2015-02-25  Benjamin Poulain  <benjamin@webkit.org>
1324
1325         Make ParserError immutable by design
1326         https://bugs.webkit.org/show_bug.cgi?id=141955
1327
1328         Reviewed by Geoffrey Garen.
1329
1330         This patch enforce that no field of ParserError can
1331         be modified after the constructor.
1332
1333         * parser/ParserError.h:
1334         Move the attributes to pack the integer + 2 bytes together.
1335         This is irrelevant for memory impact, it is to remve a load-store
1336         when copying by value.
1337
1338         Also move the attributes to be private.
1339
1340         (JSC::ParserError::isValid):
1341         To client of the interface cared about the type of the error,
1342         the only information needed was: is there an error.
1343
1344         (JSC::ParserError::ParserError):
1345         (JSC::ParserError::syntaxErrorType):
1346         (JSC::ParserError::token):
1347         (JSC::ParserError::message):
1348         (JSC::ParserError::line):
1349         (JSC::ParserError::toErrorObject):
1350         * API/JSScriptRef.cpp:
1351         * builtins/BuiltinExecutables.cpp:
1352         (JSC::BuiltinExecutables::createBuiltinExecutable):
1353         * bytecode/UnlinkedCodeBlock.cpp:
1354         (JSC::generateFunctionCodeBlock):
1355         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1356         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
1357         * bytecode/UnlinkedCodeBlock.h:
1358         * inspector/agents/InspectorRuntimeAgent.cpp:
1359         (Inspector::InspectorRuntimeAgent::parse):
1360         * jsc.cpp:
1361         (runInteractive):
1362         * parser/Parser.h:
1363         (JSC::parse):
1364         * runtime/CodeCache.cpp:
1365         (JSC::CodeCache::getGlobalCodeBlock):
1366         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1367         * runtime/CodeCache.h:
1368         * runtime/Completion.h:
1369         * runtime/Executable.cpp:
1370         (JSC::ProgramExecutable::checkSyntax):
1371         * runtime/JSGlobalObject.cpp:
1372         (JSC::JSGlobalObject::createProgramCodeBlock):
1373         (JSC::JSGlobalObject::createEvalCodeBlock):
1374
1375 2015-02-25  Filip Pizlo  <fpizlo@apple.com>
1376
1377         Need to pass RTLD_DEEPBIND to dlopen() to ensure that our LLVMOverrides take effect on Linux
1378         https://bugs.webkit.org/show_bug.cgi?id=142006
1379
1380         Reviewed by Csaba Osztrogonác.
1381
1382         This fixes hard-to-reproduce concurrency-related crashes when running stress tests with FTL and
1383         concurrent JIT enabled.
1384
1385         * llvm/InitializeLLVMPOSIX.cpp:
1386         (JSC::initializeLLVMPOSIX):
1387
1388 2015-02-24  Filip Pizlo  <fpizlo@apple.com>
1389
1390         CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
1391         https://bugs.webkit.org/show_bug.cgi?id=141989
1392
1393         Reviewed by Gyuyoung Kim.
1394
1395         * CMakeLists.txt:
1396         * llvm/library/libllvmForJSC.version: Added.
1397
1398 2015-02-24  Alexey Proskuryakov  <ap@apple.com>
1399
1400         More iOS build fix after r180602.
1401
1402         * heap/Heap.h: Export Heap::machineThreads().
1403
1404 2015-02-24  Brent Fulgham  <bfulgham@apple.com>
1405
1406         Unreviewed build fix after r180602.
1407
1408         * heap/MachineStackMarker.h: Add missing 'no return'
1409         declaration for Windows.
1410
1411 2015-02-24  Commit Queue  <commit-queue@webkit.org>
1412
1413         Unreviewed, rolling out r180599.
1414         https://bugs.webkit.org/show_bug.cgi?id=141998
1415
1416         Lots of new test failures (Requested by smfr on #webkit).
1417
1418         Reverted changeset:
1419
1420         "Parsing support for -webkit-trailing-word"
1421         https://bugs.webkit.org/show_bug.cgi?id=141939
1422         http://trac.webkit.org/changeset/180599
1423
1424 2015-02-24  Mark Lam  <mark.lam@apple.com>
1425
1426         MachineThreads::Thread clean up has a use after free race condition.
1427         <https://webkit.org/b/141990>
1428
1429         Reviewed by Michael Saboff.
1430
1431         MachineThreads::Thread clean up relies on the clean up mechanism
1432         implemented in _pthread_tsd_cleanup_key(), which looks like this:
1433
1434         void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
1435         {
1436             void (*destructor)(void *);
1437             if (_pthread_key_get_destructor(key, &destructor)) {
1438                 void **ptr = &self->tsd[key];
1439                 void *value = *ptr;
1440
1441                 // At this point, this thread has cached "destructor" and "value"
1442                 // (which is a MachineThreads*).  If the VM gets destructed (along
1443                 // with its MachineThreads registry) by another thread, then this
1444                 // thread will have no way of knowing that the MachineThreads* is
1445                 // now pointing to freed memory.  Calling the destructor below will
1446                 // therefore result in a use after free scenario when it tries to
1447                 // access the MachineThreads' data members.
1448
1449                 if (value) {
1450                     *ptr = NULL;
1451                     if (destructor) {
1452                         destructor(value);
1453                     }
1454                 }
1455             }
1456         }
1457
1458         The solution is simply to change MachineThreads from a per VM thread
1459         registry to a process global singleton thread registry i.e. the
1460         MachineThreads registry is now immortal and we cannot have a use after
1461         free scenario since we never free it.
1462
1463         The cost of this change is that all VM instances will have to scan
1464         stacks of all threads ever touched by a VM, and not just those that
1465         touched a specific VM.  However, stacks tend to be shallow.  Hence,
1466         those additional scans will tend to be cheap.
1467
1468         Secondly, it is not common for there to be multiple JSC VMs in use
1469         concurrently on multiple threads.  Hence, this cost should rarely
1470         manifest in real world applications.
1471
1472         * heap/Heap.cpp:
1473         (JSC::Heap::Heap):
1474         (JSC::Heap::machineThreads):
1475         (JSC::Heap::gatherStackRoots):
1476         * heap/Heap.h:
1477         (JSC::Heap::machineThreads): Deleted.
1478         * heap/MachineStackMarker.cpp:
1479         (JSC::MachineThreads::MachineThreads):
1480         (JSC::MachineThreads::~MachineThreads):
1481         (JSC::MachineThreads::addCurrentThread):
1482         * heap/MachineStackMarker.h:
1483         * runtime/JSLock.cpp:
1484         (JSC::JSLock::didAcquireLock):
1485
1486 2015-02-24  Myles C. Maxfield  <mmaxfield@apple.com>
1487
1488         [Mac] [iOS] Parsing support for -apple-trailing-word
1489         https://bugs.webkit.org/show_bug.cgi?id=141939
1490
1491         Reviewed by Andreas Kling.
1492
1493         * Configurations/FeatureDefines.xcconfig:
1494
1495 2015-02-24  Ryosuke Niwa  <rniwa@webkit.org>
1496
1497         Use "this" instead of "callee" to get the constructor
1498         https://bugs.webkit.org/show_bug.cgi?id=141019
1499
1500         Reviewed by Filip Pizlo.
1501
1502         This patch uses "this" register to pass the constructor (newTarget) to op_create_this from
1503         op_construct or op_construct_varargs. This will allow future patches that implement ES6 class
1504         to pass in the most derived class' constructor through "this" argument.
1505
1506         BytecodeGenerator's emitConstruct and emitConstructVarargs now passes thisRegister like
1507         regular calls and emitCreateThis passes in this register to op_create_this as constructor.
1508
1509         The rest of the code change removes the code for special casing "this" register not being used
1510         in call to construct.
1511
1512         * bytecode/BytecodeUseDef.h:
1513         (JSC::computeUsesForBytecodeOffset):
1514         * bytecompiler/BytecodeGenerator.cpp:
1515         (JSC::BytecodeGenerator::emitCreateThis):
1516         (JSC::BytecodeGenerator::emitConstructVarargs):
1517         (JSC::BytecodeGenerator::emitConstruct):
1518         * bytecompiler/BytecodeGenerator.h:
1519         * bytecompiler/NodesCodegen.cpp:
1520         (JSC::NewExprNode::emitBytecode):
1521         * dfg/DFGByteCodeParser.cpp:
1522         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
1523         (JSC::DFG::ByteCodeParser::handleVarargsCall):
1524         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
1525         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1526         (JSC::DFG::ByteCodeParser::handleInlining):
1527         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1528         (JSC::DFG::ByteCodeParser::parseBlock):
1529         * dfg/DFGJITCode.cpp:
1530         (JSC::DFG::JITCode::reconstruct):
1531         * dfg/DFGSpeculativeJIT32_64.cpp:
1532         (JSC::DFG::SpeculativeJIT::emitCall):
1533         * dfg/DFGSpeculativeJIT64.cpp:
1534         (JSC::DFG::SpeculativeJIT::emitCall):
1535         * ftl/FTLJSCallVarargs.cpp:
1536         (JSC::FTL::JSCallVarargs::emit):
1537         * ftl/FTLLowerDFGToLLVM.cpp:
1538         (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
1539         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
1540         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
1541         * interpreter/Interpreter.cpp:
1542         (JSC::Interpreter::executeConstruct):
1543         * jit/JITOperations.cpp:
1544
1545 2015-02-24  Joseph Pecoraro  <pecoraro@apple.com>
1546
1547         Web Inspector: Make Getter/Setter RemoteObject property and ObjectPreview handling consistent
1548         https://bugs.webkit.org/show_bug.cgi?id=141587
1549
1550         Reviewed by Timothy Hatcher.
1551
1552         Convert getProperties(ownAndGetterProperties) to getDisplayableProperties().
1553         Mark PropertyDescriptors that are presumed to be native getters / bindings
1554         separately so that the frontend may display them differently.
1555
1556         * inspector/InjectedScript.cpp:
1557         (Inspector::InjectedScript::getProperties):
1558         (Inspector::InjectedScript::getDisplayableProperties):
1559         * inspector/InjectedScript.h:
1560         * inspector/InjectedScriptSource.js:
1561         * inspector/agents/InspectorRuntimeAgent.cpp:
1562         (Inspector::InspectorRuntimeAgent::getProperties):
1563         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
1564         * inspector/agents/InspectorRuntimeAgent.h:
1565         * inspector/protocol/Runtime.json:
1566
1567 2015-02-24  Mark Lam  <mark.lam@apple.com>
1568
1569         Rolling out r179753.  The fix was invalid.
1570         <https://webkit.org/b/141990>
1571
1572         Not reviewed.
1573
1574         * API/tests/testapi.mm:
1575         (threadMain):
1576         (useVMFromOtherThread): Deleted.
1577         (useVMFromOtherThreadAndOutliveVM): Deleted.
1578         * heap/Heap.cpp:
1579         (JSC::Heap::Heap):
1580         (JSC::Heap::~Heap):
1581         (JSC::Heap::gatherStackRoots):
1582         * heap/Heap.h:
1583         (JSC::Heap::machineThreads):
1584         * heap/MachineStackMarker.cpp:
1585         (JSC::MachineThreads::Thread::Thread):
1586         (JSC::MachineThreads::MachineThreads):
1587         (JSC::MachineThreads::~MachineThreads):
1588         (JSC::MachineThreads::addCurrentThread):
1589         (JSC::MachineThreads::removeThread):
1590         (JSC::MachineThreads::removeCurrentThread):
1591         * heap/MachineStackMarker.h:
1592
1593 2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1594
1595         Constructor returning null should construct an object instead of null
1596         https://bugs.webkit.org/show_bug.cgi?id=141640
1597
1598         Reviewed by Filip Pizlo.
1599
1600         When constructor code doesn't return object, constructor should return `this` object instead.
1601         Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
1602         it allows `null` as an object.
1603         This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
1604         Instead, constructor uses simplified `is_object`.
1605
1606         As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
1607
1608         1. LLInt and baseline JIT support `op_is_object` as a fast path.
1609         2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
1610         3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
1611         4. FTL lowers DFG's IsObject into LLVM IR.
1612
1613         And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
1614         in LLInt, JIT, DFG and FTL.
1615         Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
1616         So in many places, when the cell is not object, we recognize it as a string, and vice versa.
1617         However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
1618         So this patch stop using !isString as isObject.
1619         To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
1620         we examine typeInfo in JSCell.
1621
1622         * JavaScriptCore.order:
1623         * bytecode/BytecodeList.json:
1624         * bytecode/BytecodeUseDef.h:
1625         (JSC::computeUsesForBytecodeOffset):
1626         (JSC::computeDefsForBytecodeOffset):
1627         * bytecode/CodeBlock.cpp:
1628         (JSC::CodeBlock::dumpBytecode):
1629         * bytecode/PutByIdStatus.cpp:
1630         (JSC::PutByIdStatus::computeFor):
1631         * bytecompiler/BytecodeGenerator.cpp:
1632         (JSC::BytecodeGenerator::emitEqualityOp):
1633         (JSC::BytecodeGenerator::emitReturn):
1634         * dfg/DFGAbstractInterpreterInlines.h:
1635         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1636         * dfg/DFGByteCodeParser.cpp:
1637         (JSC::DFG::ByteCodeParser::parseBlock):
1638         * dfg/DFGCapabilities.cpp:
1639         (JSC::DFG::capabilityLevel):
1640         * dfg/DFGClobberize.h:
1641         (JSC::DFG::clobberize):
1642
1643         IsObject operation only touches JSCell typeInfoType.
1644         And this value would be changed through structure transition.
1645         As a result, IsObject can report that it doesn't read any information.
1646
1647         * dfg/DFGConstantFoldingPhase.cpp:
1648         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1649         * dfg/DFGDoesGC.cpp:
1650         (JSC::DFG::doesGC):
1651         * dfg/DFGFixupPhase.cpp:
1652         (JSC::DFG::FixupPhase::fixupNode):
1653
1654         Just like IsString, IsObject is also fixed up.
1655
1656         * dfg/DFGHeapLocation.cpp:
1657         (WTF::printInternal):
1658         * dfg/DFGHeapLocation.h:
1659         * dfg/DFGNodeType.h:
1660         * dfg/DFGOperations.cpp:
1661         * dfg/DFGOperations.h:
1662         * dfg/DFGPredictionPropagationPhase.cpp:
1663         (JSC::DFG::PredictionPropagationPhase::propagate):
1664         * dfg/DFGSafeToExecute.h:
1665         (JSC::DFG::safeToExecute):
1666         * dfg/DFGSpeculativeJIT.cpp:
1667         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
1668         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
1669         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
1670         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
1671         (JSC::DFG::SpeculativeJIT::speculateObject):
1672         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
1673         (JSC::DFG::SpeculativeJIT::speculateString):
1674         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
1675         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
1676         (JSC::DFG::SpeculativeJIT::emitSwitchString):
1677         (JSC::DFG::SpeculativeJIT::branchIsObject):
1678         (JSC::DFG::SpeculativeJIT::branchNotObject):
1679         (JSC::DFG::SpeculativeJIT::branchIsString):
1680         (JSC::DFG::SpeculativeJIT::branchNotString):
1681         * dfg/DFGSpeculativeJIT.h:
1682         * dfg/DFGSpeculativeJIT32_64.cpp:
1683         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1684         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1685         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1686         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1687         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1688         (JSC::DFG::SpeculativeJIT::compile):
1689         * dfg/DFGSpeculativeJIT64.cpp:
1690         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1691         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1692         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1693         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1694         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1695         (JSC::DFG::SpeculativeJIT::compile):
1696         * ftl/FTLCapabilities.cpp:
1697         (JSC::FTL::canCompile):
1698         * ftl/FTLLowerDFGToLLVM.cpp:
1699         (JSC::FTL::LowerDFGToLLVM::compileNode):
1700         (JSC::FTL::LowerDFGToLLVM::compileToString):
1701         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
1702         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
1703         (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
1704         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
1705         (JSC::FTL::LowerDFGToLLVM::isObject):
1706         (JSC::FTL::LowerDFGToLLVM::isNotObject):
1707         (JSC::FTL::LowerDFGToLLVM::isNotString):
1708         (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
1709         * jit/JIT.cpp:
1710         (JSC::JIT::privateCompileMainPass):
1711         * jit/JIT.h:
1712         * jit/JITInlines.h:
1713         (JSC::JIT::emitJumpIfCellObject):
1714         * jit/JITOpcodes.cpp:
1715         (JSC::JIT::emit_op_is_object):
1716         (JSC::JIT::emit_op_to_primitive):
1717         * jit/JITOpcodes32_64.cpp:
1718         (JSC::JIT::emit_op_is_object):
1719         (JSC::JIT::emit_op_to_primitive):
1720         (JSC::JIT::compileOpStrictEq):
1721         * llint/LowLevelInterpreter.asm:
1722         * llint/LowLevelInterpreter32_64.asm:
1723         * llint/LowLevelInterpreter64.asm:
1724         * runtime/CommonSlowPaths.cpp:
1725         (JSC::SLOW_PATH_DECL):
1726         * runtime/CommonSlowPaths.h:
1727         * runtime/Operations.cpp:
1728         (JSC::jsIsObjectTypeOrNull):
1729         (JSC::jsIsObjectType): Deleted.
1730         * runtime/Operations.h:
1731         * tests/stress/constructor-with-return.js: Added.
1732         (Test):
1733
1734         When constructor doesn't return an object, `this` should be returned instead.
1735         In this test, we check all primitives. And test object, array and wrappers.
1736
1737         * tests/stress/dfg-to-primitive-pass-symbol.js: Added.
1738         (toPrimitiveTarget):
1739         (doToPrimitive):
1740
1741         op_to_primitive operation passes Symbol in fast path.
1742
1743 2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1744
1745         REGRESSION(r179429): Can't type comments in Facebook
1746         https://bugs.webkit.org/show_bug.cgi?id=141859
1747
1748         Reviewed by Brent Fulgham.
1749
1750         When window.Symbol is exposed to user-space pages,
1751         Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
1752         However, to work with Symbols completely, it also requires
1753         1) Object.getOwnPropertySymbols (for mixin including Symbols)
1754         2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
1755         Since they are not landed yet, comments in Facebook don't work.
1756
1757         This patch introduces RuntimeFlags for JavaScriptCore.
1758         Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
1759         And drop JavaScriptExperimentsEnabled flag
1760         because it is no longer used and use case of this is duplicated to runtime flags.
1761
1762         * JavaScriptCore.order:
1763         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1764         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1765         * JavaScriptCore.xcodeproj/project.pbxproj:
1766         * jsc.cpp:
1767         (GlobalObject::javaScriptRuntimeFlags):
1768         (GlobalObject::javaScriptExperimentsEnabled): Deleted.
1769         * runtime/JSGlobalObject.cpp:
1770         (JSC::JSGlobalObject::JSGlobalObject):
1771         (JSC::JSGlobalObject::init):
1772         * runtime/JSGlobalObject.h:
1773         (JSC::JSGlobalObject::finishCreation):
1774         (JSC::JSGlobalObject::javaScriptRuntimeFlags):
1775         (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
1776         * runtime/RuntimeFlags.h: Added.
1777         (JSC::RuntimeFlags::RuntimeFlags):
1778         (JSC::RuntimeFlags::createAllEnabled):
1779
1780 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
1781
1782         Our bizarre behavior on Arguments::defineOwnProperty should be deliberate rather than a spaghetti incident
1783         https://bugs.webkit.org/show_bug.cgi?id=141951
1784
1785         Reviewed by Benjamin Poulain.
1786         
1787         This patch has no behavioral change, but it simplifies a bunch of wrong code. The code is
1788         still wrong in exactly the same way, but at least it's obvious what's going on. The wrongness
1789         is covered by this bug: https://bugs.webkit.org/show_bug.cgi?id=141952.
1790
1791         * runtime/Arguments.cpp:
1792         (JSC::Arguments::copyBackingStore): We should only see the arguments token; assert otherwise. This works because if the GC sees the butterfly token it calls the JSObject::copyBackingStore method directly.
1793         (JSC::Arguments::defineOwnProperty): Make our bizarre behavior deliberate rather than an accident of a decade of patches.
1794         * tests/stress/arguments-bizarre-behavior.js: Added.
1795         (foo):
1796         * tests/stress/arguments-bizarre-behaviour-disable-enumerability.js: Added. My choice of spellings of the word "behavio[u]r" is almost as consistent as our implementation of arguments.
1797         (foo):
1798         * tests/stress/arguments-custom-properties-gc.js: Added. I added this test because at first I was unsure if we GCd arguments correctly.
1799         (makeBaseArguments):
1800         (makeArray):
1801         (cons):
1802
1803 2015-02-23  Commit Queue  <commit-queue@webkit.org>
1804
1805         Unreviewed, rolling out r180547 and r180550.
1806         https://bugs.webkit.org/show_bug.cgi?id=141957
1807
1808         Broke 10 Windows tests. (Requested by bfulgham_ on #webkit).
1809
1810         Reverted changesets:
1811
1812         "REGRESSION(r179429): Can't type comments in Facebook"
1813         https://bugs.webkit.org/show_bug.cgi?id=141859
1814         http://trac.webkit.org/changeset/180547
1815
1816         "Constructor returning null should construct an object instead
1817         of null"
1818         https://bugs.webkit.org/show_bug.cgi?id=141640
1819         http://trac.webkit.org/changeset/180550
1820
1821 2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>
1822
1823         Constructor returning null should construct an object instead of null
1824         https://bugs.webkit.org/show_bug.cgi?id=141640
1825
1826         Reviewed by Geoffrey Garen.
1827
1828         When constructor code doesn't return object, constructor should return `this` object instead.
1829         Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
1830         it allows `null` as an object.
1831         This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
1832         Instead, constructor uses simplified `is_object`.
1833
1834         As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
1835
1836         1. LLInt and baseline JIT support `op_is_object` as a fast path.
1837         2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
1838         3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
1839         4. FTL lowers DFG's IsObject into LLVM IR.
1840
1841         And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
1842         in LLInt, JIT, DFG and FTL.
1843         Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
1844         So in many places, when the cell is not object, we recognize it as a string, and vice versa.
1845         However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
1846         So this patch stop using !isString as isObject.
1847         To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
1848         we examine typeInfo in JSCell.
1849
1850         * JavaScriptCore.order:
1851         * bytecode/BytecodeList.json:
1852         * bytecode/BytecodeUseDef.h:
1853         (JSC::computeUsesForBytecodeOffset):
1854         (JSC::computeDefsForBytecodeOffset):
1855         * bytecode/CodeBlock.cpp:
1856         (JSC::CodeBlock::dumpBytecode):
1857         * bytecode/PutByIdStatus.cpp:
1858         (JSC::PutByIdStatus::computeFor):
1859         * bytecompiler/BytecodeGenerator.cpp:
1860         (JSC::BytecodeGenerator::emitEqualityOp):
1861         (JSC::BytecodeGenerator::emitReturn):
1862         * dfg/DFGAbstractInterpreterInlines.h:
1863         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1864         * dfg/DFGByteCodeParser.cpp:
1865         (JSC::DFG::ByteCodeParser::parseBlock):
1866         * dfg/DFGCapabilities.cpp:
1867         (JSC::DFG::capabilityLevel):
1868         * dfg/DFGClobberize.h:
1869         (JSC::DFG::clobberize):
1870
1871         IsObject operation only touches JSCell typeInfoType.
1872         And this value would not be changed through structure transition.
1873         As a result, IsObject can report that it doesn't read any information.
1874
1875         * dfg/DFGDoesGC.cpp:
1876         (JSC::DFG::doesGC):
1877         * dfg/DFGFixupPhase.cpp:
1878         (JSC::DFG::FixupPhase::fixupNode):
1879
1880         Just like IsString, IsObject is also fixed up.
1881
1882         * dfg/DFGHeapLocation.cpp:
1883         (WTF::printInternal):
1884         * dfg/DFGHeapLocation.h:
1885         * dfg/DFGNodeType.h:
1886         * dfg/DFGOperations.cpp:
1887         * dfg/DFGOperations.h:
1888         * dfg/DFGPredictionPropagationPhase.cpp:
1889         (JSC::DFG::PredictionPropagationPhase::propagate):
1890         * dfg/DFGSafeToExecute.h:
1891         (JSC::DFG::safeToExecute):
1892         * dfg/DFGSpeculativeJIT.cpp:
1893         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
1894         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
1895         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
1896         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
1897         (JSC::DFG::SpeculativeJIT::speculateObject):
1898         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
1899         (JSC::DFG::SpeculativeJIT::speculateString):
1900         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
1901         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
1902         (JSC::DFG::SpeculativeJIT::emitSwitchString):
1903         (JSC::DFG::SpeculativeJIT::branchIsObject):
1904         (JSC::DFG::SpeculativeJIT::branchNotObject):
1905         (JSC::DFG::SpeculativeJIT::branchIsString):
1906         (JSC::DFG::SpeculativeJIT::branchNotString):
1907         * dfg/DFGSpeculativeJIT.h:
1908         * dfg/DFGSpeculativeJIT32_64.cpp:
1909         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1910         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1911         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1912         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1913         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1914         (JSC::DFG::SpeculativeJIT::compile):
1915         * dfg/DFGSpeculativeJIT64.cpp:
1916         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1917         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1918         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1919         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1920         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1921         (JSC::DFG::SpeculativeJIT::compile):
1922         * ftl/FTLCapabilities.cpp:
1923         (JSC::FTL::canCompile):
1924         * ftl/FTLLowerDFGToLLVM.cpp:
1925         (JSC::FTL::LowerDFGToLLVM::compileNode):
1926         (JSC::FTL::LowerDFGToLLVM::compileToString):
1927         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
1928         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
1929         (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
1930         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
1931         (JSC::FTL::LowerDFGToLLVM::isObject):
1932         (JSC::FTL::LowerDFGToLLVM::isNotObject):
1933         (JSC::FTL::LowerDFGToLLVM::isNotString):
1934         (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
1935         * jit/JIT.cpp:
1936         (JSC::JIT::privateCompileMainPass):
1937         * jit/JIT.h:
1938         * jit/JITInlines.h:
1939         (JSC::JIT::emitJumpIfCellObject):
1940         * jit/JITOpcodes.cpp:
1941         (JSC::JIT::emit_op_is_object):
1942         (JSC::JIT::emit_op_to_primitive):
1943         * jit/JITOpcodes32_64.cpp:
1944         (JSC::JIT::emit_op_is_object):
1945         (JSC::JIT::emit_op_to_primitive):
1946         (JSC::JIT::compileOpStrictEq):
1947         * llint/LowLevelInterpreter.asm:
1948         * llint/LowLevelInterpreter32_64.asm:
1949         * llint/LowLevelInterpreter64.asm:
1950         * runtime/CommonSlowPaths.cpp:
1951         (JSC::SLOW_PATH_DECL):
1952         * runtime/CommonSlowPaths.h:
1953         * runtime/Operations.cpp:
1954         (JSC::jsIsObjectTypeOrNull):
1955         (JSC::jsIsObjectType): Deleted.
1956         * runtime/Operations.h:
1957
1958 2015-02-23  Ryosuke Niwa  <rniwa@webkit.org>
1959
1960         Disable font loading events until our implementation gets updated to match the latest spec
1961         https://bugs.webkit.org/show_bug.cgi?id=141938
1962
1963         Reviewed by Andreas Kling.
1964
1965         * Configurations/FeatureDefines.xcconfig:
1966
1967 2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>
1968
1969         REGRESSION(r179429): Can't type comments in Facebook
1970         https://bugs.webkit.org/show_bug.cgi?id=141859
1971
1972         Reviewed by Geoffrey Garen.
1973
1974         When window.Symbol is exposed to user-space pages,
1975         Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
1976         However, to work with Symbols completely, it also requires
1977         1) Object.getOwnPropertySymbols (for mixin including Symbols)
1978         2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
1979         Since they are not landed yet, comments in Facebook don't work.
1980
1981         This patch introduces RuntimeFlags for JavaScriptCore.
1982         Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
1983         And drop JavaScriptExperimentsEnabled flag
1984         because it is no longer used and use case of this is duplicated to runtime flags.
1985
1986         * JavaScriptCore.order:
1987         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1988         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1989         * JavaScriptCore.xcodeproj/project.pbxproj:
1990         * jsc.cpp:
1991         (GlobalObject::javaScriptRuntimeFlags):
1992         (GlobalObject::javaScriptExperimentsEnabled): Deleted.
1993         * runtime/JSGlobalObject.cpp:
1994         (JSC::JSGlobalObject::JSGlobalObject):
1995         (JSC::JSGlobalObject::init):
1996         * runtime/JSGlobalObject.h:
1997         (JSC::JSGlobalObject::finishCreation):
1998         (JSC::JSGlobalObject::javaScriptRuntimeFlags):
1999         (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
2000         * runtime/RuntimeFlags.h: Added.
2001         (JSC::RuntimeFlags::RuntimeFlags):
2002         (JSC::RuntimeFlags::createAllEnabled):
2003
2004 2015-02-23  Benjamin Poulain  <bpoulain@apple.com>
2005
2006         Set the semantic origin of delayed SetLocal to the Bytecode that originated it
2007         https://bugs.webkit.org/show_bug.cgi?id=141727
2008
2009         Reviewed by Filip Pizlo.
2010
2011         Previously, delayed SetLocals would have the NodeOrigin of the next
2012         bytecode. This was because delayed SetLocal are...delayed... and
2013         currentCodeOrigin() is the one where the node is emitted.
2014
2015         This made debugging a little awkward since the OSR exits on SetLocal
2016         were reported for the next bytecode. This patch changes the semantic
2017         origin to keep the original bytecode.
2018
2019         From benchmarks, this looks like it could be a tiny bit faster
2020         but it likely just noise.
2021
2022         * dfg/DFGByteCodeParser.cpp:
2023         (JSC::DFG::ByteCodeParser::setDirect):
2024         (JSC::DFG::ByteCodeParser::setLocal):
2025         (JSC::DFG::ByteCodeParser::setArgument):
2026         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
2027         (JSC::DFG::ByteCodeParser::addToGraph):
2028         (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
2029         (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
2030
2031 2015-02-23  Benjamin Poulain  <bpoulain@apple.com>
2032
2033         Remove DFGNode::predictHeap()
2034         https://bugs.webkit.org/show_bug.cgi?id=141864
2035
2036         Reviewed by Geoffrey Garen.
2037
2038         * dfg/DFGNode.h:
2039         (JSC::DFG::Node::predictHeap): Deleted.
2040         Unused code.
2041
2042 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
2043
2044         Get rid of JSLexicalEnvironment::argumentsGetter
2045         https://bugs.webkit.org/show_bug.cgi?id=141930
2046
2047         Reviewed by Mark Lam.
2048         
2049         This function is unused, and the way it's written is bizarre - it's a return statement that
2050         dominates a bunch of dead code.
2051
2052         * runtime/JSLexicalEnvironment.cpp:
2053         (JSC::JSLexicalEnvironment::argumentsGetter): Deleted.
2054         * runtime/JSLexicalEnvironment.h:
2055
2056 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
2057
2058         Remove unused activationCount and allTheThingsCount variable declarations.
2059
2060         Rubber stamped by Mark Lam and Michael Saboff.
2061
2062         * runtime/JSLexicalEnvironment.h:
2063
2064 2015-02-23  Saam Barati  <saambarati1@gmail.com>
2065
2066         Adjust the ranges of basic block statements in JSC's control flow profiler to be mutually exclusive
2067         https://bugs.webkit.org/show_bug.cgi?id=141095
2068
2069         Reviewed by Mark Lam.
2070
2071         Suppose the control flow of a program forms basic block A with successor block
2072         B. A's end offset will be the *same* as B's start offset in the current architecture 
2073         of the control flow profiler. This makes reasoning about the text offsets of
2074         the control flow profiler unsound. To make reasoning about offsets sound, all 
2075         basic block ranges should be mutually exclusive.  All calls to emitProfileControlFlow 
2076         now pass in the *start* of a basic block as the text offset argument. This simplifies 
2077         all calls to emitProfileControlFlow because the previous implementation had a
2078         lot of edge cases for getting the desired basic block text boundaries.
2079
2080         This patch also ensures that the basic block boundary of a block statement 
2081         is the exactly the block's open and close brace offsets (inclusive). For example,
2082         in if/for/while statements. This also has the consequence that for statements 
2083         like "if (cond) foo();", the whitespace preceding "foo()" is not part of 
2084         the "foo()" basic block, but instead is part of the "if (cond) " basic block. 
2085         This is okay because these text offsets aren't meant to be human readable.
2086         Instead, they reflect the text offsets of JSC's AST nodes. The Web Inspector 
2087         is the only client of this API and user of these text offsets and it is 
2088         not negatively effected by this new behavior.
2089
2090         * bytecode/CodeBlock.cpp:
2091         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
2092         When computing basic block boundaries in CodeBlock, we ensure that every
2093         block's end offset is one less than its successor's start offset to
2094         maintain that boundaries' ranges should be mutually exclusive.
2095
2096         * bytecompiler/BytecodeGenerator.cpp:
2097         (JSC::BytecodeGenerator::BytecodeGenerator):
2098         Because the control flow profiler needs to know which functions
2099         have executed, we can't lazily create functions. This was a bug 
2100         from before that was hidden because the Type Profiler was always 
2101         enabled when the control flow profiler was enabled when profiling 
2102         was turned on from the Web Inspector. But, JSC allows for Control 
2103         Flow profiling to be turned on without Type Profiling, so we need 
2104         to ensure the Control Flow profiler has all the data it needs.
2105
2106         * bytecompiler/NodesCodegen.cpp:
2107         (JSC::ConditionalNode::emitBytecode):
2108         (JSC::IfElseNode::emitBytecode):
2109         (JSC::WhileNode::emitBytecode):
2110         (JSC::ForNode::emitBytecode):
2111         (JSC::ForInNode::emitMultiLoopBytecode):
2112         (JSC::ForOfNode::emitBytecode):
2113         (JSC::TryNode::emitBytecode):
2114         * jsc.cpp:
2115         (functionHasBasicBlockExecuted):
2116         We now assert that the substring argument is indeed a substring
2117         of the function argument's text because subtle bugs could be
2118         introduced otherwise.
2119
2120         * parser/ASTBuilder.h:
2121         (JSC::ASTBuilder::setStartOffset):
2122         * parser/Nodes.h:
2123         (JSC::Node::setStartOffset):
2124         * parser/Parser.cpp:
2125         (JSC::Parser<LexerType>::parseBlockStatement):
2126         (JSC::Parser<LexerType>::parseStatement):
2127         (JSC::Parser<LexerType>::parseMemberExpression):
2128         For the various function call AST nodes, their m_position member 
2129         variable is now the start of the entire function call expression 
2130         and not at the start of the open paren of the arguments list.
2131
2132         * runtime/BasicBlockLocation.cpp:
2133         (JSC::BasicBlockLocation::getExecutedRanges):
2134         * runtime/ControlFlowProfiler.cpp:
2135         (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
2136         Function ranges inserted as gaps should follow the same criteria
2137         that the bytecode generator uses to ensure that basic blocks
2138         start and end offsets are mutually exclusive.
2139
2140         * tests/controlFlowProfiler/brace-location.js: Added.
2141         (foo):
2142         (bar):
2143         (baz):
2144         (testIf):
2145         (testForRegular):
2146         (testForIn):
2147         (testForOf):
2148         (testWhile):
2149         (testIfNoBraces):
2150         (testForRegularNoBraces):
2151         (testForInNoBraces):
2152         (testForOfNoBraces):
2153         (testWhileNoBraces):
2154         * tests/controlFlowProfiler/conditional-expression.js: Added.
2155         (foo):
2156         (bar):
2157         (baz):
2158         (testConditionalBasic):
2159         (testConditionalFunctionCall):
2160         * tests/controlFlowProfiler/driver/driver.js:
2161         (checkBasicBlock):
2162
2163 2015-02-23  Matthew Mirman  <mmirman@apple.com>
2164
2165         r9 is volatile on ARMv7 for iOS 3 and up. 
2166         https://bugs.webkit.org/show_bug.cgi?id=141489
2167         rdar://problem/19432916
2168
2169         Reviewed by Michael Saboff.
2170
2171         * jit/RegisterSet.cpp: 
2172         (JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers.
2173         * tests/stress/regress-141489.js: Added.
2174         (foo):
2175
2176 2015-02-23  Csaba Osztrogonác  <ossy@webkit.org>
2177
2178         [ARM] Add the necessary setupArgumentsWithExecState after bug141915
2179         https://bugs.webkit.org/show_bug.cgi?id=141921
2180
2181         Reviewed by Michael Saboff.
2182
2183         * jit/CCallHelpers.h:
2184         (JSC::CCallHelpers::setupArgumentsWithExecState):
2185
2186 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
2187
2188         Scopes should always be created with a previously-created symbol table rather than creating one on the fly
2189         https://bugs.webkit.org/show_bug.cgi?id=141915
2190
2191         Reviewed by Mark Lam.
2192         
2193         The main effect of this change is that pushing name scopes no longer requires creating symbol
2194         tables on the fly.
2195         
2196         This also makes it so that JSEnvironmentRecords must always have an a priori symbol table.
2197         
2198         JSSegmentedVariableObject still does a hack where it creates a blank symbol table on-demand.
2199         This is needed because that's what JSGlobalObject and all of its many subclasses want. That's
2200         harmless; I mainly needed a prior symbol tables for JSEnvironmentRecords anyway.
2201
2202         * bytecode/BytecodeList.json:
2203         * bytecompiler/BytecodeGenerator.cpp:
2204         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
2205         (JSC::BytecodeGenerator::emitPushCatchScope):
2206         * jit/CCallHelpers.h:
2207         (JSC::CCallHelpers::setupArgumentsWithExecState):
2208         * jit/JIT.h:
2209         * jit/JITInlines.h:
2210         (JSC::JIT::callOperation):
2211         * jit/JITOpcodes.cpp:
2212         (JSC::JIT::emit_op_push_name_scope):
2213         * jit/JITOpcodes32_64.cpp:
2214         (JSC::JIT::emit_op_push_name_scope):
2215         * jit/JITOperations.cpp:
2216         (JSC::pushNameScope):
2217         * jit/JITOperations.h:
2218         * llint/LLIntSlowPaths.cpp:
2219         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2220         * llint/LowLevelInterpreter.asm:
2221         * runtime/Executable.cpp:
2222         (JSC::ScriptExecutable::newCodeBlockFor):
2223         * runtime/JSCatchScope.h:
2224         (JSC::JSCatchScope::JSCatchScope):
2225         (JSC::JSCatchScope::create):
2226         * runtime/JSEnvironmentRecord.h:
2227         (JSC::JSEnvironmentRecord::JSEnvironmentRecord):
2228         * runtime/JSFunctionNameScope.h:
2229         (JSC::JSFunctionNameScope::JSFunctionNameScope):
2230         (JSC::JSFunctionNameScope::create):
2231         * runtime/JSNameScope.cpp:
2232         (JSC::JSNameScope::create):
2233         * runtime/JSNameScope.h:
2234         (JSC::JSNameScope::create):
2235         (JSC::JSNameScope::finishCreation):
2236         (JSC::JSNameScope::JSNameScope):
2237         * runtime/JSSegmentedVariableObject.h:
2238         (JSC::JSSegmentedVariableObject::finishCreation):
2239         * runtime/JSSymbolTableObject.h:
2240         (JSC::JSSymbolTableObject::JSSymbolTableObject):
2241         (JSC::JSSymbolTableObject::finishCreation): Deleted.
2242         * runtime/SymbolTable.h:
2243         (JSC::SymbolTable::createNameScopeTable):
2244
2245 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
2246
2247         Add a comment to clarify that the test was taken from the bug report, in response to
2248         feedback from Michael Saboff and Benjamin Poulain.
2249         
2250         * tests/stress/regress-141883.js:
2251
2252 2015-02-22  Filip Pizlo  <fpizlo@apple.com>
2253
2254         Function name scope is only created on the function instance that triggered parsing rather than on every function instance that needs it
2255         https://bugs.webkit.org/show_bug.cgi?id=141881
2256
2257         Reviewed by Michael Saboff.
2258         
2259         Previously we only created the function name scope in a way that made it visible to the
2260         function that triggered parsing/linking of the executable/codeBlock, and to the linker for
2261         that code block. This was sort of the bare minimum for the feature to appear to work right to
2262         synthetic tests.
2263
2264         There are two valid "times" to create the function name scope. Either it's created for each
2265         JSFunction instance that needs a name scope, or it's created for each execution of such a
2266         JSFunction. This change chooses the latter, because it happens to be the easiest to implement
2267         with what we have right now. I opened a bug for optimizing this if we ever need to:
2268         https://bugs.webkit.org/show_bug.cgi?id=141887.
2269         
2270         * bytecompiler/BytecodeGenerator.cpp:
2271         (JSC::BytecodeGenerator::BytecodeGenerator):
2272         * interpreter/Interpreter.cpp:
2273         (JSC::Interpreter::execute):
2274         (JSC::Interpreter::executeCall):
2275         (JSC::Interpreter::executeConstruct):
2276         (JSC::Interpreter::prepareForRepeatCall):
2277         * jit/JITOperations.cpp:
2278         * llint/LLIntSlowPaths.cpp:
2279         (JSC::LLInt::setUpCall):
2280         * runtime/ArrayPrototype.cpp:
2281         (JSC::isNumericCompareFunction):
2282         * runtime/Executable.cpp:
2283         (JSC::ScriptExecutable::newCodeBlockFor):
2284         (JSC::ScriptExecutable::prepareForExecutionImpl):
2285         (JSC::FunctionExecutable::FunctionExecutable):
2286         * runtime/Executable.h:
2287         (JSC::ScriptExecutable::prepareForExecution):
2288         * runtime/JSFunction.cpp:
2289         (JSC::JSFunction::addNameScopeIfNeeded): Deleted.
2290         * runtime/JSFunction.h:
2291         * tests/stress/function-name-scope.js: Added.
2292         (check.verify):
2293         (check):
2294
2295 2015-02-22  Filip Pizlo  <fpizlo@apple.com>
2296
2297         Crash in DFGFrozenValue
2298         https://bugs.webkit.org/show_bug.cgi?id=141883
2299
2300         Reviewed by Benjamin Poulain.
2301         
2302         If a value might be a cell, then we have to have Graph freeze it rather than trying to
2303         create the FrozenValue directly. Creating it directly is just an optimization for when you
2304         know for sure that it cannot be a cell.
2305
2306         * dfg/DFGAbstractInterpreterInlines.h:
2307         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2308         * tests/stress/regress-141883.js: Added. Hacked the original test to be faster while still crashing before this fix.
2309
2310 2015-02-21  Joseph Pecoraro  <pecoraro@apple.com>
2311
2312         Web Inspector: Generate Previews more often for RemoteObject interaction
2313         https://bugs.webkit.org/show_bug.cgi?id=141875
2314
2315         Reviewed by Timothy Hatcher.
2316
2317         * inspector/protocol/Runtime.json:
2318         Add generatePreview to getProperties.
2319
2320         * inspector/InjectedScript.cpp:
2321         (Inspector::InjectedScript::getProperties):
2322         (Inspector::InjectedScript::getInternalProperties):
2323         * inspector/InjectedScript.h:
2324         * inspector/agents/InspectorRuntimeAgent.cpp:
2325         (Inspector::InspectorRuntimeAgent::getProperties):
2326         * inspector/agents/InspectorRuntimeAgent.h:
2327         Plumb the generatePreview boolean through to the injected script.
2328
2329         * inspector/InjectedScriptSource.js:
2330         Add generatePreview for getProperties.
2331         Fix callFunctionOn to generatePreviews if asked.
2332
2333 2015-02-20  Mark Lam  <mark.lam@apple.com>
2334
2335         Refactor JSWrapperMap.mm to defer creation of the ObjC JSValue until the latest possible moment.
2336         <https://webkit.org/b/141856>
2337
2338         Reviewed by Geoffrey Garen.
2339
2340         1. Make JSObjCClassInfo's -constructor and -wrapperForObject return a
2341            JSC::JSObject* just like -prototype.
2342         2. Defer the creation of the ObjC JSValue from JSC::JSObject* until
2343            the latest moment when it is needed.  This allows us to not have to
2344            keep converting back to a JSC::JSObject* in intermediate code.
2345
2346         * API/JSWrapperMap.mm:
2347         (makeWrapper):
2348         (objectWithCustomBrand):
2349         (constructorWithCustomBrand):
2350         (allocateConstructorForCustomClass):
2351         (-[JSObjCClassInfo allocateConstructorAndPrototype]):
2352         (-[JSObjCClassInfo wrapperForObject:]):
2353         (-[JSObjCClassInfo constructor]):
2354         (-[JSWrapperMap jsWrapperForObject:]):
2355
2356 2015-02-20  Filip Pizlo  <fpizlo@apple.com>
2357
2358         Build fix for gcc.
2359
2360         * runtime/JSNameScope.cpp:
2361         (JSC::JSNameScope::create):
2362
2363 2015-02-20  Filip Pizlo  <fpizlo@apple.com>
2364
2365         Get rid of JSNameScope::m_type
2366         https://bugs.webkit.org/show_bug.cgi?id=141851
2367
2368         Reviewed by Geoffrey Garen.
2369         
2370         This is a big step towards getting rid of JSEnvironmentRecord::m_registers. To do it we need
2371         to ensure that subclasses of JSEnvironmentRecord never have additional C++ fields, so that
2372         JSEnvironmentRecord can always place "registers" right after the end of itself.
2373
2374         * CMakeLists.txt:
2375         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2376         * JavaScriptCore.xcodeproj/project.pbxproj:
2377         * debugger/DebuggerScope.cpp:
2378         (JSC::DebuggerScope::isCatchScope):
2379         (JSC::DebuggerScope::isFunctionNameScope):
2380         * interpreter/Interpreter.cpp:
2381         (JSC::Interpreter::execute):
2382         * jit/JITOperations.cpp:
2383         * llint/LLIntSlowPaths.cpp:
2384         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2385         * runtime/JSCatchScope.cpp: Added.
2386         * runtime/JSCatchScope.h: Added.
2387         (JSC::JSCatchScope::JSCatchScope):
2388         (JSC::JSCatchScope::create):
2389         (JSC::JSCatchScope::createStructure):
2390         * runtime/JSFunction.cpp:
2391         (JSC::JSFunction::addNameScopeIfNeeded):
2392         * runtime/JSFunctionNameScope.cpp: Added.
2393         * runtime/JSFunctionNameScope.h: Added.
2394         (JSC::JSFunctionNameScope::JSFunctionNameScope):
2395         (JSC::JSFunctionNameScope::create):
2396         (JSC::JSFunctionNameScope::createStructure):
2397         * runtime/JSGlobalObject.cpp:
2398         (JSC::JSGlobalObject::init):
2399         (JSC::JSGlobalObject::visitChildren):
2400         * runtime/JSGlobalObject.h:
2401         (JSC::JSGlobalObject::catchScopeStructure):
2402         (JSC::JSGlobalObject::functionNameScopeStructure):
2403         (JSC::JSGlobalObject::nameScopeStructure): Deleted.
2404         * runtime/JSNameScope.cpp:
2405         (JSC::JSNameScope::create):
2406         * runtime/JSNameScope.h:
2407         (JSC::JSNameScope::create):
2408         (JSC::JSNameScope::JSNameScope):
2409         (JSC::JSNameScope::createStructure): Deleted.
2410         (JSC::JSNameScope::isFunctionNameScope): Deleted.
2411         (JSC::JSNameScope::isCatchScope): Deleted.
2412         * runtime/JSObject.cpp:
2413         (JSC::JSObject::isCatchScopeObject):
2414         (JSC::JSObject::isFunctionNameScopeObject):
2415         * runtime/JSObject.h:
2416
2417 2015-02-20  Mark Lam  <mark.lam@apple.com>
2418
2419         [JSObjCClassInfo reallocateConstructorAndOrPrototype] should also reallocate super class prototype chain.
2420         <https://webkit.org/b/141809>
2421
2422         Reviewed by Geoffrey Garen.
2423
2424         A ObjC class that implement the JSExport protocol will have a JS prototype
2425         chain and constructor automatically synthesized for its JS wrapper object.
2426         However, if there are no more instances of that ObjC class reachable by a
2427         JS GC root scan, then its synthesized prototype chain and constructors may
2428         be released by the GC.  If a new instance of that ObjC class is subsequently
2429         instantiated, then [JSObjCClassInfo reallocateConstructorAndOrPrototype]
2430         should re-construct the prototype chain and constructor (if they were
2431         previously released).  However, the current implementation only
2432         re-constructs the immediate prototype, but not every other prototype
2433         object upstream in the prototype chain.
2434
2435         To fix this, we do the following:
2436         1. We no longer allocate the JSObjCClassInfo's prototype and constructor
2437            eagerly.  Hence, -initWithContext:forClass: will no longer call
2438            -allocateConstructorAndPrototypeWithSuperClassInfo:.
2439         2. Instead, we'll always access the prototype and constructor thru
2440            accessor methods.  The accessor methods will call
2441            -allocateConstructorAndPrototype: if needed.
2442         3. -allocateConstructorAndPrototype: will fetch the needed superClassInfo
2443            from the JSWrapperMap itself.  This makes it so that we no longer
2444            need to pass the superClassInfo all over.
2445         4. -allocateConstructorAndPrototype: will get the super class prototype
2446            by invoking -prototype: on the superClassInfo, thereby allowing the
2447            super class to allocate its prototype and constructor if needed and
2448            fixing the issue in this bug.
2449
2450         5. Also removed the GC warning comments, and ensured that needed JS
2451            objects are kept alive by having a local var pointing to it from the
2452            stack (which makes a GC root).
2453
2454         * API/JSWrapperMap.mm:
2455         (-[JSObjCClassInfo initWithContext:forClass:]):
2456         (-[JSObjCClassInfo allocateConstructorAndPrototype]):
2457         (-[JSObjCClassInfo wrapperForObject:]):
2458         (-[JSObjCClassInfo constructor]):
2459         (-[JSObjCClassInfo prototype]):
2460         (-[JSWrapperMap classInfoForClass:]):
2461         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Deleted.
2462         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Deleted.
2463         (-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Deleted.
2464         * API/tests/Regress141809.h: Added.
2465         * API/tests/Regress141809.mm: Added.
2466         (-[TestClassB name]):
2467         (-[TestClassC name]):
2468         (runRegress141809):
2469         * API/tests/testapi.mm:
2470         * JavaScriptCore.xcodeproj/project.pbxproj:
2471
2472 2015-02-20  Alexey Proskuryakov  <ap@apple.com>
2473
2474         Remove svn:keywords property.
2475
2476         As far as I can tell, the property had no effect on any of these files, but also,
2477         when it has effect it's likely harmful.
2478
2479         * builtins/ArrayConstructor.js: Removed property svn:keywords.
2480
2481 2015-02-20  Michael Saboff  <msaboff@apple.com>
2482
2483         DFG JIT needs to check for stack overflow at the start of Program and Eval execution
2484         https://bugs.webkit.org/show_bug.cgi?id=141676
2485
2486         Reviewed by Filip Pizlo.
2487
2488         Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes.
2489         To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const
2490         a options in runtime/Options.h.  The test script, run-jsc-stress-tests, sets that option
2491         to a huge value when running with the "Eager" options.  This allows the updated test to 
2492         reliably exercise the code in questions.
2493
2494         * dfg/DFGJITCompiler.cpp:
2495         (JSC::DFG::JITCompiler::compile):
2496         Added stack check.
2497
2498         * bytecode/EvalCodeCache.h:
2499         (JSC::EvalCodeCache::tryGet):
2500         (JSC::EvalCodeCache::getSlow):
2501         * runtime/Options.h:
2502         Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength
2503         so that it can be configured when running the related test.
2504
2505 2015-02-20  Eric Carlson  <eric.carlson@apple.com>
2506
2507         [iOS] cleanup AirPlay code
2508         https://bugs.webkit.org/show_bug.cgi?id=141811
2509
2510         Reviewed by Jer Noble.
2511
2512         * Configurations/FeatureDefines.xcconfig: IOS_AIRPLAY -> WIRELESS_PLAYBACK_TARGET.
2513
2514 2015-02-19  Dean Jackson  <dino@apple.com>
2515
2516         ES6: Implement Array.from()
2517         https://bugs.webkit.org/show_bug.cgi?id=141054
2518         <rdar://problem/19654521>
2519
2520         Reviewed by Filip Pizlo.
2521
2522         Implement the Array.from() ES6 method
2523         as defined in Section 22.1.2.1 of the specification.
2524
2525         Given that we can't rely on the built-in
2526         global functions or objects to be untainted,
2527         I had to expose a few of them directly to
2528         the function via private names. In particular:
2529         - Math.floor -> @floor
2530         - Math.abs -> @abs
2531         - Number -> @Number
2532         - Array -> @Array
2533         - isFinite -> @isFinite
2534
2535         * builtins/ArrayConstructor.js: Added.
2536         (from): Implementation of Array.from in JavaScript.
2537         * runtime/ArrayConstructor.cpp: Add "from" to the lookup
2538         table for the constructor object.
2539         * runtime/CommonIdentifiers.h: Add the private versions
2540         of the identifiers listed above.
2541         * runtime/JSGlobalObject.cpp: Add the implementations of
2542         those identifiers to the global object (using their
2543         private names).
2544         (JSC::JSGlobalObject::init):
2545         * runtime/JSGlobalObjectFunctions.cpp:
2546         (JSC::globalPrivateFuncAbs): Implementation of the abs function.
2547         (JSC::globalPrivateFuncFloor): Implementation of the floor function.
2548         * runtime/JSGlobalObjectFunctions.h:
2549
2550 2015-02-19  Benjamin Poulain  <bpoulain@apple.com>
2551
2552         Refine the FTL part of ArithPow
2553         https://bugs.webkit.org/show_bug.cgi?id=141792
2554
2555         Reviewed by Filip Pizlo.
2556
2557         This patch refines the FTL lowering of ArithPow. This was left out
2558         of the original patch to keep it simpler.
2559
2560         * ftl/FTLLowerDFGToLLVM.cpp:
2561         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
2562         Two improvements here:
2563         1) Do not generate the NaN check unless we know the exponent might be a NaN.
2564         2) Use one BasicBlock per check with the appropriate weight. Now that we have
2565            one branch per test, move the Infinity check before the check for 1 since
2566            it is the less common case.
2567
2568         * tests/stress/math-pow-becomes-custom-function.js: Added.
2569         Test for changing the Math.pow() function after it has been optimized.
2570
2571         * tests/stress/math-pow-nan-behaviors.js:
2572         The previous tests were only going as far as the DFGAbstractInterpreter
2573         were the operations were replaced by the equivalent constant.
2574
2575         I duplicated the test functions to also test the dynamic behavior of DFG
2576         and FTL.
2577
2578         * tests/stress/math-pow-with-constants.js:
2579         Add cases covering exponent constants. LLVM removes many value
2580         checks for those.
2581
2582         * tests/stress/math-pow-with-never-NaN-exponent.js: Added.
2583         Test for the new optimization removing the NaN check.
2584
2585 2015-02-19  Csaba Osztrogonác  <ossy@webkit.org>
2586
2587         REGRESSION(r180279): It broke 20 tests on ARM Linux
2588         https://bugs.webkit.org/show_bug.cgi?id=141771
2589
2590         Reviewed by Filip Pizlo.
2591
2592         * dfg/DFGSpeculativeJIT.h:
2593         (JSC::DFG::SpeculativeJIT::callOperation): Align 64-bit values to respect ARM EABI.
2594
2595 2015-02-18  Benjamin Poulain  <bpoulain@apple.com>
2596
2597         Remove BytecodeGenerator's numberMap, it is dead code
2598         https://bugs.webkit.org/show_bug.cgi?id=141779
2599
2600         Reviewed by Filip Pizlo.
2601
2602         * bytecompiler/BytecodeGenerator.cpp:
2603         (JSC::BytecodeGenerator::emitLoad): Deleted.
2604         * bytecompiler/BytecodeGenerator.h:
2605         The JSValueMap seems better in every way.
2606
2607         The emitLoad() taking a double was the only way to use numberMap
2608         and that code has no caller.
2609
2610 2015-02-18  Michael Saboff  <msaboff@apple.com>
2611
2612         Rollout r180247 & r180249 from trunk
2613         https://bugs.webkit.org/show_bug.cgi?id=141773
2614
2615         Reviewed by Filip Pizlo.
2616
2617         Theses changes makes sense to fix the crash reported in https://bugs.webkit.org/show_bug.cgi?id=141730
2618         only for branches.  The change to fail the FTL compile but continue running is not comprehensive
2619         enough for general use on trunk.
2620
2621         * dfg/DFGPlan.cpp:
2622         (JSC::DFG::Plan::compileInThreadImpl):
2623         * ftl/FTLLowerDFGToLLVM.cpp:
2624         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
2625         (JSC::FTL::LowerDFGToLLVM::lower):
2626         (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
2627         (JSC::FTL::LowerDFGToLLVM::compileNode):
2628         (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
2629         (JSC::FTL::LowerDFGToLLVM::compilePhi):
2630         (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
2631         (JSC::FTL::LowerDFGToLLVM::compileValueRep):
2632         (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
2633         (JSC::FTL::LowerDFGToLLVM::compilePutLocal):
2634         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
2635         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
2636         (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
2637         (JSC::FTL::LowerDFGToLLVM::compileArithMod):
2638         (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
2639         (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
2640         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2641         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
2642         (JSC::FTL::LowerDFGToLLVM::compileGetById):
2643         (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
2644         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
2645         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2646         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
2647         (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
2648         (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
2649         (JSC::FTL::LowerDFGToLLVM::compileNewArray):
2650         (JSC::FTL::LowerDFGToLLVM::compileToString):
2651         (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
2652         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
2653         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
2654         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
2655         (JSC::FTL::LowerDFGToLLVM::compare):
2656         (JSC::FTL::LowerDFGToLLVM::boolify):
2657         (JSC::FTL::LowerDFGToLLVM::opposite):
2658         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
2659         (JSC::FTL::LowerDFGToLLVM::speculate):
2660         (JSC::FTL::LowerDFGToLLVM::isArrayType):
2661         (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
2662         (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
2663         (JSC::FTL::LowerDFGToLLVM::setInt52):
2664         (JSC::FTL::lowerDFGToLLVM):
2665         (JSC::FTL::LowerDFGToLLVM::loweringFailed): Deleted.
2666         * ftl/FTLLowerDFGToLLVM.h:
2667
2668 2015-02-18  Filip Pizlo  <fpizlo@apple.com>
2669
2670         DFG should really support varargs
2671         https://bugs.webkit.org/show_bug.cgi?id=141332
2672
2673         Reviewed by Oliver Hunt.
2674         
2675         This adds comprehensive vararg call support to the DFG and FTL compilers. Previously, if a
2676         function had a varargs call, then it could only be compiled if that varargs call was just
2677         forwarding arguments and we were inlining the function rather than compiling it directly. Also,
2678         only varargs calls were dealt with; varargs constructs were not.
2679         
2680         This lifts all of those restrictions. Every varargs call or construct can now be compiled by both
2681         the DFG and the FTL. Those calls can also be inlined, too - provided that profiling gives us a
2682         sensible bound on arguments list length. When we inline a varargs call, the act of loading the
2683         varargs is now made explicit in IR. I believe that we have enough IR machinery in place that we
2684         would be able to do the arguments forwarding optimization as an IR transformation. This patch
2685         doesn't implement that yet, and keeps the old bytecode-based varargs argument forwarding
2686         optimization for now.
2687         
2688         There are three major IR features introduced in this patch:
2689         
2690         CallVarargs/ConstructVarargs: these are like Call/Construct except that they take an arguments
2691         array rather than a list of arguments. Currently, they splat this arguments array onto the stack
2692         using the same basic technique as the baseline JIT has always done. Except, these nodes indicate
2693         that we are not interested in doing the non-escaping "arguments" optimization.
2694         
2695         CallForwardVarargs: this is a form of CallVarargs that just does the non-escaping "arguments"
2696         optimization, aka forwarding arguments. It's somewhat lazy that this doesn't include
2697         ConstructForwardVarargs, but the reason is that once we eliminate the lazy tear-off for
2698         arguments, this whole thing will have to be tweaked - and for now forwarding on construct is just
2699         not important in benchmarks. ConstructVarargs will still do forwarding, just not inlined.
2700         
2701         LoadVarargs: loads all elements out of an array onto the stack in a manner suitable for a varargs
2702         call. This is used only when a varargs call (or construct) was inlined. The bytecode parser will
2703         make room on the stack for the arguments, and will use LoadVarars to put those arguments into
2704         place.
2705         
2706         In the future, we can consider adding strength reductions like:
2707         
2708         - If CallVarargs/ConstructVarargs see an array of known size with known elements, turn them into
2709           Call/Construct.
2710         
2711         - If CallVarargs/ConstructVarargs are passed an unmodified, unescaped Arguments object, then
2712           turn them into CallForwardVarargs/ConstructForwardVarargs.
2713         
2714         - If LoadVarargs sees an array of known size, then turn it into a sequence of GetByVals and
2715           PutLocals.
2716         
2717         - If LoadVarargs sees an unmodified, unescaped Arguments object, then turn it into something like
2718           LoadForwardVarargs.
2719         
2720         - If CallVarargs/ConstructVarargs/LoadVarargs see the result of a splice (or other Array
2721           prototype function), then do the splice and varargs loading in one go (maybe via a new node
2722           type).
2723
2724         * CMakeLists.txt:
2725         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2726         * JavaScriptCore.xcodeproj/project.pbxproj:
2727         * assembler/MacroAssembler.h:
2728         (JSC::MacroAssembler::rshiftPtr):
2729         (JSC::MacroAssembler::urshiftPtr):
2730         * assembler/MacroAssemblerARM64.h:
2731         (JSC::MacroAssemblerARM64::urshift64):
2732         * assembler/MacroAssemblerX86_64.h:
2733         (JSC::MacroAssemblerX86_64::urshift64):
2734         * assembler/X86Assembler.h:
2735         (JSC::X86Assembler::shrq_i8r):
2736         * bytecode/CallLinkInfo.h:
2737         (JSC::CallLinkInfo::CallLinkInfo):
2738         * bytecode/CallLinkStatus.cpp:
2739         (JSC::CallLinkStatus::computeFor):
2740         (JSC::CallLinkStatus::setProvenConstantCallee):
2741         (JSC::CallLinkStatus::dump):
2742         * bytecode/CallLinkStatus.h:
2743         (JSC::CallLinkStatus::maxNumArguments):
2744         (JSC::CallLinkStatus::setIsProved): Deleted.
2745         * bytecode/CodeOrigin.cpp:
2746         (WTF::printInternal):
2747         * bytecode/CodeOrigin.h:
2748         (JSC::InlineCallFrame::varargsKindFor):
2749         (JSC::InlineCallFrame::specializationKindFor):
2750         (JSC::InlineCallFrame::isVarargs):
2751         (JSC::InlineCallFrame::isNormalCall): Deleted.
2752         * bytecode/ExitKind.cpp:
2753         (JSC::exitKindToString):
2754         * bytecode/ExitKind.h:
2755         * bytecode/ValueRecovery.cpp:
2756         (JSC::ValueRecovery::dumpInContext):
2757         * dfg/DFGAbstractInterpreterInlines.h:
2758         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2759         * dfg/DFGArgumentsSimplificationPhase.cpp:
2760         (JSC::DFG::ArgumentsSimplificationPhase::run):
2761         * dfg/DFGByteCodeParser.cpp:
2762         (JSC::DFG::ByteCodeParser::flush):
2763         (JSC::DFG::ByteCodeParser::addCall):
2764         (JSC::DFG::ByteCodeParser::handleCall):
2765         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2766         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
2767         (JSC::DFG::ByteCodeParser::inliningCost):
2768         (JSC::DFG::ByteCodeParser::inlineCall):
2769         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2770         (JSC::DFG::ByteCodeParser::handleInlining):
2771         (JSC::DFG::ByteCodeParser::handleMinMax):
2772         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2773         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
2774         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2775         (JSC::DFG::ByteCodeParser::parseBlock):
2776         (JSC::DFG::ByteCodeParser::removeLastNodeFromGraph): Deleted.
2777         (JSC::DFG::ByteCodeParser::undoFunctionChecks): Deleted.
2778         * dfg/DFGCapabilities.cpp:
2779         (JSC::DFG::capabilityLevel):
2780         * dfg/DFGCapabilities.h:
2781         (JSC::DFG::functionCapabilityLevel):
2782         (JSC::DFG::mightCompileFunctionFor):
2783         * dfg/DFGClobberize.h:
2784         (JSC::DFG::clobberize):
2785         * dfg/DFGCommon.cpp:
2786         (WTF::printInternal):
2787         * dfg/DFGCommon.h:
2788         (JSC::DFG::canInline):
2789         (JSC::DFG::leastUpperBound):
2790         * dfg/DFGDoesGC.cpp:
2791         (JSC::DFG::doesGC):
2792         * dfg/DFGFixupPhase.cpp:
2793         (JSC::DFG::FixupPhase::fixupNode):
2794         * dfg/DFGGraph.cpp:
2795         (JSC::DFG::Graph::dump):
2796         (JSC::DFG::Graph::dumpBlockHeader):
2797         (JSC::DFG::Graph::isLiveInBytecode):
2798         (JSC::DFG::Graph::valueProfileFor):
2799         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2800         * dfg/DFGGraph.h:
2801         (JSC::DFG::Graph::valueProfileFor): Deleted.
2802         (JSC::DFG::Graph::methodOfGettingAValueProfileFor): Deleted.
2803         * dfg/DFGJITCompiler.cpp:
2804         (JSC::DFG::JITCompiler::compileExceptionHandlers):
2805         (JSC::DFG::JITCompiler::link):
2806         * dfg/DFGMayExit.cpp:
2807         (JSC::DFG::mayExit):
2808         * dfg/DFGNode.h:
2809         (JSC::DFG::Node::hasCallVarargsData):
2810         (JSC::DFG::Node::callVarargsData):
2811         (JSC::DFG::Node::hasLoadVarargsData):
2812         (JSC::DFG::Node::loadVarargsData):
2813         (JSC::DFG::Node::hasHeapPrediction):
2814         * dfg/DFGNodeType.h:
2815         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2816         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
2817         * dfg/DFGOSRExitCompilerCommon.cpp:
2818         (JSC::DFG::reifyInlinedCallFrames):
2819         * dfg/DFGOperations.cpp:
2820         * dfg/DFGOperations.h:
2821         * dfg/DFGPlan.cpp:
2822         (JSC::DFG::dumpAndVerifyGraph):
2823         (JSC::DFG::Plan::compileInThreadImpl):
2824         * dfg/DFGPreciseLocalClobberize.h:
2825         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2826         (JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop):
2827         * dfg/DFGPredictionPropagationPhase.cpp:
2828         (JSC::DFG::PredictionPropagationPhase::propagate):
2829         * dfg/DFGSSAConversionPhase.cpp:
2830         * dfg/DFGSafeToExecute.h:
2831         (JSC::DFG::safeToExecute):
2832         * dfg/DFGSpeculativeJIT.h:
2833         (JSC::DFG::SpeculativeJIT::isFlushed):
2834         (JSC::DFG::SpeculativeJIT::callOperation):
2835         * dfg/DFGSpeculativeJIT32_64.cpp:
2836         (JSC::DFG::SpeculativeJIT::emitCall):
2837         (JSC::DFG::SpeculativeJIT::compile):
2838         * dfg/DFGSpeculativeJIT64.cpp:
2839         (JSC::DFG::SpeculativeJIT::emitCall):
2840         (JSC::DFG::SpeculativeJIT::compile):
2841         * dfg/DFGStackLayoutPhase.cpp:
2842         (JSC::DFG::StackLayoutPhase::run):
2843         (JSC::DFG::StackLayoutPhase::assign):
2844         * dfg/DFGStrengthReductionPhase.cpp:
2845         (JSC::DFG::StrengthReductionPhase::handleNode):
2846         * dfg/DFGTypeCheckHoistingPhase.cpp:
2847         (JSC::DFG::TypeCheckHoistingPhase::run):
2848         * dfg/DFGValidate.cpp:
2849         (JSC::DFG::Validate::validateCPS):
2850         * ftl/FTLAbbreviations.h:
2851         (JSC::FTL::functionType):
2852         (JSC::FTL::buildCall):
2853         * ftl/FTLCapabilities.cpp:
2854         (JSC::FTL::canCompile):
2855         * ftl/FTLCompile.cpp:
2856         (JSC::FTL::mmAllocateDataSection):
2857         * ftl/FTLInlineCacheSize.cpp:
2858         (JSC::FTL::sizeOfCall):
2859         (JSC::FTL::sizeOfCallVarargs):
2860         (JSC::FTL::sizeOfCallForwardVarargs):
2861         (JSC::FTL::sizeOfConstructVarargs):
2862         (JSC::FTL::sizeOfIn):
2863         (JSC::FTL::sizeOfICFor):
2864         (JSC::FTL::sizeOfCheckIn): Deleted.
2865         * ftl/FTLInlineCacheSize.h:
2866         * ftl/FTLIntrinsicRepository.h:
2867         * ftl/FTLJSCall.cpp:
2868         (JSC::FTL::JSCall::JSCall):
2869         * ftl/FTLJSCallBase.cpp:
2870         * ftl/FTLJSCallBase.h:
2871         * ftl/FTLJSCallVarargs.cpp: Added.
2872         (JSC::FTL::JSCallVarargs::JSCallVarargs):
2873         (JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
2874         (JSC::FTL::JSCallVarargs::emit):
2875         (JSC::FTL::JSCallVarargs::link):
2876         * ftl/FTLJSCallVarargs.h: Added.
2877         (JSC::FTL::JSCallVarargs::node):
2878         (JSC::FTL::JSCallVarargs::stackmapID):
2879         (JSC::FTL::JSCallVarargs::operator<):
2880         * ftl/FTLLowerDFGToLLVM.cpp:
2881         (JSC::FTL::LowerDFGToLLVM::lower):
2882         (JSC::FTL::LowerDFGToLLVM::compileNode):
2883         (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength):
2884         (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
2885         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
2886         (JSC::FTL::LowerDFGToLLVM::compileLoadVarargs):
2887         (JSC::FTL::LowerDFGToLLVM::compileIn):
2888         (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
2889         (JSC::FTL::LowerDFGToLLVM::vmCall):
2890         (JSC::FTL::LowerDFGToLLVM::vmCallNoExceptions):
2891         (JSC::FTL::LowerDFGToLLVM::callCheck):
2892         * ftl/FTLOutput.h:
2893         (JSC::FTL::Output::call):
2894         * ftl/FTLState.cpp:
2895         (JSC::FTL::State::State):
2896         * ftl/FTLState.h:
2897         * interpreter/Interpreter.cpp:
2898         (JSC::sizeOfVarargs):
2899         (JSC::sizeFrameForVarargs):
2900         * interpreter/Interpreter.h:
2901         * interpreter/StackVisitor.cpp:
2902         (JSC::StackVisitor::readInlinedFrame):
2903         * jit/AssemblyHelpers.cpp:
2904         (JSC::AssemblyHelpers::emitExceptionCheck):
2905         * jit/AssemblyHelpers.h:
2906         (JSC::AssemblyHelpers::addressFor):
2907         (JSC::AssemblyHelpers::calleeFrameSlot):
2908         (JSC::AssemblyHelpers::calleeArgumentSlot):
2909         (JSC::AssemblyHelpers::calleeFrameTagSlot):
2910         (JSC::AssemblyHelpers::calleeFramePayloadSlot):
2911         (JSC::AssemblyHelpers::calleeArgumentTagSlot):
2912         (JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
2913         (JSC::AssemblyHelpers::calleeFrameCallerFrame):
2914         (JSC::AssemblyHelpers::selectScratchGPR):
2915         * jit/CCallHelpers.h:
2916         (JSC::CCallHelpers::setupArgumentsWithExecState):
2917         * jit/GPRInfo.h:
2918         * jit/JIT.cpp:
2919         (JSC::JIT::privateCompile):
2920         * jit/JIT.h:
2921         * jit/JITCall.cpp:
2922         (JSC::JIT::compileSetupVarargsFrame):
2923         (JSC::JIT::compileOpCall):
2924         * jit/JITCall32_64.cpp:
2925         (JSC::JIT::compileSetupVarargsFrame):
2926         (JSC::JIT::compileOpCall):
2927         * jit/JITOperations.h:
2928         * jit/SetupVarargsFrame.cpp:
2929         (JSC::emitSetupVarargsFrameFastCase):
2930         * jit/SetupVarargsFrame.h:
2931         * runtime/Arguments.h:
2932         (JSC::Arguments::create):
2933         (JSC::Arguments::registerArraySizeInBytes):
2934         (JSC::Arguments::finishCreation):
2935         * runtime/Options.h:
2936         * tests/stress/construct-varargs-inline-smaller-Foo.js: Added.
2937         (Foo):
2938         (bar):
2939         (checkEqual):
2940         (test):
2941         * tests/stress/construct-varargs-inline.js: Added.
2942         (Foo):
2943         (bar):
2944         (checkEqual):
2945         (test):
2946         * tests/stress/construct-varargs-no-inline.js: Added.
2947         (Foo):
2948         (bar):
2949         (checkEqual):
2950         (test):
2951         * tests/stress/get-argument-by-val-in-inlined-varargs-call-out-of-bounds.js: Added.
2952         (foo):
2953         (bar):
2954         * tests/stress/get-argument-by-val-safe-in-inlined-varargs-call-out-of-bounds.js: Added.
2955         (foo):
2956         (bar):
2957         * tests/stress/get-my-argument-by-val-creates-arguments.js: Added.
2958         (blah):
2959         (foo):
2960         (bar):
2961         (checkEqual):
2962         (test):
2963         * tests/stress/load-varargs-then-inlined-call-exit-in-foo.js: Added.
2964         (foo):
2965         (bar):
2966         (checkEqual):
2967         * tests/stress/load-varargs-then-inlined-call-inlined.js: Added.
2968         (foo):
2969         (bar):
2970         (baz):
2971         (checkEqual):
2972         (test):
2973         * tests/stress/load-varargs-then-inlined-call.js: Added.
2974         (foo):
2975         (bar):
2976         (checkEqual):
2977         (test):
2978
2979 2015-02-17  Michael Saboff  <msaboff@apple.com>
2980
2981         Unreviewed, Restoring the C LOOP insta-crash fix in r180184.
2982
2983         Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
2984         After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
2985
2986         * llint/LowLevelInterpreter.asm: Fixed a typo.
2987
2988 2015-02-18  Csaba Osztrogonác  <ossy@webkit.org>
2989
2990         URTBF after r180258 to fix Windows build.
2991
2992         * runtime/MathCommon.cpp:
2993         (JSC::mathPowInternal):
2994
2995 2015-02-18  Joseph Pecoraro  <pecoraro@apple.com>
2996
2997         REGRESSION(r180235): It broke the !ENABLE(PROMISES) build
2998         https://bugs.webkit.org/show_bug.cgi?id=141746
2999
3000         Unreviewed build fix.
3001
3002         * inspector/JSInjectedScriptHost.cpp:
3003         (Inspector::JSInjectedScriptHost::getInternalProperties):
3004         Wrap JSPromise related code in ENABLE(PROMISES) guard.
3005
3006 2015-02-18  Benjamin Poulain  <benjamin@webkit.org>
3007
3008         Fix the C-Loop LLInt build
3009         https://bugs.webkit.org/show_bug.cgi?id=141618
3010
3011         Reviewed by Filip Pizlo.
3012
3013         I broke C-Loop when moving the common code of pow()
3014         to JITOperations because that file is #ifdefed out
3015         when the JITs are disabled.
3016
3017         It would be weird to move it back to MathObject since
3018         the function needs to know about the calling conventions.
3019
3020         To avoid making a mess, I just gave the function its own file
3021         that is used by both the runtime and the JIT.
3022
3023         * CMakeLists.txt:
3024         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3025         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3026         * JavaScriptCore.xcodeproj/project.pbxproj:
3027         * dfg/DFGAbstractInterpreterInlines.h:
3028         * jit/JITOperations.cpp:
3029         * jit/JITOperations.h:
3030         * runtime/MathCommon.cpp: Added.
3031         (JSC::fdlibmScalbn):
3032         (JSC::fdlibmPow):
3033         (JSC::isDenormal):
3034         (JSC::isEdgeCase):
3035         (JSC::mathPowInternal):
3036         (JSC::operationMathPow):
3037         * runtime/MathCommon.h: Added.
3038         * runtime/MathObject.cpp:
3039
3040 2015-02-17  Benjamin Poulain  <bpoulain@apple.com>
3041
3042         Clean up OSRExit's considerAddingAsFrequentExitSite()
3043         https://bugs.webkit.org/show_bug.cgi?id=141690
3044
3045         Reviewed by Anders Carlsson.
3046
3047         Looks like some code was removed from CodeBlock::tallyFrequentExitSites()
3048         and the OSRExit were left untouched.
3049
3050         This patch cleans up the two loops and remove the boolean return
3051         on considerAddingAsFrequentExitSite().
3052
3053         * bytecode/CodeBlock.cpp:
3054         (JSC::CodeBlock::tallyFrequentExitSites):
3055         * dfg/DFGOSRExit.h:
3056         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
3057         * dfg/DFGOSRExitBase.cpp:
3058         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
3059         * dfg/DFGOSRExitBase.h:
3060         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
3061         * ftl/FTLOSRExit.h:
3062         (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
3063
3064 2015-02-17  Alexey Proskuryakov  <ap@apple.com>
3065
3066         Debug build fix after r180247.
3067
3068         * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::loweringFailed):
3069
3070 2015-02-17  Commit Queue  <commit-queue@webkit.org>
3071
3072         Unreviewed, rolling out r180184.
3073         https://bugs.webkit.org/show_bug.cgi?id=141733
3074
3075         Caused infinite recursion on js/function-apply-aliased.html
3076         (Requested by ap_ on #webkit).
3077
3078         Reverted changeset:
3079
3080         "REGRESSION(r180060): C Loop crashes"
3081         https://bugs.webkit.org/show_bug.cgi?id=141671
3082         http://trac.webkit.org/changeset/180184
3083
3084 2015-02-17  Michael Saboff  <msaboff@apple.com>
3085
3086         CrashTracer: DFG_CRASH beneath JSC::FTL::LowerDFGToLLVM::compileNode
3087         https://bugs.webkit.org/show_bug.cgi?id=141730
3088
3089         Reviewed by Geoffrey Garen.
3090
3091         Added a new failure handler, loweringFailed(), to LowerDFGToLLVM that reports failures
3092         while processing DFG lowering.  For debug builds, the failures are logged identical
3093         to the way the DFG_CRASH() reports them.  For release builds, the failures are reported
3094         and that FTL compilation is terminated, but the process is allowed to continue.
3095         Wrapped calls to loweringFailed() in a macro LOWERING_FAILED so the function and
3096         line number are reported at the point of the inconsistancy.
3097
3098         Converted instances of DFG_CRASH to LOWERING_FAILED.
3099
3100         * dfg/DFGPlan.cpp:
3101         (JSC::DFG::Plan::compileInThreadImpl): Added lowerDFGToLLVM() failure check that
3102         will fail the FTL compile.
3103
3104         * ftl/FTLLowerDFGToLLVM.cpp:
3105         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
3106         Added new member variable, m_loweringSucceeded, to stop compilation on the first
3107         reported failure.
3108
3109         * ftl/FTLLowerDFGToLLVM.cpp:
3110         (JSC::FTL::LowerDFGToLLVM::lower):
3111         * ftl/FTLLowerDFGToLLVM.h:
3112         Added check for compilation failures and now report those failures via a boolean
3113         return value.
3114
3115         * ftl/FTLLowerDFGToLLVM.cpp:
3116         (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
3117         (JSC::FTL::LowerDFGToLLVM::compileNode):
3118         (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
3119         (JSC::FTL::LowerDFGToLLVM::compilePhi):
3120         (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
3121         (JSC::FTL::LowerDFGToLLVM::compileValueRep):
3122         (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
3123         (JSC::FTL::LowerDFGToLLVM::compilePutLocal):
3124         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
3125         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
3126         (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
3127         (JSC::FTL::LowerDFGToLLVM::compileArithMod):
3128         (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
3129         (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
3130         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
3131         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
3132         (JSC::FTL::LowerDFGToLLVM::compileGetById):
3133         (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
3134         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
3135         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
3136         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
3137         (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
3138         (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
3139         (JSC::FTL::LowerDFGToLLVM::compileNewArray):
3140         (JSC::FTL::LowerDFGToLLVM::compileToString):
3141         (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
3142         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
3143         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
3144         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
3145         (JSC::FTL::LowerDFGToLLVM::compare):
3146         (JSC::FTL::LowerDFGToLLVM::boolify):
3147         (JSC::FTL::LowerDFGToLLVM::opposite):
3148         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
3149         (JSC::FTL::LowerDFGToLLVM::speculate):
3150         (JSC::FTL::LowerDFGToLLVM::isArrayType):
3151         (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
3152         (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
3153         (JSC::FTL::LowerDFGToLLVM::setInt52):
3154         Changed DFG_CRASH() to LOWERING_FAILED().  Updated related control flow as appropriate.
3155
3156         (JSC::FTL::LowerDFGToLLVM::loweringFailed): New error reporting member function.
3157
3158 2015-02-17  Filip Pizlo  <fpizlo@apple.com>
3159
3160         StackLayoutPhase should use CodeBlock::usesArguments rather than FunctionExecutable::usesArguments
3161         https://bugs.webkit.org/show_bug.cgi?id=141721
3162         rdar://problem/17198633
3163
3164         Reviewed by Michael Saboff.
3165         
3166         I've seen cases where the two are out of sync.  We know we can trust the CodeBlock::usesArguments because
3167         we use it everywhere else.
3168         
3169         No test because I could never reproduce the crash.
3170
3171         * dfg/DFGGraph.h:
3172         (JSC::DFG::Graph::usesArguments):
3173         * dfg/DFGStackLayoutPhase.cpp:
3174         (JSC::DFG::StackLayoutPhase::run):
3175
3176 2015-02-16  Joseph Pecoraro  <pecoraro@apple.com>
3177
3178         Web Inspector: Improved Console Support for Bound Functions
3179         https://bugs.webkit.org/show_bug.cgi?id=141635
3180
3181         Reviewed by Timothy Hatcher.
3182
3183         * inspector/JSInjectedScriptHost.cpp:
3184         (Inspector::JSInjectedScriptHost::getInternalProperties):
3185         Expose internal properties of a JSBoundFunction.
3186
3187 2015-02-16  Joseph Pecoraro  <pecoraro@apple.com>
3188
3189         Web Inspector: ES6: Improved Console Support for Promise Objects
3190         https://bugs.webkit.org/show_bug.cgi?id=141634
3191
3192         Reviewed by Timothy Hatcher.
3193
3194         * inspector/InjectedScript.cpp:
3195         (Inspector::InjectedScript::getInternalProperties):
3196         * inspector/InjectedScriptSource.js:
3197         Include internal properties in previews. Share code
3198         with normal internal property handling.
3199
3200         * inspector/JSInjectedScriptHost.cpp:
3201         (Inspector::constructInternalProperty):
3202         (Inspector::JSInjectedScriptHost::getInternalProperties):
3203         Provide internal state of Promises.
3204
3205         * inspector/protocol/Runtime.json:
3206         Provide an optional field to distinguish if a PropertyPreview
3207         is for an Internal property or not.
3208
3209 2015-02-17  Filip Pizlo  <fpizlo@apple.com>
3210
3211         Throwing from an FTL call IC slow path may result in tag registers being clobbered on 64-bit CPUs
3212         https://bugs.webkit.org/show_bug.cgi?id=141717
3213         rdar://problem/19863382
3214
3215         Reviewed by Geoffrey Garen.
3216         
3217         The best solution is to ensure that the engine catching an exception restores tag registers.
3218         
3219         Each of these new test cases reliably crashed prior to this patch and they don't crash at all now.
3220
3221         * jit/JITOpcodes.cpp:
3222         (JSC::JIT::emit_op_catch):
3223         * llint/LowLevelInterpreter.asm:
3224         * llint/LowLevelInterpreter64.asm:
3225         * tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: Added.
3226         * tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: Added.
3227         * tests/stress/throw-from-ftl-call-ic-slow-path.js: Added.
3228
3229 2015-02-17  Csaba Osztrogonác  <ossy@webkit.org>
3230
3231         [ARM] Add the necessary setupArgumentsWithExecState after bug141332
3232         https://bugs.webkit.org/show_bug.cgi?id=141714
3233
3234         Reviewed by Michael Saboff.
3235
3236         * jit/CCallHelpers.h:
3237         (JSC::CCallHelpers::setupArgumentsWithExecState):
3238
3239 2015-02-15  Sam Weinig  <sam@webkit.org>
3240
3241         Add experimental <attachment> element support
3242         https://bugs.webkit.org/show_bug.cgi?id=141626
3243
3244         Reviewed by Tim Horton.
3245
3246         * Configurations/FeatureDefines.xcconfig:
3247
3248 2015-02-16  Michael Saboff  <msaboff@apple.com>
3249
3250         REGRESSION(r180060): C Loop crashes
3251         https://bugs.webkit.org/show_bug.cgi?id=141671
3252
3253         Reviewed by Geoffrey Garen.
3254
3255         Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
3256         After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
3257         Fixed the processing of an out of stack exception in llint_stack_check to not get the caller's
3258         frame.  This isn't needed, since this helper is only called to check the stack on entry.  Any
3259         exception will be handled by a call ancestor.
3260
3261         * llint/LLIntSlowPaths.cpp:
3262         (JSC::LLInt::llint_stack_check): Changed to use the current frame for processing an exception.
3263         * llint/LowLevelInterpreter.asm: Fixed a typo.
3264
3265 2015-02-16  Joseph Pecoraro  <pecoraro@apple.com>
3266
3267         Web Inspector: Scope details sidebar should label objects with constructor names
3268         https://bugs.webkit.org/show_bug.cgi?id=139449
3269
3270         Reviewed by Timothy Hatcher.
3271
3272         * inspector/JSInjectedScriptHost.cpp:
3273         (Inspector::JSInjectedScriptHost::internalConstructorName):
3274         * runtime/Structure.cpp:
3275         (JSC::Structure::toStructureShape):
3276         Share calculatedClassName.
3277
3278         * runtime/JSObject.h:        
3279         * runtime/JSObject.cpp:
3280         (JSC::JSObject::calculatedClassName):
3281         Elaborate on a way to get an Object's class name.
3282
3283 2015-02-16  Filip Pizlo  <fpizlo@apple.com>
3284
3285         DFG SSA should use GetLocal for arguments, and the GetArgument node type should be removed
3286         https://bugs.webkit.org/show_bug.cgi?id=141623
3287
3288         Reviewed by Oliver Hunt.
3289         
3290         During development of https://bugs.webkit.org/show_bug.cgi?id=141332, I realized that I
3291         needed to use GetArgument for loading something that has magically already appeared on the
3292         stack, so currently trunk sort of allows this. But then I realized three things:
3293         
3294         - A GetArgument with a non-JSValue flush format means speculating that the value on the
3295           stack obeys that format, rather than just assuming that that it already has that format.
3296           In bug 141332, I want it to assume rather than speculate. That also happens to be more
3297           intuitive; I don't think I was wrong to expect that.
3298         
3299         - The node I really want is GetLocal. I'm just getting the value of the local and I don't
3300           want to do anything else.
3301         
3302         - Maybe it would be easier if we just used GetLocal for all of the cases where we currently
3303           use GetArgument.
3304         
3305         This changes the FTL to do argument speculations in the prologue just like the DFG does.
3306         This brings some consistency to our system, and allows us to get rid of the GetArgument
3307         node. The speculations that the FTL must do are now made explicit in the m_argumentFormats
3308         vector in DFG::Graph. This has natural DCE behavior: even if all uses of the argument are
3309         dead we will still speculate. We already have safeguards to ensure we only speculate if
3310         there are uses that benefit from speculation (which is a much more conservative criterion
3311         than DCE).
3312         
3313         * dfg/DFGAbstractInterpreterInlines.h:
3314         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3315         * dfg/DFGClobberize.h:
3316         (JSC::DFG::clobberize):
3317         * dfg/DFGDCEPhase.cpp:
3318         (JSC::DFG::DCEPhase::run):
3319         * dfg/DFGDoesGC.cpp:
3320         (JSC::DFG::doesGC):
3321         * dfg/DFGFixupPhase.cpp:
3322         (JSC::DFG::FixupPhase::fixupNode):
3323         * dfg/DFGFlushFormat.h:
3324         (JSC::DFG::typeFilterFor):
3325         * dfg/DFGGraph.cpp:
3326         (JSC::DFG::Graph::dump):
3327         * dfg/DFGGraph.h:
3328         (JSC::DFG::Graph::valueProfileFor):
3329         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
3330         * dfg/DFGInPlaceAbstractState.cpp:
3331         (JSC::DFG::InPlaceAbstractState::initialize):
3332         * dfg/DFGNode.cpp:
3333         (JSC::DFG::Node::hasVariableAccessData):
3334         * dfg/DFGNodeType.h: