2015-10-27 Matthew Hanson Merge r191395. rdar://problem/22847057 2015-10-21 Filip Pizlo Failures in PutStackSinkingPhase should be less severe https://bugs.webkit.org/show_bug.cgi?id=150400 Reviewed by Geoffrey Garen. Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase. * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests. (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled. * runtime/Options.h: Add an option for disabling PutStackSinkingPhase. 2015-10-27 Matthew Hanson Merge r187510. rdar://problem/22847057 2015-07-28 Filip Pizlo DFG::PutStackSinkingPhase should be more aggressive about its "no GetStack until put" rule https://bugs.webkit.org/show_bug.cgi?id=147371 Reviewed by Mark Lam. Two fixes: - Make ConflictingFlush really mean that you can't load from the stack slot. This means not using ConflictingFlush for arguments. - Assert that a GetStack never sees ConflictingFlush. * dfg/DFGPutStackSinkingPhase.cpp: 2015-10-26 Matthew Hanson Merge r191530. rdar://problem/23206864 2015-10-23 Michael Saboff REGRESSION (r179357-r179359): WebContent Crash using AOL Mail @ com.apple.JavascriptCore JSC::linkPolymorphicCall(JSC::ExecState*, JSC::CallLinkInfo&, JSC::CallVariant, JSC::RegisterPreservationMode) + 1584 https://bugs.webkit.org/show_bug.cgi?id=150513 Reviewed by Saam Barati. Add check in linkPolymorphicCall() to make sure we have a CodeBlock for the newly added variant. If not, we turn the call into a virtual call. The bug was caused by a stack overflow when preparing the function for execution. This properly threw an exception, however linkPolymorphicCall() didn't check for this error case. Added a new test function "failNextNewCodeBlock()" to test tools to simplify the testing. * API/JSCTestRunnerUtils.cpp: (JSC::failNextNewCodeBlock): (JSC::numberOfDFGCompiles): * API/JSCTestRunnerUtils.h: * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * jsc.cpp: (GlobalObject::finishCreation): (functionTransferArrayBuffer): (functionFailNextNewCodeBlock): (functionQuit): * runtime/Executable.cpp: (JSC::ScriptExecutable::prepareForExecutionImpl): * runtime/TestRunnerUtils.cpp: (JSC::optimizeNextInvocation): (JSC::failNextNewCodeBlock): (JSC::numberOfDFGCompiles): * runtime/TestRunnerUtils.h: * runtime/VM.h: (JSC::VM::setFailNextNewCodeBlock): (JSC::VM::getAndClearFailNextNewCodeBlock): (JSC::VM::stackPointerAtVMEntry): 2015-10-22 Matthew Hanson Rollout r191395. rdar://problem/22847057 2015-10-21 Filip Pizlo Failures in PutStackSinkingPhase should be less severe https://bugs.webkit.org/show_bug.cgi?id=150400 Reviewed by Geoffrey Garen. Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase. * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests. (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled. * runtime/Options.h: Add an option for disabling PutStackSinkingPhase. 2015-10-22 Matthew Hanson Merge r191395. rdar://problem/22847057 2015-10-21 Filip Pizlo Failures in PutStackSinkingPhase should be less severe https://bugs.webkit.org/show_bug.cgi?id=150400 Reviewed by Geoffrey Garen. Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase. * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests. (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled. * runtime/Options.h: Add an option for disabling PutStackSinkingPhase. 2015-10-22 Matthew Hanson Merge r191364. rdar://problem/22862879 2015-10-20 Mark Lam YarrPatternConstructor::containsCapturingTerms() should not assume that its terms.size() is greater than 0. https://bugs.webkit.org/show_bug.cgi?id=150372 Reviewed by Geoffrey Garen. * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor): (JSC::Yarr::YarrPatternConstructor::optimizeBOL): (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms): (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions): 2015-10-13 Matthew Hanson Merge r189834. rdar://problem/22801966 2015-09-15 Joseph Pecoraro Web Inspector: Paused Debugger prevents page reload https://bugs.webkit.org/show_bug.cgi?id=148174 Reviewed by Brian Burg. * debugger/Debugger.h: (JSC::Debugger::suppressAllPauses): (JSC::Debugger::setSuppressAllPauses): * debugger/Debugger.cpp: (JSC::Debugger::Debugger): (JSC::Debugger::pauseIfNeeded): * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::setSuppressAllPauses): Provide a way to suppress pauses. 2015-10-08 Lucas Forschler Merge r189454. rdar://problem/22802036 2015-09-06 Mark Lam StackOverflow stack unwinding should stop at native frames. https://bugs.webkit.org/show_bug.cgi?id=148749 Reviewed by Michael Saboff. In the present code, after ping-pong'ing back and forth between native and JS code a few times, if we have a stack overflow on re-entry into the VM to run JS code's whose stack frame would overflow the JS stack, the code will end up unwinding past the native function that is making the call to re-enter the VM. As a result, any clean up code (e.g. destructors for stack variables) in the skipped native function frame (and its chain of native function callers) will not be called. This patch is based on the Michael Saboff's fix of this issue landed on the jsc-tailcall branch: http://trac.webkit.org/changeset/188555 We now check for the case where there are no JS frames to unwind since the last native frame, and treat the exception as an unhandled exception. The native function is responsible for further propagating the exception if needed. Other supporting work: 1. Remove vm->vmEntryFrameForThrow. It should always be the same as vm->topVMEntryFrame. 2. Change operationThrowStackOverflowError() to use the throwStackOverflowError() helper function instead of rolling its own. 3. Added a test that exercises this edge case. The test should not hang or crash. * API/tests/PingPongStackOverflowTest.cpp: Added. (PingPongStackOverflowObject_hasInstance): (testPingPongStackOverflow): * API/tests/PingPongStackOverflowTest.h: Added. * API/tests/testapi.c: (main): * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CallFrame.h: (JSC::ExecState::operator=): (JSC::ExecState::callerFrame): (JSC::ExecState::callerFrameOrVMEntryFrame): (JSC::ExecState::argIndexForRegister): (JSC::ExecState::callerFrameAndPC): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::UnwindFunctor): (JSC::UnwindFunctor::operator()): (JSC::Interpreter::unwind): * interpreter/Interpreter.h: (JSC::NativeCallFrameTracer::NativeCallFrameTracer): (JSC::Interpreter::sampler): * jit/CCallHelpers.h: (JSC::CCallHelpers::jumpToExceptionHandler): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITExceptions.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/VM.h: (JSC::VM::exceptionOffset): (JSC::VM::callFrameForThrowOffset): (JSC::VM::vmEntryFrameForThrowOffset): Deleted. (JSC::VM::topVMEntryFrameOffset): Deleted. 2015-10-02 Matthew Hanson Merge r189460. rdar://problem/22802036 2015-09-06 Mark Lam Gardening: fix broken Windows build after r189454. Not reviewed. * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: 2015-09-03 Babak Shafiei Merge r189046. 2015-08-27 Basile Clement REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h https://bugs.webkit.org/show_bug.cgi?id=148411 Reviewed by Geoffrey Garen and Filip Pizlo. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2015-09-03 Babak Shafiei Merge r188311. 2015-08-11 Alexey Proskuryakov Make ASan build not depend on asan.xcconfig https://bugs.webkit.org/show_bug.cgi?id=147840 rdar://problem/21093702 Reviewed by Daniel Bates. * dfg/DFGOSREntry.cpp: (JSC::DFG::OSREntryData::dump): (JSC::DFG::prepareOSREntry): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * heap/ConservativeRoots.cpp: (JSC::ConservativeRoots::genericAddPointer): (JSC::ConservativeRoots::genericAddSpan): * heap/MachineStackMarker.cpp: (JSC::MachineThreads::removeThreadIfFound): (JSC::MachineThreads::gatherFromCurrentThread): (JSC::MachineThreads::Thread::captureStack): (JSC::copyMemory): * interpreter/Register.h: (JSC::Register::operator=): (JSC::Register::asanUnsafeJSValue): (JSC::Register::jsValue): 2015-09-03 Babak Shafiei Merge r188067. 2015-08-06 Filip Pizlo Structures used for tryGetConstantProperty() should be registered first https://bugs.webkit.org/show_bug.cgi?id=147750 Reviewed by Saam Barati and Michael Saboff. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetConstantProperty): Add an assertion to that effect. This should catch the bug sooner. * dfg/DFGGraph.h: (JSC::DFG::Graph::addStructureSet): Register structures when we make a structure set. That ensures that we won't call tryGetConstantProperty() on a structure that hasn't been registered yet. * dfg/DFGStructureRegistrationPhase.cpp: (JSC::DFG::StructureRegistrationPhase::run): Don't register structure sets here anymore. Registering them before we get here means there is no chance of the code being DCE'd before the structures get registered. It also enables the tryGetConstantProperty() assertion, since that code runs before StructureRegisterationPhase. (JSC::DFG::StructureRegistrationPhase::registerStructures): (JSC::DFG::StructureRegistrationPhase::registerStructure): (JSC::DFG::StructureRegistrationPhase::assertAreRegistered): (JSC::DFG::StructureRegistrationPhase::assertIsRegistered): (JSC::DFG::performStructureRegistration): 2015-08-27 Matthew Hanson Merge r189012. rdar://problem/22084478 2015-08-26 Saam barati MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize() https://bugs.webkit.org/show_bug.cgi?id=148500 Reviewed by Mark Lam. Consider the following scenario: - On OS X, WTF::pageSize() is 4*1024 bytes. - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000 - sizeof(MarkedBlock) == 248 - (248 + 53000) is a multiple of 4*1024. - (248 + 53000)/(4*1024) == 13 We will allocate a chunk of memory of size 53248 bytes that looks like this: 0 248 256 53248 53256 [Marked Block | 8 bytes | payload ...... ] 8 bytes | ^ ^ Our Environment record starts here. ^ ^ Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory. We need to ensure that we round up sizeof(MarkedBlock) to an atomSize boundary. We need to do this because the first atom inside the MarkedBlock will start at the rounded up multiple of atomSize past MarkedBlock. If we end up with an allocation that is perfectly aligned to the page size, then we will be short 8 bytes (in the current implementation where atomSize is 16 bytes, and MarkedBlock is 248 bytes). * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::allocateBlock): * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added. (use): (makeFunction): 2015-07-31 Lucas Forschler Merge r187579 2015-07-29 Filip Pizlo DFG::ArgumentsEliminationPhase should emit a PutStack for all of the GetStacks that the ByteCodeParser emitted https://bugs.webkit.org/show_bug.cgi?id=147433 rdar://problem/21668986 Reviewed by Mark Lam. Ideally, the ByteCodeParser would only emit SetArgument nodes for named arguments. But currently that's not what it does - it emits a SetArgument for every argument that a varargs call may pass. Each SetArgument gets turned into a GetStack. This means that if ArgumentsEliminationPhase optimizes away PutStacks for those varargs arguments that didn't get passed or used, we get degenerate IR where we have a GetStack of something that didn't have a PutStack. This fixes the bug by removing the code to optimize away PutStacks in ArgumentsEliminationPhase. * dfg/DFGArgumentsEliminationPhase.cpp: * tests/stress/varargs-inlining-underflow.js: Added. (baz): (bar): (foo): 2015-07-24 Matthew Hanson Merge r187139. rdar://problem/21847618 2015-07-21 Filip Pizlo Unreviewed, fix a lot of tests. Need to initialize WTF threading sooner. * jsc.cpp: (main): 2015-07-23 Lucas Forschler Merge r187125 2015-07-21 Filip Pizlo Fixed VM pool allocation should have a reserve for allocations that cannot fail https://bugs.webkit.org/show_bug.cgi?id=147154 rdar://problem/21847618 Reviewed by Geoffrey Garen. This adds the notion of a JIT pool reserve fraction. Some fraction, currently 1/4, of the JIT pool is reserved for allocations that cannot fail. It makes sense to make this a fraction rather than a constant because each allocation that can fail may cause some number of allocations that cannot fail (for example, the OSR exit thunks that we compile when we exit from some CodeBlock cannot fail). I've tested this by adding a test mode where we artificially limit the JIT pool size. Prior to the fix, we had >20 failures. Now we have none. * heap/GCLogging.cpp: (WTF::printInternal): I needed a dump method on Options members when debugging this. * heap/GCLogging.h: * jit/ExecutableAllocator.h: Raise the ARM64 limit to 32MB because 16MB is cutting it too close. * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Add the ability to artificially limit JIT pool size for testing. (JSC::ExecutableAllocator::memoryPressureMultiplier): Implement the reserve when computing memory pressure for JIT tier-up heuristics. (JSC::ExecutableAllocator::allocate): Implement the reserve when allocating can-fail things. * jsc.cpp: Rewire some options parsing so that CommandLine happens before we create the JIT pool. (main): (CommandLine::parseArguments): (jscmain): * runtime/Options.cpp: (JSC::OptionRange::dump): I needed a dump method on Options members when debugging this. (JSC::Options::initialize): This can now be called more than once. * runtime/Options.h: == Rolled over to ChangeLog-2015-07-23 ==