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