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