[ES6] Add @@toStringTag to GeneratorFunction
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [ES6] Add @@toStringTag to GeneratorFunction
4         https://bugs.webkit.org/show_bug.cgi?id=156499
5
6         Reviewed by Mark Lam.
7
8         GeneratorFunction.prototype has @@toStringTag property, "GeneratorFunction".
9         https://tc39.github.io/ecma262/#sec-generatorfunction.prototype-@@tostringtag
10
11         * runtime/GeneratorFunctionPrototype.cpp:
12         (JSC::GeneratorFunctionPrototype::finishCreation):
13         * tests/es6.yaml:
14         * tests/es6/well-known_symbols_Symbol.toStringTag_new_built-ins.js: Added.
15         (test):
16
17 2016-04-13  Alberto Garcia  <berto@igalia.com>
18
19         Fix build in glibc-based BSD systems
20         https://bugs.webkit.org/show_bug.cgi?id=156533
21
22         Reviewed by Carlos Garcia Campos.
23
24         Change the order of the #elif conditionals so glibc-based BSD
25         systems (e.g. Debian GNU/kFreeBSD) use the code inside the
26         OS(FREEBSD) blocks.
27
28         * heap/MachineStackMarker.cpp:
29         (JSC::MachineThreads::Thread::Registers::stackPointer):
30         (JSC::MachineThreads::Thread::Registers::framePointer):
31         (JSC::MachineThreads::Thread::Registers::instructionPointer):
32         (JSC::MachineThreads::Thread::Registers::llintPC):
33
34 2016-04-12  Keith Miller  <keith_miller@apple.com>
35
36         Unreviewed undo change from ArrayClass to ArrayWithUndecided, which
37         was not intedend to land with r199397.
38
39         * runtime/ArrayPrototype.h:
40         (JSC::ArrayPrototype::createStructure):
41
42 2016-04-12  Mark Lam  <mark.lam@apple.com>
43
44         Rollout: ES6: Implement String.prototype.split and RegExp.prototype[@@split].
45         https://bugs.webkit.org/show_bug.cgi?id=156013
46
47         Speculative rollout to fix 32-bit shadow-chicken.yaml/tests/v8-v6/v8-regexp.js.shadow-chicken test failure.
48
49         Not reviewed.
50
51         * CMakeLists.txt:
52         * JavaScriptCore.xcodeproj/project.pbxproj:
53         * builtins/GlobalObject.js:
54         (speciesGetter):
55         (speciesConstructor): Deleted.
56         * builtins/PromisePrototype.js:
57         * builtins/RegExpPrototype.js:
58         (advanceStringIndexUnicode):
59         (match):
60         (advanceStringIndex): Deleted.
61         (regExpExec): Deleted.
62         (hasObservableSideEffectsForRegExpSplit): Deleted.
63         (split): Deleted.
64         * builtins/StringPrototype.js:
65         (repeat):
66         (split): Deleted.
67         * bytecode/BytecodeIntrinsicRegistry.cpp:
68         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
69         (JSC::BytecodeIntrinsicRegistry::lookup):
70         * bytecode/BytecodeIntrinsicRegistry.h:
71         * runtime/CommonIdentifiers.h:
72         * runtime/ECMAScriptSpecInternalFunctions.cpp: Removed.
73         * runtime/ECMAScriptSpecInternalFunctions.h: Removed.
74         * runtime/JSGlobalObject.cpp:
75         (JSC::JSGlobalObject::setGlobalThis):
76         (JSC::JSGlobalObject::init):
77         (JSC::getGetterById): Deleted.
78         * runtime/PropertyDescriptor.cpp:
79         (JSC::PropertyDescriptor::setDescriptor):
80         * runtime/RegExpObject.h:
81         (JSC::RegExpObject::offsetOfLastIndexIsWritable):
82         * runtime/RegExpPrototype.cpp:
83         (JSC::RegExpPrototype::finishCreation):
84         (JSC::regExpProtoFuncExec):
85         (JSC::regExpProtoFuncSearch):
86         (JSC::advanceStringIndex): Deleted.
87         (JSC::regExpProtoFuncSplitFast): Deleted.
88         * runtime/RegExpPrototype.h:
89         * runtime/StringObject.h:
90         (JSC::jsStringWithReuse): Deleted.
91         (JSC::jsSubstring): Deleted.
92         * runtime/StringPrototype.cpp:
93         (JSC::StringPrototype::finishCreation):
94         (JSC::jsStringWithReuse):
95         (JSC::jsSubstring):
96         (JSC::substituteBackreferencesSlow):
97         (JSC::splitStringByOneCharacterImpl):
98         (JSC::stringProtoFuncSplit):
99         (JSC::stringProtoFuncSubstr):
100         (JSC::stringProtoFuncSubstring):
101         (JSC::stringProtoFuncEndsWith):
102         (JSC::stringProtoFuncIncludes):
103         (JSC::stringProtoFuncIterator):
104         (JSC::stringProtoFuncSplitFast): Deleted.
105         (JSC::builtinStringSubstrInternal): Deleted.
106         (JSC::stringIncludesImpl): Deleted.
107         (JSC::builtinStringIncludesInternal): Deleted.
108         * runtime/StringPrototype.h:
109         * tests/es6.yaml:
110
111 2016-04-12  Mark Lam  <mark.lam@apple.com>
112
113         Remove 2 unused JSC options.
114         https://bugs.webkit.org/show_bug.cgi?id=156526
115
116         Reviewed by Benjamin Poulain.
117
118         The options JSC_assertICSizing and JSC_dumpFailedICSizing are no longer in use
119         now that we have B3.
120
121         * runtime/Options.h:
122
123 2016-04-12  Keith Miller  <keith_miller@apple.com>
124
125         [ES6] Add support for Symbol.isConcatSpreadable.
126         https://bugs.webkit.org/show_bug.cgi?id=155351
127
128         Reviewed by Saam Barati.
129
130         This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
131         Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
132         a builtin performant. First, four new DFG intrinsics were added.
133
134         1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
135            the Array.isArray function.
136         2) IsJSArray: checks the first child is a JSArray object.
137         3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
138         4) CallObjectConstructor: an intrinsic of the Object constructor.
139
140         IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
141         we are able to prove that the first child is an Array or for ToObject an Object.
142
143         In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
144         code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
145         were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
146         the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
147         into a contiguous array).
148
149         This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
150         values onto the result array. This works roughly the same as the two array fast path using the same methodology
151         to decide if we can memcpy the other butterfly into the result butterfly.
152
153         Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
154         name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
155         dataLog function on it.
156
157         Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
158         JSValueOperand if the operand's use count is one.
159
160         * JavaScriptCore.xcodeproj/project.pbxproj:
161         * builtins/ArrayPrototype.js:
162         (concatSlowPath):
163         (concat):
164         * bytecode/BytecodeIntrinsicRegistry.cpp:
165         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
166         * bytecode/BytecodeIntrinsicRegistry.h:
167         * dfg/DFGAbstractInterpreterInlines.h:
168         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
169         * dfg/DFGByteCodeParser.cpp:
170         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
171         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
172         * dfg/DFGClobberize.h:
173         (JSC::DFG::clobberize):
174         * dfg/DFGDoesGC.cpp:
175         (JSC::DFG::doesGC):
176         * dfg/DFGFixupPhase.cpp:
177         (JSC::DFG::FixupPhase::fixupNode):
178         * dfg/DFGNodeType.h:
179         * dfg/DFGOperations.cpp:
180         * dfg/DFGOperations.h:
181         * dfg/DFGPredictionPropagationPhase.cpp:
182         (JSC::DFG::PredictionPropagationPhase::propagate):
183         * dfg/DFGSafeToExecute.h:
184         (JSC::DFG::safeToExecute):
185         * dfg/DFGSpeculativeJIT.cpp:
186         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
187         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
188         (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
189         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
190         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
191         * dfg/DFGSpeculativeJIT.h:
192         (JSC::DFG::SpeculativeJIT::callOperation):
193         * dfg/DFGSpeculativeJIT32_64.cpp:
194         (JSC::DFG::SpeculativeJIT::compile):
195         * dfg/DFGSpeculativeJIT64.cpp:
196         (JSC::DFG::SpeculativeJIT::compile):
197         * ftl/FTLCapabilities.cpp:
198         (JSC::FTL::canCompile):
199         * ftl/FTLLowerDFGToB3.cpp:
200         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
201         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
202         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
203         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
204         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
205         (JSC::FTL::DFG::LowerDFGToB3::isArray):
206         * jit/JITOperations.h:
207         * jsc.cpp:
208         (GlobalObject::finishCreation):
209         (functionDataLogValue):
210         * runtime/ArrayConstructor.cpp:
211         (JSC::ArrayConstructor::finishCreation):
212         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
213         * runtime/ArrayConstructor.h:
214         (JSC::isArrayConstructor):
215         * runtime/ArrayPrototype.cpp:
216         (JSC::ArrayPrototype::finishCreation):
217         (JSC::arrayProtoPrivateFuncIsJSArray):
218         (JSC::moveElements):
219         (JSC::arrayProtoPrivateFuncConcatMemcpy):
220         (JSC::arrayProtoPrivateFuncAppendMemcpy):
221         (JSC::arrayProtoFuncConcat): Deleted.
222         * runtime/ArrayPrototype.h:
223         (JSC::ArrayPrototype::createStructure):
224         * runtime/CommonIdentifiers.h:
225         * runtime/Intrinsic.h:
226         * runtime/JSArray.cpp:
227         (JSC::JSArray::appendMemcpy):
228         (JSC::JSArray::fastConcatWith): Deleted.
229         * runtime/JSArray.h:
230         (JSC::JSArray::createStructure):
231         (JSC::JSArray::fastConcatType): Deleted.
232         * runtime/JSArrayInlines.h: Added.
233         (JSC::JSArray::memCopyWithIndexingType):
234         (JSC::JSArray::canFastCopy):
235         * runtime/JSGlobalObject.cpp:
236         (JSC::JSGlobalObject::init):
237         * runtime/JSType.h:
238         * runtime/ObjectConstructor.h:
239         (JSC::constructObject):
240         * tests/es6.yaml:
241         * tests/stress/array-concat-spread-object.js: Added.
242         (arrayEq):
243         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
244         (arrayEq):
245         * tests/stress/array-concat-spread-proxy.js: Added.
246         (arrayEq):
247         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
248         (arrayEq):
249         * tests/stress/array-species-config-array-constructor.js:
250
251 2016-04-12  Saam barati  <sbarati@apple.com>
252
253         Lets not iterate over the constant pool twice every time we link a code block
254         https://bugs.webkit.org/show_bug.cgi?id=156517
255
256         Reviewed by Mark Lam.
257
258         I introduced a second iteration over the constant pool when I implemented
259         block scoping. I did this because we must clone all the symbol tables when
260         we link a CodeBlock. We can just do this cloning when setting the constant
261         registers for the first time. There is no need to iterate over the constant
262         pool a second time.
263
264         * bytecode/CodeBlock.cpp:
265         (JSC::CodeBlock::finishCreation):
266         (JSC::CodeBlock::~CodeBlock):
267         (JSC::CodeBlock::setConstantRegisters):
268         (JSC::CodeBlock::setAlternative):
269         * bytecode/CodeBlock.h:
270         (JSC::CodeBlock::replaceConstant):
271         (JSC::CodeBlock::setConstantRegisters): Deleted.
272
273 2016-04-12  Mark Lam  <mark.lam@apple.com>
274
275         ES6: Implement String.prototype.split and RegExp.prototype[@@split].
276         https://bugs.webkit.org/show_bug.cgi?id=156013
277
278         Reviewed by Keith Miller.
279
280         * CMakeLists.txt:
281         * JavaScriptCore.xcodeproj/project.pbxproj:
282         * builtins/GlobalObject.js:
283         (speciesConstructor):
284         * builtins/PromisePrototype.js:
285         - refactored to use the @speciesConstructor internal function.
286
287         * builtins/RegExpPrototype.js:
288         (advanceStringIndex):
289         - refactored from @advanceStringIndexUnicode() to be match the spec.
290           Benchmarks show that there's no advantage in doing the unicode check outside
291           of the advanceStringIndexUnicode part.  So, I simplified the code to match the
292           spec (especially since @@split needs to call advanceStringIndex from more than
293           1 location).
294         (match):
295         - Removed an unnecessary call to @Object because it was already proven above.
296         - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
297           Again, there's no perf regression for this.
298         (regExpExec):
299         (hasObservableSideEffectsForRegExpSplit):
300         (split):
301         (advanceStringIndexUnicode): Deleted.
302
303         * builtins/StringPrototype.js:
304         (split):
305         - Modified to use RegExp.prototype[@@split].
306
307         * bytecode/BytecodeIntrinsicRegistry.cpp:
308         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
309         (JSC::BytecodeIntrinsicRegistry::lookup):
310         * bytecode/BytecodeIntrinsicRegistry.h:
311         - Added the @@split symbol.
312
313         * runtime/CommonIdentifiers.h:
314         * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
315         (JSC::esSpecIsConstructor):
316         (JSC::esSpecIsRegExp):
317         * runtime/ECMAScriptSpecInternalFunctions.h: Added.
318
319         * runtime/JSGlobalObject.cpp:
320         (JSC::getGetterById):
321         (JSC::JSGlobalObject::init):
322
323         * runtime/PropertyDescriptor.cpp:
324         (JSC::PropertyDescriptor::setDescriptor):
325         - Removed an assert that is no longer valid.
326
327         * runtime/RegExpObject.h:
328         - Made advanceStringUnicode() public so that it can be re-used by the regexp split
329           fast path.
330
331         * runtime/RegExpPrototype.cpp:
332         (JSC::RegExpPrototype::finishCreation):
333         (JSC::regExpProtoFuncExec):
334         (JSC::regExpProtoFuncSearch):
335         (JSC::advanceStringIndex):
336         (JSC::regExpProtoFuncSplitFast):
337         * runtime/RegExpPrototype.h:
338
339         * runtime/StringObject.h:
340         (JSC::jsStringWithReuse):
341         (JSC::jsSubstring):
342         - Hoisted some utility functions from StringPrototype.cpp so that they can be
343           reused by the regexp split fast path.
344
345         * runtime/StringPrototype.cpp:
346         (JSC::StringPrototype::finishCreation):
347         (JSC::stringProtoFuncSplitFast):
348         (JSC::stringProtoFuncSubstr):
349         (JSC::builtinStringSubstrInternal):
350         (JSC::stringProtoFuncSubstring):
351         (JSC::stringIncludesImpl):
352         (JSC::stringProtoFuncIncludes):
353         (JSC::builtinStringIncludesInternal):
354         (JSC::jsStringWithReuse): Deleted.
355         (JSC::jsSubstring): Deleted.
356         (JSC::stringProtoFuncSplit): Deleted.
357         * runtime/StringPrototype.h:
358
359         * tests/es6.yaml:
360
361 2016-04-12  Keith Miller  <keith_miller@apple.com>
362
363         AbstractValue should use the result type to filter structures
364         https://bugs.webkit.org/show_bug.cgi?id=156516
365
366         Reviewed by Geoffrey Garen.
367
368         When filtering an AbstractValue with a SpeculatedType we would not use the merged type when
369         filtering out the valid structures (despite what the comment directly above said). This
370         would cause us to crash if our structure-set was Top and the two speculated types were
371         different kinds of cells.
372
373         * dfg/DFGAbstractValue.cpp:
374         (JSC::DFG::AbstractValue::filter):
375         * tests/stress/ai-consistency-filter-cells.js: Added.
376         (get value):
377         (attribute.value.get record):
378         (attribute.attrs.get this):
379         (get foo):
380         (let.thisValue.return.serialize):
381         (let.thisValue.transformFor):
382
383 2016-04-12  Filip Pizlo  <fpizlo@apple.com>
384
385         Unreviewed, remove FIXME for https://bugs.webkit.org/show_bug.cgi?id=156457 and replace it
386         with a comment that describes what we do now.
387
388         * bytecode/PolymorphicAccess.h:
389
390 2016-04-12  Saam barati  <sbarati@apple.com>
391
392         isLocked() assertion broke builds because ConcurrentJITLock isn't always a real lock.
393
394         Rubber-stamped by Filip Pizlo.
395
396         * bytecode/CodeBlock.cpp:
397         (JSC::CodeBlock::resultProfileForBytecodeOffset):
398         (JSC::CodeBlock::ensureResultProfile):
399
400 2016-04-11  Filip Pizlo  <fpizlo@apple.com>
401
402         PolymorphicAccess should buffer AccessCases before regenerating
403         https://bugs.webkit.org/show_bug.cgi?id=156457
404
405         Reviewed by Benjamin Poulain.
406
407         Prior to this change, whenever we added an AccessCase to a PolymorphicAccess, we would
408         regenerate the whole stub. That meant that we'd do O(N^2) work for N access cases.
409
410         One way to fix this is to have each AccessCase generate a stub just for itself, which
411         cascades down to the already-generated cases. But that removes the binary switch
412         optimization, which makes the IC perform great even when there are many cases.
413
414         This change fixes the issue by buffering access cases. When we take slow path and try to add
415         a new case, the StructureStubInfo will usually just buffer the new case without generating
416         new code. We simply guarantee that after we buffer a case, we will take at most
417         Options::repatchBufferingCountdown() slow path calls before generating code for it. That
418         option is currently 7. Taking 7 more slow paths means that we have 7 more opportunities to
419         gather more access cases, or to realize that this IC is too crazy to bother with.
420
421         This change ensures that the DFG still gets the same kind of profiling. This is because the
422         buffered AccessCases are still part of PolymorphicAccess and so are still scanned by
423         GetByIdStatus and PutByIdStatus. The fact that the AccessCases hadn't been generated and so
424         hadn't executed doesn't change much. Mainly, it increases the likelihood that the DFG will
425         see an access case that !couldStillSucceed(). The DFG's existing profile parsing logic can
426         handle this just fine.
427         
428         There are a bunch of algorithmic changes here. StructureStubInfo now caches the set of
429         structures that it has seen as a guard to prevent adding lots of redundant cases, in case
430         we see the same 7 cases after buffering the first one. This cache means we won't wastefully
431         allocate 7 identical AccessCase instances. PolymorphicAccess is now restructured around
432         having separate addCase() and regenerate() calls. That means a bit more moving data around.
433         So far that seems OK for performance, probably since it's O(N) work rather than O(N^2) work.
434         There is room for improvement for future patches, to be sure.
435         
436         This is benchmarking as slightly positive or neutral on JS benchmarks. It's meant to reduce
437         pathologies I saw in page loads.
438
439         * bytecode/GetByIdStatus.cpp:
440         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
441         * bytecode/PolymorphicAccess.cpp:
442         (JSC::PolymorphicAccess::PolymorphicAccess):
443         (JSC::PolymorphicAccess::~PolymorphicAccess):
444         (JSC::PolymorphicAccess::addCases):
445         (JSC::PolymorphicAccess::addCase):
446         (JSC::PolymorphicAccess::visitWeak):
447         (JSC::PolymorphicAccess::dump):
448         (JSC::PolymorphicAccess::commit):
449         (JSC::PolymorphicAccess::regenerate):
450         (JSC::PolymorphicAccess::aboutToDie):
451         (WTF::printInternal):
452         (JSC::PolymorphicAccess::regenerateWithCases): Deleted.
453         (JSC::PolymorphicAccess::regenerateWithCase): Deleted.
454         * bytecode/PolymorphicAccess.h:
455         (JSC::AccessCase::isGetter):
456         (JSC::AccessCase::callLinkInfo):
457         (JSC::AccessGenerationResult::AccessGenerationResult):
458         (JSC::AccessGenerationResult::madeNoChanges):
459         (JSC::AccessGenerationResult::gaveUp):
460         (JSC::AccessGenerationResult::buffered):
461         (JSC::AccessGenerationResult::generatedNewCode):
462         (JSC::AccessGenerationResult::generatedFinalCode):
463         (JSC::AccessGenerationResult::shouldGiveUpNow):
464         (JSC::AccessGenerationResult::generatedSomeCode):
465         (JSC::PolymorphicAccess::isEmpty):
466         (JSC::PolymorphicAccess::size):
467         (JSC::PolymorphicAccess::at):
468         * bytecode/PutByIdStatus.cpp:
469         (JSC::PutByIdStatus::computeForStubInfo):
470         * bytecode/StructureStubInfo.cpp:
471         (JSC::StructureStubInfo::StructureStubInfo):
472         (JSC::StructureStubInfo::addAccessCase):
473         (JSC::StructureStubInfo::reset):
474         (JSC::StructureStubInfo::visitWeakReferences):
475         * bytecode/StructureStubInfo.h:
476         (JSC::StructureStubInfo::considerCaching):
477         (JSC::StructureStubInfo::willRepatch): Deleted.
478         (JSC::StructureStubInfo::willCoolDown): Deleted.
479         * jit/JITOperations.cpp:
480         * jit/Repatch.cpp:
481         (JSC::tryCacheGetByID):
482         (JSC::repatchGetByID):
483         (JSC::tryCachePutByID):
484         (JSC::repatchPutByID):
485         (JSC::tryRepatchIn):
486         (JSC::repatchIn):
487         * runtime/JSCJSValue.h:
488         * runtime/JSCJSValueInlines.h:
489         (JSC::JSValue::putByIndex):
490         (JSC::JSValue::structureOrNull):
491         (JSC::JSValue::structureOrUndefined):
492         * runtime/Options.h:
493
494 2016-04-12  Saam barati  <sbarati@apple.com>
495
496         There is a race with the compiler thread and the main thread with result profiles
497         https://bugs.webkit.org/show_bug.cgi?id=156503
498
499         Reviewed by Filip Pizlo.
500
501         The compiler thread should not be asking for a result
502         profile while the execution thread is creating one.
503         We must guard against such races with a lock.
504
505         * bytecode/CodeBlock.cpp:
506         (JSC::CodeBlock::resultProfileForBytecodeOffset):
507         (JSC::CodeBlock::ensureResultProfile):
508         (JSC::CodeBlock::capabilityLevel):
509         * bytecode/CodeBlock.h:
510         (JSC::CodeBlock::couldTakeSlowCase):
511         (JSC::CodeBlock::numberOfResultProfiles):
512         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
513         (JSC::CodeBlock::ensureResultProfile): Deleted.
514
515 2016-04-12  Commit Queue  <commit-queue@webkit.org>
516
517         Unreviewed, rolling out r199339.
518         https://bugs.webkit.org/show_bug.cgi?id=156505
519
520         memset_s is indeed necessary (Requested by alexchristensen_ on
521         #webkit).
522
523         Reverted changeset:
524
525         "Build fix after r199299."
526         https://bugs.webkit.org/show_bug.cgi?id=155508
527         http://trac.webkit.org/changeset/199339
528
529 2016-04-12  Guillaume Emont  <guijemont@igalia.com>
530
531         MIPS: add MacroAssemblerMIPS::store8(TrustedImm32,ImplicitAddress)
532         https://bugs.webkit.org/show_bug.cgi?id=156481
533
534         This method with this signature is used by r199075, and therefore
535         WebKit doesn't build on MIPS since then.
536
537         Reviewed by Mark Lam.
538
539         * assembler/MacroAssemblerMIPS.h:
540         (JSC::MacroAssemblerMIPS::store8):
541
542 2016-04-12  Saam barati  <sbarati@apple.com>
543
544         We incorrectly parse arrow function expressions
545         https://bugs.webkit.org/show_bug.cgi?id=156373
546
547         Reviewed by Mark Lam.
548
549         This patch removes the notion of "isEndOfArrowFunction".
550         This was a very weird function and it was incorrect.
551         It checked that the arrow functions with concise body
552         grammar production "had a valid ending". "had a valid
553         ending" is in quotes because concise body arrow functions
554         have a valid ending as long as their body has a valid
555         assignment expression. I've removed all notion of this
556         function because it was wrong and was causing us
557         to throw syntax errors on valid programs.
558
559         * parser/Lexer.cpp:
560         (JSC::Lexer<T>::nextTokenIsColon):
561         (JSC::Lexer<T>::lex):
562         (JSC::Lexer<T>::setTokenPosition): Deleted.
563         * parser/Lexer.h:
564         (JSC::Lexer::setIsReparsingFunction):
565         (JSC::Lexer::isReparsingFunction):
566         (JSC::Lexer::lineNumber):
567         * parser/Parser.cpp:
568         (JSC::Parser<LexerType>::parseInner):
569         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
570         (JSC::Parser<LexerType>::parseFunctionInfo):
571         * parser/Parser.h:
572         (JSC::Parser::matchIdentifierOrKeyword):
573         (JSC::Parser::tokenStart):
574         (JSC::Parser::autoSemiColon):
575         (JSC::Parser::canRecurse):
576         (JSC::Parser::isEndOfArrowFunction): Deleted.
577         (JSC::Parser::setEndOfStatement): Deleted.
578         * tests/stress/arrowfunction-others.js:
579         (testCase):
580         (simpleArrowFunction):
581         (truthy):
582         (falsey):
583
584 2016-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
585
586         [JSC] addStaticGlobals should emit SymbolTableEntry watchpoints to encourage constant folding in DFG
587         https://bugs.webkit.org/show_bug.cgi?id=155110
588
589         Reviewed by Saam Barati.
590
591         `addStaticGlobals` does not emit SymbolTableEntry watchpoints for the added entries.
592         So, all the global variable lookups pointing to these static globals are not converted
593         into constants in DFGBytecodeGenerator: this fact leaves these lookups as GetGlobalVar.
594         Such thing avoids constant folding chance and emits CheckCell for @privateFunction inlining.
595         This operation is pure overhead.
596
597         Static globals are not configurable, and they are typically non-writable.
598         So they are constants in almost all the cases.
599
600         This patch initializes watchpoints for these static globals.
601         These watchpoints allow DFG to convert these nodes into constants in DFG BytecodeParser.
602         These watchpoints includes many builtin operations and `undefined`.
603
604         The microbenchmark, many-foreach-calls shows 5 - 7% improvement since it removes unnecessary CheckCell.
605
606         * bytecode/VariableWriteFireDetail.h:
607         * runtime/JSGlobalObject.cpp:
608         (JSC::JSGlobalObject::addGlobalVar):
609         (JSC::JSGlobalObject::addStaticGlobals):
610         * runtime/JSSymbolTableObject.h:
611         (JSC::symbolTablePutTouchWatchpointSet):
612         (JSC::symbolTablePutInvalidateWatchpointSet):
613         (JSC::symbolTablePut):
614         (JSC::symbolTablePutWithAttributesTouchWatchpointSet): Deleted.
615         * runtime/SymbolTable.h:
616         (JSC::SymbolTableEntry::SymbolTableEntry):
617         (JSC::SymbolTableEntry::operator=):
618         (JSC::SymbolTableEntry::swap):
619
620 2016-04-12  Alex Christensen  <achristensen@webkit.org>
621
622         Build fix after r199299.
623         https://bugs.webkit.org/show_bug.cgi?id=155508
624
625         * jit/ExecutableAllocatorFixedVMPool.cpp:
626         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
627         memset_s is not defined.  __STDC_WANT_LIB_EXT1__ is not defined anywhere.
628         Since the return value is unused and set_constraint_handler_s is never called
629         I'm chaning it to memset.
630
631 2016-04-11  Benjamin Poulain  <bpoulain@apple.com>
632
633         [JSC] B3 can use undefined bits or not defined required bits when spilling
634         https://bugs.webkit.org/show_bug.cgi?id=156486
635
636         Reviewed by Filip Pizlo.
637
638         Spilling had issues when replacing arguments in place.
639
640         The problems are:
641         1) If we have a 32bit stackslot, a x86 instruction could still try to load 64bits from it.
642         2) If we have a 64bit stackslot, Move32 would only set half the bits.
643         3) We were reducing Move to Move32 even if the top bits are read from the stack slot.
644
645         The case 1 appear with something like this:
646             Move32 %tmp0, %tmp1
647             Op64 %tmp1, %tmp2, %tmp3
648         When we spill %tmp1, the stack slot is 32bit, Move32 sets 32bits
649         but Op64 supports addressing for %tmp1. When we substitute %tmp1 in Op64,
650         we are creating a 64bit read for a 32bit stack slot.
651
652         The case 2 is an other common one. If we have:
653             BB#1
654                 Move32 %tmp0, %tmp1
655                 Jump #3
656             BB#2
657                 Op64 %tmp0, %tmp1
658                 Jump #3
659             BB#3
660                 Use64 %tmp1
661
662         We have a stack slot of 64bits. When spilling %tmp1 in #1, we are
663         effectively doing a 32bit store on the stack slot, leaving the top bits undefined.
664
665         Case 3 is pretty much the same as 2 but we create the Move32 ourself
666         because the source is a 32bit with ZDef.
667
668         Case (1) is solved by requiring that the stack slot is at least as large as the largest
669         use/def of that tmp.
670
671         Case (2) and (3) are solved by not replacing a Tmp by an Address if the Def
672         is smaller than the stack slot.
673
674         * b3/air/AirIteratedRegisterCoalescing.cpp:
675         * b3/testb3.cpp:
676         (JSC::B3::testSpillDefSmallerThanUse):
677         (JSC::B3::testSpillUseLargerThanDef):
678         (JSC::B3::run):
679
680 2016-04-11  Brian Burg  <bburg@apple.com>
681
682         Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
683         https://bugs.webkit.org/show_bug.cgi?id=156407
684         <rdar://problem/25627659>
685
686         Reviewed by Joseph Pecoraro.
687
688         There's no point having these subclasses as they don't save any space.
689         Add a StringImpl to the union and merge some implementations of writeJSON.
690
691         Rename m_data to m_map and explicitly name the union as InspectorValue::m_value.
692         If the value is a string and the string is not empty or null (i.e., it has a
693         StringImpl), then we need to ref() and deref() the string as the InspectorValue
694         is created or destroyed.
695
696         Move uses of the subclass to InspectorValue and delete redundant methods.
697         Now, most InspectorValue methods are non-virtual so they can be templated.
698
699         * bindings/ScriptValue.cpp:
700         (Deprecated::jsToInspectorValue):
701         * inspector/InjectedScriptBase.cpp:
702         (Inspector::InjectedScriptBase::makeCall):
703         Don't used deleted subclasses.
704
705         * inspector/InspectorValues.cpp:
706         (Inspector::InspectorValue::null):
707         (Inspector::InspectorValue::create):
708         (Inspector::InspectorValue::asValue):
709         (Inspector::InspectorValue::asBoolean):
710         (Inspector::InspectorValue::asDouble):
711         (Inspector::InspectorValue::asInteger):
712         (Inspector::InspectorValue::asString):
713         These only need one implementation now.
714
715         (Inspector::InspectorValue::writeJSON):
716         Still a virtual method since Object and Array need their members.
717
718         (Inspector::InspectorObjectBase::InspectorObjectBase):
719         (Inspector::InspectorBasicValue::asBoolean): Deleted.
720         (Inspector::InspectorBasicValue::asDouble): Deleted.
721         (Inspector::InspectorBasicValue::asInteger): Deleted.
722         (Inspector::InspectorBasicValue::writeJSON): Deleted.
723         (Inspector::InspectorString::asString): Deleted.
724         (Inspector::InspectorString::writeJSON): Deleted.
725         (Inspector::InspectorString::create): Deleted.
726         (Inspector::InspectorBasicValue::create): Deleted.
727
728         * inspector/InspectorValues.h:
729         (Inspector::InspectorObjectBase::find):
730         (Inspector::InspectorObjectBase::setBoolean):
731         (Inspector::InspectorObjectBase::setInteger):
732         (Inspector::InspectorObjectBase::setDouble):
733         (Inspector::InspectorObjectBase::setString):
734         (Inspector::InspectorObjectBase::setValue):
735         (Inspector::InspectorObjectBase::setObject):
736         (Inspector::InspectorObjectBase::setArray):
737         (Inspector::InspectorArrayBase::pushBoolean):
738         (Inspector::InspectorArrayBase::pushInteger):
739         (Inspector::InspectorArrayBase::pushDouble):
740         (Inspector::InspectorArrayBase::pushString):
741         (Inspector::InspectorArrayBase::pushValue):
742         (Inspector::InspectorArrayBase::pushObject):
743         (Inspector::InspectorArrayBase::pushArray):
744         Use new factory methods.
745
746         * replay/EncodedValue.cpp:
747         (JSC::ScalarEncodingTraits<bool>::encodeValue):
748         (JSC::ScalarEncodingTraits<double>::encodeValue):
749         (JSC::ScalarEncodingTraits<float>::encodeValue):
750         (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
751         (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
752         (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
753         (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
754         * replay/EncodedValue.h:
755         Use new factory methods.
756
757 2016-04-11  Filip Pizlo  <fpizlo@apple.com>
758
759         It should be possible to edit StructureStubInfo without recompiling the world
760         https://bugs.webkit.org/show_bug.cgi?id=156470
761
762         Reviewed by Keith Miller.
763
764         This change makes it less painful to make changes to the IC code. It used to be that any
765         change to StructureStubInfo caused every JIT-related file to get recompiled. Now only a
766         smaller set of files - ones that actually peek into StructureStubInfo - will recompile. This
767         is mainly because CodeBlock.h no longer includes StructureStubInfo.h.
768
769         * bytecode/ByValInfo.h:
770         * bytecode/CodeBlock.cpp:
771         * bytecode/CodeBlock.h:
772         * bytecode/GetByIdStatus.cpp:
773         * bytecode/GetByIdStatus.h:
774         * bytecode/PutByIdStatus.cpp:
775         * bytecode/PutByIdStatus.h:
776         * bytecode/StructureStubInfo.h:
777         (JSC::getStructureStubInfoCodeOrigin):
778         * dfg/DFGByteCodeParser.cpp:
779         * dfg/DFGJITCompiler.cpp:
780         * dfg/DFGOSRExitCompilerCommon.cpp:
781         * dfg/DFGSpeculativeJIT.h:
782         * ftl/FTLLowerDFGToB3.cpp:
783         * ftl/FTLSlowPathCall.h:
784         * jit/IntrinsicEmitter.cpp:
785         * jit/JITInlineCacheGenerator.cpp:
786         * jit/JITInlineCacheGenerator.h:
787         * jit/JITOperations.cpp:
788         * jit/JITPropertyAccess.cpp:
789         * jit/JITPropertyAccess32_64.cpp:
790
791 2016-04-11  Skachkov Oleksandr  <gskachkov@gmail.com>
792
793         Remove NewArrowFunction from DFG IR
794         https://bugs.webkit.org/show_bug.cgi?id=156439
795
796         Reviewed by Saam Barati.
797
798         It seems that NewArrowFunction was left in DFG IR during refactoring by mistake.
799
800         * dfg/DFGAbstractInterpreterInlines.h:
801         * dfg/DFGClobberize.h:
802         (JSC::DFG::clobberize):
803         * dfg/DFGClobbersExitState.cpp:
804         * dfg/DFGDoesGC.cpp:
805         * dfg/DFGFixupPhase.cpp:
806         * dfg/DFGMayExit.cpp:
807         * dfg/DFGNode.h:
808         (JSC::DFG::Node::convertToPhantomNewFunction):
809         * dfg/DFGNodeType.h:
810         * dfg/DFGObjectAllocationSinkingPhase.cpp:
811         * dfg/DFGPredictionPropagationPhase.cpp:
812         * dfg/DFGSafeToExecute.h:
813         * dfg/DFGSpeculativeJIT.cpp:
814         (JSC::DFG::SpeculativeJIT::compileNewFunction):
815         * dfg/DFGSpeculativeJIT32_64.cpp:
816         * dfg/DFGSpeculativeJIT64.cpp:
817         * dfg/DFGStoreBarrierInsertionPhase.cpp:
818         * dfg/DFGStructureRegistrationPhase.cpp:
819         * ftl/FTLCapabilities.cpp:
820         * ftl/FTLLowerDFGToB3.cpp:
821         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
822
823 2016-04-05  Oliver Hunt  <oliver@apple.com>
824
825         Remove compile time define for SEPARATED_HEAP
826         https://bugs.webkit.org/show_bug.cgi?id=155508
827
828         Reviewed by Mark Lam.
829
830         Remove the SEPARATED_HEAP compile time flag. The separated
831         heap is available, but off by default, on x86_64, ARMv7, and
832         ARM64.
833
834         Working through the issues that happened last time essentially
835         required implementing the ARMv7 path for the separated heap
836         just so I could find all the ways it was going wrong.
837
838         We fixed all the logic by making the branch and jump logic in
839         the linker and assemblers take two parameters, the location to
840         write to, and the location we'll actually be writing to. We 
841         need to do this because it's no longer sufficient to compute
842         jumps relative to region the linker is writing to.
843
844         The repatching jump, branch, and call functions only need the
845         executable address as the patching is performed directly using
846         performJITMemcpy function which works in terms of the executable
847         address.
848
849         There is no performance impact on jsc-benchmarks with the separate
850         heap either emabled or disabled.
851
852         * Configurations/FeatureDefines.xcconfig:
853         * assembler/ARM64Assembler.h:
854         (JSC::ARM64Assembler::linkJump):
855         (JSC::ARM64Assembler::linkCall):
856         (JSC::ARM64Assembler::relinkJump):
857         (JSC::ARM64Assembler::relinkCall):
858         (JSC::ARM64Assembler::link):
859         (JSC::ARM64Assembler::linkJumpOrCall):
860         (JSC::ARM64Assembler::linkCompareAndBranch):
861         (JSC::ARM64Assembler::linkConditionalBranch):
862         (JSC::ARM64Assembler::linkTestAndBranch):
863         (JSC::ARM64Assembler::relinkJumpOrCall):
864         * assembler/ARMv7Assembler.h:
865         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
866         (JSC::ARMv7Assembler::revertJumpTo_movT3):
867         (JSC::ARMv7Assembler::link):
868         (JSC::ARMv7Assembler::linkJump):
869         (JSC::ARMv7Assembler::relinkJump):
870         (JSC::ARMv7Assembler::repatchCompact):
871         (JSC::ARMv7Assembler::replaceWithJump):
872         (JSC::ARMv7Assembler::replaceWithLoad):
873         (JSC::ARMv7Assembler::replaceWithAddressComputation):
874         (JSC::ARMv7Assembler::setInt32):
875         (JSC::ARMv7Assembler::setUInt7ForLoad):
876         (JSC::ARMv7Assembler::isB):
877         (JSC::ARMv7Assembler::isBX):
878         (JSC::ARMv7Assembler::isMOV_imm_T3):
879         (JSC::ARMv7Assembler::isMOVT):
880         (JSC::ARMv7Assembler::isNOP_T1):
881         (JSC::ARMv7Assembler::isNOP_T2):
882         (JSC::ARMv7Assembler::linkJumpT1):
883         (JSC::ARMv7Assembler::linkJumpT2):
884         (JSC::ARMv7Assembler::linkJumpT3):
885         (JSC::ARMv7Assembler::linkJumpT4):
886         (JSC::ARMv7Assembler::linkConditionalJumpT4):
887         (JSC::ARMv7Assembler::linkBX):
888         (JSC::ARMv7Assembler::linkConditionalBX):
889         (JSC::ARMv7Assembler::linkJumpAbsolute):
890         * assembler/LinkBuffer.cpp:
891         (JSC::LinkBuffer::copyCompactAndLinkCode):
892         * assembler/MacroAssemblerARM64.h:
893         (JSC::MacroAssemblerARM64::link):
894         * assembler/MacroAssemblerARMv7.h:
895         (JSC::MacroAssemblerARMv7::link):
896         * jit/ExecutableAllocator.h:
897         (JSC::performJITMemcpy):
898         * jit/ExecutableAllocatorFixedVMPool.cpp:
899         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
900         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
901         (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
902         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
903         * runtime/Options.cpp:
904         (JSC::recomputeDependentOptions):
905         * runtime/Options.h:
906
907 2016-04-10  Filip Pizlo  <fpizlo@apple.com>
908
909         Clean up how we reason about the states of AccessCases
910         https://bugs.webkit.org/show_bug.cgi?id=156454
911
912         Reviewed by Mark Lam.
913         
914         Currently when we add an AccessCase to a PolymorphicAccess stub, we regenerate the stub.
915         That means that as we grow a stub to have N cases, we will do O(N^2) generation work. I want
916         to explore buffering AccessCases so that we can do O(N) generation work instead. But to
917         before I go there, I want to make sure that the statefulness of AccessCase makes sense. So,
918         I broke it down into three different states and added assertions about the transitions. I
919         also broke out a separate operation called AccessCase::commit(), which is the work that
920         cannot be buffered since there cannot be any JS effects between when the AccessCase was
921         created and when we do the work in commit().
922         
923         This opens up a fairly obvious path to buffering AccessCases: add them to the list without
924         regenerating. Then when we do eventually trigger regeneration, those cases will get cloned
925         and generated automagically. This patch doesn't implement this technique yet, but gives us
926         an opportunity to independently test the scaffolding necessary to do it.
927
928         This is perf-neutral on lots of tests.
929
930         * bytecode/PolymorphicAccess.cpp:
931         (JSC::AccessGenerationResult::dump):
932         (JSC::AccessCase::clone):
933         (JSC::AccessCase::commit):
934         (JSC::AccessCase::guardedByStructureCheck):
935         (JSC::AccessCase::dump):
936         (JSC::AccessCase::generateWithGuard):
937         (JSC::AccessCase::generate):
938         (JSC::AccessCase::generateImpl):
939         (JSC::PolymorphicAccess::regenerateWithCases):
940         (JSC::PolymorphicAccess::regenerate):
941         (WTF::printInternal):
942         * bytecode/PolymorphicAccess.h:
943         (JSC::AccessCase::type):
944         (JSC::AccessCase::state):
945         (JSC::AccessCase::offset):
946         (JSC::AccessCase::viaProxy):
947         (JSC::AccessCase::callLinkInfo):
948         * bytecode/StructureStubInfo.cpp:
949         (JSC::StructureStubInfo::addAccessCase):
950         * bytecode/Watchpoint.h:
951         * dfg/DFGOperations.cpp:
952         * jit/Repatch.cpp:
953         (JSC::repatchGetByID):
954         (JSC::repatchPutByID):
955         (JSC::repatchIn):
956         * runtime/VM.cpp:
957         (JSC::VM::dumpRegExpTrace):
958         (JSC::VM::ensureWatchpointSetForImpureProperty):
959         (JSC::VM::registerWatchpointForImpureProperty):
960         (JSC::VM::addImpureProperty):
961         * runtime/VM.h:
962
963 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
964
965         [CMake] Make FOLDER property INHERITED
966         https://bugs.webkit.org/show_bug.cgi?id=156460
967
968         Reviewed by Brent Fulgham.
969
970         * CMakeLists.txt:
971         * shell/CMakeLists.txt:
972         * shell/PlatformWin.cmake:
973         Set FOLDER property as a directory property not a target property
974
975 2016-04-09  Keith Miller  <keith_miller@apple.com>
976
977         tryGetById should be supported by the DFG/FTL
978         https://bugs.webkit.org/show_bug.cgi?id=156378
979
980         Reviewed by Filip Pizlo.
981
982         This patch adds support for tryGetById in the DFG/FTL. It adds a new DFG node
983         TryGetById, which acts similarly to the normal GetById DFG node. One key
984         difference between GetById and TryGetById is that in the LLInt and Baseline
985         we do not profile the result type. This profiling is unnessary for the current
986         use case of tryGetById, which is expected to be a strict equality comparision
987         against a specific object or undefined. In either case other DFG optimizations
988         will make this equally fast with or without the profiling information.
989
990         Additionally, this patch adds new reuse modes for JSValueRegsTemporary that take
991         an operand and attempt to reuse the registers for that operand if they are free
992         after the current DFG node.
993
994         * bytecode/GetByIdStatus.cpp:
995         (JSC::GetByIdStatus::computeFromLLInt):
996         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
997         * dfg/DFGAbstractInterpreterInlines.h:
998         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
999         * dfg/DFGByteCodeParser.cpp:
1000         (JSC::DFG::ByteCodeParser::handleGetById):
1001         (JSC::DFG::ByteCodeParser::parseBlock):
1002         * dfg/DFGCapabilities.cpp:
1003         (JSC::DFG::capabilityLevel):
1004         * dfg/DFGClobberize.h:
1005         (JSC::DFG::clobberize):
1006         * dfg/DFGDoesGC.cpp:
1007         (JSC::DFG::doesGC):
1008         * dfg/DFGFixupPhase.cpp:
1009         (JSC::DFG::FixupPhase::fixupNode):
1010         * dfg/DFGNode.h:
1011         (JSC::DFG::Node::hasIdentifier):
1012         * dfg/DFGNodeType.h:
1013         * dfg/DFGPredictionPropagationPhase.cpp:
1014         (JSC::DFG::PredictionPropagationPhase::propagate):
1015         * dfg/DFGSafeToExecute.h:
1016         (JSC::DFG::safeToExecute):
1017         * dfg/DFGSpeculativeJIT.cpp:
1018         (JSC::DFG::SpeculativeJIT::compileTryGetById):
1019         (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
1020         * dfg/DFGSpeculativeJIT.h:
1021         (JSC::DFG::GPRTemporary::operator=):
1022         * dfg/DFGSpeculativeJIT32_64.cpp:
1023         (JSC::DFG::SpeculativeJIT::cachedGetById):
1024         (JSC::DFG::SpeculativeJIT::compile):
1025         * dfg/DFGSpeculativeJIT64.cpp:
1026         (JSC::DFG::SpeculativeJIT::cachedGetById):
1027         (JSC::DFG::SpeculativeJIT::compile):
1028         * ftl/FTLCapabilities.cpp:
1029         (JSC::FTL::canCompile):
1030         * ftl/FTLLowerDFGToB3.cpp:
1031         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1032         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
1033         (JSC::FTL::DFG::LowerDFGToB3::getById):
1034         * jit/JITOperations.cpp:
1035         * jit/JITOperations.h:
1036         * tests/stress/try-get-by-id.js:
1037         (tryGetByIdTextStrict):
1038         (get let):
1039         (let.get createBuiltin):
1040         (get throw):
1041         (getCaller.obj.1.throw.new.Error): Deleted.
1042
1043 2016-04-09  Saam barati  <sbarati@apple.com>
1044
1045         Allocation sinking SSA Defs are allowed to have replacements
1046         https://bugs.webkit.org/show_bug.cgi?id=156444
1047
1048         Reviewed by Filip Pizlo.
1049
1050         Consider the following program and the annotations that explain why
1051         the SSA defs we create in allocation sinking can have replacements.
1052
1053         function foo(a1) {
1054             let o1 = {x: 20, y: 50};
1055             let o2 = {y: 40, o1: o1};
1056             let o3 = {};
1057         
1058             // We're Defing a new variable here, call it o3_field.
1059             // o3_field is defing the value that is the result of 
1060             // a GetByOffset that gets eliminated through allocation sinking.
1061             o3.field = o1.y;
1062         
1063             dontCSE();
1064         
1065             // This control flow is here to not allow the phase to consult
1066             // its local SSA mapping (which properly handles replacements)
1067             // for the value of o3_field.
1068             if (a1) {
1069                 a1 = true; 
1070             } else {
1071                 a1 = false;
1072             }
1073         
1074             // Here, we ask for the reaching def of o3_field, and assert
1075             // it doesn't have a replacement. It does have a replacement
1076             // though. The original Def was the GetByOffset. We replaced
1077             // that GetByOffset with the value of the o1_y variable.
1078             let value = o3.field;
1079             assert(value === 50);
1080         }
1081
1082         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1083         * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
1084         (dontCSE):
1085         (assert):
1086         (foo):
1087
1088 2016-04-09  Commit Queue  <commit-queue@webkit.org>
1089
1090         Unreviewed, rolling out r199242.
1091         https://bugs.webkit.org/show_bug.cgi?id=156442
1092
1093         Caused many many leaks (Requested by ap on #webkit).
1094
1095         Reverted changeset:
1096
1097         "Web Inspector: get rid of InspectorBasicValue and
1098         InspectorString subclasses"
1099         https://bugs.webkit.org/show_bug.cgi?id=156407
1100         http://trac.webkit.org/changeset/199242
1101
1102 2016-04-09  Filip Pizlo  <fpizlo@apple.com>
1103
1104         Debug JSC test failure: stress/multi-put-by-offset-reallocation-butterfly-cse.js.ftl-no-cjit-small-pool
1105         https://bugs.webkit.org/show_bug.cgi?id=156406
1106
1107         Reviewed by Saam Barati.
1108
1109         The failure was because the GC ran from within the butterfly allocation call in a put_by_id
1110         transition AccessCase that had to deal with indexing storage. When the GC runs in a call from a stub,
1111         then we need to be extra careful:
1112
1113         1) The GC may reset the IC and delete the stub. So, the stub needs to tell the GC that it might be on
1114            the stack during GC, so that the GC keeps it alive if it's currently running.
1115         
1116         2) If the stub uses (dereferences or stores) some object after the call, then we need to ensure that
1117            the stub routine knows about that object independently of the IC.
1118         
1119         In the case of put_by_id transitions that use a helper to allocate the butterfly, we have both
1120         issues. A long time ago, we had to deal with (2), and we still had code to handle that case, although
1121         it appears to be dead. This change revives that code and glues it together with PolymorphicAccess.
1122
1123         * bytecode/PolymorphicAccess.cpp:
1124         (JSC::AccessCase::alternateBase):
1125         (JSC::AccessCase::doesCalls):
1126         (JSC::AccessCase::couldStillSucceed):
1127         (JSC::AccessCase::generate):
1128         (JSC::PolymorphicAccess::regenerate):
1129         * bytecode/PolymorphicAccess.h:
1130         (JSC::AccessCase::customSlotBase):
1131         (JSC::AccessCase::isGetter):
1132         (JSC::AccessCase::doesCalls): Deleted.
1133         * jit/GCAwareJITStubRoutine.cpp:
1134         (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
1135         (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
1136         (JSC::MarkingGCAwareJITStubRoutine::~MarkingGCAwareJITStubRoutine):
1137         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
1138         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
1139         (JSC::createJITStubRoutine):
1140         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
1141         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
1142         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): Deleted.
1143         * jit/GCAwareJITStubRoutine.h:
1144         (JSC::createJITStubRoutine):
1145
1146 2016-04-08  Joseph Pecoraro  <pecoraro@apple.com>
1147
1148         Web Inspector: XHRs and Web Worker scripts are not searchable
1149         https://bugs.webkit.org/show_bug.cgi?id=154214
1150         <rdar://problem/24643587>
1151
1152         Reviewed by Timothy Hatcher.
1153
1154         * inspector/protocol/Page.json:
1155         Add optional requestId to search results properties and search
1156         parameters for when the frameId and url are not enough. XHR
1157         resources, and "Other" resources will use this.
1158
1159 2016-04-08  Guillaume Emont  <guijemont@igalia.com>
1160
1161         MIPS: support Signed cond in branchTest32()
1162         https://bugs.webkit.org/show_bug.cgi?id=156260
1163
1164         This is needed since r197688 makes use of it.
1165
1166         Reviewed by Mark Lam.
1167
1168         * assembler/MacroAssemblerMIPS.h:
1169         (JSC::MacroAssemblerMIPS::branchTest32):
1170
1171 2016-04-08  Alex Christensen  <achristensen@webkit.org>
1172
1173         Progress towards running CMake WebKit2 on Mac
1174         https://bugs.webkit.org/show_bug.cgi?id=156426
1175
1176         Reviewed by Tim Horton.
1177
1178         * PlatformMac.cmake:
1179
1180 2016-04-08  Saam barati  <sbarati@apple.com>
1181
1182         Debugger may dereference m_currentCallFrame even after the VM has gone idle
1183         https://bugs.webkit.org/show_bug.cgi?id=156413
1184
1185         Reviewed by Mark Lam.
1186
1187         There is a bug where the debugger may dereference its m_currentCallFrame
1188         pointer after that pointer becomes invalid to read from. This happens like so:
1189
1190         We may step over an instruction which causes the end of execution for the
1191         current program. This causes the VM to exit. Then, we perform a GC which
1192         causes us to collect the global object. The global object being collected
1193         causes us to detach the debugger. In detaching, we think we still have a 
1194         valid m_currentCallFrame, we dereference it, and crash. The solution is to
1195         make sure we're paused when dereferencing this pointer inside ::detach().
1196
1197         * debugger/Debugger.cpp:
1198         (JSC::Debugger::detach):
1199
1200 2016-04-08  Brian Burg  <bburg@apple.com>
1201
1202         Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
1203         https://bugs.webkit.org/show_bug.cgi?id=156407
1204         <rdar://problem/25627659>
1205
1206         Reviewed by Timothy Hatcher.
1207
1208         There's no point having these subclasses as they don't save any space.
1209         Add m_stringValue to the union and merge some implementations of writeJSON.
1210         Move uses of the subclass to InspectorValue and delete redundant methods.
1211         Now, most InspectorValue methods are non-virtual so they can be templated.
1212
1213         * bindings/ScriptValue.cpp:
1214         (Deprecated::jsToInspectorValue):
1215         * inspector/InjectedScriptBase.cpp:
1216         (Inspector::InjectedScriptBase::makeCall):
1217         Don't used deleted subclasses.
1218
1219         * inspector/InspectorValues.cpp:
1220         (Inspector::InspectorValue::null):
1221         (Inspector::InspectorValue::create):
1222         (Inspector::InspectorValue::asValue):
1223         (Inspector::InspectorValue::asBoolean):
1224         (Inspector::InspectorValue::asDouble):
1225         (Inspector::InspectorValue::asInteger):
1226         (Inspector::InspectorValue::asString):
1227         These only need one implementation now.
1228
1229         (Inspector::InspectorValue::writeJSON):
1230         Still a virtual method since Object and Array need their members.
1231
1232         (Inspector::InspectorObjectBase::InspectorObjectBase):
1233         (Inspector::InspectorBasicValue::asBoolean): Deleted.
1234         (Inspector::InspectorBasicValue::asDouble): Deleted.
1235         (Inspector::InspectorBasicValue::asInteger): Deleted.
1236         (Inspector::InspectorBasicValue::writeJSON): Deleted.
1237         (Inspector::InspectorString::asString): Deleted.
1238         (Inspector::InspectorString::writeJSON): Deleted.
1239         (Inspector::InspectorString::create): Deleted.
1240         (Inspector::InspectorBasicValue::create): Deleted.
1241
1242         * inspector/InspectorValues.h:
1243         (Inspector::InspectorObjectBase::setBoolean):
1244         (Inspector::InspectorObjectBase::setInteger):
1245         (Inspector::InspectorObjectBase::setDouble):
1246         (Inspector::InspectorObjectBase::setString):
1247         (Inspector::InspectorArrayBase::pushBoolean):
1248         (Inspector::InspectorArrayBase::pushInteger):
1249         (Inspector::InspectorArrayBase::pushDouble):
1250         (Inspector::InspectorArrayBase::pushString):
1251         Use new factory methods.
1252
1253         * replay/EncodedValue.cpp:
1254         (JSC::ScalarEncodingTraits<bool>::encodeValue):
1255         (JSC::ScalarEncodingTraits<double>::encodeValue):
1256         (JSC::ScalarEncodingTraits<float>::encodeValue):
1257         (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
1258         (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
1259         (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
1260         (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
1261         * replay/EncodedValue.h:
1262         Use new factory methods.
1263
1264 2016-04-08  Filip Pizlo  <fpizlo@apple.com>
1265
1266         Add IC support for arguments.length
1267         https://bugs.webkit.org/show_bug.cgi?id=156389
1268
1269         Reviewed by Geoffrey Garen.
1270         
1271         This adds support for caching accesses to arguments.length for both DirectArguments and
1272         ScopedArguments. In strict mode, we already cached these accesses since they were just
1273         normal properties.
1274
1275         Amazingly, we also already supported caching of overridden arguments.length in both
1276         DirectArguments and ScopedArguments. This is because when you override, the property gets
1277         materialized as a normal JS property and the structure is changed.
1278         
1279         This patch painstakingly preserves our previous caching of overridden length while
1280         introducing caching of non-overridden length (i.e. the common case). In fact, we even cache
1281         the case where it could either be overridden or not, since we just end up with an AccessCase
1282         for each and they cascade to each other.
1283
1284         This is a >3x speed-up on microbenchmarks that do arguments.length in a polymorphic context.
1285         Entirely monomorphic accesses were already handled by the DFG.
1286
1287         * bytecode/PolymorphicAccess.cpp:
1288         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1289         (JSC::AccessCase::guardedByStructureCheck):
1290         (JSC::AccessCase::generateWithGuard):
1291         (JSC::AccessCase::generate):
1292         (WTF::printInternal):
1293         * bytecode/PolymorphicAccess.h:
1294         * jit/ICStats.h:
1295         * jit/JITOperations.cpp:
1296         * jit/Repatch.cpp:
1297         (JSC::tryCacheGetByID):
1298         (JSC::tryCachePutByID):
1299         (JSC::tryRepatchIn):
1300         * tests/stress/direct-arguments-override-length-then-access-normal-length.js: Added.
1301         (args):
1302         (foo):
1303         (result.foo):
1304
1305 2016-04-08  Benjamin Poulain  <bpoulain@apple.com>
1306
1307         UInt32ToNumber should have an Int52 path
1308         https://bugs.webkit.org/show_bug.cgi?id=125704
1309
1310         Reviewed by Filip Pizlo.
1311
1312         When dealing with big numbers, fall back to Int52 instead
1313         of double when possible.
1314
1315         * dfg/DFGAbstractInterpreterInlines.h:
1316         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1317         * dfg/DFGFixupPhase.cpp:
1318         (JSC::DFG::FixupPhase::fixupNode):
1319         * dfg/DFGPredictionPropagationPhase.cpp:
1320         (JSC::DFG::PredictionPropagationPhase::propagate):
1321         * dfg/DFGSpeculativeJIT.cpp:
1322         (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
1323         * ftl/FTLLowerDFGToB3.cpp:
1324         (JSC::FTL::DFG::LowerDFGToB3::compileUInt32ToNumber):
1325
1326 2016-04-08  Brian Burg  <bburg@apple.com>
1327
1328         Web Inspector: protocol generator should emit an error when 'type' is used instead of '$ref'
1329         https://bugs.webkit.org/show_bug.cgi?id=156275
1330         <rdar://problem/25569331>
1331
1332         Reviewed by Darin Adler.
1333
1334         * inspector/protocol/Heap.json: Fix a mistake that's now caught by the protocol generator.
1335
1336         * inspector/scripts/codegen/models.py:
1337         (TypeReference.__init__): Check here if type_kind is on a whitelist of primitive types.
1338         (TypeReference.referenced_name): Update comment.
1339
1340         Add a new test specifically for the case when the type would otherwise be resolved. Rebaseline.
1341
1342         * inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Added.
1343         * inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error:
1344         * inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Added.
1345
1346 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1347
1348         Remove ENABLE(ENABLE_ES6_CLASS_SYNTAX) guards
1349         https://bugs.webkit.org/show_bug.cgi?id=156384
1350
1351         Reviewed by Ryosuke Niwa.
1352
1353         * Configurations/FeatureDefines.xcconfig:
1354         * features.json: Mark as Done.
1355         * parser/Parser.cpp:
1356         (JSC::Parser<LexerType>::parseExportDeclaration):
1357         (JSC::Parser<LexerType>::parseStatementListItem):
1358         (JSC::Parser<LexerType>::parsePrimaryExpression):
1359         (JSC::Parser<LexerType>::parseMemberExpression):
1360
1361 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1362
1363         Implementing caching transition puts that need to reallocate with indexing storage
1364         https://bugs.webkit.org/show_bug.cgi?id=130914
1365
1366         Reviewed by Saam Barati.
1367
1368         This enables the IC's put_by_id path to handle reallocating the out-of-line storage even if
1369         the butterfly has indexing storage. Like the DFG, we do this by calling operations that
1370         reallocate the butterfly. Those use JSObject API and do all of the nasty work for us, like
1371         triggering a barrier.
1372
1373         This does a bunch of refactoring to how PolymorphicAccess makes calls. It's a lot easier to
1374         do it now because the hard work is hidden under AccessGenerationState methods. This means
1375         that custom accessors now share logic with put_by_id transitions.
1376
1377         * bytecode/PolymorphicAccess.cpp:
1378         (JSC::AccessGenerationState::succeed):
1379         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1380         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
1381         (JSC::AccessGenerationState::originalCallSiteIndex):
1382         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1383         (JSC::AccessCase::AccessCase):
1384         (JSC::AccessCase::transition):
1385         (JSC::AccessCase::generate):
1386         (JSC::PolymorphicAccess::regenerate):
1387         * bytecode/PolymorphicAccess.h:
1388         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
1389         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
1390         * dfg/DFGOperations.cpp:
1391         * dfg/DFGOperations.h:
1392         * jit/JITOperations.cpp:
1393         * jit/JITOperations.h:
1394
1395 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1396
1397         Remote Inspector: When disallowing remote inspection on a debuggable, a listing is still sent to debuggers
1398         https://bugs.webkit.org/show_bug.cgi?id=156380
1399         <rdar://problem/25323727>
1400
1401         Reviewed by Timothy Hatcher.
1402
1403         * inspector/remote/RemoteInspector.mm:
1404         (Inspector::RemoteInspector::updateTarget):
1405         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1406         When a target has been updated and it no longer generates a listing,
1407         we should remove the old listing as that is now stale and should
1408         not be sent. Not generating a listing means this target is no
1409         longer allowed to be debugged.
1410
1411 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1412
1413         Web Inspector: Not necessary to validate webinspectord connection on iOS
1414         https://bugs.webkit.org/show_bug.cgi?id=156377
1415         <rdar://problem/25612460>
1416
1417         Reviewed by Simon Fraser.
1418
1419         * inspector/remote/RemoteInspectorXPCConnection.h:
1420         * inspector/remote/RemoteInspectorXPCConnection.mm:
1421         (Inspector::RemoteInspectorXPCConnection::handleEvent):
1422
1423 2016-04-07  Keith Miller  <keith_miller@apple.com>
1424
1425         Rename ArrayMode::supportsLength to supportsSelfLength
1426         https://bugs.webkit.org/show_bug.cgi?id=156374
1427
1428         Reviewed by Filip Pizlo.
1429
1430         The name supportsLength is confusing because TypedArray have a
1431         length function however it is on the prototype and not on the
1432         instance. supportsSelfLength makes more sense since we use the
1433         function during fixup to tell if we can intrinsic the length
1434         property lookup on self accesses.
1435
1436         * dfg/DFGArrayMode.h:
1437         (JSC::DFG::ArrayMode::supportsSelfLength):
1438         (JSC::DFG::ArrayMode::supportsLength): Deleted.
1439         * dfg/DFGFixupPhase.cpp:
1440         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
1441
1442 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1443
1444         Web Inspector: ProfileView source links are off by 1 line, worse in pretty printed code
1445         https://bugs.webkit.org/show_bug.cgi?id=156371
1446
1447         Reviewed by Timothy Hatcher.
1448
1449         * inspector/protocol/ScriptProfiler.json:
1450         Clarify that these locations are 1-based.
1451
1452 2016-04-07  Jon Davis  <jond@apple.com>
1453
1454         Add Web Animations API to Feature Status Page
1455         https://bugs.webkit.org/show_bug.cgi?id=156360
1456
1457         Reviewed by Timothy Hatcher.
1458
1459         * features.json:
1460
1461 2016-04-07  Saam barati  <sbarati@apple.com>
1462
1463         Invalid assertion inside DebuggerScope::getOwnPropertySlot
1464         https://bugs.webkit.org/show_bug.cgi?id=156357
1465
1466         Reviewed by Keith Miller.
1467
1468         The Type Profiler might profile JS code that uses DebuggerScope and accesses properties
1469         on it. Therefore, it may have a DebuggerScope object in its log. Objects in the log
1470         are subject to having their getOwnPropertySlot method called. Therefore, the DebuggerScope
1471         might not always be in a valid state when its getOwnPropertySlot method is called.
1472         Therefore, the assertion invalid.
1473
1474         * debugger/DebuggerScope.cpp:
1475         (JSC::DebuggerScope::getOwnPropertySlot):
1476
1477 2016-04-07  Saam barati  <sbarati@apple.com>
1478
1479         Initial implementation of annex b.3.3 behavior was incorrect
1480         https://bugs.webkit.org/show_bug.cgi?id=156276
1481
1482         Reviewed by Keith Miller.
1483
1484         I almost got annex B.3.3 correct in my first implementation.
1485         There is a subtlety here I got wrong. We always create a local binding for
1486         a function at the very beginning of execution of a block scope. So we
1487         hoist function declarations to their local binding within a given
1488         block scope. When we actually evaluate the function declaration statement
1489         itself, we must lookup the binding in the current scope, and bind the
1490         value to the binding in the "var" scope. We perform the following
1491         abstract operations when executing a function declaration statement.
1492
1493         f = lookupBindingInCurrentScope("func")
1494         store(varScope, "func", f)
1495
1496         I got this wrong by performing the store to the var binding at the beginning
1497         of the block scope instead of when we evaluate the function declaration statement.
1498         This behavior is observable. For example, a program could change the value
1499         of "func" before the actual function declaration statement executes.
1500         Consider the following two functions:
1501         ```
1502         function foo1() {
1503             // func === undefined
1504             {
1505                 // typeof func === "function"
1506                 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1507                 func = 20 // This sets the local "func" binding to 20.
1508             }
1509             // typeof func === "function"
1510         }
1511
1512         function foo2() {
1513             // func === undefined
1514             {
1515                 // typeof func === "function"
1516                 func = 20 // This sets the local "func" binding to 20.
1517                 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1518             }
1519             // func === 20
1520         }
1521         ```
1522
1523         * bytecompiler/BytecodeGenerator.cpp:
1524         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1525         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1526         * bytecompiler/BytecodeGenerator.h:
1527         (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
1528         * bytecompiler/NodesCodegen.cpp:
1529         (JSC::FuncDeclNode::emitBytecode):
1530         * tests/stress/sloppy-mode-function-hoisting.js:
1531         (test.foo):
1532         (test):
1533         (test.):
1534         (test.bar):
1535         (test.switch.case.0):
1536         (test.capFoo1):
1537         (test.switch.capFoo2):
1538         (test.outer):
1539         (foo):
1540
1541 2016-04-07  Alex Christensen  <achristensen@webkit.org>
1542
1543         Build fix after r199170
1544
1545         * CMakeLists.txt:
1546
1547 2016-04-07  Keith Miller  <keith_miller@apple.com>
1548
1549         We should support the ability to do a non-effectful getById
1550         https://bugs.webkit.org/show_bug.cgi?id=156116
1551
1552         Reviewed by Benjamin Poulain.
1553
1554         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
1555         useful because it enables us to take different code paths based on values that we would
1556         otherwise not be able to have knowledge of. This patch adds this new feature called
1557         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
1558         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
1559         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
1560         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
1561         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
1562         the global object that indicates we could not get the result.
1563
1564         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
1565         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
1566         get_by_id the same way we would for load and return the value at the appropriate offset.
1567         Additionally, in order to make sure the we can properly compare the GetterSetter object
1568         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
1569         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
1570         likely to have little to no impact on memory usage as normal accessors are generally rare.
1571
1572         * JavaScriptCore.xcodeproj/project.pbxproj:
1573         * builtins/BuiltinExecutableCreator.cpp: Added.
1574         (JSC::createBuiltinExecutable):
1575         * builtins/BuiltinExecutableCreator.h: Copied from Source/JavaScriptCore/builtins/BuiltinExecutables.h.
1576         * builtins/BuiltinExecutables.cpp:
1577         (JSC::BuiltinExecutables::createDefaultConstructor):
1578         (JSC::BuiltinExecutables::createBuiltinExecutable):
1579         (JSC::createBuiltinExecutable):
1580         (JSC::BuiltinExecutables::createExecutable):
1581         (JSC::createExecutableInternal): Deleted.
1582         * builtins/BuiltinExecutables.h:
1583         * bytecode/BytecodeIntrinsicRegistry.h:
1584         * bytecode/BytecodeList.json:
1585         * bytecode/BytecodeUseDef.h:
1586         (JSC::computeUsesForBytecodeOffset):
1587         (JSC::computeDefsForBytecodeOffset):
1588         * bytecode/CodeBlock.cpp:
1589         (JSC::CodeBlock::dumpBytecode):
1590         * bytecode/PolymorphicAccess.cpp:
1591         (JSC::AccessCase::tryGet):
1592         (JSC::AccessCase::generate):
1593         (WTF::printInternal):
1594         * bytecode/PolymorphicAccess.h:
1595         (JSC::AccessCase::isGet): Deleted.
1596         (JSC::AccessCase::isPut): Deleted.
1597         (JSC::AccessCase::isIn): Deleted.
1598         * bytecode/StructureStubInfo.cpp:
1599         (JSC::StructureStubInfo::reset):
1600         * bytecode/StructureStubInfo.h:
1601         * bytecompiler/BytecodeGenerator.cpp:
1602         (JSC::BytecodeGenerator::emitTryGetById):
1603         * bytecompiler/BytecodeGenerator.h:
1604         * bytecompiler/NodesCodegen.cpp:
1605         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
1606         * dfg/DFGSpeculativeJIT32_64.cpp:
1607         (JSC::DFG::SpeculativeJIT::cachedGetById):
1608         * dfg/DFGSpeculativeJIT64.cpp:
1609         (JSC::DFG::SpeculativeJIT::cachedGetById):
1610         * ftl/FTLLowerDFGToB3.cpp:
1611         (JSC::FTL::DFG::LowerDFGToB3::getById):
1612         * jit/JIT.cpp:
1613         (JSC::JIT::privateCompileMainPass):
1614         (JSC::JIT::privateCompileSlowCases):
1615         * jit/JIT.h:
1616         * jit/JITInlineCacheGenerator.cpp:
1617         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1618         * jit/JITInlineCacheGenerator.h:
1619         * jit/JITInlines.h:
1620         (JSC::JIT::callOperation):
1621         * jit/JITOperations.cpp:
1622         * jit/JITOperations.h:
1623         * jit/JITPropertyAccess.cpp:
1624         (JSC::JIT::emitGetByValWithCachedId):
1625         (JSC::JIT::emit_op_try_get_by_id):
1626         (JSC::JIT::emitSlow_op_try_get_by_id):
1627         (JSC::JIT::emit_op_get_by_id):
1628         * jit/JITPropertyAccess32_64.cpp:
1629         (JSC::JIT::emitGetByValWithCachedId):
1630         (JSC::JIT::emit_op_try_get_by_id):
1631         (JSC::JIT::emitSlow_op_try_get_by_id):
1632         (JSC::JIT::emit_op_get_by_id):
1633         * jit/Repatch.cpp:
1634         (JSC::repatchByIdSelfAccess):
1635         (JSC::appropriateOptimizingGetByIdFunction):
1636         (JSC::appropriateGenericGetByIdFunction):
1637         (JSC::tryCacheGetByID):
1638         (JSC::repatchGetByID):
1639         (JSC::resetGetByID):
1640         * jit/Repatch.h:
1641         * jsc.cpp:
1642         (GlobalObject::finishCreation):
1643         (functionGetGetterSetter):
1644         (functionCreateBuiltin):
1645         * llint/LLIntData.cpp:
1646         (JSC::LLInt::Data::performAssertions):
1647         * llint/LLIntSlowPaths.cpp:
1648         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1649         * llint/LLIntSlowPaths.h:
1650         * llint/LowLevelInterpreter.asm:
1651         * runtime/GetterSetter.cpp:
1652         * runtime/GetterSetter.h:
1653         * runtime/JSType.h:
1654         * runtime/PropertySlot.cpp:
1655         (JSC::PropertySlot::getPureResult):
1656         * runtime/PropertySlot.h:
1657         * runtime/ProxyObject.cpp:
1658         (JSC::ProxyObject::getOwnPropertySlotCommon):
1659         * tests/stress/try-get-by-id.js: Added.
1660         (tryGetByIdText):
1661         (getCaller.obj.1.throw.new.Error.let.func):
1662         (getCaller.obj.1.throw.new.Error):
1663         (throw.new.Error.get let):
1664         (throw.new.Error.):
1665         (throw.new.Error.let.get createBuiltin):
1666         (get let):
1667         (let.get createBuiltin):
1668         (let.func):
1669         (get let.func):
1670         (get throw):
1671
1672 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1673
1674         Rationalize the makeSpaceForCCall stuff
1675         https://bugs.webkit.org/show_bug.cgi?id=156352
1676
1677         Reviewed by Mark Lam.
1678
1679         I want to add more code to PolymorphicAccess that makes C calls, so that I can finally fix
1680         https://bugs.webkit.org/show_bug.cgi?id=130914 (allow transition caches to handle indexing
1681         headers).
1682
1683         When trying to understand what it takes to make a C call, I came across code that was making
1684         room on the stack for spilled arguments. This logic was guarded with some complicated
1685         condition. At first, I tried to just refactor the code so that the same ugly condition
1686         wouldn't have to be copy-pasted everywhere that we made C calls. But then I started thinking
1687         about the condition, and realized that it was probably wrong: if the outer PolymorphicAccess
1688         harness decides to reuse a register for the scratchGPR then the top of the stack will store
1689         the old value of scratchGPR, but the condition wouldn't necessarily trigger. So if the call
1690         then overwrote something on the stack, we'd have a bad time.
1691
1692         Making room on the stack for a call is a cheap operation. It's orders of magnitude cheaper
1693         than the rest of the call. Therefore, I think that it's best to just unconditionally make
1694         room on the stack.
1695
1696         This patch makes us do just that. I also made the relevant helpers not inline, because I
1697         think that we have too many inline methods in our assemblers. Now it's much easier to make
1698         C calls from PolymorphicAccess because you just call the AssemblyHelper methods for making
1699         space. There are no special conditions or anything like that.
1700
1701         * bytecode/PolymorphicAccess.cpp:
1702         (JSC::AccessCase::generate):
1703         * jit/AssemblyHelpers.cpp:
1704         (JSC::AssemblyHelpers::emitLoadStructure):
1705         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
1706         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
1707         (JSC::emitRandomThunkImpl):
1708         * jit/AssemblyHelpers.h:
1709         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): Deleted.
1710         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): Deleted.
1711
1712 2016-04-07  Commit Queue  <commit-queue@webkit.org>
1713
1714         Unreviewed, rolling out r199128 and r199141.
1715         https://bugs.webkit.org/show_bug.cgi?id=156348
1716
1717         Causes crashes on multiple webpages (Requested by keith_mi_ on
1718         #webkit).
1719
1720         Reverted changesets:
1721
1722         "[ES6] Add support for Symbol.isConcatSpreadable."
1723         https://bugs.webkit.org/show_bug.cgi?id=155351
1724         http://trac.webkit.org/changeset/199128
1725
1726         "Unreviewed, uncomment accidentally commented line in test."
1727         http://trac.webkit.org/changeset/199141
1728
1729 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1730
1731         Rationalize the handling of PutById transitions a bit
1732         https://bugs.webkit.org/show_bug.cgi?id=156330
1733
1734         Reviewed by Mark Lam.
1735
1736         * bytecode/PolymorphicAccess.cpp:
1737         (JSC::AccessCase::generate): Get rid of the specialized slow calls. We can just use the failAndIgnore jump target. We just need to make sure that we don't make observable effects until we're done with all of the fast path checks.
1738         * bytecode/StructureStubInfo.cpp:
1739         (JSC::StructureStubInfo::addAccessCase): MadeNoChanges indicates that we should keep trying to repatch. Currently PutById transitions might trigger the case that addAccessCase() sees null, if the transition involves an indexing header. Doing repatching in that case is probably not good. But, we should just fix this the right way eventually.
1740
1741 2016-04-07  Per Arne Vollan  <peavo@outlook.com>
1742
1743         [Win] Fix for JSC stress test failures.
1744         https://bugs.webkit.org/show_bug.cgi?id=156343
1745
1746         Reviewed by Filip Pizlo.
1747
1748         We need to make it clear to MSVC that the method loadPtr(ImplicitAddress address, RegisterID dest)
1749         should be used, and not loadPtr(const void* address, RegisterID dest).
1750
1751         * jit/CCallHelpers.cpp:
1752         (JSC::CCallHelpers::setupShadowChickenPacket):
1753
1754 2016-04-06  Benjamin Poulain  <bpoulain@apple.com>
1755
1756         [JSC] UInt32ToNumber should be NodeMustGenerate
1757         https://bugs.webkit.org/show_bug.cgi?id=156329
1758
1759         Reviewed by Filip Pizlo.
1760
1761         It exits on negative numbers on the integer path.
1762
1763         * dfg/DFGFixupPhase.cpp:
1764         (JSC::DFG::FixupPhase::fixupNode):
1765         * dfg/DFGNodeType.h:
1766
1767 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
1768
1769         Unreviewed, rolling out r199016.
1770         https://bugs.webkit.org/show_bug.cgi?id=156140
1771
1772         "Perf bots are down, so I can't re-land this right now."
1773
1774         Reverted changeset:
1775
1776         CopiedBlock should be 16kB
1777         https://bugs.webkit.org/show_bug.cgi?id=156168
1778         http://trac.webkit.org/changeset/199016
1779
1780 2016-04-06  Mark Lam  <mark.lam@apple.com>
1781
1782         String.prototype.match() should be calling internal function RegExpCreate.
1783         https://bugs.webkit.org/show_bug.cgi?id=156318
1784
1785         Reviewed by Filip Pizlo.
1786
1787         RegExpCreate is not the same as the RegExp constructor.  The current implementation
1788         invokes new @RegExp which calls the constructor.  This results in failures in
1789         es6/Proxy_internal_get_calls_String.prototype.match.js, and
1790         es6/Proxy_internal_get_calls_String.prototype.search.js due to observable side
1791         effects.
1792
1793         This patch fixes this by factoring out the part of the RegExp constructor that
1794         makes the RegExpCreate function, and changing String's match and search to call
1795         RegExpCreate instead in accordance with the ES6 spec. 
1796
1797         * builtins/StringPrototype.js:
1798         (match):
1799         (search):
1800         * runtime/CommonIdentifiers.h:
1801         * runtime/JSGlobalObject.cpp:
1802         (JSC::JSGlobalObject::init):
1803         * runtime/RegExpConstructor.cpp:
1804         (JSC::toFlags):
1805         (JSC::regExpCreate):
1806         (JSC::constructRegExp):
1807         (JSC::esSpecRegExpCreate):
1808         (JSC::constructWithRegExpConstructor):
1809         * runtime/RegExpConstructor.h:
1810         (JSC::isRegExp):
1811
1812 2016-04-06  Keith Miller  <keith_miller@apple.com>
1813
1814         Unreviewed, uncomment accidentally commented line in test.
1815
1816         * tests/stress/array-concat-spread-object.js:
1817
1818 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1819
1820         JSC should have a simple way of gathering IC statistics
1821         https://bugs.webkit.org/show_bug.cgi?id=156317
1822
1823         Reviewed by Benjamin Poulain.
1824
1825         This adds a cheap, runtime-enabled way of gathering statistics about why we take the slow
1826         paths for inline caches. This is complementary to our existing bytecode profiler. Eventually
1827         we may want to combine the two things.
1828         
1829         This is not a slow-down on anything because we only do extra work on IC slow paths and if
1830         it's disabled it's just a load-and-branch to skip the stats gathering code.
1831
1832         * CMakeLists.txt:
1833         * JavaScriptCore.xcodeproj/project.pbxproj:
1834         * jit/ICStats.cpp: Added.
1835         * jit/ICStats.h: Added.
1836         * jit/JITOperations.cpp:
1837         * runtime/JSCJSValue.h:
1838         * runtime/JSCJSValueInlines.h:
1839         (JSC::JSValue::inherits):
1840         (JSC::JSValue::classInfoOrNull):
1841         (JSC::JSValue::toThis):
1842         * runtime/Options.h:
1843
1844 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1845
1846         32-bit JSC stress/multi-put-by-offset-multiple-transitions.js failing
1847         https://bugs.webkit.org/show_bug.cgi?id=156292
1848
1849         Reviewed by Benjamin Poulain.
1850
1851         Make sure that we stash the callsite index before calling operationReallocateStorageAndFinishPut.
1852
1853         * bytecode/PolymorphicAccess.cpp:
1854         (JSC::AccessCase::generate):
1855
1856 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1857
1858         JSC test stress/arrowfunction-lexical-bind-superproperty.js failing
1859         https://bugs.webkit.org/show_bug.cgi?id=156309
1860
1861         Reviewed by Saam Barati.
1862
1863         Just be honest about the fact that the ArgumentCount and Callee parts of inline callframe runtime
1864         meta-data can be read at any time.
1865         
1866         We only have to say this for the inline callframe forms of ArgumentCount and Callee because we don't
1867         sink any part of the machine prologue. This change just prevents us from sinking the pseudoprologue
1868         of inlined varargs or closure calls.
1869
1870         Shockingly, this is not a regression on anything.
1871
1872         * dfg/DFGClobberize.h:
1873         (JSC::DFG::clobberize):
1874
1875 2016-03-29  Keith Miller  <keith_miller@apple.com>
1876
1877         [ES6] Add support for Symbol.isConcatSpreadable.
1878         https://bugs.webkit.org/show_bug.cgi?id=155351
1879
1880         Reviewed by Saam Barati.
1881
1882         This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
1883         Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
1884         a builtin performant. First, four new DFG intrinsics were added.
1885
1886         1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
1887            the Array.isArray function.
1888         2) IsJSArray: checks the first child is a JSArray object.
1889         3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
1890         4) CallObjectConstructor: an intrinsic of the Object constructor.
1891
1892         IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
1893         we are able to prove that the first child is an Array or for ToObject an Object.
1894
1895         In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
1896         code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
1897         were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
1898         the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
1899         into a contiguous array).
1900
1901         This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
1902         values onto the result array. This works roughly the same as the two array fast path using the same methodology
1903         to decide if we can memcpy the other butterfly into the result butterfly.
1904
1905         Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
1906         name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
1907         dataLog function on it.
1908
1909         Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
1910         JSValueOperand if the operand's use count is one.
1911
1912         * JavaScriptCore.xcodeproj/project.pbxproj:
1913         * builtins/ArrayPrototype.js:
1914         (concatSlowPath):
1915         (concat):
1916         * bytecode/BytecodeIntrinsicRegistry.cpp:
1917         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1918         * bytecode/BytecodeIntrinsicRegistry.h:
1919         * dfg/DFGAbstractInterpreterInlines.h:
1920         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1921         * dfg/DFGByteCodeParser.cpp:
1922         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1923         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1924         * dfg/DFGClobberize.h:
1925         (JSC::DFG::clobberize):
1926         * dfg/DFGDoesGC.cpp:
1927         (JSC::DFG::doesGC):
1928         * dfg/DFGFixupPhase.cpp:
1929         (JSC::DFG::FixupPhase::fixupNode):
1930         * dfg/DFGNodeType.h:
1931         * dfg/DFGOperations.cpp:
1932         * dfg/DFGOperations.h:
1933         * dfg/DFGPredictionPropagationPhase.cpp:
1934         (JSC::DFG::PredictionPropagationPhase::propagate):
1935         * dfg/DFGSafeToExecute.h:
1936         (JSC::DFG::safeToExecute):
1937         * dfg/DFGSpeculativeJIT.cpp:
1938         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1939         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
1940         (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
1941         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
1942         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
1943         * dfg/DFGSpeculativeJIT.h:
1944         (JSC::DFG::SpeculativeJIT::callOperation):
1945         * dfg/DFGSpeculativeJIT32_64.cpp:
1946         (JSC::DFG::SpeculativeJIT::compile):
1947         * dfg/DFGSpeculativeJIT64.cpp:
1948         (JSC::DFG::SpeculativeJIT::compile):
1949         * ftl/FTLCapabilities.cpp:
1950         (JSC::FTL::canCompile):
1951         * ftl/FTLLowerDFGToB3.cpp:
1952         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1953         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
1954         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
1955         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
1956         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
1957         (JSC::FTL::DFG::LowerDFGToB3::isArray):
1958         * jit/JITOperations.h:
1959         * jsc.cpp:
1960         (WTF::RuntimeArray::createStructure):
1961         (GlobalObject::finishCreation):
1962         (functionDebug):
1963         (functionDataLogValue):
1964         * runtime/ArrayConstructor.cpp:
1965         (JSC::ArrayConstructor::finishCreation):
1966         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
1967         * runtime/ArrayConstructor.h:
1968         (JSC::isArrayConstructor):
1969         * runtime/ArrayPrototype.cpp:
1970         (JSC::ArrayPrototype::finishCreation):
1971         (JSC::arrayProtoPrivateFuncIsJSArray):
1972         (JSC::moveElements):
1973         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1974         (JSC::arrayProtoPrivateFuncAppendMemcpy):
1975         (JSC::arrayProtoFuncConcat): Deleted.
1976         * runtime/ArrayPrototype.h:
1977         (JSC::ArrayPrototype::createStructure):
1978         * runtime/CommonIdentifiers.h:
1979         * runtime/Intrinsic.h:
1980         * runtime/JSArray.cpp:
1981         (JSC::JSArray::appendMemcpy):
1982         (JSC::JSArray::fastConcatWith): Deleted.
1983         * runtime/JSArray.h:
1984         (JSC::JSArray::createStructure):
1985         (JSC::JSArray::fastConcatType): Deleted.
1986         * runtime/JSArrayInlines.h: Added.
1987         (JSC::JSArray::memCopyWithIndexingType):
1988         (JSC::JSArray::canFastCopy):
1989         * runtime/JSGlobalObject.cpp:
1990         (JSC::JSGlobalObject::init):
1991         * runtime/JSType.h:
1992         * runtime/ObjectConstructor.h:
1993         (JSC::constructObject):
1994         * tests/es6.yaml:
1995         * tests/stress/array-concat-spread-object.js: Added.
1996         (arrayEq):
1997         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
1998         (arrayEq):
1999         * tests/stress/array-concat-spread-proxy.js: Added.
2000         (arrayEq):
2001         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
2002         (arrayEq):
2003         * tests/stress/array-species-config-array-constructor.js:
2004
2005 2016-04-06  Commit Queue  <commit-queue@webkit.org>
2006
2007         Unreviewed, rolling out r199070.
2008         https://bugs.webkit.org/show_bug.cgi?id=156324
2009
2010         "It didn't fix the timeout" (Requested by saamyjoon on
2011         #webkit).
2012
2013         Reverted changeset:
2014
2015         "jsc-layout-tests.yaml/js/script-tests/regress-141098.js
2016         failing on Yosemite Debug after r198989"
2017         https://bugs.webkit.org/show_bug.cgi?id=156187
2018         http://trac.webkit.org/changeset/199070
2019
2020 2016-04-06  Geoffrey Garen  <ggaren@apple.com>
2021
2022         Unreviewed, rolling in r199016.
2023         https://bugs.webkit.org/show_bug.cgi?id=156140
2024
2025         It might work this time without regression because 16kB aligned requests
2026         now take the allocation fast path.
2027
2028         Restored changeset:
2029
2030         CopiedBlock should be 16kB
2031         https://bugs.webkit.org/show_bug.cgi?id=156168
2032         http://trac.webkit.org/changeset/199016
2033
2034 2016-04-06  Mark Lam  <mark.lam@apple.com>
2035
2036         Update es6.yaml to expect es6/Proxy_internal_get_calls_RegExp_constructor.js to pass.
2037         https://bugs.webkit.org/show_bug.cgi?id=156314
2038
2039         Reviewed by Saam Barati.
2040
2041         * tests/es6.yaml:
2042
2043 2016-04-06  Commit Queue  <commit-queue@webkit.org>
2044
2045         Unreviewed, rolling out r199104.
2046         https://bugs.webkit.org/show_bug.cgi?id=156301
2047
2048         Still breaks internal builds (Requested by keith_miller on
2049         #webkit).
2050
2051         Reverted changeset:
2052
2053         "We should support the ability to do a non-effectful getById"
2054         https://bugs.webkit.org/show_bug.cgi?id=156116
2055         http://trac.webkit.org/changeset/199104
2056
2057 2016-04-06  Keith Miller  <keith_miller@apple.com>
2058
2059         RegExp constructor should use Symbol.match and other properties
2060         https://bugs.webkit.org/show_bug.cgi?id=155873
2061
2062         Reviewed by Michael Saboff.
2063
2064         This patch updates the behavior of the RegExp constructor. Now the constructor
2065         should get the Symbol.match property and check if it exists to decide if something
2066         should be constructed like a regexp object.
2067
2068         * runtime/RegExpConstructor.cpp:
2069         (JSC::toFlags):
2070         (JSC::constructRegExp):
2071         (JSC::constructWithRegExpConstructor):
2072         (JSC::callRegExpConstructor):
2073         * runtime/RegExpConstructor.h:
2074         * tests/stress/regexp-constructor.js: Added.
2075         (assert):
2076         (throw.new.Error.get let):
2077         (throw.new.Error.):
2078         (throw.new.Error.get re):
2079
2080 2016-04-06  Keith Miller  <keith_miller@apple.com>
2081
2082         We should support the ability to do a non-effectful getById
2083         https://bugs.webkit.org/show_bug.cgi?id=156116
2084
2085         Reviewed by Benjamin Poulain.
2086
2087         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
2088         useful because it enables us to take different code paths based on values that we would
2089         otherwise not be able to have knowledge of. This patch adds this new feature called
2090         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
2091         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
2092         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
2093         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
2094         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
2095         the global object that indicates we could not get the result.
2096
2097         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
2098         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
2099         get_by_id the same way we would for load and return the value at the appropriate offset.
2100         Additionally, in order to make sure the we can properly compare the GetterSetter object
2101         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
2102         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
2103         likely to have little to no impact on memory usage as normal accessors are generally rare.
2104
2105         * builtins/BuiltinExecutables.cpp:
2106         (JSC::BuiltinExecutables::createDefaultConstructor):
2107         (JSC::BuiltinExecutables::createBuiltinExecutable):
2108         (JSC::createBuiltinExecutable):
2109         (JSC::BuiltinExecutables::createExecutable):
2110         (JSC::createExecutableInternal): Deleted.
2111         * builtins/BuiltinExecutables.h:
2112         * bytecode/BytecodeIntrinsicRegistry.h:
2113         * bytecode/BytecodeList.json:
2114         * bytecode/BytecodeUseDef.h:
2115         (JSC::computeUsesForBytecodeOffset):
2116         (JSC::computeDefsForBytecodeOffset):
2117         * bytecode/CodeBlock.cpp:
2118         (JSC::CodeBlock::dumpBytecode):
2119         * bytecode/PolymorphicAccess.cpp:
2120         (JSC::AccessCase::tryGet):
2121         (JSC::AccessCase::generate):
2122         (WTF::printInternal):
2123         * bytecode/PolymorphicAccess.h:
2124         (JSC::AccessCase::isGet): Deleted.
2125         (JSC::AccessCase::isPut): Deleted.
2126         (JSC::AccessCase::isIn): Deleted.
2127         * bytecode/StructureStubInfo.cpp:
2128         (JSC::StructureStubInfo::reset):
2129         * bytecode/StructureStubInfo.h:
2130         * bytecompiler/BytecodeGenerator.cpp:
2131         (JSC::BytecodeGenerator::emitTryGetById):
2132         * bytecompiler/BytecodeGenerator.h:
2133         * bytecompiler/NodesCodegen.cpp:
2134         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
2135         * dfg/DFGSpeculativeJIT32_64.cpp:
2136         (JSC::DFG::SpeculativeJIT::cachedGetById):
2137         * dfg/DFGSpeculativeJIT64.cpp:
2138         (JSC::DFG::SpeculativeJIT::cachedGetById):
2139         * ftl/FTLLowerDFGToB3.cpp:
2140         (JSC::FTL::DFG::LowerDFGToB3::getById):
2141         * jit/JIT.cpp:
2142         (JSC::JIT::privateCompileMainPass):
2143         (JSC::JIT::privateCompileSlowCases):
2144         * jit/JIT.h:
2145         * jit/JITInlineCacheGenerator.cpp:
2146         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2147         * jit/JITInlineCacheGenerator.h:
2148         * jit/JITInlines.h:
2149         (JSC::JIT::callOperation):
2150         * jit/JITOperations.cpp:
2151         * jit/JITOperations.h:
2152         * jit/JITPropertyAccess.cpp:
2153         (JSC::JIT::emitGetByValWithCachedId):
2154         (JSC::JIT::emit_op_try_get_by_id):
2155         (JSC::JIT::emitSlow_op_try_get_by_id):
2156         (JSC::JIT::emit_op_get_by_id):
2157         * jit/JITPropertyAccess32_64.cpp:
2158         (JSC::JIT::emitGetByValWithCachedId):
2159         (JSC::JIT::emit_op_try_get_by_id):
2160         (JSC::JIT::emitSlow_op_try_get_by_id):
2161         (JSC::JIT::emit_op_get_by_id):
2162         * jit/Repatch.cpp:
2163         (JSC::repatchByIdSelfAccess):
2164         (JSC::appropriateOptimizingGetByIdFunction):
2165         (JSC::appropriateGenericGetByIdFunction):
2166         (JSC::tryCacheGetByID):
2167         (JSC::repatchGetByID):
2168         (JSC::resetGetByID):
2169         * jit/Repatch.h:
2170         * jsc.cpp:
2171         (GlobalObject::finishCreation):
2172         (functionGetGetterSetter):
2173         (functionCreateBuiltin):
2174         * llint/LLIntData.cpp:
2175         (JSC::LLInt::Data::performAssertions):
2176         * llint/LLIntSlowPaths.cpp:
2177         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2178         * llint/LLIntSlowPaths.h:
2179         * llint/LowLevelInterpreter.asm:
2180         * runtime/GetterSetter.cpp:
2181         * runtime/GetterSetter.h:
2182         * runtime/JSType.h:
2183         * runtime/PropertySlot.cpp:
2184         (JSC::PropertySlot::getPureResult):
2185         * runtime/PropertySlot.h:
2186         * runtime/ProxyObject.cpp:
2187         (JSC::ProxyObject::getOwnPropertySlotCommon):
2188         * tests/stress/try-get-by-id.js: Added.
2189         (tryGetByIdText):
2190         (getCaller.obj.1.throw.new.Error.let.func):
2191         (getCaller.obj.1.throw.new.Error):
2192         (throw.new.Error.get let):
2193         (throw.new.Error.):
2194         (throw.new.Error.let.get createBuiltin):
2195         (get let):
2196         (let.get createBuiltin):
2197         (let.func):
2198         (get let.func):
2199         (get throw):
2200
2201 2016-04-05  Chris Dumez  <cdumez@apple.com>
2202
2203         Add support for [EnabledAtRuntime] operations on DOMWindow
2204         https://bugs.webkit.org/show_bug.cgi?id=156272
2205
2206         Reviewed by Alex Christensen.
2207
2208         Add identifier for 'fetch' so it can be used from the generated
2209         bindings.
2210
2211         * runtime/CommonIdentifiers.h:
2212
2213 2016-04-05  Alex Christensen  <achristensen@webkit.org>
2214
2215         Make CMake-generated binaries on Mac able to run
2216         https://bugs.webkit.org/show_bug.cgi?id=156268
2217
2218         Reviewed by Daniel Bates.
2219
2220         * CMakeLists.txt:
2221
2222 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2223
2224         Improve some other cases of context-sensitive inlining
2225         https://bugs.webkit.org/show_bug.cgi?id=156277
2226
2227         Reviewed by Benjamin Poulain.
2228         
2229         This implements some improvements for inlining:
2230
2231         - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have
2232           been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to
2233           err on the side of not inlining.
2234         
2235         - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block
2236           increases the chances of the parser seeing the callee constant. While inlining doesn't require a
2237           callee constant, sometimes it makes a difference. Note that we were previously breaking the block
2238           for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then
2239           the parser will automatically break the block for us. There is no reason to add any block breaking
2240           ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a
2241           check and falling through.
2242         
2243         - get_by_id handling now tries to apply some common sense to its status object. In particular, if
2244           the source is a NewObject and there was no interfering operation that could clobber the structure,
2245           then we know which case of a polymorphic GetByIdStatus we would take. This arises in some
2246           constructor patterns.
2247         
2248         Long term, we should address all of these cases comprehensively by having a late inliner. The inliner
2249         being part of the bytecode parser means that there is a lot of complexity in the parser and it
2250         prevents us from inlining upon learning new information from static analysis. But for now, I think
2251         it's fine to experiment with one-off hacks, if only to learn what the possibilities are.
2252         
2253         This is a 14% speed-up on Octane/raytrace.
2254
2255         * bytecode/CallLinkStatus.cpp:
2256         (JSC::CallLinkStatus::dump):
2257         * bytecode/CallLinkStatus.h:
2258         (JSC::CallLinkStatus::couldTakeSlowPath):
2259         (JSC::CallLinkStatus::setCouldTakeSlowPath):
2260         (JSC::CallLinkStatus::variants):
2261         (JSC::CallLinkStatus::size):
2262         (JSC::CallLinkStatus::at):
2263         * bytecode/GetByIdStatus.cpp:
2264         (JSC::GetByIdStatus::makesCalls):
2265         (JSC::GetByIdStatus::filter):
2266         (JSC::GetByIdStatus::dump):
2267         * bytecode/GetByIdStatus.h:
2268         (JSC::GetByIdStatus::wasSeenInJIT):
2269         * dfg/DFGByteCodeParser.cpp:
2270         (JSC::DFG::ByteCodeParser::handleCall):
2271         (JSC::DFG::ByteCodeParser::refineStatically):
2272         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2273         (JSC::DFG::ByteCodeParser::handleInlining):
2274         (JSC::DFG::ByteCodeParser::handleGetById):
2275         (JSC::DFG::ByteCodeParser::parseBlock):
2276         * runtime/Options.h:
2277
2278 2016-04-05  Saam barati  <sbarati@apple.com>
2279
2280         JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples
2281         https://bugs.webkit.org/show_bug.cgi?id=154017
2282
2283         Reviewed by Geoffrey Garen.
2284
2285         By moving to an explicitly created seperate thread + sample-then-sleep
2286         loop, we can remove a lot of the crufty code around WorkQueue.
2287         We're also getting sample rates that are much closer to what we're
2288         asking the OS for. When the sampling handler was built off of WorkQueue,
2289         we'd often get sample rates much higher than the 1ms we asked for. On Kraken,
2290         we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate.
2291         Now, on Kraken, we're getting about 1.2ms rates. Because we're getting
2292         higher rates, this patch is a performance regression. It's slower because
2293         we're sampling more frequently.
2294
2295         Before this patch, the sampling profiler had the following overhead:
2296         - 10% on Kraken
2297         - 12% on octane
2298         - 15% on AsmBench
2299
2300         With this patch, the sampling profiler has the following overhead:
2301         - 16% on Kraken
2302         - 17% on Octane
2303         - 30% on AsmBench
2304
2305         Comparatively, this new patch has the following overhead over the old sampling profiler:
2306         - 5% on Kraken
2307         - 3.5% on Octane
2308         - 13% slower on AsmBench
2309
2310         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2311         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2312         * runtime/SamplingProfiler.cpp:
2313         (JSC::SamplingProfiler::SamplingProfiler):
2314         (JSC::SamplingProfiler::~SamplingProfiler):
2315         (JSC::SamplingProfiler::createThreadIfNecessary):
2316         (JSC::SamplingProfiler::timerLoop):
2317         (JSC::SamplingProfiler::takeSample):
2318         (JSC::tryGetBytecodeIndex):
2319         (JSC::SamplingProfiler::shutdown):
2320         (JSC::SamplingProfiler::start):
2321         (JSC::SamplingProfiler::pause):
2322         (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
2323         (JSC::SamplingProfiler::noticeJSLockAcquisition):
2324         (JSC::SamplingProfiler::noticeVMEntry):
2325         (JSC::SamplingProfiler::clearData):
2326         (JSC::SamplingProfiler::stop): Deleted.
2327         (JSC::SamplingProfiler::dispatchIfNecessary): Deleted.
2328         (JSC::SamplingProfiler::dispatchFunction): Deleted.
2329         * runtime/SamplingProfiler.h:
2330         (JSC::SamplingProfiler::setTimingInterval):
2331         (JSC::SamplingProfiler::setStopWatch):
2332         * runtime/VM.cpp:
2333         (JSC::VM::VM):
2334
2335 2016-04-05  Commit Queue  <commit-queue@webkit.org>
2336
2337         Unreviewed, rolling out r199073.
2338         https://bugs.webkit.org/show_bug.cgi?id=156261
2339
2340         This change broke internal Mac builds (Requested by ryanhaddad
2341         on #webkit).
2342
2343         Reverted changeset:
2344
2345         "We should support the ability to do a non-effectful getById"
2346         https://bugs.webkit.org/show_bug.cgi?id=156116
2347         http://trac.webkit.org/changeset/199073
2348
2349 2016-04-05  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2350
2351         [Fetch API] Add a runtime flag to fetch API and related constructs
2352         https://bugs.webkit.org/show_bug.cgi?id=156113
2353  
2354         Reviewed by Alex Christensen.
2355
2356         Add a fetch API runtime flag based on preferences.
2357         Disable fetch API by default.
2358  
2359         * runtime/CommonIdentifiers.h:
2360
2361 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2362
2363         Unreviewed, fix cloop some more.
2364
2365         * runtime/RegExpInlines.h:
2366         (JSC::RegExp::hasCodeFor):
2367         (JSC::RegExp::hasMatchOnlyCodeFor):
2368
2369 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2370
2371         Unreviewed, fix cloop.
2372
2373         * jit/CCallHelpers.cpp:
2374
2375 2016-03-18  Filip Pizlo  <fpizlo@apple.com>
2376
2377         JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames
2378         https://bugs.webkit.org/show_bug.cgi?id=155598
2379
2380         Reviewed by Saam Barati.
2381         
2382         JSC is the first JSVM to have proper tail calls. This means that error.stack and the
2383         debugger will appear to "delete" strict mode stack frames, if the call that this frame made
2384         was in tail position. This is exactly what functional programmers expect - they don't want
2385         the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever
2386         using tail calls. It's also something that non-functional programmers fear. It's not clear
2387         that tail-deleted frames would actually degrade the debugging experience, but the fear is
2388         real, so it's worthwhile to do something about it.
2389
2390         It turns out that there is at least one tail call implementation that doesn't suffer from
2391         this problem. It implements proper tail calls in the sense that you won't run out of memory
2392         by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so
2393         long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my
2394         favorite hacks:
2395         
2396         http://www.more-magic.net/posts/internals-gc.html
2397
2398         CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple
2399         one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that
2400         frame only once we proved that there was insufficient memory to keep it around.
2401         
2402         CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we
2403         can have arbitrary native code, and that native code does not have relocatable stack frames.
2404         
2405         But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a
2406         VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra
2407         information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its
2408         layout. The main stack can then continue to obey ABI rules.
2409
2410         This patch implements a mechanism for being able to display stack traces that include
2411         tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all
2412         frames all the time, though we will collect the tail-deleted ones if the stack gets too big.
2413         This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack.
2414         
2415         ShadowChicken is always on, but individual CodeBlocks may make their own choices about
2416         whether to opt into it. They will do that at bytecompile time based on the debugger mode on
2417         their global object.
2418
2419         When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing
2420         in that case. Well, except when exceptions are thrown. Then it might do some work, but it's
2421         minor.
2422
2423         When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable
2424         this all the time, but it's low enough to justify enabling in the Inspector. It's currently
2425         enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the
2426         debugger is on.
2427
2428         Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have
2429         no logging. This is essential since we *can* have debugging enabled in one GlobalObject and
2430         disabled in another. Also, some frames don't do ShadowChicken because they just haven't been
2431         hacked to do it yet. Native frames fall into this category, as do the VM entry frames.
2432
2433         This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It
2434         just makes a ShadowChicken stack walk function available to jsc. It's used from the
2435         shadow-chicken tests.
2436
2437         * API/JSContextRef.cpp:
2438         (BacktraceFunctor::BacktraceFunctor):
2439         (BacktraceFunctor::operator()):
2440         (JSContextCreateBacktrace):
2441         * CMakeLists.txt:
2442         * JavaScriptCore.xcodeproj/project.pbxproj:
2443         * bytecode/BytecodeList.json:
2444         * bytecode/BytecodeUseDef.h:
2445         (JSC::computeUsesForBytecodeOffset):
2446         (JSC::computeDefsForBytecodeOffset):
2447         * bytecode/CodeBlock.cpp:
2448         (JSC::CodeBlock::dumpBytecode):
2449         (JSC::RecursionCheckFunctor::RecursionCheckFunctor):
2450         (JSC::RecursionCheckFunctor::operator()):
2451         (JSC::CodeBlock::noticeIncomingCall):
2452         * bytecompiler/BytecodeGenerator.cpp:
2453         (JSC::BytecodeGenerator::emitEnter):
2454         (JSC::BytecodeGenerator::emitCallInTailPosition):
2455         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2456         (JSC::BytecodeGenerator::emitCallVarargs):
2457         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
2458         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
2459         (JSC::BytecodeGenerator::emitCallDefineProperty):
2460         * bytecompiler/BytecodeGenerator.h:
2461         * debugger/DebuggerCallFrame.cpp:
2462         (JSC::LineAndColumnFunctor::operator()):
2463         (JSC::LineAndColumnFunctor::column):
2464         (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor):
2465         (JSC::FindCallerMidStackFunctor::operator()):
2466         (JSC::DebuggerCallFrame::DebuggerCallFrame):
2467         * dfg/DFGAbstractInterpreterInlines.h:
2468         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2469         * dfg/DFGByteCodeParser.cpp:
2470         (JSC::DFG::ByteCodeParser::parseBlock):
2471         * dfg/DFGClobberize.h:
2472         (JSC::DFG::clobberize):
2473         * dfg/DFGDoesGC.cpp:
2474         (JSC::DFG::doesGC):
2475         * dfg/DFGFixupPhase.cpp:
2476         (JSC::DFG::FixupPhase::fixupNode):
2477         * dfg/DFGNodeType.h:
2478         * dfg/DFGPredictionPropagationPhase.cpp:
2479         (JSC::DFG::PredictionPropagationPhase::propagate):
2480         * dfg/DFGSafeToExecute.h:
2481         (JSC::DFG::safeToExecute):
2482         * dfg/DFGSpeculativeJIT32_64.cpp:
2483         (JSC::DFG::SpeculativeJIT::compile):
2484         * dfg/DFGSpeculativeJIT64.cpp:
2485         (JSC::DFG::SpeculativeJIT::compile):
2486         * ftl/FTLAbstractHeapRepository.cpp:
2487         * ftl/FTLAbstractHeapRepository.h:
2488         * ftl/FTLCapabilities.cpp:
2489         (JSC::FTL::canCompile):
2490         * ftl/FTLLowerDFGToB3.cpp:
2491         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2492         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2493         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
2494         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
2495         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2496         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2497         (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket):
2498         (JSC::FTL::DFG::LowerDFGToB3::boolify):
2499         * heap/Heap.cpp:
2500         (JSC::Heap::markRoots):
2501         (JSC::Heap::visitSamplingProfiler):
2502         (JSC::Heap::visitShadowChicken):
2503         (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
2504         (JSC::Heap::collectImpl):
2505         * heap/Heap.h:
2506         * inspector/ScriptCallStackFactory.cpp:
2507         (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor):
2508         (Inspector::CreateScriptCallStackFunctor::operator()):
2509         (Inspector::createScriptCallStack):
2510         * interpreter/CallFrame.h:
2511         (JSC::ExecState::iterate):
2512         * interpreter/Interpreter.cpp:
2513         (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
2514         (JSC::DumpRegisterFunctor::operator()):
2515         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
2516         (JSC::GetStackTraceFunctor::operator()):
2517         (JSC::Interpreter::getStackTrace):
2518         (JSC::GetCatchHandlerFunctor::handler):
2519         (JSC::GetCatchHandlerFunctor::operator()):
2520         (JSC::notifyDebuggerOfUnwinding):
2521         (JSC::UnwindFunctor::UnwindFunctor):
2522         (JSC::UnwindFunctor::operator()):
2523         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
2524         * interpreter/ShadowChicken.cpp: Added.
2525         (JSC::ShadowChicken::Packet::dump):
2526         (JSC::ShadowChicken::Frame::dump):
2527         (JSC::ShadowChicken::ShadowChicken):
2528         (JSC::ShadowChicken::~ShadowChicken):
2529         (JSC::ShadowChicken::log):
2530         (JSC::ShadowChicken::update):
2531         (JSC::ShadowChicken::visitChildren):
2532         (JSC::ShadowChicken::reset):
2533         (JSC::ShadowChicken::dump):
2534         (JSC::ShadowChicken::functionsOnStack):
2535         * interpreter/ShadowChicken.h: Added.
2536         (JSC::ShadowChicken::Packet::Packet):
2537         (JSC::ShadowChicken::Packet::tailMarker):
2538         (JSC::ShadowChicken::Packet::throwMarker):
2539         (JSC::ShadowChicken::Packet::prologue):
2540         (JSC::ShadowChicken::Packet::tail):
2541         (JSC::ShadowChicken::Packet::throwPacket):
2542         (JSC::ShadowChicken::Packet::operator bool):
2543         (JSC::ShadowChicken::Packet::isPrologue):
2544         (JSC::ShadowChicken::Packet::isTail):
2545         (JSC::ShadowChicken::Packet::isThrow):
2546         (JSC::ShadowChicken::Frame::Frame):
2547         (JSC::ShadowChicken::Frame::operator==):
2548         (JSC::ShadowChicken::Frame::operator!=):
2549         (JSC::ShadowChicken::log):
2550         (JSC::ShadowChicken::logSize):
2551         (JSC::ShadowChicken::addressOfLogCursor):
2552         (JSC::ShadowChicken::logEnd):
2553         * interpreter/ShadowChickenInlines.h: Added.
2554         (JSC::ShadowChicken::iterate):
2555         * interpreter/StackVisitor.h:
2556         (JSC::StackVisitor::Frame::callee):
2557         (JSC::StackVisitor::Frame::codeBlock):
2558         (JSC::StackVisitor::Frame::bytecodeOffset):
2559         (JSC::StackVisitor::Frame::inlineCallFrame):
2560         (JSC::StackVisitor::Frame::isJSFrame):
2561         (JSC::StackVisitor::Frame::isInlinedFrame):
2562         (JSC::StackVisitor::visit):
2563         * jit/CCallHelpers.cpp: Added.
2564         (JSC::CCallHelpers::logShadowChickenProloguePacket):
2565         (JSC::CCallHelpers::logShadowChickenTailPacket):
2566         (JSC::CCallHelpers::setupShadowChickenPacket):
2567         * jit/CCallHelpers.h:
2568         (JSC::CCallHelpers::prepareForTailCallSlow):
2569         * jit/JIT.cpp:
2570         (JSC::JIT::privateCompileMainPass):
2571         * jit/JIT.h:
2572         * jit/JITExceptions.cpp:
2573         (JSC::genericUnwind):
2574         * jit/JITOpcodes.cpp:
2575         (JSC::JIT::emit_op_resume):
2576         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2577         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2578         * jit/JITOperations.cpp:
2579         * jit/JITOperations.h:
2580         * jsc.cpp:
2581         (GlobalObject::finishCreation):
2582         (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
2583         (FunctionJSCStackFunctor::operator()):
2584         (functionClearSamplingFlags):
2585         (functionShadowChickenFunctionsOnStack):
2586         (functionReadline):
2587         * llint/LLIntOffsetsExtractor.cpp:
2588         * llint/LLIntSlowPaths.cpp:
2589         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2590         (JSC::LLInt::llint_throw_stack_overflow_error):
2591         * llint/LLIntSlowPaths.h:
2592         * llint/LowLevelInterpreter.asm:
2593         * profiler/ProfileGenerator.cpp:
2594         (JSC::AddParentForConsoleStartFunctor::foundParent):
2595         (JSC::AddParentForConsoleStartFunctor::operator()):
2596         * runtime/Error.cpp:
2597         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
2598         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
2599         (JSC::addErrorInfoAndGetBytecodeOffset):
2600         * runtime/JSFunction.cpp:
2601         (JSC::RetrieveArgumentsFunctor::result):
2602         (JSC::RetrieveArgumentsFunctor::operator()):
2603         (JSC::retrieveArguments):
2604         (JSC::RetrieveCallerFunctionFunctor::result):
2605         (JSC::RetrieveCallerFunctionFunctor::operator()):
2606         (JSC::retrieveCallerFunction):
2607         * runtime/JSGlobalObjectFunctions.cpp:
2608         (JSC::GlobalFuncProtoGetterFunctor::result):
2609         (JSC::GlobalFuncProtoGetterFunctor::operator()):
2610         (JSC::globalFuncProtoGetter):
2611         (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
2612         (JSC::GlobalFuncProtoSetterFunctor::operator()):
2613         * runtime/NullSetterFunction.cpp:
2614         (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
2615         (JSC::GetCallerStrictnessFunctor::operator()):
2616         (JSC::GetCallerStrictnessFunctor::callerIsStrict):
2617         (JSC::callerIsStrict):
2618         * runtime/ObjectConstructor.cpp:
2619         (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
2620         (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
2621         (JSC::objectConstructorGetPrototypeOf):
2622         * runtime/Options.h:
2623         * runtime/VM.cpp:
2624         (JSC::VM::VM):
2625         (JSC::SetEnabledProfilerFunctor::operator()):
2626         * runtime/VM.h:
2627         (JSC::VM::shouldBuilderPCToCodeOriginMapping):
2628         (JSC::VM::bytecodeIntrinsicRegistry):
2629         (JSC::VM::shadowChicken):
2630         * tests/stress/resources/shadow-chicken-support.js: Added.
2631         (describeFunction):
2632         (describeArray):
2633         (expectStack):
2634         (initialize):
2635         * tests/stress/shadow-chicken-disabled.js: Added.
2636         (test1.foo):
2637         (test1.bar):
2638         (test1.baz):
2639         (test1):
2640         (test2.foo):
2641         (test2.bar):
2642         (test2.baz):
2643         (test2):
2644         (test3.foo):
2645         (test3.bar):
2646         (test3.baz):
2647         (test3):
2648         * tests/stress/shadow-chicken-enabled.js: Added.
2649         (test1.foo):
2650         (test1.bar):
2651         (test1.baz):
2652         (test1):
2653         (test2.foo):
2654         (test2.bar):
2655         (test2.baz):
2656         (test2):
2657         (test3.bob):
2658         (test3.thingy):
2659         (test3.foo):
2660         (test3.bar):
2661         (test3.baz):
2662         (test3):
2663         (test4.bob):
2664         (test4.thingy):
2665         (test4.foo):
2666         (test4.bar):
2667         (test4.baz):
2668         (test4):
2669         (test5.foo):
2670         (test5):
2671         * tools/JSDollarVMPrototype.cpp:
2672         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2673         (JSC::CallerFrameJITTypeFunctor::operator()):
2674         (JSC::CallerFrameJITTypeFunctor::jitType):
2675         (JSC::functionLLintTrue):
2676         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2677         (JSC::CellAddressCheckFunctor::operator()):
2678         (JSC::JSDollarVMPrototype::isValidCell):
2679         (JSC::JSDollarVMPrototype::isValidCodeBlock):
2680         (JSC::JSDollarVMPrototype::codeBlockForFrame):
2681         (JSC::PrintFrameFunctor::PrintFrameFunctor):
2682         (JSC::PrintFrameFunctor::operator()):
2683         (JSC::printCallFrame):
2684
2685 2016-03-19  Filip Pizlo  <fpizlo@apple.com>
2686
2687         DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace
2688         https://bugs.webkit.org/show_bug.cgi?id=155270
2689
2690         Reviewed by Saam Barati.
2691
2692         This enables constant-folding of RegExpExec, RegExpTest, and StringReplace.
2693
2694         It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding
2695         strings gave the DFG an API for reasoning about JSString constants in terms of
2696         JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR
2697         based on the results.
2698
2699         But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must
2700         use the same Structure that the code would have used or else we'll pollute the program's
2701         inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named
2702         properties in one go - we don't want to lose that optimization. So, this patch enables
2703         MaterializeNewObject to allocate objects or arrays with any number of indexed or named
2704         properties. Previously it could only handle objects (but not arrays) and named properties
2705         (but not indexed ones).
2706
2707         This also adds a few minor things for setting the RegExpConstructor cached result.
2708
2709         This is about a 2x speed-up on microbenchmarks when we fold a match success and about a
2710         8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp.
2711
2712         * JavaScriptCore.xcodeproj/project.pbxproj:
2713         * dfg/DFGAbstractInterpreterInlines.h:
2714         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2715         * dfg/DFGClobberize.h:
2716         (JSC::DFG::clobberize):
2717         * dfg/DFGDoesGC.cpp:
2718         (JSC::DFG::doesGC):
2719         * dfg/DFGFixupPhase.cpp:
2720         (JSC::DFG::FixupPhase::fixupNode):
2721         * dfg/DFGGraph.cpp:
2722         (JSC::DFG::Graph::dump):
2723         * dfg/DFGInsertionSet.cpp:
2724         (JSC::DFG::InsertionSet::insertSlow):
2725         (JSC::DFG::InsertionSet::execute):
2726         * dfg/DFGInsertionSet.h:
2727         (JSC::DFG::InsertionSet::insertCheck):
2728         * dfg/DFGLazyJSValue.cpp:
2729         (JSC::DFG::LazyJSValue::tryGetString):
2730         * dfg/DFGMayExit.cpp:
2731         (JSC::DFG::mayExit):
2732         * dfg/DFGNode.h:
2733         (JSC::DFG::StackAccessData::flushedAt):
2734         (JSC::DFG::OpInfo::OpInfo): Deleted.
2735         * dfg/DFGNodeType.h:
2736         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2737         * dfg/DFGObjectMaterializationData.cpp:
2738         (JSC::DFG::ObjectMaterializationData::dump):
2739         (JSC::DFG::PhantomPropertyValue::dump): Deleted.
2740         (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted.
2741         (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted.
2742         * dfg/DFGObjectMaterializationData.h:
2743         (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted.
2744         (JSC::DFG::PhantomPropertyValue::operator==): Deleted.
2745         * dfg/DFGOpInfo.h: Added.
2746         (JSC::DFG::OpInfo::OpInfo):
2747         * dfg/DFGOperations.cpp:
2748         * dfg/DFGOperations.h:
2749         * dfg/DFGPredictionPropagationPhase.cpp:
2750         (JSC::DFG::PredictionPropagationPhase::propagate):
2751         * dfg/DFGPromotedHeapLocation.cpp:
2752         (WTF::printInternal):
2753         * dfg/DFGPromotedHeapLocation.h:
2754         * dfg/DFGSafeToExecute.h:
2755         (JSC::DFG::safeToExecute):
2756         * dfg/DFGSpeculativeJIT.cpp:
2757         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
2758         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
2759         (JSC::DFG::SpeculativeJIT::emitGetLength):
2760         (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
2761         (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
2762         (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
2763         (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted.
2764         * dfg/DFGSpeculativeJIT.h:
2765         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
2766         * dfg/DFGSpeculativeJIT32_64.cpp:
2767         (JSC::DFG::SpeculativeJIT::compile):
2768         * dfg/DFGSpeculativeJIT64.cpp:
2769         (JSC::DFG::SpeculativeJIT::compile):
2770         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2771         * dfg/DFGStrengthReductionPhase.cpp:
2772         (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
2773         (JSC::DFG::StrengthReductionPhase::handleNode):
2774         (JSC::DFG::StrengthReductionPhase::handleCommutativity):
2775         (JSC::DFG::StrengthReductionPhase::executeInsertionSet):
2776         * dfg/DFGValidate.cpp:
2777         (JSC::DFG::Validate::validate):
2778         (JSC::DFG::Validate::validateCPS):
2779         * ftl/FTLAbstractHeapRepository.cpp:
2780         * ftl/FTLAbstractHeapRepository.h:
2781         * ftl/FTLCapabilities.cpp:
2782         (JSC::FTL::canCompile):
2783         * ftl/FTLLowerDFGToB3.cpp:
2784         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2785         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
2786         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
2787         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
2788         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2789         (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
2790         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2791         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
2792         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2793         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
2794         (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
2795         (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
2796         * ftl/FTLOperations.cpp:
2797         (JSC::FTL::operationPopulateObjectInOSR):
2798         (JSC::FTL::operationNewObjectWithButterfly): Deleted.
2799         * ftl/FTLOperations.h:
2800         * inspector/ContentSearchUtilities.cpp:
2801         * runtime/JSObject.h:
2802         (JSC::JSObject::createRawObject):
2803         (JSC::JSFinalObject::create):
2804         * runtime/RegExp.cpp:
2805         (JSC::RegExp::compile):
2806         (JSC::RegExp::match):
2807         (JSC::RegExp::matchConcurrently):
2808         (JSC::RegExp::compileMatchOnly):
2809         (JSC::RegExp::deleteCode):
2810         * runtime/RegExp.h:
2811         * runtime/RegExpCachedResult.h:
2812         (JSC::RegExpCachedResult::offsetOfLastRegExp):
2813         (JSC::RegExpCachedResult::offsetOfLastInput):
2814         (JSC::RegExpCachedResult::offsetOfResult):
2815         (JSC::RegExpCachedResult::offsetOfReified):
2816         * runtime/RegExpConstructor.h:
2817         (JSC::RegExpConstructor::offsetOfCachedResult):
2818         * runtime/RegExpInlines.h:
2819         (JSC::RegExp::hasCodeFor):
2820         (JSC::RegExp::compileIfNecessary):
2821         (JSC::RegExp::matchInline):
2822         (JSC::RegExp::hasMatchOnlyCodeFor):
2823         (JSC::RegExp::compileIfNecessaryMatchOnly):
2824         * runtime/RegExpObjectInlines.h:
2825         (JSC::RegExpObject::execInline):
2826         * runtime/StringPrototype.cpp:
2827         (JSC::substituteBackreferencesSlow):
2828         (JSC::substituteBackreferencesInline):
2829         (JSC::substituteBackreferences):
2830         (JSC::StringRange::StringRange):
2831         * runtime/StringPrototype.h:
2832         * runtime/VM.h:
2833         * tests/stress/simple-regexp-exec-folding-fail.js: Added.
2834         (foo):
2835         * tests/stress/simple-regexp-exec-folding.js: Added.
2836         (foo):
2837         * tests/stress/simple-regexp-test-folding-fail.js: Added.
2838         (foo):
2839         * tests/stress/simple-regexp-test-folding.js: Added.
2840         (foo):
2841         * yarr/RegularExpression.cpp:
2842         * yarr/Yarr.h:
2843         * yarr/YarrInterpreter.cpp:
2844         (JSC::Yarr::Interpreter::interpret):
2845         (JSC::Yarr::ByteCompiler::ByteCompiler):
2846         (JSC::Yarr::ByteCompiler::compile):
2847         (JSC::Yarr::ByteCompiler::checkInput):
2848         (JSC::Yarr::byteCompile):
2849         (JSC::Yarr::interpret):
2850         * yarr/YarrInterpreter.h:
2851         (JSC::Yarr::BytecodePattern::BytecodePattern):
2852
2853 2016-04-05  Keith Miller  <keith_miller@apple.com>
2854
2855         We should support the ability to do a non-effectful getById
2856         https://bugs.webkit.org/show_bug.cgi?id=156116
2857
2858         Reviewed by Benjamin Poulain.
2859
2860         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
2861         useful because it enables us to take different code paths based on values that we would
2862         otherwise not be able to have knowledge of. This patch adds this new feature called
2863         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
2864         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
2865         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
2866         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
2867         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
2868         the global object that indicates we could not get the result.
2869
2870         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
2871         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
2872         get_by_id the same way we would for load and return the value at the appropriate offset.
2873         Additionally, in order to make sure the we can properly compare the GetterSetter object
2874         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
2875         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
2876         likely to have little to no impact on memory usage as normal accessors are generally rare.
2877
2878         * JavaScriptCore.xcodeproj/project.pbxproj:
2879         * builtins/BuiltinExecutables.cpp:
2880         (JSC::BuiltinExecutables::createDefaultConstructor):
2881         (JSC::BuiltinExecutables::createBuiltinExecutable):
2882         (JSC::createBuiltinExecutable):
2883         (JSC::BuiltinExecutables::createExecutable):
2884         (JSC::createExecutableInternal): Deleted.
2885         * builtins/BuiltinExecutables.h:
2886         * bytecode/BytecodeIntrinsicRegistry.h:
2887         * bytecode/BytecodeList.json:
2888         * bytecode/BytecodeUseDef.h:
2889         (JSC::computeUsesForBytecodeOffset):
2890         (JSC::computeDefsForBytecodeOffset):
2891         * bytecode/CodeBlock.cpp:
2892         (JSC::CodeBlock::dumpBytecode):
2893         * bytecode/PolymorphicAccess.cpp:
2894         (JSC::AccessCase::tryGet):
2895         (JSC::AccessCase::generate):
2896         (WTF::printInternal):
2897         * bytecode/PolymorphicAccess.h:
2898         (JSC::AccessCase::isGet): Deleted.
2899         (JSC::AccessCase::isPut): Deleted.
2900         (JSC::AccessCase::isIn): Deleted.
2901         * bytecode/StructureStubInfo.cpp:
2902         (JSC::StructureStubInfo::reset):
2903         * bytecode/StructureStubInfo.h:
2904         * bytecompiler/BytecodeGenerator.cpp:
2905         (JSC::BytecodeGenerator::emitTryGetById):
2906         * bytecompiler/BytecodeGenerator.h:
2907         * bytecompiler/NodesCodegen.cpp:
2908         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
2909         * dfg/DFGSpeculativeJIT32_64.cpp:
2910         (JSC::DFG::SpeculativeJIT::cachedGetById):
2911         * dfg/DFGSpeculativeJIT64.cpp:
2912         (JSC::DFG::SpeculativeJIT::cachedGetById):
2913         * ftl/FTLLowerDFGToB3.cpp:
2914         (JSC::FTL::DFG::LowerDFGToB3::getById):
2915         * jit/JIT.cpp:
2916         (JSC::JIT::privateCompileMainPass):
2917         (JSC::JIT::privateCompileSlowCases):
2918         * jit/JIT.h:
2919         * jit/JITInlineCacheGenerator.cpp:
2920         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2921         * jit/JITInlineCacheGenerator.h:
2922         * jit/JITInlines.h:
2923         (JSC::JIT::callOperation):
2924         * jit/JITOperations.cpp:
2925         * jit/JITOperations.h:
2926         * jit/JITPropertyAccess.cpp:
2927         (JSC::JIT::emitGetByValWithCachedId):
2928         (JSC::JIT::emit_op_try_get_by_id):
2929         (JSC::JIT::emitSlow_op_try_get_by_id):
2930         (JSC::JIT::emit_op_get_by_id):
2931         * jit/JITPropertyAccess32_64.cpp:
2932         (JSC::JIT::emitGetByValWithCachedId):
2933         (JSC::JIT::emit_op_try_get_by_id):
2934         (JSC::JIT::emitSlow_op_try_get_by_id):
2935         (JSC::JIT::emit_op_get_by_id):
2936         * jit/Repatch.cpp:
2937         (JSC::repatchByIdSelfAccess):
2938         (JSC::appropriateOptimizingGetByIdFunction):
2939         (JSC::appropriateGenericGetByIdFunction):
2940         (JSC::tryCacheGetByID):
2941         (JSC::repatchGetByID):
2942         (JSC::resetGetByID):
2943         * jit/Repatch.h:
2944         * jsc.cpp:
2945         (GlobalObject::finishCreation):
2946         (functionGetGetterSetter):
2947         (functionCreateBuiltin):
2948         * llint/LLIntData.cpp:
2949         (JSC::LLInt::Data::performAssertions):
2950         * llint/LLIntSlowPaths.cpp:
2951         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2952         * llint/LLIntSlowPaths.h:
2953         * llint/LowLevelInterpreter.asm:
2954         * runtime/GetterSetter.cpp:
2955         * runtime/GetterSetter.h:
2956         * runtime/JSType.h:
2957         * runtime/PropertySlot.cpp:
2958         (JSC::PropertySlot::getPureResult):
2959         * runtime/PropertySlot.h:
2960         * runtime/ProxyObject.cpp:
2961         (JSC::ProxyObject::getOwnPropertySlotCommon):
2962         * tests/stress/try-get-by-id.js: Added.
2963         (tryGetByIdText):
2964         (getCaller.obj.1.throw.new.Error.let.func):
2965         (getCaller.obj.1.throw.new.Error):
2966         (throw.new.Error.get let):
2967         (throw.new.Error.):
2968         (throw.new.Error.let.get createBuiltin):
2969         (get let):
2970         (let.get createBuiltin):
2971         (let.func):
2972         (get let.func):
2973         (get throw):
2974
2975 2016-04-05  Saam barati  <sbarati@apple.com>
2976
2977         jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989
2978         https://bugs.webkit.org/show_bug.cgi?id=156187
2979
2980         Reviewed by Filip Pizlo.
2981
2982         This is a speculative fix. Lets see if the prevents the timeout.
2983
2984         * parser/Parser.cpp:
2985         (JSC::Parser<LexerType>::parseStatementListItem):
2986
2987 2016-04-04  Filip Pizlo  <fpizlo@apple.com>
2988
2989         PolymorphicAccess should have a MegamorphicLoad case
2990         https://bugs.webkit.org/show_bug.cgi?id=156182
2991
2992         Reviewed by Geoffrey Garen and Keith Miller.
2993
2994         This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in
2995         the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than
2996         calling into C++ to do the same job - particularly since inlining the lookup into an access means
2997         that we can precompute the hash code.
2998
2999         When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not
3000         optimal. It used a double-hashing method for reducing collision pathologies. This is great for
3001         improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we
3002         want to optimize the average-case performance. When optimizing for average-case, we can choose to
3003         either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the
3004         worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high
3005         probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case
3006         pathology only makes sense if it also preserves the good performance of the fast case, or reduces the
3007         likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in
3008         the fast case.
3009
3010         I don't believe, based on looking at how the double-hashing is implemented, that it's possible that
3011         this preserves the good performance of the fast case. It requires at least one more value to be live
3012         around the loop, and dramatically increases the register pressure at key points inside the loop. The
3013         biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if
3014         the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere
3015         then we will pay a steep price anytime we take the second iteration around the loop; but if the
3016         compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on
3017         some architectures (I performed biological register allocation and found that I needed 9 registers
3018         for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might
3019         be better off).
3020
3021         Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down
3022         on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill.
3023
3024         There are some other small changes in this patch, like rationalizing the IC's choice between giving
3025         up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can
3026         try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to
3027         choose between those options, but we weren't fully taking advantage of it because the
3028         regenerateWithCase() method just returned null for any failure, and didn't say whether it was the
3029         sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now
3030         this is all made explicit. I wanted to make sure this change happened in this patch since the
3031         MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since
3032         this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure
3033         that the rules for giving up were something that made sense to me.
3034         
3035         This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight
3036         speed-up for page loading, because many real websites like to have megamorphic property accesses.
3037
3038         * bytecode/PolymorphicAccess.cpp:
3039         (JSC::AccessGenerationResult::dump):
3040         (JSC::AccessGenerationState::addWatchpoint):
3041         (JSC::AccessCase::get):
3042         (JSC::AccessCase::megamorphicLoad):
3043         (JSC::AccessCase::replace):
3044         (JSC::AccessCase::guardedByStructureCheck):
3045         (JSC::AccessCase::couldStillSucceed):
3046         (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
3047         (JSC::AccessCase::canReplace):
3048         (JSC::AccessCase::generateWithGuard):
3049         (JSC::AccessCase::generate):
3050         (JSC::PolymorphicAccess::PolymorphicAccess):
3051         (JSC::PolymorphicAccess::~PolymorphicAccess):
3052         (JSC::PolymorphicAccess::regenerateWithCases):
3053         (JSC::PolymorphicAccess::regenerateWithCase):
3054         (WTF::printInternal):
3055         * bytecode/PolymorphicAccess.h:
3056         (JSC::AccessCase::isGet):
3057         (JSC::AccessCase::isPut):
3058         (JSC::AccessCase::isIn):
3059         (JSC::AccessGenerationResult::AccessGenerationResult):
3060         (JSC::AccessGenerationResult::operator==):
3061         (JSC::AccessGenerationResult::operator!=):
3062         (JSC::AccessGenerationResult::operator bool):
3063         (JSC::AccessGenerationResult::kind):
3064         (JSC::AccessGenerationResult::code):
3065         (JSC::AccessGenerationResult::madeNoChanges):
3066         (JSC::AccessGenerationResult::gaveUp):
3067         (JSC::AccessGenerationResult::generatedNewCode):
3068         (JSC::PolymorphicAccess::isEmpty):
3069         (JSC::AccessGenerationState::AccessGenerationState):
3070         * bytecode/StructureStubInfo.cpp:
3071         (JSC::StructureStubInfo::aboutToDie):
3072         (JSC::StructureStubInfo::addAccessCase):
3073         * bytecode/StructureStubInfo.h:
3074         * jit/AssemblyHelpers.cpp:
3075         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
3076         (JSC::AssemblyHelpers::loadProperty):
3077         (JSC::emitRandomThunkImpl):
3078         (JSC::AssemblyHelpers::emitRandomThunk):
3079         (JSC::AssemblyHelpers::emitLoadStructure):
3080         * jit/AssemblyHelpers.h:
3081         (JSC::AssemblyHelpers::loadValue):
3082         (JSC::AssemblyHelpers::moveValueRegs):
3083         (JSC::AssemblyHelpers::argumentsStart):
3084         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
3085         (JSC::AssemblyHelpers::emitLoadStructure): Deleted.
3086         * jit/GPRInfo.cpp:
3087         (JSC::JSValueRegs::dump):
3088         * jit/GPRInfo.h:
3089         (JSC::JSValueRegs::uses):
3090         * jit/Repatch.cpp:
3091         (JSC::replaceWithJump):
3092         (JSC::tryCacheGetByID):
3093         (JSC::tryCachePutByID):
3094         (JSC::tryRepatchIn):
3095         * jit/ThunkGenerators.cpp:
3096         (JSC::virtualThunkFor):
3097         * runtime/Options.h:
3098         * runtime/PropertyMapHashTable.h:
3099         (JSC::PropertyTable::begin):
3100         (JSC::PropertyTable::find):
3101         (JSC::PropertyTable::get):
3102         * runtime/Structure.h:
3103
3104 2016-04-05  Antoine Quint  <graouts@apple.com>
3105
3106         [WebGL2] Turn the ENABLE_WEBGL2 flag on
3107         https://bugs.webkit.org/show_bug.cgi?id=156061
3108         <rdar://problem/25463193>
3109
3110         Reviewed by Alex Christensen.
3111
3112         * Configurations/FeatureDefines.xcconfig:
3113         * runtime/CommonIdentifiers.h:
3114
3115         Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject. 
3116
3117 2016-04-04  Zan Dobersek  <zdobersek@igalia.com>
3118
3119         Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads
3120         https://bugs.webkit.org/show_bug.cgi?id=156161
3121
3122         Reviewed by Yusuke Suzuki.
3123
3124         r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads
3125         that handle arguments split into the tag and the payload. The two were split
3126         between the last argument register and the stack on 32-bit ARM EABI systems,
3127         causing incorrect behavior.
3128
3129         Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the
3130         stack, removing the issue.
3131
3132         * dfg/DFGSpeculativeJIT.h:
3133         (JSC::DFG::SpeculativeJIT::callOperation):
3134
3135 2016-04-04  Joseph Pecoraro  <pecoraro@apple.com>
3136
3137         Avoid copying ModuleLoaderObject.js to resources bundle
3138         https://bugs.webkit.org/show_bug.cgi?id=156188
3139         <rdar://problem/25534383>
3140
3141         Reviewed by Alexey Proskuryakov.
3142
3143         * JavaScriptCore.xcodeproj/project.pbxproj:
3144
3145 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
3146
3147         Unreviewed, rolling out r199016.
3148         https://bugs.webkit.org/show_bug.cgi?id=156140
3149
3150         "Regressed Octane and Kraken on the perf bots."
3151
3152         Reverted changeset:
3153
3154         CopiedBlock should be 16kB
3155         https://bugs.webkit.org/show_bug.cgi?id=156168
3156         http://trac.webkit.org/changeset/199016
3157
3158 2016-04-04  Benjamin Poulain  <bpoulain@apple.com>
3159
3160         [JSC][x86] Fix an assertion in MacroAssembler::branch8()
3161         https://bugs.webkit.org/show_bug.cgi?id=156181
3162
3163         Reviewed by Geoffrey Garen.
3164
3165         * assembler/MacroAssemblerX86Common.h:
3166         (JSC::MacroAssemblerX86Common::branch8):
3167         The test was wrong because valid negative numbers have ones
3168         in the top bits.
3169
3170         I replaced the assertion to be explicit about the valid range.
3171
3172 2016-04-04  Chris Dumez  <cdumez@apple.com>
3173
3174         Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings
3175         https://bugs.webkit.org/show_bug.cgi?id=156136
3176         <rdar://problem/25410767>
3177
3178         Reviewed by Ryosuke Niwa.
3179
3180         Add a few more identifiers for using in the generated bindings.
3181
3182         * runtime/CommonIdentifiers.h:
3183
3184 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
3185
3186         CopiedBlock should be 16kB
3187         https://bugs.webkit.org/show_bug.cgi?id=156168
3188
3189         Reviewed by Mark Lam.
3190
3191         MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB,
3192         and the largest page size on Apple devices is 16kB -- so this change
3193         should improve sharing and recycling and keep us on the fast path more.
3194
3195         32kB is also super aggro. At 16kB, we support allocations up to 8kB,
3196         which covers 99.3% of allocations on facebook.com. The 32kB block size
3197         only covered an additional 0.2% of allocations.
3198
3199         * heap/CopiedBlock.h:
3200
3201 2016-04-04  Carlos Garcia Campos  <cgarcia@igalia.com>
3202
3203         REGRESSION(r198792): [GTK] Inspector crashes in Inspector::Protocol::getEnumConstantValue since r198792
3204         https://bugs.webkit.org/show_bug.cgi?id=155745
3205         <rdar://problem/25289456>
3206
3207         Reviewed by Brian Burg.
3208
3209         The problem is that we are generating the Inspector::Protocol::getEnumConstantValue() method and the
3210         enum_constant_values array for every framework that has enum values. So, in case of GTK port we have two
3211         implementations, one for the inspector in JavaScriptCore and another one for Web Automation in WebKit2, but when
3212         using the inspector in WebKit2 we always end up using the one in WebKit2. Since the enum_constant_values array
3213         is smaller in WebKit2 than the one in JavaScriptCore, we crash every time we receive an enum value higher than
3214         the array size. We need to disambiguate the getEnumConstantValue() generated and used for every framework, so we
3215         can use a specific namespace for the enum conversion methods.
3216
3217         * inspector/agents/InspectorDebuggerAgent.cpp:
3218         (Inspector::breakpointActionTypeForString): Use Inspector::Protocol::InspectorHelpers.
3219         * inspector/scripts/codegen/cpp_generator.py:
3220         (CppGenerator.helpers_namespace): Return the namespace name that should be used for the helper methods.
3221         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
3222         (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): Use
3223         CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue().
3224         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Ditto.
3225         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
3226         (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): Ditto.
3227         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
3228         (CppProtocolTypesHeaderGenerator.generate_output): Move declaration of getEnumConstantValue to a helper function.
3229         (_generate_enum_constant_value_conversion_methods): Do not emit any code if there aren't enums and ensure all
3230         conversion methods are declared inside the helpers namespace.
3231         (_generate_builder_setter_for_member): Use CppGenerator.helpers_namespace() to use the right namespace when
3232         using getEnumConstantValue().
3233         (_generate_unchecked_setter_for_member): Ditto.
3234         (_generate_declarations_for_enum_conversion_methods): Return a list instead of a string so that we can return an
3235         empty list in case of not emitting any code. The caller will use extend() that has no effect when an empty list
3236         is passed.
3237         * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
3238         (CppProtocolTypesImplementationGenerator.generate_output): Use the new helper function to generate both the enum
3239         mapping and conversion methods inside the helpers namespace.
3240         (CppProtocolTypesImplementationGenerator._generate_enum_mapping): Return a list instead of a string so that we
3241         can return an empty list in case of not emitting any code.
3242         (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): Ensure we only emit
3243         code when there are enum values, and it's generated inside the helpers namespace.
3244         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
3245         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
3246         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
3247         * inspector/scripts/tests/expected/enum-values.json-result:
3248         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
3249         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
3250         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
3251         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
3252         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
3253         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
3254         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
3255         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
3256         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
3257
3258 2016-04-04  Csaba Osztrogon√°c  <ossy@webkit.org>
3259
3260         Unreviewed ARM buildfix after r198981.
3261
3262         * assembler/MacroAssemblerARM.h:
3263         (JSC::MacroAssemblerARM::roundTowardZeroDouble):
3264
3265 2016-04-03  Saam barati  <sbarati@apple.com>
3266
3267         Implement Annex B.3.3 function hoisting rules for function code
3268         https://bugs.webkit.org/show_bug.cgi?id=155672
3269
3270         Reviewed by Geoffrey Garen.
3271
3272         The spec states that functions declared inside a function
3273         inside a block scope are subject to the rules of Annex B.3.3:
3274         https://tc39.github.io/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics
3275
3276         The rule states that functions declared in such blocks should
3277         be local bindings of the block. If declaring the function's name
3278         as a "var" in the function would not lead to a syntax error (i.e,
3279         if we don't have a let/const/class variable with the same name)
3280         and if we don't have a parameter with the same name, then we
3281         implictly also declare the funcion name as a "var". When evaluating
3282         the block statement we bind the hoisted "var" to be the value
3283         of the local function binding.
3284
3285         There is one more thing we do for web compatibility. We allow
3286         function declarations inside if/else statements that aren't
3287         blocks. For such statements, we transform the code as if the
3288         function were declared inside a block statement. For example:
3289         ``` function foo() { if (cond) function baz() { } }```
3290         is transformed into:
3291         ``` function foo() { if (cond) { function baz() { } } }```
3292
3293         * bytecompiler/BytecodeGenerator.cpp:
3294         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
3295         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
3296         * bytecompiler/BytecodeGenerator.h:
3297         * parser/Nodes.cpp:
3298         (JSC::ScopeNode::ScopeNode):
3299         (JSC::ProgramNode::ProgramNode):
3300         (JSC::ModuleProgramNode::ModuleProgramNode):
3301         (JSC::EvalNode::EvalNode):
3302         (JSC::FunctionNode::FunctionNode):
3303         * parser/Nodes.h:
3304         (JSC::ScopeNode::hasCapturedVariables):
3305         (JSC::ScopeNode::captures):
3306         (JSC::ScopeNode::hasSloppyModeHoistedFunction):
3307         (JSC::ScopeNode::varDeclarations):
3308         (JSC::ProgramNode::startColumn):
3309         (JSC::ProgramNode::endColumn):
3310         (JSC::EvalNode::startColumn):
3311         (JSC::EvalNode::endColumn):
3312         (JSC::ModuleProgramNode::startColumn):
3313         (JSC::ModuleProgramNode::endColumn):
3314         * parser/Parser.cpp:
3315         (JSC::Parser<LexerType>::Parser):
3316         (JSC::Parser<LexerType>::parseInner):
3317         (JSC::Parser<LexerType>::didFinishParsing):
3318         (JSC::Parser<LexerType>::parseStatement):
3319         (JSC::Parser<LexerType>::parseIfStatement):
3320         * parser/Parser.h:
3321         (JSC::Scope::declareVariable):
3322         (JSC::Scope::declareFunction):
3323         (JSC::Scope::addSloppyModeHoistableFunctionCandidate):
3324         (JSC::Scope::appendFunction):