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