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