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