DFG::Plan shouldn't read from its VM once it's been cancelled
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-05-15  Filip Pizlo  <fpizlo@apple.com>
2
3         DFG::Plan shouldn't read from its VM once it's been cancelled
4         https://bugs.webkit.org/show_bug.cgi?id=157726
5
6         Reviewed by Saam Barati.
7         
8         Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a
9         cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling
10         the plan.
11         
12         Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody
13         would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard
14         regression to spot because usually a cancelled plan will still refer to a valid VM.
15         
16         This change fixes the regression and makes it a lot easier to spot the regression in the
17         future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this
18         mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is
19         cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to
20         use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst.
21         
22         Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the
23         plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the
24         safepoint's VM to determine whether this is one of our safepoints *after* the plan is
25         already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled
26         when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's
27         vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one
28         loop and a cancel path for Safepoints in the loop after it).
29
30         * dfg/DFGJITFinalizer.cpp:
31         (JSC::DFG::JITFinalizer::finalizeCommon):
32         * dfg/DFGPlan.cpp:
33         (JSC::DFG::Plan::Plan):
34         (JSC::DFG::Plan::computeCompileTimes):
35         (JSC::DFG::Plan::reportCompileTimes):
36         (JSC::DFG::Plan::compileInThreadImpl):
37         (JSC::DFG::Plan::reallyAdd):
38         (JSC::DFG::Plan::notifyCompiling):
39         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
40         (JSC::DFG::Plan::cancel):
41         * dfg/DFGPlan.h:
42         (JSC::DFG::Plan::canTierUpAndOSREnter):
43         * dfg/DFGSafepoint.cpp:
44         (JSC::DFG::Safepoint::cancel):
45         (JSC::DFG::Safepoint::vm):
46         * dfg/DFGSafepoint.h:
47         * dfg/DFGWorklist.cpp:
48         (JSC::DFG::Worklist::isActiveForVM):
49         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
50         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
51         (JSC::DFG::Worklist::rememberCodeBlocks):
52         (JSC::DFG::Worklist::visitWeakReferences):
53         (JSC::DFG::Worklist::removeDeadPlans):
54         (JSC::DFG::Worklist::runThread):
55         * ftl/FTLJITFinalizer.cpp:
56         (JSC::FTL::JITFinalizer::finalizeFunction):
57
58 2016-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
59
60         Modernize Intl constructors; using InternalFunction::createSubclassStructure
61         https://bugs.webkit.org/show_bug.cgi?id=157082
62
63         Reviewed by Darin Adler.
64
65         Previously, Intl constructors retrieve "prototype" to inherit the "new.target".
66         At that time, this mis-assumed that getDirect() always returns meaningful JS value.
67         Actually, it returns an empty value if a property does not exist.
68
69         Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure
70         in Intl constructors. It is modern and preferable way since it can cache the derived
71         structures in InternalFunction.
72
73         This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat.
74         Those code are largely duplicate. This is now extracted into
75         constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not
76         have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat
77         and LayoutTests/js/intl-numberformat.
78
79         * JavaScriptCore.xcodeproj/project.pbxproj:
80         * runtime/IntlCollator.cpp:
81         (JSC::IntlCollator::create):
82         * runtime/IntlCollator.h:
83         * runtime/IntlCollatorConstructor.cpp:
84         (JSC::constructIntlCollator):
85         (JSC::callIntlCollator):
86         * runtime/IntlDateTimeFormat.cpp:
87         (JSC::IntlDateTimeFormat::create):
88         * runtime/IntlDateTimeFormat.h:
89         * runtime/IntlDateTimeFormatConstructor.cpp:
90         (JSC::constructIntlDateTimeFormat):
91         (JSC::callIntlDateTimeFormat):
92         * runtime/IntlDateTimeFormatPrototype.cpp:
93         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
94         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
95         * runtime/IntlNumberFormat.cpp:
96         (JSC::IntlNumberFormat::create):
97         * runtime/IntlNumberFormat.h:
98         * runtime/IntlNumberFormatConstructor.cpp:
99         (JSC::constructIntlNumberFormat):
100         (JSC::callIntlNumberFormat):
101         * runtime/IntlNumberFormatPrototype.cpp:
102         (JSC::IntlNumberFormatPrototypeGetterFormat):
103         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
104         * runtime/IntlObjectInlines.h: Added.
105         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
106         * tests/stress/intl-constructors-with-proxy.js: Added.
107         (shouldBe):
108         (throw.new.Error.Empty):
109         (throw.new.Error):
110         (shouldBe.Empty):
111
112 2016-05-14  Joseph Pecoraro  <pecoraro@apple.com>
113
114         Remove LegacyProfiler
115         https://bugs.webkit.org/show_bug.cgi?id=153565
116
117         Reviewed by Mark Lam.
118
119         JavaScriptCore now provides a sampling profiler and it is enabled
120         by all ports. Web Inspector switched months ago to using the
121         sampling profiler and displaying its data. Remove the legacy
122         profiler, as it is no longer being used by anything other then
123         console.profile and tests. We will update console.profile's
124         behavior soon to have new behavior and use the sampling data.
125
126         * API/JSProfilerPrivate.cpp: Removed.
127         * API/JSProfilerPrivate.h: Removed.
128         * CMakeLists.txt:
129         * JavaScriptCore.xcodeproj/project.pbxproj:
130         * bytecode/BytecodeList.json:
131         * bytecode/BytecodeUseDef.h:
132         (JSC::computeUsesForBytecodeOffset): Deleted.
133         (JSC::computeDefsForBytecodeOffset): Deleted.
134         * bytecode/CodeBlock.cpp:
135         (JSC::CodeBlock::dumpBytecode): Deleted.
136         * bytecode/UnlinkedFunctionExecutable.cpp:
137         (JSC::generateUnlinkedFunctionCodeBlock):
138         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
139         * bytecode/UnlinkedFunctionExecutable.h:
140         * bytecompiler/BytecodeGenerator.cpp:
141         (JSC::BytecodeGenerator::BytecodeGenerator):
142         (JSC::BytecodeGenerator::emitCall):
143         (JSC::BytecodeGenerator::emitCallVarargs):
144         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
145         (JSC::BytecodeGenerator::emitConstructVarargs):
146         (JSC::BytecodeGenerator::emitConstruct):
147         * bytecompiler/BytecodeGenerator.h:
148         (JSC::CallArguments::profileHookRegister): Deleted.
149         (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
150         * bytecompiler/NodesCodegen.cpp:
151         (JSC::CallFunctionCallDotNode::emitBytecode):
152         (JSC::ApplyFunctionCallDotNode::emitBytecode):
153         (JSC::CallArguments::CallArguments): Deleted.
154         * dfg/DFGAbstractInterpreterInlines.h:
155         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
156         * dfg/DFGByteCodeParser.cpp:
157         (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
158         * dfg/DFGCapabilities.cpp:
159         (JSC::DFG::capabilityLevel): Deleted.
160         * dfg/DFGClobberize.h:
161         (JSC::DFG::clobberize): Deleted.
162         * dfg/DFGDoesGC.cpp:
163         (JSC::DFG::doesGC): Deleted.
164         * dfg/DFGFixupPhase.cpp:
165         (JSC::DFG::FixupPhase::fixupNode): Deleted.
166         * dfg/DFGNodeType.h:
167         * dfg/DFGPredictionPropagationPhase.cpp:
168         * dfg/DFGSafeToExecute.h:
169         (JSC::DFG::safeToExecute): Deleted.
170         * dfg/DFGSpeculativeJIT32_64.cpp:
171         (JSC::DFG::SpeculativeJIT::compile): Deleted.
172         * dfg/DFGSpeculativeJIT64.cpp:
173         (JSC::DFG::SpeculativeJIT::compile): Deleted.
174         * inspector/InjectedScriptBase.cpp:
175         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
176         * inspector/protocol/Timeline.json:
177         * interpreter/Interpreter.cpp:
178         (JSC::UnwindFunctor::operator()): Deleted.
179         (JSC::Interpreter::execute): Deleted.
180         (JSC::Interpreter::executeCall): Deleted.
181         (JSC::Interpreter::executeConstruct): Deleted.
182         * jit/JIT.cpp:
183         (JSC::JIT::privateCompileMainPass): Deleted.
184         * jit/JIT.h:
185         * jit/JITOpcodes.cpp:
186         (JSC::JIT::emit_op_profile_will_call): Deleted.
187         (JSC::JIT::emit_op_profile_did_call): Deleted.
188         * jit/JITOpcodes32_64.cpp:
189         (JSC::JIT::emit_op_profile_will_call): Deleted.
190         (JSC::JIT::emit_op_profile_did_call): Deleted.
191         * jit/JITOperations.cpp:
192         * jit/JITOperations.h:
193         * jsc.cpp:
194         * llint/LLIntSlowPaths.cpp:
195         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
196         * llint/LLIntSlowPaths.h:
197         * llint/LowLevelInterpreter.asm:
198         * parser/ParserModes.h:
199         * profiler/CallIdentifier.h: Removed.
200         * profiler/LegacyProfiler.cpp: Removed.
201         * profiler/LegacyProfiler.h: Removed.
202         * profiler/Profile.cpp: Removed.
203         * profiler/Profile.h: Removed.
204         * profiler/ProfileGenerator.cpp: Removed.
205         * profiler/ProfileGenerator.h: Removed.
206         * profiler/ProfileNode.cpp: Removed.
207         * profiler/ProfileNode.h: Removed.
208         * profiler/ProfilerJettisonReason.cpp:
209         (WTF::printInternal): Deleted.
210         * profiler/ProfilerJettisonReason.h:
211         * runtime/CodeCache.cpp:
212         (JSC::CodeCache::getGlobalCodeBlock):
213         (JSC::CodeCache::getProgramCodeBlock):
214         (JSC::CodeCache::getEvalCodeBlock):
215         (JSC::CodeCache::getModuleProgramCodeBlock):
216         * runtime/CodeCache.h:
217         * runtime/Executable.cpp:
218         (JSC::ScriptExecutable::newCodeBlockFor):
219         * runtime/JSGlobalObject.cpp:
220         (JSC::JSGlobalObject::createProgramCodeBlock):
221         (JSC::JSGlobalObject::createEvalCodeBlock):
222         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
223         (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
224         (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
225         * runtime/JSGlobalObject.h:
226         (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
227         * runtime/Options.h:
228         * runtime/VM.cpp:
229         (JSC::VM::VM): Deleted.
230         (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
231         (JSC::VM::setEnabledProfiler): Deleted.
232         * runtime/VM.h:
233         (JSC::VM::enabledProfiler): Deleted.
234         (JSC::VM::enabledProfilerAddress): Deleted.
235
236 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
237
238         jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash
239         https://bugs.webkit.org/show_bug.cgi?id=157704
240
241         Reviewed by Saam Barati.
242
243         * jsc.cpp:
244         (functionStartSamplingProfiler):
245         (functionSamplingProfilerStackTraces):
246         Throw an exception instead of crashing if we haven't started sampling.
247
248         * inspector/agents/InspectorScriptProfilerAgent.cpp:
249         (Inspector::InspectorScriptProfilerAgent::startTracking):
250         * runtime/VM.h:
251         * runtime/VM.cpp:
252         (JSC::VM::ensureSamplingProfiler):
253         Switch ensure to returning a reference, like most other ensures.
254
255 2016-05-13  Saam barati  <sbarati@apple.com>
256
257         DFG/FTL have a few bugs in their reasoning about the scope
258         https://bugs.webkit.org/show_bug.cgi?id=157696
259
260         Reviewed by Benjamin Poulain.
261
262         1. When the debugger is enabled, it is easier for the DFG to reason
263         about the scope register by simply claiming all nodes read the scope
264         register. This prevents us from ever entering the runtime where we
265         may take a stack trace but there isn't a scope on the stack.
266
267         2. This patch fixes a bug where the FTL compilation wasn't properly
268         setting the CodeBlock register. It was only doing this when there
269         was inline data, but when the debugger is enabled, we never inline.
270         So this code just needed to be removed from that loop. It was never
271         right for it to be inside the loop.
272
273         * dfg/DFGClobberize.h:
274         (JSC::DFG::clobberize):
275         * ftl/FTLCompile.cpp:
276         (JSC::FTL::compile):
277
278 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
279
280         [JSC] SetLocal without exit do not need phantoms
281         https://bugs.webkit.org/show_bug.cgi?id=157653
282
283         Reviewed by Filip Pizlo.
284
285         I made a mistake in r200498.
286
287         If a SetLocal cannot possibly exit, we were not clearing
288         the source of the operand. As a result, we sometime kept
289         a value alive up to the end of the block.
290
291         That's uncommon because SetLocal typically appear
292         toward the end of blocks. That's probably why there was
293         no perf impact with that fix.
294
295         * dfg/DFGPhantomInsertionPhase.cpp:
296
297 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
298
299         [JSC] Move the CheckTierUp function calls out of the main path
300         https://bugs.webkit.org/show_bug.cgi?id=157668
301
302         Reviewed by Mark Lam.
303
304         If you have a tiny tiny loop (for example, Sunspider's bits-in-byte),
305         the size of CheckTierUp is a problem.
306
307         On multi-issue CPUs, the node is so big that we do not
308         get to run anything from the loop in the instruction fetch.
309
310         On x86, having a bigger loop also pushes us out of the LSD.
311
312         This is a 6% improvement on bits-in-byte. Other Sunspider tests
313         only improves marginally.
314
315         * dfg/DFGSpeculativeJIT.cpp:
316         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
317         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
318         * dfg/DFGSpeculativeJIT.h:
319         (JSC::DFG::SpeculativeJIT::silentSpill):
320         (JSC::DFG::SpeculativeJIT::silentFill):
321         * dfg/DFGSpeculativeJIT64.cpp:
322         (JSC::DFG::SpeculativeJIT::compile):
323
324 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
325
326         [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used
327         https://bugs.webkit.org/show_bug.cgi?id=157671
328
329         Reviewed by Mark Lam.
330
331         This improves the chances of having a value
332         when issuing the TEST.
333
334         * jit/JITPropertyAccess.cpp:
335         (JSC::JIT::emitLoadWithStructureCheck):
336
337 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
338
339         Web Inspector: Inform augmenting client when inspector controller is destroyed
340         https://bugs.webkit.org/show_bug.cgi?id=157688
341         <rdar://problem/25832724>
342
343         Reviewed by Timothy Hatcher.
344
345         * inspector/JSGlobalObjectInspectorController.cpp:
346         (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
347         * inspector/augmentable/AugmentableInspectorControllerClient.h:
348         There is a weak relationship between the InspectorController and the
349         AugmentingClient. Let the augmenting client know when the controller
350         is destroyed so it doesn't try to use us anymore.
351
352 2016-05-13  Geoffrey Garen  <ggaren@apple.com>
353
354         Runaway malloc memory usage in this simple JSC program
355         https://bugs.webkit.org/show_bug.cgi?id=157682
356
357         Reviewed by Mark Lam.
358
359         * heap/WeakSet.cpp:
360         (JSC::WeakSet::sweep): Whenever we might add a block to
361         m_logicallyEmptyWeakBlocks, be sure also to sweep a block in
362         m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals
363         even when all memory is freed.
364
365         We do this whenever we *might* add a block and not just whenever we *do*
366         add a block because we'd like to sweep the entries in
367         m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this
368         is a reasonably rate-limited opportunity to do so.
369
370 2016-05-13  Mark Lam  <mark.lam@apple.com>
371
372         We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM.
373         https://bugs.webkit.org/show_bug.cgi?id=157537
374         <rdar://problem/24794845>
375
376         Reviewed by Michael Saboff.
377
378         The pre-existing code behaves this way:
379
380         1. When JS code throws an exception, it saves callee save registers in
381            the VM calleeSaveRegistersBuffer.  These values are meant to be restored
382            to the callee save registers later either at the catch handler or at the
383            uncaught exception handler.
384
385         2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect
386            the exception.  That C++ code can change the values of the callee save
387            registers.
388
389            The inspector code in turn re-enters the VM to execute JS inspector code.
390
391            The JS inspector code can run hot enough that we do an enterOptimizationCheck
392            on it.  The enterOptimizationCheck first saves all callee save registers
393            into the VM calleeSaveRegistersBuffer.
394
395            This effectively overwrites the values in the VM calleeSaveRegistersBuffer
396            from (1).
397
398         3. Eventually, execution returns to the catch handler or the uncaught exception
399            handler which restores the overwritten values in the VM
400            calleeSaveRegistersBuffer to the callee save registers.
401
402            When execution returns to the C++ code that entered the VM before (1), the
403            values in the callee registers are not what that code expects, and badness
404            and/or crashes ensues.
405
406         This patch applies the following fix:
407         
408         1. Allocate space in the VMEntryFrame for the calleeSaveRegistersBuffer.
409            This ensures that each VM entry session has its own buffer to use, and will
410            not corrupt the one from the previous VM entry session.
411
412            Delete the VM calleeSaveRegistersBuffer.
413
414         2. Change all locations that uses the VM calleeSaveRegistersBuffer to use the
415            calleeSaveRegistersBuffer in the current VMEntryFrame.
416
417         3. Renamed all uses of the term "VMCalleeSavesBuffer" to
418            "VMEntryFrameCalleeSavesBuffer".
419
420         This fix has been tested on the following configurations:
421         1. JSC and layout tests on a debug ASan build for 64-bit x86_64.
422         2. JSC tests on a release ASan build for 32-bit x86.
423         3. JSC tests on a release normal (non-ASan) build for ARM64.
424         4. JSC tests on a release normal (non-ASan) build for ARMv7 and ARMv7s.
425         5. JSC tests on a release ASan CLOOP build for x86_64.
426
427         These test runs did not produce any new crashes.  The ASan CLOOP has some
428         pre-existing crashes which are not due to this patch.
429
430         This bug can be tested by running the inspector/debugger/regress-133182.html test
431         on an ASan build.
432
433         * bytecode/PolymorphicAccess.cpp:
434         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
435         * dfg/DFGJITCompiler.cpp:
436         (JSC::DFG::JITCompiler::compileExceptionHandlers):
437         * dfg/DFGOSREntry.cpp:
438         (JSC::DFG::prepareOSREntry):
439         * dfg/DFGOSRExitCompiler.cpp:
440         * dfg/DFGOSRExitCompiler32_64.cpp:
441         (JSC::DFG::OSRExitCompiler::compileExit):
442         * dfg/DFGOSRExitCompiler64.cpp:
443         (JSC::DFG::OSRExitCompiler::compileExit):
444         * dfg/DFGThunks.cpp:
445         (JSC::DFG::osrEntryThunkGenerator):
446         * ftl/FTLCompile.cpp:
447         (JSC::FTL::compile):
448         * ftl/FTLLowerDFGToB3.cpp:
449         (JSC::FTL::DFG::LowerDFGToB3::lower):
450         * ftl/FTLOSRExitCompiler.cpp:
451         (JSC::FTL::compileStub):
452         * interpreter/Interpreter.cpp:
453         (JSC::UnwindFunctor::operator()):
454         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
455         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
456         * interpreter/Interpreter.h:
457         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
458         * interpreter/VMEntryRecord.h:
459         (JSC::VMEntryRecord::calleeSaveRegistersBufferOffset):
460         (JSC::VMEntryRecord::prevTopCallFrame):
461         (JSC::VMEntryRecord::unsafePrevTopCallFrame):
462         (JSC::VMEntryFrame::vmEntryRecordOffset):
463         (JSC::VMEntryFrame::calleeSaveRegistersBufferOffset):
464         * jit/AssemblyHelpers.cpp:
465         (JSC::AssemblyHelpers::emitRandomThunk):
466         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
467         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
468         * jit/AssemblyHelpers.h:
469         (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
470         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
471         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
472         (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
473         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer): Deleted.
474         * jit/JIT.cpp:
475         (JSC::JIT::emitEnterOptimizationCheck):
476         (JSC::JIT::privateCompileExceptionHandlers):
477         * jit/JITOpcodes.cpp:
478         (JSC::JIT::emit_op_throw):
479         (JSC::JIT::emit_op_catch):
480         (JSC::JIT::emitSlow_op_loop_hint):
481         * jit/JITOpcodes32_64.cpp:
482         (JSC::JIT::emit_op_throw):
483         (JSC::JIT::emit_op_catch):
484         * jit/ThunkGenerators.cpp:
485         (JSC::throwExceptionFromCallSlowPathGenerator):
486         (JSC::nativeForGenerator):
487         * llint/LLIntThunks.cpp:
488         (JSC::vmEntryRecord):
489         * llint/LowLevelInterpreter.asm:
490         * llint/LowLevelInterpreter32_64.asm:
491         * llint/LowLevelInterpreter64.asm:
492         * runtime/VM.h:
493         (JSC::VM::getCTIStub):
494         (JSC::VM::calleeSaveRegistersBufferOffset): Deleted.
495         * wasm/WASMFunctionCompiler.h:
496         (JSC::WASMFunctionCompiler::endFunction):
497
498 2016-05-13  Beth Dakin  <bdakin@apple.com>
499
500         Add dyldSPI.h for linked on or after checks, and add one for link preview
501         https://bugs.webkit.org/show_bug.cgi?id=157401
502         -and corresponding-
503         rdar://problem/26253396
504
505         Reviewed by Darin Adler.
506
507         Import #import <wtf/spi/darwin/dyldSPI.h> which now declares all of the 
508         needed dyld code.
509         * API/JSWrapperMap.mm:
510
511 2016-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
512
513         Assertion failure for direct eval in non-class method
514         https://bugs.webkit.org/show_bug.cgi?id=157138
515
516         Reviewed by Saam Barati.
517
518         This assertion was incorrect. In method definitions in object literals,
519         it can be sloppy mode, but its DerivedContextType may not be DerivedContextType::None.
520
521         * bytecode/EvalCodeCache.h:
522         (JSC::EvalCodeCache::CacheKey::CacheKey):
523         (JSC::EvalCodeCache::CacheKey::operator==):
524         (JSC::EvalCodeCache::CacheKey::Hash::equal):
525         (JSC::EvalCodeCache::tryGet):
526         (JSC::EvalCodeCache::getSlow):
527         * interpreter/Interpreter.cpp:
528         (JSC::eval):
529         * tests/stress/direct-eval-in-object-literal-methods.js: Added.
530         (shouldBe):
531         (throw.new.Error):
532         (shouldBe.Parent.prototype.l):
533         (shouldBe.Parent):
534         (shouldBe.Derived.prototype.m):
535         (shouldBe.Derived):
536
537 2016-05-13  Skachkov Oleksandr  <gskachkov@gmail.com>
538
539         Assertion failure for super() call in arrow function default parameters
540         https://bugs.webkit.org/show_bug.cgi?id=157079
541
542         Reviewed by Saam Barati.
543
544         Root of the issue that in arrow function we load bounded variables this/super/new.target just after 
545         input parameters were initialized, and did not covered case of default values for 
546         function parameters. 
547         Current patch tried to fix issue and allow to load bounded variables earlier, before the input 
548         parameters are assigned by default values.
549
550         * bytecompiler/BytecodeGenerator.cpp:
551         (JSC::BytecodeGenerator::BytecodeGenerator):
552         * tests/stress/arrowfunction-lexical-bind-this-2.js:
553
554 2016-05-12  Mark Lam  <mark.lam@apple.com>
555
556         Baseline and DFG's JSC_report...CompileTimes needs CodeBlock hashes.
557         https://bugs.webkit.org/show_bug.cgi?id=157643
558
559         Reviewed by Keith Miller.
560
561         * runtime/Options.cpp:
562         (JSC::recomputeDependentOptions):
563
564 2016-05-12  Csaba Osztrogonác  <ossy@webkit.org>
565
566         Remove ENABLE(ES6_ARROWFUNCTION_SYNTAX) guards
567         https://bugs.webkit.org/show_bug.cgi?id=157564
568
569         Reviewed by Darin Adler.
570
571         * Configurations/FeatureDefines.xcconfig:
572         * parser/Parser.cpp:
573
574 2016-05-12  Joseph Pecoraro  <pecoraro@apple.com>
575
576         Web Inspector: CRASH getting internal properties of function with no bound arguments causes
577         https://bugs.webkit.org/show_bug.cgi?id=157613
578         <rdar://problem/26238754>
579
580         Reviewed by Timothy Hatcher.
581
582         * inspector/JSInjectedScriptHost.cpp:
583         (Inspector::JSInjectedScriptHost::getInternalProperties):
584         Gracefully handle a JSBoundFunction with no bound arguments.
585         In this case boundArgs is JSValue() which we don't want to
586         expose as the value of the internal property.
587
588 2016-05-11  Benjamin Poulain  <bpoulain@apple.com>
589
590         [JSC] Make sure StringRange is passed to Vector by register
591         https://bugs.webkit.org/show_bug.cgi?id=157603
592
593         Reviewed by Darin Adler.
594
595         This is bizarre, but on my SDK, Vector::append(StringRange)
596         is passing the values on the stack.
597         The two integers are written to the stack, the address given
598         to append(), then append() reads it back and store it.
599
600         This patch changes the code to use constructAndAppend(), ensuring
601         the values are used directly.
602
603         On my machine, this helps Sunspider and Octane.
604         This might be something wrong with my SDK but the fix is so easy
605         that we might as well do this.
606
607         * runtime/StringPrototype.cpp:
608         (JSC::removeUsingRegExpSearch):
609         (JSC::replaceUsingRegExpSearch):
610
611 2016-05-11  Zan Dobersek  <zdobersek@igalia.com>
612
613         ARMv7Assembler: suppress a -Wnarrowing warning when compiling with GCC
614         https://bugs.webkit.org/show_bug.cgi?id=157576
615
616         Reviewed by Csaba Osztrogonác.
617
618         * assembler/ARMv7Assembler.h:
619         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): Explicitly cast the
620         `OP_CMP_reg_T2 | left` value to uint16_t, avoiding a narrowing conversion
621         warning that's being reported when compiling with GCC. The warning is sprung
622         due to RegisterID (which is the type of `left`) being an enum based on int,
623         even when the enum itself only declares 23 values.
624
625 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
626
627         Web Inspector: `this` in Scope Chain Sidebar does not have preview, looks poor
628         https://bugs.webkit.org/show_bug.cgi?id=157602
629
630         Reviewed by Timothy Hatcher.
631
632         * inspector/InjectedScriptSource.js:
633         (InjectedScript.CallFrameProxy):
634         Include a preview when creating the RemoteObject for `this`.
635
636 2016-05-11  Keith Miller  <keith_miller@apple.com>
637
638         Unreviewed, correct the title of the ChangeLog for r200667.
639
640 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
641
642         JSC test stress/reflect-set.js failing after 200694
643         https://bugs.webkit.org/show_bug.cgi?id=157586
644
645         Unreviewed test rebaseline.
646
647         * tests/stress/reflect-set.js:
648         Update the expected error message. We are in strict mode, so the
649         improved error message makes sense.
650
651 2016-05-11  Filip Pizlo  <fpizlo@apple.com>
652
653         Beef up JSC profiler event log
654         https://bugs.webkit.org/show_bug.cgi?id=157584
655
656         Reviewed by Saam Barati.
657         
658         Also log more about compilation.
659
660         * bytecode/ExecutionCounter.cpp: Changed the meaning of codeBlock to be the codeBlock that is doing the profiling. This will now get the baseline version if it needs it. This is needed for logging the threshold checking event.
661         (JSC::applyMemoryUsageHeuristics):
662         (JSC::ExecutionCounter<countingVariant>::hasCrossedThreshold):
663         * dfg/DFGJITCode.cpp: Pass the right codeBlock.
664         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
665         (JSC::DFG::JITCode::optimizeNextInvocation):
666         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
667         (JSC::DFG::JITCode::optimizeSoon):
668         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
669         * dfg/DFGPlan.cpp: Log things about compile times and whether the compiler succeeded or failed.
670         (JSC::DFG::Plan::computeCompileTimes):
671         (JSC::DFG::Plan::reportCompileTimes):
672         (JSC::DFG::Plan::compileInThread):
673         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
674         * jit/ExecutableAllocatorFixedVMPool.cpp: Make it possible to look at memory usage, though separately from the log, for now.
675         (JSC::ExecutableAllocator::allocate):
676         * runtime/Options.h:
677
678 2016-05-11  Saam barati  <sbarati@apple.com>
679
680         Air may decide to put the result register of an arithmetic snippet in the tag register
681         https://bugs.webkit.org/show_bug.cgi?id=157548
682
683         Reviewed by Filip Pizlo.
684
685         This patch adds a new ValueRep to B3 called LateRegister. The semantics
686         are similar to Register in that it can be used to pin an argument to
687         a particular register. It differs from ValueRep::Register in that the semantics of
688         LateRegister are that it is used after the result of the node its an argument to
689         is computed. This means that a LateRegister argument will interfere with the result
690         of a node. LateRegister is not a valid result ValueRep.
691
692         This was needed because there was a bug where B3/Air would assign the
693         result of a patchpoint to the TagTypeNumber register. This broke our
694         code when we would box a double into a JSValue in a snippet when the
695         result is the same as the TagTypeNumber register. To fix the issue,
696         we pass TagMaskRegister and TagTypeNumberRegister as ValueRep::LateRegister
697         arguments to various patchpoints.
698
699         * b3/B3LowerToAir.cpp:
700         (JSC::B3::Air::LowerToAir::fillStackmap):
701         * b3/B3PatchpointSpecial.cpp:
702         (JSC::B3::PatchpointSpecial::admitsStack):
703         * b3/B3StackmapSpecial.cpp:
704         (JSC::B3::StackmapSpecial::forEachArgImpl):
705         (JSC::B3::StackmapSpecial::isArgValidForRep):
706         * b3/B3Validate.cpp:
707         * b3/B3ValueRep.cpp:
708         (JSC::B3::ValueRep::addUsedRegistersTo):
709         (JSC::B3::ValueRep::dump):
710         (JSC::B3::ValueRep::emitRestore):
711         (JSC::B3::ValueRep::recoveryForJSValue):
712         (WTF::printInternal):
713         * b3/B3ValueRep.h:
714         (JSC::B3::ValueRep::reg):
715         (JSC::B3::ValueRep::lateReg):
716         (JSC::B3::ValueRep::stack):
717         (JSC::B3::ValueRep::operator==):
718         (JSC::B3::ValueRep::isSomeRegister):
719         (JSC::B3::ValueRep::isReg):
720         * b3/testb3.cpp:
721         (JSC::B3::testSpillUseLargerThanDef):
722         (JSC::B3::testLateRegister):
723         (JSC::B3::zero):
724         (JSC::B3::run):
725         * ftl/FTLLowerDFGToB3.cpp:
726         (JSC::FTL::DFG::LowerDFGToB3::lower):
727         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
728         (JSC::FTL::DFG::LowerDFGToB3::getById):
729         (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
730         (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
731         (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
732
733 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
734
735         Improve error messages for accessing arguments.callee and similar getters in strict mode
736         https://bugs.webkit.org/show_bug.cgi?id=157545
737
738         Reviewed by Mark Lam.
739
740         * runtime/ClonedArguments.cpp:
741         (JSC::ClonedArguments::getOwnPropertySlot):
742         (JSC::ClonedArguments::materializeSpecials):
743         Provide better error GetterSetter in strict mode.
744
745         * runtime/JSFunction.cpp:
746         (JSC::getThrowTypeErrorGetterSetter):
747         (JSC::JSFunction::defineOwnProperty):
748         Provide better error GetterSetter in strict mode.
749
750         * runtime/JSGlobalObject.cpp:
751         (JSC::JSGlobalObject::init):
752         (JSC::JSGlobalObject::visitChildren):
753         * runtime/JSGlobalObject.h:
754         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
755         (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter):
756         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter):
757         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter):
758         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): Deleted.
759         * runtime/JSGlobalObjectFunctions.cpp:
760         (JSC::globalFuncThrowTypeErrorCalleeAndCaller):
761         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode):
762         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext):
763         (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): Deleted.
764         * runtime/JSGlobalObjectFunctions.h:
765         Rename and expose new handles for new error getter setter native functions.
766
767 2016-05-11  Commit Queue  <commit-queue@webkit.org>
768
769         Unreviewed, rolling out r200481.
770         https://bugs.webkit.org/show_bug.cgi?id=157573
771
772         it's bad news for asm.js (Requested by pizlo on #webkit).
773
774         Reverted changeset:
775
776         "Reduce maximum JIT pool size on X86_64."
777         http://trac.webkit.org/changeset/200481
778
779 2016-05-10  Keith Miller  <keith_miller@apple.com>
780
781         TypedArray.prototype.slice should not use the byteLength of the passed array for memmove
782         https://bugs.webkit.org/show_bug.cgi?id=157551
783         <rdar://problem/26179914>
784
785         Reviewed by Michael Saboff.
786
787         The TypedArray.prototype.slice function would use the byteLength of the passed array
788         to determine the amount of data to copy. It should have been using the passed length
789         times the size of each element. This fixes a crash on JavaPoly.com
790
791         * runtime/JSGenericTypedArrayViewInlines.h:
792         (JSC::JSGenericTypedArrayView<Adaptor>::set):
793         * tests/stress/typedarray-slice.js:
794
795 2016-05-10  Michael Saboff  <msaboff@apple.com>
796
797         REGRESSION(r200447): Unable to build C_LOOP with clang version 800.0.12 or higher
798         https://bugs.webkit.org/show_bug.cgi?id=157549
799
800         Reviewed by Keith Miller.
801
802         Disable debug annotations for C_LOOP builds.  They are inline assembly directives,
803         unnecessary and they cause syntax errors.
804
805         * offlineasm/asm.rb:
806
807 2016-05-10  Filip Pizlo  <fpizlo@apple.com>
808
809         Internal JSC profiler should have a timestamped log of events for each code block
810         https://bugs.webkit.org/show_bug.cgi?id=157538
811
812         Reviewed by Benjamin Poulain.
813         
814         For example, in 3d-cube, I can query the events for MMulti and I get:
815
816         1462917476.17083  MMulti#DTZ7qc                          installCode        
817         1462917476.179663 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
818         1462917476.179664 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline osrEntry           at bc#49
819         1462917476.185651 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1011.214233/1717.000000, -707
820         1462917476.187913 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      installCode        
821         1462917476.187917 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      osrEntry           at bc#49
822         1462917476.205365 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      jettison           due to OSRExit, counting = true, detail = (null)
823         1462917476.205368 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#65: BadCache/FromDFG
824         1462917476.205369 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
825         1462917476.205482 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/3434.000000, -1000
826         1462917476.211547 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/3434.000000, -1000
827         1462917476.213721 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      installCode        
828         1462917476.213726 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      osrEntry           at bc#49
829         1462917476.223976 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      jettison           due to OSRExit, counting = true, detail = (null)
830         1462917476.223981 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#77: BadCache/FromDFG
831         1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#94: BadCache/FromDFG
832         1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
833         1462917476.224064 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/6868.000000, -1000
834         1462917476.224151 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/6868.000000, -1000
835         1462917476.224258 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 3013.000000/6868.000000, -1000
836         1462917476.224337 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 4023.000000/6868.000000, -1000
837         1462917476.224425 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 5023.000000/6868.000000, -1000
838         1462917476.224785 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 6023.396484/6868.000000, -862
839         1462917476.227669 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      installCode        
840         1462917476.227675 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      osrEntry           at bc#0
841         
842         The output is ugly but useful. We can make it less ugly later.
843
844         * CMakeLists.txt:
845         * JavaScriptCore.xcodeproj/project.pbxproj:
846         * bytecode/CodeBlock.cpp:
847         (JSC::CodeBlock::jettison):
848         * bytecode/CodeBlock.h:
849         (JSC::ScriptExecutable::forEachCodeBlock):
850         * bytecode/DFGExitProfile.cpp:
851         (JSC::DFG::ExitProfile::add):
852         * dfg/DFGJITFinalizer.cpp:
853         (JSC::DFG::JITFinalizer::finalizeCommon):
854         * dfg/DFGOperations.cpp:
855         * ftl/FTLJITFinalizer.cpp:
856         (JSC::FTL::JITFinalizer::finalizeFunction):
857         * jit/JIT.cpp:
858         (JSC::JIT::privateCompile):
859         * jit/JITOperations.cpp:
860         * llint/LLIntSlowPaths.cpp:
861         (JSC::LLInt::jitCompileAndSetHeuristics):
862         (JSC::LLInt::entryOSR):
863         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
864         * profiler/ProfilerCompilation.cpp:
865         (JSC::Profiler::Compilation::Compilation):
866         (JSC::Profiler::Compilation::setJettisonReason):
867         (JSC::Profiler::Compilation::dump):
868         (JSC::Profiler::Compilation::toJS):
869         * profiler/ProfilerCompilation.h:
870         (JSC::Profiler::Compilation::uid):
871         * profiler/ProfilerDatabase.cpp:
872         (JSC::Profiler::Database::ensureBytecodesFor):
873         (JSC::Profiler::Database::notifyDestruction):
874         (JSC::Profiler::Database::addCompilation):
875         (JSC::Profiler::Database::toJS):
876         (JSC::Profiler::Database::registerToSaveAtExit):
877         (JSC::Profiler::Database::logEvent):
878         (JSC::Profiler::Database::addDatabaseToAtExit):
879         * profiler/ProfilerDatabase.h:
880         * profiler/ProfilerEvent.cpp: Added.
881         (JSC::Profiler::Event::dump):
882         (JSC::Profiler::Event::toJS):
883         * profiler/ProfilerEvent.h: Added.
884         (JSC::Profiler::Event::Event):
885         (JSC::Profiler::Event::operator bool):
886         (JSC::Profiler::Event::time):
887         (JSC::Profiler::Event::bytecodes):
888         (JSC::Profiler::Event::compilation):
889         (JSC::Profiler::Event::summary):
890         (JSC::Profiler::Event::detail):
891         * profiler/ProfilerUID.cpp: Added.
892         (JSC::Profiler::UID::create):
893         (JSC::Profiler::UID::dump):
894         (JSC::Profiler::UID::toJS):
895         * profiler/ProfilerUID.h: Added.
896         (JSC::Profiler::UID::UID):
897         (JSC::Profiler::UID::fromInt):
898         (JSC::Profiler::UID::toInt):
899         (JSC::Profiler::UID::operator==):
900         (JSC::Profiler::UID::operator!=):
901         (JSC::Profiler::UID::operator bool):
902         (JSC::Profiler::UID::isHashTableDeletedValue):
903         (JSC::Profiler::UID::hash):
904         (JSC::Profiler::UIDHash::hash):
905         (JSC::Profiler::UIDHash::equal):
906         * runtime/CommonIdentifiers.h:
907         * runtime/Executable.cpp:
908         (JSC::ScriptExecutable::installCode):
909         * runtime/VM.h:
910         (JSC::VM::bytecodeIntrinsicRegistry):
911         (JSC::VM::shadowChicken):
912         * runtime/VMInlines.h:
913         (JSC::VM::shouldTriggerTermination):
914         (JSC::VM::logEvent):
915
916 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
917
918         Web Inspector: Backend should initiate timeline recordings on page navigations to ensure nothing is missed
919         https://bugs.webkit.org/show_bug.cgi?id=157504
920         <rdar://problem/26188642>
921
922         Reviewed by Brian Burg.
923
924         * inspector/protocol/Timeline.json:
925         Add protocol commands to enable/disable auto capture and list the
926         instruments that should be enabled when auto capture starts.
927         Add protocol event for when the backend starts an auto capture.
928
929 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
930
931         Make the different evaluateWithScopeExtension implementations more consistent
932         https://bugs.webkit.org/show_bug.cgi?id=157536
933
934         Reviewed by Timothy Hatcher.
935
936         * inspector/JSInjectedScriptHost.cpp:
937         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
938         Throw the exception consistent with JSJavaScriptCallFrame.
939
940         * inspector/JSJavaScriptCallFrame.cpp:
941         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
942         Better error message consistent with InjectedScriptHost.
943
944         * runtime/Completion.h:
945         * runtime/Completion.cpp:
946         (JSC::evaluateWithScopeExtension):
947         Give this an Exception out parameter like other evaluations
948         so the caller can decide what to do with it.
949
950 2016-05-10  Benjamin Poulain  <bpoulain@apple.com>
951
952         [JSC] FTL can produce GetByVal nodes without proper bounds checking
953         https://bugs.webkit.org/show_bug.cgi?id=157502
954         rdar://problem/26027027
955
956         Reviewed by Filip Pizlo.
957
958         It was possible for FTL to generates GetByVal on arbitrary offsets
959         without any bounds checking.
960
961         The bug is caused by the order of optimization phases:
962         -First, the Integer Range Optimization proves that a CheckInBounds
963          test can never fail.
964          This proof is based on control flow or preceeding instructions
965          inside a loop.
966         -The Loop Invariant Code Motion phase finds that the GetByVal does not
967          depend on anything in the loop and hoist it out of the loop.
968         -> As a result, the conditions that were necessary to eliminate
969            the CheckInBounds are no longer met before the GetByVal.
970
971         This patch just moves the Integer Range Optimization phase after
972         Loop Invariant Code Motion to make sure no code is moved after
973         its integer ranges bounds proofs have been used.
974
975         * dfg/DFGPlan.cpp:
976         (JSC::DFG::Plan::compileInThreadImpl):
977         * tests/stress/bounds-check-not-eliminated-by-licm.js: Added.
978         (testInLoopTests):
979
980 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
981
982         Web Inspector: Eliminate the crazy code for evaluateOnCallFrame
983         https://bugs.webkit.org/show_bug.cgi?id=157510
984         <rdar://problem/26191332>
985
986         Reviewed by Timothy Hatcher.
987
988         * debugger/DebuggerCallFrame.cpp:
989         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
990         Set and clear an optional scope extension object.
991
992         * inspector/InjectedScriptSource.js:
993         (InjectedScript.prototype.evaluate):
994         (InjectedScript.prototype._evaluateOn):
995         (InjectedScript.prototype.evaluateOnCallFrame):
996         Unify the code to use the passed in evaluate function and object.
997         When evaluating on a call frame the evaluate function ends up being
998         DebuggerCallFrame::evaluateWithScopeExtension. When evaluating globally
999         this ends up being JSInjectedScriptHost::evaluateWithScopeExtension.
1000         In both cases "object" is the preferred this object to use.
1001
1002         * debugger/DebuggerCallFrame.h:
1003         * inspector/JSJavaScriptCallFrame.cpp:
1004         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
1005         (Inspector::JSJavaScriptCallFrame::evaluate): Deleted.
1006         * inspector/JSJavaScriptCallFrame.h:
1007         * inspector/JSJavaScriptCallFramePrototype.cpp:
1008         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
1009         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
1010         * inspector/JavaScriptCallFrame.h:
1011         (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
1012         (Inspector::JavaScriptCallFrame::evaluate): Deleted.
1013         Pass through to DebuggerCallFrame with the proper arguments.
1014
1015         * debugger/Debugger.cpp:
1016         (JSC::Debugger::hasBreakpoint):
1017         * inspector/ScriptDebugServer.cpp:
1018         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
1019         Use the new evaluate on call frame method name and no scope extension object.
1020
1021 2016-05-10  Saam barati  <sbarati@apple.com>
1022
1023         Make super-property-access.js test run for less time because it was timing out in debug builds.
1024
1025         Rubber stamped by Filip Pizlo.
1026
1027         * tests/stress/super-property-access.js:
1028         (test):
1029         (test.value):
1030         (test.foo):
1031         (test.B.prototype.bar):
1032         (test.B):
1033
1034 2016-05-10  Csaba Osztrogonác  <ossy@webkit.org>
1035
1036         [JSC] Fix the !ENABLE(DFG_JIT) build
1037         https://bugs.webkit.org/show_bug.cgi?id=157512
1038
1039         Reviewed by Mark Lam.
1040
1041         * jit/Repatch.cpp:
1042
1043 2016-05-09  Joseph Pecoraro  <pecoraro@apple.com>
1044
1045         Web Inspector: CRASH under JSC::DebuggerCallFrame::thisValue when hitting breakpoint
1046         https://bugs.webkit.org/show_bug.cgi?id=157442
1047         <rdar://problem/24172015>
1048
1049         Reviewed by Saam Barati.
1050
1051         * debugger/DebuggerCallFrame.cpp:
1052         (JSC::DebuggerCallFrame::thisValueForCallFrame):
1053         When the thisValue is JSValue() return undefined and avoid calling
1054         toThisValue which would lead to a crash. Having `this` be an empty
1055         JSValue could happen inside an ES6 class constructor, before
1056         calling super.
1057
1058 2016-05-09  Filip Pizlo  <fpizlo@apple.com>
1059
1060         Unreviewed, fix cloop.
1061
1062         * bytecode/ValueProfile.cpp:
1063         (JSC::ResultProfile::emitDetectNumericness):
1064         (JSC::ResultProfile::emitSetNonNumber):
1065         * bytecode/ValueProfile.h:
1066         (JSC::ResultProfile::addressOfFlags):
1067         (JSC::ResultProfile::addressOfSpecialFastPathCount):
1068         (JSC::ResultProfile::detectNumericness):
1069         (JSC::ResultProfile::hasBits):
1070
1071 2016-05-09  Michael Saboff  <msaboff@apple.com>
1072
1073         Crash beneath ObjCCallbackFunctionImpl::call
1074         https://bugs.webkit.org/show_bug.cgi?id=157491
1075
1076         Reviewed by Saam Barati.
1077
1078         Clear any exceptions after the micro task runs.
1079
1080         Tried creating a test case, but I don't have source for the app.
1081         I can't seem to find the right combination of Promises and ObjC code.
1082
1083         * runtime/JSJob.cpp:
1084         (JSC::JSJobMicrotask::run):
1085
1086 2016-05-09  Filip Pizlo  <fpizlo@apple.com>
1087
1088         Polymorphic operands in operators coerces downstream values to double.
1089         https://bugs.webkit.org/show_bug.cgi?id=151793
1090
1091         Reviewed by Mark Lam.
1092         
1093         Previously if an object flowed into arithmetic, the prediction propagation phase would either
1094         assume that the output of the arithmetic had to be double or sometimes it would assume that it
1095         couldn't be double. We want it to only assume that the output is double if it actually had been.
1096         
1097         The first part of this patch is to roll out http://trac.webkit.org/changeset/200502. That removed
1098         some of the machinery that we had in place to detect whether the output of an operation is int or
1099         double. That changeset claimed that the machinery was "fundamentally broken". It actually wasn't.
1100         The reason why it didn't work was that ByteCodeParser was ignoring it if likelyToTakeSlowCase was
1101         false. I think this was a complete goof-up: the code in ByteCodeParser::makeSafe was structured
1102         in a way that made it non-obvious that the method is a no-op if !likelyToTakeSlowCase. So, this
1103         change rolls out r200502 and makes ResultProfile do its job by reshaping how makeSafe processes
1104         it.
1105         
1106         This also makes two other changes to shore up ResultProfile:
1107         - OSR exit can now refine a ResultProfile the same way that it refines ValueProfile.
1108         - Baseline JIT slow paths now set bits in ResultProfile.
1109         
1110         Based on this stuff, the DFG now predicts int/double/string in op_add/op_sub/op_mul based on
1111         ResultProfiles. To be conservative, we still only use the ResultProfiles if the incoming
1112         prediction is not number-or-boolean. This ensures that we exactly retain our old behavior in
1113         those cases for which it was tuned. But I hope to remove this soon. I believe that ResultProfile
1114         is already strictly better than what prediction propagation was doing before.
1115         
1116         This can be an enormous win. This patch adds some simple microbenchmarks that demonstrate the
1117         problem of assuming that arithmetic on objects returns double. The most extreme of these speeds
1118         up 8x with this change (object-int-add-array).
1119         
1120         * CMakeLists.txt:
1121         * JavaScriptCore.xcodeproj/project.pbxproj:
1122         * bytecode/CodeBlock.h:
1123         (JSC::CodeBlock::addFrequentExitSite):
1124         (JSC::CodeBlock::hasExitSite):
1125         * bytecode/DFGExitProfile.cpp:
1126         (JSC::DFG::FrequentExitSite::dump):
1127         (JSC::DFG::ExitProfile::ExitProfile):
1128         (JSC::DFG::ExitProfile::~ExitProfile):
1129         (JSC::DFG::ExitProfile::add):
1130         * bytecode/DFGExitProfile.h:
1131         (JSC::DFG::FrequentExitSite::isHashTableDeletedValue):
1132         * bytecode/MethodOfGettingAValueProfile.cpp:
1133         (JSC::MethodOfGettingAValueProfile::fromLazyOperand):
1134         (JSC::MethodOfGettingAValueProfile::emitReportValue):
1135         (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): Deleted.
1136         * bytecode/MethodOfGettingAValueProfile.h:
1137         (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
1138         (JSC::MethodOfGettingAValueProfile::operator bool):
1139         (JSC::MethodOfGettingAValueProfile::operator!): Deleted.
1140         * bytecode/PolymorphicAccess.cpp:
1141         (JSC::AccessCase::generateImpl):
1142         * bytecode/ValueProfile.cpp:
1143         (JSC::ResultProfile::emitDetectBitsLight):
1144         (JSC::ResultProfile::emitSetDouble):
1145         (JSC::ResultProfile::emitSetNonNumber):
1146         (WTF::printInternal):
1147         * bytecode/ValueProfile.h:
1148         (JSC::ResultProfile::ResultProfile):
1149         (JSC::ResultProfile::bytecodeOffset):
1150         (JSC::ResultProfile::specialFastPathCount):
1151         (JSC::ResultProfile::didObserveNonInt32):
1152         (JSC::ResultProfile::didObserveDouble):
1153         (JSC::ResultProfile::didObserveNonNegZeroDouble):
1154         (JSC::ResultProfile::didObserveNegZeroDouble):
1155         (JSC::ResultProfile::didObserveNonNumber):
1156         (JSC::ResultProfile::didObserveInt32Overflow):
1157         (JSC::ResultProfile::didObserveInt52Overflow):
1158         (JSC::ResultProfile::setObservedNonNegZeroDouble):
1159         (JSC::ResultProfile::setObservedNegZeroDouble):
1160         (JSC::ResultProfile::setObservedNonNumber):
1161         (JSC::ResultProfile::setObservedInt32Overflow):
1162         (JSC::ResultProfile::addressOfFlags):
1163         (JSC::ResultProfile::addressOfSpecialFastPathCount):
1164         (JSC::ResultProfile::detectBitsLight):
1165         (JSC::ResultProfile::hasBits):
1166         * dfg/DFGByteCodeParser.cpp:
1167         (JSC::DFG::ByteCodeParser::makeSafe):
1168         * dfg/DFGFixupPhase.cpp:
1169         (JSC::DFG::FixupPhase::fixupNode):
1170         * dfg/DFGGraph.cpp:
1171         (JSC::DFG::Graph::ensureNaturalLoops):
1172         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1173         (JSC::DFG::Graph::valueProfileFor): Deleted.
1174         * dfg/DFGGraph.h:
1175         (JSC::DFG::Graph::hasExitSite):
1176         (JSC::DFG::Graph::numBlocks):
1177         * dfg/DFGNode.h:
1178         (JSC::DFG::Node::arithNodeFlags):
1179         (JSC::DFG::Node::mayHaveNonIntResult):
1180         (JSC::DFG::Node::mayHaveDoubleResult):
1181         (JSC::DFG::Node::mayHaveNonNumberResult):
1182         (JSC::DFG::Node::hasConstantBuffer):
1183         * dfg/DFGNodeFlags.cpp:
1184         (JSC::DFG::dumpNodeFlags):
1185         * dfg/DFGNodeFlags.h:
1186         * dfg/DFGOSRExitCompiler32_64.cpp:
1187         (JSC::DFG::OSRExitCompiler::compileExit):
1188         * dfg/DFGOSRExitCompiler64.cpp:
1189         (JSC::DFG::OSRExitCompiler::compileExit):
1190         * dfg/DFGOperations.cpp:
1191         * dfg/DFGOperations.h:
1192         * dfg/DFGPredictionPropagationPhase.cpp:
1193         * dfg/DFGSpeculativeJIT.h:
1194         (JSC::DFG::SpeculativeJIT::callOperation):
1195         * ftl/FTLOSRExitCompiler.cpp:
1196         (JSC::FTL::compileStub):
1197         * jit/AssemblyHelpers.h:
1198         (JSC::AssemblyHelpers::branchIfEqual):
1199         (JSC::AssemblyHelpers::branchIfNotCell):
1200         (JSC::AssemblyHelpers::branchIfNotNumber):
1201         (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32):
1202         (JSC::AssemblyHelpers::branchIfBoolean):
1203         (JSC::AssemblyHelpers::branchIfEmpty):
1204         (JSC::AssemblyHelpers::branchStructure):
1205         * jit/CCallHelpers.h:
1206         (JSC::CCallHelpers::CCallHelpers):
1207         (JSC::CCallHelpers::setupArguments):
1208         (JSC::CCallHelpers::setupArgumentsWithExecState):
1209         * jit/IntrinsicEmitter.cpp:
1210         (JSC::AccessCase::emitIntrinsicGetter):
1211         * jit/JIT.h:
1212         * jit/JITAddGenerator.cpp:
1213         (JSC::JITAddGenerator::generateFastPath):
1214         * jit/JITAddGenerator.h:
1215         (JSC::JITAddGenerator::JITAddGenerator):
1216         * jit/JITArithmetic.cpp:
1217         (JSC::JIT::emit_op_add):
1218         (JSC::JIT::emitSlow_op_add):
1219         (JSC::JIT::emit_op_div):
1220         (JSC::JIT::emit_op_mul):
1221         (JSC::JIT::emitSlow_op_mul):
1222         (JSC::JIT::emit_op_sub):
1223         (JSC::JIT::emitSlow_op_sub):
1224         * jit/JITInlines.h:
1225         (JSC::JIT::callOperation):
1226         (JSC::JIT::callOperationNoExceptionCheck):
1227         * jit/JITMulGenerator.cpp:
1228         (JSC::JITMulGenerator::generateFastPath):
1229         * jit/JITOperations.cpp:
1230         * jit/JITOperations.h:
1231         * jit/JITSubGenerator.cpp:
1232         (JSC::JITSubGenerator::generateFastPath):
1233         * jit/JITSubGenerator.h:
1234         (JSC::JITSubGenerator::JITSubGenerator):
1235         * jit/TagRegistersMode.cpp: Added.
1236         (WTF::printInternal):
1237         * jit/TagRegistersMode.h: Added.
1238         * runtime/CommonSlowPaths.cpp:
1239         (JSC::updateResultProfileForBinaryArithOp):
1240
1241 2016-05-09  Keith Miller  <keith_miller@apple.com>
1242
1243         CallObjectConstructor should not call operationToThis in the FTL
1244         https://bugs.webkit.org/show_bug.cgi?id=157492
1245         <rdar://problem/26149904>
1246
1247         Reviewed by Mark Lam.
1248
1249         At some point when I was working on intrinsifying the Object
1250         constructor, I realized that the Object constructor was different
1251         from the ToObject operation. I fixed the DFG but I guess I didn't
1252         fix the FTL.
1253
1254         This patch fixes an issue with www.wunderground.com not loading
1255         the 10-day forecast and local map.
1256
1257         * ftl/FTLLowerDFGToB3.cpp:
1258         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
1259         * tests/stress/call-object-constructor.js: Added.
1260         (test):
1261         (assert):
1262
1263 2016-05-09  Saam barati  <sbarati@apple.com>
1264
1265         Getter and setter on super are called with wrong "this" object
1266         https://bugs.webkit.org/show_bug.cgi?id=147064
1267         <rdar://problem/21885916>
1268
1269         Reviewed by Filip Pizlo.
1270
1271         This patch implements calls to 'super' getters and setters.
1272         The problem before is we were passing the 'super' (i.e, the prototype
1273         object) as the this value to these getters/setters, which is wrong. 
1274         We should be passing the caller's this value.
1275
1276         To implement this behavior, I've introduced four new opcodes and their corresponding DFG nodes:
1277         - op_get_by_id_with_this | GetByIdWithThis
1278         - op_put_by_id_with_this | PutByIdWithThis
1279         - op_get_by_val_with_this | GetByValWithThis
1280         - op_put_by_val_with_this | PutByValWithThis
1281
1282         These are implemented with no optimizations. The future plan is 
1283         to unite them with the *by_id and *by_val opcodes and nodes:
1284         https://bugs.webkit.org/show_bug.cgi?id=157215
1285
1286         * bytecode/BytecodeList.json:
1287         * bytecode/BytecodeUseDef.h:
1288         (JSC::computeUsesForBytecodeOffset):
1289         (JSC::computeDefsForBytecodeOffset):
1290         * bytecode/CodeBlock.cpp:
1291         (JSC::CodeBlock::dumpBytecode):
1292         * bytecompiler/BytecodeGenerator.cpp:
1293         (JSC::BytecodeGenerator::emitGetById):
1294         (JSC::BytecodeGenerator::emitPutById):
1295         (JSC::BytecodeGenerator::emitDirectPutById):
1296         (JSC::BytecodeGenerator::emitGetByVal):
1297         (JSC::BytecodeGenerator::emitPutByVal):
1298         (JSC::BytecodeGenerator::emitDirectPutByVal):
1299         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
1300         (JSC::BytecodeGenerator::ensureThis):
1301         (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
1302         * bytecompiler/BytecodeGenerator.h:
1303         * bytecompiler/NodesCodegen.cpp:
1304         (JSC::ThisNode::emitBytecode):
1305         (JSC::emitHomeObjectForCallee):
1306         (JSC::emitSuperBaseForCallee):
1307         (JSC::emitGetSuperFunctionForConstruct):
1308         (JSC::SuperNode::emitBytecode):
1309         (JSC::NewTargetNode::emitBytecode):
1310         (JSC::TaggedTemplateNode::emitBytecode):
1311         (JSC::BracketAccessorNode::emitBytecode):
1312         (JSC::DotAccessorNode::emitBytecode):
1313         (JSC::FunctionCallValueNode::emitBytecode):
1314         (JSC::FunctionCallBracketNode::emitBytecode):
1315         (JSC::FunctionCallDotNode::emitBytecode):
1316         (JSC::CallFunctionCallDotNode::emitBytecode):
1317         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1318         (JSC::PostfixNode::emitBracket):
1319         (JSC::PostfixNode::emitDot):
1320         (JSC::PrefixNode::emitBracket):
1321         (JSC::PrefixNode::emitDot):
1322         (JSC::AssignDotNode::emitBytecode):
1323         (JSC::ReadModifyDotNode::emitBytecode):
1324         (JSC::AssignBracketNode::emitBytecode):
1325         (JSC::ReadModifyBracketNode::emitBytecode):
1326         (JSC::ForInNode::emitLoopHeader):
1327         (JSC::ForOfNode::emitBytecode):
1328         (JSC::AssignmentElementNode::bindValue):
1329         * dfg/DFGAbstractInterpreterInlines.h:
1330         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1331         * dfg/DFGByteCodeParser.cpp:
1332         (JSC::DFG::ByteCodeParser::parseBlock):
1333         * dfg/DFGCapabilities.cpp:
1334         (JSC::DFG::capabilityLevel):
1335         * dfg/DFGClobberize.h:
1336         (JSC::DFG::clobberize):
1337         * dfg/DFGDoesGC.cpp:
1338         (JSC::DFG::doesGC):
1339         * dfg/DFGFixupPhase.cpp:
1340         (JSC::DFG::FixupPhase::fixupNode):
1341         * dfg/DFGNode.h:
1342         (JSC::DFG::Node::hasIdentifier):
1343         * dfg/DFGNodeType.h:
1344         * dfg/DFGOperations.cpp:
1345         (JSC::DFG::newTypedArrayWithSize):
1346         (JSC::DFG::putWithThis):
1347         * dfg/DFGOperations.h:
1348         * dfg/DFGPredictionPropagationPhase.cpp:
1349         * dfg/DFGSafeToExecute.h:
1350         (JSC::DFG::safeToExecute):
1351         * dfg/DFGSpeculativeJIT.h:
1352         (JSC::DFG::SpeculativeJIT::callOperation):
1353         * dfg/DFGSpeculativeJIT32_64.cpp:
1354         (JSC::DFG::SpeculativeJIT::compile):
1355         * dfg/DFGSpeculativeJIT64.cpp:
1356         (JSC::DFG::SpeculativeJIT::compile):
1357         * ftl/FTLCapabilities.cpp:
1358         (JSC::FTL::canCompile):
1359         * ftl/FTLLowerDFGToB3.cpp:
1360         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1361         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
1362         (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
1363         (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
1364         (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
1365         (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
1366         (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
1367         * jit/CCallHelpers.cpp:
1368         (JSC::CCallHelpers::setupShadowChickenPacket):
1369         (JSC::CCallHelpers::setupFourStubArgsGPR):
1370         * jit/CCallHelpers.h:
1371         (JSC::CCallHelpers::setupArgumentsWithExecState):
1372         (JSC::CCallHelpers::setupThreeStubArgsGPR):
1373         (JSC::CCallHelpers::setupTwoStubArgsFPR):
1374         (JSC::CCallHelpers::setupStubArguments134):
1375         * jit/GPRInfo.h:
1376         (JSC::argumentRegisterFor): Deleted.
1377         * jit/JIT.cpp:
1378         (JSC::JIT::privateCompileMainPass):
1379         * jit/JIT.h:
1380         * jit/JITOperations.h:
1381         * jit/JITPropertyAccess.cpp:
1382         (JSC::JIT::emit_op_put_by_val):
1383         (JSC::JIT::emit_op_put_by_val_with_this):
1384         (JSC::JIT::emitGenericContiguousPutByVal):
1385         (JSC::JIT::emit_op_get_by_id):
1386         (JSC::JIT::emit_op_get_by_id_with_this):
1387         (JSC::JIT::emit_op_get_by_val_with_this):
1388         (JSC::JIT::emitSlow_op_get_by_id):
1389         (JSC::JIT::emit_op_put_by_id):
1390         (JSC::JIT::emit_op_put_by_id_with_this):
1391         (JSC::JIT::emitSlow_op_put_by_id):
1392         * jit/JITPropertyAccess32_64.cpp:
1393         (JSC::JIT::emit_op_put_to_arguments):
1394         (JSC::JIT::emit_op_get_by_id_with_this):
1395         (JSC::JIT::emit_op_get_by_val_with_this):
1396         (JSC::JIT::emit_op_put_by_id_with_this):
1397         (JSC::JIT::emit_op_put_by_val_with_this):
1398         * llint/LowLevelInterpreter.asm:
1399         * runtime/CommonSlowPaths.cpp:
1400         (JSC::SLOW_PATH_DECL):
1401         * runtime/CommonSlowPaths.h:
1402         * tests/stress/super-property-access-exceptions.js: Added.
1403         (assert):
1404         (test):
1405         (test.fooProp):
1406         (test.A.prototype.get foo):
1407         (test.A.prototype.get x):
1408         (test.A):
1409         (test.B):
1410         (test.B.prototype.bar):
1411         (test.B.prototype.baz):
1412         (test.foo):
1413         (test.func):
1414         (test.A.prototype.set foo):
1415         * tests/stress/super-property-access-tdz.js: Added.
1416         (assert):
1417         (test):
1418         (shouldThrowTDZ):
1419         (test.A.prototype.get foo):
1420         (test.A.prototype.set foo):
1421         (test.A):
1422         (test.fooProp):
1423         (test.B):
1424         (test.C):
1425         (test.D):
1426         (test.E):
1427         (test.F):
1428         * tests/stress/super-property-access.js: Added.
1429         (assert):
1430         (test):
1431         (func):
1432         (test.A):
1433         (test.A.prototype.set value):
1434         (test.A.prototype.get value):
1435         (test.B.prototype.set value):
1436         (test.B.prototype.get value):
1437         (test.B):
1438         (test.value):
1439         (test.A.prototype.get func):
1440         (test.B.prototype.inc):
1441         (test.B.prototype.dec):
1442         (test.B.prototype.preInc):
1443         (test.B.prototype.preDec):
1444         (test.B.prototype.plusEq):
1445         (test.B.prototype.minusEq):
1446         (test.B.prototype.timesEq):
1447         (test.B.prototype.divEq):
1448         (test.B.prototype.funcDot):
1449         (test.B.prototype.funcBracket):
1450         (test.foo):
1451         (test.B.prototype.baz):
1452         (test.B.prototype.jaz):
1453         (test.B.prototype.bar):
1454         (test.B.prototype.index):
1455         (test.):
1456         (test.prototype.bar):
1457         (test.A.prototype.set foo):
1458         (test.A.prototype.get array):
1459         (test.A.prototype.get foo):
1460         (test.obj):
1461         (test.A.prototype.get call):
1462         (test.A.prototype.get apply):
1463         (test.B.prototype.foo):
1464         (test.A.prototype.get i):
1465
1466 2016-05-08  Chris Dumez  <cdumez@apple.com>
1467
1468         [COCOA] Disable HAVE_DTRACE at build time
1469         https://bugs.webkit.org/show_bug.cgi?id=157433
1470         <rdar://problem/26148841>
1471
1472         Reviewed by Mark Lam.
1473
1474         Drop DTRACE-related code from JSC since it is very old and seems
1475         unused.
1476
1477         * JavaScriptCore.xcodeproj/project.pbxproj:
1478         * PlatformMac.cmake:
1479         * heap/Heap.cpp:
1480         (JSC::Heap::collectImpl): Deleted.
1481         (JSC::Heap::didFinishCollection): Deleted.
1482         * profiler/ProfileGenerator.cpp:
1483         (JSC::ProfileGenerator::willExecute): Deleted.
1484         (JSC::ProfileGenerator::didExecute): Deleted.
1485         * runtime/Tracing.d: Removed.
1486         * runtime/Tracing.h: Removed.
1487
1488 2016-05-07  Mark Lam  <mark.lam@apple.com>
1489
1490         Add JSC options bytecodeRangeToJITCompile and jitWhitelist.
1491         https://bugs.webkit.org/show_bug.cgi?id=157428
1492
1493         Reviewed by Michael Saboff.
1494
1495         1. Added Options::bytecodeRangeToJITCompile and Options::jitWhitelist options.
1496
1497         2. Moved DFGFunctionWhitelist* to FunctionWhitelist* and made it generic so that
1498            it can be used for more than one whitelist instance.  In this case, we now have
1499            two: the dfgWhitelist and the jitWhitelist.
1500
1501         3. Added "can compile" checks in LLInt::shouldJIT() to check
1502            Options::bytecodeRangeToJITCompile and Options::jitWhitelist.
1503
1504         * CMakeLists.txt:
1505         * JavaScriptCore.xcodeproj/project.pbxproj:
1506         * dfg/DFGDriver.cpp:
1507         (JSC::DFG::getNumCompilations):
1508         (JSC::DFG::ensureGlobalDFGWhitelist):
1509         (JSC::DFG::compileImpl):
1510         * dfg/DFGFunctionWhitelist.cpp: Removed.
1511         * dfg/DFGFunctionWhitelist.h: Removed.
1512
1513         * llint/LLIntSlowPaths.cpp:
1514         (JSC::LLInt::ensureGlobalJITWhitelist):
1515         (JSC::LLInt::shouldJIT):
1516
1517         * runtime/Options.h:
1518
1519         * tools/FunctionWhitelist.cpp: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.cpp.
1520         (JSC::FunctionWhitelist::FunctionWhitelist):
1521         (JSC::FunctionWhitelist::contains):
1522         (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist): Deleted.
1523         (JSC::DFG::FunctionWhitelist::FunctionWhitelist): Deleted.
1524         (JSC::DFG::FunctionWhitelist::parseFunctionNamesInFile): Deleted.
1525         (JSC::DFG::FunctionWhitelist::contains): Deleted.
1526         * tools/FunctionWhitelist.h: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.h.
1527
1528 2016-05-07  Benjamin Poulain  <bpoulain@apple.com>
1529
1530         [JSC][32bit] stress/tagged-templates-template-object.js fails in debug
1531         https://bugs.webkit.org/show_bug.cgi?id=157436
1532
1533         Reviewed by Filip Pizlo.
1534
1535         * dfg/DFGSpeculativeJIT32_64.cpp:
1536         (JSC::DFG::SpeculativeJIT::compile):
1537         The node OverridesHasInstance had a speculation after a jump.
1538
1539 2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>
1540
1541         Web Inspector: Misc CommandLineAPI cleanup
1542         https://bugs.webkit.org/show_bug.cgi?id=157450
1543
1544         Reviewed by Ryosuke Niwa.
1545
1546         * inspector/InjectedScriptSource.js:
1547         (BasicCommandLineAPI):
1548         Fix mistake in r200533, and modernize related code.
1549
1550 2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>
1551
1552         Web Inspector: Improve console.count()
1553         https://bugs.webkit.org/show_bug.cgi?id=157439
1554         <rdar://problem/26152654>
1555
1556         Reviewed by Timothy Hatcher.
1557
1558           - make console.count() increment an unnamed global counter.
1559           - make console.count(label) increment a counter with that label name.
1560
1561         * inspector/agents/InspectorConsoleAgent.cpp:
1562         (Inspector::InspectorConsoleAgent::count):
1563
1564 2016-05-06  Simon Fraser  <simon.fraser@apple.com>
1565
1566         Enable IOS_TEXT_AUTOSIZING on Mac and make it testable
1567         https://bugs.webkit.org/show_bug.cgi?id=157432
1568         rdar://problem/16406720
1569
1570         Reviewed by Dean Jackson.
1571
1572         Enable IOS_TEXT_AUTOSIZING on Mac so it can be tested.
1573
1574         * Configurations/FeatureDefines.xcconfig:
1575
1576 2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>
1577
1578         Web Inspector: Console: Variables defined with let/const aren't accessible outside of console's scope
1579         https://bugs.webkit.org/show_bug.cgi?id=150752
1580         <rdar://problem/23343385>
1581
1582         Reviewed by Mark Lam.
1583
1584         This approach allows Web Inspector to hang a "Scope Extension", a
1585         WithObjectScope, off the GlobalObject. When resolving identifiers
1586         in fails to resolve anything in the normal scope chain, consult
1587         the scope extension.
1588
1589         This allows us to eliminate the `with (commandLineAPI) { ... }`
1590         block in global console evaluations, and instead makes it a full
1591         program evaluation, with the commandLineAPI available and safely
1592         shadowed by actual variables as expected.
1593
1594         * inspector/InjectedScriptSource.js:
1595         (InjectedScript.prototype._evaluateOn):
1596         Use the new evaluateWithScopeExtension and provide the CommandLineAPI
1597         object as the scope extension object.
1598
1599         (BasicCommandLineAPI):
1600         (BasicCommandLineAPI.inScopeVariables): Deleted.
1601         Simplify now that we don't need to check for variable shadowing ourselves.
1602
1603         * inspector/JSInjectedScriptHost.cpp:
1604         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
1605         * inspector/JSInjectedScriptHost.h:
1606         * inspector/JSInjectedScriptHostPrototype.cpp:
1607         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1608         (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
1609         Provide a new InjectedScriptHost method to evaluate a program
1610         with a scope extension.
1611
1612         * runtime/Completion.cpp:
1613         (JSC::evaluateWithScopeExtension):
1614         * runtime/Completion.h:
1615         General JSC::evaluate function to evaluate a program with a scope extension.
1616
1617         * runtime/JSGlobalObject.cpp:
1618         (JSC::JSGlobalObject::setGlobalScopeExtension):
1619         (JSC::JSGlobalObject::clearGlobalScopeExtension):
1620         (JSC::JSGlobalObject::visitChildren):
1621         * runtime/JSGlobalObject.h:
1622         (JSC::JSGlobalObject::globalScopeExtension):
1623         Hang a scope extension off the global object.
1624
1625         * runtime/JSScope.cpp:
1626         (JSC::JSScope::resolve):
1627         Consult the scope extension when resolve fails to find anything normally.
1628
1629 2016-05-06  Mark Lam  <mark.lam@apple.com>
1630
1631         Add JSC options reportBaselineCompileTimes and reportDFGCompileTimes.
1632         https://bugs.webkit.org/show_bug.cgi?id=157427
1633
1634         Reviewed by Filip Pizlo and Keith Miller.
1635
1636         The compile times reporting options are now:
1637             reportCompileTimes         -> report compile times in all tiers.
1638             reportBaselineCompileTimes -> report compile times in baseline JIT.
1639             reportDFGCompileTimes      -> report compile times in DFG and FTL.
1640             reportFTLCompileTimes      -> report compile times in FTL.
1641
1642         Also updated reportTotalCompileTimes() to collect stats that include the baseline
1643         JIT.  compileTimeStats() is now moved into JIT.cpp (from DFGPlan.cpp). 
1644
1645         * dfg/DFGPlan.cpp:
1646         (JSC::DFG::Plan::reportCompileTimes):
1647         (JSC::DFG::Plan::compileInThread):
1648         (JSC::DFG::Plan::compileInThreadImpl):
1649         (JSC::DFG::Plan::cancel):
1650         (JSC::DFG::Plan::compileTimeStats): Deleted.
1651         * dfg/DFGPlan.h:
1652         (JSC::DFG::Plan::compileTimeStats): Deleted.
1653         * jit/JIT.cpp:
1654         (JSC::ctiPatchCallByReturnAddress):
1655         (JSC::JIT::privateCompile):
1656         (JSC::JIT::stackPointerOffsetFor):
1657         (JSC::JIT::reportCompileTimes):
1658         (JSC::JIT::computeCompileTimes):
1659         (JSC::JIT::compileTimeStats):
1660         * jit/JIT.h:
1661         (JSC::JIT::shouldEmitProfiling):
1662         * jsc.cpp:
1663         (runJSC):
1664         * runtime/Options.h:
1665
1666 2016-05-05  Benjamin Poulain  <bpoulain@apple.com>
1667
1668         [JSC] Get rid of NonNegZeroDouble, it is broken
1669         https://bugs.webkit.org/show_bug.cgi?id=157399
1670         rdar://problem/25339647
1671
1672         Reviewed by Mark Lam.
1673
1674         The profile "NonNegZeroDouble" is fundamentally broken.
1675
1676         It is used by DFG to predict the result of ArithMul as being a Double
1677         or Int32.
1678         The problem is you are likely to mispredict, and when you do, you are
1679         guaranteed to end up in a recompile loop.
1680
1681         The compile loops usually happen like this:
1682         -We speculate you have Int32 despite producing doubles.
1683         -We OSR exit on another node (ValueToInt32 for example) from the result of this ArithMul.
1684         -When we compile this block again, ArithMul will do the same misprediction
1685          because it unconditionally predicts Int32.
1686
1687         The flag NonNegZeroDouble was very unlikely to be set correctly
1688         in the first place.
1689
1690         In LLINT, the flag is only set on the slow path.
1691         Since double*double is on the fast path, those cases are ignored.
1692
1693         In Baseline, the flag is set for any case that falls back on double
1694         multiplication. BUT, the DFG flag was only set for nodes that spend
1695         many iteration in slow path, which obviously does not apply to double*double.
1696
1697         Given the perf drawbacks and the recompile loops, I removed
1698         the whole flag for now.
1699
1700         * bytecode/ValueProfile.cpp:
1701         (WTF::printInternal):
1702         * bytecode/ValueProfile.h:
1703         (JSC::ResultProfile::didObserveNonInt32): Deleted.
1704         (JSC::ResultProfile::didObserveDouble): Deleted.
1705         (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
1706         (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
1707         * dfg/DFGByteCodeParser.cpp:
1708         (JSC::DFG::ByteCodeParser::makeSafe): Deleted.
1709         * dfg/DFGNode.h:
1710         (JSC::DFG::Node::mayHaveNonIntResult): Deleted.
1711         * dfg/DFGNodeFlags.cpp:
1712         (JSC::DFG::dumpNodeFlags): Deleted.
1713         * dfg/DFGNodeFlags.h:
1714         * dfg/DFGPredictionPropagationPhase.cpp:
1715         * jit/JITMulGenerator.cpp:
1716         (JSC::JITMulGenerator::generateFastPath): Deleted.
1717         * runtime/CommonSlowPaths.cpp:
1718         (JSC::updateResultProfileForBinaryArithOp): Deleted.
1719
1720 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1721
1722         REGRESSION(r200422): Web Inspector: Make new Array Iterator objects play nice with Web Inspector
1723         https://bugs.webkit.org/show_bug.cgi?id=157361
1724         <rdar://problem/26099793>
1725
1726         Reviewed by Timothy Hatcher.
1727
1728         * builtins/ArrayPrototype.js:
1729         (createArrayIterator):
1730         (values):
1731         (keys):
1732         (entries):
1733         * builtins/TypedArrayPrototype.js:
1734         (values):
1735         (keys):
1736         (entries):
1737         * runtime/CommonIdentifiers.h:
1738         Set the kind on the iterator object, that can be shown
1739         to the inspector if the object is shown in the console.
1740
1741         * inspector/InjectedScriptSource.js:
1742         (InjectedScript.prototype._describe):
1743         Get a better name for the new Array Iterator which is just an Object.
1744
1745         * inspector/JSInjectedScriptHost.cpp:
1746         (Inspector::JSInjectedScriptHost::subtype):
1747         (Inspector::JSInjectedScriptHost::getInternalProperties):
1748         Detect and handle ArrayIterator object instances. Porting the code
1749         from the JSArrayIterator code path.
1750
1751 2016-05-05  Benjamin Poulain  <bpoulain@apple.com>
1752
1753         [JSC] In DFG, an OSR Exit on SetLocal can trash its child node
1754         https://bugs.webkit.org/show_bug.cgi?id=157358
1755         rdar://problem/25339647
1756
1757         Reviewed by Filip Pizlo.
1758
1759         When we OSR Exit on SetLocal, the child is never restored if its representation
1760         was changed since the MovHint.
1761
1762         For example, say we have:
1763             @1 = SomethingProducingDouble()
1764             @2 = MovHint(@1)
1765             @3 = ValueRep(@1)
1766             @4 = SetLocal(@3, FlushedInt32)
1767
1768         When we lower SetLocal(), we start by speculating that @3 is an Int32.
1769         Now this can fail if @1 was really a double.
1770         When that happens, we go over the VariableEventStream to find where values
1771         are, and @1 died at @3. Since the speculation failure happens before
1772         the SetLocal event, we don't do anything with @3.
1773
1774         In this patch, I extend the PhantomInsertion phase to keep the MovHint
1775         alive past the SetLocal.
1776
1777         * dfg/DFGPhantomInsertionPhase.cpp:
1778         * tests/stress/multiply-typed-double-and-object.js: Added.
1779         (otherObject.valueOf):
1780         (targetDFG.multiply):
1781         (targetFTL.multiply):
1782
1783 2016-05-05  Oliver Hunt  <oliver@apple.com>
1784
1785         Enable separated heap by default on ios
1786         https://bugs.webkit.org/show_bug.cgi?id=156720
1787
1788         Reviewed by Geoffrey Garen.
1789
1790         We've fixed the xnu side of things, so we can reland this.
1791
1792         * runtime/Options.cpp:
1793         (JSC::recomputeDependentOptions):
1794
1795 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1796
1797         JSContext Inspector: Better CommandLineAPI in JSContext inspection
1798         https://bugs.webkit.org/show_bug.cgi?id=157387
1799         <rdar://problem/22630583>
1800
1801         Reviewed by Timothy Hatcher.
1802
1803         * inspector/InjectedScriptSource.js:
1804         (InjectedScript.prototype._evaluateOn):
1805         (BasicCommandLineAPI.inScopeVariables):
1806         (BasicCommandLineAPI):
1807         When creating a BasicCommandLineAPI, pass the call frame so
1808         that we don't shadow variables in the callstack.
1809
1810         (BasicCommandLineAPI.methods):
1811         (clear):
1812         (table):
1813         (profile):
1814         (profileEnd):
1815         (keys):
1816         (values):
1817         Some just pass through to console, others are tiny methods.
1818         Implement them, and give them the expected toString string.
1819
1820 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
1821
1822         Reduce maximum JIT pool size on X86_64.
1823
1824         Rubber stamped by Geoffrey Garen.
1825         
1826         This changes our maximum pool size to 100MB. The problem with letting a page allocate much
1827         more than this is that we will sometimes call deleteAllCode() or one of its friends. Deleting
1828         a huge amount of memory is expensive in our allocator.
1829         
1830         So long as we allow for such large-scale code death to happen, and so long as it's expensive,
1831         we should bound the amount of code we end up with in the first place.
1832         
1833         In the long run, we should fix our executable allocator so that it's not so expensive to kill
1834         all code.
1835         
1836         * jit/ExecutableAllocator.h:
1837
1838 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
1839
1840         Reduce thresholds that control the maximum IC stub size.
1841
1842         Rubber stamped by Chris Dumez and Benjamin Poulain.
1843         
1844         This reduces the thresholds to before the megamorphic load optimizations to see if that
1845         recovers a PLT regression.
1846
1847         * runtime/Options.h:
1848
1849 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
1850
1851         We shouldn't crash if DFG AI proved that something was unreachable on one run but then decided not to prove it on another run
1852         https://bugs.webkit.org/show_bug.cgi?id=157379
1853
1854         Reviewed by Mark Lam.
1855         
1856         Any run of DFG AI is a fixpoint that loosens the proof until it can't find any more
1857         counterexamples to the proof.  It errs on the side of loosening proofs, i.e., on the side of
1858         proving fewer things.
1859
1860         We run this fixpoint multiple times since there are multiple points in the DFG optimization
1861         pipeline when we run DFG AI.  Each of those runs completes a fixpoint and produces the
1862         tightest proof it can that did not result in counterexamples being found.
1863
1864         It's possible that on run K of DFG AI, we prove some property, but on run K+1, we don't prove
1865         that property. The code could have changed between the two runs due to other phases. Other
1866         phases may modify the code in such a way that it's less amenable to AI's analysis. Our design
1867         allows this because DFG AI is not 100% precise. It defends itself from making unsound choices
1868         or running forever by sometimes punting on proving some property. It must be able to do this,
1869         and so therefore, it might sometimes prove fewer things on a later run.
1870
1871         Currently in trunk if the property that AI proves on run K but fails to prove on run K+1 is
1872         the reachability of a piece of code, then run K+1 will crash on an assertion at the
1873         Unreachable node. It will complain that it reached an Unreachable. But it might be reaching
1874         that Unreachable because it failed to prove that something earlier was always exiting. That's
1875         OK, see above.
1876
1877         So, we should remove the assertion that AI doesn't see Unreachable.
1878         
1879         No new tests because I don't know how to make this happen. I believe that this happens in the
1880         wild based on crash logs.
1881
1882         * dfg/DFGAbstractInterpreterInlines.h:
1883         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1884
1885 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1886
1887         Crash if you type "debugger" in the console and continue
1888         https://bugs.webkit.org/show_bug.cgi?id=156924
1889         <rdar://problem/25884189>
1890
1891         Reviewed by Mark Lam.
1892
1893         * inspector/agents/InspectorDebuggerAgent.cpp:
1894         (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
1895         Bail with an error when we are not paused.
1896
1897         * inspector/agents/InspectorRuntimeAgent.cpp:
1898         (Inspector::InspectorRuntimeAgent::callFunctionOn):
1899         (Inspector::InspectorRuntimeAgent::getProperties):
1900         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
1901         (Inspector::InspectorRuntimeAgent::getCollectionEntries):
1902         (Inspector::InspectorRuntimeAgent::saveResult):
1903         Update poor error message.
1904
1905 2016-05-05  Keith Miller  <keith_miller@apple.com>
1906
1907         Add support for delete by value to the DFG
1908         https://bugs.webkit.org/show_bug.cgi?id=157372
1909
1910         Reviewed by Filip Pizlo.
1911
1912         This patch adds basic support for delete by value to the DFG. delete by value
1913         just calls out to a C++ operation on each execution. Additionally, this patch
1914         fixes an issue with delete by id where we would crash if the base was null
1915         or undefined.
1916
1917         * dfg/DFGAbstractInterpreterInlines.h:
1918         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1919         * dfg/DFGByteCodeParser.cpp:
1920         (JSC::DFG::ByteCodeParser::parseBlock):
1921         * dfg/DFGCapabilities.cpp:
1922         (JSC::DFG::capabilityLevel):
1923         * dfg/DFGClobberize.h:
1924         (JSC::DFG::clobberize):
1925         * dfg/DFGDoesGC.cpp:
1926         (JSC::DFG::doesGC):
1927         * dfg/DFGFixupPhase.cpp:
1928         (JSC::DFG::FixupPhase::fixupNode):
1929         * dfg/DFGNodeType.h:
1930         * dfg/DFGPredictionPropagationPhase.cpp:
1931         * dfg/DFGSafeToExecute.h:
1932         (JSC::DFG::safeToExecute):
1933         * dfg/DFGSpeculativeJIT.cpp:
1934         (JSC::DFG::SpeculativeJIT::compileDeleteById):
1935         (JSC::DFG::SpeculativeJIT::compileDeleteByVal):
1936         * dfg/DFGSpeculativeJIT.h:
1937         (JSC::DFG::SpeculativeJIT::callOperation):
1938         * dfg/DFGSpeculativeJIT32_64.cpp:
1939         (JSC::DFG::SpeculativeJIT::compile):
1940         * dfg/DFGSpeculativeJIT64.cpp:
1941         (JSC::DFG::SpeculativeJIT::compile):
1942         * jit/JIT.cpp:
1943         (JSC::JIT::privateCompileMainPass):
1944         * jit/JIT.h:
1945         * jit/JITOperations.cpp:
1946         * jit/JITOperations.h:
1947         * jit/JITPropertyAccess.cpp:
1948         (JSC::JIT::emit_op_del_by_val):
1949         * jit/JITPropertyAccess32_64.cpp:
1950         (JSC::JIT::emit_op_del_by_val):
1951         * tests/stress/delete-by-val.js: Added.
1952         (assert):
1953         (test):
1954         * tests/stress/delete-to-object-exception.js: Added.
1955         (assert):
1956         (test):
1957
1958 2016-05-05  Michael Saboff  <msaboff@apple.com>
1959
1960         Unreviewed build fix after change set r200447.
1961
1962         Made the detection of clang version XCode build specific.
1963         Now shouldEnableDebugAnnotations() should return false for all other build types.
1964
1965         * offlineasm/config.rb:
1966
1967 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1968
1969         Create console object lazily
1970         https://bugs.webkit.org/show_bug.cgi?id=157328
1971
1972         Reviewed by Geoffrey Garen.
1973
1974         * runtime/CommonIdentifiers.h:
1975         * runtime/JSGlobalObject.cpp:
1976         (JSC::createConsoleProperty):
1977         (JSC::JSGlobalObject::init): Deleted.
1978
1979 2016-05-04  Michael Saboff  <msaboff@apple.com>
1980
1981         Enable Dwarf2 debug information in offline assembler for clang compiler
1982         https://bugs.webkit.org/show_bug.cgi?id=157364.
1983
1984         Reviewed by Mark Lam.
1985
1986         Added a new function shouldEnableDebugAnnotations() that determines if
1987         we are using clang and a new enough version to support the debug annotations.
1988
1989         * offlineasm/config.rb:
1990         (shouldEnableDebugAnnotations): Added.
1991
1992 2016-05-04  Keith Miller  <keith_miller@apple.com>
1993
1994         Unreviewed, fix test for new ArrayIteratorPrototype.next() error message.
1995
1996         * tests/stress/array-iterators-next-with-call.js:
1997
1998 2016-05-04  Filip Pizlo  <fpizlo@apple.com>
1999
2000         Speed up JSGlobalObject initialization by making some properties lazy
2001         https://bugs.webkit.org/show_bug.cgi?id=157045
2002
2003         Reviewed by Keith Miller.
2004         
2005         This makes about half of JSGlobalObject's state lazy. There are three categories of
2006         state in JSGlobalObject:
2007         
2008         1) C++ fields in JSGlobalObject.
2009         2) JS object properties in JSGlobalObject's JSObject superclass.
2010         3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
2011         
2012         State held in JS variables cannot yet be made lazy. That's why this patch only goes
2013         half-way.
2014         
2015         State in JS object properties can be made lazy if we move it to the static property
2016         hashtable. JSGlobalObject already had one of those. This patch makes static property
2017         hashtables a lot more powerful, by adding three new kinds of static properties. These
2018         new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
2019         
2020         State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
2021         lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
2022         JSGlobalObject and we are adding more all the time. We don't want to require that each
2023         of these has a getter with an initialization check and a corresponding out-of-line slow
2024         path that does the initialization. We want this kind of boilerplate to be handled by
2025         some abstractions.
2026         
2027         The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
2028         only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
2029         You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
2030         so it's almost a drop-in replacement.
2031         
2032         The key to LazyProperty<Type>'s power is that you can do this:
2033         
2034             class Bar {
2035                 ...
2036                 LazyProperty<Foo> m_foo;
2037             };
2038             ...
2039             m_foo.initLater(
2040                 [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
2041                     init.set(Foo::create(init.vm, init.owner));
2042                 });
2043         
2044         This initLater() call requires that you pass a stateless lambda (see WTF changelog for
2045         the definition). Miraculously, this initLater() call is guaranteed to compile to a store
2046         of a pointer constant to m_foo, as in:
2047         
2048             movabsq 0xBLAH, %rax
2049             movq %rax, &m_foo
2050         
2051         This magical pointer constant points to a callback that was generated by the template
2052         instantiation of initLater(). That callback knows to call your stateless lambda, but
2053         also does some other bookkeeping: it makes sure that you indeed initialized the property
2054         inside the callback and it manages recursive initializations. It's totally legal to call
2055         m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
2056         m_foo.get() will return null. This is an excellent escape hatch if we ever find
2057         ourselves in a dependency cycle. I added this feature because I already had to create a
2058         dependency cycle.
2059         
2060         Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
2061         to get this right. The DFG thread cannot initialize those fields, so it has to make sure
2062         that it does conservative things. But for some nodes this could mean adding a lot of new
2063         logic, like NewTypedArray, which currently is written in such a way that it assumes that
2064         we always have the typed array structure. Currently we take a two-fold approach: for
2065         typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
2066         initialized, and for everything else we don't make the properties lazy if the DFG needs
2067         them. As we optimize this further we might need to teach the DFG to handle more lazy
2068         properties. I tried to do this for RegExp but found it to be very confusing. With typed
2069         arrays I got lucky.
2070         
2071         There is also a somewhat more powerful construct called LazyClassStructure. We often
2072         need to keep around the structure of some standard JS class, like Date. We also need to
2073         make sure that the constructor ends up in the global object's property table. And we
2074         often need to keep the original value of the constructor for ourselves. In this case, we
2075         want to make sure that the creation of the structure-prototype-constructor constellation
2076         is atomic. We don't want code to start looking at the structure if it points to a
2077         prototype that doesn't have its "constructor" property set yet, for example.
2078         LazyClassStructure solves this by abstracting that whole initialization. You provide the
2079         callback that allocates everything, since we are super inconsistent about the way we
2080         initialize things, but LazyClassStructure establishes the workflow and helps you not
2081         mess up.
2082         
2083         Finally, the new static hashtable attributes allow for all of this to work with the JS
2084         property table:
2085         
2086         PropertyCallback: if you use this attribute, the second column in the table should be
2087         the name of a function to call to initialize this property. This is useful for things
2088         like the Math property. The Math object turns out to be very expensive to allocate.
2089         Delaying its allocation is super easy with the PropertyCallback attribute.
2090         
2091         CellProperty: with this attribute the second column should be a C++ field name like
2092         JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
2093         this property, and when it needs to be initialized, Lookup will assume you have a
2094         LazyProperty<JSCell> and call its get() method. It will initialize the property to
2095         whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
2096         LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
2097         call whatever callback function pointer is encoded in the property and it does not need
2098         to know anything about what type that callback will instantiate.
2099         
2100         ClassStructure: with this attribute the second column should be a C++ field name. The
2101         static hashtable will initialize the property by treating the field as a
2102         LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
2103         initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
2104         the property in question will already be set. By convention, we have LazyClassStructure
2105         initialize the property with a pointer to the constructor, since that's how all of our
2106         classes work: "globalObject.Date" points to the DateConstructor.
2107         
2108         This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
2109         calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
2110         
2111         Rolling this back in after fixing the function pointer alignment issue. The last version
2112         relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this,
2113         especially since ARMv7 uses the low bit of function pointers as a tag to indicate the
2114         instruction set. This version adds an extra indirection, so that
2115         LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to
2116         a pointer is guaranteed to be at least 4-byte aligned.
2117
2118         * API/JSCallbackFunction.cpp:
2119         (JSC::JSCallbackFunction::create):
2120         * API/ObjCCallbackFunction.h:
2121         (JSC::ObjCCallbackFunction::impl):
2122         * API/ObjCCallbackFunction.mm:
2123         (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
2124         (JSC::ObjCCallbackFunction::create):
2125         * CMakeLists.txt:
2126         * JavaScriptCore.xcodeproj/project.pbxproj:
2127         * create_hash_table:
2128         * debugger/DebuggerScope.cpp:
2129         (JSC::DebuggerScope::create):
2130         (JSC::DebuggerScope::DebuggerScope):
2131         * debugger/DebuggerScope.h:
2132         (JSC::DebuggerScope::jsScope):
2133         (JSC::DebuggerScope::create): Deleted.
2134         * dfg/DFGAbstractInterpreterInlines.h:
2135         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2136         * dfg/DFGAbstractValue.cpp:
2137         (JSC::DFG::AbstractValue::set):
2138         * dfg/DFGArrayMode.cpp:
2139         (JSC::DFG::ArrayMode::originalArrayStructure):
2140         * dfg/DFGByteCodeParser.cpp:
2141         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
2142         * dfg/DFGSpeculativeJIT.cpp:
2143         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
2144         * dfg/DFGSpeculativeJIT32_64.cpp:
2145         (JSC::DFG::SpeculativeJIT::compile):
2146         * dfg/DFGSpeculativeJIT64.cpp:
2147         (JSC::DFG::SpeculativeJIT::compile):
2148         * dfg/DFGStructureRegistrationPhase.cpp:
2149         (JSC::DFG::StructureRegistrationPhase::run):
2150         * ftl/FTLLowerDFGToB3.cpp:
2151         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2152         * runtime/ClonedArguments.cpp:
2153         (JSC::ClonedArguments::getOwnPropertySlot):
2154         (JSC::ClonedArguments::materializeSpecials):
2155         * runtime/CommonSlowPaths.cpp:
2156         (JSC::SLOW_PATH_DECL):
2157         * runtime/FunctionPrototype.cpp:
2158         (JSC::functionProtoFuncToString):
2159         * runtime/InternalFunction.cpp:
2160         (JSC::InternalFunction::visitChildren):
2161         (JSC::InternalFunction::name):
2162         (JSC::InternalFunction::calculatedDisplayName):
2163         (JSC::InternalFunction::createSubclassStructure):
2164         * runtime/InternalFunction.h:
2165         * runtime/JSBoundFunction.cpp:
2166         (JSC::JSBoundFunction::finishCreation):
2167         (JSC::JSBoundFunction::visitChildren):
2168         * runtime/JSBoundSlotBaseFunction.cpp:
2169         (JSC::JSBoundSlotBaseFunction::create):
2170         * runtime/JSFunction.cpp:
2171         (JSC::retrieveCallerFunction):
2172         (JSC::getThrowTypeErrorGetterSetter):
2173         (JSC::JSFunction::callerGetter):
2174         (JSC::JSFunction::getOwnPropertySlot):
2175         (JSC::JSFunction::defineOwnProperty):
2176         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2177         (JSC::constructGenericTypedArrayView):
2178         * runtime/JSGlobalObject.cpp:
2179         (JSC::createProxyProperty):
2180         (JSC::createJSONProperty):
2181         (JSC::createMathProperty):
2182         (JSC::JSGlobalObject::init):
2183         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
2184         (JSC::JSGlobalObject::resetPrototype):
2185         (JSC::JSGlobalObject::visitChildren):
2186         (JSC::JSGlobalObject::toThis):
2187         (JSC::JSGlobalObject::getOwnPropertySlot):
2188         (JSC::JSGlobalObject::createThrowTypeError): Deleted.
2189         (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted.
2190         * runtime/JSGlobalObject.h:
2191         (JSC::JSGlobalObject::objectConstructor):
2192         (JSC::JSGlobalObject::promiseConstructor):
2193         (JSC::JSGlobalObject::internalPromiseConstructor):
2194         (JSC::JSGlobalObject::evalErrorConstructor):
2195         (JSC::JSGlobalObject::rangeErrorConstructor):
2196         (JSC::JSGlobalObject::referenceErrorConstructor):
2197         (JSC::JSGlobalObject::syntaxErrorConstructor):
2198         (JSC::JSGlobalObject::typeErrorConstructor):
2199         (JSC::JSGlobalObject::URIErrorConstructor):
2200         (JSC::JSGlobalObject::nullGetterFunction):
2201         (JSC::JSGlobalObject::nullSetterFunction):
2202         (JSC::JSGlobalObject::callFunction):
2203         (JSC::JSGlobalObject::applyFunction):
2204         (JSC::JSGlobalObject::definePropertyFunction):
2205         (JSC::JSGlobalObject::arrayProtoValuesFunction):
2206         (JSC::JSGlobalObject::initializePromiseFunction):
2207         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
2208         (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
2209         (JSC::JSGlobalObject::regExpProtoExecFunction):
2210         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
2211         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
2212         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
2213         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
2214         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
2215         (JSC::JSGlobalObject::moduleLoader):
2216         (JSC::JSGlobalObject::objectPrototype):
2217         (JSC::JSGlobalObject::functionPrototype):
2218         (JSC::JSGlobalObject::arrayPrototype):
2219         (JSC::JSGlobalObject::booleanPrototype):
2220         (JSC::JSGlobalObject::stringPrototype):
2221         (JSC::JSGlobalObject::symbolPrototype):
2222         (JSC::JSGlobalObject::numberPrototype):
2223         (JSC::JSGlobalObject::datePrototype):
2224         (JSC::JSGlobalObject::regExpPrototype):
2225         (JSC::JSGlobalObject::errorPrototype):
2226         (JSC::JSGlobalObject::iteratorPrototype):
2227         (JSC::JSGlobalObject::generatorFunctionPrototype):
2228         (JSC::JSGlobalObject::generatorPrototype):
2229         (JSC::JSGlobalObject::debuggerScopeStructure):
2230         (JSC::JSGlobalObject::withScopeStructure):
2231         (JSC::JSGlobalObject::strictEvalActivationStructure):
2232         (JSC::JSGlobalObject::activationStructure):
2233         (JSC::JSGlobalObject::moduleEnvironmentStructure):
2234         (JSC::JSGlobalObject::directArgumentsStructure):
2235         (JSC::JSGlobalObject::scopedArgumentsStructure):
2236         (JSC::JSGlobalObject::clonedArgumentsStructure):
2237         (JSC::JSGlobalObject::isOriginalArrayStructure):
2238         (JSC::JSGlobalObject::booleanObjectStructure):
2239         (JSC::JSGlobalObject::callbackConstructorStructure):
2240         (JSC::JSGlobalObject::callbackFunctionStructure):
2241         (JSC::JSGlobalObject::callbackObjectStructure):
2242         (JSC::JSGlobalObject::propertyNameIteratorStructure):
2243         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
2244         (JSC::JSGlobalObject::objcWrapperObjectStructure):
2245         (JSC::JSGlobalObject::dateStructure):
2246         (JSC::JSGlobalObject::nullPrototypeObjectStructure):
2247         (JSC::JSGlobalObject::errorStructure):
2248         (JSC::JSGlobalObject::calleeStructure):
2249         (JSC::JSGlobalObject::functionStructure):
2250         (JSC::JSGlobalObject::boundFunctionStructure):
2251         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
2252         (JSC::JSGlobalObject::getterSetterStructure):
2253         (JSC::JSGlobalObject::nativeStdFunctionStructure):
2254         (JSC::JSGlobalObject::namedFunctionStructure):
2255         (JSC::JSGlobalObject::functionNameOffset):
2256         (JSC::JSGlobalObject::numberObjectStructure):
2257         (JSC::JSGlobalObject::privateNameStructure):
2258         (JSC::JSGlobalObject::mapStructure):
2259         (JSC::JSGlobalObject::regExpStructure):
2260         (JSC::JSGlobalObject::generatorFunctionStructure):
2261         (JSC::JSGlobalObject::setStructure):
2262         (JSC::JSGlobalObject::stringObjectStructure):
2263         (JSC::JSGlobalObject::symbolObjectStructure):
2264         (JSC::JSGlobalObject::iteratorResultObjectStructure):
2265         (JSC::JSGlobalObject::lazyTypedArrayStructure):
2266         (JSC::JSGlobalObject::typedArrayStructure):
2267         (JSC::JSGlobalObject::typedArrayStructureConcurrently):
2268         (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
2269         (JSC::JSGlobalObject::typedArrayConstructor):
2270         (JSC::JSGlobalObject::actualPointerFor):
2271         (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
2272         * runtime/JSNativeStdFunction.cpp:
2273         (JSC::JSNativeStdFunction::create):
2274         * runtime/JSWithScope.cpp:
2275         (JSC::JSWithScope::create):
2276         (JSC::JSWithScope::visitChildren):
2277         (JSC::JSWithScope::createStructure):
2278         (JSC::JSWithScope::JSWithScope):
2279         * runtime/JSWithScope.h:
2280         (JSC::JSWithScope::object):
2281         (JSC::JSWithScope::create): Deleted.
2282         (JSC::JSWithScope::createStructure): Deleted.
2283         (JSC::JSWithScope::JSWithScope): Deleted.
2284         * runtime/LazyClassStructure.cpp: Added.
2285         (JSC::LazyClassStructure::Initializer::Initializer):
2286         (JSC::LazyClassStructure::Initializer::setPrototype):
2287         (JSC::LazyClassStructure::Initializer::setStructure):
2288         (JSC::LazyClassStructure::Initializer::setConstructor):
2289         (JSC::LazyClassStructure::visit):
2290         (JSC::LazyClassStructure::dump):
2291         * runtime/LazyClassStructure.h: Added.
2292         (JSC::LazyClassStructure::LazyClassStructure):
2293         (JSC::LazyClassStructure::get):
2294         (JSC::LazyClassStructure::prototype):
2295         (JSC::LazyClassStructure::constructor):
2296         (JSC::LazyClassStructure::getConcurrently):
2297         (JSC::LazyClassStructure::prototypeConcurrently):
2298         (JSC::LazyClassStructure::constructorConcurrently):
2299         * runtime/LazyClassStructureInlines.h: Added.
2300         (JSC::LazyClassStructure::initLater):
2301         * runtime/LazyProperty.h: Added.
2302         (JSC::LazyProperty::Initializer::Initializer):
2303         (JSC::LazyProperty::LazyProperty):
2304         (JSC::LazyProperty::get):
2305         (JSC::LazyProperty::getConcurrently):
2306         * runtime/LazyPropertyInlines.h: Added.
2307         (JSC::ElementType>::Initializer::set):
2308         (JSC::ElementType>::initLater):
2309         (JSC::ElementType>::setMayBeNull):
2310         (JSC::ElementType>::set):
2311         (JSC::ElementType>::visit):
2312         (JSC::ElementType>::dump):
2313         (JSC::ElementType>::callFunc):
2314         * runtime/Lookup.cpp:
2315         (JSC::setUpStaticFunctionSlot):
2316         * runtime/Lookup.h:
2317         (JSC::HashTableValue::function):
2318         (JSC::HashTableValue::functionLength):
2319         (JSC::HashTableValue::propertyGetter):
2320         (JSC::HashTableValue::propertyPutter):
2321         (JSC::HashTableValue::accessorGetter):
2322         (JSC::HashTableValue::accessorSetter):
2323         (JSC::HashTableValue::constantInteger):
2324         (JSC::HashTableValue::lexerValue):
2325         (JSC::HashTableValue::lazyCellPropertyOffset):
2326         (JSC::HashTableValue::lazyClassStructureOffset):
2327         (JSC::HashTableValue::lazyPropertyCallback):
2328         (JSC::getStaticPropertySlot):
2329         (JSC::getStaticValueSlot):
2330         (JSC::putEntry):
2331         (JSC::reifyStaticProperty):
2332         * runtime/PropertySlot.h:
2333         * runtime/TypedArrayType.h:
2334
2335 2016-05-04  Joseph Pecoraro  <pecoraro@apple.com>
2336
2337         Improve the grammar of some error messages 'a argument list' => 'an argument list'
2338         https://bugs.webkit.org/show_bug.cgi?id=157350
2339         <rdar://problem/26082108>
2340
2341         Reviewed by Mark Lam.
2342
2343         * parser/Parser.cpp:
2344         (JSC::Parser<LexerType>::parseIfStatement):
2345         (JSC::Parser<LexerType>::parseImportDeclaration):
2346         (JSC::Parser<LexerType>::parseExportDeclaration):
2347         (JSC::Parser<LexerType>::parseObjectLiteral):
2348         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
2349         (JSC::Parser<LexerType>::parseArguments):
2350         Use the alternate error message formatter macro which outputs 'an'
2351         instead of 'a' preceding the last argument.
2352
2353 2016-05-04  Keith Miller  <keith_miller@apple.com>
2354
2355         Corrections to r200422
2356         https://bugs.webkit.org/show_bug.cgi?id=157351
2357
2358         Reviewed by Joseph Pecoraro.
2359
2360         Fix some typos in various files. Also, make separate error messages
2361         for the this value being undefined vs null in the ArrayIteratorprototype
2362         next function and add test.
2363
2364         * Scripts/builtins/builtins_model.py:
2365         * builtins/ArrayIteratorPrototype.js:
2366         (next):
2367         (arrayIteratorValueNext):
2368         (arrayIteratorKeyNext):
2369         (arrayIteratorKeyValueNext):
2370         * builtins/ArrayPrototype.js:
2371         (keys):
2372         (entries):
2373         * builtins/TypedArrayPrototype.js:
2374         * runtime/JSGlobalObject.cpp:
2375         (JSC::JSGlobalObject::init): Deleted.
2376         * tests/stress/array-iterators-next-error-messages.js: Added.
2377         (assert):
2378         (catch):
2379
2380 2016-05-04  Keith Miller  <keith_miller@apple.com>
2381
2382         Unreviewed, reland r200149 since the rollout had inconclusive PLT AB testing results.
2383
2384 2016-05-04  Mark Lam  <mark.lam@apple.com>
2385
2386         ES6 Function.name inferred from property names of literal objects can break some websites.
2387         https://bugs.webkit.org/show_bug.cgi?id=157246
2388
2389         Reviewed by Geoffrey Garen.
2390
2391         Specifically, the library mathjs (see http://mathjs.org and https://github.com/josdejong/mathjs)
2392         uses an idiom where it created literal objects with property names that look like
2393         this: 'number | BigNumber | Unit'.  Later, this name is used in a string to create
2394         function source code that gets eval'ed.  Since 'number | BigNumber | Unit' is not
2395         a valid function name, we get a syntax error.
2396
2397         Here are the details:
2398
2399         1. mathjs uses object literals with the funky property names for its function members.
2400            For example, 
2401
2402               // helper function to type check the middle value of the array
2403               var middle = typed({
2404                 'number | BigNumber | Unit': function (value) {
2405                   return value;
2406                 }
2407               });
2408
2409         2. mathjs' getName() uses Function.name to get the name of functions (hence, picks
2410            up the property name as inferred value of Function.name as specified by ES6):
2411
2412                 /**
2413                  * Retrieve the function name from a set of functions, and check
2414                  * whether the name of all functions match (if given)
2415                  ...
2416                  */
2417                 function getName (fns) {
2418                   var name = '';
2419
2420                   for (var i = 0; i < fns.length; i++) {
2421                     var fn = fns[i];
2422                     ...
2423                         name = fn.name;
2424                     ...
2425                   return name;
2426                 }
2427
2428         3. mathjs uses that name to assembler new function source code that gets eval'ed:
2429
2430                 /**
2431                  * Compose a function from sub-functions each handling a single type signature.
2432                  ...
2433                  */
2434                 function _typed(name, signatures) {
2435                   ...
2436                   // generate code for the typed function
2437                   var code = [];
2438                   var _name = name || '';
2439                   ...
2440                   code.push('function ' + _name + '(' + _args.join(', ') + ') {');
2441                   code.push('  "use strict";');
2442                   code.push('  var name = \'' + _name + '\';');
2443                   code.push(node.toCode(refs, '  '));
2444                   code.push('}');
2445
2446                   // generate body for the factory function
2447                   var body = [
2448                     refs.toCode(),
2449                     'return ' + code.join('\n')
2450                   ].join('\n');
2451
2452                   // evaluate the JavaScript code and attach function references
2453                   var factory = (new Function(refs.name, 'createError', body));  // <== Syntax Error here!
2454                   var fn = factory(refs, createError);
2455                   ...
2456                   return fn;
2457                 }
2458
2459         Until mathjs (and any other frameworks that does similar things) and sites that
2460         uses mathjs has been updated to work with ES6, we'll need a compatibility hack to
2461         work around it.
2462
2463         Here's what we'll do:
2464         1. Introduce a needsSiteSpecificQuirks flag in JSGlobalObject.
2465         2. Have WebCore's JSDOMWindowBase set that flag if the browser's
2466            needsSiteSpecificQuirks is enabled in its settings.
2467         3. If needsSiteSpecificQuirks is enabled, have JSFunction::reifyName() check for
2468            ' ' or '|' in the name string it will use to reify the Function.name property.
2469            If those characters exists in the name, we'll replace the name string with a
2470            null string.
2471
2472         * runtime/JSFunction.cpp:
2473         (JSC::JSFunction::reifyName):
2474         * runtime/JSGlobalObject.h:
2475         (JSC::JSGlobalObject::needsSiteSpecificQuirks):
2476         (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
2477         (JSC::JSGlobalObject::setNeedsSiteSpecificQuirks):
2478
2479 2016-05-04  Keith Miller  <keith_miller@apple.com>
2480
2481         Speedup array iterators
2482         https://bugs.webkit.org/show_bug.cgi?id=157315
2483
2484         Reviewed by Michael Saboff.
2485
2486         This patch improves the performance of Array iterators in ES6. There are two main changes
2487         that make things faster. The first is that the value, keys and entries functions have been
2488         moved to JS. This enables us to inline the construction of the iterator. Thus, when we get
2489         to the FTL we are able to sink the allocation of the iterator object. This significantly
2490         improves the performance of any for-of loop since we are now able to have both the iteration
2491         counter and the iterated object in local variables rather than in the heap.
2492
2493         Secondly, instead of using a number to store the iteratation kind we now use a virtual
2494         method on the iteration object to indicate which next function to use. This ends up being
2495         helpful because it means we can eliminate the branches in the old next function that decide
2496         what value to return. With those branches gone the various next functions are now small
2497         enough to inline. Once the next functions are inlined then the FTL is able to sink the
2498         allocation of next() result object. There is still room for optimization in the loop since
2499         we currently don't recognize that the array access in the next function is in bounds or that
2500         the increment to the loop counter cannot overflow.
2501
2502         The overall performance changes appear to be a ~4-6x speedup in a simple microbenchmark that
2503         computes the sum of an array with some extra arithmetic. The variance depends on the exact
2504         body of the loop. Additionally, on a new regress test that changes all the loops in
2505         deltablue into for-of loops this patch is a 1.8x progression. Overall, it still looks like
2506         for-of loops are significantly slower than an indexed for loop. In the first test it's ~2-4x
2507         slower with the difference depending on the body of the loop. If the loop is just the sum
2508         then we see a much larger regression than if the loop does even simple arithmetic. It looks
2509         like the indexed for loop without extra arithmetic is small enough to fit into the x86
2510         replay buffer on my machine, which would explain why there is such a big difference between
2511         the for of loop in that case. On the deltablue benchmark it's 1.4x slower. It's clear from
2512         these numbers that there is still a lot of work we can do to make for of loops faster.
2513
2514         This patch also makes some changes to the way that we decorate our builtin js
2515         functions. Instead of the old syntax (putting the decorated values in [] before the function
2516         declaration i.e. [intrinsic=foo]) this patch changes the syntax to be closer to the way that
2517         decorators are proposed in a future ECMAScript proposal (using @ followed by the entry on a
2518         new line before the function declaration i.e. @intrinsic=foo).
2519
2520         Finally, in the builtin scripts regular expressions re.S has been changed to re.DOTALL since
2521         DOTALL is easier to understand without going to the reference page for python regular
2522         expressions.
2523
2524         * Scripts/builtins/builtins_model.py:
2525         * builtins/ArrayIteratorPrototype.js:
2526         (next):
2527         (arrayIteratorValueNext):
2528         (arrayIteratorKeyNext):
2529         (arrayIteratorKeyValueNext):
2530         * builtins/ArrayPrototype.js:
2531         (createArrayIterator):
2532         (values):
2533         (keys):
2534         (entries):
2535         * builtins/RegExpPrototype.js:
2536         (intrinsic.RegExpTestIntrinsic.test):
2537         * builtins/StringPrototype.js:
2538         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2539         * builtins/TypedArrayPrototype.js:
2540         (values):
2541         (keys):
2542         (entries):
2543         * inspector/JSInjectedScriptHost.cpp:
2544         (Inspector::cloneArrayIteratorObject):
2545         (Inspector::JSInjectedScriptHost::iteratorEntries):
2546         * jit/ThunkGenerators.cpp:
2547         * runtime/ArrayPrototype.cpp:
2548         (JSC::ArrayPrototype::finishCreation):
2549         (JSC::arrayProtoFuncValues): Deleted.
2550         (JSC::arrayProtoFuncEntries): Deleted.
2551         (JSC::arrayProtoFuncKeys): Deleted.
2552         * runtime/CommonIdentifiers.h:
2553         * runtime/JSArrayIterator.cpp:
2554         (JSC::JSArrayIterator::clone): Deleted.
2555         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2556         (JSC::genericTypedArrayViewProtoFuncEntries): Deleted.
2557         (JSC::genericTypedArrayViewProtoFuncKeys): Deleted.
2558         (JSC::typedArrayViewProtoFuncValues): Deleted.
2559         * runtime/JSGlobalObject.cpp:
2560         (JSC::JSGlobalObject::init):
2561         * runtime/JSGlobalObject.h:
2562         * runtime/JSTypedArrayViewPrototype.cpp:
2563         (JSC::JSTypedArrayViewPrototype::finishCreation):
2564         (JSC::typedArrayViewProtoFuncEntries): Deleted.
2565         (JSC::typedArrayViewProtoFuncKeys): Deleted.
2566         (JSC::typedArrayViewProtoFuncValues): Deleted.
2567         * runtime/MapPrototype.cpp:
2568         (JSC::MapPrototype::finishCreation):
2569         * runtime/SetPrototype.cpp:
2570         (JSC::SetPrototype::finishCreation):
2571
2572 2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2573
2574         [JSC] Object constructor need to be aware of new.target
2575         https://bugs.webkit.org/show_bug.cgi?id=157196
2576
2577         Reviewed by Darin Adler.
2578
2579         Object constructor should be aware of new.target.
2580         When the new.target is specified, we should store it.prototype to the newly created
2581         object's [[Prototype]].
2582
2583         * runtime/JSGlobalObject.cpp:
2584         (JSC::JSGlobalObject::init):
2585         (JSC::JSGlobalObject::visitChildren):
2586         Take the design that caches the structure used for empty object.
2587         This structure is also used in constructEmptyObject frequently.
2588
2589         * runtime/JSGlobalObject.h:
2590         (JSC::JSGlobalObject::objectStructureForObjectConstructor):
2591         * runtime/ObjectConstructor.cpp:
2592         (JSC::constructObject):
2593         (JSC::constructWithObjectConstructor):
2594         (JSC::callObjectConstructor):
2595         * runtime/ObjectConstructor.h:
2596         (JSC::constructEmptyObject):
2597         Construct the object by using the plain structure that is also used in the ObjectConstructor.
2598
2599         * tests/stress/object-constructor-should-be-new-target-aware.js: Added.
2600         (shouldBe):
2601         (Hello):
2602
2603 2016-05-04  Chris Dumez  <cdumez@apple.com>
2604
2605         Unreviewed, rolling out r200383 and r200406.
2606
2607         Seems to have caused crashes on iOS / ARMv7s
2608
2609         Reverted changesets:
2610
2611         "Speed up JSGlobalObject initialization by making some
2612         properties lazy"
2613         https://bugs.webkit.org/show_bug.cgi?id=157045
2614         http://trac.webkit.org/changeset/200383
2615
2616         "REGRESSION(r200383): Setting lazily initialized properties
2617         across frame boundaries crashes"
2618         https://bugs.webkit.org/show_bug.cgi?id=157333
2619         http://trac.webkit.org/changeset/200406
2620
2621 2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2622
2623         Assertion failure for super() call in direct eval in method function
2624         https://bugs.webkit.org/show_bug.cgi?id=157091
2625
2626         Reviewed by Darin Adler.
2627
2628         While we ensure that direct super is under the correct context,
2629         we don't check it for the eval code. This patch moves the check from the end of parsing the function
2630         to the places where we found the direct super or the super bindings. This covers the direct eval that
2631         contains the direct super calls.
2632
2633         * parser/Parser.cpp:
2634         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
2635         (JSC::Parser<LexerType>::parseFunctionInfo):
2636         (JSC::Parser<LexerType>::parseMemberExpression):
2637         * parser/Parser.h:
2638         (JSC::Scope::hasDirectSuper):
2639         (JSC::Scope::setHasDirectSuper):
2640         (JSC::Scope::needsSuperBinding):
2641         (JSC::Scope::setNeedsSuperBinding):
2642         (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
2643         * tests/stress/eval-and-super.js: Added.
2644         (shouldBe):
2645         (shouldThrow):
2646         (prototype.m):
2647         (prototype.n):
2648         * tests/stress/generator-and-super.js: Added.
2649         (testSyntaxError):
2650         (testSyntaxError.Base.prototype.hello):
2651         (testSyntaxError.Base.prototype.ok):
2652         (testSyntaxError.Base):
2653         (Hello.prototype.gen):
2654         (Hello):
2655         (testSyntaxError.hello):
2656
2657 2016-05-03  Filip Pizlo  <fpizlo@apple.com>
2658
2659         REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes
2660         https://bugs.webkit.org/show_bug.cgi?id=157333
2661
2662         Reviewed by Benjamin Poulain.
2663         
2664         I forgot to add logic for lazy properties in putEntry(). It turns out that it's easy to
2665         add.
2666
2667         * runtime/Lookup.h:
2668         (JSC::putEntry):
2669         * runtime/PropertySlot.h:
2670
2671 2016-05-03  Filip Pizlo  <fpizlo@apple.com>
2672
2673         References from code to Structures should be stronger than weak
2674         https://bugs.webkit.org/show_bug.cgi?id=157324
2675
2676         Reviewed by Mark Lam.
2677         
2678         If code refers to a Structure and the Structure dies, then previously we'd kill the code. 
2679         This makes sense because the Structure could be the only thing left referring to some global
2680         object or prototype.
2681
2682         But this also causes unnecessary churn. Sometimes there will be a structure that we just
2683         haven't really done anything with recently and so it appears dead. The approach we use
2684         elsewhere in our type inference is that the type that the code uses is general enough to
2685         handle every past execution. Having the GC clear code when some Structure it uses dies means
2686         that we forget that the code used that Structure. We'll either assume that the code is more
2687         monomorphic than it really is (because after GC we patch in some other structure but not the
2688         deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's
2689         crazier than it really is (because we'll remember that there had been some structure that
2690         caused deletion, so we'll assume that deletions might happen in the future, so we'll use a
2691         fully dynamic IC).
2692
2693         This change introduces a more nuanced policy: if it's cheap to mark a dead Structure then we
2694         should mark it just so that all of the code that refers to it remembers that there had been
2695         this exact Structure in the past. If the code often goes through different Structures then
2696         we already have great mechanisms to realize that the code is nutty (namely, the
2697         PolymorphicAccess size limit). But if the code just does this a handful of times then
2698         remembering this old Structure is probably net good:
2699
2700         - It obeys the "handle all past executions" law.
2701         - It preserves the history of the property access, allowing a precise measure of its past
2702           polymorphism.
2703         - It makes the code ready to run fast if the user decides to use that Structure again.
2704           Marking the Structure means it will stay in whatever property transition tables it was in,
2705           so if the program does the same thing it did in the past, it will get this old Structure.
2706
2707         It looks like this is a progression in gbemu and it makes gbemu perform more
2708         deterministically. Also, it seems that this makes JetStream run faster.
2709         
2710         Over five in-browser runs of JetStream, here's what we see before and after:
2711         
2712         Geometric Mean:
2713             Before              After
2714             229.23 +- 8.2523    230.70 +- 12.888
2715             232.91 +- 15.638    239.04 +- 13.766
2716             234.79 +- 12.760    236.32 +- 15.562
2717             236.20 +- 23.125    242.02 +- 3.3865
2718             237.22 +- 2.1929    237.23 +- 17.664
2719         
2720         Just gbemu:
2721             Before              After
2722             541.0 +- 135.8      481.7 +- 143.4
2723             518.9 +- 15.65      508.1 +- 136.3
2724             362.5 +- 0.8884     489.7 +- 101.4
2725             470.7 +- 313.3      530.7 +- 11.49
2726             418.7 +- 180.6      537.2 +- 6.514
2727         
2728         Notice that there is plenty of noise before and after, but the noise is now far less severe.
2729         After this change I did not see any runs like "470.7 +- 313.3" where the size of the 
2730         confidence interval (313.3 * 2) is greater than the score (470.7). Also, notice that the
2731         least noisy run before the change also got a lower score than we ever observed after the
2732         change (36.5 +- 0.8884). The noise, and these occasional very low scores, are due to a
2733         pathology where the GC would reset some stubs at an unfortunate time during profiling,
2734         causing the optimizing compiler to make many poor decisions. That pathology doesn't exist
2735         anymore.
2736         
2737         On the other hand, prior to this change it was possible for gbemu to sometimes run sooooper
2738         fast because the GC would cause the profiler to forget gbemu's behavior on the first tick
2739         and focus only on its behavior in subsequent ticks. So, in steady state, we'd optimize gbemu
2740         for its later behavior rather than a combination of its early behavior and later behavior.
2741         We rarely got lucky this way, so it's not fair to view this quirk as a feature.
2742         
2743         * bytecode/CodeBlock.cpp:
2744         (JSC::CodeBlock::propagateTransitions):
2745         * bytecode/PolymorphicAccess.cpp:
2746         (JSC::AccessCase::visitWeak):
2747         (JSC::AccessCase::propagateTransitions):
2748         (JSC::AccessCase::generateWithGuard):
2749         (JSC::PolymorphicAccess::visitWeak):
2750         (JSC::PolymorphicAccess::propagateTransitions):
2751         (JSC::PolymorphicAccess::dump):
2752         * bytecode/PolymorphicAccess.h:
2753         * bytecode/StructureStubInfo.cpp:
2754         (JSC::StructureStubInfo::visitWeakReferences):
2755         (JSC::StructureStubInfo::propagateTransitions):
2756         (JSC::StructureStubInfo::containsPC):
2757         * bytecode/StructureStubInfo.h:
2758         (JSC::StructureStubInfo::considerCaching):
2759         * runtime/Structure.cpp:
2760         (JSC::Structure::visitChildren):
2761         (JSC::Structure::isCheapDuringGC):
2762         (JSC::Structure::markIfCheap):
2763         (JSC::Structure::prototypeChainMayInterceptStoreTo):
2764         * runtime/Structure.h:
2765
2766 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2767
2768         Web Inspector: Simplify console.clear
2769         https://bugs.webkit.org/show_bug.cgi?id=157316
2770
2771         Reviewed by Timothy Hatcher.
2772
2773         * inspector/ScriptArguments.cpp:
2774         (Inspector::ScriptArguments::createEmpty):
2775         (Inspector::ScriptArguments::ScriptArguments):
2776         * inspector/ScriptArguments.h:
2777         Provide a way to create an empty list.
2778
2779         * runtime/ConsoleClient.cpp:
2780         (JSC::ConsoleClient::clear):
2781         * runtime/ConsoleClient.h:
2782         Drop unnecessary parameter.
2783
2784         * runtime/ConsoleObject.cpp:
2785         (JSC::consoleProtoFuncClear):
2786         No need to parse arguments.
2787
2788 2016-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2789
2790         Improve Symbol() to string coercion error message
2791         https://bugs.webkit.org/show_bug.cgi?id=157317
2792
2793         Reviewed by Geoffrey Garen.
2794
2795         Improve error messages related to Symbols.
2796
2797         * runtime/JSCJSValue.cpp:
2798         (JSC::JSValue::toStringSlowCase):
2799         * runtime/Symbol.cpp:
2800         (JSC::Symbol::toNumber):
2801         * runtime/SymbolConstructor.cpp:
2802         (JSC::symbolConstructorKeyFor):
2803         * runtime/SymbolPrototype.cpp:
2804         (JSC::symbolProtoFuncToString):
2805         (JSC::symbolProtoFuncValueOf):
2806         * tests/stress/dfg-to-primitive-pass-symbol.js:
2807         * tests/stress/floating-point-div-to-mul.js:
2808         (i.catch):
2809         * tests/stress/string-from-code-point.js:
2810         (shouldThrow):
2811         (string_appeared_here.shouldThrow):
2812         * tests/stress/symbol-error-messages.js: Added.
2813         (shouldThrow):
2814         * tests/stress/symbol-registry.js:
2815
2816 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2817
2818         Web Inspector: Give console.time/timeEnd a default label and warnings
2819         https://bugs.webkit.org/show_bug.cgi?id=157325
2820         <rdar://problem/26073290>
2821
2822         Reviewed by Timothy Hatcher.
2823
2824         Provide more user friendly console.time/timeEnd. The timer name
2825         is now optional, and is "default" if not provided. Also provide
2826         warnings when attempting to start an already started timer,
2827         or stop a timer that does not exist.
2828
2829         * inspector/agents/InspectorConsoleAgent.cpp:
2830         (Inspector::InspectorConsoleAgent::startTiming):
2831         (Inspector::InspectorConsoleAgent::stopTiming):
2832         Warnings for bad cases.
2833
2834         * runtime/ConsoleObject.cpp:
2835         (JSC::defaultLabelString):
2836         (JSC::consoleProtoFuncTime):
2837         (JSC::consoleProtoFuncTimeEnd):
2838         Optional label becomes "default".
2839
2840 2016-05-03  Xan Lopez  <xlopez@igalia.com>
2841
2842         Fix the ENABLE(WEBASSEMBLY) build
2843         https://bugs.webkit.org/show_bug.cgi?id=157312
2844
2845         Reviewed by Darin Adler.
2846
2847         * runtime/Executable.cpp:
2848         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
2849         * wasm/WASMFunctionCompiler.h:
2850         (JSC::WASMFunctionCompiler::convertValueToDouble):
2851
2852 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2853
2854         Web Inspector: Remove unused parameter of ScriptArguments::getFirstArgumentAsString
2855         https://bugs.webkit.org/show_bug.cgi?id=157301
2856
2857         Reviewed by Timothy Hatcher.
2858
2859         * inspector/ScriptArguments.cpp:
2860         (Inspector::ScriptArguments::getFirstArgumentAsString):
2861         * inspector/ScriptArguments.h:
2862         Remove unused argument and related code.
2863
2864         * runtime/ConsoleClient.cpp:
2865         (JSC::ConsoleClient::printConsoleMessageWithArguments):
2866         Drive by remove unnecessary cast.
2867
2868 2016-05-03  Michael Saboff  <msaboff@apple.com>
2869
2870         Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
2871         https://bugs.webkit.org/show_bug.cgi?id=157322
2872
2873         Reviewed by Filip Pizlo.
2874
2875         Check to see if the source array has changed length before calling fastSlice().
2876         If it has, take the slow path.
2877
2878         * runtime/ArrayPrototype.cpp:
2879         (JSC::arrayProtoFuncSlice):
2880         (JSC::arrayProtoFuncSplice):
2881         * tests/stress/regress-157322.js: New test.
2882
2883 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2884
2885         Eliminate PassRefPtr conversion from ConsoleObject
2886         https://bugs.webkit.org/show_bug.cgi?id=157300
2887
2888         Reviewed by Timothy Hatcher.
2889
2890         * runtime/ConsoleObject.cpp:
2891         (JSC::consoleLogWithLevel):
2892         (JSC::consoleProtoFuncClear):
2893         (JSC::consoleProtoFuncDir):
2894         (JSC::consoleProtoFuncDirXML):
2895         (JSC::consoleProtoFuncTable):
2896         (JSC::consoleProtoFuncTrace):
2897         (JSC::consoleProtoFuncAssert):
2898         (JSC::consoleProtoFuncCount):
2899         (JSC::consoleProtoFuncTimeStamp):
2900         (JSC::consoleProtoFuncGroup):
2901         (JSC::consoleProtoFuncGroupCollapsed):
2902         (JSC::consoleProtoFuncGroupEnd):
2903         No need to release to a PassRefPtr, we can just move into the RefPtr<>&&.
2904
2905 2016-05-01  Filip Pizlo  <fpizlo@apple.com>
2906
2907         Speed up JSGlobalObject initialization by making some properties lazy
2908         https://bugs.webkit.org/show_bug.cgi?id=157045
2909
2910         Reviewed by Keith Miller.
2911         
2912         This makes about half of JSGlobalObject's state lazy. There are three categories of
2913         state in JSGlobalObject:
2914         
2915         1) C++ fields in JSGlobalObject.
2916         2) JS object properties in JSGlobalObject's JSObject superclass.
2917         3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
2918         
2919         State held in JS variables cannot yet be made lazy. That's why this patch only goes
2920         half-way.
2921         
2922         State in JS object properties can be made lazy if we move it to the static property
2923         hashtable. JSGlobalObject already had one of those. This patch makes static property
2924         hashtables a lot more powerful, by adding three new kinds of static properties. These
2925         new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
2926         
2927         State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
2928         lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
2929         JSGlobalObject and we are adding more all the time. We don't want to require that each
2930         of these has a getter with an initialization check and a corresponding out-of-line slow
2931         path that does the initialization. We want this kind of boilerplate to be handled by
2932         some abstractions.
2933         
2934         The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
2935         only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
2936         You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
2937         so it's almost a drop-in replacement.
2938         
2939         The key to LazyProperty<Type>'s power is that you can do this:
2940         
2941             class Bar {
2942                 ...
2943                 LazyProperty<Foo> m_foo;
2944             };
2945             ...
2946             m_foo.initLater(
2947                 [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
2948                     init.set(Foo::create(init.vm, init.owner));
2949                 });
2950         
2951         This initLater() call requires that you pass a stateless lambda (see WTF changelog for
2952         the definition). Miraculously, this initLater() call is guaranteed to compile to a store
2953         of a pointer constant to m_foo, as in:
2954         
2955             movabsq 0xBLAH, %rax
2956             movq %rax, &m_foo
2957         
2958         This magical pointer constant points to a callback that was generated by the template
2959         instantiation of initLater(). That callback knows to call your stateless lambda, but
2960         also does some other bookkeeping: it makes sure that you indeed initialized the property
2961         inside the callback and it manages recursive initializations. It's totally legal to call
2962         m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
2963         m_foo.get() will return null. This is an excellent escape hatch if we ever find
2964         ourselves in a dependency cycle. I added this feature because I already had to create a
2965         dependency cycle.
2966         
2967         Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
2968         to get this right. The DFG thread cannot initialize those fields, so it has to make sure
2969         that it does conservative things. But for some nodes this could mean adding a lot of new
2970         logic, like NewTypedArray, which currently is written in such a way that it assumes that
2971         we always have the typed array structure. Currently we take a two-fold approach: for
2972         typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
2973         initialized, and for everything else we don't make the properties lazy if the DFG needs
2974         them. As we optimize this further we might need to teach the DFG to handle more lazy
2975         properties. I tried to do this for RegExp but found it to be very confusing. With typed
2976         arrays I got lucky.
2977         
2978         There is also a somewhat more powerful construct called LazyClassStructure. We often
2979         need to keep around the structure of some standard JS class, like Date. We also need to
2980         make sure that the constructor ends up in the global object's property table. And we
2981         often need to keep the original value of the constructor for ourselves. In this case, we
2982         want to make sure that the creation of the structure-prototype-constructor constellation
2983         is atomic. We don't want code to start looking at the structure if it points to a
2984         prototype that doesn't have its "constructor" property set yet, for example.
2985         LazyClassStructure solves this by abstracting that whole initialization. You provide the
2986         callback that allocates everything, since we are super inconsistent about the way we
2987         initialize things, but LazyClassStructure establishes the workflow and helps you not
2988         mess up.
2989         
2990         Finally, the new static hashtable attributes allow for all of this to work with the JS
2991         property table:
2992         
2993         PropertyCallback: if you use this attribute, the second column in the table should be
2994         the name of a function to call to initialize this property. This is useful for things
2995         like the Math property. The Math object turns out to be very expensive to allocate.
2996         Delaying its allocation is super easy with the PropertyCallback attribute.
2997         
2998         CellProperty: with this attribute the second column should be a C++ field name like
2999         JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
3000         this property, and when it needs to be initialized, Lookup will assume you have a
3001         LazyProperty<JSCell> and call its get() method. It will initialize the property to
3002         whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
3003         LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
3004         call whatever callback function pointer is encoded in the property and it does not need
3005         to know anything about what type that callback will instantiate.
3006         
3007         ClassStructure: with this attribute the second column should be a C++ field name. The
3008         static hashtable will initialize the property by treating the field as a
3009         LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
3010         initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
3011         the property in question will already be set. By convention, we have LazyClassStructure
3012         initialize the property with a pointer to the constructor, since that's how all of our
3013         classes work: "globalObject.Date" points to the DateConstructor.
3014         
3015         This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
3016         calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
3017
3018         * API/JSCallbackFunction.cpp:
3019         (JSC::JSCallbackFunction::create):
3020         * API/ObjCCallbackFunction.h:
3021         (JSC::ObjCCallbackFunction::impl):
3022         * API/ObjCCallbackFunction.mm:
3023         (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
3024         (JSC::ObjCCallbackFunction::create):
3025         * CMakeLists.txt:
3026         * JavaScriptCore.xcodeproj/project.pbxproj:
3027         * create_hash_table:
3028         * dfg/DFGAbstractInterpreterInlines.h:
3029         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3030         * dfg/DFGAbstractValue.cpp:
3031         (JSC::DFG::AbstractValue::set):
3032         * dfg/DFGArrayMode.cpp:
3033         (JSC::DFG::ArrayMode::originalArrayStructure):
3034         * dfg/DFGByteCodeParser.cpp:
3035         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
3036         * dfg/DFGSpeculativeJIT.cpp:
3037         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
3038         * dfg/DFGSpeculativeJIT32_64.cpp:
3039         (JSC::DFG::SpeculativeJIT::compile):
3040         * dfg/DFGSpeculativeJIT64.cpp:
3041         (JSC::DFG::SpeculativeJIT::compile):
3042         * dfg/DFGStructureRegistrationPhase.cpp:
3043         (JSC::DFG::StructureRegistrationPhase::run):
3044         * ftl/FTLLowerDFGToB3.cpp:
3045         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
3046         * runtime/ClonedArguments.cpp:
3047         (JSC::ClonedArguments::getOwnPropertySlot):
3048         (JSC::ClonedArguments::materializeSpecials):
3049         * runtime/CommonSlowPaths.cpp:
3050         (JSC::SLOW_PATH_DECL):
3051         * runtime/FunctionPrototype.cpp:
3052         (JSC::functionProtoFuncToString):
3053         * runtime/InternalFunction.cpp:
3054         (JSC::InternalFunction::visitChildren):
3055         (JSC::InternalFunction::name):
3056         (JSC::InternalFunction::calculatedDisplayName):
3057         (JSC::InternalFunction::createSubclassStructure):
3058         * runtime/InternalFunction.h:
3059         * runtime/JSBoundFunction.cpp:
3060         (JSC::JSBoundFunction::finishCreation):
3061         (JSC::JSBoundFunction::visitChildren):
3062         * runtime/JSFunction.cpp:
3063         (JSC::JSFunction::getOwnPropertySlot):
3064         (JSC::JSFunction::defineOwnProperty):
3065         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3066         (JSC::constructGenericTypedArrayView):
3067         * runtime/JSGlobalObject.cpp:
3068         (JSC::createProxyProperty):
3069         (JSC::createJSONProperty):
3070         (JSC::createMathProperty):
3071         (JSC::JSGlobalObject::init):
3072         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
3073         (JSC::JSGlobalObject::resetPrototype):
3074         (JSC::JSGlobalObject::visitChildren):
3075         (JSC::JSGlobalObject::toThis):
3076         (JSC::JSGlobalObject::getOwnPropertySlot):
3077         (JSC::JSGlobalObject::createThrowTypeError): Deleted.
3078         * runtime/JSGlobalObject.h:
3079         (JSC::JSGlobalObject::objectConstructor):
3080         (JSC::JSGlobalObject::promiseConstructor):
3081         (JSC::JSGlobalObject::internalPromiseConstructor):
3082         (JSC::JSGlobalObject::evalErrorConstructor):
3083         (JSC::JSGlobalObject::rangeErrorConstructor):
3084         (JSC::JSGlobalObject::referenceErrorConstructor):
3085         (JSC::JSGlobalObject::syntaxErrorConstructor):
3086         (JSC::JSGlobalObject::typeErrorConstructor):
3087         (JSC::JSGlobalObject::URIErrorConstructor):
3088         (JSC::JSGlobalObject::nullGetterFunction):
3089         (JSC::JSGlobalObject::nullSetterFunction):
3090         (JSC::JSGlobalObject::callFunction):
3091         (JSC::JSGlobalObject::applyFunction):
3092         (JSC::JSGlobalObject::definePropertyFunction):
3093         (JSC::JSGlobalObject::arrayProtoValuesFunction):
3094         (JSC::JSGlobalObject::initializePromiseFunction):
3095         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
3096         (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
3097         (JSC::JSGlobalObject::regExpProtoExecFunction):
3098         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
3099         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
3100         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
3101         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
3102         (JSC::JSGlobalObject::moduleLoader):
3103         (JSC::JSGlobalObject::objectPrototype):
3104         (JSC::JSGlobalObject::functionPrototype):
3105         (JSC::JSGlobalObject::arrayPrototype):
3106         (JSC::JSGlobalObject::booleanPrototype):
3107         (JSC::JSGlobalObject::stringPrototype):
3108         (JSC::JSGlobalObject::symbolPrototype):
3109         (JSC::JSGlobalObject::numberPrototype):
3110         (JSC::JSGlobalObject::datePrototype):
3111         (JSC::JSGlobalObject::regExpPrototype):
3112         (JSC::JSGlobalObject::errorPrototype):
3113         (JSC::JSGlobalObject::iteratorPrototype):
3114         (JSC::JSGlobalObject::generatorFunctionPrototype):
3115         (JSC::JSGlobalObject::generatorPrototype):
3116         (JSC::JSGlobalObject::debuggerScopeStructure):
3117         (JSC::JSGlobalObject::withScopeStructure):
3118         (JSC::JSGlobalObject::strictEvalActivationStructure):
3119         (JSC::JSGlobalObject::activationStructure):
3120         (JSC::JSGlobalObject::moduleEnvironmentStructure):
3121         (JSC::JSGlobalObject::directArgumentsStructure):
3122         (JSC::JSGlobalObject::scopedArgumentsStructure):
3123         (JSC::JSGlobalObject::clonedArgumentsStructure):
3124         (JSC::JSGlobalObject::isOriginalArrayStructure):
3125         (JSC::JSGlobalObject::booleanObjectStructure):
3126         (JSC::JSGlobalObject::callbackConstructorStructure):
3127         (JSC::JSGlobalObject::callbackFunctionStructure):
3128         (JSC::JSGlobalObject::callbackObjectStructure):
3129         (JSC::JSGlobalObject::propertyNameIteratorStructure):
3130         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
3131         (JSC::JSGlobalObject::objcWrapperObjectStructure):
3132         (JSC::JSGlobalObject::dateStructure):
3133         (JSC::JSGlobalObject::nullPrototypeObjectStructure):
3134         (JSC::JSGlobalObject::errorStructure):
3135         (JSC::JSGlobalObject::calleeStructure):
3136         (JSC::JSGlobalObject::functionStructure):
3137         (JSC::JSGlobalObject::boundFunctionStructure):
3138         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
3139         (JSC::JSGlobalObject::getterSetterStructure):
3140         (JSC::JSGlobalObject::nativeStdFunctionStructure):
3141         (JSC::JSGlobalObject::namedFunctionStructure):
3142         (JSC::JSGlobalObject::functionNameOffset):
3143         (JSC::JSGlobalObject::numberObjectStructure):
3144         (JSC::JSGlobalObject::privateNameStructure):
3145         (JSC::JSGlobalObject::mapStructure):
3146         (JSC::JSGlobalObject::regExpStructure):
3147         (JSC::JSGlobalObject::generatorFunctionStructure):
3148         (JSC::JSGlobalObject::setStructure):
3149         (JSC::JSGlobalObject::stringObjectStructure):
3150         (JSC::JSGlobalObject::symbolObjectStructure):
3151         (JSC::JSGlobalObject::iteratorResultObjectStructure):
3152         (JSC::JSGlobalObject::lazyTypedArrayStructure):
3153         (JSC::JSGlobalObject::typedArrayStructure):
3154         (JSC::JSGlobalObject::typedArrayStructureConcurrently):
3155         (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
3156         (JSC::JSGlobalObject::typedArrayConstructor):
3157         (JSC::JSGlobalObject::actualPointerFor):
3158         (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
3159         * runtime/JSNativeStdFunction.cpp:
3160         (JSC::JSNativeStdFunction::create):
3161         * runtime/JSWithScope.cpp:
3162         (JSC::JSWithScope::create):
3163         (JSC::JSWithScope::visitChildren):
3164         (JSC::JSWithScope::createStructure):
3165         (JSC::JSWithScope::JSWithScope):
3166         * runtime/JSWithScope.h:
3167         (JSC::JSWithScope::object):
3168         (JSC::JSWithScope::create): Deleted.
3169         (JSC::JSWithScope::createStructure): Deleted.
3170         (JSC::JSWithScope::JSWithScope): Deleted.
3171         * runtime/LazyClassStructure.cpp: Added.
3172         (JSC::LazyClassStructure::Initializer::Initializer):
3173         (JSC::LazyClassStructure::Initializer::setPrototype):
3174         (JSC::LazyClassStructure::Initializer::setStructure):
3175         (JSC::LazyClassStructure::Initializer::setConstructor):
3176         (JSC::LazyClassStructure::visit):
3177         (JSC::LazyClassStructure::dump):
3178         * runtime/LazyClassStructure.h: Added.
3179         (JSC::LazyClassStructure::LazyClassStructure):
3180         (JSC::LazyClassStructure::get):
3181         (JSC::LazyClassStructure::prototype):
3182         (JSC::LazyClassStructure::constructor):
3183         (JSC::LazyClassStructure::getConcurrently):
3184         (JSC::LazyClassStructure::prototypeConcurrently):
3185         (JSC::LazyClassStructure::constructorConcurrently):
3186         * runtime/LazyClassStructureInlines.h: Added.
3187         (JSC::LazyClassStructure::initLater):
3188         * runtime/LazyProperty.h: Added.
3189         (JSC::LazyProperty::Initializer::Initializer):
3190         (JSC::LazyProperty::LazyProperty):
3191         (JSC::LazyProperty::get):
3192         (JSC::LazyProperty::getConcurrently):
3193         * runtime/LazyPropertyInlines.h: Added.
3194         (JSC::LazyProperty<ElementType>::Initializer<OwnerType>::set):
3195         (JSC::LazyProperty<ElementType>::initLater):
3196         (JSC::LazyProperty<ElementType>::setMayBeNull):
3197         (JSC::LazyProperty<ElementType>::set):
3198         (JSC::LazyProperty<ElementType>::visit):
3199         (JSC::LazyProperty<ElementType>::dump):
3200         (JSC::LazyProperty<ElementType>::callFunc):
3201         * runtime/Lookup.cpp:
3202         (JSC::setUpStaticFunctionSlot):
3203         * runtime/Lookup.h:
3204         (JSC::HashTableValue::function):
3205         (JSC::HashTableValue::functionLength):
3206         (JSC::HashTableValue::propertyGetter):
3207         (JSC::HashTableValue::propertyPutter):
3208         (JSC::HashTableValue::accessorGetter):
3209         (JSC::HashTableValue::accessorSetter):
3210         (JSC::HashTableValue::constantInteger):
3211         (JSC::HashTableValue::lexerValue):
3212         (JSC::HashTableValue::lazyCellPropertyOffset):
3213         (JSC::HashTableValue::lazyClassStructureOffset):
3214         (JSC::HashTableValue::lazyPropertyCallback):
3215         (JSC::getStaticPropertySlot):
3216         (JSC::getStaticValueSlot):
3217         (JSC::reifyStaticProperty):
3218         * runtime/PropertySlot.h:
3219         * runtime/TypedArrayType.h:
3220
3221 2016-05-03  Per Arne Vollan  <peavo@outlook.com>
3222
3223         [Win] Remove Windows XP Compatibility Requirements
3224         https://bugs.webkit.org/show_bug.cgi?id=152899
3225
3226         Reviewed by Brent Fulgham.
3227
3228         Windows XP is not supported anymore, we can remove workarounds.
3229
3230         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
3231         (enableTerminationOnHeapCorruption):
3232
3233 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
3234
3235         Web Inspector: console.assert should do far less work when the assertion is true
3236         https://bugs.webkit.org/show_bug.cgi?id=157297
3237         <rdar://problem/26056556>
3238
3239         Reviewed by Timothy Hatcher.
3240
3241         * runtime/ConsoleClient.h:
3242         * runtime/ConsoleClient.cpp:
3243         (JSC::ConsoleClient::assertion):
3244         (JSC::ConsoleClient::assertCondition): Deleted.
3245         Rename, now that this will only get called when the assertion failed.
3246
3247         * runtime/ConsoleObject.cpp:
3248         (JSC::consoleProtoFuncAssert):
3249         Avoid doing any work if the assertion succeeded.
3250
3251 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
3252
3253         Unreviewed follow-up testapi fix after r200355.
3254
3255         * runtime/JSGlobalObject.cpp:
3256         (JSC::JSGlobalObject::init):
3257         Revert back to non-enumerable. This matches our older behavior,
3258         we can decide to make this Enumerable later if needed.
3259
3260 2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>
3261
3262         Web Inspector: Reflect.toString() should be [object Object] not [object Reflect]
3263         https://bugs.webkit.org/show_bug.cgi?id=157288
3264
3265         Reviewed by Darin Adler.
3266
3267         * runtime/ReflectObject.cpp:
3268         * tests/stress/reflect.js: Added.
3269
3270 2016-05-02  Jon Davis  <jond@apple.com>
3271
3272         Add Resource Timing entry to the Feature Status page.
3273         https://bugs.webkit.org/show_bug.cgi?id=157285
3274
3275         Reviewed by Timothy Hatcher.
3276
3277         * features.json:
3278
3279 2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>
3280
3281         Make console a namespace object (like Math/JSON), allowing functions to be called unbound
3282         https://bugs.webkit.org/show_bug.cgi?id=157286
3283         <rdar://problem/26052830>
3284
3285         Reviewed by Timothy Hatcher.
3286
3287         This changes `console` to be a global namespace object, like `Math` and `JSON`.
3288         It just holds a bunch of functions, that can be used on their own, unbound.
3289         For example, `[1,2,3].forEach(console.log)` and `var log = console.log; log(1)`
3290         used to throw exceptions and now do not.
3291
3292         Previously console was an Object/Prototype pair, so functions were on
3293         ConsolePrototype (console.__proto__.log) and they needed to be called
3294         Console objects as the `this` value. Now, `console` is just a standard
3295         object with a bunch of functions. Since there is no console prototype the
3296         functions can be passed around and called as expected and they will
3297         just do the right thing.
3298
3299         For compatability with other browsers, `console` was made enumerable
3300         on the global object.