We should support the ability to do a non-effectful getById
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-04-06  Keith Miller  <keith_miller@apple.com>
2
3         We should support the ability to do a non-effectful getById
4         https://bugs.webkit.org/show_bug.cgi?id=156116
5
6         Reviewed by Benjamin Poulain.
7
8         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
9         useful because it enables us to take different code paths based on values that we would
10         otherwise not be able to have knowledge of. This patch adds this new feature called
11         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
12         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
13         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
14         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
15         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
16         the global object that indicates we could not get the result.
17
18         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
19         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
20         get_by_id the same way we would for load and return the value at the appropriate offset.
21         Additionally, in order to make sure the we can properly compare the GetterSetter object
22         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
23         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
24         likely to have little to no impact on memory usage as normal accessors are generally rare.
25
26         * builtins/BuiltinExecutables.cpp:
27         (JSC::BuiltinExecutables::createDefaultConstructor):
28         (JSC::BuiltinExecutables::createBuiltinExecutable):
29         (JSC::createBuiltinExecutable):
30         (JSC::BuiltinExecutables::createExecutable):
31         (JSC::createExecutableInternal): Deleted.
32         * builtins/BuiltinExecutables.h:
33         * bytecode/BytecodeIntrinsicRegistry.h:
34         * bytecode/BytecodeList.json:
35         * bytecode/BytecodeUseDef.h:
36         (JSC::computeUsesForBytecodeOffset):
37         (JSC::computeDefsForBytecodeOffset):
38         * bytecode/CodeBlock.cpp:
39         (JSC::CodeBlock::dumpBytecode):
40         * bytecode/PolymorphicAccess.cpp:
41         (JSC::AccessCase::tryGet):
42         (JSC::AccessCase::generate):
43         (WTF::printInternal):
44         * bytecode/PolymorphicAccess.h:
45         (JSC::AccessCase::isGet): Deleted.
46         (JSC::AccessCase::isPut): Deleted.
47         (JSC::AccessCase::isIn): Deleted.
48         * bytecode/StructureStubInfo.cpp:
49         (JSC::StructureStubInfo::reset):
50         * bytecode/StructureStubInfo.h:
51         * bytecompiler/BytecodeGenerator.cpp:
52         (JSC::BytecodeGenerator::emitTryGetById):
53         * bytecompiler/BytecodeGenerator.h:
54         * bytecompiler/NodesCodegen.cpp:
55         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
56         * dfg/DFGSpeculativeJIT32_64.cpp:
57         (JSC::DFG::SpeculativeJIT::cachedGetById):
58         * dfg/DFGSpeculativeJIT64.cpp:
59         (JSC::DFG::SpeculativeJIT::cachedGetById):
60         * ftl/FTLLowerDFGToB3.cpp:
61         (JSC::FTL::DFG::LowerDFGToB3::getById):
62         * jit/JIT.cpp:
63         (JSC::JIT::privateCompileMainPass):
64         (JSC::JIT::privateCompileSlowCases):
65         * jit/JIT.h:
66         * jit/JITInlineCacheGenerator.cpp:
67         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
68         * jit/JITInlineCacheGenerator.h:
69         * jit/JITInlines.h:
70         (JSC::JIT::callOperation):
71         * jit/JITOperations.cpp:
72         * jit/JITOperations.h:
73         * jit/JITPropertyAccess.cpp:
74         (JSC::JIT::emitGetByValWithCachedId):
75         (JSC::JIT::emit_op_try_get_by_id):
76         (JSC::JIT::emitSlow_op_try_get_by_id):
77         (JSC::JIT::emit_op_get_by_id):
78         * jit/JITPropertyAccess32_64.cpp:
79         (JSC::JIT::emitGetByValWithCachedId):
80         (JSC::JIT::emit_op_try_get_by_id):
81         (JSC::JIT::emitSlow_op_try_get_by_id):
82         (JSC::JIT::emit_op_get_by_id):
83         * jit/Repatch.cpp:
84         (JSC::repatchByIdSelfAccess):
85         (JSC::appropriateOptimizingGetByIdFunction):
86         (JSC::appropriateGenericGetByIdFunction):
87         (JSC::tryCacheGetByID):
88         (JSC::repatchGetByID):
89         (JSC::resetGetByID):
90         * jit/Repatch.h:
91         * jsc.cpp:
92         (GlobalObject::finishCreation):
93         (functionGetGetterSetter):
94         (functionCreateBuiltin):
95         * llint/LLIntData.cpp:
96         (JSC::LLInt::Data::performAssertions):
97         * llint/LLIntSlowPaths.cpp:
98         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
99         * llint/LLIntSlowPaths.h:
100         * llint/LowLevelInterpreter.asm:
101         * runtime/GetterSetter.cpp:
102         * runtime/GetterSetter.h:
103         * runtime/JSType.h:
104         * runtime/PropertySlot.cpp:
105         (JSC::PropertySlot::getPureResult):
106         * runtime/PropertySlot.h:
107         * runtime/ProxyObject.cpp:
108         (JSC::ProxyObject::getOwnPropertySlotCommon):
109         * tests/stress/try-get-by-id.js: Added.
110         (tryGetByIdText):
111         (getCaller.obj.1.throw.new.Error.let.func):
112         (getCaller.obj.1.throw.new.Error):
113         (throw.new.Error.get let):
114         (throw.new.Error.):
115         (throw.new.Error.let.get createBuiltin):
116         (get let):
117         (let.get createBuiltin):
118         (let.func):
119         (get let.func):
120         (get throw):
121
122 2016-04-05  Chris Dumez  <cdumez@apple.com>
123
124         Add support for [EnabledAtRuntime] operations on DOMWindow
125         https://bugs.webkit.org/show_bug.cgi?id=156272
126
127         Reviewed by Alex Christensen.
128
129         Add identifier for 'fetch' so it can be used from the generated
130         bindings.
131
132         * runtime/CommonIdentifiers.h:
133
134 2016-04-05  Alex Christensen  <achristensen@webkit.org>
135
136         Make CMake-generated binaries on Mac able to run
137         https://bugs.webkit.org/show_bug.cgi?id=156268
138
139         Reviewed by Daniel Bates.
140
141         * CMakeLists.txt:
142
143 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
144
145         Improve some other cases of context-sensitive inlining
146         https://bugs.webkit.org/show_bug.cgi?id=156277
147
148         Reviewed by Benjamin Poulain.
149         
150         This implements some improvements for inlining:
151
152         - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have
153           been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to
154           err on the side of not inlining.
155         
156         - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block
157           increases the chances of the parser seeing the callee constant. While inlining doesn't require a
158           callee constant, sometimes it makes a difference. Note that we were previously breaking the block
159           for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then
160           the parser will automatically break the block for us. There is no reason to add any block breaking
161           ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a
162           check and falling through.
163         
164         - get_by_id handling now tries to apply some common sense to its status object. In particular, if
165           the source is a NewObject and there was no interfering operation that could clobber the structure,
166           then we know which case of a polymorphic GetByIdStatus we would take. This arises in some
167           constructor patterns.
168         
169         Long term, we should address all of these cases comprehensively by having a late inliner. The inliner
170         being part of the bytecode parser means that there is a lot of complexity in the parser and it
171         prevents us from inlining upon learning new information from static analysis. But for now, I think
172         it's fine to experiment with one-off hacks, if only to learn what the possibilities are.
173         
174         This is a 14% speed-up on Octane/raytrace.
175
176         * bytecode/CallLinkStatus.cpp:
177         (JSC::CallLinkStatus::dump):
178         * bytecode/CallLinkStatus.h:
179         (JSC::CallLinkStatus::couldTakeSlowPath):
180         (JSC::CallLinkStatus::setCouldTakeSlowPath):
181         (JSC::CallLinkStatus::variants):
182         (JSC::CallLinkStatus::size):
183         (JSC::CallLinkStatus::at):
184         * bytecode/GetByIdStatus.cpp:
185         (JSC::GetByIdStatus::makesCalls):
186         (JSC::GetByIdStatus::filter):
187         (JSC::GetByIdStatus::dump):
188         * bytecode/GetByIdStatus.h:
189         (JSC::GetByIdStatus::wasSeenInJIT):
190         * dfg/DFGByteCodeParser.cpp:
191         (JSC::DFG::ByteCodeParser::handleCall):
192         (JSC::DFG::ByteCodeParser::refineStatically):
193         (JSC::DFG::ByteCodeParser::handleVarargsCall):
194         (JSC::DFG::ByteCodeParser::handleInlining):
195         (JSC::DFG::ByteCodeParser::handleGetById):
196         (JSC::DFG::ByteCodeParser::parseBlock):
197         * runtime/Options.h:
198
199 2016-04-05  Saam barati  <sbarati@apple.com>
200
201         JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples
202         https://bugs.webkit.org/show_bug.cgi?id=154017
203
204         Reviewed by Geoffrey Garen.
205
206         By moving to an explicitly created seperate thread + sample-then-sleep
207         loop, we can remove a lot of the crufty code around WorkQueue.
208         We're also getting sample rates that are much closer to what we're
209         asking the OS for. When the sampling handler was built off of WorkQueue,
210         we'd often get sample rates much higher than the 1ms we asked for. On Kraken,
211         we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate.
212         Now, on Kraken, we're getting about 1.2ms rates. Because we're getting
213         higher rates, this patch is a performance regression. It's slower because
214         we're sampling more frequently.
215
216         Before this patch, the sampling profiler had the following overhead:
217         - 10% on Kraken
218         - 12% on octane
219         - 15% on AsmBench
220
221         With this patch, the sampling profiler has the following overhead:
222         - 16% on Kraken
223         - 17% on Octane
224         - 30% on AsmBench
225
226         Comparatively, this new patch has the following overhead over the old sampling profiler:
227         - 5% on Kraken
228         - 3.5% on Octane
229         - 13% slower on AsmBench
230
231         * inspector/agents/InspectorScriptProfilerAgent.cpp:
232         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
233         * runtime/SamplingProfiler.cpp:
234         (JSC::SamplingProfiler::SamplingProfiler):
235         (JSC::SamplingProfiler::~SamplingProfiler):
236         (JSC::SamplingProfiler::createThreadIfNecessary):
237         (JSC::SamplingProfiler::timerLoop):
238         (JSC::SamplingProfiler::takeSample):
239         (JSC::tryGetBytecodeIndex):
240         (JSC::SamplingProfiler::shutdown):
241         (JSC::SamplingProfiler::start):
242         (JSC::SamplingProfiler::pause):
243         (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
244         (JSC::SamplingProfiler::noticeJSLockAcquisition):
245         (JSC::SamplingProfiler::noticeVMEntry):
246         (JSC::SamplingProfiler::clearData):
247         (JSC::SamplingProfiler::stop): Deleted.
248         (JSC::SamplingProfiler::dispatchIfNecessary): Deleted.
249         (JSC::SamplingProfiler::dispatchFunction): Deleted.
250         * runtime/SamplingProfiler.h:
251         (JSC::SamplingProfiler::setTimingInterval):
252         (JSC::SamplingProfiler::setStopWatch):
253         * runtime/VM.cpp:
254         (JSC::VM::VM):
255
256 2016-04-05  Commit Queue  <commit-queue@webkit.org>
257
258         Unreviewed, rolling out r199073.
259         https://bugs.webkit.org/show_bug.cgi?id=156261
260
261         This change broke internal Mac builds (Requested by ryanhaddad
262         on #webkit).
263
264         Reverted changeset:
265
266         "We should support the ability to do a non-effectful getById"
267         https://bugs.webkit.org/show_bug.cgi?id=156116
268         http://trac.webkit.org/changeset/199073
269
270 2016-04-05  Youenn Fablet  <youenn.fablet@crf.canon.fr>
271
272         [Fetch API] Add a runtime flag to fetch API and related constructs
273         https://bugs.webkit.org/show_bug.cgi?id=156113
274  
275         Reviewed by Alex Christensen.
276
277         Add a fetch API runtime flag based on preferences.
278         Disable fetch API by default.
279  
280         * runtime/CommonIdentifiers.h:
281
282 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
283
284         Unreviewed, fix cloop some more.
285
286         * runtime/RegExpInlines.h:
287         (JSC::RegExp::hasCodeFor):
288         (JSC::RegExp::hasMatchOnlyCodeFor):
289
290 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
291
292         Unreviewed, fix cloop.
293
294         * jit/CCallHelpers.cpp:
295
296 2016-03-18  Filip Pizlo  <fpizlo@apple.com>
297
298         JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames
299         https://bugs.webkit.org/show_bug.cgi?id=155598
300
301         Reviewed by Saam Barati.
302         
303         JSC is the first JSVM to have proper tail calls. This means that error.stack and the
304         debugger will appear to "delete" strict mode stack frames, if the call that this frame made
305         was in tail position. This is exactly what functional programmers expect - they don't want
306         the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever
307         using tail calls. It's also something that non-functional programmers fear. It's not clear
308         that tail-deleted frames would actually degrade the debugging experience, but the fear is
309         real, so it's worthwhile to do something about it.
310
311         It turns out that there is at least one tail call implementation that doesn't suffer from
312         this problem. It implements proper tail calls in the sense that you won't run out of memory
313         by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so
314         long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my
315         favorite hacks:
316         
317         http://www.more-magic.net/posts/internals-gc.html
318
319         CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple
320         one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that
321         frame only once we proved that there was insufficient memory to keep it around.
322         
323         CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we
324         can have arbitrary native code, and that native code does not have relocatable stack frames.
325         
326         But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a
327         VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra
328         information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its
329         layout. The main stack can then continue to obey ABI rules.
330
331         This patch implements a mechanism for being able to display stack traces that include
332         tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all
333         frames all the time, though we will collect the tail-deleted ones if the stack gets too big.
334         This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack.
335         
336         ShadowChicken is always on, but individual CodeBlocks may make their own choices about
337         whether to opt into it. They will do that at bytecompile time based on the debugger mode on
338         their global object.
339
340         When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing
341         in that case. Well, except when exceptions are thrown. Then it might do some work, but it's
342         minor.
343
344         When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable
345         this all the time, but it's low enough to justify enabling in the Inspector. It's currently
346         enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the
347         debugger is on.
348
349         Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have
350         no logging. This is essential since we *can* have debugging enabled in one GlobalObject and
351         disabled in another. Also, some frames don't do ShadowChicken because they just haven't been
352         hacked to do it yet. Native frames fall into this category, as do the VM entry frames.
353
354         This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It
355         just makes a ShadowChicken stack walk function available to jsc. It's used from the
356         shadow-chicken tests.
357
358         * API/JSContextRef.cpp:
359         (BacktraceFunctor::BacktraceFunctor):
360         (BacktraceFunctor::operator()):
361         (JSContextCreateBacktrace):
362         * CMakeLists.txt:
363         * JavaScriptCore.xcodeproj/project.pbxproj:
364         * bytecode/BytecodeList.json:
365         * bytecode/BytecodeUseDef.h:
366         (JSC::computeUsesForBytecodeOffset):
367         (JSC::computeDefsForBytecodeOffset):
368         * bytecode/CodeBlock.cpp:
369         (JSC::CodeBlock::dumpBytecode):
370         (JSC::RecursionCheckFunctor::RecursionCheckFunctor):
371         (JSC::RecursionCheckFunctor::operator()):
372         (JSC::CodeBlock::noticeIncomingCall):
373         * bytecompiler/BytecodeGenerator.cpp:
374         (JSC::BytecodeGenerator::emitEnter):
375         (JSC::BytecodeGenerator::emitCallInTailPosition):
376         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
377         (JSC::BytecodeGenerator::emitCallVarargs):
378         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
379         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
380         (JSC::BytecodeGenerator::emitCallDefineProperty):
381         * bytecompiler/BytecodeGenerator.h:
382         * debugger/DebuggerCallFrame.cpp:
383         (JSC::LineAndColumnFunctor::operator()):
384         (JSC::LineAndColumnFunctor::column):
385         (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor):
386         (JSC::FindCallerMidStackFunctor::operator()):
387         (JSC::DebuggerCallFrame::DebuggerCallFrame):
388         * dfg/DFGAbstractInterpreterInlines.h:
389         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
390         * dfg/DFGByteCodeParser.cpp:
391         (JSC::DFG::ByteCodeParser::parseBlock):
392         * dfg/DFGClobberize.h:
393         (JSC::DFG::clobberize):
394         * dfg/DFGDoesGC.cpp:
395         (JSC::DFG::doesGC):
396         * dfg/DFGFixupPhase.cpp:
397         (JSC::DFG::FixupPhase::fixupNode):
398         * dfg/DFGNodeType.h:
399         * dfg/DFGPredictionPropagationPhase.cpp:
400         (JSC::DFG::PredictionPropagationPhase::propagate):
401         * dfg/DFGSafeToExecute.h:
402         (JSC::DFG::safeToExecute):
403         * dfg/DFGSpeculativeJIT32_64.cpp:
404         (JSC::DFG::SpeculativeJIT::compile):
405         * dfg/DFGSpeculativeJIT64.cpp:
406         (JSC::DFG::SpeculativeJIT::compile):
407         * ftl/FTLAbstractHeapRepository.cpp:
408         * ftl/FTLAbstractHeapRepository.h:
409         * ftl/FTLCapabilities.cpp:
410         (JSC::FTL::canCompile):
411         * ftl/FTLLowerDFGToB3.cpp:
412         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
413         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
414         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
415         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
416         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
417         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
418         (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket):
419         (JSC::FTL::DFG::LowerDFGToB3::boolify):
420         * heap/Heap.cpp:
421         (JSC::Heap::markRoots):
422         (JSC::Heap::visitSamplingProfiler):
423         (JSC::Heap::visitShadowChicken):
424         (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
425         (JSC::Heap::collectImpl):
426         * heap/Heap.h:
427         * inspector/ScriptCallStackFactory.cpp:
428         (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor):
429         (Inspector::CreateScriptCallStackFunctor::operator()):
430         (Inspector::createScriptCallStack):
431         * interpreter/CallFrame.h:
432         (JSC::ExecState::iterate):
433         * interpreter/Interpreter.cpp:
434         (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
435         (JSC::DumpRegisterFunctor::operator()):
436         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
437         (JSC::GetStackTraceFunctor::operator()):
438         (JSC::Interpreter::getStackTrace):
439         (JSC::GetCatchHandlerFunctor::handler):
440         (JSC::GetCatchHandlerFunctor::operator()):
441         (JSC::notifyDebuggerOfUnwinding):
442         (JSC::UnwindFunctor::UnwindFunctor):
443         (JSC::UnwindFunctor::operator()):
444         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
445         * interpreter/ShadowChicken.cpp: Added.
446         (JSC::ShadowChicken::Packet::dump):
447         (JSC::ShadowChicken::Frame::dump):
448         (JSC::ShadowChicken::ShadowChicken):
449         (JSC::ShadowChicken::~ShadowChicken):
450         (JSC::ShadowChicken::log):
451         (JSC::ShadowChicken::update):
452         (JSC::ShadowChicken::visitChildren):
453         (JSC::ShadowChicken::reset):
454         (JSC::ShadowChicken::dump):
455         (JSC::ShadowChicken::functionsOnStack):
456         * interpreter/ShadowChicken.h: Added.
457         (JSC::ShadowChicken::Packet::Packet):
458         (JSC::ShadowChicken::Packet::tailMarker):
459         (JSC::ShadowChicken::Packet::throwMarker):
460         (JSC::ShadowChicken::Packet::prologue):
461         (JSC::ShadowChicken::Packet::tail):
462         (JSC::ShadowChicken::Packet::throwPacket):
463         (JSC::ShadowChicken::Packet::operator bool):
464         (JSC::ShadowChicken::Packet::isPrologue):
465         (JSC::ShadowChicken::Packet::isTail):
466         (JSC::ShadowChicken::Packet::isThrow):
467         (JSC::ShadowChicken::Frame::Frame):
468         (JSC::ShadowChicken::Frame::operator==):
469         (JSC::ShadowChicken::Frame::operator!=):
470         (JSC::ShadowChicken::log):
471         (JSC::ShadowChicken::logSize):
472         (JSC::ShadowChicken::addressOfLogCursor):
473         (JSC::ShadowChicken::logEnd):
474         * interpreter/ShadowChickenInlines.h: Added.
475         (JSC::ShadowChicken::iterate):
476         * interpreter/StackVisitor.h:
477         (JSC::StackVisitor::Frame::callee):
478         (JSC::StackVisitor::Frame::codeBlock):
479         (JSC::StackVisitor::Frame::bytecodeOffset):
480         (JSC::StackVisitor::Frame::inlineCallFrame):
481         (JSC::StackVisitor::Frame::isJSFrame):
482         (JSC::StackVisitor::Frame::isInlinedFrame):
483         (JSC::StackVisitor::visit):
484         * jit/CCallHelpers.cpp: Added.
485         (JSC::CCallHelpers::logShadowChickenProloguePacket):
486         (JSC::CCallHelpers::logShadowChickenTailPacket):
487         (JSC::CCallHelpers::setupShadowChickenPacket):
488         * jit/CCallHelpers.h:
489         (JSC::CCallHelpers::prepareForTailCallSlow):
490         * jit/JIT.cpp:
491         (JSC::JIT::privateCompileMainPass):
492         * jit/JIT.h:
493         * jit/JITExceptions.cpp:
494         (JSC::genericUnwind):
495         * jit/JITOpcodes.cpp:
496         (JSC::JIT::emit_op_resume):
497         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
498         (JSC::JIT::emit_op_log_shadow_chicken_tail):
499         * jit/JITOperations.cpp:
500         * jit/JITOperations.h:
501         * jsc.cpp:
502         (GlobalObject::finishCreation):
503         (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
504         (FunctionJSCStackFunctor::operator()):
505         (functionClearSamplingFlags):
506         (functionShadowChickenFunctionsOnStack):
507         (functionReadline):
508         * llint/LLIntOffsetsExtractor.cpp:
509         * llint/LLIntSlowPaths.cpp:
510         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
511         (JSC::LLInt::llint_throw_stack_overflow_error):
512         * llint/LLIntSlowPaths.h:
513         * llint/LowLevelInterpreter.asm:
514         * profiler/ProfileGenerator.cpp:
515         (JSC::AddParentForConsoleStartFunctor::foundParent):
516         (JSC::AddParentForConsoleStartFunctor::operator()):
517         * runtime/Error.cpp:
518         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
519         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
520         (JSC::addErrorInfoAndGetBytecodeOffset):
521         * runtime/JSFunction.cpp:
522         (JSC::RetrieveArgumentsFunctor::result):
523         (JSC::RetrieveArgumentsFunctor::operator()):
524         (JSC::retrieveArguments):
525         (JSC::RetrieveCallerFunctionFunctor::result):
526         (JSC::RetrieveCallerFunctionFunctor::operator()):
527         (JSC::retrieveCallerFunction):
528         * runtime/JSGlobalObjectFunctions.cpp:
529         (JSC::GlobalFuncProtoGetterFunctor::result):
530         (JSC::GlobalFuncProtoGetterFunctor::operator()):
531         (JSC::globalFuncProtoGetter):
532         (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
533         (JSC::GlobalFuncProtoSetterFunctor::operator()):
534         * runtime/NullSetterFunction.cpp:
535         (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
536         (JSC::GetCallerStrictnessFunctor::operator()):
537         (JSC::GetCallerStrictnessFunctor::callerIsStrict):
538         (JSC::callerIsStrict):
539         * runtime/ObjectConstructor.cpp:
540         (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
541         (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
542         (JSC::objectConstructorGetPrototypeOf):
543         * runtime/Options.h:
544         * runtime/VM.cpp:
545         (JSC::VM::VM):
546         (JSC::SetEnabledProfilerFunctor::operator()):
547         * runtime/VM.h:
548         (JSC::VM::shouldBuilderPCToCodeOriginMapping):
549         (JSC::VM::bytecodeIntrinsicRegistry):
550         (JSC::VM::shadowChicken):
551         * tests/stress/resources/shadow-chicken-support.js: Added.
552         (describeFunction):
553         (describeArray):
554         (expectStack):
555         (initialize):
556         * tests/stress/shadow-chicken-disabled.js: Added.
557         (test1.foo):
558         (test1.bar):
559         (test1.baz):
560         (test1):
561         (test2.foo):
562         (test2.bar):
563         (test2.baz):
564         (test2):
565         (test3.foo):
566         (test3.bar):
567         (test3.baz):
568         (test3):
569         * tests/stress/shadow-chicken-enabled.js: Added.
570         (test1.foo):
571         (test1.bar):
572         (test1.baz):
573         (test1):
574         (test2.foo):
575         (test2.bar):
576         (test2.baz):
577         (test2):
578         (test3.bob):
579         (test3.thingy):
580         (test3.foo):
581         (test3.bar):
582         (test3.baz):
583         (test3):
584         (test4.bob):
585         (test4.thingy):
586         (test4.foo):
587         (test4.bar):
588         (test4.baz):
589         (test4):
590         (test5.foo):
591         (test5):
592         * tools/JSDollarVMPrototype.cpp:
593         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
594         (JSC::CallerFrameJITTypeFunctor::operator()):
595         (JSC::CallerFrameJITTypeFunctor::jitType):
596         (JSC::functionLLintTrue):
597         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
598         (JSC::CellAddressCheckFunctor::operator()):
599         (JSC::JSDollarVMPrototype::isValidCell):
600         (JSC::JSDollarVMPrototype::isValidCodeBlock):
601         (JSC::JSDollarVMPrototype::codeBlockForFrame):
602         (JSC::PrintFrameFunctor::PrintFrameFunctor):
603         (JSC::PrintFrameFunctor::operator()):
604         (JSC::printCallFrame):
605
606 2016-03-19  Filip Pizlo  <fpizlo@apple.com>
607
608         DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace
609         https://bugs.webkit.org/show_bug.cgi?id=155270
610
611         Reviewed by Saam Barati.
612
613         This enables constant-folding of RegExpExec, RegExpTest, and StringReplace.
614
615         It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding
616         strings gave the DFG an API for reasoning about JSString constants in terms of
617         JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR
618         based on the results.
619
620         But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must
621         use the same Structure that the code would have used or else we'll pollute the program's
622         inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named
623         properties in one go - we don't want to lose that optimization. So, this patch enables
624         MaterializeNewObject to allocate objects or arrays with any number of indexed or named
625         properties. Previously it could only handle objects (but not arrays) and named properties
626         (but not indexed ones).
627
628         This also adds a few minor things for setting the RegExpConstructor cached result.
629
630         This is about a 2x speed-up on microbenchmarks when we fold a match success and about a
631         8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp.
632
633         * JavaScriptCore.xcodeproj/project.pbxproj:
634         * dfg/DFGAbstractInterpreterInlines.h:
635         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
636         * dfg/DFGClobberize.h:
637         (JSC::DFG::clobberize):
638         * dfg/DFGDoesGC.cpp:
639         (JSC::DFG::doesGC):
640         * dfg/DFGFixupPhase.cpp:
641         (JSC::DFG::FixupPhase::fixupNode):
642         * dfg/DFGGraph.cpp:
643         (JSC::DFG::Graph::dump):
644         * dfg/DFGInsertionSet.cpp:
645         (JSC::DFG::InsertionSet::insertSlow):
646         (JSC::DFG::InsertionSet::execute):
647         * dfg/DFGInsertionSet.h:
648         (JSC::DFG::InsertionSet::insertCheck):
649         * dfg/DFGLazyJSValue.cpp:
650         (JSC::DFG::LazyJSValue::tryGetString):
651         * dfg/DFGMayExit.cpp:
652         (JSC::DFG::mayExit):
653         * dfg/DFGNode.h:
654         (JSC::DFG::StackAccessData::flushedAt):
655         (JSC::DFG::OpInfo::OpInfo): Deleted.
656         * dfg/DFGNodeType.h:
657         * dfg/DFGObjectAllocationSinkingPhase.cpp:
658         * dfg/DFGObjectMaterializationData.cpp:
659         (JSC::DFG::ObjectMaterializationData::dump):
660         (JSC::DFG::PhantomPropertyValue::dump): Deleted.
661         (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted.
662         (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted.
663         * dfg/DFGObjectMaterializationData.h:
664         (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted.
665         (JSC::DFG::PhantomPropertyValue::operator==): Deleted.
666         * dfg/DFGOpInfo.h: Added.
667         (JSC::DFG::OpInfo::OpInfo):
668         * dfg/DFGOperations.cpp:
669         * dfg/DFGOperations.h:
670         * dfg/DFGPredictionPropagationPhase.cpp:
671         (JSC::DFG::PredictionPropagationPhase::propagate):
672         * dfg/DFGPromotedHeapLocation.cpp:
673         (WTF::printInternal):
674         * dfg/DFGPromotedHeapLocation.h:
675         * dfg/DFGSafeToExecute.h:
676         (JSC::DFG::safeToExecute):
677         * dfg/DFGSpeculativeJIT.cpp:
678         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
679         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
680         (JSC::DFG::SpeculativeJIT::emitGetLength):
681         (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
682         (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
683         (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
684         (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted.
685         * dfg/DFGSpeculativeJIT.h:
686         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
687         * dfg/DFGSpeculativeJIT32_64.cpp:
688         (JSC::DFG::SpeculativeJIT::compile):
689         * dfg/DFGSpeculativeJIT64.cpp:
690         (JSC::DFG::SpeculativeJIT::compile):
691         * dfg/DFGStoreBarrierInsertionPhase.cpp:
692         * dfg/DFGStrengthReductionPhase.cpp:
693         (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
694         (JSC::DFG::StrengthReductionPhase::handleNode):
695         (JSC::DFG::StrengthReductionPhase::handleCommutativity):
696         (JSC::DFG::StrengthReductionPhase::executeInsertionSet):
697         * dfg/DFGValidate.cpp:
698         (JSC::DFG::Validate::validate):
699         (JSC::DFG::Validate::validateCPS):
700         * ftl/FTLAbstractHeapRepository.cpp:
701         * ftl/FTLAbstractHeapRepository.h:
702         * ftl/FTLCapabilities.cpp:
703         (JSC::FTL::canCompile):
704         * ftl/FTLLowerDFGToB3.cpp:
705         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
706         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
707         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
708         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
709         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
710         (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
711         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
712         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
713         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
714         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
715         (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
716         (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
717         * ftl/FTLOperations.cpp:
718         (JSC::FTL::operationPopulateObjectInOSR):
719         (JSC::FTL::operationNewObjectWithButterfly): Deleted.
720         * ftl/FTLOperations.h:
721         * inspector/ContentSearchUtilities.cpp:
722         * runtime/JSObject.h:
723         (JSC::JSObject::createRawObject):
724         (JSC::JSFinalObject::create):
725         * runtime/RegExp.cpp:
726         (JSC::RegExp::compile):
727         (JSC::RegExp::match):
728         (JSC::RegExp::matchConcurrently):
729         (JSC::RegExp::compileMatchOnly):
730         (JSC::RegExp::deleteCode):
731         * runtime/RegExp.h:
732         * runtime/RegExpCachedResult.h:
733         (JSC::RegExpCachedResult::offsetOfLastRegExp):
734         (JSC::RegExpCachedResult::offsetOfLastInput):
735         (JSC::RegExpCachedResult::offsetOfResult):
736         (JSC::RegExpCachedResult::offsetOfReified):
737         * runtime/RegExpConstructor.h:
738         (JSC::RegExpConstructor::offsetOfCachedResult):
739         * runtime/RegExpInlines.h:
740         (JSC::RegExp::hasCodeFor):
741         (JSC::RegExp::compileIfNecessary):
742         (JSC::RegExp::matchInline):
743         (JSC::RegExp::hasMatchOnlyCodeFor):
744         (JSC::RegExp::compileIfNecessaryMatchOnly):
745         * runtime/RegExpObjectInlines.h:
746         (JSC::RegExpObject::execInline):
747         * runtime/StringPrototype.cpp:
748         (JSC::substituteBackreferencesSlow):
749         (JSC::substituteBackreferencesInline):
750         (JSC::substituteBackreferences):
751         (JSC::StringRange::StringRange):
752         * runtime/StringPrototype.h:
753         * runtime/VM.h:
754         * tests/stress/simple-regexp-exec-folding-fail.js: Added.
755         (foo):
756         * tests/stress/simple-regexp-exec-folding.js: Added.
757         (foo):
758         * tests/stress/simple-regexp-test-folding-fail.js: Added.
759         (foo):
760         * tests/stress/simple-regexp-test-folding.js: Added.
761         (foo):
762         * yarr/RegularExpression.cpp:
763         * yarr/Yarr.h:
764         * yarr/YarrInterpreter.cpp:
765         (JSC::Yarr::Interpreter::interpret):
766         (JSC::Yarr::ByteCompiler::ByteCompiler):
767         (JSC::Yarr::ByteCompiler::compile):
768         (JSC::Yarr::ByteCompiler::checkInput):
769         (JSC::Yarr::byteCompile):
770         (JSC::Yarr::interpret):
771         * yarr/YarrInterpreter.h:
772         (JSC::Yarr::BytecodePattern::BytecodePattern):
773
774 2016-04-05  Keith Miller  <keith_miller@apple.com>
775
776         We should support the ability to do a non-effectful getById
777         https://bugs.webkit.org/show_bug.cgi?id=156116
778
779         Reviewed by Benjamin Poulain.
780
781         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
782         useful because it enables us to take different code paths based on values that we would
783         otherwise not be able to have knowledge of. This patch adds this new feature called
784         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
785         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
786         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
787         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
788         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
789         the global object that indicates we could not get the result.
790
791         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
792         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
793         get_by_id the same way we would for load and return the value at the appropriate offset.
794         Additionally, in order to make sure the we can properly compare the GetterSetter object
795         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
796         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
797         likely to have little to no impact on memory usage as normal accessors are generally rare.
798
799         * JavaScriptCore.xcodeproj/project.pbxproj:
800         * builtins/BuiltinExecutables.cpp:
801         (JSC::BuiltinExecutables::createDefaultConstructor):
802         (JSC::BuiltinExecutables::createBuiltinExecutable):
803         (JSC::createBuiltinExecutable):
804         (JSC::BuiltinExecutables::createExecutable):
805         (JSC::createExecutableInternal): Deleted.
806         * builtins/BuiltinExecutables.h:
807         * bytecode/BytecodeIntrinsicRegistry.h:
808         * bytecode/BytecodeList.json:
809         * bytecode/BytecodeUseDef.h:
810         (JSC::computeUsesForBytecodeOffset):
811         (JSC::computeDefsForBytecodeOffset):
812         * bytecode/CodeBlock.cpp:
813         (JSC::CodeBlock::dumpBytecode):
814         * bytecode/PolymorphicAccess.cpp:
815         (JSC::AccessCase::tryGet):
816         (JSC::AccessCase::generate):
817         (WTF::printInternal):
818         * bytecode/PolymorphicAccess.h:
819         (JSC::AccessCase::isGet): Deleted.
820         (JSC::AccessCase::isPut): Deleted.
821         (JSC::AccessCase::isIn): Deleted.
822         * bytecode/StructureStubInfo.cpp:
823         (JSC::StructureStubInfo::reset):
824         * bytecode/StructureStubInfo.h:
825         * bytecompiler/BytecodeGenerator.cpp:
826         (JSC::BytecodeGenerator::emitTryGetById):
827         * bytecompiler/BytecodeGenerator.h:
828         * bytecompiler/NodesCodegen.cpp:
829         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
830         * dfg/DFGSpeculativeJIT32_64.cpp:
831         (JSC::DFG::SpeculativeJIT::cachedGetById):
832         * dfg/DFGSpeculativeJIT64.cpp:
833         (JSC::DFG::SpeculativeJIT::cachedGetById):
834         * ftl/FTLLowerDFGToB3.cpp:
835         (JSC::FTL::DFG::LowerDFGToB3::getById):
836         * jit/JIT.cpp:
837         (JSC::JIT::privateCompileMainPass):
838         (JSC::JIT::privateCompileSlowCases):
839         * jit/JIT.h:
840         * jit/JITInlineCacheGenerator.cpp:
841         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
842         * jit/JITInlineCacheGenerator.h:
843         * jit/JITInlines.h:
844         (JSC::JIT::callOperation):
845         * jit/JITOperations.cpp:
846         * jit/JITOperations.h:
847         * jit/JITPropertyAccess.cpp:
848         (JSC::JIT::emitGetByValWithCachedId):
849         (JSC::JIT::emit_op_try_get_by_id):
850         (JSC::JIT::emitSlow_op_try_get_by_id):
851         (JSC::JIT::emit_op_get_by_id):
852         * jit/JITPropertyAccess32_64.cpp:
853         (JSC::JIT::emitGetByValWithCachedId):
854         (JSC::JIT::emit_op_try_get_by_id):
855         (JSC::JIT::emitSlow_op_try_get_by_id):
856         (JSC::JIT::emit_op_get_by_id):
857         * jit/Repatch.cpp:
858         (JSC::repatchByIdSelfAccess):
859         (JSC::appropriateOptimizingGetByIdFunction):
860         (JSC::appropriateGenericGetByIdFunction):
861         (JSC::tryCacheGetByID):
862         (JSC::repatchGetByID):
863         (JSC::resetGetByID):
864         * jit/Repatch.h:
865         * jsc.cpp:
866         (GlobalObject::finishCreation):
867         (functionGetGetterSetter):
868         (functionCreateBuiltin):
869         * llint/LLIntData.cpp:
870         (JSC::LLInt::Data::performAssertions):
871         * llint/LLIntSlowPaths.cpp:
872         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
873         * llint/LLIntSlowPaths.h:
874         * llint/LowLevelInterpreter.asm:
875         * runtime/GetterSetter.cpp:
876         * runtime/GetterSetter.h:
877         * runtime/JSType.h:
878         * runtime/PropertySlot.cpp:
879         (JSC::PropertySlot::getPureResult):
880         * runtime/PropertySlot.h:
881         * runtime/ProxyObject.cpp:
882         (JSC::ProxyObject::getOwnPropertySlotCommon):
883         * tests/stress/try-get-by-id.js: Added.
884         (tryGetByIdText):
885         (getCaller.obj.1.throw.new.Error.let.func):
886         (getCaller.obj.1.throw.new.Error):
887         (throw.new.Error.get let):
888         (throw.new.Error.):
889         (throw.new.Error.let.get createBuiltin):
890         (get let):
891         (let.get createBuiltin):
892         (let.func):
893         (get let.func):
894         (get throw):
895
896 2016-04-05  Saam barati  <sbarati@apple.com>
897
898         jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989
899         https://bugs.webkit.org/show_bug.cgi?id=156187
900
901         Reviewed by Filip Pizlo.
902
903         This is a speculative fix. Lets see if the prevents the timeout.
904
905         * parser/Parser.cpp:
906         (JSC::Parser<LexerType>::parseStatementListItem):
907
908 2016-04-04  Filip Pizlo  <fpizlo@apple.com>
909
910         PolymorphicAccess should have a MegamorphicLoad case
911         https://bugs.webkit.org/show_bug.cgi?id=156182
912
913         Reviewed by Geoffrey Garen and Keith Miller.
914
915         This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in
916         the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than
917         calling into C++ to do the same job - particularly since inlining the lookup into an access means
918         that we can precompute the hash code.
919
920         When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not
921         optimal. It used a double-hashing method for reducing collision pathologies. This is great for
922         improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we
923         want to optimize the average-case performance. When optimizing for average-case, we can choose to
924         either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the
925         worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high
926         probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case
927         pathology only makes sense if it also preserves the good performance of the fast case, or reduces the
928         likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in
929         the fast case.
930
931         I don't believe, based on looking at how the double-hashing is implemented, that it's possible that
932         this preserves the good performance of the fast case. It requires at least one more value to be live
933         around the loop, and dramatically increases the register pressure at key points inside the loop. The
934         biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if
935         the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere
936         then we will pay a steep price anytime we take the second iteration around the loop; but if the
937         compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on
938         some architectures (I performed biological register allocation and found that I needed 9 registers
939         for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might
940         be better off).
941
942         Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down
943         on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill.
944
945         There are some other small changes in this patch, like rationalizing the IC's choice between giving
946         up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can
947         try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to
948         choose between those options, but we weren't fully taking advantage of it because the
949         regenerateWithCase() method just returned null for any failure, and didn't say whether it was the
950         sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now
951         this is all made explicit. I wanted to make sure this change happened in this patch since the
952         MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since
953         this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure
954         that the rules for giving up were something that made sense to me.
955         
956         This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight
957         speed-up for page loading, because many real websites like to have megamorphic property accesses.
958
959         * bytecode/PolymorphicAccess.cpp:
960         (JSC::AccessGenerationResult::dump):
961         (JSC::AccessGenerationState::addWatchpoint):
962         (JSC::AccessCase::get):
963         (JSC::AccessCase::megamorphicLoad):
964         (JSC::AccessCase::replace):
965         (JSC::AccessCase::guardedByStructureCheck):
966         (JSC::AccessCase::couldStillSucceed):
967         (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
968         (JSC::AccessCase::canReplace):
969         (JSC::AccessCase::generateWithGuard):
970         (JSC::AccessCase::generate):
971         (JSC::PolymorphicAccess::PolymorphicAccess):
972         (JSC::PolymorphicAccess::~PolymorphicAccess):
973         (JSC::PolymorphicAccess::regenerateWithCases):
974         (JSC::PolymorphicAccess::regenerateWithCase):
975         (WTF::printInternal):
976         * bytecode/PolymorphicAccess.h:
977         (JSC::AccessCase::isGet):
978         (JSC::AccessCase::isPut):
979         (JSC::AccessCase::isIn):
980         (JSC::AccessGenerationResult::AccessGenerationResult):
981         (JSC::AccessGenerationResult::operator==):
982         (JSC::AccessGenerationResult::operator!=):
983         (JSC::AccessGenerationResult::operator bool):
984         (JSC::AccessGenerationResult::kind):
985         (JSC::AccessGenerationResult::code):
986         (JSC::AccessGenerationResult::madeNoChanges):
987         (JSC::AccessGenerationResult::gaveUp):
988         (JSC::AccessGenerationResult::generatedNewCode):
989         (JSC::PolymorphicAccess::isEmpty):
990         (JSC::AccessGenerationState::AccessGenerationState):
991         * bytecode/StructureStubInfo.cpp:
992         (JSC::StructureStubInfo::aboutToDie):
993         (JSC::StructureStubInfo::addAccessCase):
994         * bytecode/StructureStubInfo.h:
995         * jit/AssemblyHelpers.cpp:
996         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
997         (JSC::AssemblyHelpers::loadProperty):
998         (JSC::emitRandomThunkImpl):
999         (JSC::AssemblyHelpers::emitRandomThunk):
1000         (JSC::AssemblyHelpers::emitLoadStructure):
1001         * jit/AssemblyHelpers.h:
1002         (JSC::AssemblyHelpers::loadValue):
1003         (JSC::AssemblyHelpers::moveValueRegs):
1004         (JSC::AssemblyHelpers::argumentsStart):
1005         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
1006         (JSC::AssemblyHelpers::emitLoadStructure): Deleted.
1007         * jit/GPRInfo.cpp:
1008         (JSC::JSValueRegs::dump):
1009         * jit/GPRInfo.h:
1010         (JSC::JSValueRegs::uses):
1011         * jit/Repatch.cpp:
1012         (JSC::replaceWithJump):
1013         (JSC::tryCacheGetByID):
1014         (JSC::tryCachePutByID):
1015         (JSC::tryRepatchIn):
1016         * jit/ThunkGenerators.cpp:
1017         (JSC::virtualThunkFor):
1018         * runtime/Options.h:
1019         * runtime/PropertyMapHashTable.h:
1020         (JSC::PropertyTable::begin):
1021         (JSC::PropertyTable::find):
1022         (JSC::PropertyTable::get):
1023         * runtime/Structure.h:
1024
1025 2016-04-05  Antoine Quint  <graouts@apple.com>
1026
1027         [WebGL2] Turn the ENABLE_WEBGL2 flag on
1028         https://bugs.webkit.org/show_bug.cgi?id=156061
1029         <rdar://problem/25463193>
1030
1031         Reviewed by Alex Christensen.
1032
1033         * Configurations/FeatureDefines.xcconfig:
1034         * runtime/CommonIdentifiers.h:
1035
1036         Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject. 
1037
1038 2016-04-04  Zan Dobersek  <zdobersek@igalia.com>
1039
1040         Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads
1041         https://bugs.webkit.org/show_bug.cgi?id=156161
1042
1043         Reviewed by Yusuke Suzuki.
1044
1045         r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads
1046         that handle arguments split into the tag and the payload. The two were split
1047         between the last argument register and the stack on 32-bit ARM EABI systems,
1048         causing incorrect behavior.
1049
1050         Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the
1051         stack, removing the issue.
1052
1053         * dfg/DFGSpeculativeJIT.h:
1054         (JSC::DFG::SpeculativeJIT::callOperation):
1055
1056 2016-04-04  Joseph Pecoraro  <pecoraro@apple.com>
1057
1058         Avoid copying ModuleLoaderObject.js to resources bundle
1059         https://bugs.webkit.org/show_bug.cgi?id=156188
1060         <rdar://problem/25534383>
1061
1062         Reviewed by Alexey Proskuryakov.
1063
1064         * JavaScriptCore.xcodeproj/project.pbxproj:
1065
1066 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
1067
1068         Unreviewed, rolling out r199016.
1069         https://bugs.webkit.org/show_bug.cgi?id=156140
1070
1071         "Regressed Octane and Kraken on the perf bots."
1072
1073         Reverted changeset:
1074
1075         CopiedBlock should be 16kB
1076         https://bugs.webkit.org/show_bug.cgi?id=156168
1077         http://trac.webkit.org/changeset/199016
1078
1079 2016-04-04  Benjamin Poulain  <bpoulain@apple.com>
1080
1081         [JSC][x86] Fix an assertion in MacroAssembler::branch8()
1082         https://bugs.webkit.org/show_bug.cgi?id=156181
1083
1084         Reviewed by Geoffrey Garen.
1085
1086         * assembler/MacroAssemblerX86Common.h:
1087         (JSC::MacroAssemblerX86Common::branch8):
1088         The test was wrong because valid negative numbers have ones
1089         in the top bits.
1090
1091         I replaced the assertion to be explicit about the valid range.
1092
1093 2016-04-04  Chris Dumez  <cdumez@apple.com>
1094
1095         Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings
1096         https://bugs.webkit.org/show_bug.cgi?id=156136
1097         <rdar://problem/25410767>
1098
1099         Reviewed by Ryosuke Niwa.
1100
1101         Add a few more identifiers for using in the generated bindings.
1102
1103         * runtime/CommonIdentifiers.h:
1104
1105 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
1106
1107         CopiedBlock should be 16kB
1108         https://bugs.webkit.org/show_bug.cgi?id=156168
1109
1110         Reviewed by Mark Lam.
1111
1112         MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB,
1113         and the largest page size on Apple devices is 16kB -- so this change
1114         should improve sharing and recycling and keep us on the fast path more.
1115
1116         32kB is also super aggro. At 16kB, we support allocations up to 8kB,
1117         which covers 99.3% of allocations on facebook.com. The 32kB block size
1118         only covered an additional 0.2% of allocations.
1119
1120         * heap/CopiedBlock.h:
1121
1122 2016-04-04  Carlos Garcia Campos  <cgarcia@igalia.com>
1123
1124         REGRESSION(r198792): [GTK] Inspector crashes in Inspector::Protocol::getEnumConstantValue since r198792
1125         https://bugs.webkit.org/show_bug.cgi?id=155745
1126         <rdar://problem/25289456>
1127
1128         Reviewed by Brian Burg.
1129
1130         The problem is that we are generating the Inspector::Protocol::getEnumConstantValue() method and the
1131         enum_constant_values array for every framework that has enum values. So, in case of GTK port we have two
1132         implementations, one for the inspector in JavaScriptCore and another one for Web Automation in WebKit2, but when
1133         using the inspector in WebKit2 we always end up using the one in WebKit2. Since the enum_constant_values array
1134         is smaller in WebKit2 than the one in JavaScriptCore, we crash every time we receive an enum value higher than
1135         the array size. We need to disambiguate the getEnumConstantValue() generated and used for every framework, so we
1136         can use a specific namespace for the enum conversion methods.
1137
1138         * inspector/agents/InspectorDebuggerAgent.cpp:
1139         (Inspector::breakpointActionTypeForString): Use Inspector::Protocol::InspectorHelpers.
1140         * inspector/scripts/codegen/cpp_generator.py:
1141         (CppGenerator.helpers_namespace): Return the namespace name that should be used for the helper methods.
1142         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
1143         (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): Use
1144         CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue().
1145         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Ditto.
1146         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
1147         (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): Ditto.
1148         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
1149         (CppProtocolTypesHeaderGenerator.generate_output): Move declaration of getEnumConstantValue to a helper function.
1150         (_generate_enum_constant_value_conversion_methods): Do not emit any code if there aren't enums and ensure all
1151         conversion methods are declared inside the helpers namespace.
1152         (_generate_builder_setter_for_member): Use CppGenerator.helpers_namespace() to use the right namespace when
1153         using getEnumConstantValue().
1154         (_generate_unchecked_setter_for_member): Ditto.
1155         (_generate_declarations_for_enum_conversion_methods): Return a list instead of a string so that we can return an
1156         empty list in case of not emitting any code. The caller will use extend() that has no effect when an empty list
1157         is passed.
1158         * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
1159         (CppProtocolTypesImplementationGenerator.generate_output): Use the new helper function to generate both the enum
1160         mapping and conversion methods inside the helpers namespace.
1161         (CppProtocolTypesImplementationGenerator._generate_enum_mapping): Return a list instead of a string so that we
1162         can return an empty list in case of not emitting any code.
1163         (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): Ensure we only emit
1164         code when there are enum values, and it's generated inside the helpers namespace.
1165         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
1166         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1167         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
1168         * inspector/scripts/tests/expected/enum-values.json-result:
1169         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
1170         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
1171         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
1172         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
1173         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
1174         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
1175         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
1176         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
1177         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
1178
1179 2016-04-04  Csaba Osztrogon√°c  <ossy@webkit.org>
1180
1181         Unreviewed ARM buildfix after r198981.
1182
1183         * assembler/MacroAssemblerARM.h:
1184         (JSC::MacroAssemblerARM::roundTowardZeroDouble):
1185
1186 2016-04-03  Saam barati  <sbarati@apple.com>
1187
1188         Implement Annex B.3.3 function hoisting rules for function code
1189         https://bugs.webkit.org/show_bug.cgi?id=155672
1190
1191         Reviewed by Geoffrey Garen.
1192
1193         The spec states that functions declared inside a function
1194         inside a block scope are subject to the rules of Annex B.3.3:
1195         https://tc39.github.io/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics
1196
1197         The rule states that functions declared in such blocks should
1198         be local bindings of the block. If declaring the function's name
1199         as a "var" in the function would not lead to a syntax error (i.e,
1200         if we don't have a let/const/class variable with the same name)
1201         and if we don't have a parameter with the same name, then we
1202         implictly also declare the funcion name as a "var". When evaluating
1203         the block statement we bind the hoisted "var" to be the value
1204         of the local function binding.
1205
1206         There is one more thing we do for web compatibility. We allow
1207         function declarations inside if/else statements that aren't
1208         blocks. For such statements, we transform the code as if the
1209         function were declared inside a block statement. For example:
1210         ``` function foo() { if (cond) function baz() { } }```
1211         is transformed into:
1212         ``` function foo() { if (cond) { function baz() { } } }```
1213
1214         * bytecompiler/BytecodeGenerator.cpp:
1215         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
1216         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1217         * bytecompiler/BytecodeGenerator.h:
1218         * parser/Nodes.cpp:
1219         (JSC::ScopeNode::ScopeNode):
1220         (JSC::ProgramNode::ProgramNode):
1221         (JSC::ModuleProgramNode::ModuleProgramNode):
1222         (JSC::EvalNode::EvalNode):
1223         (JSC::FunctionNode::FunctionNode):
1224         * parser/Nodes.h:
1225         (JSC::ScopeNode::hasCapturedVariables):
1226         (JSC::ScopeNode::captures):
1227         (JSC::ScopeNode::hasSloppyModeHoistedFunction):
1228         (JSC::ScopeNode::varDeclarations):
1229         (JSC::ProgramNode::startColumn):
1230         (JSC::ProgramNode::endColumn):
1231         (JSC::EvalNode::startColumn):
1232         (JSC::EvalNode::endColumn):
1233         (JSC::ModuleProgramNode::startColumn):
1234         (JSC::ModuleProgramNode::endColumn):
1235         * parser/Parser.cpp:
1236         (JSC::Parser<LexerType>::Parser):
1237         (JSC::Parser<LexerType>::parseInner):
1238         (JSC::Parser<LexerType>::didFinishParsing):
1239         (JSC::Parser<LexerType>::parseStatement):
1240         (JSC::Parser<LexerType>::parseIfStatement):
1241         * parser/Parser.h:
1242         (JSC::Scope::declareVariable):
1243         (JSC::Scope::declareFunction):
1244         (JSC::Scope::addSloppyModeHoistableFunctionCandidate):
1245         (JSC::Scope::appendFunction):
1246         (JSC::Scope::declareParameter):
1247         (JSC::Scope::mergeInnerArrowFunctionFeatures):
1248         (JSC::Scope::getSloppyModeHoistedFunctions):
1249         (JSC::Scope::getCapturedVars):
1250         (JSC::ScopeRef::containingScope):
1251         (JSC::ScopeRef::operator==):
1252         (JSC::ScopeRef::operator!=):
1253         (JSC::Parser::declareFunction):
1254         (JSC::Parser::hasDeclaredVariable):
1255         (JSC::Parser::isFunctionMetadataNode):
1256         (JSC::Parser::DepthManager::DepthManager):
1257         (JSC::Parser<LexerType>::parse):
1258         * parser/VariableEnvironment.h:
1259         (JSC::VariableEnvironmentEntry::isImported):
1260         (JSC::VariableEnvironmentEntry::isImportedNamespace):
1261         (JSC::VariableEnvironmentEntry::isFunction):
1262         (JSC::VariableEnvironmentEntry::isParameter):
1263         (JSC::VariableEnvironmentEntry::isSloppyModeHoistingCandidate):
1264         (JSC::VariableEnvironmentEntry::setIsCaptured):
1265         (JSC::VariableEnvironmentEntry::setIsConst):
1266         (JSC::VariableEnvironmentEntry::setIsImported):
1267         (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
1268         (JSC::VariableEnvironmentEntry::setIsFunction):
1269         (JSC::VariableEnvironmentEntry::setIsParameter):
1270         (JSC::VariableEnvironmentEntry::setIsSloppyModeHoistingCandidate):
1271         (JSC::VariableEnvironmentEntry::clearIsVar):
1272         * runtime/CodeCache.h:
1273         (JSC::SourceCodeValue::SourceCodeValue):
1274         * runtime/JSScope.cpp:
1275         * runtime/JSScope.h:
1276         * tests/es6.yaml:
1277         * tests/stress/sloppy-mode-function-hoisting.js: Added.
1278         (assert):
1279         (test):
1280         (falsey):
1281         (truthy):
1282         (test.):
1283         (test.a):
1284         (test.f):
1285         (test.let.funcs.f):
1286         (test.catch.f):
1287         (test.foo):
1288         (test.bar):
1289         (test.switch.case.0):
1290         (test.else.f):
1291         (test.b):
1292         (test.c):
1293         (test.d):
1294         (test.e):
1295         (test.g):
1296         (test.h):
1297         (test.i):
1298         (test.j):
1299         (test.k):
1300         (test.l):
1301         (test.m):
1302         (test.n):
1303         (test.o):
1304         (test.p):
1305         (test.q):
1306         (test.r):
1307         (test.s):
1308         (test.t):
1309         (test.u):
1310         (test.v):
1311         (test.w):
1312         (test.x):
1313         (test.y):
1314         (test.z):
1315         (foo):
1316         (bar):
1317         (falsey.bar):
1318         (baz):
1319         (falsey.baz):
1320
1321 2016-04-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1322
1323         Unreviewed, turn ES6 for-in loop test success
1324         https://bugs.webkit.org/show_bug.cgi?id=155451
1325
1326         * tests/es6.yaml:
1327
1328 2016-04-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1329
1330         [JSC] Add truncate operation (rounding to zero)
1331         https://bugs.webkit.org/show_bug.cgi?id=156072
1332
1333         Reviewed by Saam Barati.
1334
1335         Add TruncIntrinsic for Math.trunc. DFG handles it as ArithTrunc.
1336         In DFG, ArithTrunc behaves similar to ArithRound, ArithCeil, and ArithFloor.
1337         ArithTrunc rounds the value towards zero.
1338
1339         And we rewrite @toInteger to use @trunc instead of @abs, @floor, negation and branch.
1340         This is completely the same to what we do in JSValue::toInteger.
1341
1342         Since DFG recognize it, DFG can convert ArithTrunc to Identity if the given argument is Int32.
1343         This is useful because almost all the argument is Int32 in @toLength -> @toInteger -> @trunc case.
1344         In such cases, we can eliminate trunc() call.
1345
1346         As a bonus, to speed up Math.trunc operation, we use x86 SSE round and frintz in ARM64 for ArithRound.
1347         In DFG, we emit these instructions. In FTL, we use Patchpoint to emit these instructions to avoid adding a new B3 IR.
1348
1349         * assembler/MacroAssemblerARM64.h:
1350         (JSC::MacroAssemblerARM64::roundTowardZeroDouble):
1351         (JSC::MacroAssemblerARM64::roundTowardZeroFloat):
1352         * assembler/MacroAssemblerARMv7.h:
1353         (JSC::MacroAssemblerARMv7::roundTowardZeroDouble):
1354         * assembler/MacroAssemblerMIPS.h:
1355         (JSC::MacroAssemblerMIPS::roundTowardZeroDouble):
1356         * assembler/MacroAssemblerSH4.h:
1357         (JSC::MacroAssemblerSH4::roundTowardZeroDouble):
1358         * assembler/MacroAssemblerX86Common.h:
1359         (JSC::MacroAssemblerX86Common::roundTowardZeroDouble):
1360         (JSC::MacroAssemblerX86Common::roundTowardZeroFloat):
1361         * builtins/GlobalObject.js:
1362         (toInteger):
1363         * dfg/DFGAbstractInterpreterInlines.h:
1364         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1365         * dfg/DFGByteCodeParser.cpp:
1366         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1367         * dfg/DFGClobberize.h:
1368         (JSC::DFG::clobberize):
1369         * dfg/DFGDoesGC.cpp:
1370         (JSC::DFG::doesGC):
1371         * dfg/DFGFixupPhase.cpp:
1372         (JSC::DFG::FixupPhase::fixupNode):
1373         * dfg/DFGGraph.h:
1374         (JSC::DFG::Graph::roundShouldSpeculateInt32):
1375         * dfg/DFGNode.h:
1376         (JSC::DFG::Node::arithNodeFlags):
1377         (JSC::DFG::Node::hasHeapPrediction):
1378         (JSC::DFG::Node::hasArithRoundingMode):
1379         * dfg/DFGNodeType.h:
1380         * dfg/DFGPredictionPropagationPhase.cpp:
1381         (JSC::DFG::PredictionPropagationPhase::propagate):
1382         * dfg/DFGSafeToExecute.h:
1383         (JSC::DFG::safeToExecute):
1384         * dfg/DFGSpeculativeJIT.cpp:
1385         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1386         * dfg/DFGSpeculativeJIT.h:
1387         * dfg/DFGSpeculativeJIT32_64.cpp:
1388         (JSC::DFG::SpeculativeJIT::compile):
1389         * dfg/DFGSpeculativeJIT64.cpp:
1390         (JSC::DFG::SpeculativeJIT::compile):
1391         * ftl/FTLCapabilities.cpp:
1392         (JSC::FTL::canCompile):
1393         * ftl/FTLLowerDFGToB3.cpp:
1394         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1395         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
1396         * ftl/FTLOutput.cpp:
1397         (JSC::FTL::Output::doubleTrunc):
1398         * ftl/FTLOutput.h:
1399         * jit/ThunkGenerators.cpp:
1400         (JSC::truncThunkGenerator):
1401         * jit/ThunkGenerators.h:
1402         * runtime/CommonIdentifiers.h:
1403         * runtime/Intrinsic.h:
1404         * runtime/JSGlobalObject.cpp:
1405         (JSC::JSGlobalObject::init):
1406         * runtime/MathObject.cpp:
1407         (JSC::MathObject::finishCreation):
1408         * runtime/MathObject.h:
1409         * runtime/VM.cpp:
1410         (JSC::thunkGeneratorForIntrinsic):
1411         * tests/stress/math-rounding-infinity.js:
1412         (testTrunc):
1413         * tests/stress/math-rounding-nan.js:
1414         (testTrunc):
1415         * tests/stress/math-rounding-negative-zero.js:
1416         (testTrunc):
1417         * tests/stress/math-trunc-arith-rounding-mode.js: Added.
1418         (firstCareAboutZeroSecondDoesNot):
1419         (firstDoNotCareAboutZeroSecondDoes):
1420         (warmup):
1421         (verifyNegativeZeroIsPreserved):
1422         * tests/stress/math-trunc-basics.js: Added.
1423         (mathTruncOnIntegers):
1424         (mathTruncOnDoubles):
1425         (mathTruncOnBooleans):
1426         (uselessMathTrunc):
1427         (mathTruncWithOverflow):
1428         (mathTruncConsumedAsDouble):
1429         (mathTruncDoesNotCareAboutMinusZero):
1430         (mathTruncNoArguments):
1431         (mathTruncTooManyArguments):
1432         (testMathTruncOnConstants):
1433         (mathTruncStructTransition):
1434         (Math.trunc):
1435         * tests/stress/math-trunc-should-be-truncate.js: Added.
1436         (mathTrunc):
1437
1438 2016-04-03  Skachkov Oleksandr  <gskachkov@gmail.com>
1439
1440         [ES6] Class syntax. Access to new.target inside of the eval should not lead to SyntaxError
1441         https://bugs.webkit.org/show_bug.cgi?id=155545
1442
1443         Reviewed by Saam Barati.
1444        
1445         Current patch allow to invoke new.target in eval if this eval is executed within function, 
1446         otherwise this will lead to Syntax error 
1447    
1448         * bytecode/EvalCodeCache.h:
1449         (JSC::EvalCodeCache::getSlow):
1450         * bytecode/ExecutableInfo.h:
1451         (JSC::ExecutableInfo::ExecutableInfo):
1452         (JSC::ExecutableInfo::evalContextType):
1453         * bytecode/UnlinkedCodeBlock.cpp:
1454         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1455         * bytecode/UnlinkedCodeBlock.h:
1456         (JSC::UnlinkedCodeBlock::evalContextType):
1457         * bytecode/UnlinkedFunctionExecutable.cpp:
1458         (JSC::generateUnlinkedFunctionCodeBlock):
1459         * debugger/DebuggerCallFrame.cpp:
1460         (JSC::DebuggerCallFrame::evaluate):
1461         * interpreter/Interpreter.cpp:
1462         (JSC::eval):
1463         * parser/Parser.cpp:
1464         (JSC::Parser<LexerType>::Parser):
1465         (JSC::Parser<LexerType>::parseMemberExpression):
1466         * parser/Parser.h:
1467         (JSC::Scope::Scope):
1468         (JSC::Scope::setEvalContextType):
1469         (JSC::Scope::evalContextType):
1470         (JSC::parse):
1471         * runtime/CodeCache.cpp:
1472         (JSC::CodeCache::getGlobalCodeBlock):
1473         (JSC::CodeCache::getProgramCodeBlock):
1474         (JSC::CodeCache::getEvalCodeBlock):
1475         (JSC::CodeCache::getModuleProgramCodeBlock):
1476         * runtime/CodeCache.h:
1477         * runtime/Executable.cpp:
1478         (JSC::ScriptExecutable::ScriptExecutable):
1479         (JSC::EvalExecutable::create):
1480         (JSC::EvalExecutable::EvalExecutable):
1481         (JSC::ProgramExecutable::ProgramExecutable):
1482         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
1483         (JSC::FunctionExecutable::FunctionExecutable):
1484         * runtime/Executable.h:
1485         (JSC::ScriptExecutable::evalContextType):
1486         * runtime/JSGlobalObject.cpp:
1487         (JSC::JSGlobalObject::createEvalCodeBlock):
1488         * runtime/JSGlobalObjectFunctions.cpp:
1489         (JSC::globalFuncEval):
1490         * tests/stress/arrowfunction-lexical-bind-newtarget.js:
1491         * tests/stress/new-target.js:
1492
1493 2016-04-02  Commit Queue  <commit-queue@webkit.org>
1494
1495         Unreviewed, rolling out r198976.
1496         https://bugs.webkit.org/show_bug.cgi?id=156140
1497
1498         "Causes js/regress/array-nonarray-polymorhpic-access.html to
1499         crash." (Requested by ddkilzer on #webkit).
1500
1501         Reverted changeset:
1502
1503         "[JSC] Initialize SSA's live values at tail lazily"
1504         https://bugs.webkit.org/show_bug.cgi?id=156126
1505         http://trac.webkit.org/changeset/198976
1506
1507 2016-04-02  Benjamin Poulain  <bpoulain@apple.com>
1508
1509         [JSC] Initialize SSA's live values at tail lazily
1510         https://bugs.webkit.org/show_bug.cgi?id=156126
1511
1512         Reviewed by Mark Lam.
1513
1514         Setting up the clean state early looks harmless but it is
1515         actually quite expensive.
1516
1517         The problem is AbstractValue is gigantic, you really want
1518         to minimize how much you touch that memory.
1519
1520         By removing the initialization, most blocks only
1521         get 2 or 3 accesses. Once to setup the value, and a few
1522         queries for merging the current block with the successors.
1523
1524         * dfg/DFGInPlaceAbstractState.cpp:
1525         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
1526         (JSC::DFG::setLiveValues): Deleted.
1527         (JSC::DFG::InPlaceAbstractState::initialize): Deleted.
1528
1529 2016-04-02  Benjamin Poulain  <bpoulain@apple.com>
1530
1531         [JSC] Add an option to avoid disassembling baseline code for the JSC Profiler
1532         https://bugs.webkit.org/show_bug.cgi?id=156127
1533
1534         Reviewed by Mark Lam.
1535
1536         The profiler run out of memory on big programs if you dump
1537         the baseline disassembly.
1538
1539         * jit/JIT.cpp:
1540         (JSC::JIT::privateCompile):
1541         * runtime/Options.h:
1542
1543 2016-04-02  Dan Bernstein  <mitz@apple.com>
1544
1545         jsc binary embedded in relocatable JavaScriptCore.framework links against system JavaScriptCore.framework
1546         https://bugs.webkit.org/show_bug.cgi?id=156134
1547         <rdar://problem/25443824>
1548
1549         Reviewed by Mark Lam.
1550
1551         * Configurations/JSC.xcconfig: Define WK_RELOCATABLE_FRAMEWORKS_LDFLAGS when building
1552           relocatable frameworks to include a -dyld_env option setting DYLD_FRAMEWORK_PATH to point
1553           to the directory containing JavaScript.framework, and add
1554           WK_RELOCATABLE_FRAMEWORKS_LDFLAGS to OTHER_LDFLAGS.
1555
1556 2016-04-01  Benjamin Poulain  <bpoulain@apple.com>
1557
1558         [JSC][x86] Add the 3 operands form of floating point substraction
1559         https://bugs.webkit.org/show_bug.cgi?id=156095
1560
1561         Reviewed by Geoffrey Garen.
1562
1563         Same old, same old. Add the AVX form of subsd and subss.
1564
1565         Unfortunately, we cannot benefit from the 3 register form
1566         in B3 yet because the Air script does not support CPU flags yet.
1567         That can be fixed later.
1568
1569         * assembler/MacroAssemblerX86Common.h:
1570         (JSC::MacroAssemblerX86Common::subDouble):
1571         (JSC::MacroAssemblerX86Common::subFloat):
1572         * assembler/X86Assembler.h:
1573         (JSC::X86Assembler::vsubsd_rr):
1574         (JSC::X86Assembler::subsd_mr):
1575         (JSC::X86Assembler::vsubsd_mr):
1576         (JSC::X86Assembler::vsubss_rr):
1577         (JSC::X86Assembler::subss_mr):
1578         (JSC::X86Assembler::vsubss_mr):
1579         (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
1580         * b3/air/AirOpcode.opcodes:
1581
1582 2016-04-01  Alberto Garcia  <berto@igalia.com>
1583
1584         [JSC] Missing PATH_MAX definition
1585         https://bugs.webkit.org/show_bug.cgi?id=156102
1586
1587         Reviewed by Yusuke Suzuki.
1588
1589         Not all systems define PATH_MAX, so add a fallback value that is
1590         long enough.
1591
1592         * jsc.cpp:
1593
1594 2016-03-31  Benjamin Poulain  <bpoulain@apple.com>
1595
1596         [JSC] CFA's valuesAtHead should be a list, not a map
1597         https://bugs.webkit.org/show_bug.cgi?id=156087
1598
1599         Reviewed by Mark Lam.
1600
1601         One more step toward moving to the Air-style of liveness analysis:
1602
1603         Make DFG's valuesAtHead a list of Node*-AbstractValue.
1604         This patch alone is already a speedup because our many CFAs
1605         spend an unreasonable amount of time updating at block boundaries.
1606
1607         * dfg/DFGBasicBlock.h:
1608         * dfg/DFGCFAPhase.cpp:
1609         (JSC::DFG::CFAPhase::performBlockCFA):
1610         * dfg/DFGGraph.cpp:
1611         (JSC::DFG::Graph::dump):
1612         * dfg/DFGInPlaceAbstractState.cpp:
1613         (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
1614         (JSC::DFG::setLiveValues):
1615         (JSC::DFG::InPlaceAbstractState::merge):
1616         * dfg/DFGNode.h:
1617         (JSC::DFG::nodeValuePairComparator):
1618         (JSC::DFG::nodeValuePairListDump):
1619
1620 2016-03-31  Saam barati  <sbarati@apple.com>
1621
1622         Revert rewrite const as var workaround
1623         https://bugs.webkit.org/show_bug.cgi?id=155393
1624
1625         Reviewed by Mark Lam.
1626
1627         * parser/Parser.h:
1628         (JSC::Parser::next):
1629         (JSC::Parser::nextExpectIdentifier):
1630         * runtime/VM.h:
1631         (JSC::VM::setShouldRewriteConstAsVar): Deleted.
1632         (JSC::VM::shouldRewriteConstAsVar): Deleted.
1633
1634 2016-03-31  Saam barati  <sbarati@apple.com>
1635
1636         [ES6] Disallow var assignments in for-in loops
1637         https://bugs.webkit.org/show_bug.cgi?id=155451
1638
1639         Reviewed by Mark Lam.
1640
1641         We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
1642         because last time we made this change it broke some websites. Lets try making
1643         it again because it's what the ES6 mandates. If it still breaks things we will
1644         roll it out.
1645
1646         * parser/Parser.cpp:
1647         (JSC::Parser<LexerType>::parseForStatement):
1648
1649 2016-03-31  Saam barati  <sbarati@apple.com>
1650
1651         parsing arrow function expressions slows down the parser by 8% lets recoup some loss
1652         https://bugs.webkit.org/show_bug.cgi?id=155988
1653
1654         Reviewed by Benjamin Poulain.
1655
1656         We used to eagerly check if we're parsing an arrow function.
1657         We did this inside parseAssignmentExpression(), and it was
1658         very costly. The reason it was costly is that arrow functions
1659         might start with an identifier. This means anytime we saw an
1660         identifier we would have to do a lookahead, and then most likely
1661         backtrack because more often than not, we wouldn't see "=>"
1662         as the next token.
1663
1664         In this patch I implement a new approach. We just parse
1665         the lhs of an assignment expression eagerly without doing any
1666         lookahead. Retroactively, if we see that we might have started
1667         with an arrow function, and we don't have a valid lhs or the
1668         next token is a "=>", we try to parse as an arrow function.
1669
1670         Here are a few examples motivating why this is valid:
1671
1672         `x => x`
1673         In this example:
1674         - "x" is a valid arrow function starting point.
1675         - "x" also happens to be a valid lhs
1676         - because we see "=>" as the next token, we parse as an arrow function and succeed.
1677
1678         `(x) => x`
1679         In this example:
1680         - "(" is a valid arrow function starting point.
1681         - "(x)" also happens to be a valid lhs
1682         - because we see "=>" as the next token, we parse as an arrow function and succeed.
1683
1684         `({x = 30}) => x;`
1685         In this example:
1686         - "(" is a valid arrow function starting point.
1687         - "({x = 30})" is NOT a valid lhs. Because of this, we try to parse it as an arrow function and succeed.
1688
1689         There is one interesting implementation detail where we might
1690         parse something that is both a valid LHS but happens
1691         to actually be the arrow function parameters. The valid LHS
1692         parsing might declare such variables as "uses" which would cause 
1693         weird capture analysis. This patch also introduces a mechanism
1694         to backtrack on used variable analysis.
1695
1696         This is a 3.5%-4.5% octane code load speedup.
1697
1698         * parser/Lexer.h:
1699         (JSC::Lexer::sawError):
1700         (JSC::Lexer::setSawError):
1701         (JSC::Lexer::getErrorMessage):
1702         (JSC::Lexer::setErrorMessage):
1703         (JSC::Lexer::sourceURL):
1704         (JSC::Lexer::sourceMappingURL):
1705         * parser/Parser.cpp:
1706         (JSC::Parser<LexerType>::isArrowFunctionParameters):
1707         (JSC::Parser<LexerType>::parseAssignmentExpression):
1708         (JSC::Parser<LexerType>::parsePrimaryExpression):
1709         * parser/Parser.h:
1710         (JSC::Scope::Scope):
1711         (JSC::Scope::startSwitch):
1712         (JSC::Scope::declareParameter):
1713         (JSC::Scope::usedVariablesContains):
1714         (JSC::Scope::useVariable):
1715         (JSC::Scope::pushUsedVariableSet):
1716         (JSC::Scope::currentUsedVariablesSize):
1717         (JSC::Scope::revertToPreviousUsedVariables):
1718         (JSC::Scope::setNeedsFullActivation):
1719         (JSC::Scope::needsFullActivation):
1720         (JSC::Scope::isArrowFunctionBoundary):
1721         (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
1722         (JSC::Scope::collectFreeVariables):
1723         (JSC::Scope::fillParametersForSourceProviderCache):
1724         (JSC::Scope::restoreFromSourceProviderCache):
1725         (JSC::Scope::setIsModule):
1726
1727 2016-03-31  Yusuke Suzuki  <utatane.tea@gmail.com>
1728
1729         Fails to build in Linux / PowerPC due to different ucontext_t definition
1730         https://bugs.webkit.org/show_bug.cgi?id=156015
1731
1732         Reviewed by Michael Catanzaro.
1733
1734         PPC does not have mcontext_t in ucontext_t::uc_mcontext.
1735         So we take the special way to retrieve mcontext_t in PPC.
1736
1737         * heap/MachineStackMarker.cpp:
1738         (pthreadSignalHandlerSuspendResume):
1739
1740 2016-03-31  Benjamin Poulain  <benjamin@webkit.org>
1741
1742         [JSC][x86] Add the indexed forms of floating point addition and multiplication
1743         https://bugs.webkit.org/show_bug.cgi?id=156058
1744
1745         Reviewed by Geoffrey Garen.
1746
1747         B3 supports lowering [base, index] addresses into
1748         arbitrary instructions but we were not using that feature.
1749
1750         This patch adds the missing support for the lowering
1751         of Add and Mul.
1752
1753         * assembler/MacroAssemblerX86Common.h:
1754         (JSC::MacroAssemblerX86Common::addDouble):
1755         (JSC::MacroAssemblerX86Common::addFloat):
1756         (JSC::MacroAssemblerX86Common::mulDouble):
1757         (JSC::MacroAssemblerX86Common::mulFloat):
1758         * assembler/X86Assembler.h:
1759         (JSC::X86Assembler::addsd_mr):
1760         (JSC::X86Assembler::vaddsd_mr):
1761         (JSC::X86Assembler::addss_mr):
1762         (JSC::X86Assembler::vaddss_mr):
1763         (JSC::X86Assembler::mulsd_mr):
1764         (JSC::X86Assembler::vmulsd_mr):
1765         (JSC::X86Assembler::mulss_mr):
1766         (JSC::X86Assembler::vmulss_mr):
1767         (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
1768         * b3/B3LowerToAir.cpp:
1769         (JSC::B3::Air::LowerToAir::appendBinOp):
1770         Unlike the Addr form, we never need to transform a Tmp
1771         into an Index for spilling.
1772
1773         Instead of duplicating all the code in MacroAssembler, I can
1774         just have the lowering phase try using addresses for the first
1775         argument when possible.
1776
1777         * b3/air/AirOpcode.opcodes:
1778         * b3/air/testair.cpp:
1779         (JSC::B3::Air::testX86VMULSDBaseNeedsRex):
1780         (JSC::B3::Air::testX86VMULSDIndexNeedsRex):
1781         (JSC::B3::Air::testX86VMULSDBaseIndexNeedRex):
1782         (JSC::B3::Air::run):
1783
1784 2016-03-31  Saam barati  <sbarati@apple.com>
1785
1786         DFG JIT bug in typeof constant folding where the input to typeof is an object or function
1787         https://bugs.webkit.org/show_bug.cgi?id=156034
1788         <rdar://problem/25446785>
1789
1790         Reviewed by Ryosuke Niwa.
1791
1792         AI would constant fold TypeOf to the string "object" if it saw that
1793         its input type didn't expand past the types contained in the set 
1794         "SpecObject - SpecObjectOther". But, SpecObject contains SpecFunction.
1795         And typeof of a function should return "function". This patch fixes
1796         this bug by making sure we constant fold to object iff the type
1797         doesn't expand past the set "SpecObject - SpecObjectOther - SpecFunction".
1798
1799         * dfg/DFGAbstractInterpreterInlines.h:
1800         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1801         * tests/stress/typeof-dfg-function-or-object.js: Added.
1802         (assert):
1803         (foo.else.o):
1804         (foo):
1805
1806 2016-03-31  Mark Lam  <mark.lam@apple.com>
1807
1808         Gardening: Build and logic fix after r198873.
1809         https://bugs.webkit.org/show_bug.cgi?id=156043
1810
1811         Not reviewed.
1812
1813         * assembler/MacroAssemblerX86Common.h:
1814         (JSC::MacroAssemblerX86Common::addFloat):
1815         - 2 args were meant to be ordered differently in order to call the other addFloat.
1816           Instead, there was an infinite recursion bug.  This is now fixed.
1817
1818 2016-03-30  Benjamin Poulain  <benjamin@webkit.org>
1819
1820         [JSC][x86] Add the 3 operands forms of floating point addition and multiplication
1821         https://bugs.webkit.org/show_bug.cgi?id=156043
1822
1823         Reviewed by Geoffrey Garen.
1824
1825         When they are available, VADD and VMUL are better options to lower
1826         floating point addition and multiplication.
1827
1828         In the simple cases when one of the operands is aliased to the destination,
1829         those forms have the same size or 1 byte shorter depending on the registers.
1830
1831         In the more advanced cases, we gain nice advantages with the new forms:
1832         -We can get rid of the MoveDouble in front the instruction when we cannot
1833          alias.
1834         -We can disable aliasing entirely in Air. That is useful for latency
1835          since computing coalescing is not exactly cheap.
1836
1837         * assembler/MacroAssemblerX86Common.cpp:
1838         * assembler/MacroAssemblerX86Common.h:
1839         (JSC::MacroAssemblerX86Common::and32):
1840         (JSC::MacroAssemblerX86Common::mul32):
1841         (JSC::MacroAssemblerX86Common::or32):
1842         (JSC::MacroAssemblerX86Common::xor32):
1843         (JSC::MacroAssemblerX86Common::branchAdd32):
1844         The change in B3LowerToAir exposed a bug in the fake 3 operands
1845         forms of those instructions. If the address is equal to
1846         the destination, we were nuking the address.
1847
1848         For example,
1849             Add32([%r11], %eax, %r11)
1850         would generate:
1851             move %eax, %r11
1852             add32 [%r11], %r11
1853         which crashes.
1854
1855         I updated codegen of those cases to support that case through
1856             load32 [%r11], %r11
1857             add32 %eax, %r11
1858
1859         The weird case were all arguments have the same registers
1860         is handled too.
1861
1862         (JSC::MacroAssemblerX86Common::addDouble):
1863         (JSC::MacroAssemblerX86Common::addFloat):
1864         (JSC::MacroAssemblerX86Common::mulDouble):
1865         (JSC::MacroAssemblerX86Common::mulFloat):
1866         (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
1867         (JSC::MacroAssemblerX86Common::supportsAVX):
1868         (JSC::MacroAssemblerX86Common::updateEax1EcxFlags):
1869         * assembler/MacroAssemblerX86_64.h:
1870         (JSC::MacroAssemblerX86_64::branchAdd64):
1871         * assembler/X86Assembler.h:
1872         (JSC::X86Assembler::vaddsd_rr):
1873         (JSC::X86Assembler::vaddsd_mr):
1874         (JSC::X86Assembler::vaddss_rr):
1875         (JSC::X86Assembler::vaddss_mr):
1876         (JSC::X86Assembler::vmulsd_rr):
1877         (JSC::X86Assembler::vmulsd_mr):
1878         (JSC::X86Assembler::vmulss_rr):
1879         (JSC::X86Assembler::vmulss_mr):
1880         (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
1881         * b3/B3LowerToAir.cpp:
1882         (JSC::B3::Air::LowerToAir::appendBinOp):
1883         Add the 3 operand forms so that we lower Add and Mul
1884         to the best form directly.
1885
1886         I will change how we lower the fake 3 operands instructions
1887         but the codegen should end up the same in most cases.
1888         The new codegen is the load32 + op above.
1889
1890         * b3/air/AirInstInlines.h:
1891         (JSC::B3::Air::Inst::shouldTryAliasingDef):
1892         * b3/air/testair.cpp:
1893         (JSC::B3::Air::testX86VMULSD):
1894         (JSC::B3::Air::testX86VMULSDDestRex):
1895         (JSC::B3::Air::testX86VMULSDOp1DestRex):
1896         (JSC::B3::Air::testX86VMULSDOp2DestRex):
1897         (JSC::B3::Air::testX86VMULSDOpsDestRex):
1898         (JSC::B3::Air::testX86VMULSDAddr):
1899         (JSC::B3::Air::testX86VMULSDAddrOpRexAddr):
1900         (JSC::B3::Air::testX86VMULSDDestRexAddr):
1901         (JSC::B3::Air::testX86VMULSDRegOpDestRexAddr):
1902         (JSC::B3::Air::testX86VMULSDAddrOpDestRexAddr):
1903         Make sure we have some coverage for AVX encoding of instructions.
1904
1905 2016-03-30  Saam Barati  <sbarati@apple.com>
1906
1907         Change some release asserts in CodeBlock linking into debug asserts
1908         https://bugs.webkit.org/show_bug.cgi?id=155500
1909
1910         Reviewed by Filip Pizlo.
1911
1912         * bytecode/CodeBlock.cpp:
1913         (JSC::CodeBlock::finishCreation):
1914
1915 2016-03-30  Joseph Pecoraro  <pecoraro@apple.com>
1916
1917         Remove unused ScriptProfiler.Samples.totalTime
1918         https://bugs.webkit.org/show_bug.cgi?id=156002
1919
1920         Reviewed by Saam Barati.
1921
1922         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1923         (Inspector::buildSamples):
1924         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
1925         * inspector/protocol/ScriptProfiler.json:
1926         Remove totalTime.
1927
1928         * runtime/SamplingProfiler.cpp:
1929         (JSC::SamplingProfiler::SamplingProfiler): Deleted.
1930         * runtime/SamplingProfiler.h:
1931         (JSC::SamplingProfiler::totalTime): Deleted.
1932         Remove now unused m_totalTime.
1933
1934 2016-03-30  Michael Saboff  <msaboff@apple.com>
1935
1936         [ES6] Quantified unicode regular expressions do not work for counts greater than 1
1937         https://bugs.webkit.org/show_bug.cgi?id=156044
1938
1939         Reviewed by Mark Lam.
1940
1941         Fixed incorrect indexing of non-BMP characters in fixed patterns.  The old code
1942         was indexing by character units, a single JS character, instead of code points
1943         which is 2 JS characters.
1944
1945         * yarr/YarrInterpreter.cpp:
1946         (JSC::Yarr::Interpreter::matchDisjunction):
1947
1948 2016-03-30  Mark Lam  <mark.lam@apple.com>
1949
1950         Make the $vm debugging tools available to builtins as @$vm.
1951         https://bugs.webkit.org/show_bug.cgi?id=156012
1952
1953         Reviewed by Saam Barati.
1954
1955         We also need some debugging tools for builtin development.  The $vm object will
1956         be made available to builtins as @$vm, which gives us, amongst many goodies,
1957         @$vm.print() (which prints the toString() values of its args) and
1958         @$vm.printValue() (which dataLogs its arg as a JSValue).  @$vm will only be
1959         available if we run with JSC_useDollarVM=true.
1960
1961         Also changed @$vm.print() to not automatically insert a space between the
1962         printing of each of its args.  This makes it clearer as to what will be printed
1963         i.e. it will only print what is passed to it.
1964
1965         * builtins/BuiltinNames.h:
1966         (JSC::BuiltinNames::BuiltinNames):
1967         (JSC::BuiltinNames::dollarVMPublicName):
1968         (JSC::BuiltinNames::dollarVMPrivateName):
1969         * runtime/JSGlobalObject.cpp:
1970         (JSC::JSGlobalObject::init):
1971         * tools/JSDollarVMPrototype.cpp:
1972         (JSC::functionPrint):
1973
1974 2016-03-30  Keith Miller  <keith_miller@apple.com>
1975
1976         Unreviewed, buildfix.
1977
1978         * bytecode/BytecodeIntrinsicRegistry.h:
1979
1980 2016-03-30  Keith Miller <keith_miller@apple.com>
1981
1982         Unreviewed, rollout r198808. The patch causes crashes on 32-bit and appears to be a JSBench regression.
1983
1984 2016-03-30  Yusuke Suzuki  <utatane.tea@gmail.com>
1985
1986         [JSC] Implement String.prototype.repeat in builtins JS
1987         https://bugs.webkit.org/show_bug.cgi?id=155974
1988
1989         Reviewed by Darin Adler.
1990
1991         This patch converts C++ String.prototype.repeat implementation into JS builtins.
1992         |this| in strict mode is correctly inferred as String[1]. This fact encourages us
1993         to write PrimitiveTypes.prototype.XXX methods in builtin JS.
1994
1995         LayoutTests/js/string-repeat.html already covers the tests for this change.
1996
1997         Note: String.prototype.repeat functionality is similar to Harmony's
1998         String.prototype.{padStart, padEnd}. It's nice to port them to builtin JS in
1999         the other patch.
2000
2001         The existing C++ code has the fast path for singleCharacterString repeating.
2002         Since this use is important (e.g. generating N length spaces: ' '.repeat(N)),
2003         we keep this fast path as @repeatCharacter().
2004
2005         The performance results show that, while the performance of the single character fast path
2006         is neutral, other string repeating has significant speed up.
2007         There are two reasons.
2008
2009         1. Not resolving string rope.
2010
2011         We added several tests postfixed "not-resolving". In that tests, we do not touch the content
2012         of the generated string. As a result, the generated rope is not resolved.
2013
2014         2. O(log N) intermediate JSRopeStrings.
2015
2016         In the existing C++ implementation, we use JSString::RopeBuilder. We iterate N times and append
2017         the given string to the builder.
2018         In this case, the intermediate rope strings generated in JSString::RopeBuilder is O(N).
2019         In JS builtin implementation, we only iterate log N times. As a result, the number of the
2020         intermediate rope strings becomes O(log N).
2021
2022         [1]: http://trac.webkit.org/changeset/195938
2023
2024         * builtins/StringPrototype.js:
2025         (repeatSlowPath):
2026         (repeat):
2027         * bytecode/BytecodeIntrinsicRegistry.cpp:
2028         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2029         * bytecode/BytecodeIntrinsicRegistry.h:
2030         * runtime/CommonIdentifiers.h:
2031         * runtime/JSGlobalObject.cpp:
2032         (JSC::JSGlobalObject::init):
2033         * runtime/StringPrototype.cpp:
2034         (JSC::stringProtoFuncRepeatCharacter):
2035         (JSC::StringPrototype::finishCreation): Deleted.
2036         (JSC::stringProtoFuncRepeat): Deleted.
2037         * runtime/StringPrototype.h:
2038         * tests/stress/string-repeat-edge-cases.js: Added.
2039         (shouldBe):
2040         (let.object.toString):
2041         (valueOf):
2042         (shouldThrow):
2043
2044 2016-03-30  Benjamin Poulain  <benjamin@webkit.org>
2045
2046         [JSC] Update udis86
2047         https://bugs.webkit.org/show_bug.cgi?id=156005
2048
2049         Reviewed by Geoffrey Garen.
2050
2051         * CMakeLists.txt:
2052         * DerivedSources.make:
2053         * JavaScriptCore.xcodeproj/project.pbxproj:
2054         * disassembler/udis86/differences.txt:
2055         * disassembler/udis86/itab.py: Removed.
2056         * disassembler/udis86/optable.xml:
2057         * disassembler/udis86/ud_itab.py: Added.
2058         * disassembler/udis86/ud_opcode.py:
2059         * disassembler/udis86/ud_optable.py: Removed.
2060         * disassembler/udis86/udis86.c:
2061         * disassembler/udis86/udis86_decode.c:
2062         * disassembler/udis86/udis86_decode.h:
2063         * disassembler/udis86/udis86_extern.h:
2064         * disassembler/udis86/udis86_input.c: Removed.
2065         * disassembler/udis86/udis86_input.h: Removed.
2066         * disassembler/udis86/udis86_syn-att.c:
2067         * disassembler/udis86/udis86_syn.h:
2068         * disassembler/udis86/udis86_types.h:
2069         * disassembler/udis86/udis86_udint.h:
2070
2071 2016-03-30  Benjamin Poulain  <bpoulain@apple.com>
2072
2073         [JSC] Get rid of operationInitGlobalConst(), it is useless
2074         https://bugs.webkit.org/show_bug.cgi?id=156010
2075
2076         Reviewed by Geoffrey Garen.
2077
2078         * jit/JITOperations.cpp:
2079         * jit/JITOperations.h:
2080
2081 2016-03-29  Saam barati  <sbarati@apple.com>
2082
2083         Fix typos in our error messages and remove some trailing periods
2084         https://bugs.webkit.org/show_bug.cgi?id=155985
2085
2086         Reviewed by Mark Lam.
2087
2088         * bytecompiler/BytecodeGenerator.cpp:
2089         (JSC::BytecodeGenerator::BytecodeGenerator):
2090         * runtime/ArrayConstructor.h:
2091         (JSC::isArray):
2092         * runtime/ProxyConstructor.cpp:
2093         (JSC::makeRevocableProxy):
2094         (JSC::proxyRevocableConstructorThrowError):
2095         (JSC::ProxyConstructor::finishCreation):
2096         (JSC::constructProxyObject):
2097         * runtime/ProxyObject.cpp:
2098         (JSC::ProxyObject::finishCreation):
2099         (JSC::performProxyGet):
2100         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2101         (JSC::ProxyObject::performHasProperty):
2102         (JSC::ProxyObject::performPut):
2103         (JSC::performProxyCall):
2104         (JSC::performProxyConstruct):
2105         (JSC::ProxyObject::performDelete):
2106         (JSC::ProxyObject::performPreventExtensions):
2107         (JSC::ProxyObject::performIsExtensible):
2108         (JSC::ProxyObject::performDefineOwnProperty):
2109         (JSC::ProxyObject::performGetOwnPropertyNames):
2110         (JSC::ProxyObject::performSetPrototype):
2111         (JSC::ProxyObject::performGetPrototype):
2112         * runtime/StringPrototype.cpp:
2113         (JSC::stringProtoFuncStartsWith):
2114         (JSC::stringProtoFuncEndsWith):
2115         (JSC::stringProtoFuncIncludes):
2116         * runtime/Structure.cpp:
2117         (JSC::Structure::preventExtensionsTransition):
2118         * tests/stress/proxy-basic.js:
2119         * tests/stress/proxy-construct.js:
2120         (throw.new.Error):
2121         (assert):
2122         * tests/stress/proxy-define-own-property.js:
2123         (assert):
2124         (throw.new.Error):
2125         (i.catch):
2126         (assert.set get catch):
2127         * tests/stress/proxy-delete.js:
2128         (assert):
2129         * tests/stress/proxy-get-own-property.js:
2130         (assert):
2131         (i.catch):
2132         (set get let):
2133         * tests/stress/proxy-get-prototype-of.js:
2134         (assert):
2135         (assert.get let):
2136         (assert.get catch):
2137         * tests/stress/proxy-has-property.js:
2138         (assert):
2139         * tests/stress/proxy-is-array.js:
2140         (test):
2141         * tests/stress/proxy-is-extensible.js:
2142         (assert):
2143         * tests/stress/proxy-json.js:
2144         (assert):
2145         (test):
2146         * tests/stress/proxy-own-keys.js:
2147         (assert):
2148         (i.catch):
2149         * tests/stress/proxy-prevent-extensions.js:
2150         (assert):
2151         * tests/stress/proxy-property-descriptor.js:
2152         * tests/stress/proxy-revoke.js:
2153         (assert):
2154         (throw.new.Error.):
2155         (throw.new.Error):
2156         (shouldThrowNullHandler):
2157         * tests/stress/proxy-set-prototype-of.js:
2158         (assert.set let):
2159         (assert.set catch):
2160         (assert):
2161         (set catch):
2162         * tests/stress/proxy-set.js:
2163         (throw.new.Error.let.handler.set 45):
2164         (throw.new.Error):
2165         * tests/stress/proxy-with-private-symbols.js:
2166         (assert):
2167         * tests/stress/proxy-with-unbalanced-getter-setter.js:
2168         (assert):
2169         * tests/stress/reflect-set-proxy-set.js:
2170         (throw.new.Error.let.handler.set 45):
2171         (throw.new.Error):
2172         * tests/stress/reflect-set-receiver-proxy-set.js:
2173         (let.handler.set 45):
2174         (catch):
2175         * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js:
2176         (test):
2177         (test.get let):
2178
2179 2016-03-29  Keith Miller  <keith_miller@apple.com>
2180
2181         [ES6] Add support for Symbol.isConcatSpreadable.
2182         https://bugs.webkit.org/show_bug.cgi?id=155351
2183
2184         Reviewed by Saam Barati.
2185
2186         This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
2187         Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
2188         a builtin performant. First, four new DFG intrinsics were added.
2189
2190         1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
2191            the Array.isArray function.
2192         2) IsJSArray: checks the first child is a JSArray object.
2193         3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
2194         4) CallObjectConstructor: an intrinsic of the Object constructor.
2195
2196         IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
2197         we are able to prove that the first child is an Array or for ToObject an Object.
2198
2199         In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
2200         code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
2201         were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
2202         the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
2203         into a contiguous array).
2204
2205         This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
2206         values onto the result array. This works roughly the same as the two array fast path using the same methodology
2207         to decide if we can memcpy the other butterfly into the result butterfly.
2208
2209         Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
2210         name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
2211         dataLog function on it.
2212
2213         Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
2214         JSValueOperand if the operand's use count is one.
2215
2216         * JavaScriptCore.xcodeproj/project.pbxproj:
2217         * builtins/ArrayPrototype.js:
2218         (concatSlowPath):
2219         (concat):
2220         * bytecode/BytecodeIntrinsicRegistry.cpp:
2221         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2222         * bytecode/BytecodeIntrinsicRegistry.h:
2223         * dfg/DFGAbstractInterpreterInlines.h:
2224         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2225         * dfg/DFGByteCodeParser.cpp:
2226         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2227         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2228         * dfg/DFGClobberize.h:
2229         (JSC::DFG::clobberize):
2230         * dfg/DFGDoesGC.cpp:
2231         (JSC::DFG::doesGC):
2232         * dfg/DFGFixupPhase.cpp:
2233         (JSC::DFG::FixupPhase::fixupNode):
2234         * dfg/DFGNodeType.h:
2235         * dfg/DFGOperations.cpp:
2236         * dfg/DFGOperations.h:
2237         * dfg/DFGPredictionPropagationPhase.cpp:
2238         (JSC::DFG::PredictionPropagationPhase::propagate):
2239         * dfg/DFGSafeToExecute.h:
2240         (JSC::DFG::safeToExecute):
2241         * dfg/DFGSpeculativeJIT.cpp:
2242         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2243         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
2244         (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
2245         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
2246         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
2247         * dfg/DFGSpeculativeJIT.h:
2248         (JSC::DFG::SpeculativeJIT::callOperation):
2249         * dfg/DFGSpeculativeJIT32_64.cpp:
2250         (JSC::DFG::SpeculativeJIT::compile):
2251         * dfg/DFGSpeculativeJIT64.cpp:
2252         (JSC::DFG::SpeculativeJIT::compile):
2253         * ftl/FTLCapabilities.cpp:
2254         (JSC::FTL::canCompile):
2255         * ftl/FTLLowerDFGToB3.cpp:
2256         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2257         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
2258         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
2259         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
2260         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
2261         (JSC::FTL::DFG::LowerDFGToB3::isArray):
2262         * jit/JITOperations.h:
2263         * jsc.cpp:
2264         (WTF::RuntimeArray::createStructure):
2265         (GlobalObject::finishCreation):
2266         (functionDebug):
2267         (functionDataLogValue):
2268         * runtime/ArrayConstructor.cpp:
2269         (JSC::ArrayConstructor::finishCreation):
2270         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
2271         * runtime/ArrayConstructor.h:
2272         (JSC::isArrayConstructor):
2273         * runtime/ArrayPrototype.cpp:
2274         (JSC::ArrayPrototype::finishCreation):
2275         (JSC::arrayProtoPrivateFuncIsJSArray):
2276         (JSC::moveElements):
2277         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2278         (JSC::arrayProtoPrivateFuncAppendMemcpy):
2279         (JSC::arrayProtoFuncConcat): Deleted.
2280         * runtime/ArrayPrototype.h:
2281         (JSC::ArrayPrototype::createStructure):
2282         * runtime/CommonIdentifiers.h:
2283         * runtime/Intrinsic.h:
2284         * runtime/JSArray.cpp:
2285         (JSC::JSArray::appendMemcpy):
2286         (JSC::JSArray::fastConcatWith): Deleted.
2287         * runtime/JSArray.h:
2288         (JSC::JSArray::createStructure):
2289         (JSC::JSArray::fastConcatType): Deleted.
2290         * runtime/JSArrayInlines.h: Added.
2291         (JSC::JSArray::memCopyWithIndexingType):
2292         (JSC::JSArray::canFastCopy):
2293         * runtime/JSGlobalObject.cpp:
2294         (JSC::JSGlobalObject::init):
2295         * runtime/JSType.h:
2296         * runtime/ObjectConstructor.h:
2297         (JSC::constructObject):
2298         * tests/es6.yaml:
2299         * tests/stress/array-concat-spread-object.js: Added.
2300         (arrayEq):
2301         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
2302         (arrayEq):
2303         * tests/stress/array-concat-spread-proxy.js: Added.
2304         (arrayEq):
2305         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
2306         (arrayEq):
2307         * tests/stress/array-species-config-array-constructor.js:
2308
2309 2016-03-29  Saam barati  <sbarati@apple.com>
2310
2311         We don't properly optimize TDZ checks when we declare a let variable without an initializer
2312         https://bugs.webkit.org/show_bug.cgi?id=150453
2313
2314         Reviewed by Mark Lam.
2315
2316         * bytecompiler/NodesCodegen.cpp:
2317         (JSC::EmptyLetExpression::emitBytecode):
2318
2319 2016-03-29  Saam barati  <sbarati@apple.com>
2320
2321         Allow builtin JS functions to be intrinsics
2322         https://bugs.webkit.org/show_bug.cgi?id=155960
2323
2324         Reviewed by Mark Lam.
2325
2326         Builtin functions can now be recognized as intrinsics inside
2327         the DFG. This gives us the flexibility to either lower a builtin
2328         as an intrinsic in the DFG or as a normal function call.
2329         Because we may decide to not lower it as an intrinsic, the DFG
2330         inliner could still inline the function call.
2331
2332         You can annotate a builtin function like so to make
2333         it be recognized as an intrinsic.
2334         ```
2335         [intrinsic=FooIntrinsic] function foo() { ... }
2336         ```
2337         where FooIntrinsic is an enum value of the Intrinsic enum.
2338
2339         So in the future if we write RegExp.prototype.test as a builtin, we would do:
2340         ``` RegExpPrototype.js
2341         [intrinsic=RegExpTestIntrinsic] function test() { ... }
2342         ```
2343
2344         * Scripts/builtins/builtins_generate_combined_implementation.py:
2345         (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
2346         * Scripts/builtins/builtins_generate_separate_implementation.py:
2347         (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
2348         * Scripts/builtins/builtins_generator.py:
2349         (BuiltinsGenerator.generate_embedded_code_string_section_for_function):
2350         * Scripts/builtins/builtins_model.py:
2351         (BuiltinObject.__init__):
2352         (BuiltinFunction):
2353         (BuiltinFunction.__init__):
2354         (BuiltinFunction.fromString):
2355         (BuiltinFunction.__str__):
2356         * Scripts/builtins/builtins_templates.py:
2357         * bytecode/UnlinkedFunctionExecutable.cpp:
2358         (JSC::UnlinkedFunctionExecutable::visitChildren):
2359         (JSC::UnlinkedFunctionExecutable::link):
2360         * bytecode/UnlinkedFunctionExecutable.h:
2361         * dfg/DFGByteCodeParser.cpp:
2362         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2363         * runtime/Executable.cpp:
2364         (JSC::ExecutableBase::clearCode):
2365         (JSC::NativeExecutable::destroy):
2366         (JSC::ScriptExecutable::ScriptExecutable):
2367         (JSC::EvalExecutable::create):
2368         (JSC::EvalExecutable::EvalExecutable):
2369         (JSC::ProgramExecutable::ProgramExecutable):
2370         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
2371         (JSC::FunctionExecutable::FunctionExecutable):
2372         (JSC::ExecutableBase::intrinsic): Deleted.
2373         (JSC::NativeExecutable::intrinsic): Deleted.
2374         * runtime/Executable.h:
2375         (JSC::ExecutableBase::ExecutableBase):
2376         (JSC::ExecutableBase::hasJITCodeFor):
2377         (JSC::ExecutableBase::intrinsic):
2378         (JSC::ExecutableBase::intrinsicFor):
2379         (JSC::ScriptExecutable::finishCreation):
2380         * runtime/Intrinsic.h:
2381
2382 2016-03-29  Joseph Pecoraro  <pecoraro@apple.com>
2383
2384         JSC::Debugger cleanup after recent changes
2385         https://bugs.webkit.org/show_bug.cgi?id=155982
2386
2387         Reviewed by Mark Lam.
2388
2389         * debugger/Debugger.cpp:
2390         (JSC::Debugger::Debugger):
2391         Initialize with breakpoints disabled. Web Inspector always informs
2392         the backend if it should enable or disable breakpoints on startup.
2393
2394         (JSC::Debugger::setProfilingClient):
2395         When using the Sampling profiler we do not need to recompile.
2396
2397 2016-03-29  Saam barati  <sbarati@apple.com>
2398
2399         "Can not" => "cannot" in String.prototype error messages
2400         https://bugs.webkit.org/show_bug.cgi?id=155895
2401
2402         Reviewed by Mark Lam.
2403
2404         * runtime/StringPrototype.cpp:
2405         (JSC::stringProtoFuncStartsWith):
2406         (JSC::stringProtoFuncEndsWith):
2407         (JSC::stringProtoFuncIncludes):
2408         * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js:
2409         (test):
2410         (test.get let):
2411
2412 2016-03-29  Joseph Pecoraro  <pecoraro@apple.com>
2413
2414         Web Inspector: We should have a way to capture heap snapshots programatically.
2415         https://bugs.webkit.org/show_bug.cgi?id=154407
2416         <rdar://problem/24726292>
2417
2418         Reviewed by Timothy Hatcher.
2419
2420         * inspector/protocol/Console.json:
2421         Add a new Console.heapSnapshot event for when a heap snapshot is taken.
2422
2423         * runtime/ConsolePrototype.cpp:
2424         (JSC::ConsolePrototype::finishCreation):
2425         (JSC::consoleProtoFuncProfile):
2426         (JSC::consoleProtoFuncProfileEnd):
2427         (JSC::consoleProtoFuncTakeHeapSnapshot):
2428         * runtime/ConsoleClient.h:
2429         Add the console.takeHeapSnapshot method and dispatch to the ConsoleClient.
2430
2431         * inspector/JSGlobalObjectConsoleClient.cpp:
2432         (Inspector::JSGlobalObjectConsoleClient::takeHeapSnapshot):
2433         * inspector/JSGlobalObjectConsoleClient.h:
2434         Have the InspectorConsoleAgent handle this.
2435
2436         * inspector/JSGlobalObjectInspectorController.cpp:
2437         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2438         * inspector/agents/InspectorConsoleAgent.cpp:
2439         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
2440         (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
2441         * inspector/agents/InspectorConsoleAgent.h:
2442         * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
2443         (Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent):
2444         * inspector/agents/JSGlobalObjectConsoleAgent.h:
2445         Give the ConsoleAgent a HeapAgent pointer so that it can have the HeapAgent
2446         perform the snapshot building work like it normally does.
2447
2448 2016-03-29  Yusuke Suzuki  <utatane.tea@gmail.com>
2449
2450         REGRESSION(r192914): 10% regression on Sunspider's date-format-tofte
2451         https://bugs.webkit.org/show_bug.cgi?id=155559
2452
2453         Reviewed by Saam Barati.
2454
2455         The fast path of the eval function is the super hot path in date-format-tofte.
2456         Any performance regression is not allowed here.
2457         Before this patch, we allocated SourceCode in the fast path.
2458         This allocation incurs 10% performance regression.
2459
2460         This patch removes this allocation in the fast path.
2461         And change the key of the EvalCodeCache to EvalCodeCache::CacheKey.
2462         It combines RefPtr<StringImpl> and isArrowFunctionContext.
2463         Since EvalCodeCache does not cache any eval code evaluated under the strict mode,
2464         it is unnecessary to include several options (ThisTDZMode, and DerivedContextType) in the cache map's key.
2465         But isArrowFunctionContext is necessary since the sloppy mode arrow function exists.
2466
2467         To validate this change, we add a new test that evaluates the same code
2468         under the non-arrow function context and the arrow function context.
2469
2470         After introducing CacheKey, we observed 1% regression compared to the RefPtr<StringImpl> keyed case.
2471         This is because HashMap<RefPtr<T>, ...>::get(T*) is specially optimized; this path is inlined while the normal ::get() is not inlined.
2472         To avoid this performance regression, we introduce HashMap::fastGet, that aggressively encourages inlining.
2473         The relationship between fastGet() and get() is similar to fastAdd() and add().
2474         After applying this change, the evaluation shows no performance regression in comparison with the RefPtr<StringImpl> keyed case.
2475
2476         * bytecode/EvalCodeCache.h:
2477         (JSC::EvalCodeCache::CacheKey::CacheKey):
2478         (JSC::EvalCodeCache::CacheKey::hash):
2479         (JSC::EvalCodeCache::CacheKey::isEmptyValue):
2480         (JSC::EvalCodeCache::CacheKey::operator==):
2481         (JSC::EvalCodeCache::CacheKey::isHashTableDeletedValue):
2482         (JSC::EvalCodeCache::CacheKey::Hash::hash):
2483         (JSC::EvalCodeCache::CacheKey::Hash::equal):
2484         (JSC::EvalCodeCache::tryGet):
2485         (JSC::EvalCodeCache::getSlow):
2486         (JSC::EvalCodeCache::isCacheable):
2487         * interpreter/Interpreter.cpp:
2488         (JSC::eval):
2489         * tests/stress/eval-in-arrow-function.js: Added.
2490         (shouldBe):
2491         (i):
2492
2493 2016-03-29  Joseph Pecoraro  <pecoraro@apple.com>
2494
2495         Audit WebCore builtins for user overridable code
2496         https://bugs.webkit.org/show_bug.cgi?id=155923
2497
2498         Reviewed by Youenn Fablet.
2499
2500         * runtime/CommonIdentifiers.h:
2501         * runtime/ObjectConstructor.cpp:
2502         (JSC::ObjectConstructor::finishCreation):
2503         Expose @Object.@defineProperty to built-ins.
2504
2505 2016-03-28  Benjamin Poulain  <bpoulain@apple.com>
2506
2507         [JSC] ArithSub should not propagate "UsesAsOther"
2508         https://bugs.webkit.org/show_bug.cgi?id=155932
2509
2510         Reviewed by Mark Lam.
2511
2512         The node ArithSub was backpropagating UsesAsOther.
2513         This causes any GetByVal on a Double Array to have an extra
2514         hole check if it flows into an ArithSub.
2515
2516         The definition of ArithSub (12.8.4.1) has both operands go
2517         through ToNumber(). ToNumber() on "undefined" always produces
2518         NaN. It is safe to ignore the NaN marker from hole when
2519         the DAG flows into ArithSub.
2520
2521         This patch also adds this change and test coverage to ArithAdd.
2522         ArithAdd was not a problem in practice because it is only
2523         generated before Fixup if both operands are known to be numerical.
2524         The change to ArithAdd is there to protect us of the ArithSub-like
2525         problems if we ever improve our support of arithmetic operators.
2526
2527         * dfg/DFGBackwardsPropagationPhase.cpp:
2528         (JSC::DFG::BackwardsPropagationPhase::propagate):
2529         * tests/stress/arith-add-on-double-array-with-holes.js: Added.
2530         (let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
2531         (let.testCase.of.testCases.observableHoleOnLhs):
2532         (let.testCase.of.testCases.nonObservableHoleOnRhs):
2533         (let.testCase.of.testCases.observableHoleOnRhs):
2534         * tests/stress/arith-sub-on-double-array-with-holes.js: Added.
2535         (let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
2536         (let.testCase.of.testCases.observableHoleOnLhs):
2537         (let.testCase.of.testCases.nonObservableHoleOnRhs):
2538         (let.testCase.of.testCases.observableHoleOnRhs):
2539         * tests/stress/value-add-on-double-array-with-holes.js: Added.
2540         (let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
2541         (let.testCase.of.testCases.observableHoleOnLhs):
2542         (let.testCase.of.testCases.nonObservableHoleOnRhs):
2543         (let.testCase.of.testCases.observableHoleOnRhs):
2544
2545 2016-03-28  Brian Burg  <bburg@apple.com>
2546
2547         Web Inspector: protocol generator should generate C++ string-to-enum helper functions
2548         https://bugs.webkit.org/show_bug.cgi?id=155691
2549         <rdar://problem/25258078>
2550
2551         Reviewed by Timothy Hatcher.
2552
2553         There's a lot of code throughout the Inspector agents and automation code
2554         that needs to convert a raw string into a typed protocol enum. Generate
2555         some helpers that do this conversion so clients can move over to using it.
2556
2557         These helpers are necessary for when we eventually switch to calling backend
2558         dispatcher handlers with typed arguments instead of untyped JSON objects.
2559
2560         To correctly generate a conversion function for an anonymous enum, the
2561         generator needs to be able to get the containing object type's declaration.
2562         Since the model's Type object each have only one instance, there is a
2563         one-to-one association between type and its declaration.
2564
2565         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
2566         (CppProtocolTypesHeaderGenerator.generate_output):
2567         (CppProtocolTypesHeaderGenerator._generate_forward_declarations):
2568         Clean up this method to use methodcaller to sort types by raw name.
2569
2570         (_generate_declarations_for_enum_conversion_methods):
2571         (_generate_declarations_for_enum_conversion_methods.return_type_with_export_macro):
2572         (_generate_declarations_for_enum_conversion_methods.type_member_is_anonymous_enum_type):
2573         Added. Generates a new section with an unfilled template and specializations of
2574         the template for every named and anonymous enum in every domain. Guards for
2575         domains wrap the forward declarations. This is added to the end of the header
2576         file so that specializations for both types of enums are in the same place.
2577
2578         * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
2579         (CppProtocolTypesImplementationGenerator.generate_output):
2580         (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
2581         (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.type_member_is_anonymous_enum_type):
2582         (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body):
2583         Added. Generate a static array of offsets into the enum constant value array.
2584         Then, loop over this array of offsets and do string comparisons against the
2585         provided string and enum constant values at the relevant offsets for this enum.
2586
2587         * inspector/scripts/codegen/generator_templates.py:
2588         (GeneratorTemplates): Update copyright year in generated files.
2589
2590         * inspector/scripts/codegen/models.py:
2591         (AliasedType.__init__):
2592         (EnumType.__init__):
2593         (EnumType.enum_values):
2594         (EnumType.declaration):
2595         (ArrayType.__init__):
2596         (ArrayType.declaration):
2597         (ObjectType.__init__):
2598         (ObjectType.declaration):
2599         (Protocol.resolve_types):
2600         (Protocol.lookup_type_reference):
2601         Pass the type declaration to Type constructors if available. If not,
2602         fill in a placeholder name for the type in the constructor instead of caller.
2603
2604         Rebaseline all the things, mostly for copyright block changes.
2605
2606         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2607         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2608         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2609         * inspector/scripts/tests/expected/enum-values.json-result:
2610         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2611         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2612         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2613         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2614         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2615         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2616         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2617         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2618         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2619
2620 2016-03-25  Joseph Pecoraro  <pecoraro@apple.com>
2621
2622         Misc. JavaScriptCore built-ins cleanups
2623         https://bugs.webkit.org/show_bug.cgi?id=155920
2624
2625         Reviewed by Mark Lam.
2626
2627         * builtins/RegExpPrototype.js:
2628         (match):
2629         No need for an else after an if that always returns.
2630
2631         * builtins/TypedArrayConstructor.js:
2632         (of):
2633         Fix error message to use the correct function name.
2634
2635         (allocateInt8Array):
2636         (allocateInt16Array):
2637         (allocateInt32Array):
2638         (allocateUint32Array):
2639         (allocateUint16Array):
2640         (allocateUint8Array):
2641         (allocateUint8ClampedArray):
2642         (allocateFloat32Array):
2643         (allocateFloat64Array):
2644         Cleanup style to be like all the other code.
2645
2646         * tests/stress/typedarray-of.js:
2647         Test the exception message.
2648
2649 2016-03-25  Joseph Pecoraro  <pecoraro@apple.com>
2650
2651         Date.prototype.toLocaleDateString uses overridable Object.create
2652         https://bugs.webkit.org/show_bug.cgi?id=155917
2653
2654         Reviewed by Mark Lam.
2655
2656         * builtins/DatePrototype.js:
2657         (toLocaleString.toDateTimeOptionsAnyAll):
2658         (toLocaleDateString.toDateTimeOptionsDateDate):
2659         (toLocaleTimeString.toDateTimeOptionsTimeTime):
2660         Switch from @Object.create to @Object.@create to guarentee we are
2661         using the built-in create method and not user defined code.
2662
2663         * runtime/CommonIdentifiers.h:
2664         * runtime/ObjectConstructor.cpp:
2665         (JSC::ObjectConstructor::finishCreation):
2666         Setup the @create private symbol.
2667
2668 2016-03-25  Benjamin Poulain  <bpoulain@apple.com>
2669
2670         [JSC] Put the x86 Assembler on a binary diet
2671         https://bugs.webkit.org/show_bug.cgi?id=155683
2672
2673         Reviewed by Darin Adler.
2674
2675         The MacroAssemblers are heavily inlined. This is unfortunately
2676         important for baseline JIT where many branches can be eliminated
2677         at compile time.
2678
2679         This inlining causes a lot of binary bloat. The phases
2680         lowering to ASM are massively large.
2681
2682         This patch improves the situation a bit for x86 through
2683         many small improvements:
2684
2685         -Every instruction starts with ensureSpace(). The slow
2686          path realloc the buffer.
2687          From that slow path, only fastRealloc() was a function
2688          call. What is around does not need to be fast, I moved
2689          the whole grow() function out of line for those cases.
2690
2691         -When testing multiple registers for REX requirements,
2692          we had something like this:
2693              byteRegRequiresRex(reg) || byteRegRequiresRex(rm)
2694              regRequiresRex(index) || regRequiresRex(base)
2695          Those were producing multiple test-and-branch. Those branches
2696          are effectively random so we don't have to care about individual
2697          branches being predictable.
2698
2699          The new code effectively does:
2700              byteRegRequiresRex(reg | rm)
2701              regRequiresRex(index | base)
2702
2703         -Change "ModRmMode" to have the value we can OR directly
2704          to the generated ModRm.
2705          This is important because some ModRM code is so large
2706          that is goes out of line;
2707
2708         -Finally, a big change on how we write to the AssemblerBuffer.
2709
2710          Previously, instructions were written byte by byte into
2711          the assembler buffer of the MacroAssembler.
2712
2713          The problem with that is the compiler cannot prove that
2714          the buffer pointer and the AssemblerBuffer are not pointing
2715          to the same memory.
2716
2717          Because of that, before any write, all the local register
2718          were pushed back to the AssemblerBuffer memory, then everything
2719          was read back after the write to compute the next write.
2720
2721          I attempted to use the "restrict" keyword and wrapper types
2722          to help Clang with that but nothing worked.
2723
2724          The current solution is to keep a local copy of the index
2725          and the buffer pointer in the scope of each instruction.
2726          That is done by AssemblerBuffer::LocalWriter.
2727
2728          Since LocalWriter only exists locally, it stays in
2729          register and we don't have all the memory churn between
2730          each byte writing. This also allows clang to combine
2731          obvious cases since there are no longer observable side
2732          effects between bytes.
2733
2734         This patch reduces the binary size by 66k. It is a small
2735         speed-up on Sunspider.
2736
2737         * assembler/AssemblerBuffer.h:
2738         (JSC::AssemblerBuffer::ensureSpace):
2739         (JSC::AssemblerBuffer::LocalWriter::LocalWriter):
2740         (JSC::AssemblerBuffer::LocalWriter::~LocalWriter):
2741         (JSC::AssemblerBuffer::LocalWriter::putByteUnchecked):
2742         (JSC::AssemblerBuffer::LocalWriter::putShortUnchecked):
2743         (JSC::AssemblerBuffer::LocalWriter::putIntUnchecked):
2744         (JSC::AssemblerBuffer::LocalWriter::putInt64Unchecked):
2745         (JSC::AssemblerBuffer::LocalWriter::putIntegralUnchecked):
2746         (JSC::AssemblerBuffer::putIntegral):
2747         (JSC::AssemblerBuffer::outOfLineGrow):
2748         * assembler/MacroAssemblerX86Common.h:
2749         * assembler/X86Assembler.h:
2750         (JSC::X86Assembler::X86InstructionFormatter::byteRegRequiresRex):
2751         (JSC::X86Assembler::X86InstructionFormatter::regRequiresRex):
2752         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::LocalBufferWriter):
2753         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRex):
2754         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexW):
2755         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIf):
2756         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIfNeeded):
2757         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRm):
2758         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRmSib):
2759         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::registerModRM):
2760         (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::memoryModRM):
2761         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp): Deleted.
2762         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp32): Deleted.
2763         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp8): Deleted.
2764         (JSC::X86Assembler::X86InstructionFormatter::twoByteOp): Deleted.
2765         (JSC::X86Assembler::X86InstructionFormatter::threeByteOp): Deleted.
2766         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64): Deleted.
2767         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp32): Deleted.
2768         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp8): Deleted.
2769         (JSC::X86Assembler::X86InstructionFormatter::twoByteOp64): Deleted.
2770         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): Deleted.
2771         (JSC::X86Assembler::X86InstructionFormatter::twoByteOp8): Deleted.
2772         (JSC::X86Assembler::X86InstructionFormatter::emitRex): Deleted.
2773         (JSC::X86Assembler::X86InstructionFormatter::emitRexW): Deleted.
2774         (JSC::X86Assembler::X86InstructionFormatter::emitRexIf): Deleted.
2775         (JSC::X86Assembler::X86InstructionFormatter::emitRexIfNeeded): Deleted.
2776         (JSC::X86Assembler::X86InstructionFormatter::putModRm): Deleted.
2777         (JSC::X86Assembler::X86InstructionFormatter::putModRmSib): Deleted.
2778         (JSC::X86Assembler::X86InstructionFormatter::registerModRM): Deleted.
2779         (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): Deleted.
2780
2781 2016-03-25  Saam barati  <sbarati@apple.com>
2782
2783         RegExp.prototype.test should be an intrinsic again
2784         https://bugs.webkit.org/show_bug.cgi?id=155861
2785
2786         Reviewed by Yusuke Suzuki.
2787
2788         * runtime/RegExpPrototype.cpp:
2789         (JSC::RegExpPrototype::finishCreation):
2790
2791 2016-03-25  Mark Lam  <mark.lam@apple.com>
2792
2793         ES6's throwing of TypeErrors on access of RegExp.prototype flag properties breaks websites.
2794         https://bugs.webkit.org/show_bug.cgi?id=155904
2795
2796         Reviewed by Geoffrey Garen.
2797
2798         There exists a JS library XRegExp (see http://xregexp.com) that extends the regexp
2799         implementation.  XRegExp does feature testing by comparing RegExp.prototype.sticky
2800         to undefined.  See:
2801
2802         Example 1. https://github.com/slevithan/xregexp/blob/28a2b033c5951477bed8c7c867ddf7e89c431cd4/tests/perf/index.html
2803             ...
2804             } else if (knownVersion[version]) {
2805                 // Hack around ES6 incompatibility in XRegExp versions prior to 3.0.0
2806                 if (parseInt(version, 10) < 3) {
2807                     delete RegExp.prototype.sticky;
2808             }
2809             ...
2810
2811         Example 2. https://github.com/slevithan/xregexp/blob/d0e665d4068cec4d15919215b098b2373f1f12e9/tests/perf/versions/xregexp-all-v2.0.0.js
2812             ...
2813             // Check for flag y support (Firefox 3+)
2814                 hasNativeY = RegExp.prototype.sticky !== undef,
2815             ...
2816
2817         The ES6 spec states that we should throw a TypeError here because RegExp.prototype
2818         is not a RegExp object, and the sticky getter is only allowed to be called on
2819         RegExp objects.  See https://tc39.github.io/ecma262/2016/#sec-get-regexp.prototype.sticky.
2820         As a result, websites that uses XRegExp can break (e.g. some Atlassian tools).
2821
2822         As a workaround, we'll return undefined instead of throwing on access of these
2823         flag properties that may be used for feature testing.
2824
2825         * runtime/RegExpPrototype.cpp:
2826         (JSC::regExpProtoGetterGlobal):
2827         (JSC::regExpProtoGetterIgnoreCase):
2828         (JSC::regExpProtoGetterMultiline):
2829         (JSC::regExpProtoGetterSticky):
2830         (JSC::regExpProtoGetterUnicode):
2831
2832 2016-03-25  Caitlin Potter  <caitp@igalia.com>
2833
2834         [JSC] fix divide-by-zero in String.prototype.padStart/padEnd
2835         https://bugs.webkit.org/show_bug.cgi?id=155903
2836
2837         Reviewed by Filip Pizlo.
2838
2839         * runtime/StringPrototype.cpp:
2840         (JSC::padString):
2841
2842 2016-03-25  Benjamin Poulain  <benjamin@webkit.org>
2843
2844         [JSC] materialize-past-butterfly-allocation.js time out in debug
2845
2846         * tests/stress/materialize-past-butterfly-allocation.js:
2847         The test times out on the debug bots. We suspect there is nothing
2848         wrong, just overkill loops.
2849
2850 2016-03-25  Brian Burg  <bburg@apple.com>
2851
2852         Web Inspector: protocol generator should prefix C++ filenames with the protocol group
2853         https://bugs.webkit.org/show_bug.cgi?id=155859
2854         <rdar://problem/25349859>
2855
2856         Reviewed by Alex Christensen and Joseph Pecoraro.
2857
2858         Like for generated Objective-C files, we should use the 'protocol group' name
2859         as the prefix for generated C++ files so that headers from different protocol
2860         groups have unambiguous names.
2861
2862         * inspector/scripts/codegen/cpp_generator.py:
2863         (CppGenerator):
2864         (CppGenerator.__init__):
2865         (CppGenerator.protocol_name):
2866         Make all C++ code generators extend the CppGenerator python class and use the
2867         protocol_name() instance method. This matches a recent change to the ObjC generator.
2868
2869         * inspector/scripts/codegen/cpp_generator_templates.py:
2870         (CppGeneratorTemplates):
2871         Drive-by cleanup to use #pragma once instead of header guards.
2872
2873         * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
2874         (CppAlternateBackendDispatcherHeaderGenerator):
2875         (CppAlternateBackendDispatcherHeaderGenerator.__init__):
2876         (CppAlternateBackendDispatcherHeaderGenerator.output_filename):
2877         (CppAlternateBackendDispatcherHeaderGenerator.generate_output):
2878         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
2879         (CppBackendDispatcherHeaderGenerator):
2880         (CppBackendDispatcherHeaderGenerator.__init__):
2881         (CppBackendDispatcherHeaderGenerator.output_filename):
2882         (CppBackendDispatcherHeaderGenerator.generate_output):
2883         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
2884         (CppBackendDispatcherImplementationGenerator):
2885         (CppBackendDispatcherImplementationGenerator.__init__):
2886         (CppBackendDispatcherImplementationGenerator.output_filename):
2887         (CppBackendDispatcherImplementationGenerator.generate_output):
2888         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
2889         (CppFrontendDispatcherHeaderGenerator):
2890         (CppFrontendDispatcherHeaderGenerator.__init__):
2891         (CppFrontendDispatcherHeaderGenerator.output_filename):
2892         (CppFrontendDispatcherHeaderGenerator.generate_output):
2893         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
2894         (CppFrontendDispatcherImplementationGenerator):
2895         (CppFrontendDispatcherImplementationGenerator.__init__):
2896         (CppFrontendDispatcherImplementationGenerator.output_filename):
2897         (CppFrontendDispatcherImplementationGenerator.generate_output):
2898         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
2899         (CppProtocolTypesHeaderGenerator):
2900         (CppProtocolTypesHeaderGenerator.__init__):
2901         (CppProtocolTypesHeaderGenerator.output_filename):
2902         (CppProtocolTypesHeaderGenerator.generate_output):
2903         * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
2904         (CppProtocolTypesImplementationGenerator):
2905         (CppProtocolTypesImplementationGenerator.__init__):
2906         (CppProtocolTypesImplementationGenerator.output_filename):
2907         (CppProtocolTypesImplementationGenerator.generate_output):
2908         Use the protocol_name() instance method to compute generated protocol file names.
2909
2910         * inspector/scripts/codegen/models.py:
2911         Explicitly set the 'protocol_group' for the Inspector protocol.
2912
2913         Rebaseline generator test results.
2914
2915         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2916         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2917         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2918         * inspector/scripts/tests/expected/enum-values.json-result:
2919         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2920         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2921         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2922         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2923         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2924         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2925         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2926         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2927         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2928
2929 2016-03-25  Keith Miller  <keith_miller@apple.com>
2930
2931         putByIndexBeyondVectorLengthWithoutAttributes should not crash if it can't ensureLength
2932         https://bugs.webkit.org/show_bug.cgi?id=155730
2933
2934         Reviewed by Saam Barati.
2935
2936         This patch makes ensureLength return a boolean indicating if it was able to set the length.
2937         ensureLength also no longer sets the butterfly to null if the allocation of the butterfly
2938         fails. All of ensureLengths callers including putByIndexBeyondVectorLengthWithoutAttributes
2939         have been adapted to throw an out of memory error if ensureLength fails.
2940
2941         * runtime/JSArray.cpp:
2942         (JSC::JSArray::setLength):
2943         (JSC::JSArray::unshiftCountWithAnyIndexingType):
2944         * runtime/JSObject.cpp:
2945         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
2946         (JSC::JSObject::ensureLengthSlow):
2947         * runtime/JSObject.h:
2948         (JSC::JSObject::ensureLength):
2949
2950 2016-03-25  Caitlin Potter  <caitp@igalia.com>
2951
2952         [JSC] implement String.prototype.padStart() and String.prototype.padEnd() proposal
2953         https://bugs.webkit.org/show_bug.cgi?id=155795
2954
2955         Reviewed by Darin Adler.
2956
2957         Implements ECMAScript proposal http://tc39.github.io/proposal-string-pad-start-end/
2958         Currently at Stage 3.
2959
2960         * runtime/JSString.h:
2961         * runtime/StringPrototype.cpp:
2962         (JSC::StringPrototype::finishCreation):
2963         (JSC::repeatCharacter):
2964         (JSC::repeatStringPattern):
2965         (JSC::padString):
2966         (JSC::stringProtoFuncPadEnd):
2967         (JSC::stringProtoFuncPadStart):
2968         * tests/es6.yaml:
2969         * tests/es6/String.prototype_methods_String.prototype.padEnd.js: Added.
2970         * tests/es6/String.prototype_methods_String.prototype.padStart.js: Added.
2971
2972 2016-03-24  Alex Christensen  <achristensen@webkit.org>
2973
2974         Fix Mac CMake build.
2975
2976         * PlatformMac.cmake:
2977         Link to Security framework.
2978
2979 2016-03-24  Saam barati  <sbarati@apple.com>
2980
2981         ES6: Implement IsRegExp function and use where needed in String.prototype.* methods
2982         https://bugs.webkit.org/show_bug.cgi?id=155854
2983
2984         Reviewed by Mark Lam.
2985
2986         This patch is a straight forward implementation of IsRegExp
2987         in the ES6 spec:
2988         https://tc39.github.io/ecma262/#sec-isregexp
2989         We now use this IsRegExp function inside String.prototype.(startsWith | endsWith | includes)
2990         as is dictated by the spec.
2991
2992         * runtime/RegExpConstructor.h:
2993         (JSC::RegExpConstructor::recordMatch):
2994         (JSC::isRegExp):
2995         * runtime/StringPrototype.cpp:
2996         (JSC::stringProtoFuncStartsWith):
2997         (JSC::stringProtoFuncEndsWith):
2998         (JSC::stringProtoFuncIncludes):
2999         * tests/es6.yaml:
3000         * tests/es6/well-known_symbols_Symbol.match_String.prototype.endsWith.js: Added.
3001         (test):
3002         * tests/es6/well-known_symbols_Symbol.match_String.prototype.includes.js: Added.
3003         (test):
3004         * tests/es6/well-known_symbols_Symbol.match_String.prototype.startsWith.js: Added.
3005         (test):
3006         * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js: Added.
3007         (assert):
3008         (test):
3009         (test.get let):
3010         (get let):
3011
3012 2016-03-24  Saam barati  <sbarati@apple.com>
3013
3014         Web Inspector: Separate Debugger enable state from the debugger breakpoints enabled state
3015         https://bugs.webkit.org/show_bug.cgi?id=152193
3016         <rdar://problem/23867520>
3017
3018         Reviewed by Joseph Pecoraro.
3019
3020         When all breakpoints are disabled, we can recompile all JS
3021         code and remove the necessary debugging code that is emitted.
3022         This allows for the code that is executing to be almost as fast
3023         as it is with the debugger completely disabled. This is in preparation for:
3024         https://bugs.webkit.org/show_bug.cgi?id=155809
3025         which will introduce a high fidelity profiler. That profiler
3026         could be built off the principle that breakpoints are disabled
3027         when we're performing a high fidelity profile. Doing so, for example,
3028         allows the sampling profiler to better measure the real performance
3029         of the JS of a particular application.
3030
3031         * debugger/Debugger.cpp:
3032         (JSC::Debugger::setBreakpointsActivated):
3033         (JSC::Debugger::setPauseOnExceptionsState):
3034         * debugger/Debugger.h:
3035         * dfg/DFGGraph.cpp:
3036         (JSC::DFG::Graph::Graph):
3037         * inspector/JSGlobalObjectScriptDebugServer.cpp:
3038         (Inspector::JSGlobalObjectScriptDebugServer::attachDebugger):
3039         (Inspector::JSGlobalObjectScriptDebugServer::detachDebugger):
3040         * inspector/agents/InspectorDebuggerAgent.cpp:
3041         (Inspector::InspectorDebuggerAgent::enable):
3042         * runtime/Executable.cpp:
3043         (JSC::ScriptExecutable::newCodeBlockFor):
3044         * runtime/JSGlobalObject.cpp:
3045         (JSC::JSGlobalObject::createProgramCodeBlock):
3046         (JSC::JSGlobalObject::createEvalCodeBlock):
3047         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
3048         (JSC::JSGlobalObject::queueMicrotask):
3049         (JSC::JSGlobalObject::hasDebugger):
3050         (JSC::JSGlobalObject::hasInteractiveDebugger):
3051         * runtime/JSGlobalObject.h:
3052         (JSC::JSGlobalObject::runtimeFlags):
3053         (JSC::JSGlobalObject::hasDebugger): Deleted.
3054
3055 2016-03-24  Michael Saboff  <msaboff@apple.com>
3056
3057         Create private builtin helper advanceStringIndexUnicode() for use by RegExp builtins
3058         https://bugs.webkit.org/show_bug.cgi?id=155855
3059
3060         Reviewed by Mark Lam.
3061
3062         Moved advanceStringIndexUnicode() as a separate helper.  Added it as a private builtin
3063         to the GlobalObject like other private builtins.
3064
3065         * builtins/RegExpPrototype.js:
3066         (advanceStringIndexUnicode):
3067         (match):
3068         (match.advanceStringIndexUnicode): Deleted.
3069         * runtime/JSGlobalObject.cpp:
3070         (JSC::JSGlobalObject::init):
3071
3072 2016-03-24  Michael Saboff  <msaboff@apple.com>
3073
3074         [ES6] Add Proxy based tests for RegExp.prototype[@@match]
3075         https://bugs.webkit.org/show_bug.cgi?id=155807
3076
3077         Reviewed by Saam Barati.
3078
3079         Added new test that uses Proxy to verify RegExp.prototype[@@match] processing
3080         conforms to the ES6 standard
3081
3082         Modified builtin RegExp.prototype[@@match] to be ES6 spec conformant.
3083
3084         Updated es6.yaml as Proxy_internal_get_calls_RegExp.prototype[Symbol.match].js now passes.
3085
3086         * builtins/RegExpPrototype.js:
3087         (match):
3088         * tests/es6.yaml: Updated.
3089         * tests/stress/regexp-match-proxy.js: Added.
3090         (assert):
3091         (let.getProxyNullExec.new.Proxy):
3092         (let.getSetProxyNullExec.new.Proxy):
3093         (get resetTracking):
3094         (let.getSetProxyMatches_s.new.Proxy):
3095         (set get getSetProxyNullExec):
3096         (let.getSetProxyMatches_tx_Greedy.new.Proxy):
3097         (set get getSetProxyMatches_s):
3098         (let.getSetProxyMatchesUnicode_digit_nonGreedy.new.Proxy):
3099         (set get getSetProxyMatches_tx_Greedy):
3100
3101 2016-03-24  Michael Saboff  <msaboff@apple.com>
3102
3103         [ES6] Greedy unicode RegExp's don't properly backtrack past non BMP characters
3104         https://bugs.webkit.org/show_bug.cgi?id=155829
3105
3106         Reviewed by Saam Barati.
3107
3108         When we backup when matching part of a unicode pattern, we can't just backup one character.
3109         Instead we need to save our start position before trying to match a character and
3110         restore the position if the match fails.  This was done in other places, but wasn't
3111         done for all greedy types.
3112
3113         Fixed matchGlobal() to properly handle advancing past non BMP characters.
3114
3115         * runtime/RegExpObject.cpp:
3116         (JSC::RegExpObject::matchGlobal):
3117         * runtime/RegExpObjectInlines.h:
3118         (JSC::RegExpObject::advanceStringUnicode):
3119         * yarr/YarrInterpreter.cpp:
3120         (JSC::Yarr::Interpreter::matchCharacterClass):
3121         (JSC::Yarr::Interpreter::matchDisjunction):
3122
3123 2016-03-24  Benjamin Poulain  <bpoulain@apple.com>
3124
3125         [JSC] In some cases, the integer range optimization phase never converges
3126         https://bugs.webkit.org/show_bug.cgi?id=155828
3127         rdar://problem/25155460
3128
3129         Reviewed by Filip Pizlo.
3130
3131         In certain conditions, the integer range optimization phase continuously
3132         changes the representation of the same truth, preventing it from
3133         converging to a stable state.
3134
3135         The bug starts by having the same ground truth incomming into a block
3136         in different valid forms. For example, you can have x < 42 coming as:
3137             1) x < 42
3138             2) x < 41 + 1
3139             3) x < 43 - 1
3140
3141         Having those 3 alone coming from predecessors would be okay, we would
3142         just accumulate them. The problem is when you have a combination
3143         of rule that filter out the previously obtained truth, then add a new
3144         form of the same truth.
3145
3146         Let's use the test case as an example. We have two incoming blocks:
3147             Block #1:
3148               -i < 42
3149               -i != 41
3150             Block #2:
3151               -i < 41
3152               -i == 42 - 42 (i == 0 refining the rule above).
3153
3154         Let say that our conditions at head are now [i < 41, i < 42 - 1].
3155
3156         If we merge block #2:
3157               -i < 42 and i < 41      -> i < 42
3158               -i < 42 and i < 42 - 1  -> i < 42
3159               -i != 41 and i < 41     -> i < 41
3160               -i != 41 and i < 42 - 1 -> nothing
3161
3162         The new head is: [i < 41, i < 42]
3163
3164         If we merge block #1:
3165               -i < 41 and i < 41       -> i < 41
3166               -i < 41 and i < 42       -> i < 42
3167               -i == 42 - 42 and i < 41 -> (i < 41 and i < 42 - 1)
3168               -i == 42 - 42 and i < 42 -> i < 42
3169
3170         After filter, we are back to [i < 41, i < 42 - 1].
3171
3172         There are several variations of this idea where the same truth
3173         rotate different forms with each merge().
3174
3175         One possible solution is to make filter() more aggressive
3176         to avoid the better form occuring at merge(). I'll probably
3177         do that at some point but that seems fragile since the same
3178         problem could reappear if merge() is later improved.
3179
3180         For this patch, I went with a more generic solution after
3181         merge(): if the generated form is equivalent to one that
3182         previously existed at head, pick the existing form.
3183
3184         In the previous example, what happens is we only have
3185         either [i < 41] or [i < 42 - 1] but never both simultaneously.
3186
3187         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
3188         * tests/stress/integer-range-optimization-constant-representation-1.js: Added.
3189         * tests/stress/integer-range-optimization-constant-representation-2.js: Added.
3190         Two variation. One timeout in release because of the additional flags.
3191         The other is gets more type of run but only assert in debug.
3192
3193 2016-03-23  Commit Queue  <commit-queue@webkit.org>
3194
3195         Unreviewed, rolling out r198582.
3196         https://bugs.webkit.org/show_bug.cgi?id=155812
3197
3198         "It broke debugging in the web inspector" (Requested by
3199         saamyjoon on #webkit).
3200
3201         Reverted changeset:
3202
3203         "We should not disable inlining when the debugger is enabled"
3204         https://bugs.webkit.org/show_bug.cgi?id=155741
3205         http://trac.webkit.org/changeset/198582
3206
3207 2016-03-23  Michael Saboff  <msaboff@apple.com>
3208
3209         JavaScriptCore ArrayPrototype::join shouldn't cache butterfly when it makes effectful calls
3210         https://bugs.webkit.org/show_bug.cgi?id=155776
3211
3212         Reviewed by Saam Barati.
3213
3214         Array.join ends up calling toString, possibly on some object.  Since these calls
3215         could be effectful and could change the array itself, we can't hold the butterfly
3216         pointer while making effectful calls.  Changed the code to fall back to the general
3217         case when an effectful toString() call might be made.
3218
3219         * runtime/ArrayPrototype.cpp:
3220         (JSC::join):
3221         * runtime/JSStringJoiner.h:
3222         (JSC::JSStringJoiner::appendWithoutSideEffects): New helper that doesn't make effectful
3223         toString() calls.
3224         (JSC::JSStringJoiner::append): Built upon appendWithoutSideEffects.
3225
3226 2016-03-23  Keith Miller  <keith_miller@apple.com>
3227
3228         Array.prototype native functions' species constructors should work with proxies
3229         https://bugs.webkit.org/show_bug.cgi?id=155798
3230
3231         Reviewed by Mark Lam.
3232
3233         Before native the species constructors were checking if the this value was a JSArray.
3234         Instead they should look check that the this value returns true on Array.isArray.
3235
3236         * runtime/ArrayPrototype.cpp:
3237         (JSC::speciesConstructArray):
3238         * tests/es6.yaml:
3239         * tests/stress/proxy-array-prototype-methods.js:
3240
3241 2016-03-23  Saam barati  <sbarati@apple.com>
3242
3243         We should not disable inlining when the debugger is enabled
3244         https://bugs.webkit.org/show_bug.cgi?id=155741
3245
3246         Reviewed by Oliver Hunt.
3247
3248         We can enable inlining when the debugger is enabled as long
3249         as we make sure we still jettison the proper CodeBlocks when
3250         a breakpoint is set. This means that for any optimized CodeBlock,
3251         we must ask if any of its inlinees contain the breakpoint that
3252         is being set. If any inlinees do contain the breakpoint, we must
3253         jettison the machine code block that they are a part of.
3254
3255         * debugger/Debugger.cpp:
3256         (JSC::Debugger::toggleBreakpoint):
3257         (JSC::Debugger::applyBreakpoints):
3258         * dfg/DFGByteCodeParser.cpp:
3259         (JSC::DFG::ByteCodeParser::ByteCodeParser):
3260         (JSC::DFG::ByteCodeParser::setLocal):
3261         (JSC::DFG::ByteCodeParser::flush):
3262         (JSC::DFG::ByteCodeParser::flushForTerminal):
3263         (JSC::DFG::ByteCodeParser::inliningCost):
3264         * dfg/DFGGraph.cpp:
3265         (JSC::DFG::Graph::Graph):
3266         (JSC::DFG::Graph::~Graph):
3267         * dfg/DFGGraph.h:
3268         (JSC::DFG::Graph::hasDebuggerEnabled): Deleted.
3269         * dfg/DFGStackLayoutPhase.cpp:
3270         (JSC::DFG::StackLayoutPhase::run):
3271         * ftl/FTLCompile.cpp:
3272         (JSC::FTL::compile):
3273
3274 2016-03-23  Yusuke Suzuki  <utatane.tea@gmail.com>
3275
3276         [ES6] Allow undefined/null for Symbol.search and Symbol.match
3277         https://bugs.webkit.org/show_bug.cgi?id=155785
3278
3279         Reviewed by Saam Barati.
3280
3281         Undefined and null for Symbol.search and Symbol.match properties of the given RegExp (like) object are allowed.
3282         When they are specified, we go to the fallback path; creating the RegExp with the given object and matching.
3283
3284         * builtins/StringPrototype.js:
3285         (match):
3286         (search):
3287         * tests/stress/string-symbol-customization.js: Added.
3288         (shouldBe):
3289         (shouldThrow):
3290
3291 2016-03-22  Caitlin Potter  <caitp@igalia.com>
3292
3293         [JSC] correctly handle indexed properties in Object.getOwnPropertyDescriptors
3294         https://bugs.webkit.org/show_bug.cgi?id=155563
3295
3296         Reviewed by Saam Barati.
3297
3298         * runtime/JSObject.h:
3299         (JSC::JSObject::putOwnDataPropertyMayBeIndex):
3300         * runtime/ObjectConstructor.cpp:
3301         (JSC::objectConstructorGetOwnPropertyDescriptors):
3302
3303 2016-03-22  Saam Barati  <sbarati@apple.com>
3304
3305         We should FTL compile code when the debugger is enabled
3306         https://bugs.webkit.org/show_bug.cgi?id=155740
3307
3308         Reviewed by Oliver Hunt.
3309
3310         There was no fundamental reason why we didn't support debugging
3311         with the FTL. It looks like this was just an oversight. We had
3312         a Breakpoint node in the DFG that amounted to a nop. By removing
3313         this node, we now support debugging in the FTL. Anytime a breakpoint
3314         is set, we will jettison any DFG/FTL CodeBlocks that contain the breakpoint
3315         that was set.
3316
3317         * dfg/DFGAbstractInterpreterInlines.h:
3318         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3319         * dfg/DFGByteCodeParser.cpp:
3320         (JSC::DFG::ByteCodeParser::parseBlock):
3321         * dfg/DFGClobberize.h:
3322         (JSC::DFG::clobberize):
3323         * dfg/DFGDoesGC.cpp:
3324         (JSC::DFG::doesGC):
3325         * dfg/DFGFixupPhase.cpp:
3326         (JSC::DFG::FixupPhase::fixupNode):
3327         * dfg/DFGNodeType.h:
3328         * dfg/DFGPredictionPropagationPhase.cpp:
3329         (JSC::DFG::PredictionPropagationPhase::propagate):
3330         * dfg/DFGSafeToExecute.h:
3331         (JSC::DFG::safeToExecute):
3332         * dfg/DFGSpeculativeJIT32_64.cpp:
3333         (JSC::DFG::SpeculativeJIT::compile):
3334         * dfg/DFGSpeculativeJIT64.cpp: