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