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