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