6760a23e7e7026bda0a9d376f916d748fa5749b8
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
2
3         Do not use fastMallocGoodSize anywhere
4         https://bugs.webkit.org/show_bug.cgi?id=145103
5
6         Reviewed by Michael Saboff.
7
8         * assembler/AssemblerBuffer.h:
9         (JSC::AssemblerData::AssemblerData):
10         (JSC::AssemblerData::grow):
11
12 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
13
14         [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
15         https://bugs.webkit.org/show_bug.cgi?id=145102
16
17         Reviewed by Darin Adler.
18
19         In general, the array targeted by Array.toString() or Array.join() are pretty
20         simple. In those simple cases, we spend as much time in StringRecursionChecker
21         as we do on the actual operation.
22
23         The reason for this is the HashSet stringRecursionCheckVisitedObjects used
24         to detect recursion. We are constantly adding and removing objects which
25         dirty buckets and force constant rehash.
26
27         This patch adds a simple shortcut for those simple case: in addition to the HashSet,
28         we keep a pointer to the root object of the recursion.
29         In the vast majority of cases, we no longer touch the HashSet at all.
30
31         This patch is a 12% progression on the overall score of ArrayWeighted.
32
33         * runtime/StringRecursionChecker.h:
34         (JSC::StringRecursionChecker::performCheck):
35         (JSC::StringRecursionChecker::~StringRecursionChecker):
36         * runtime/VM.h:
37
38 2015-05-17  Filip Pizlo  <fpizlo@apple.com>
39
40         Insert store barriers late so that IR transformations don't have to worry about them
41         https://bugs.webkit.org/show_bug.cgi?id=145015
42
43         Reviewed by Geoffrey Garen.
44         
45         We have had three kinds of bugs with store barriers. For the sake of discussion we say
46         that a store barrier is needed when we have something like:
47         
48             base.field = value
49         
50         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
51           This might happen if we prove value to be a non-cell even though in the FixupPhase it
52           wasn't predicted non-cell.
53         
54         - We sometimes have a barrier in the wrong place after object allocation sinking. We
55           might sink an allocation to just above the store, but that puts it just after the
56           StoreBarrier that FixupPhase inserted.
57         
58         - We don't remove redundant barriers across basic blocks.
59         
60         This comprehensively fixes these issues by doing store barrier insertion late, and
61         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
62         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
63         base is in the current GC epoch (i.e. was the last object that we allocated or had a
64         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
65         always been allocated before base). We do conservative things when merging epoch state
66         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
67         queries AI to determine what type we've proved about value, and avoids barriers when
68         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
69         the likelihood that this AI-based removal is effective.
70         
71         Rolling back in after fixing some debug build test failures.
72
73         * CMakeLists.txt:
74         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
75         * JavaScriptCore.xcodeproj/project.pbxproj:
76         * dfg/DFGBlockMap.h:
77         (JSC::DFG::BlockMap::at):
78         * dfg/DFGConstantFoldingPhase.cpp:
79         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
80         * dfg/DFGEpoch.h:
81         (JSC::DFG::Epoch::operator<):
82         (JSC::DFG::Epoch::operator>):
83         (JSC::DFG::Epoch::operator<=):
84         (JSC::DFG::Epoch::operator>=):
85         * dfg/DFGFixupPhase.cpp:
86         (JSC::DFG::FixupPhase::fixupNode):
87         (JSC::DFG::FixupPhase::speculateForBarrier):
88         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
89         * dfg/DFGPlan.cpp:
90         (JSC::DFG::Plan::compileInThreadImpl):
91         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
92         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
93         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
94         (JSC::DFG::performFastStoreBarrierInsertion):
95         (JSC::DFG::performGlobalStoreBarrierInsertion):
96         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
97         * ftl/FTLOperations.cpp:
98         (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
99         * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
100         * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
101
102 2015-05-16  Commit Queue  <commit-queue@webkit.org>
103
104         Unreviewed, rolling out r184415.
105         https://bugs.webkit.org/show_bug.cgi?id=145096
106
107         Broke several tests (Requested by msaboff on #webkit).
108
109         Reverted changeset:
110
111         "Insert store barriers late so that IR transformations don't
112         have to worry about them"
113         https://bugs.webkit.org/show_bug.cgi?id=145015
114         http://trac.webkit.org/changeset/184415
115
116 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
117
118         Insert store barriers late so that IR transformations don't have to worry about them
119         https://bugs.webkit.org/show_bug.cgi?id=145015
120
121         Reviewed by Geoffrey Garen.
122         
123         We have had three kinds of bugs with store barriers. For the sake of discussion we say
124         that a store barrier is needed when we have something like:
125         
126             base.field = value
127         
128         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
129           This might happen if we prove value to be a non-cell even though in the FixupPhase it
130           wasn't predicted non-cell.
131         
132         - We sometimes have a barrier in the wrong place after object allocation sinking. We
133           might sink an allocation to just above the store, but that puts it just after the
134           StoreBarrier that FixupPhase inserted.
135         
136         - We don't remove redundant barriers across basic blocks.
137         
138         This comprehensively fixes these issues by doing store barrier insertion late, and
139         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
140         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
141         base is in the current GC epoch (i.e. was the last object that we allocated or had a
142         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
143         always been allocated before base). We do conservative things when merging epoch state
144         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
145         queries AI to determine what type we've proved about value, and avoids barriers when
146         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
147         the likelihood that this AI-based removal is effective.
148
149         * CMakeLists.txt:
150         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
151         * JavaScriptCore.xcodeproj/project.pbxproj:
152         * dfg/DFGBlockMap.h:
153         (JSC::DFG::BlockMap::at):
154         * dfg/DFGConstantFoldingPhase.cpp:
155         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
156         * dfg/DFGEpoch.h:
157         (JSC::DFG::Epoch::operator<):
158         (JSC::DFG::Epoch::operator>):
159         (JSC::DFG::Epoch::operator<=):
160         (JSC::DFG::Epoch::operator>=):
161         * dfg/DFGFixupPhase.cpp:
162         (JSC::DFG::FixupPhase::fixupNode):
163         (JSC::DFG::FixupPhase::speculateForBarrier):
164         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
165         * dfg/DFGPlan.cpp:
166         (JSC::DFG::Plan::compileInThreadImpl):
167         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
168         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
169         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
170         (JSC::DFG::performFastStoreBarrierInsertion):
171         (JSC::DFG::performGlobalStoreBarrierInsertion):
172         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
173
174 2015-05-15  Benjamin Poulain  <bpoulain@apple.com>
175
176         [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
177         https://bugs.webkit.org/show_bug.cgi?id=144976
178
179         Reviewed by Michael Saboff.
180
181         Failing the conversion on zero is pretty dangerous as we discovered on x86.
182
183         This patch does not really impact performance significantly because
184         r184220 removed the zero checks from Kraken. This patch is just to be
185         on the safe side for cases not covered by existing benchmarks.
186
187         * assembler/MacroAssemblerARM64.h:
188         (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
189
190 2015-05-15  Sungmann Cho  <sungmann.cho@navercorp.com>
191
192         Remove unnecessary forward declarations in PropertyNameArray.h.
193         https://bugs.webkit.org/show_bug.cgi?id=145058
194
195         Reviewed by Andreas Kling.
196
197         No new tests, no behavior change.
198
199         * runtime/PropertyNameArray.h:
200
201 2015-05-15  Mark Lam  <mark.lam@apple.com>
202
203         JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
204         https://bugs.webkit.org/show_bug.cgi?id=144622
205
206         Reviewed by Geoffrey Garen.
207
208         When setting the array to a new length that is shorter, we now check if it is worth
209         just making a new butterfly instead of clearing out the slots in the old butterfly
210         that resides beyond the new length.  If so, we will make a new butterfly instead.
211
212         There is no perf differences in the benchmark results.  However, this does benefit
213         the perf of pathological cases where we need to shorten the length of a very large
214         array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js.  With this
215         patch, we can expect that test to complete in a short time again.
216
217         * runtime/JSArray.cpp:
218         (JSC::JSArray::setLength):
219         * runtime/JSObject.cpp:
220         (JSC::JSObject::reallocateAndShrinkButterfly):
221         - makes a new butterfly with a new shorter length.
222         * runtime/JSObject.h:
223         * tests/mozilla/js1_5/Array/regress-101964.js:
224         - Undo this test change since this patch will prevent us from spending a lot of time
225           clearing a large butterfly.
226
227 2015-05-15  Basile Clement  <basile_clement@apple.com>
228
229         DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
230         https://bugs.webkit.org/show_bug.cgi?id=145062
231
232         Reviewed by Filip Pizlo.
233
234         We assert in various places (including NodeOrigin::isSet()) that a
235         NodeOrigin's semantic and forExit must be either both set, or both
236         unset.  However, LICM'ing a node with unset NodeOrigin would only set
237         forExit, and leave semantic unset. This can for instance happen when a
238         Phi node is constant-folded into a JSConstant, which in turn gets
239         LICM'd.
240
241         This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
242         addition to its forExit if semantic was previously unset.
243
244         It also adds two validators to DFGValidate.cpp:
245          - In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
246          - In CPS form, all nodes must have a set NodeOrigin forExit (this is
247            the CPS counterpart to the SSA validator that checks that all nodes
248            must have a set NodeOrigin except possibly for a continuous chunk of
249            nodes at the top of a block)
250
251         * dfg/DFGLICMPhase.cpp:
252         (JSC::DFG::LICMPhase::attemptHoist):
253         * dfg/DFGValidate.cpp:
254         (JSC::DFG::Validate::validate):
255         (JSC::DFG::Validate::validateCPS):
256
257 2015-05-15  Filip Pizlo  <fpizlo@apple.com>
258
259         Unreviewed, remove an unused declaration.
260
261         * dfg/DFGSpeculativeJIT.h:
262
263 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
264
265         Remove unused constant-base and constant-value store barrier code in the DFG
266         https://bugs.webkit.org/show_bug.cgi?id=145039
267
268         Reviewed by Andreas Kling.
269         
270         Just killing dead code.
271
272         * dfg/DFGSpeculativeJIT.cpp:
273         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
274         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
275         * dfg/DFGSpeculativeJIT.h:
276         * dfg/DFGSpeculativeJIT32_64.cpp:
277         (JSC::DFG::SpeculativeJIT::writeBarrier):
278         * dfg/DFGSpeculativeJIT64.cpp:
279         (JSC::DFG::SpeculativeJIT::writeBarrier):
280
281 2015-05-15  Alexandr Skachkov  <gskachkov@gmail.com>
282
283         Fix typo in function name parseFunctionParamters -> parseFunctionParameters
284         https://bugs.webkit.org/show_bug.cgi?id=145040
285
286         Reviewed by Mark Lam.
287
288         * parser/Parser.h:
289         * parser/Parser.cpp:
290
291 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
292
293         Remove StoreBarrierWithNullCheck, nobody ever generates this.
294         
295         Rubber stamped by Benjamin Poulain and Michael Saboff.
296
297         If we did bring something like this back in the future, we would just use UntypedUse instead
298         of CellUse to indicate that this is what we want.
299
300         * dfg/DFGAbstractInterpreterInlines.h:
301         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
302         * dfg/DFGClobberize.h:
303         (JSC::DFG::clobberize):
304         * dfg/DFGDoesGC.cpp:
305         (JSC::DFG::doesGC):
306         * dfg/DFGFixupPhase.cpp:
307         (JSC::DFG::FixupPhase::fixupNode):
308         * dfg/DFGNode.h:
309         (JSC::DFG::Node::isStoreBarrier):
310         * dfg/DFGNodeType.h:
311         * dfg/DFGObjectAllocationSinkingPhase.cpp:
312         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
313         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
314         * dfg/DFGPredictionPropagationPhase.cpp:
315         (JSC::DFG::PredictionPropagationPhase::propagate):
316         * dfg/DFGSafeToExecute.h:
317         (JSC::DFG::safeToExecute):
318         * dfg/DFGSpeculativeJIT.cpp:
319         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
320         * dfg/DFGSpeculativeJIT32_64.cpp:
321         (JSC::DFG::SpeculativeJIT::compile):
322         * dfg/DFGSpeculativeJIT64.cpp:
323         (JSC::DFG::SpeculativeJIT::compile):
324         * ftl/FTLCapabilities.cpp:
325         (JSC::FTL::canCompile):
326         * ftl/FTLLowerDFGToLLVM.cpp:
327         (JSC::FTL::LowerDFGToLLVM::compileNode):
328         (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.
329
330 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
331
332         PutGlobalVar should reference the global object it's storing into
333         https://bugs.webkit.org/show_bug.cgi?id=145036
334
335         Reviewed by Michael Saboff.
336         
337         This makes it easier to reason about store barrier insertion and elimination. This changes
338         the format of PutGlobalVar so that child1 is the global object and child2 is the value.
339         Previously it just had child1, and that was the value.
340
341         * dfg/DFGByteCodeParser.cpp:
342         (JSC::DFG::ByteCodeParser::parseBlock):
343         * dfg/DFGClobberize.h:
344         (JSC::DFG::clobberize):
345         * dfg/DFGFixupPhase.cpp:
346         (JSC::DFG::FixupPhase::fixupNode):
347         * dfg/DFGSpeculativeJIT32_64.cpp:
348         (JSC::DFG::SpeculativeJIT::compile):
349         * dfg/DFGSpeculativeJIT64.cpp:
350         (JSC::DFG::SpeculativeJIT::compile):
351         * ftl/FTLLowerDFGToLLVM.cpp:
352         (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
353
354 2015-05-14  Michael Catanzaro  <mcatanzaro@igalia.com>
355
356         [CMake] Error out when ruby is too old
357         https://bugs.webkit.org/show_bug.cgi?id=145014
358
359         Reviewed by Martin Robinson.
360
361         Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
362         CMakeLists.txt instead.
363
364         * CMakeLists.txt:
365
366 2015-05-12  Basile Clement  <basile_clement@apple.com>
367
368         Enforce options coherency
369         https://bugs.webkit.org/show_bug.cgi?id=144921
370
371         Reviewed by Mark Lam.
372
373         JavaScriptCore should be failing early when the options are set in such
374         a way that we don't have a meaningful way to execute JavaScript, rather
375         than failing for obscure reasons at some point during execution.
376
377         This patch adds a new function that checks whether the options are set
378         in a coherent way, and makes JSC::Options::initialize() crash when the
379         environment enforces incoherent options.
380         Client applications able to add or change additional options are
381         responsible to check for coherency again before starting to actually
382         execute JavaScript, if any additional options have been set. This is
383         implemented for the jsc executable in this patch.
384
385         * jsc.cpp:
386         (CommandLine::parseArguments):
387         * runtime/Options.cpp:
388         (JSC::Options::initialize):
389         (JSC::Options::ensureOptionsAreCoherent): Added.
390         * runtime/Options.h:
391         (JSC::Options::ensureOptionsAreCoherent): Added.
392
393 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
394
395         REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
396         https://bugs.webkit.org/show_bug.cgi?id=145019
397
398         Reviewed by Ryosuke Niwa.
399
400         Attempt to fix compile errors in EFL ARM buildbots.
401         By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
402         unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
403
404         * runtime/JSTemplateRegistryKey.cpp:
405         * runtime/TemplateRegistry.cpp:
406
407 2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>
408
409         Small refactoring before implementation of the ES6 arrow function.
410         https://bugs.webkit.org/show_bug.cgi?id=144954
411
412         Reviewed by Ryosuke Niwa.
413
414         * parser/Parser.h:
415         * parser/Parser.cpp:
416
417 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
418
419         REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
420         https://bugs.webkit.org/show_bug.cgi?id=145013
421
422         Reviewed by Filip Pizlo.
423
424         Fix the regression introduced by r184337.
425
426         1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
427            JSDestructibleObject::s_info.
428
429         2. The first register argument of BytecodeGenerator::emitNode
430            should be a referenced register if it is a temporary register.
431
432         * bytecompiler/NodesCodegen.cpp:
433         (JSC::TaggedTemplateNode::emitBytecode):
434         * runtime/JSTemplateRegistryKey.cpp:
435
436 2015-05-14  Andreas Kling  <akling@apple.com>
437
438         String.prototype.split() should create efficient substrings.
439         <https://webkit.org/b/144985>
440         <rdar://problem/20949344>
441
442         Reviewed by Geoffrey Garen.
443
444         Teach split() how to make substring JSStrings instead of relying on StringImpl's
445         substring sharing mechanism. The optimization works by deferring the construction
446         of a StringImpl until the substring's value is actually needed.
447
448         This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
449         Out of ~70000 substrings created by split(), only ~2000 of them get reified.
450
451         * runtime/StringPrototype.cpp:
452         (JSC::jsSubstring):
453         (JSC::splitStringByOneCharacterImpl):
454         (JSC::stringProtoFuncSplit):
455
456 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
457
458         Change the status of ES6 tagged templates to Done in features.json
459         https://bugs.webkit.org/show_bug.cgi?id=145003
460
461         Reviewed by Benjamin Poulain.
462
463         Now it's implemented in r184337.
464
465         * features.json:
466
467 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
468
469         Introduce SymbolType into SpeculativeTypes
470         https://bugs.webkit.org/show_bug.cgi?id=142651
471
472         Reviewed by Filip Pizlo.
473
474         Introduce SpecSymbol type into speculative types.
475         Previously symbol type is categorized into SpecCellOther.
476         But SpecCellOther is not intended to be used for such cells.
477
478         This patch just introduces SpecSymbol.
479         It represents the type of target value is definitely the symbol type.
480         It is the part of SpecCell.
481
482         In this patch, we do not introduce SymbolUse tracking.
483         It will be added in the separate patch.
484
485         * bytecode/SpeculatedType.cpp:
486         (JSC::dumpSpeculation):
487         (JSC::speculationFromStructure):
488         * bytecode/SpeculatedType.h:
489         (JSC::isSymbolSpeculation):
490         * dfg/DFGAbstractInterpreterInlines.h:
491         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
492         * dfg/DFGAbstractValue.cpp:
493         (JSC::DFG::AbstractValue::setType):
494         * dfg/DFGConstantFoldingPhase.cpp:
495         (JSC::DFG::ConstantFoldingPhase::foldConstants):
496         * tests/stress/typeof-symbol.js: Added.
497
498 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
499
500         [ES6] Implement tagged templates
501         https://bugs.webkit.org/show_bug.cgi?id=143183
502
503         Reviewed by Oliver Hunt.
504
505         This patch implements ES6 tagged templates.
506         In tagged templates, the function takes the template object.
507
508         The template object contains the raw and cooked template strings,
509         so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
510         While tagged templates require the both strings, the template literal only requires
511         the cooked strings. So when tokenizing under the template literal context,
512         we only builds the cooked strings.
513
514         As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
515         The template objects is cached. And every time we evaluate the same tagged templates,
516         the same (cached) template objects are used.
517         Since the spec freezes this template objects completely,
518         we cannot attach some properties to it.
519         So we can say that it behaves as if the template objects are the primitive values (like JSString).
520         Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
521         As the result, when there is no reference to the template object, we can garbage collect it
522         because the user has no way to test that the newly created template object does not equal
523         to the already collected template object.
524
525         So, to implement tagged templates, we implement the following components.
526
527         1. JSTemplateRegistryKey
528         It holds the template registry key and it does not exposed to users.
529         TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
530         When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
531         we use this JSTemplateRegistryKey as a key to the map and look up the template object from
532         TemplateRegistry.
533         JSTemplateRegistryKey is created at the bytecode compiling time and
534         stored in the CodeBlock as like as JSString content values.
535
536         2. TemplateRegistry
537         This manages the cached template objects.
538         It holds the weak map (JSTemplateRegistryKey -> the template object).
539         The template object is weakly referenced.
540         So if there is no reference to the template object,
541         the template object is automatically GC-ed.
542         When looking up the template object, it searches the cached template object.
543         If it is found, it is returned to the users.
544         If there is no cached template objects, it creates the new template object and
545         stores it with the given template registry key.
546
547         * CMakeLists.txt:
548         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
549         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
550         * JavaScriptCore.xcodeproj/project.pbxproj:
551         * bytecompiler/BytecodeGenerator.cpp:
552         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
553         (JSC::BytecodeGenerator::emitGetTemplateObject):
554         * bytecompiler/BytecodeGenerator.h:
555         * bytecompiler/NodesCodegen.cpp:
556         (JSC::TaggedTemplateNode::emitBytecode):
557         (JSC::TemplateLiteralNode::emitBytecode): Deleted.
558         * parser/ASTBuilder.h:
559         (JSC::ASTBuilder::createTaggedTemplate):
560         (JSC::ASTBuilder::createTemplateLiteral): Deleted.
561         * parser/Lexer.cpp:
562         (JSC::Lexer<T>::setCode):
563         (JSC::Lexer<T>::parseTemplateLiteral):
564         (JSC::Lexer<T>::lex):
565         (JSC::Lexer<T>::scanTrailingTemplateString):
566         (JSC::Lexer<T>::clear):
567         * parser/Lexer.h:
568         (JSC::Lexer<T>::makeEmptyIdentifier):
569         * parser/NodeConstructors.h:
570         (JSC::TaggedTemplateNode::TaggedTemplateNode):
571         (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
572         * parser/Nodes.h:
573         (JSC::TemplateLiteralNode::templateStrings):
574         (JSC::TemplateLiteralNode::templateExpressions):
575         (JSC::TaggedTemplateNode::templateLiteral):
576         * parser/Parser.cpp:
577         (JSC::Parser<LexerType>::parseTemplateString):
578         (JSC::Parser<LexerType>::parseTemplateLiteral):
579         (JSC::Parser<LexerType>::parsePrimaryExpression):
580         (JSC::Parser<LexerType>::parseMemberExpression):
581         * parser/Parser.h:
582         * parser/ParserArena.h:
583         (JSC::IdentifierArena::makeEmptyIdentifier):
584         * parser/SyntaxChecker.h:
585         (JSC::SyntaxChecker::createTaggedTemplate):
586         (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
587         * runtime/CommonIdentifiers.h:
588         * runtime/JSGlobalObject.cpp:
589         (JSC::getTemplateObject):
590         (JSC::JSGlobalObject::JSGlobalObject):
591         (JSC::JSGlobalObject::init):
592         * runtime/JSGlobalObject.h:
593         (JSC::JSGlobalObject::templateRegistry):
594         * runtime/JSTemplateRegistryKey.cpp: Added.
595         (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
596         (JSC::JSTemplateRegistryKey::create):
597         (JSC::JSTemplateRegistryKey::destroy):
598         * runtime/JSTemplateRegistryKey.h: Added.
599         * runtime/ObjectConstructor.cpp:
600         (JSC::objectConstructorFreeze):
601         * runtime/ObjectConstructor.h:
602         * runtime/TemplateRegistry.cpp: Added.
603         (JSC::TemplateRegistry::TemplateRegistry):
604         (JSC::TemplateRegistry::getTemplateObject):
605         * runtime/TemplateRegistry.h: Added.
606         * runtime/TemplateRegistryKey.h: Added.
607         (JSC::TemplateRegistryKey::isDeletedValue):
608         (JSC::TemplateRegistryKey::isEmptyValue):
609         (JSC::TemplateRegistryKey::hash):
610         (JSC::TemplateRegistryKey::rawStrings):
611         (JSC::TemplateRegistryKey::cookedStrings):
612         (JSC::TemplateRegistryKey::operator==):
613         (JSC::TemplateRegistryKey::operator!=):
614         (JSC::TemplateRegistryKey::Hasher::hash):
615         (JSC::TemplateRegistryKey::Hasher::equal):
616         (JSC::TemplateRegistryKey::TemplateRegistryKey):
617         * runtime/VM.cpp:
618         (JSC::VM::VM):
619         * runtime/VM.h:
620         * tests/stress/tagged-templates-identity.js: Added.
621         (shouldBe):
622         * tests/stress/tagged-templates-raw-strings.js: Added.
623         (shouldBe):
624         (tag):
625         (testEval):
626         * tests/stress/tagged-templates-syntax.js: Added.
627         (tag):
628         (testSyntax):
629         (testSyntaxError):
630         * tests/stress/tagged-templates-template-object.js: Added.
631         (shouldBe):
632         (tag):
633         * tests/stress/tagged-templates-this.js: Added.
634         (shouldBe):
635         (tag):
636         * tests/stress/tagged-templates.js: Added.
637         (shouldBe):
638         (raw):
639         (cooked):
640         (Counter):
641
642 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
643
644         REGRESSION(r180595): same-callee profiling no longer works
645         https://bugs.webkit.org/show_bug.cgi?id=144787
646
647         Reviewed by Filip Pizlo.
648
649         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
650         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
651         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
652
653         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
654         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
655         our speculation that the callee is the same. To avoid recompiling the same code for different callee
656         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
657         LLint and baseline JIT when multiple callees are observed.
658
659         Tests: stress/create-this-with-callee-variants.js
660
661         * bytecode/BytecodeList.json: Increased the number of operands to 5.
662         * bytecode/CodeBlock.cpp:
663         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
664         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
665         * bytecompiler/BytecodeGenerator.cpp:
666         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
667         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
668         operand.
669         * dfg/DFGByteCodeParser.cpp:
670         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
671         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
672         * jit/JITOpcodes.cpp:
673         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
674         as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
675         (JSC::JIT::emitSlow_op_create_this):
676         * jit/JITOpcodes32_64.cpp:
677         (JSC::JIT::emit_op_create_this): Ditto.
678         (JSC::JIT::emitSlow_op_create_this):
679         * llint/LowLevelInterpreter32_64.asm:
680         (_llint_op_create_this): Ditto.
681         * llint/LowLevelInterpreter64.asm:
682         (_llint_op_create_this): Ditto.
683         * runtime/CommonSlowPaths.cpp:
684         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
685         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
686         * runtime/JSCell.h:
687         (JSC::JSCell::seenMultipleCalleeObjects): Added.
688         * runtime/WriteBarrier.h:
689         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
690         * tests/stress/create-this-with-callee-variants.js: Added.
691
692 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
693
694         Clean up some possible RefPtr to PassRefPtr churn
695         https://bugs.webkit.org/show_bug.cgi?id=144779
696
697         Reviewed by Darin Adler.
698
699         * runtime/GenericTypedArrayViewInlines.h:
700         (JSC::GenericTypedArrayView<Adaptor>::create):
701         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
702         * runtime/JSArrayBufferConstructor.cpp:
703         (JSC::constructArrayBuffer):
704         * runtime/Structure.cpp:
705         (JSC::Structure::toStructureShape):
706         * runtime/TypedArrayBase.h:
707         (JSC::TypedArrayBase::create):
708         (JSC::TypedArrayBase::createUninitialized):
709         * tools/FunctionOverrides.cpp:
710         (JSC::initializeOverrideInfo):
711         Release the last use of a RefPtr as it is passed on.
712
713 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
714
715         ES6: Allow duplicate property names
716         https://bugs.webkit.org/show_bug.cgi?id=142895
717
718         Reviewed by Geoffrey Garen.
719
720         Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
721         that will define a single getter or setter property on an object.
722
723         The existing `op_put_getter_setter` opcode is still preferred for
724         putting both a getter and setter at the same time but cannot be used
725         for putting an individual getter or setter which is needed in
726         some cases.
727
728         Add a new slow path when generating bytecodes for a property list
729         with computed properties, as computed properties are the only time
730         the list of properties cannot be determined statically.
731
732         * bytecompiler/NodesCodegen.cpp:
733         (JSC::PropertyListNode::emitBytecode):
734         - fast path for all constant properties
735         - slow but paired getter/setter path if there are no computed properties
736         - slow path, individual put operation for every property, if there are computed properties
737
738         * parser/Nodes.h:
739         Distinguish a Computed property from a Constant property.
740
741         * parser/Parser.cpp:
742         (JSC::Parser<LexerType>::parseProperty):
743         (JSC::Parser<LexerType>::parsePropertyMethod):
744         Distingish Computed and Constant properties.
745
746         (JSC::Parser<LexerType>::parseObjectLiteral):
747         When we drop into strict mode it is because we saw a getter
748         or setter, so be more explicit.
749
750         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
751         Eliminate duplicate property syntax error exception.
752
753         * parser/SyntaxChecker.h:
754         (JSC::SyntaxChecker::getName):
755         * parser/ASTBuilder.h:
756         (JSC::ASTBuilder::getName): Deleted.
757         No longer used.
758
759         * runtime/JSObject.h:
760         (JSC::JSObject::putDirectInternal):
761         When updating a property. If the Accessor attribute changed
762         update the Structure.
763
764         * runtime/JSObject.cpp:
765         (JSC::JSObject::putGetter):
766         (JSC::JSObject::putSetter):
767         Called by the opcodes, just perform the same operation that
768         __defineGetter__ or __defineSetter__ would do.
769
770         (JSC::JSObject::putDirectNonIndexAccessor):
771         This transition is now handled in putDirectInternal.
772
773         * runtime/Structure.h:
774         Add needed export.
775
776         * bytecode/BytecodeList.json:
777         * bytecode/BytecodeUseDef.h:
778         (JSC::computeUsesForBytecodeOffset):
779         (JSC::computeDefsForBytecodeOffset):
780         * bytecode/CodeBlock.cpp:
781         (JSC::CodeBlock::dumpBytecode):
782         * bytecompiler/BytecodeGenerator.cpp:
783         (JSC::BytecodeGenerator::emitPutGetterById):
784         (JSC::BytecodeGenerator::emitPutSetterById):
785         * bytecompiler/BytecodeGenerator.h:
786         * jit/JIT.cpp:
787         (JSC::JIT::privateCompileMainPass):
788         * jit/JIT.h:
789         * jit/JITInlines.h:
790         (JSC::JIT::callOperation):
791         * jit/JITOperations.cpp:
792         * jit/JITOperations.h:
793         * jit/JITPropertyAccess.cpp:
794         (JSC::JIT::emit_op_put_getter_by_id):
795         (JSC::JIT::emit_op_put_setter_by_id):
796         * jit/JITPropertyAccess32_64.cpp:
797         (JSC::JIT::emit_op_put_getter_by_id):
798         (JSC::JIT::emit_op_put_setter_by_id):
799         * llint/LLIntSlowPaths.cpp:
800         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
801         * llint/LLIntSlowPaths.h:
802         * llint/LowLevelInterpreter.asm:
803         New bytecodes. Modelled after existing op_put_getter_setter.
804
805 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
806
807         Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
808         https://bugs.webkit.org/show_bug.cgi?id=144856
809
810         Reviewed by Benjamin Poulain.
811         
812         First I made fixTypeForRepresentation() print out better diagnostics when it dies.
813         
814         Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
815         converts to a representation-changing node, it needs to use one of the UseKinds that such
816         a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
817         something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
818
819         * dfg/DFGAbstractInterpreter.h:
820         (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
821         * dfg/DFGAbstractInterpreterInlines.h:
822         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
823         * dfg/DFGAbstractValue.cpp:
824         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
825         * dfg/DFGAbstractValue.h:
826         * dfg/DFGInPlaceAbstractState.cpp:
827         (JSC::DFG::InPlaceAbstractState::initialize):
828         * dfg/DFGNode.cpp:
829         (JSC::DFG::Node::convertToIdentityOn):
830         * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
831         (foo):
832
833 2015-05-13  Commit Queue  <commit-queue@webkit.org>
834
835         Unreviewed, rolling out r184313.
836         https://bugs.webkit.org/show_bug.cgi?id=144974
837
838         Introduced an assertion failure in class-syntax-
839         declaration.js, class-syntax-expression.js, and object-
840         literal-syntax.js (Requested by rniwa on #webkit).
841
842         Reverted changeset:
843
844         "Small refactoring before ES6 Arrow function implementation."
845         https://bugs.webkit.org/show_bug.cgi?id=144954
846         http://trac.webkit.org/changeset/184313
847
848 2015-05-13  Oliver Hunt  <oliver@apple.com>
849         Ensure that all the smart pointer types in WTF clear their pointer before deref
850         https://bugs.webkit.org/show_bug.cgi?id=143789
851
852         Reviewed by Ryosuke Niwa.
853
854         One of the simpler cases of this in JavaScriptCore. There
855         are other cases where we need to guard the derefs but they
856         are more complex cases.
857
858         * inspector/JSInjectedScriptHost.cpp:
859         (Inspector::JSInjectedScriptHost::releaseImpl):
860         * inspector/JSJavaScriptCallFrame.cpp:
861         (Inspector::JSJavaScriptCallFrame::releaseImpl):
862
863 2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>
864
865         Small refactoring before ES6 Arrow function implementation.
866         https://bugs.webkit.org/show_bug.cgi?id=144954
867
868         Reviewed by Filip Pizlo.
869
870         * parser/Parser.h:
871         * parser/Parser.cpp:
872
873 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
874
875         The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
876         https://bugs.webkit.org/show_bug.cgi?id=144945
877
878         Reviewed by Michael Saboff.
879         
880         We were making the mistake of using DFG liveness for object allocation sinking decisions.
881         This is wrong. In fact we almost never want to use DFG liveness directly. The only place
882         where that makes sense is pruning in DFG AI.
883         
884         So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
885         liveness.
886         
887         In the process of doing this, I realized that the DFGForAllKills definition of combined
888         liveness at block tail was not strictly right; it was using the bytecode liveness at the
889         block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
890         I changed DFGForAllKills to work in terms of CombinedLiveness.
891         
892         This allows me to unskip the test I added in r184260. I also added a new test that tries to
893         trigger this bug more directly.
894
895         * CMakeLists.txt:
896         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
897         * JavaScriptCore.xcodeproj/project.pbxproj:
898         * dfg/DFGArgumentsEliminationPhase.cpp:
899         * dfg/DFGCombinedLiveness.cpp: Added.
900         (JSC::DFG::liveNodesAtHead):
901         (JSC::DFG::CombinedLiveness::CombinedLiveness):
902         * dfg/DFGCombinedLiveness.h: Added.
903         (JSC::DFG::CombinedLiveness::CombinedLiveness):
904         * dfg/DFGForAllKills.h:
905         (JSC::DFG::forAllKillsInBlock):
906         (JSC::DFG::forAllLiveNodesAtTail): Deleted.
907         * dfg/DFGObjectAllocationSinkingPhase.cpp:
908         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
909         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
910         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
911         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
912         * tests/stress/escape-object-in-diamond-then-exit.js: Added.
913         * tests/stress/sink-object-past-invalid-check-sneaky.js:
914
915 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
916
917         I skipped a wrong test in r184270. Fix that.
918         The failure is tracked by webkit.org/b/144947.
919
920         * tests/stress/arith-modulo-node-behaviors.js:
921         * tests/stress/arith-mul-with-constants.js:
922
923 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
924
925         Avoid always running some debug code in type profiling
926         https://bugs.webkit.org/show_bug.cgi?id=144775
927
928         Reviewed by Daniel Bates.
929
930         * runtime/TypeProfilerLog.cpp:
931         (JSC::TypeProfilerLog::processLogEntries):
932
933 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
934
935         Pass String as reference in more places
936         https://bugs.webkit.org/show_bug.cgi?id=144769
937
938         Reviewed by Daniel Bates.
939
940         * debugger/Breakpoint.h:
941         (JSC::Breakpoint::Breakpoint):
942         * parser/Parser.h:
943         (JSC::Parser::setErrorMessage):
944         (JSC::Parser::updateErrorWithNameAndMessage):
945         * parser/ParserError.h:
946         (JSC::ParserError::ParserError):
947         * runtime/RegExp.cpp:
948         (JSC::RegExpFunctionalTestCollector::outputOneTest):
949         * runtime/RegExpObject.cpp:
950         (JSC::regExpObjectSourceInternal):
951         * runtime/TypeProfiler.cpp:
952         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
953         * runtime/TypeProfilerLog.cpp:
954         (JSC::TypeProfilerLog::processLogEntries):
955         * runtime/TypeProfilerLog.h:
956         * tools/FunctionOverrides.cpp:
957         (JSC::initializeOverrideInfo):
958         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
959         (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
960
961         * inspector/scripts/codegen/objc_generator_templates.py:
962         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
963         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
964         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
965         * inspector/scripts/tests/expected/enum-values.json-result:
966         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
967         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
968         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
969         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
970         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
971         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
972         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
973         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
974         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
975         Rebaseline tests after updating the generator.
976
977 2015-05-13  Michael Saboff  <msaboff@apple.com>
978
979         com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
980         https://bugs.webkit.org/show_bug.cgi?id=144933
981
982         Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
983         help determine the cause for any crash.
984
985         Reviewed by Geoffrey Garen.
986
987         * bytecode/CodeBlock.cpp:
988         (JSC::CodeBlock::finalizeUnconditionally):
989
990 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
991
992         REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
993         https://bugs.webkit.org/show_bug.cgi?id=144951
994
995         Reviewed by Michael Saboff.
996         
997         There were two issues here:
998         
999         - In r184260 we expected a small number of possible use kinds in Check nodes, and
1000           UntypedUse was not one of them. That seemed like a sensible assumption because we don't
1001           create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
1002           Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
1003           follow the same idiom as everyone else and not create tautological checks.
1004         
1005         - It's clearly not very robust to assume that Checks will not be used tautologically. So,
1006           this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
1007           which catches cases that AI would have already marked as unnecessary. It then also uses
1008           a new helper called alreadyChecked(), which allows us to just ask if the check is
1009           unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
1010
1011         * dfg/DFGArgumentsEliminationPhase.cpp:
1012         * dfg/DFGMayExit.cpp:
1013         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1014         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1015         * dfg/DFGSSAConversionPhase.cpp:
1016         (JSC::DFG::SSAConversionPhase::run):
1017         * dfg/DFGUseKind.h:
1018         (JSC::DFG::alreadyChecked):
1019         * dfg/DFGVarargsForwardingPhase.cpp:
1020
1021 k
1022 2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1023
1024         [ES6] Implement String.raw
1025         https://bugs.webkit.org/show_bug.cgi?id=144330
1026
1027         Reviewed by Filip Pizlo.
1028
1029         Implement String.raw. It is intended to be used with tagged-templates syntax.
1030         To implement ToString abstract operation efficiently,
1031         we introduce @toString bytecode intrinsic. It emits op_to_string directly.
1032
1033         * CMakeLists.txt:
1034         * builtins/StringConstructor.js: Added.
1035         (raw):
1036         * bytecompiler/NodesCodegen.cpp:
1037         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
1038         * runtime/CommonIdentifiers.h:
1039         * runtime/StringConstructor.cpp:
1040         * tests/stress/string-raw.js: Added.
1041         (shouldBe):
1042         (.get shouldBe):
1043         (Counter):
1044
1045 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
1046
1047         Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
1048
1049         * tests/stress/arith-mul-with-constants.js:
1050
1051 2015-05-12  Filip Pizlo  <fpizlo@apple.com>
1052
1053         js/dom/stack-trace.html fails with eager compilation
1054         https://bugs.webkit.org/show_bug.cgi?id=144853
1055
1056         Reviewed by Benjamin Poulain.
1057         
1058         All of our escape analyses were mishandling Check(). They were assuming that this is a
1059         non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
1060         candidate, then we need to do something: if we eliminate or sink @x, then the check no
1061         longer makes any sense since a phantom allocation has no type. This will make us forget
1062         that this operation would have exited. This was causing us to not call a valueOf method in
1063         js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
1064         +o where o had a valueOf method, and o was otherwise sinkable.
1065         
1066         This changes our escape analyses to basically pretend that any Check() that isn't obviously
1067         unnecessary is an escape. We don't have to be super careful here. Most checks will be
1068         completely eliminated by constant-folding. If that doesn't run in time, then the most
1069         common check we will see is CellUse. So, we just recognize some very obvious check kinds
1070         that we know would have passed, and for all of the rest we just assume that it's an escape.
1071         
1072         This was super tricky to test. The obvious way to test it is to use +o like
1073         stack-trace.html, except that doing so relies on the fact that we still haven't implemented
1074         the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
1075         
1076         1) Use +o. These will test what we want it to test for now, but at some point in the future
1077            these tests will just be a good sanity-check that our op_to_number implementation is
1078            right.
1079         
1080         2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
1081            operation always sees integers even though we eventually feed it an object and that
1082            object is a sink candidate.
1083         
1084         3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
1085            value is an int32. This intrinsic is required to be implemented by DFG by
1086            unconditionally speculating that the input is int32. This allows us to write much more
1087            targetted tests of the underlying issue.
1088         
1089         4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
1090            get regression test coverage of this test in eager mode.
1091
1092         * dfg/DFGArgumentsEliminationPhase.cpp:
1093         * dfg/DFGByteCodeParser.cpp:
1094         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1095         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1096         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1097         * dfg/DFGVarargsForwardingPhase.cpp:
1098         * ftl/FTLExitValue.cpp:
1099         (JSC::FTL::ExitValue::dumpInContext):
1100         * ftl/FTLLowerDFGToLLVM.cpp:
1101         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1102         * ftl/FTLOSRExitCompiler.cpp:
1103         (JSC::FTL::compileFTLOSRExit):
1104         * jsc.cpp:
1105         (GlobalObject::finishCreation):
1106         (functionIsInt32):
1107         * runtime/Intrinsic.h:
1108         * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
1109         * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
1110         * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
1111         * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
1112         * tests/stress/sink-arguments-past-invalid-check.js: Added.
1113         * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
1114         * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
1115         * tests/stress/sink-object-past-invalid-check-int32.js: Added.
1116         * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
1117         * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
1118         * tests/stress/sink-object-past-invalid-check.js: Added.
1119
1120 2015-05-12  Benjamin Poulain  <benjamin@webkit.org>
1121
1122         Fix the iteration count of arith-modulo-node-behaviors.js
1123
1124         * tests/stress/arith-modulo-node-behaviors.js:
1125         No need for big numbers for the real testing.
1126
1127 2015-05-12  Mark Lam  <mark.lam@apple.com>
1128
1129         Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
1130         https://bugs.webkit.org/show_bug.cgi?id=144924
1131
1132         Reviewed by Alex Christensen.
1133
1134         The present stack scanning code in the Windows port is expecting that the
1135         GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
1136         then saves and later uses that HANDLE with GetThreadContext() to get the
1137         runtime state of the target thread from the GC thread.  According to
1138         https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
1139         GetCurrentThread() does not provide this unique HANDLE that we expect:
1140
1141             "The function cannot be used by one thread to create a handle that can
1142             be used by other threads to refer to the first thread. The handle is
1143             always interpreted as referring to the thread that is using it. A
1144             thread can create a "real" handle to itself that can be used by other
1145             threads, or inherited by other processes, by specifying the pseudo
1146             handle as the source handle in a call to the DuplicateHandle function."
1147
1148         As a result of this, GetCurrentThread() always returns the same HANDLE value, and
1149         we end up never scanning the stacks of other threads because we wrongly think that
1150         they are all equal (in identity) to the scanning thread.  This, in turn, results
1151         in crashes due to objects that are incorrectly collected.
1152
1153         The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
1154         MachineThreads::Thread class already accurately tracks the period of time when
1155         we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
1156         to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
1157
1158         * heap/MachineStackMarker.cpp:
1159         (JSC::getCurrentPlatformThread):
1160         (JSC::MachineThreads::Thread::Thread):
1161         (JSC::MachineThreads::Thread::~Thread):
1162         (JSC::MachineThreads::Thread::suspend):
1163         (JSC::MachineThreads::Thread::resume):
1164         (JSC::MachineThreads::Thread::getRegisters):
1165
1166 2015-05-12  Benjamin Poulain  <bpoulain@apple.com>
1167
1168         [JSC] Make the NegZero backward propagated flags of ArithMod stricter
1169         https://bugs.webkit.org/show_bug.cgi?id=144897
1170
1171         Reviewed by Geoffrey Garen.
1172
1173         The NegZero flags of ArithMod were the same as ArithDiv: both children were
1174         marked as needing to handle NegativeZero.
1175
1176         Lucky for us, ArithMod is quite a bit different than ArithDiv.
1177
1178         First, the sign of the result is completely independent from
1179         the sign of the divisor. A zero on the divisor always produces a NaN.
1180         That's great, we can remove the NodeBytecodeNeedsNegZero
1181         from the flags propagated to child2.
1182
1183         Second, the sign of the result is always the same as the sign of
1184         the dividend. A dividend of zero produces a zero of same sign
1185         unless the divisor is zero (in which case the result is NaN).
1186         This is great too: we can just pass the flags we got into
1187         ArithMod.
1188
1189         With those two out of the way, we can make a faster version of ArithRound
1190         for Kraken's oscillator. Since we no longer care about negative zero,
1191         rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
1192         on the benchmark.
1193
1194         Unfortunatelly, most of the time is spent in FTL and the same optimization
1195         does not apply well just yet: rdar://problem/20904149.
1196
1197         * dfg/DFGBackwardsPropagationPhase.cpp:
1198         (JSC::DFG::BackwardsPropagationPhase::propagate):
1199         Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
1200
1201         * dfg/DFGSpeculativeJIT.cpp:
1202         (JSC::DFG::SpeculativeJIT::compileArithRound):
1203         Faster Math.round() when negative zero is not important.
1204
1205         * tests/stress/arith-modulo-node-behaviors.js: Added.
1206         (moduloWithNegativeZeroDividend):
1207         (moduloWithUnusedNegativeZeroDividend):
1208         (moduloWithNegativeZeroDivisor):
1209
1210 2015-05-12  Mark Lam  <mark.lam@apple.com>
1211
1212         Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
1213         https://bugs.webkit.org/show_bug.cgi?id=144925
1214
1215         Reviewed by Michael Saboff.
1216
1217         Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
1218         operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
1219         can apply better OO encapsulation and convert all these functions into methods of the
1220         MachineThreads::Thread struct.
1221
1222         This will also make it easier to reason about the fix for
1223         https://bugs.webkit.org/show_bug.cgi?id=144924 later.
1224
1225         * heap/MachineStackMarker.cpp:
1226         (JSC::getCurrentPlatformThread):
1227         (JSC::MachineThreads::Thread::createForCurrentThread):
1228         (JSC::MachineThreads::Thread::operator!=):
1229         (JSC::MachineThreads::Thread::operator==):
1230         (JSC::MachineThreads::addCurrentThread):
1231         (JSC::MachineThreads::removeThreadIfFound):
1232         (JSC::MachineThreads::Thread::suspend):
1233         (JSC::MachineThreads::Thread::resume):
1234         (JSC::MachineThreads::Thread::getRegisters):
1235         (JSC::MachineThreads::Thread::Registers::stackPointer):
1236         (JSC::MachineThreads::Thread::freeRegisters):
1237         (JSC::MachineThreads::Thread::captureStack):
1238         (JSC::MachineThreads::tryCopyOtherThreadStack):
1239         (JSC::MachineThreads::tryCopyOtherThreadStacks):
1240         (JSC::equalThread): Deleted.
1241         (JSC::suspendThread): Deleted.
1242         (JSC::resumeThread): Deleted.
1243         (JSC::getPlatformThreadRegisters): Deleted.
1244         (JSC::otherThreadStackPointer): Deleted.
1245         (JSC::freePlatformThreadRegisters): Deleted.
1246         (JSC::otherThreadStack): Deleted.
1247
1248 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
1249
1250         Array.slice should have a fast path like Array.splice
1251         https://bugs.webkit.org/show_bug.cgi?id=144901
1252
1253         Reviewed by Geoffrey Garen.
1254
1255         Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
1256         In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
1257
1258         * runtime/ArrayPrototype.cpp:
1259         (JSC::arrayProtoFuncSlice):
1260         * runtime/JSArray.cpp:
1261         (JSC::JSArray::fastSlice): Added.
1262         * runtime/JSArray.h:
1263
1264 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1265
1266         OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
1267         https://bugs.webkit.org/show_bug.cgi?id=143078
1268
1269         Reviewed by Andreas Kling.
1270         
1271         In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
1272         pruning is actually necessary. Well, not quite: we just need to prune out keys from the
1273         heap availability map where the base node doesn't dominate the point where we are asking
1274         for availability. If we don't do this, then eventually the IR gets corrupt because we'll
1275         insert PutHints that reference the base node in places where the base node doesn't
1276         dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
1277         liveness. This is the strongest possible pruning we can do, and it should be sound. We
1278         shouldn't have a node available for a virtual register if that register is live and the
1279         node doesn't dominate.
1280         
1281         Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
1282         abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
1283
1284         * dfg/DFGAvailabilityMap.cpp:
1285         (JSC::DFG::AvailabilityMap::pruneHeap):
1286         (JSC::DFG::AvailabilityMap::pruneByLiveness):
1287         (JSC::DFG::AvailabilityMap::prune): Deleted.
1288         * dfg/DFGAvailabilityMap.h:
1289         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1290         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1291         * ftl/FTLLowerDFGToLLVM.cpp:
1292         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1293         * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
1294         * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
1295
1296 2015-05-12  Gabor Loki  <loki@webkit.org>
1297
1298         Workaround for Cortex-A53 erratum 843419
1299         https://bugs.webkit.org/show_bug.cgi?id=144680
1300
1301         Reviewed by Michael Saboff.
1302
1303         This patch is about to give simple workaround for Cortex-A53 erratum 843419.
1304         It inserts nops after ADRP instruction to avoid wrong address accesses.
1305
1306         * assembler/ARM64Assembler.h:
1307         (JSC::ARM64Assembler::adrp):
1308         (JSC::ARM64Assembler::nopCortexA53Fix843419):
1309
1310 2015-05-11  Commit Queue  <commit-queue@webkit.org>
1311
1312         Unreviewed, rolling out r184009.
1313         https://bugs.webkit.org/show_bug.cgi?id=144900
1314
1315         Caused crashes on inspector tests (Requested by ap on
1316         #webkit).
1317
1318         Reverted changeset:
1319
1320         "MapDataImpl::add() shouldn't do the same hash lookup twice."
1321         https://bugs.webkit.org/show_bug.cgi?id=144759
1322         http://trac.webkit.org/changeset/184009
1323
1324 2015-05-11  Commit Queue  <commit-queue@webkit.org>
1325
1326         Unreviewed, rolling out r184123.
1327         https://bugs.webkit.org/show_bug.cgi?id=144899
1328
1329         Seems to have introduced flaky crashes in many JS tests
1330         (Requested by rniwa on #webkit).
1331
1332         Reverted changeset:
1333
1334         "REGRESSION(r180595): same-callee profiling no longer works"
1335         https://bugs.webkit.org/show_bug.cgi?id=144787
1336         http://trac.webkit.org/changeset/184123
1337
1338 2015-05-11  Brent Fulgham  <bfulgham@apple.com>
1339
1340         [Win] Move Windows build target to Windows 7 (or newer)
1341         https://bugs.webkit.org/show_bug.cgi?id=144890
1342         <rdar://problem/20707307>
1343
1344         Reviewed by Anders Carlsson.
1345
1346         Update linked SDK and minimal Windows level to be compatible with
1347         Windows 7 or newer.
1348
1349         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1350         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1351         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
1352         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
1353         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
1354         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
1355         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
1356         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
1357         * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
1358         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
1359         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
1360         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
1361         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
1362         * config.h:
1363
1364 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1365
1366         CPS rethreading phase's flush detector flushes way too many SetLocals
1367         https://bugs.webkit.org/show_bug.cgi?id=144819
1368
1369         Reviewed by Geoffrey Garen.
1370         
1371         After probably unrelated changes, this eventually caused some arguments elimination to stop
1372         working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
1373         a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
1374         meant to only affect the SetLocal itself.
1375         
1376         This is a speed-up on Octane/earley.
1377
1378         * dfg/DFGCPSRethreadingPhase.cpp:
1379         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
1380
1381 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1382
1383         gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
1384         https://bugs.webkit.org/show_bug.cgi?id=144854
1385
1386         Reviewed by Oliver Hunt.
1387         
1388         This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
1389         It used to be that Construct required less code, but that's not the case for now.
1390
1391         * ftl/FTLInlineCacheSize.cpp:
1392         (JSC::FTL::sizeOfCallForwardVarargs):
1393         (JSC::FTL::sizeOfConstructVarargs):
1394         (JSC::FTL::sizeOfConstructForwardVarargs):
1395
1396 2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>
1397
1398         REGRESSION(r180595): same-callee profiling no longer works
1399         https://bugs.webkit.org/show_bug.cgi?id=144787
1400
1401         Reviewed by Michael Saboff.
1402
1403         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
1404         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
1405         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
1406
1407         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
1408         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
1409         our speculation that the callee is the same. To avoid recompiling the same code for different callee
1410         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
1411         LLint and baseline JIT when multiple callees are observed.
1412
1413         Tests: stress/create-this-with-callee-variants.js
1414
1415         * bytecode/BytecodeList.json: Increased the number of operands to 5.
1416         * bytecode/BytecodeUseDef.h:
1417         (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
1418         operands.
1419         * bytecode/CodeBlock.cpp:
1420         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
1421         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
1422         * bytecompiler/BytecodeGenerator.cpp:
1423         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
1424         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
1425         operand.
1426         * dfg/DFGByteCodeParser.cpp:
1427         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
1428         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
1429         * jit/JITOpcodes.cpp:
1430         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
1431         as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
1432         (JSC::JIT::emitSlow_op_create_this):
1433         * jit/JITOpcodes32_64.cpp:
1434         (JSC::JIT::emit_op_create_this): Ditto.
1435         (JSC::JIT::emitSlow_op_create_this):
1436         * llint/LowLevelInterpreter32_64.asm:
1437         (_llint_op_create_this): Ditto.
1438         * llint/LowLevelInterpreter64.asm:
1439         (_llint_op_create_this): Ditto.
1440         * runtime/CommonSlowPaths.cpp:
1441         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
1442         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
1443         * runtime/JSCell.h:
1444         (JSC::JSCell::seenMultipleCalleeObjects): Added.
1445         * runtime/WriteBarrier.h:
1446         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
1447         * tests/stress/create-this-with-callee-variants.js: Added.
1448
1449 2015-05-11  Andreas Kling  <akling@apple.com>
1450
1451         PropertyNameArray should use a Vector when there are few entries.
1452         <https://webkit.org/b/144874>
1453
1454         Reviewed by Geoffrey Garen.
1455
1456         Bring back an optimization that was lost in the for-in refactoring.
1457         PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
1458         enough (20) entries to justify converting to a HashSet for contains().
1459
1460         Also inlined the code while we're here, since it has so few clients and
1461         the call overhead adds up.
1462
1463         ~5% progression on Kraken/json-stringify-tinderbox.
1464
1465         * runtime/PropertyNameArray.cpp: Removed.
1466         * runtime/PropertyNameArray.h:
1467         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1468         (JSC::PropertyNameArray::add):
1469         (JSC::PropertyNameArray::addKnownUnique):
1470
1471 2015-05-11  Matt Baker  <mattbaker@apple.com>
1472
1473         Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
1474         https://bugs.webkit.org/show_bug.cgi?id=144808
1475
1476         Reviewed by Darin Adler.
1477
1478         Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
1479         The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
1480
1481         * profiler/Profile.cpp:
1482         (JSC::Profile::create):
1483         (JSC::Profile::Profile):
1484         * profiler/Profile.h:
1485         * profiler/ProfileGenerator.cpp:
1486         (JSC::ProfileGenerator::ProfileGenerator):
1487         (JSC::AddParentForConsoleStartFunctor::operator()):
1488
1489 2015-05-11  Basile Clement  <basile_clement@apple.com>
1490
1491         Unreviewed, remove unintended change.
1492
1493         * dfg/DFGAbstractInterpreterInlines.h:
1494         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1495
1496 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1497
1498         Make it easy to enable eager/non-concurrent JIT compilation
1499         https://bugs.webkit.org/show_bug.cgi?id=144877
1500
1501         Reviewed by Michael Saboff.
1502
1503         * runtime/Options.cpp:
1504         (JSC::recomputeDependentOptions):
1505         * runtime/Options.h:
1506
1507 2015-05-10  Filip Pizlo  <fpizlo@apple.com>
1508
1509         We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
1510         https://bugs.webkit.org/show_bug.cgi?id=144851
1511
1512         Reviewed by Michael Saboff.
1513         
1514         LoadVarargs loads arguments from some object and puts them on the stack. The region of
1515         stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
1516         shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
1517         something that uses more stack than the LoadVarargs wanted to.
1518         
1519         This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
1520         promoter. This is an important promotion rule for performance, and in cases where we are
1521         compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
1522         the phantom arguments array that this phase sees. The LoadVarargs limit is based on
1523         profiling and the phantom arguments array is a proof; in most cases the profiling is more
1524         conservative.
1525         
1526         But, you could write some crazy code where the statically obvious arguments array value is
1527         bigger than what the profiling would have told you. When this happens, this promotion
1528         effectively removes a bounds check. This either results in us clobbering a bunch of stack,
1529         or it means that we never initialize a region of the stack that a later operation will read
1530         (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
1531         unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
1532         the original LoadVarargs limit).
1533         
1534         * dfg/DFGArgumentsEliminationPhase.cpp:
1535         * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
1536         (foo):
1537         (bar):
1538         (baz):
1539         * tests/stress/load-varargs-elimination-bounds-check.js: Added.
1540         (foo):
1541         (bar):
1542         (baz):
1543
1544 2015-05-11  Andreas Kling  <akling@apple.com>
1545
1546         JSON.stringify shouldn't use generic get() to access Array.length
1547         <https://webkit.org/b/144847>
1548
1549         Reviewed by Geoffrey Garen.
1550
1551         If the value being serialized is a JSArray object, we can downcast and call its
1552         length() directly instead of doing a generic property lookup.
1553
1554         0.5% progression on Kraken/json-stringify-tinderbox.
1555
1556         * runtime/JSONObject.cpp:
1557         (JSC::Stringifier::Holder::appendNextProperty):
1558
1559 2015-05-10  Andreas Kling  <akling@apple.com>
1560
1561         Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
1562
1563         Follow up to r184050 suggested by Darin.
1564
1565         * runtime/PropertyNameArray.h:
1566
1567 2015-05-10  Andreas Kling  <akling@apple.com>
1568
1569         Remove unused things from PropertyNameArray.
1570         <https://webkit.org/b/144834>
1571
1572         Reviewed by Filip Pizlo.
1573
1574         PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
1575         was refactored and optimized last year. Then more refactoring happened and this class
1576         doesn't need to ring and toot anymore.
1577
1578         The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
1579         actually using it for anything and we were just wasting time creating these.
1580
1581         Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
1582
1583         * runtime/JSObject.cpp:
1584         (JSC::JSObject::getPropertyNames):
1585         * runtime/JSPropertyNameEnumerator.cpp:
1586         (JSC::JSPropertyNameEnumerator::create):
1587         (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
1588         * runtime/JSPropertyNameEnumerator.h:
1589         * runtime/PropertyNameArray.cpp:
1590         (JSC::PropertyNameArray::add):
1591         (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
1592         * runtime/PropertyNameArray.h:
1593         (JSC::PropertyNameArray::PropertyNameArray):
1594         (JSC::PropertyNameArray::add):
1595         (JSC::PropertyNameArray::addKnownUnique):
1596         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1597         (JSC::RefCountedIdentifierSet::contains): Deleted.
1598         (JSC::RefCountedIdentifierSet::size): Deleted.
1599         (JSC::RefCountedIdentifierSet::add): Deleted.
1600         (JSC::PropertyNameArray::identifierSet): Deleted.
1601         (JSC::PropertyNameArray::numCacheableSlots): Deleted.
1602         (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
1603         (JSC::PropertyNameArray::setBaseObject): Deleted.
1604         (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
1605
1606 2015-05-09  Yoav Weiss  <yoav@yoav.ws>
1607
1608         Remove the PICTURE_SIZES build flag
1609         https://bugs.webkit.org/show_bug.cgi?id=144679
1610
1611         Reviewed by Benjamin Poulain.
1612
1613         Removed the PICTURE_SIZES build time flag.
1614
1615         * Configurations/FeatureDefines.xcconfig:
1616
1617 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1618
1619         Extend the SaneChain optimization to Contiguous arrays
1620         https://bugs.webkit.org/show_bug.cgi?id=144664
1621
1622         Reviewed by Mark Lam.
1623         
1624         Previously if you loaded from a hole, you'd either have to take slow path for the array
1625         load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
1626         gathered the necessary profiling yet). But that's unnecessary if we know that the
1627         prototype chain is sane - i.e. has no indexed properties. Then we can just return
1628         Undefined for the hole.
1629         
1630         Making this change requires setting more watchpoints on the array prototype chain. But
1631         that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
1632         itself up lazily. This means that this increased the number of recompilations we'd get
1633         due to the array prototype chain being built up.
1634         
1635         So, this change also removes the laziness and static tables from ArrayPrototype.
1636         
1637         But to make that change, I also had to add a helper for eagerly building up a prototype
1638         that has builtin functions.
1639
1640         * CMakeLists.txt:
1641         * DerivedSources.make:
1642         * dfg/DFGArrayMode.h:
1643         * dfg/DFGFixupPhase.cpp:
1644         (JSC::DFG::FixupPhase::fixupNode):
1645         * dfg/DFGSpeculativeJIT32_64.cpp:
1646         (JSC::DFG::SpeculativeJIT::compile):
1647         * dfg/DFGSpeculativeJIT64.cpp:
1648         (JSC::DFG::SpeculativeJIT::compile):
1649         * ftl/FTLLowerDFGToLLVM.cpp:
1650         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1651         * runtime/ArrayPrototype.cpp:
1652         (JSC::ArrayPrototype::finishCreation):
1653         (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
1654         * runtime/ArrayPrototype.h:
1655         * runtime/JSObject.h:
1656
1657 2015-05-08  Michael Saboff  <msaboff@apple.com>
1658
1659         Creating a large MarkedBlock sometimes results in more than one cell in the block
1660         https://bugs.webkit.org/show_bug.cgi?id=144815
1661
1662         Reviewed by Mark Lam.
1663
1664         Large MarkedBlocks should have one and only one cell.  Changed the calculation of
1665         m_endAtom for large blocks to use the location of the first cell + 1.  This
1666         assures that large blocks only have one cell.
1667
1668         * heap/MarkedBlock.cpp:
1669         (JSC::MarkedBlock::MarkedBlock):
1670
1671 2015-05-08  Oliver Hunt  <oliver@apple.com>
1672
1673         MapDataImpl::add() shouldn't do the same hash lookup twice.
1674         https://bugs.webkit.org/show_bug.cgi?id=144759
1675
1676         Reviewed by Gavin Barraclough.
1677
1678         We don't actually need to do a double lookup here, all we need to
1679         do is update the index to point to the correct m_size.
1680
1681         * runtime/MapDataInlines.h:
1682         (JSC::JSIterator>::add):
1683
1684 2015-05-08  Andreas Kling  <akling@apple.com>
1685
1686         Micro-optimize JSON serialization of string primitives.
1687         <https://webkit.org/b/144800>
1688
1689         Reviewed by Sam Weinig.
1690
1691         Don't use the out-of-line JSValue::getString() to grab at string primitives
1692         in serialization. Just check if it's a JSString and then downcast to grab at
1693         the WTF::String inside.
1694
1695         2% progression on Kraken/json-stringify-tinderbox.
1696
1697         * runtime/JSONObject.cpp:
1698         (JSC::Stringifier::appendStringifiedValue):
1699
1700 2015-05-08  Andreas Kling  <akling@apple.com>
1701
1702         Optimize serialization of quoted JSON strings.
1703         <https://webkit.org/b/144754>
1704
1705         Reviewed by Darin Adler.
1706
1707         Optimized the serialization of quoted strings into JSON by moving the logic into
1708         StringBuilder so it can make smarter decisions about buffering.
1709
1710         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1711
1712         * bytecompiler/NodesCodegen.cpp:
1713         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1714
1715         * runtime/JSONObject.h:
1716         * runtime/JSONObject.cpp:
1717         (JSC::Stringifier::Holder::appendNextProperty):
1718         (JSC::appendStringToStringBuilder): Deleted.
1719         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1720         (JSC::Stringifier::appendQuotedString): Deleted.
1721         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1722         to StringBuilder and call that from here.
1723
1724 2015-05-07  Commit Queue  <commit-queue@webkit.org>
1725
1726         Unreviewed, rolling out r183961.
1727         https://bugs.webkit.org/show_bug.cgi?id=144784
1728
1729         Broke js/dom/JSON-stringify.html (Requested by kling on
1730         #webkit).
1731
1732         Reverted changeset:
1733
1734         "Optimize serialization of quoted JSON strings."
1735         https://bugs.webkit.org/show_bug.cgi?id=144754
1736         http://trac.webkit.org/changeset/183961
1737
1738 2015-05-07  Filip Pizlo  <fpizlo@apple.com>
1739
1740         GC has trouble with pathologically large array allocations
1741         https://bugs.webkit.org/show_bug.cgi?id=144609
1742
1743         Reviewed by Geoffrey Garen.
1744
1745         The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
1746         after pinning them), and would skip the accounting. The GC calculates the size of the heap
1747         in tandem with the scan to save time, and that accounting was part of how the GC would
1748         know how big the heap was. The GC would then think that oversize copied blocks use no
1749         memory, and would then mess up its scheduling of the next GC.
1750         
1751         Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
1752         size by summing the size from the last collection and the size by walking the eden heap.
1753         But this breaks when we eagerly delete objects that the last collection touched. We can do
1754         that in one corner case: copied block reallocation. The old block will be deleted from old
1755         space during the realloc and a new block will be allocated in new space. In order for the
1756         GC to know that the size of old space actually shrank, we need a field to tell us how much
1757         such shrinkage could occur. Since this is a very dirty corner case and it only works for
1758         very particular reasons arising from the special properties of copied space (single owner,
1759         and the realloc is used in places where the compiler already knows that it cannot register
1760         allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
1761         devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
1762         
1763         To test this, I needed to add an Option to force a particular RAM size in the GC. This
1764         allows us to write tests that assert that the GC heap size is some value X, without
1765         worrying about machine-to-machine variations due to GC heuristics changing based on RAM
1766         size.
1767
1768         * heap/CopiedSpace.cpp:
1769         (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
1770         (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
1771         * heap/CopiedSpace.h:
1772         (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
1773         * heap/Heap.cpp:
1774         (JSC::Heap::Heap): Allow the user to force the RAM size.
1775         (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
1776         * heap/SlotVisitorInlines.h:
1777         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
1778         * jsc.cpp: Add size measuring hooks to write the largeish test.
1779         (GlobalObject::finishCreation):
1780         (functionGCAndSweep):
1781         (functionFullGC):
1782         (functionEdenGC):
1783         (functionHeapSize):
1784         * runtime/Options.h:
1785         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
1786         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
1787         (foo):
1788         (test):
1789
1790 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1791
1792         Global functions should be initialized as JSFunctions in byte code
1793         https://bugs.webkit.org/show_bug.cgi?id=144178
1794
1795         Reviewed by Geoffrey Garen.
1796
1797         This patch makes the initialization of global functions more explicit by
1798         moving initialization into bytecode. It also prepares JSC for having ES6
1799         style lexical scoping because initializing global functions in bytecode
1800         easily allows global functions to be initialized with the proper scope that
1801         will have access to global lexical variables. Global lexical variables
1802         should be visible to global functions but don't live on the global object.
1803
1804         * bytecode/UnlinkedCodeBlock.cpp:
1805         (JSC::UnlinkedProgramCodeBlock::visitChildren):
1806         * bytecode/UnlinkedCodeBlock.h:
1807         * bytecompiler/BytecodeGenerator.cpp:
1808         (JSC::BytecodeGenerator::generate):
1809         (JSC::BytecodeGenerator::BytecodeGenerator):
1810         * bytecompiler/BytecodeGenerator.h:
1811         * runtime/Executable.cpp:
1812         (JSC::ProgramExecutable::initializeGlobalProperties):
1813         * runtime/JSGlobalObject.cpp:
1814         (JSC::JSGlobalObject::addGlobalVar):
1815         (JSC::JSGlobalObject::addFunction):
1816         * runtime/JSGlobalObject.h:
1817
1818 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1819
1820         Fix the x86 32bits build
1821
1822         * assembler/X86Assembler.h:
1823
1824 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1825
1826         [JSC] Add basic DFG/FTL support for Math.round
1827         https://bugs.webkit.org/show_bug.cgi?id=144725
1828
1829         Reviewed by Filip Pizlo.
1830
1831         This patch adds two optimizations targeting Math.round():
1832         -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
1833         -Change the MacroAssembler to be stricter on how we fail to convert a double
1834          to ingeter. Previously, any number valued zero would fail, now we only
1835          fail for -0.
1836
1837         Since ArithRound speculate it produces int32, the MacroAssembler assembler
1838         part became necessary because zero is a pretty common output of Math.round()
1839         and we would OSR exit a lot (and eventually recompile for doubles).
1840
1841         The implementation itself of the inline Math.round() is exactly the same
1842         as the C function that exists for Math.round(). We can very likely do better
1843         but it is a good start known to be valid and inlining alone alread provides
1844         significant speedups.
1845
1846         * assembler/X86Assembler.h:
1847         (JSC::X86Assembler::movmskpd_rr):
1848         * assembler/MacroAssemblerX86Common.h:
1849         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
1850         When we have a zero, get the sign bit out of the double and check if is one.
1851
1852         I'll look into doing the same improvement for ARM.
1853
1854         * bytecode/SpeculatedType.cpp:
1855         (JSC::typeOfDoubleRounding):
1856         (JSC::typeOfDoubleFRound): Deleted.
1857         * bytecode/SpeculatedType.h:
1858         * dfg/DFGAbstractInterpreterInlines.h:
1859         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1860         * dfg/DFGByteCodeParser.cpp:
1861         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1862         * dfg/DFGClobberize.h:
1863         (JSC::DFG::clobberize):
1864         * dfg/DFGDoesGC.cpp:
1865         (JSC::DFG::doesGC):
1866         * dfg/DFGFixupPhase.cpp:
1867         (JSC::DFG::FixupPhase::fixupNode):
1868         * dfg/DFGGraph.h:
1869         (JSC::DFG::Graph::roundShouldSpeculateInt32):
1870         (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
1871         * dfg/DFGNode.h:
1872         (JSC::DFG::Node::arithNodeFlags):
1873         (JSC::DFG::Node::hasHeapPrediction):
1874         (JSC::DFG::Node::hasArithMode):
1875         * dfg/DFGNodeType.h:
1876         * dfg/DFGPredictionPropagationPhase.cpp:
1877         (JSC::DFG::PredictionPropagationPhase::propagate):
1878         * dfg/DFGSafeToExecute.h:
1879         (JSC::DFG::safeToExecute):
1880         * dfg/DFGSpeculativeJIT.cpp:
1881         (JSC::DFG::SpeculativeJIT::compileArithRound):
1882         * dfg/DFGSpeculativeJIT.h:
1883         * dfg/DFGSpeculativeJIT32_64.cpp:
1884         (JSC::DFG::SpeculativeJIT::compile):
1885         * dfg/DFGSpeculativeJIT64.cpp:
1886         (JSC::DFG::SpeculativeJIT::compile):
1887         * ftl/FTLCapabilities.cpp:
1888         (JSC::FTL::canCompile):
1889         * ftl/FTLIntrinsicRepository.h:
1890         * ftl/FTLLowerDFGToLLVM.cpp:
1891         (JSC::FTL::LowerDFGToLLVM::compileNode):
1892         (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
1893         (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
1894         (JSC::FTL::LowerDFGToLLVM::compileArithRound):
1895         * ftl/FTLOutput.h:
1896         (JSC::FTL::Output::ceil64):
1897         * jit/ThunkGenerators.cpp:
1898         * runtime/MathCommon.cpp:
1899         * runtime/MathCommon.h:
1900         * runtime/MathObject.cpp:
1901         (JSC::mathProtoFuncRound):
1902         * tests/stress/math-round-basics.js: Added.
1903         (mathRoundOnIntegers):
1904         (mathRoundOnDoubles):
1905         (mathRoundOnBooleans):
1906         (uselessMathRound):
1907         (mathRoundWithOverflow):
1908         (mathRoundConsumedAsDouble):
1909         (mathRoundDoesNotCareAboutMinusZero):
1910         (mathRoundNoArguments):
1911         (mathRoundTooManyArguments):
1912         (testMathRoundOnConstants):
1913         (mathRoundStructTransition):
1914         (Math.round):
1915
1916 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1917
1918         exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
1919         https://bugs.webkit.org/show_bug.cgi?id=144753
1920
1921         Reviewed by Mark Lam.
1922
1923         This allows the BytecodeGenerator to freely emit startup code that "may"
1924         throw exceptions without worrying that this startup code will trigger
1925         the exceptionFuzz exception. The exceptionFuzz counter will only begin
1926         ticking when the 'enableExceptionFuzz' function is explicitly called in 
1927         the exceptionFuzz tests.
1928
1929         * jsc.cpp:
1930         (GlobalObject::finishCreation):
1931         (functionEnableExceptionFuzz):
1932         * tests/exceptionFuzz/3d-cube.js:
1933         * tests/exceptionFuzz/date-format-xparb.js:
1934         * tests/exceptionFuzz/earley-boyer.js:
1935
1936 2015-05-07  Andreas Kling  <akling@apple.com>
1937
1938         Optimize serialization of quoted JSON strings.
1939         <https://webkit.org/b/144754>
1940
1941         Reviewed by Darin Adler.
1942
1943         Optimized the serialization of quoted strings into JSON by moving the logic into
1944         StringBuilder so it can make smarter decisions about buffering.
1945
1946         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1947
1948         * bytecompiler/NodesCodegen.cpp:
1949         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1950
1951         * runtime/JSONObject.h:
1952         * runtime/JSONObject.cpp:
1953         (JSC::Stringifier::Holder::appendNextProperty):
1954         (JSC::appendStringToStringBuilder): Deleted.
1955         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1956         (JSC::Stringifier::appendQuotedString): Deleted.
1957         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1958         to StringBuilder and call that from here.
1959
1960 2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>
1961
1962         FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
1963         https://bugs.webkit.org/show_bug.cgi?id=144678
1964
1965         Reviewed by Geoffrey Garen.
1966
1967         Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
1968         But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
1969
1970         function t() { var ok = {null: function () { } }; ok[ok = null](); }
1971         t();  // Should not throw error.
1972
1973         This patch takes care about `subscriptHasAssignment`.
1974         By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
1975         it correctly moves the LHS value to a temporary register.
1976
1977         * bytecompiler/NodesCodegen.cpp:
1978         (JSC::FunctionCallBracketNode::emitBytecode):
1979         * parser/ASTBuilder.h:
1980         (JSC::ASTBuilder::makeFunctionCallNode):
1981         * parser/NodeConstructors.h:
1982         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
1983         * parser/Nodes.h:
1984         * tests/stress/assignment-in-function-call-bracket-node.js: Added.
1985         (shouldBe):
1986         (shouldBe.):
1987
1988 2015-05-07  Basile Clement  <basile_clement@apple.com>
1989
1990         Unreviewed, add missing braces on a single-line if that got expanded in r183939
1991
1992         * ftl/FTLLowerDFGToLLVM.cpp:
1993         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1994
1995 2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>
1996
1997         Revert "Introducing the Platform Abstraction Layer (PAL)"
1998         https://bugs.webkit.org/show_bug.cgi?id=144751
1999
2000         Unreviewed.
2001
2002         PAL should be a new target inside WebCore, rather than a top-level folder.
2003
2004         * Configurations/FeatureDefines.xcconfig: Updated
2005
2006 2015-05-07  Basile Clement  <basile_clement@apple.com>
2007
2008         Dumping OSR ExitValue should expand materializations only once
2009         https://bugs.webkit.org/show_bug.cgi?id=144694
2010
2011         Reviewed by Filip Pizlo.
2012
2013         Currently, dumping OSR exit values will print the full materialization
2014         information each time it is encountered. We change it to print only a
2015         brief description (only the materialization's address), and print the
2016         whole set of materializations later on.
2017
2018         This makes the dump less confusing (less likely to think that two
2019         instances of the same materialization are different), and will be a
2020         necessary change if/when we support materialization cycles.
2021
2022         * ftl/FTLCompile.cpp:
2023         (JSC::FTL::mmAllocateDataSection):
2024         * ftl/FTLExitValue.cpp:
2025         (JSC::FTL::ExitValue::dumpInContext):
2026         * ftl/FTLLowerDFGToLLVM.cpp:
2027         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2028
2029 2015-05-07  Andreas Kling  <akling@apple.com>
2030
2031         Worker threads leak WeakBlocks (as seen on leaks bot)
2032         <https://webkit.org/b/144721>
2033         <rdar://problem/20848288>
2034
2035         Reviewed by Darin Adler.
2036
2037         Nuke any remaining empty WeakBlocks when the Heap is being torn down.
2038         Trying to peek into these blocks after the VM is dead would be a bug anyway.
2039
2040         This fixes a ~750 KB leak seen on the leaks bot.
2041
2042         * heap/Heap.cpp:
2043         (JSC::Heap::~Heap):
2044
2045 2015-05-05  Geoffrey Garen  <ggaren@apple.com>
2046
2047         Don't branch when accessing the callee
2048         https://bugs.webkit.org/show_bug.cgi?id=144645
2049
2050         Reviewed by Michael Saboff.
2051
2052         The branch was added in <http://trac.webkit.org/changeset/81040> without
2053         explanation.
2054
2055         kling found it to be a performance problem. See <https://webkit.org/b/144586>.
2056
2057         Our theory of access to Registers is that it's up to the client to access
2058         them in the right way. So, let's do that.
2059
2060         * interpreter/CallFrame.h:
2061         (JSC::ExecState::callee):
2062         (JSC::ExecState::setCallee): Call the field object instead of function
2063         because nothing guarantees that it's a function.
2064         * interpreter/ProtoCallFrame.h:
2065         (JSC::ProtoCallFrame::callee):
2066         (JSC::ProtoCallFrame::setCallee):
2067         * interpreter/Register.h:
2068         * runtime/JSObject.h:
2069         (JSC::Register::object): Just do a cast like our other accessors do.
2070         (JSC::Register::operator=):
2071         (JSC::Register::function): Deleted.
2072         (JSC::Register::withCallee): Deleted.
2073
2074 2015-05-07  Dan Bernstein  <mitz@apple.com>
2075
2076         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
2077         https://bugs.webkit.org/show_bug.cgi?id=144727
2078
2079         Reviewed by Darin Adler.
2080
2081         * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
2082         INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
2083
2084 2015-05-07  Andreas Kling  <akling@apple.com>
2085
2086         Special-case Int32 values in JSON.stringify().
2087         <https://webkit.org/b/144731>
2088
2089         Reviewed by Michael Saboff.
2090
2091         Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
2092         simple integers through the full-blown dtoa() machinery.
2093
2094         ~50% speedup on Kraken/json-stringify-tinderbox.
2095
2096         * runtime/JSONObject.cpp:
2097         (JSC::Stringifier::appendStringifiedValue):
2098
2099 2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>
2100
2101         ToT WebKit crashes while loading ES6 compatibility table
2102         https://bugs.webkit.org/show_bug.cgi?id=144726
2103
2104         Reviewed by Filip Pizlo.
2105
2106         The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
2107
2108         Always build the identifier here as it could be a method name.
2109
2110         * parser/Parser.cpp:
2111         (JSC::Parser<LexerType>::parseClass):
2112
2113 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2114
2115         Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
2116         https://bugs.webkit.org/show_bug.cgi?id=144665
2117
2118         Reviewed by Michael Saboff.
2119         
2120         This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
2121         extending SaneChain to all indexing shapes.
2122
2123         * dfg/DFGFixupPhase.cpp:
2124         (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2125         (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
2126         * dfg/DFGSpeculativeJIT.cpp:
2127         (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2128         * dfg/DFGWatchpointCollectionPhase.cpp:
2129         (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
2130         (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
2131         * ftl/FTLLowerDFGToLLVM.cpp:
2132         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2133
2134 2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>
2135
2136         Introducing the Platform Abstraction Layer (PAL)
2137         https://bugs.webkit.org/show_bug.cgi?id=143358
2138
2139         Reviewed by Simon Fraser.
2140
2141         * Configurations/FeatureDefines.xcconfig: Updated
2142
2143 2015-05-06  Andreas Kling  <akling@apple.com>
2144
2145         Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
2146         <https://webkit.org/b/144676>
2147
2148         Reviewed by Darin Adler.
2149
2150         We were creating a new String for every number JSValue passing through the JSON stringifier.
2151         These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
2152         Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
2153         for the conversion instead.
2154
2155         13% progression on Kraken/json-stringify-tinderbox.
2156
2157         * runtime/JSONObject.cpp:
2158         (JSC::Stringifier::appendStringifiedValue):
2159
2160 2015-05-06  Commit Queue  <commit-queue@webkit.org>
2161
2162         Unreviewed, rolling out r183847.
2163         https://bugs.webkit.org/show_bug.cgi?id=144691
2164
2165         Caused many assertion failures (Requested by ap on #webkit).
2166
2167         Reverted changeset:
2168
2169         "GC has trouble with pathologically large array allocations"
2170         https://bugs.webkit.org/show_bug.cgi?id=144609
2171         http://trac.webkit.org/changeset/183847
2172
2173 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2174
2175         PutGlobalVar shouldn't have an unconditional store barrier
2176         https://bugs.webkit.org/show_bug.cgi?id=133104
2177
2178         Reviewed by Benjamin Poulain.
2179         
2180         We don't need a store barrier on PutGlobalVar if the value being stored can be
2181         speculated to not be a cell.
2182
2183         * dfg/DFGFixupPhase.cpp:
2184         (JSC::DFG::FixupPhase::fixupNode):
2185
2186 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2187
2188         CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
2189         https://bugs.webkit.org/show_bug.cgi?id=144667
2190
2191         Reviewed by Andreas Kling.
2192         
2193         We are now calling this method for oversize blocks. It had an assertion that indirectly
2194         implied that the block is not oversize, because it was claiming that the number of live
2195         bytes should be smaller than the non-oversize-block size.
2196
2197         * heap/CopiedBlockInlines.h:
2198         (JSC::CopiedBlock::reportLiveBytes):
2199
2200 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2201
2202         GC has trouble with pathologically large array allocations
2203         https://bugs.webkit.org/show_bug.cgi?id=144609
2204
2205         Reviewed by Mark Lam.
2206
2207         * heap/Heap.cpp:
2208         (JSC::Heap::updateObjectCounts): Make this code less confusing.
2209         * heap/SlotVisitorInlines.h:
2210         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
2211         * jsc.cpp: Add size measuring hooks to write the largeish test.
2212         (GlobalObject::finishCreation):
2213         (functionGCAndSweep):
2214         (functionFullGC):
2215         (functionEdenGC):
2216         (functionHeapSize):
2217         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
2218         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
2219         (foo):
2220         (test):
2221
2222 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2223
2224         FTL SwitchString slow case creates duplicate switch cases
2225         https://bugs.webkit.org/show_bug.cgi?id=144634
2226
2227         Reviewed by Geoffrey Garen.
2228         
2229         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
2230         added mostly-debug-only asserts to catch such issues earlier.
2231
2232         * bytecode/CallVariant.cpp:
2233         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
2234         * ftl/FTLLowerDFGToLLVM.cpp:
2235         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
2236         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
2237         * jit/BinarySwitch.cpp:
2238         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
2239         * jit/Repatch.cpp:
2240         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
2241         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
2242         (foo):
2243         (cat):
2244
2245 2015-05-05  Basile Clement  <basile_clement@apple.com>
2246
2247         Fix debug builds after r183812
2248         https://bugs.webkit.org/show_bug.cgi?id=144300
2249
2250         Rubber stamped by Andreas Kling and Filip Pizlo.
2251
2252         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
2253         as having materialization data, which was causing an assertion failure when
2254         sinking CreateActivations on debug builds.
2255
2256         * dfg/DFGNode.h:
2257         (JSC::DFG::Node::hasObjectMaterializationData):
2258
2259 2015-05-04  Basile Clement  <basile_clement@apple.com>
2260
2261         Allow CreateActivation sinking
2262         https://bugs.webkit.org/show_bug.cgi?id=144300
2263
2264         Reviewed by Filip Pizlo.
2265
2266         This pursues the work started in
2267         https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
2268         allocations we are able to sink by allowing sinking of CreateActivation
2269         node.
2270
2271         This is achieved by following closely the way NewObject is currently
2272         sunk: we add a new PhantomCreateActivation node to record the initial
2273         position of the CreateActivation node, new ClosureVarPLoc promoted heap
2274         locations to keep track of the variables put in the activation, and a
2275         new MaterializeCreateActivation node to allocate and populate the sunk
2276         activation.
2277
2278         * dfg/DFGAbstractInterpreterInlines.h:
2279         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2280         * dfg/DFGClobberize.h:
2281         (JSC::DFG::clobberize):
2282         * dfg/DFGDoesGC.cpp:
2283         (JSC::DFG::doesGC):
2284         * dfg/DFGFixupPhase.cpp:
2285         (JSC::DFG::FixupPhase::fixupNode):
2286         * dfg/DFGNode.cpp:
2287         (JSC::DFG::Node::convertToPutClosureVarHint):
2288         * dfg/DFGNode.h:
2289         (JSC::DFG::Node::convertToPhantomCreateActivation):
2290         (JSC::DFG::Node::isActivationAllocation):
2291         (JSC::DFG::Node::isPhantomActivationAllocation):
2292         (JSC::DFG::Node::isPhantomAllocation):
2293         * dfg/DFGNodeType.h:
2294         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2295         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2296         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2297         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2298         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2299         * dfg/DFGPredictionPropagationPhase.cpp:
2300         (JSC::DFG::PredictionPropagationPhase::propagate):
2301         * dfg/DFGPromotedHeapLocation.cpp:
2302         (WTF::printInternal):
2303         * dfg/DFGPromotedHeapLocation.h:
2304         * dfg/DFGSafeToExecute.h:
2305         (JSC::DFG::safeToExecute):
2306         * dfg/DFGSpeculativeJIT32_64.cpp:
2307         (JSC::DFG::SpeculativeJIT::compile):
2308         * dfg/DFGSpeculativeJIT64.cpp:
2309         (JSC::DFG::SpeculativeJIT::compile):
2310         * dfg/DFGValidate.cpp:
2311         (JSC::DFG::Validate::validateCPS):
2312         * ftl/FTLCapabilities.cpp:
2313         (JSC::FTL::canCompile):
2314         * ftl/FTLLowerDFGToLLVM.cpp:
2315         (JSC::FTL::LowerDFGToLLVM::compileNode):
2316         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
2317         * ftl/FTLOperations.cpp:
2318         (JSC::FTL::operationMaterializeObjectInOSR):
2319         * tests/stress/activation-sink-osrexit.js: Added.
2320         (bar):
2321         (foo.set result):
2322         * tests/stress/activation-sink.js: Added.
2323         (bar):
2324
2325 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2326
2327         Unreviewed, fix stale comment.
2328
2329         * tests/mozilla/js1_5/Array/regress-101964.js:
2330
2331 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2332
2333         Large array shouldn't be slow
2334         https://bugs.webkit.org/show_bug.cgi?id=144617
2335
2336         Rubber stamped by Mark Lam.
2337
2338         * tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.
2339
2340 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2341
2342         Large array shouldn't be slow
2343         https://bugs.webkit.org/show_bug.cgi?id=144617
2344
2345         Rubber stamped by Mark Lam.
2346
2347         * tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.
2348
2349 2015-05-04  Commit Queue  <commit-queue@webkit.org>
2350
2351         Unreviewed, rolling out r183789.
2352         https://bugs.webkit.org/show_bug.cgi?id=144620
2353
2354         Causing flakiness on exceptionFuzz tests locally on 32-bit
2355         build (Requested by saamyjoon on #webkit).
2356
2357         Reverted changeset:
2358
2359         "Global functions should be initialized as JSFunctions in byte
2360         code"
2361         https://bugs.webkit.org/show_bug.cgi?id=144178
2362         http://trac.webkit.org/changeset/183789
2363
2364 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2365
2366         Global functions should be initialized as JSFunctions in byte code
2367         https://bugs.webkit.org/show_bug.cgi?id=144178
2368
2369         Reviewed by Geoffrey Garen.
2370
2371         This patch makes the initialization of global functions more explicit by
2372         moving initialization into bytecode. It also prepares JSC for having ES6
2373         style lexical scoping because initializing global functions in bytecode
2374         easily allows global functions to be initialized with the proper scope that
2375         will have access to global lexical variables. Global lexical variables
2376         should be visible to global functions but don't live on the global object.
2377
2378         * bytecode/UnlinkedCodeBlock.cpp:
2379         (JSC::UnlinkedProgramCodeBlock::visitChildren):
2380         * bytecode/UnlinkedCodeBlock.h:
2381         * bytecompiler/BytecodeGenerator.cpp:
2382         (JSC::BytecodeGenerator::generate):
2383         (JSC::BytecodeGenerator::BytecodeGenerator):
2384         * bytecompiler/BytecodeGenerator.h:
2385         * runtime/Executable.cpp:
2386         (JSC::ProgramExecutable::initializeGlobalProperties):
2387         * runtime/JSGlobalObject.cpp:
2388         (JSC::JSGlobalObject::addGlobalVar):
2389         (JSC::JSGlobalObject::addFunction):
2390         * runtime/JSGlobalObject.h:
2391
2392 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2393
2394         Large array shouldn't be slow
2395         https://bugs.webkit.org/show_bug.cgi?id=144617
2396
2397         Reviewed by Geoffrey Garen.
2398         
2399         Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
2400         you're already using ArrayStorage mode, from the minimul array length required to use
2401         ArrayStorage in a new Array(length) allocation.
2402         
2403         Lift the array allocation length threshold to something very high. If this works, we'll
2404         probably remove that threshold entirely.
2405         
2406         This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
2407         JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
2408         for now.
2409
2410         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2411         * dfg/DFGSpeculativeJIT32_64.cpp:
2412         (JSC::DFG::SpeculativeJIT::compile):
2413         * dfg/DFGSpeculativeJIT64.cpp:
2414         (JSC::DFG::SpeculativeJIT::compile):
2415         * ftl/FTLLowerDFGToLLVM.cpp:
2416         (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
2417         * runtime/ArrayConventions.h:
2418         * runtime/JSArray.h:
2419         (JSC::JSArray::create):
2420         * runtime/JSGlobalObject.h:
2421         (JSC::constructEmptyArray):
2422         * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
2423
2424 2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2425
2426         Add backed intrinsics to private functions exposed with private symbols in global object
2427         https://bugs.webkit.org/show_bug.cgi?id=144545
2428
2429         Reviewed by Darin Adler.
2430
2431         Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
2432         This patch adds intrinsic to private functions exposed with private symbols in global object,
2433         @floor and @abs.
2434
2435         * runtime/JSGlobalObject.cpp:
2436         (JSC::JSGlobalObject::init):
2437         * runtime/JSGlobalObjectFunctions.cpp:
2438         (JSC::globalPrivateFuncAbs): Deleted.
2439         (JSC::globalPrivateFuncFloor): Deleted.
2440         * runtime/MathObject.cpp:
2441         * runtime/MathObject.h:
2442         * tests/stress/array-from-abs-and-floor.js: Added.
2443         (target1):
2444         (target2):
2445         (target3):
2446
2447 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2448
2449         [cmake] ARM related build system cleanup
2450         https://bugs.webkit.org/show_bug.cgi?id=144566
2451
2452         Reviewed by Darin Adler.
2453
2454         * CMakeLists.txt:
2455
2456 2015-05-04  Andreas Kling  <akling@apple.com>
2457
2458         Optimize WeakBlock's "reap" and "visit" operations.
2459         <https://webkit.org/b/144585>
2460
2461         Reviewed by Geoffrey Garen.
2462
2463         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
2464         That function was really written with conservative roots marking in mind, and will do a bunch
2465         of sanity and bounds checks.
2466
2467         For weaks, we know that the pointer will have been a valid cell pointer into a block
2468         of appropriate cell size, so we can skip a lot of the checks.
2469
2470         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
2471         MarkedBlock::blockFor() for every single cell when iterating.
2472
2473         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
2474         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
2475         be pointing to any live cells, and the only operation that will run on the block is sweep().
2476
2477         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
2478         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
2479         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
2480
2481         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
2482         what looks like a 1% speedup locally.
2483
2484         * heap/MarkedBlock.cpp:
2485         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
2486
2487         * heap/MarkedBlock.h:
2488         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
2489         block's state is known to be either Marked or Retired.
2490
2491         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
2492         would report that all cells are live anyway.
2493
2494         * heap/WeakBlock.cpp:
2495         (JSC::WeakBlock::create):
2496         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
2497
2498         (JSC::WeakBlock::visit):
2499         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
2500
2501         * heap/WeakBlock.h:
2502         (JSC::WeakBlock::disconnectMarkedBlock): Added.
2503         * heap/WeakSet.cpp:
2504         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
2505         ownership to Heap until it can die peacefully.
2506
2507         (JSC::WeakSet::addAllocator):
2508         * heap/WeakSet.h:
2509         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
2510
2511 2015-05-04  Basile Clement  <basile_clement@apple.com>
2512
2513         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
2514         https://bugs.webkit.org/show_bug.cgi?id=144587
2515
2516         Rubber stamped by Filip Pizlo.
2517
2518         When sinking object allocations, we ensure in
2519         determineMaterializationPoints that whenever an allocation is
2520         materialized on a path to a block, it is materialized in all such
2521         paths. Thus when running the SSA calculator to place Phis in
2522         placeMaterializationPoints, we can't encounter a situation where some
2523         Upsilons are referring to a materialization while others are referring
2524         to the phantom object.
2525
2526         This replaces the code that was adding a materialization late in
2527         placeMaterializationPoints to handle that case by an assertion that it
2528         does not happen, which will make
2529         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
2530
2531         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2532         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2533
2534 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2535
2536         Extending undefined in class syntax should throw a TypeError
2537         https://bugs.webkit.org/show_bug.cgi?id=144284
2538
2539         Reviewed by Darin Adler.
2540
2541         The bug was caused by op_eq_null evaluating to true when compared to undefined.
2542         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
2543
2544         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
2545
2546         * bytecompiler/NodesCodegen.cpp:
2547         (JSC::ClassExprNode::emitBytecode):
2548
2549 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2550
2551         new super should be a syntax error
2552         https://bugs.webkit.org/show_bug.cgi?id=144282
2553
2554         Reviewed by Joseph Pecoraro.
2555
2556         Disallow "new super" as ES6 spec doesn't allow this.
2557
2558         * parser/Parser.cpp:
2559         (JSC::Parser<LexerType>::parseMemberExpression):
2560
2561 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2562
2563         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
2564         https://bugs.webkit.org/show_bug.cgi?id=144265
2565
2566         Reviewed by Geoffrey Garen.
2567
2568         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
2569         for a static function if the parent has that property slot. JSCallbackObject::put 
2570         did not maintain this symmetry of also calling ::put on the parent if the parent 
2571         has the property. We should ensure that this symmetry exists.
2572
2573         * API/JSCallbackObjectFunctions.h:
2574         (JSC::JSCallbackObject<Parent>::put):
2575         * API/tests/testapi.c:
2576         * API/tests/testapi.js:
2577         (globalStaticFunction2):
2578         (this.globalStaticFunction2):
2579         (iAmNotAStaticFunction):
2580         (this.iAmNotAStaticFunction):
2581
2582 2015-05-04  Andreas Kling  <akling@apple.com>
2583
2584         Make ExecState::vm() branchless in release builds.
2585         <https://webkit.org/b/144586>
2586
2587         Reviewed by Geoffrey Garen.
2588
2589         Avoid null checking the ExecState's callee() before getting the
2590         VM from it. The code was already dereferencing it anyway, since we
2591         know it's not gonna be null.
2592
2593         * runtime/JSCellInlines.h:
2594         (JSC::ExecState::vm):
2595
2596 2015-05-04  Basile Clement  <basile_clement@apple.com>
2597
2598         Object allocation not sinking properly through CheckStructure
2599         https://bugs.webkit.org/show_bug.cgi?id=144465
2600
2601         Reviewed by Filip Pizlo.
2602
2603         Currently, sinking an allocation through a CheckStructure will
2604         completely ignore all structure checking, which is obviously wrong.
2605
2606         A CheckStructureImmediate node type was present for that purpose, but
2607         the CheckStructures were not properly replaced.  This ensures that
2608         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
2609         sunk through, and that structure checking happens correctly.
2610
2611         * dfg/DFGNode.h:
2612         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
2613         (JSC::DFG::Node::hasStructureSet):
2614         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2615         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2616         * ftl/FTLLowerDFGToLLVM.cpp:
2617         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
2618         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
2619         (JSC::FTL::LowerDFGToLLVM::checkStructure):
2620         * tests/stress/sink_checkstructure.js: Added.
2621         (foo):
2622
2623 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
2624
2625         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
2626         https://bugs.webkit.org/show_bug.cgi?id=144476
2627
2628         Reviewed by Sam Weinig.
2629
2630         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
2631
2632         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
2633         to my knowledge, the topic of how to optimize it is not covered in any
2634         literature about sorting.
2635
2636         On the slowest jQuery sorting test -- prevAll -- our new
2637         Array.prototype.sort, compared to its predecessor, performed 12% fewer
2638         comparisons and requireed 10X less overhead per comparison. Yet, it was
2639         slower.
2640
2641         It was slower because it inadvertantly increased the average cost of the
2642         comparison function by 2X. jQuery uses compareDocumentPosition to compare
2643         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
2644         required to traverse backwards from b to a. In prevAll, we encounter the
2645         worst case for merge sort of compareDocumentPosition: A long list of DOM
2646         nodes in mostly reverse order. In this case, merge sort will sequentially
2647         compareDocumentPosition(a, b), where a is not reachable backwards from
2648         b, and therefore compareDocumentPosition will traverse the whole sibling
2649         list.
2650
2651         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
2652
2653         This is a pretty silly thing to do, but it is harmless, and jQuery is
2654         popular, so let's do it.
2655
2656         We do not risk suffering the same problem in reverse when sorting a long
2657         list of DOM nodes in forward order. (We still have a 37% speedup on the
2658         nextAll benchmark.) The reason is that merge sort performs 2X fewer
2659         comparisons when the list is already sorted, so we can worry less about
2660         the cost of each comparison.
2661
2662         A fully principled soultion to this problem would probably do something
2663         like Python's timsort, which special-cases ordered ranges to perform
2664         only O(n) comparisons. But that would contradict our original
2665         goal of just having something simple that works.
2666
2667         Another option is for elements to keep a compareDocumentPosition cache,
2668         like a node list cache, which allows you to determine the absolute
2669         position of a node using a hash lookup. I will leave this as an exercise
2670         for kling.
2671
2672         * builtins/Array.prototype.js:
2673         (sort.merge): Compare in an order that is favorable to a comparator
2674         that calls compareDocumentPosition.
2675
2676 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2677
2678         [cmake] Fix generate-js-builtins related incremental build issue
2679         https://bugs.webkit.org/show_bug.cgi?id=144094
2680
2681         Reviewed by Michael Saboff.
2682
2683         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
2684         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2685         * DerivedSources.make:
2686         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2687         * generate-js-builtins: Accept input files and input directory too.
2688
2689 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
2690
2691         Make some static data const
2692         https://bugs.webkit.org/show_bug.cgi?id=144552
2693
2694         Reviewed by Andreas Kling.
2695         
2696         Turn characterSetInfo into const data.
2697
2698         * yarr/YarrCanonicalizeUCS2.cpp:
2699         * yarr/YarrCanonicalizeUCS2.h:
2700
2701 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2702
2703         TypeOf should be fast
2704         https://bugs.webkit.org/show_bug.cgi?id=144396
2705
2706         Reviewed by Geoffrey Garen.
2707         
2708         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
2709         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
2710         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
2711         
2712         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
2713         rely heavily on C++ calls to fulfill their function.
2714         
2715         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
2716         
2717         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
2718         This means that if the TypeOf is dominated by any type checks, we will automatically prune
2719         out cases that are redundant.
2720         
2721         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
2722         code generation is designed to be reusable.
2723         
2724         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
2725         the exotic call trap hook. That hook is now in a deeper slow path than before.
2726
2727         * CMakeLists.txt:
2728         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2729         * JavaScriptCore.xcodeproj/project.pbxproj:
2730         * dfg/DFGClobberize.h:
2731         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
2732         * dfg/DFGFixupPhase.cpp:
2733         (JSC::DFG::FixupPhase::fixupNode):
2734         * dfg/DFGHeapLocation.cpp:
2735         (WTF::printInternal):
2736         * dfg/DFGHeapLocation.h:
2737         * dfg/DFGOperations.cpp:
2738         * dfg/DFGOperations.h:
2739         * dfg/DFGSpeculativeJIT.cpp:
2740         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
2741         (JSC::DFG::SpeculativeJIT::compileIsFunction):
2742         (JSC::DFG::SpeculativeJIT::compileTypeOf):
2743         * dfg/DFGSpeculativeJIT.h:
2744         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
2745         (JSC::DFG::SpeculativeJIT::callOperation):
2746         * dfg/DFGSpeculativeJIT32_64.cpp:
2747         (JSC::DFG::SpeculativeJIT::compile):
2748         * dfg/DFGSpeculativeJIT64.cpp:
2749         (JSC::DFG::SpeculativeJIT::compile):
2750         * ftl/FTLCapabilities.cpp:
2751         (JSC::FTL::canCompile):
2752         * ftl/FTLIntrinsicRepository.h:
2753         * ftl/FTLLowerDFGToLLVM.cpp:
2754         (JSC::FTL::LowerDFGToLLVM::compileNode):
2755         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
2756         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
2757         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
2758         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
2759         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
2760         * ftl/FTLSwitchCase.h:
2761         (JSC::FTL::SwitchCase::SwitchCase):
2762         * jit/AssemblyHelpers.h:
2763         (JSC::AssemblyHelpers::branchIfNotEqual):
2764         (JSC::AssemblyHelpers::branchIfEqual):
2765         (JSC::AssemblyHelpers::branchIfNumber):
2766         (JSC::AssemblyHelpers::branchIfNotNumber):
2767         (JSC::AssemblyHelpers::branchIfBoolean):
2768         (JSC::AssemblyHelpers::branchIfNotBoolean):
2769         (JSC::AssemblyHelpers::boxBooleanPayload):
2770         (JSC::AssemblyHelpers::boxBoolean):
2771         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
2772         * jit/JITOperations.h:
2773         * runtime/SmallStrings.h:
2774         (JSC::SmallStrings::typeString):
2775         * runtime/TypeofType.cpp: Added.
2776         (WTF::printInternal):
2777         * runtime/TypeofType.h: Added.
2778         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
2779
2780 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2781
2782         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
2783
2784         * dfg/DFGLICMPhase.cpp:
2785         (JSC::DFG::LICMPhase::attemptHoist):
2786
2787 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2788
2789         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
2790         https://bugs.webkit.org/show_bug.cgi?id=144525.
2791
2792         * dfg/DFGLICMPhase.cpp:
2793         (JSC::DFG::LICMPhase::attemptHoist):
2794         * dfg/DFGPhantomInsertionPhase.cpp:
2795
2796 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2797
2798         Static property hashtable should only lookup with non-symbol key
2799         https://bugs.webkit.org/show_bug.cgi?id=144438
2800
2801         Reviewed by Darin Adler.
2802
2803         Static property hashtable compares the Identifier's uid
2804         with the normal C string without interning it.
2805         So this comparison is performed in their contents.
2806         As the result, in this comparison, symbol-ness is not considered.
2807
2808         So if accidentally the hash collision occur with the symbol and the string
2809         and they have the same contents, the hash table entry is looked up incorrectly.
2810
2811         * runtime/Lookup.h:
2812         (JSC::HashTable::entry):
2813
2814 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
2815
2816         Class syntax should allow string and numeric identifiers for method names
2817         https://bugs.webkit.org/show_bug.cgi?id=144254
2818
2819         Reviewed by Darin Adler.
2820
2821         Added the support for string and numeric identifiers in class syntax.
2822
2823         * parser/Parser.cpp:
2824         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
2825         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
2826         outside a class constructor as it should be.
2827         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2828         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
2829         element to allow numeric and string method names. For both of those method names, parse it here instead
2830         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
2831         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
2832         this function is never used to parse a class method.
2833         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
2834         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
2835         * parser/Parser.h:
2836         * parser/SyntaxChecker.h:
2837         (JSC::SyntaxChecker::createProperty):
2838
2839 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2840
2841         FTL should use AI more
2842         https://bugs.webkit.org/show_bug.cgi?id=144500
2843
2844         Reviewed by Oliver Hunt.
2845         
2846         This makes our type check folding even more comprehensive by ensuring that even if the FTL
2847         decides to emit some checks, it will still do another query to the abstract interpreter to
2848         see if the check is necessary. This helps with cases where we decided early on to speculate
2849         one way, but later proved a more specific type of the value in question, and the constant
2850         folder didn't catch it.
2851         
2852         This also makes it more natural to query the abstract interpreter. For example, if you just
2853         want the proven type, you can now say provenType(node) or provenType(edge).
2854
2855         * dfg/DFGArrayMode.cpp:
2856         (JSC::DFG::ArrayMode::alreadyChecked):
2857         * dfg/DFGArrayMode.h:
2858         * ftl/FTLLowerDFGToLLVM.cpp:
2859         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
2860         (JSC::FTL::LowerDFGToLLVM::compileToThis):
2861         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
2862         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
2863         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
2864         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2865         (JSC::FTL::LowerDFGToLLVM::compileGetById):
2866         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
2867         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
2868         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
2869         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
2870         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
2871         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
2872         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
2873         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
2874         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
2875         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
2876         (JSC::FTL::LowerDFGToLLVM::compileIsString):
2877         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
2878         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
2879         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
2880         (JSC::FTL::LowerDFGToLLVM::baseIndex):
2881         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
2882         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
2883         (JSC::FTL::LowerDFGToLLVM::boolify):
2884         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
2885         (JSC::FTL::LowerDFGToLLVM::lowInt32):
2886         (JSC::FTL::LowerDFGToLLVM::lowInt52):
2887         (JSC::FTL::LowerDFGToLLVM::lowCell):
2888         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
2889         (JSC::FTL::LowerDFGToLLVM::lowDouble):
2890         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
2891         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
2892         (JSC::FTL::LowerDFGToLLVM::isNumber):
2893         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
2894         (JSC::FTL::LowerDFGToLLVM::isNotCell):
2895         (JSC::FTL::LowerDFGToLLVM::isCell):
2896         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
2897         (JSC::FTL::LowerDFGToLLVM::isMisc):
2898         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
2899         (JSC::FTL::LowerDFGToLLVM::isBoolean):
2900         (JSC::FTL::LowerDFGToLLVM::isNotOther):
2901         (JSC::FTL::LowerDFGToLLVM::isOther):
2902         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
2903         (JSC::FTL::LowerDFGToLLVM::isObject):
2904         (JSC::FTL::LowerDFGToLLVM::isNotObject):
2905         (JSC::FTL::LowerDFGToLLVM::isNotString):
2906         (JSC::FTL::LowerDFGToLLVM::isString):
2907         (JSC::FTL::LowerDFGToLLVM::isFunction):
2908         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
2909         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
2910         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
2911         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
2912         (JSC::FTL::LowerDFGToLLVM::abstractValue):
2913         (JSC::FTL::LowerDFGToLLVM::provenType):
2914         (JSC::FTL::LowerDFGToLLVM::provenValue):
2915         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
2916
2917 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
2918
2919         USE(...) macro should expect unprefixed variables
2920         https://bugs.webkit.org/show_bug.cgi?id=144454
2921
2922         Reviewed by Daniel Bates.
2923
2924         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
2925
2926 2015-05-01  Jordan Harband  <ljharb@gmail.com>
2927
2928         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
2929         https://bugs.webkit.org/show_bug.cgi?id=144314
2930
2931         Reviewed by Darin Adler.
2932
2933         Fixing handling of Infinity position args, per
2934         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
2935         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
2936         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
2937
2938         * runtime/StringPrototype.cpp:
2939         (JSC::clampInt32):
2940         (JSC::stringProtoFuncStartsWith):
2941         (JSC::stringProtoFuncEndsWith):
2942         (JSC::stringProtoFuncIncludes):
2943
2944 2015-05-01  Basile Clement  <basile_clement@apple.com>
2945
2946         Math.abs() returns negative
2947         https://bugs.webkit.org/show_bug.cgi?id=137827
2948
2949         Reviewed by Michael Saboff.
2950
2951         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
2952         identity function.
2953
2954         * dfg/DFGAbstractInterpreterInlines.h:
2955         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2956         * tests/stress/math-abs-positive.js: Added, was previously failing.
2957         (foo):
2958
2959 2015-05-01  Basile Clement  <basile_clement@apple.com>
2960
2961         Function allocation sinking shouldn't be performed on singleton functions
2962         https://bugs.webkit.org/show_bug.cgi?id=144166
2963
2964         Reviewed by Geoffrey Garen.
2965
2966         Function allocations usually are free of any other side effects, but
2967         this is not the case for allocations performed while the underlying
2968         FunctionExecutable is still a singleton (as this allogation will fire
2969         watchpoints invalidating code that depends on it being a singleton).
2970         As the object allocation sinking phase assumes object allocation is
2971         free of side-effects, sinking these allocations is not correct.
2972
2973         This also means that when materializing a function allocation on OSR
2974         exit, that function's executable will never be a singleton, and we don't have
2975         to worry about its watchpoint, allowing us to use
2976         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
2977         JSFunction::create.
2978
2979         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2980         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2981         * ftl/FTLOperations.cpp:
2982         (JSC::FTL::operationMaterializeObjectInOSR):
2983
2984 2015-04-30  Jon Davis  <jond@apple.com>
2985
2986         Web Inspector: console should show an icon for console.info() messages
2987         https://bugs.webkit.org/show_bug.cgi?id=18530
2988
2989         Reviewed by Timothy Hatcher.
2990
2991         * inspector/ConsoleMessage.cpp:
2992         (Inspector::messageLevelValue):
2993         * inspector/protocol/Console.json:
2994         * runtime/ConsoleClient.cpp:
2995         (JSC::appendMessagePrefix):
2996         * runtime/ConsolePrototype.cpp:
2997         (JSC::ConsolePrototype::finishCreation):
2998         (JSC::consoleProtoFuncInfo):
2999         * runtime/ConsoleTypes.h:
3000
3001 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3002
3003         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
3004         https://bugs.webkit.org/show_bug.cgi?id=144462
3005
3006         Reviewed by Geoffrey Garen and Mark Lam.
3007         
3008         At some point we started adding representation-agnostic helpers for doing common type tests.
3009         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
3010         they had overlapping powers, though SpeculativeJIT was a bit better.
3011         
3012         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
3013         better because now all of these helpers can be used in all of the assembly-based JITs, not
3014         just the DFG. It also settles on what I find to be a slightly better naming convention.
3015         For example where we previously would have said branchIsString, now we say
3016         branchIfString. Similarly, branchNotString becomes branchIfNotString.
3017
3018         * dfg/DFGSpeculativeJIT.cpp:
3019         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
3020         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3021         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
3022         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
3023         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
3024         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
3025         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
3026         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
3027         (JSC::DFG::SpeculativeJIT::speculateObject):
3028         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
3029         (JSC::DFG::SpeculativeJIT::speculateString):
3030         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
3031         (JSC::DFG::SpeculativeJIT::speculateNotCell):
3032         (JSC::DFG::SpeculativeJIT::speculateOther):
3033         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
3034         (JSC::DFG::SpeculativeJIT::emitSwitchString):
3035         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
3036         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
3037         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
3038         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
3039         * dfg/DFGSpeculativeJIT.h:
3040         * dfg/DFGSpeculativeJIT32_64.cpp:
3041         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3042         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3043         (JSC::DFG::SpeculativeJIT::emitCall):
3044         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
3045         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3046         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3047         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3048         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3049         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3050         (JSC::DFG::SpeculativeJIT::compile):
3051         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
3052         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
3053         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
3054         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
3055         * dfg/DFGSpeculativeJIT64.cpp:
3056         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3057         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3058         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
3059         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3060         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3061         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3062         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3063         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3064         (JSC::DFG::SpeculativeJIT::compile):
3065         (JSC::DFG::SpeculativeJIT::writeBarrier):
3066         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
3067         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
3068         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
3069         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
3070         * jit/AssemblyHelpers.h:
3071         (JSC::AssemblyHelpers::branchIfCell):
3072         (JSC::AssemblyHelpers::branchIfOther):
3073         (JSC::AssemblyHelpers::branchIfNotOther):
3074         (JSC::AssemblyHelpers::branchIfObject):
3075         (JSC::AssemblyHelpers::branchIfNotObject):
3076         (JSC::AssemblyHelpers::branchIfType):
3077         (JSC::AssemblyHelpers::branchIfNotType):
3078         (JSC::AssemblyHelpers::branchIfString):
3079         (JSC::AssemblyHelpers::branchIfNotString):
3080         (JSC::AssemblyHelpers::branchIfSymbol):
3081         (JSC::AssemblyHelpers::branchIfNotSymbol):
3082         (JSC::AssemblyHelpers::branchIfFunction):
3083         (JSC::AssemblyHelpers::branchIfNotFunction):
3084         (JSC::AssemblyHelpers::branchIfEmpty):
3085         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
3086         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
3087         * jit/JITPropertyAccess.cpp:
3088         (JSC::JIT::emitScopedArgumentsGetByVal):
3089
3090 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3091
3092         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
3093         https://bugs.webkit.org/show_bug.cgi?id=144463
3094
3095         Reviewed by Benjamin Poulain.
3096         
3097         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
3098         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
3099         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
3100         converting the boolean into an integer. But as part of doing that, it would try to
3101         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
3102         and it would try to figure out if the addition might overflow. Part of that logic
3103         involved checking if the immediate is either a boolean or a sufficiently small integer.
3104         But: it would check if it's a sufficiently small integer before checking if it was a
3105         boolean, so it would try to call asNumber() on the boolean.
3106         
3107         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
3108         case was previously never hit until I wrote these tests, and so we never knew that
3109         calling asNumber() on a boolean was wrong.
3110         
3111         The fix is super simple: the expression should just check for boolean first.
3112         
3113         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
3114         garbage, and that's OK, since we'd take the boolean case anyway.
3115
3116         * dfg/DFGGraph.h:
3117         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
3118
3119 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3120
3121         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
3122
3123         * jit/JITOperations.cpp:
3124
3125 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3126
3127         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
3128         particular that they cannot change their minds and may be called from compiler threads.
3129
3130         Rubber stamped by Geoffrey Garen.
3131
3132         * runtime/JSCell.h:
3133
3134 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
3135
3136         DFG Is<Blah> versions of TypeOf should fold based on proven input type
3137         https://bugs.webkit.org/show_bug.cgi?id=144409
3138
3139         Reviewed by Geoffrey Garen.
3140         
3141         We were missing some obvious folding opportunities here. I don't know how this affects real
3142         code, but in general, we like to ensure that our constant folding is comprehensive. So this
3143         is more about placating my static analysis OCD than anything else.
3144         
3145         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
3146
3147         * dfg/DFGAbstractInterpreterInlines.h:
3148         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3149
3150 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3151
3152         Use the default hash value for Symbolized StringImpl
3153         https://bugs.webkit.org/show_bug.cgi?id=144347
3154
3155         Reviewed by Darin Adler.
3156
3157         Before this patch, symbolized StringImpl* has a special hash value
3158         to avoid the hash collision with the other normal StringImpl*.
3159         I guess that it is introduced when private symbols are introduced.
3160         However, it prevents using symbolized StringImpl* in the other place
3161         For example, using it as WTFString cause a problem because of its special hash value.
3162
3163         When only using private symbols, they are not exposed to the outside of JSC,
3164         so we can handle it carefully. But now, it's extended to symbols.
3165         So I think storing a special hash value in StringImpl* causes an error.
3166
3167         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
3168         And to provide significantly different hash value when using it as symbol,
3169         store the additional hash value in symbolized StringImpl*. It is used when
3170         the hash value is required by IdentifierRepHash.
3171
3172         * runtime/Identifier.h:
3173         (JSC::IdentifierRepHash::hash):
3174         * runtime/Lookup.h:
3175         (JSC::HashTable::entry):
3176         * runtime/PropertyMapHashTable.h:
3177         (JSC::PropertyTable::find):
3178         (JSC::PropertyTable::get):
3179         * runtime/Structure.cpp:
3180         (JSC::PropertyTable::checkConsistency):
3181
3182 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
3183
3184         [JSC] Remove RageConvert array conversion
3185         https://bugs.webkit.org/show_bug.cgi?id=144433
3186
3187         Reviewed by Filip Pizlo.
3188
3189         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
3190         pretty hard:
3191         -The indexing types shows that the array access varies between Int32 and DoubleArray.
3192         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
3193          An Arrayify node would convert the Int32 to that type.
3194         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
3195          node would use RageConvert instead of Convert.
3196         -The Arrayify for that GetByVal with RageConvert would not convert the array to
3197          Contiguous.
3198         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
3199          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
3200          fail systematically and we never get to run the later code.
3201
3202         Getting rid of RageConvert fixes the problem and does not seems to have any
3203         negative side effect on other benchmarks.
3204
3205         The improvments on Kraken are:
3206             -stanford-crypto-aes: definitely 1.0915x faster.
3207             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
3208             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
3209
3210         * dfg/DFGAbstractInterpreterInlines.h:
3211         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3212         * dfg/DFGArrayMode.cpp:
3213         (JSC::DFG::ArrayMode::refine):
3214         (JSC::DFG::arrayConversionToString):
3215         * dfg/DFGArrayMode.h:
3216         * dfg/DFGArrayifySlowPathGenerator.h:
3217         * dfg/DFGFixupPhase.cpp:
3218         (JSC::DFG::FixupPhase::fixupNode):
3219         * dfg/DFGOperations.cpp:
3220         * dfg/DFGOperations.h:
3221         * dfg/DFGPredictionPropagationPhase.cpp:
3222         (JSC::DFG::PredictionPropagationPhase::propagate):
3223         * dfg/DFGTypeCheckHoistingPhase.cpp:
3224         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
3225         * ftl/FTLLowerDFGToLLVM.cpp:
3226         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
3227         * runtime/JSObject.cpp:
3228         (JSC::JSObject::convertDoubleToContiguous):
3229         (JSC::JSObject::ensureContiguousSlow):
3230         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
3231         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
3232         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
3233         * runtime/JSObject.h:
3234         (JSC::JSObject::rageEnsureContiguous): Deleted.
3235
3236 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
3237
3238         Gracefully handle missing auto pause key on remote inspector setup
3239         https://bugs.webkit.org/show_bug.cgi?id=144411
3240
3241         Reviewed by Timothy Hatcher.
3242
3243         * inspector/remote/RemoteInspector.mm:
3244         (Inspector::RemoteInspector::receivedSetupMessage):
3245
3246 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
3247
3248         NodeList has issues with Symbol and empty string
3249         https://bugs.webkit.org/show_bug.cgi?id=144310
3250
3251         Reviewed by Darin Adler.
3252
3253         * runtime/PropertyName.h:
3254         (JSC::PropertyName::isSymbol):
3255         Helper to check if the PropertyName is a string or symbol property.
3256
3257 2015-04-29  Alex Christensen  <achristensen@webkit.org>
3258
3259         Fix non-cygwin incremental builds on Windows.
3260         https://bugs.webkit.org/show_bug.cgi?id=143264
3261
3262         Reviewed by Brent Fulgham.
3263
3264         * generate-js-builtins:
3265         Remove stale headers before calling os.rename to replace them.
3266
3267 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
3268
3269         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
3270         https://bugs.webkit.org/show_bug.cgi?id=144397
3271
3272         Reviewed by Andreas Kling.
3273         
3274         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
3275         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
3276         making a getCallData() call if it isn't necessary.
3277
3278         * API/JSCallbackObject.h:
3279         * runtime/InternalFunction.h:
3280         * runtime/JSTypeInfo.h:
3281         (JSC::TypeInfo::typeOfShouldCallGetCallData):
3282         * runtime/Operations.cpp:
3283         (JSC::jsTypeStringForValue):
3284         * tests/stress/type-of-functions-and-objects.js: Added.
3285         (foo):
3286         (bar):
3287         (baz):
3288         (fuzz):
3289         (expect):
3290         (test):
3291
3292 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
3293
3294         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
3295         https://bugs.webkit.org/show_bug.cgi?id=144013
3296
3297         Reviewed by Mark Lam.
3298
3299         This patch implements Array.prototype.sort in JavaScript, removing the
3300         C++ implementations. It is simpler and less error-prone to express our
3301         operations in JavaScript, which provides memory safety, exception safety,
3302         and recursion safety.
3303
3304         The performance result is mixed, but net positive in my opinion. It's
3305         difficult to enumerate all the results, since we used to have so many
3306         different sorting modes, and there are lots of different data patterns
3307         across which you might want to measure sorting. Suffice it to say:
3308
3309             (*) The benchmarks we track are faster or unchanged.
3310
3311             (*) Sorting random input using a comparator -- which we think is
3312             common -- is 3X faster.
3313
3314             (*) Sorting random input in a non-array object -- which jQuery does
3315             -- is 4X faster.
3316
3317             (*) Sorting random input in a compact array of integers using a
3318             trivial pattern-matchable comparator is 2X *slower*.
3319
3320         * builtins/Array.prototype.js:
3321         (sort.min):
3322         (sort.stringComparator):
3323         (sort.compactSparse): Special case compaction for sparse arrays because
3324         we don't want to hang when sorting new Array(BIG).
3325
3326         (sort.compact):
3327         (sort.merge):
3328         (sort.mergeSort): Use merge sort because it's a reasonably efficient
3329         stable sort. We have evidence that some sites depend on stable sort,
3330         even though the ES6 spec does not mandate it. (See
3331         <http://trac.webkit.org/changeset/33967>.)
3332
3333         This is a textbook implementation of merge sort with three optimizations:
3334
3335             (1) Use iteration instead of recursion;
3336
3337             (2) Use array subscripting instead of array copying in order to
3338             create logical sub-lists without creating physical sub-lists;
3339
3340             (3) Swap src and dst at each iteration instead of copying src into
3341             dst, and only copy src into the subject array at the end if src is
3342             not the subject array.
3343
3344         (sort.inflate):
3345         (sort.comparatorSort):
3346         (sort): Sort in JavaScript for the win.
3347
3348         * builtins/BuiltinExecutables.cpp:
3349         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
3350         names so we can use helper functions.
3351
3352         * bytecode/CodeBlock.h:
3353         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
3354         * bytecode/UnlinkedCodeBlock.cpp:
3355         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3356         * bytecode/UnlinkedCodeBlock.h:
3357         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
3358         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
3359         * bytecompiler/BytecodeGenerator.cpp:
3360         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
3361         * bytecompiler/BytecodeGenerator.h:
3362         * bytecompiler/NodesCodegen.cpp:
3363         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
3364         on pattern matching anymore. This was mainly an optimization to avoid 
3365         the overhead of calling from C++ to JS, which we now avoid by
3366         sorting in JS.
3367
3368         * heap/Heap.cpp:
3369         (JSC::Heap::markRoots):
3370         (JSC::Heap::pushTempSortVector): Deleted.
3371         (JSC::Heap::popTempSortVector): Deleted.
3372         (JSC::Heap::visitTempSortVectors): Deleted.
3373         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
3374         in JavaScript using a normal JavaScript array for our temporary storage.
3375
3376         * parser/Parser.cpp:
3377         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
3378         helper functions.
3379
3380         * runtime/ArrayPrototype.cpp:
3381         (JSC::isNumericCompareFunction): Deleted.
3382         (JSC::attemptFastSort): Deleted.
3383         (JSC::performSlowSort): Deleted.
3384         (JSC::arrayProtoFuncSort): Deleted.
3385
3386         * runtime/CommonIdentifiers.h: New strings used by sort.
3387
3388         * runtime/JSArray.cpp:
3389         (JSC::compareNumbersForQSortWithInt32): Deleted.
3390         (JSC::compareNumbersForQSortWithDouble): Deleted.
3391         (JSC::compareNumbersForQSort): Deleted.
3392         (JSC::compareByStringPairForQSort): Deleted.
3393         (JSC::JSArray::sortNumericVector): Deleted.
3394         (JSC::JSArray::sortNumeric): Deleted.
3395         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
3396         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
3397         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
3398         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
3399         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
3400         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
3401         (JSC::JSArray::sortCompactedVector): Deleted.
3402         (JSC::JSArray::sort): Deleted.
3403         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
3404         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
3405         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
3406         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
3407         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
3408         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
3409         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
3410         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
3411         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
3412         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
3413         (JSC::JSArray::sortVector): Deleted.
3414         (JSC::JSArray::compactForSorting): Deleted.
3415         * runtime/JSArray.h:
3416
3417         * runtime/JSGlobalObject.cpp:
3418         (JSC::JSGlobalObject::init):
3419         * runtime/ObjectConstructor.cpp:
3420         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
3421         by sort.
3422
3423 2015-04-29  Mark Lam  <mark.lam@apple.com>
3424
3425         Safari WebKit crash when loading Google Spreadsheet.
3426         https://bugs.webkit.org/show_bug.cgi?id=144020
3427
3428         Reviewed by Filip Pizlo.
3429
3430         The bug is that the object allocation sinking phase did not account for a case
3431         where a property of a sunken object is only initialized on one path and not
3432         another.  As a result, on the path where the property is not initialized, we'll
3433         encounter an Upsilon with a BottomValue (which is not allowed by definition).
3434
3435         The fix is to use a JSConstant(undefined) as the bottom value instead (of
3436         BottomValue).  If the property is uninitialized, it should still be accessible
3437         and have the value undefined.
3438
3439         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3440         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
3441         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
3442         (foo):
3443         (foo2):
3444
3445 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
3446
3447         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
3448         https://bugs.webkit.org/show_bug.cgi?id=144257
3449
3450         Reviewed by Darin Adler.
3451
3452         SHA1 is used to calculate CodeBlockHash.
3453         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
3454         However, the source code can contain null character.
3455         So when performing `strlen` on the source code's CString, it returns the incorrect length.
3456         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
3457
3458         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
3459         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
3460
3461         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
3462         is not correct. Because
3463
3464         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
3465         2. If CString can contain a null character, this assertion becomes incorrect.
3466
3467         So this patch just drops the assertion.
3468
3469         In the current implementation, we once convert the entire source code to the newly allocated
3470         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
3471         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
3472         We'll implement it in the separate patch[2].
3473
3474         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
3475         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
3476
3477         * tests/stress/eval-script-contains-null-character.js: Added.
3478         (shouldBe):
3479         (test):
3480         * tests/stress/template-literal-line-terminators.js:
3481         * tests/stress/template-literal-syntax.js:
3482         * tests/stress/template-literal.js:
3483
3484 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
3485
3486         Evict IsEnvironmentRecord from inline type flags
3487         https://bugs.webkit.org/show_bug.cgi?id=144398
3488
3489         Reviewed by Mark Lam and Michael Saboff.
3490         
3491         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
3492         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
3493         and evicts it into the out-of-line type flags. This change has no performance implications
3494         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
3495         where we access it at all is in String.prototype.repeat, and there we already load the
3496         structure anyway.
3497
3498         * runtime/JSTypeInfo.h:
3499         (JSC::TypeInfo::implementsHasInstance):
3500         (JSC::TypeInfo::structureIsImmortal):
3501         (JSC::TypeInfo::isEnvironmentRecord):
3502
3503 2015-04-29  Darin Adler  <darin@apple.com>
3504
3505         [ES6] Implement Unicode code point escapes
3506         https://bugs.webkit.org/show_bug.cgi?id=144377
3507
3508         Reviewed by Antti Koivisto.
3509
3510         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
3511         the header. Made it a non-member class so it doesn't need to be part
3512         of a template. Made it use UChar32 instead of int for the value to
3513         make it clearer what goes into this class.
3514         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
3515         old type() function.
3516         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
3517         parseFourDigitUnicodeHex and added support for code point escapes.
3518         (JSC::isLatin1): Added an overload for UChar32.
3519         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
3520         to call it with a UChar, so no need to overload for that type for now.
3521         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
3522         Also added FIXME about a subtle ES6 change that we might want to make later.
3523         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
3524         to call it with a UChar, so no need to overload for that type for now.
3525         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
3526         don't need to repeat the code twice. Added code to handle code point escapes.
3527         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
3528         code in line.
3529         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
3530         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
3531         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
3532         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
3533         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
3534         the code that handles the escapes, since the code point escape code now
3535         consumes characters while parsing rather than peeking ahead. Test case
3536         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
3537         giving a syntax error.
3538
3539         * parser/Lexer.h: Updated for above changes.
3540
3541         * runtime/StringConstructor.cpp:
3542         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
3543         out 0x10FFFF; clearer this way.
3544
3545 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
3546
3547         [CMake] [GTK] Organize and clean up unused CMake variables
3548         https://bugs.webkit.org/show_bug.cgi?id=144364
3549
3550         Reviewed by Gyuyoung Kim.
3551
3552         * PlatformGTK.cmake: Add variables specific to this project.
3553
3554 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3555
3556         TypeOf should return SpecStringIdent and the DFG should know this
3557         https://bugs.webkit.org/show_bug.cgi?id=144376
3558
3559         Reviewed by Andreas Kling.
3560         
3561         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
3562         
3563         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
3564         bad.
3565
3566         * dfg/DFGAbstractInterpreterInlines.h:
3567         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3568         * dfg/DFGAbstractValue.cpp:
3569         (JSC::DFG::AbstractValue::setType):
3570         * dfg/DFGAbstractValue.h:
3571         (JSC::DFG::AbstractValue::setType):
3572         * dfg/DFGInPlaceAbstractState.cpp:
3573         (JSC::DFG::InPlaceAbstractState::initialize):
3574         * dfg/DFGPredictionPropagationPhase.cpp:
3575         (JSC::DFG::PredictionPropagationPhase::propagate):
3576         * runtime/SmallStrings.cpp:
3577         (JSC::SmallStrings::initialize):
3578         * tests/stress/switch-typeof-indirect.js: Added.
3579         (bar):
3580         (foo):
3581         (test):
3582         * tests/stress/switch-typeof-slightly-indirect.js: Added.
3583         (foo):
3584         (test):
3585         * tests/stress/switch-typeof.js: Added.
3586         (foo):
3587         (test):
3588
3589 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
3590
3591         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
3592         https://bugs.webkit.org/show_bug.cgi?id=144373
3593
3594         Reviewed by Darin Adler.
3595
3596         Revert r181868 as it caused a failure on live.com. We can try
3597         re-enabling this exception after we make idl attributes configurable,
3598         which may have prevented this particular failure.
3599
3600         * runtime/ObjectPrototype.cpp:
3601         (JSC::objectProtoFuncDefineGetter):
3602         (JSC::objectProtoFuncDefineSetter):
3603
3604 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
3605
3606         Deadlock on applications using JSContext on non-main thread
3607         https://bugs.webkit.org/show_bug.cgi?id=144370
3608
3609         Reviewed by Timothy Hatcher.
3610
3611         * inspector/remote/RemoteInspector.mm:
3612         (Inspector::RemoteInspector::singleton):
3613         Prevent a possible deadlock by assuming we can synchronously
3614         run something on the main queue at this time.
3615
3616 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3617
3618         FTL should fully support Switch (it currently lacks the SwitchString variant)
3619         https://bugs.webkit.org/show_bug.cgi?id=144348
3620
3621         Reviewed by Benjamin Poulain.
3622         
3623         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
3624         in LayoutTests/js/regress.
3625
3626         * dfg/DFGCommon.cpp:
3627         (JSC::DFG::stringLessThan):
3628         * dfg/DFGCommon.h:
3629         * dfg/DFGOperations.cpp:
3630         * dfg/DFGOperations.h:
3631         * dfg/DFGSpeculativeJIT.cpp:
3632         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
3633         * dfg/DFGSpeculativeJIT.h:
3634         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
3635         * ftl/FTLCapabilities.cpp:
3636         (JSC::FTL::canCompile):
3637         * ftl/FTLIntrinsicRepository.h:
3638         * ftl/FTLLowerDFGToLLVM.cpp:
3639         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
3640         (JSC::FTL::LowerDFGToLLVM::switchString):
3641         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
3642         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
3643         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
3644         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
3645         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
3646         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
3647         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
3648         * ftl/FTLOutput.cpp:
3649         (JSC::FTL::Output::check):
3650         * ftl/FTLOutput.h:
3651         * ftl/FTLWeight.h:
3652         (JSC::FTL::Weight::inverse):
3653         * jit/JITOperations.h:
3654
3655 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
3656
3657         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
3658         https://bugs.webkit.org/show_bug.cgi?id=144304
3659
3660         Reviewed by Geoffrey Garen.
3661
3662         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
3663         ENABLE_LLINT_C_LOOP, disabled by default.
3664         * llint/LLIntSlowPaths.cpp:
3665         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
3666
3667 2015-04-28  Commit Queue  <commit-queue@webkit.org>
3668
3669         Unreviewed, rolling out r183514.
3670         https://bugs.webkit.org/show_bug.cgi?id=144359
3671
3672         It broke cloop test bots (Requested by mcatanzaro on #webkit).
3673
3674         Reverted changeset:
3675
3676         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
3677         https://bugs.webkit.org/show_bug.cgi?id=144304
3678         http://trac.webkit.org/changeset/183514
3679
3680 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
3681
3682         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
3683         https://bugs.webkit.org/show_bug.cgi?id=144304
3684
3685         Reviewed by Geoffrey Garen.
3686
3687         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
3688         ENABLE_LLINT_C_LOOP, disabled by default.
3689         * llint/LLIntSlowPaths.cpp:
3690         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
3691
3692 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
3693
3694         Fix common typo "targetting" => "targeting"
3695         https://bugs.webkit.org/show_bug.cgi?id=144349
3696
3697         Reviewed by Daniel Bates.
3698
3699         * bytecode/ExecutionCounter.h:
3700
3701 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
3702
3703         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
3704         https://bugs.webkit.org/show_bug.cgi?id=144328
3705
3706         Reviewed by Andreas Kling.
3707
3708         Update the status of ES6 features.
3709
3710         * features.json:
3711
3712 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3713
3714         DFG should not use or preserve Phantoms during transformations
3715         https://bugs.webkit.org/show_bug.cgi?id=143736
3716
3717         Reviewed by Geoffrey Garen.
3718         
3719         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
3720         no longer necessary to preserve Phantoms during transformations. They are still useful just
3721         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
3722         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
3723         block, we can be sure that so long as the IR pinpoints the place where the value becomes
3724         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
3725         other block would need the value (either for OSR or for DFG execution), then we don't need any
3726         liveness markers.
3727         
3728         So, this removes any places where we inserted Phantoms just for liveness during transformation
3729         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
3730         Check node only keeps its children so long as those children have checks.
3731         
3732         The fact that we no longer convertToPhantom() means that we have to be more careful when
3733         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
3734         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
3735         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
3736         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
3737         GetLocals.
3738         
3739         The only Phantom-like cruft left over after this patch is:
3740         
3741         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
3742           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
3743           the users of the original local's live range in bytecode. This is essential for supporting our
3744           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
3745         
3746         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
3747           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
3748           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
3749           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
3750           treat GetLocal/SetLocal conservatively, this should all be sound.
3751         
3752         This change should be perf-neutral although it does reduce the total work that the compiler
3753         does.
3754
3755         * CMakeLists.txt:
3756         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3757         * JavaScriptCore.xcodeproj/project.pbxproj:
3758         * dfg/DFGAdjacencyList.h:
3759         (JSC::DFG::AdjacencyList::justChecks):
3760         * dfg/DFGArgumentsEliminationPhase.cpp:
3761         * dfg/DFGBasicBlock.cpp:
3762         (JSC::DFG::BasicBlock::replaceTerminal):
3763         * dfg/DFGBasicBlock.h:
3764         (JSC::DFG::BasicBlock::findTerminal):
3765         * dfg/DFGCFGSimplificationPhase.cpp:
3766         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
3767         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
3768         * dfg/DFGCPSRethreadingPhase.cpp:
3769         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
3770         (JSC::DFG::CPSRethreadingPhase::clearVariables):
3771         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
3772         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3773         * dfg/DFGCSEPhase.cpp:
3774         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
3775         (JSC::DFG::CleanUpPhase::CleanUpPhase):
3776         (JSC::DFG::CleanUpPhase::run):
3777         (JSC::DFG::performCleanUp):
3778         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
3779         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
3780         (JSC::DFG::performPhantomRemoval): Deleted.
3781         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
3782         * dfg/DFGConstantFoldingPhase.cpp:
3783         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3784         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
3785         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
3786         * dfg/DFGDCEPhase.cpp:
3787         (JSC::DFG::DCEPhase::run):
3788         (JSC::DFG::DCEPhase::fixupBlock):
3789         (JSC::DFG::DCEPhase::cleanVariables):
3790         * dfg/DFGFixupPhase.cpp:
3791         (JSC::DFG::FixupPhase::fixupBlock):
3792         (JSC::DFG::FixupPhase::fixupNode):
3793         (JSC::DFG::FixupPhase::convertStringAddUse):
3794         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
3795         (JSC::DFG::FixupPhase::checkArray):
3796         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
3797         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
3798         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
3799         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
3800         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
3801         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
3802         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
3803         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
3804         * dfg/DFGGraph.cpp:
3805         (JSC::DFG::Graph::convertToConstant):
3806         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
3807         * dfg/DFGGraph.h:
3808         * dfg/DFGInsertionSet.h:
3809         (JSC::DFG::InsertionSet::insertCheck):
3810         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3811         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
3812         * dfg/DFGLICMPhase.cpp:
3813         (JSC::DFG::LICMPhase::attemptHoist):
3814         * dfg/DFGNode.cpp:
3815         (JSC::DFG::Node::remove):
3816         * dfg/DFGNode.h:
3817         (JSC::DFG::Node::replaceWith):
3818         (JSC::DFG::Node::convertToPhantom): Deleted.
3819         (JSC::DFG::Node::convertToCheck): Deleted.
3820         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
3821         * dfg/DFGNodeFlags.h:
3822         * dfg/DFGNodeType.h:
3823         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3824         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
3825         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
3826         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
3827         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
3828         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
3829         * dfg/DFGPhantomRemovalPhase.h: Removed.
3830         * dfg/DFGPlan.cpp:
3831         (JSC::DFG::Plan::compileInThreadImpl):
3832         * dfg/DFGPutStackSinkingPhase.cpp:
3833         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
3834         * dfg/DFGResurrectionForValidationPhase.h: Removed.
3835         * dfg/DFGSSAConversionPhase.cpp:
3836         (JSC::DFG::SSAConversionPhase::run):
3837         * dfg/DFGSpeculativeJIT64.cpp:
3838         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
3839         * dfg/DFGStoreBarrierElisionPhase.cpp:
3840         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
3841         * dfg/DFGStrengthReductionPhase.cpp:
3842         (JSC::DFG::StrengthReductionPhase::handleNode):
3843         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
3844         * dfg/DFGValidate.cpp:
3845         (JSC::DFG::Validate::validate):
3846         (JSC::DFG::Validate::validateCPS):
3847         (JSC::DFG::Validate::validateSSA):
3848         * dfg/DFGVarargsForwardingPhase.cpp:
3849         * ftl/FTLLink.cpp:
3850         (JSC::FTL::link):
3851         * ftl/FTLLowerDFGToLLVM.cpp:
3852         (JSC::FTL::LowerDFGToLLVM::compileNode):
3853         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
3854         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
3855
3856 2015-04-28  Andreas Kling  <akling@apple.com>
3857
3858         DFG+FTL should generate efficient code for branching on a string's boolean value.
3859         <https://webkit.org/b/144317>
3860
3861         Reviewed by Geoff Garen & Filip Pizlo
3862
3863         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check