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