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