1. 06 Mar, 2012 1 commit
    • commit-queue@webkit.org's avatar
      Unreviewed, rolling out r109837. · cbcd594c
      commit-queue@webkit.org authored
      http://trac.webkit.org/changeset/109837
      https://bugs.webkit.org/show_bug.cgi?id=80399
      
      breaks Mac Productions builds, too late to try and fix it
      tonight (Requested by eseidel on #webkit).
      
      Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-03-06
      
      Source/JavaScriptCore:
      
      * API/tests/JSNode.c:
      * API/tests/JSNodeList.c:
      * Configurations/Base.xcconfig:
      * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/MacroAssemblerCodeRef.h:
      * bytecompiler/BytecodeGenerator.h:
      * dfg/DFGOperations.cpp:
      * heap/GCAssertions.h:
      * heap/HandleHeap.h:
      * heap/HandleStack.h:
      * heap/MarkedSpace.h:
      * heap/PassWeak.h:
      * heap/Strong.h:
      * heap/Weak.h:
      * jit/HostCallReturnValue.cpp:
      * jit/JIT.cpp:
      * jit/JITStubs.cpp:
      * jit/ThunkGenerators.cpp:
      * parser/Lexer.cpp:
      * runtime/Completion.cpp:
      * runtime/Executable.cpp:
      * runtime/Identifier.h:
      * runtime/InitializeThreading.cpp:
      * runtime/JSDateMath.cpp:
      * runtime/JSGlobalObjectFunctions.cpp:
      * runtime/JSStringBuilder.h:
      * runtime/JSVariableObject.h:
      * runtime/NumberPrototype.cpp:
      * runtime/WriteBarrier.h:
      * tools/CodeProfile.cpp:
      * tools/TieredMMapArray.h:
      * yarr/YarrJIT.cpp:
      
      Tools:
      
      * Scripts/build-webkit:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@109888 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      cbcd594c
  2. 05 Mar, 2012 1 commit
    • eric@webkit.org's avatar
      Source/JavaScriptCore: Update JavaScriptCore files to use fully-qualified WTF include paths · 37ac49ee
      eric@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=79960
      
      Reviewed by Adam Barth.
      
      This change does 5 small/related things:
       1. Updates JavaScriptCore.xcodeproj to install WTF headers into $BUILD/usr/local/include
          (WebCore, WebKit were already setup to look there, but JavaScriptCore.xcodeproj
          was not installing headers there.)
       2. Makes JavaScriptCore targets include $BUILD/usr/local/include in their
          header search path, as that's where the WTF headers will be installed.
       3. Similarly updates JavaScriptCore.vcproj/copy-files.cmd to copy WTF headers to PrivateHeaders/wtf/*
          in addition to the current behavior of flattening all headers to PrivateHeaders/*.h.
       4. Updates a bunch of JSC files to use #include <wtf/Foo.h> instead of #include "Foo.h"
          since soon the WTF headers will not be part of the JavaScriptCore Xcode project.
       5. Makes build-webkit build the WTF XCode project by default.
      
      * API/tests/JSNode.c:
      * API/tests/JSNodeList.c:
      * Configurations/Base.xcconfig:
      * assembler/MacroAssemblerCodeRef.h:
      * bytecompiler/BytecodeGenerator.h:
      * dfg/DFGOperations.cpp:
      * heap/GCAssertions.h:
      * heap/HandleHeap.h:
      * heap/HandleStack.h:
      * heap/MarkedSpace.h:
      * heap/PassWeak.h:
      * heap/Strong.h:
      * heap/Weak.h:
      * jit/HostCallReturnValue.cpp:
      * jit/JIT.cpp:
      * jit/JITStubs.cpp:
      * jit/ThunkGenerators.cpp:
      * parser/Lexer.cpp:
      * runtime/Completion.cpp:
      * runtime/Executable.cpp:
      * runtime/Identifier.h:
      * runtime/InitializeThreading.cpp:
      * runtime/JSDateMath.cpp:
      * runtime/JSGlobalObjectFunctions.cpp:
      * runtime/JSStringBuilder.h:
      * runtime/JSVariableObject.h:
      * runtime/NumberPrototype.cpp:
      * runtime/WriteBarrier.h:
      * tools/CodeProfile.cpp:
      * tools/TieredMMapArray.h:
      * yarr/YarrJIT.cpp:
      
      Tools: Update JavaScriptCore files to use fully-qualified WTF include path
      https://bugs.webkit.org/show_bug.cgi?id=79960
      
      Reviewed by Adam Barth.
      
      Build WTF/WTF.xcodeproj by default on Mac.
      
      * Scripts/build-webkit:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@109837 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      37ac49ee
  3. 26 Feb, 2012 1 commit
    • fpizlo@apple.com's avatar
      Getting the instruction stream for a code block should not require two loads · ebe232eb
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=79608
      
      Reviewed by Sam Weinig.
              
      Introduced the RefCountedArray class, which contains a single inline pointer
      to a ref-counted non-resizeable vector backing store. This satisfies the
      requirements of CodeBlock, which desires the ability to share instruction
      streams with other CodeBlocks. It also reduces the number of loads required
      for getting the instruction stream by one.
              
      This patch also gets rid of the bytecode discarding logic, since we don't
      use it anymore and it's unlikely to ever work right with DFG or LLInt. And
      I didn't feel like porting dead code to use RefCountedArray.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/CodeBlock.cpp:
      (JSC::instructionOffsetForNth):
      (JSC::CodeBlock::dump):
      (JSC::CodeBlock::CodeBlock):
      (JSC::CodeBlock::finalizeUnconditionally):
      (JSC::CodeBlock::handlerForBytecodeOffset):
      (JSC::CodeBlock::lineNumberForBytecodeOffset):
      (JSC::CodeBlock::expressionRangeForBytecodeOffset):
      (JSC::CodeBlock::shrinkToFit):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      (JSC::CodeBlock::numberOfInstructions):
      (JSC::CodeBlock::instructions):
      (JSC::CodeBlock::instructionCount):
      (JSC::CodeBlock::valueProfileForBytecodeOffset):
      (JSC):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::Label::setLocation):
      (JSC):
      (JSC::BytecodeGenerator::generate):
      (JSC::BytecodeGenerator::newLabel):
      * bytecompiler/BytecodeGenerator.h:
      (JSC):
      (BytecodeGenerator):
      (JSC::BytecodeGenerator::instructions):
      * bytecompiler/Label.h:
      (JSC::Label::Label):
      (Label):
      * dfg/DFGByteCodeCache.h:
      (JSC::DFG::ByteCodeCache::~ByteCodeCache):
      (JSC::DFG::ByteCodeCache::get):
      * jit/JITExceptions.cpp:
      (JSC::genericThrow):
      * llint/LowLevelInterpreter32_64.asm:
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::codeBlockWithBytecodeFor):
      (JSC::FunctionExecutable::produceCodeBlockFor):
      * wtf/RefCountedArray.h: Added.
      (WTF):
      (RefCountedArray):
      (WTF::RefCountedArray::RefCountedArray):
      (WTF::RefCountedArray::operator=):
      (WTF::RefCountedArray::~RefCountedArray):
      (WTF::RefCountedArray::size):
      (WTF::RefCountedArray::data):
      (WTF::RefCountedArray::begin):
      (WTF::RefCountedArray::end):
      (WTF::RefCountedArray::at):
      (WTF::RefCountedArray::operator[]):
      (Header):
      (WTF::RefCountedArray::Header::size):
      (WTF::RefCountedArray::Header::payload):
      (WTF::RefCountedArray::Header::fromPayload):
      * wtf/Platform.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@108943 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ebe232eb
  4. 09 Feb, 2012 1 commit
    • commit-queue@webkit.org's avatar
      Remove BytecodeGenerator::isLocal · 83e9d72d
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=78241
      
      Minor refactor to BytecodeGenerator.
      
      Patch by Andy Wingo <wingo@igalia.com> on 2012-02-09
      Reviewed by Gavin Barraclough.
      
      * bytecompiler/BytecodeGenerator.h:
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::isLocal):
      (JSC::BytecodeGenerator::isLocalConstant): Remove now-unused
      methods.
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ResolveNode::isPure): Use the ResolveResult mechanism
      instead of isLocal.  This will recognize more resolve nodes as
      being pure.
      (JSC::PrefixResolveNode::emitBytecode): Use isReadOnly on the
      location instead of isLocalConstant.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@107345 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      83e9d72d
  5. 01 Feb, 2012 2 commits
    • oliver@apple.com's avatar
      Add support for inferred function names · f7190bf1
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=77579
      
      Reviewed by Gavin Barraclough.
      
      Source/JavaScriptCore:
      
      Add new "inferred" names to function expressions, getters, and setters.
      This property is not exposed to JS, so is only visible in the debugger
      and profiler.
      
      * JavaScriptCore.exp:
      * bytecompiler/BytecodeGenerator.h:
      (JSC::BytecodeGenerator::makeFunction):
      * debugger/DebuggerCallFrame.cpp:
      (JSC::DebuggerCallFrame::calculatedFunctionName):
      * parser/ASTBuilder.h:
      (JSC::ASTBuilder::createAssignResolve):
      (JSC::ASTBuilder::createGetterOrSetterProperty):
      (JSC::ASTBuilder::createProperty):
      (JSC::ASTBuilder::makeAssignNode):
      * parser/Nodes.h:
      (JSC::FunctionBodyNode::setInferredName):
      (JSC::FunctionBodyNode::inferredName):
      (FunctionBodyNode):
      * profiler/Profiler.cpp:
      (JSC):
      (JSC::Profiler::createCallIdentifier):
      (JSC::createCallIdentifierFromFunctionImp):
      * runtime/Executable.cpp:
      (JSC::FunctionExecutable::FunctionExecutable):
      (JSC::FunctionExecutable::fromGlobalCode):
      * runtime/Executable.h:
      (JSC::FunctionExecutable::create):
      (JSC::FunctionExecutable::inferredName):
      (FunctionExecutable):
      * runtime/JSFunction.cpp:
      (JSC::JSFunction::calculatedDisplayName):
      (JSC):
      (JSC::getCalculatedDisplayName):
      * runtime/JSFunction.h:
      (JSC):
      
      LayoutTests:
      
      Update test case results.
      
      * fast/profiler/anonymous-event-handler-expected.txt:
      * fast/profiler/anonymous-function-called-from-different-contexts-expected.txt:
      * fast/profiler/anonymous-function-calls-built-in-functions-expected.txt:
      * fast/profiler/anonymous-function-calls-eval-expected.txt:
      * fast/profiler/built-in-function-calls-anonymous-expected.txt:
      * fast/profiler/inline-event-handler-expected.txt:
      * fast/profiler/many-calls-in-the-same-scope-expected.txt:
      * fast/profiler/multiple-and-different-scoped-anonymous-function-calls-expected.txt:
      * fast/profiler/multiple-and-different-scoped-function-calls-expected.txt:
      * fast/profiler/multiple-anonymous-functions-called-from-the-same-function-expected.txt:
      * fast/profiler/nested-anonymous-functon-expected.txt:
      * fast/profiler/start-and-stop-profiler-multiple-times-expected.txt:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@106504 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f7190bf1
    • commit-queue@webkit.org's avatar
      Refactor identifier resolution in BytecodeGenerator · 2fea740c
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=76285
      
      Patch by Andy Wingo <wingo@igalia.com> on 2012-02-01
      Reviewed by Geoffrey Garen.
      
      * bytecompiler/BytecodeGenerator.h:
      (JSC::ResolveResult): New class, to describe the storage
      location corresponding to an identifier in a program.
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::resolve): New function, replacing
      findScopedProperty.
      (JSC::BytecodeGenerator::resolveConstDecl): New function,
      encapsulating what ConstDeclNode::emitBytecode used to do.
      (JSC::BytecodeGenerator::emitGetStaticVar):
      (JSC::BytecodeGenerator::emitPutStaticVar): New functions,
      corresponding to the old emitGetScopedVar and emitPutScopedVar.
      (JSC::BytecodeGenerator::registerFor): Remove version that took an
      Identifier&; replaced by ResolveResult::local().
      (JSC::BytecodeGenerator::emitResolve):
      (JSC::BytecodeGenerator::emitResolveBase):
      (JSC::BytecodeGenerator::emitResolveBaseForPut):
      (JSC::BytecodeGenerator::emitResolveWithBase):
      (JSC::BytecodeGenerator::emitResolveWithThis): Change to accept a
      "resolveResult" argument.  This is more clear, and reduces the
      amount of double analysis happening at compile-time.
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ResolveNode::emitBytecode):
      (JSC::EvalFunctionCallNode::emitBytecode):
      (JSC::FunctionCallResolveNode::emitBytecode):
      (JSC::PostfixResolveNode::emitBytecode):
      (JSC::DeleteResolveNode::emitBytecode):
      (JSC::TypeOfResolveNode::emitBytecode):
      (JSC::PrefixResolveNode::emitBytecode):
      (JSC::ReadModifyResolveNode::emitBytecode):
      (JSC::AssignResolveNode::emitBytecode):
      (JSC::ConstDeclNode::emitCodeSingle):
      (JSC::ForInNode::emitBytecode): Refactor to use the new
      ResolveResult structure.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@106478 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2fea740c
  6. 30 Jan, 2012 1 commit
    • barraclough@apple.com's avatar
      Clean up putDirect · 09a55680
      barraclough@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=76232
      
      Reviewed by Sam Weinig.
      
      Part 3 - merge op_put_getter & op_put_setter.
      
      Putting these separately is inefficient (and makes future optimiation,
      e.g. making GetterSetter immutable) harder. Change to emit a single
      op_put_getter_setter bytecode op. Ultimately we should probably be
      able to merge this with put direct, to create a common op to initialize
      object literal properties.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dump):
      * bytecode/Opcode.h:
      (JSC):
      ():
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitPutGetterSetter):
      * bytecompiler/BytecodeGenerator.h:
      (BytecodeGenerator):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::PropertyListNode::emitBytecode):
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::privateExecute):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      * jit/JIT.h:
      (JIT):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emit_op_put_getter_setter):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emit_op_put_getter_setter):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * jit/JITStubs.h:
      ():
      * runtime/JSObject.cpp:
      (JSC::JSObject::putDirectVirtual):
      (JSC::JSObject::putDirectAccessor):
      (JSC):
      (JSC::putDescriptor):
      (JSC::JSObject::defineOwnProperty):
      * runtime/JSObject.h:
      ():
      (JSC::JSObject::putDirectInternal):
      (JSC::JSObject::putDirect):
      (JSC::JSObject::putDirectWithoutTransition):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@106255 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      09a55680
  7. 20 Jan, 2012 1 commit
    • fpizlo@apple.com's avatar
      Bytecode instructions that may have value profiling should have a direct inline · afcf9040
      fpizlo@apple.com authored
      link to the ValueProfile instance
      https://bugs.webkit.org/show_bug.cgi?id=76682
      <rdar://problem/10727689>
      
      Reviewed by Sam Weinig.
              
      Each opcode that gets value profiled now has a link to its ValueProfile. This
      required rationalizing the emission of value profiles for opcode combos, like
      op_method_check/op_get_by_id and op_call/op_call_put_result. It only makes
      sense for one of them to have a value profile link, and it makes most sense
      for it to be the one that actually sets the result. The previous behavior was
      to have op_method_check profile for op_get_by_id when they were used together,
      but otherwise for op_get_by_id to have its own profiles. op_call already did
      the right thing; all profiling was done by op_call_put_result.
              
      But rationalizing this code required breaking some of the natural boundaries
      that the code had; for instance the code in DFG that emits a GetById in place
      of both op_method_check and op_get_by_id must now know that it's the latter of
      those that has the value profile, while the first of those constitutes the OSR
      target. Hence each CodeOrigin must now have two bytecode indices - one for
      OSR exit and one for profiling.
              
      Finally this change required some refiddling of our optimization heuristics,
      because now all code blocks have "more instructions" due to the value profile
      slots.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::printGetByIdOp):
      (JSC::CodeBlock::dump):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::valueProfileForBytecodeOffset):
      * bytecode/CodeOrigin.h:
      (JSC::CodeOrigin::CodeOrigin):
      (JSC::CodeOrigin::bytecodeIndexForValueProfile):
      * bytecode/Instruction.h:
      (JSC::Instruction::Instruction):
      * bytecode/Opcode.h:
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitProfiledOpcode):
      (JSC::BytecodeGenerator::emitResolve):
      (JSC::BytecodeGenerator::emitGetScopedVar):
      (JSC::BytecodeGenerator::emitResolveBase):
      (JSC::BytecodeGenerator::emitResolveBaseForPut):
      (JSC::BytecodeGenerator::emitResolveWithBase):
      (JSC::BytecodeGenerator::emitResolveWithThis):
      (JSC::BytecodeGenerator::emitGetById):
      (JSC::BytecodeGenerator::emitGetByVal):
      (JSC::BytecodeGenerator::emitCall):
      (JSC::BytecodeGenerator::emitCallVarargs):
      (JSC::BytecodeGenerator::emitConstruct):
      * bytecompiler/BytecodeGenerator.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::ByteCodeParser):
      (JSC::DFG::ByteCodeParser::currentCodeOrigin):
      (JSC::DFG::ByteCodeParser::addCall):
      (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
      (JSC::DFG::ByteCodeParser::getPrediction):
      (JSC::DFG::ByteCodeParser::handleCall):
      (JSC::DFG::ByteCodeParser::handleInlining):
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::ByteCodeParser::parse):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::valueProfileFor):
      * jit/JIT.h:
      (JSC::JIT::emitValueProfilingSite):
      * jit/JITCall.cpp:
      (JSC::JIT::emit_op_call_put_result):
      * jit/JITCall32_64.cpp:
      (JSC::JIT::emit_op_call_put_result):
      * jit/JITInlineMethods.h:
      (JSC::JIT::emitValueProfilingSite):
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_resolve):
      (JSC::JIT::emit_op_resolve_base):
      (JSC::JIT::emit_op_resolve_skip):
      (JSC::JIT::emit_op_resolve_global):
      (JSC::JIT::emitSlow_op_resolve_global):
      (JSC::JIT::emit_op_resolve_with_base):
      (JSC::JIT::emit_op_resolve_with_this):
      (JSC::JIT::emitSlow_op_resolve_global_dynamic):
      * jit/JITOpcodes32_64.cpp:
      (JSC::JIT::emit_op_resolve):
      (JSC::JIT::emit_op_resolve_base):
      (JSC::JIT::emit_op_resolve_skip):
      (JSC::JIT::emit_op_resolve_global):
      (JSC::JIT::emitSlow_op_resolve_global):
      (JSC::JIT::emit_op_resolve_with_base):
      (JSC::JIT::emit_op_resolve_with_this):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emit_op_get_by_val):
      (JSC::JIT::emitSlow_op_get_by_val):
      (JSC::JIT::emit_op_method_check):
      (JSC::JIT::emitSlow_op_method_check):
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emitSlow_op_get_by_id):
      (JSC::JIT::emit_op_get_scoped_var):
      (JSC::JIT::emit_op_get_global_var):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emit_op_method_check):
      (JSC::JIT::emitSlow_op_method_check):
      (JSC::JIT::emit_op_get_by_val):
      (JSC::JIT::emitSlow_op_get_by_val):
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emitSlow_op_get_by_id):
      (JSC::JIT::emit_op_get_scoped_var):
      (JSC::JIT::emit_op_get_global_var):
      * jit/JITStubCall.h:
      (JSC::JITStubCall::callWithValueProfiling):
      * runtime/Options.cpp:
      (JSC::Options::initializeOptions):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@105533 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      afcf9040
  8. 11 Jan, 2012 1 commit
  9. 11 Dec, 2011 1 commit
    • ggaren@apple.com's avatar
      v8 benchmark takes 12-13 million function call slow paths due to extra arguments · 0af1468f
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=74244
      
      Reviewed by Filip Pizlo.
              
      .arguments function of order the Reversed
              
      10% speedup on v8-raytrace, 1.7% speedup on v8 overall, neutral on Kraken
      and SunSpider.
      
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::valueProfileForArgument): Clarified that the interface
      to this function is an argument number.
      
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      (JSC::BytecodeGenerator::emitCall):
      (JSC::BytecodeGenerator::emitConstruct):
      (JSC::BytecodeGenerator::isArgumentNumber): Switched to using CallFrame
      helper functions for computing offsets for arguments, rather than doing
      the math by hand.
              
      Switched to iterating argument offsets backwards (--) instead of forwards (++).
      
      * bytecompiler/BytecodeGenerator.h:
      (JSC::CallArguments::thisRegister):
      (JSC::CallArguments::argumentRegister):
      (JSC::CallArguments::registerOffset): Updated for arguments being reversed.
      
      * bytecompiler/NodesCodegen.cpp: Allocate arguments in reverse order.
      
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::getArgument):
      (JSC::DFG::ByteCodeParser::setArgument):
      (JSC::DFG::ByteCodeParser::flush):
      (JSC::DFG::ByteCodeParser::addCall):
      (JSC::DFG::ByteCodeParser::handleCall):
      (JSC::DFG::ByteCodeParser::handleInlining):
      (JSC::DFG::ByteCodeParser::handleMinMax):
      (JSC::DFG::ByteCodeParser::handleIntrinsic):
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::ByteCodeParser::processPhiStack): Use abstract argument indices
      that just-in-time convert to bytecode operands (i.e., indexes in the register
      file) through helper functions. This means only one piece of code needs
      to know how arguments are laid out in the register file.
      
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump): Ditto.
      
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::valueProfileFor): Ditto.
      
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::compileFunction): The whole point of this patch:
      Treat too many arguments as an arity match.
      
      * dfg/DFGOSRExit.h:
      (JSC::DFG::OSRExit::variableForIndex):
      (JSC::DFG::OSRExit::operandForIndex): Use helper functions, as above.
      
      * dfg/DFGOperands.h:
      (JSC::DFG::operandToArgument):
      (JSC::DFG::argumentToOperand): These are now the only two lines of code in
      the DFG compiler that know how arguments are laid out in memory.
      
      (JSC::DFG::Operands::operand):
      (JSC::DFG::Operands::setOperand): Use helper functions, as above.
      
      * dfg/DFGOperations.cpp: The whole point of this patch:
      Treat too many arguments as an arity match.
      
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::emitCall): Use helper functions, as above.
              
      Also, don't tag the caller frame slot as a cell, because it's not a cell.
      
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::emitCall): Use helper functions, as above.
      
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compile): Use helper functions, as above.
      
      (JSC::DFG::SpeculativeJIT::checkArgumentTypes): Use already-computed
      argument virtual register instead of recomputing by hand.
      
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callFrameSlot):
      (JSC::DFG::SpeculativeJIT::argumentSlot):
      (JSC::DFG::SpeculativeJIT::callFrameTagSlot):
      (JSC::DFG::SpeculativeJIT::callFramePayloadSlot):
      (JSC::DFG::SpeculativeJIT::argumentTagSlot):
      (JSC::DFG::SpeculativeJIT::argumentPayloadSlot): Added a few helper
      functions for dealing with callee arguments specifically. These still
      build on top of our other helper functions, and have no direct knowledge
      of how arguments are laid out in the register file.
      
      (JSC::DFG::SpeculativeJIT::resetCallArguments):
      (JSC::DFG::SpeculativeJIT::addCallArgument): Renamed argumentIndex to
      argumentOffset to match CallFrame naming.
      
      (JSC::DFG::SpeculativeJIT::valueSourceReferenceForOperand): Use helper
      functions, as above.
      
      * interpreter/CallFrame.h:
      (JSC::ExecState::argumentOffset):
      (JSC::ExecState::argumentOffsetIncludingThis):
      (JSC::ExecState::argument):
      (JSC::ExecState::setArgument):
      (JSC::ExecState::thisArgumentOffset):
      (JSC::ExecState::thisValue):
      (JSC::ExecState::setThisValue):
      (JSC::ExecState::offsetFor):
      (JSC::ExecState::hostThisRegister):
      (JSC::ExecState::hostThisValue): Added a bunch of helper functions for
      computing where an argument is in the register file. Anything in the
      runtime that needs to access arguments should use these helpers.
      
      * interpreter/CallFrameClosure.h:
      (JSC::CallFrameClosure::setThis):
      (JSC::CallFrameClosure::setArgument):
      (JSC::CallFrameClosure::resetCallFrame): This stuff is a lot simpler, now
      that too many arguments counts as an arity match and doesn't require
      preserving two copies of our arguments.
      
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::slideRegisterWindowForCall): Only need to do something
      special if the caller provided too few arguments.
              
      Key simplification: We never need to maintain two copies of our arguments
      anymore.
      
      (JSC::eval):
      (JSC::loadVarargs): Use helper functions.
      
      (JSC::Interpreter::unwindCallFrame): Updated for new interface.
      
      (JSC::Interpreter::execute):
      (JSC::Interpreter::executeCall):
      (JSC::Interpreter::executeConstruct):
      (JSC::Interpreter::prepareForRepeatCall): Seriously, though: use helper
      functions.
      
      (JSC::Interpreter::privateExecute): No need to check for stack overflow
      when calling host functions because they have zero callee registers.
      
      (JSC::Interpreter::retrieveArguments): Explicitly tear off the arguments
      object, since there's no special constructor for this anymore.
      
      * interpreter/Interpreter.h: Reduced the C++ re-entry depth because some
      workers tests were hitting stack overflow in some of my testing. We should
      make this test more exact in future.
      
      * interpreter/RegisterFile.h: Death to all runtime knowledge of argument
      location that does not belong to the CallFrame class!
      
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile): I am a broken record and I use helper functions.
              
      Also, the whole point of this patch: Treat too many arguments as an arity match.
      
      * jit/JITCall32_64.cpp:
      (JSC::JIT::compileLoadVarargs):
      * jit/JITCall.cpp:
      (JSC::JIT::compileLoadVarargs): Updated the argument copying math to use
      helper functions, for backwards-correctness. Removed the condition
      pertaining to declared argument count because, now that arguments are
      always in just one place, this optimization is valid for all functions.
      Standardized the if predicate for each line of the optimization. This might
      fix a bug, but I couldn't get the bug to crash in practice.
      
      * jit/JITOpcodes32_64.cpp:
      (JSC::JIT::emit_op_create_arguments):
      (JSC::JIT::emit_op_get_argument_by_val):
      (JSC::JIT::emitSlow_op_get_argument_by_val):
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_create_arguments):
      (JSC::JIT::emit_op_get_argument_by_val):
      (JSC::JIT::emitSlow_op_get_argument_by_val): Removed cti_op_create_arguments_no_params
      optimization because it's no longer an optimization, now that arguments
      are always contiguous in a known location.
              
      Updated argument access opcode math for backwards-correctness.
      
      * jit/JITStubs.cpp:
      (JSC::arityCheckFor): Updated just like slideRegisterWindowForCall. This
      function is slightly different because it copies the call frame in
      addition to the arguments. (In the Interpreter, the call frame is not
      set up by this point.)
      
      (JSC::lazyLinkFor): The whole point of this patch: Treat too many
      arguments as an arity match.
      
      (JSC::DEFINE_STUB_FUNCTION): Updated for new iterface to tearOff().
      
      * jit/JITStubs.h:
      * jit/SpecializedThunkJIT.h:
      (JSC::SpecializedThunkJIT::loadDoubleArgument):
      (JSC::SpecializedThunkJIT::loadCellArgument):
      (JSC::SpecializedThunkJIT::loadInt32Argument): Use helper functions! They
      build strong bones and teeth!
      
      * runtime/ArgList.cpp:
      (JSC::ArgList::getSlice):
      (JSC::MarkedArgumentBuffer::slowAppend):
      * runtime/ArgList.h:
      (JSC::MarkedArgumentBuffer::MarkedArgumentBuffer):
      (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
      (JSC::MarkedArgumentBuffer::at):
      (JSC::MarkedArgumentBuffer::clear):
      (JSC::MarkedArgumentBuffer::append):
      (JSC::MarkedArgumentBuffer::removeLast):
      (JSC::MarkedArgumentBuffer::last):
      (JSC::ArgList::ArgList):
      (JSC::ArgList::at): Updated for backwards-correctness. WTF::Vector doesn't
      play nice with backwards-ness, so I changed to using manual allocation.
              
      Fixed a FIXME about not all values being marked in the case of out-of-line
      arguments. I had to rewrite the loop anyway, and I didn't feel like
      maintaining fidelity to its old bugs.
      
      * runtime/Arguments.cpp:
      (JSC::Arguments::visitChildren):
      (JSC::Arguments::copyToArguments):
      (JSC::Arguments::fillArgList):
      (JSC::Arguments::getOwnPropertySlotByIndex):
      (JSC::Arguments::getOwnPropertySlot):
      (JSC::Arguments::getOwnPropertyDescriptor):
      (JSC::Arguments::putByIndex):
      (JSC::Arguments::put):
      (JSC::Arguments::tearOff):
      * runtime/Arguments.h:
      (JSC::Arguments::create):
      (JSC::Arguments::Arguments):
      (JSC::Arguments::argument):
      (JSC::Arguments::finishCreation): Secondary benefit of this patch: deleted
      lots of tricky code designed to maintain two different copies of function
      arguments. Now that arguments are always contiguous in one place in memory,
      this complexity can go away.
              
      Reduced down to one create function for the Arguments class, from three.
      
      Moved tearOff() into an out-of-line function because it's huge.
              
      Moved logic about whether to tear off eagerly into the Arguments class,
      so we didn't have to duplicate it elsewhere.
      
      * runtime/JSActivation.cpp:
      (JSC::JSActivation::JSActivation):
      (JSC::JSActivation::visitChildren): Renamed m_numParametersMinusThis to
      m_numCapturedArgs because if the value really were m_numParametersMinusThis
      we would be marking too much. (We shouldn't mark 'this' because it can't
      be captured.) Also, use helper functions.
      
      * runtime/JSActivation.h:
      (JSC::JSActivation::tearOff): Use helper functions.
      
      * runtime/JSArray.cpp:
      (JSC::JSArray::copyToArguments):
      * runtime/JSArray.h: Use helper functions, as above.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@102545 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0af1468f
  10. 20 Nov, 2011 1 commit
    • fpizlo@apple.com's avatar
      Showing the data overlay in OpenStreetMap doesn't work, zooming partially broken · 5da687a7
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=71505
      
      Source/JavaScriptCore:
      
      Reviewed by Oliver Hunt.
      
      The bytecode generator was assuming that call_varargs never reuses the base register
      (i.e. the function being called) for the result. This is no longer true.
      
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitCallVarargs):
      * bytecompiler/BytecodeGenerator.h:
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ApplyFunctionCallDotNode::emitBytecode):
      
      LayoutTests:
      
      Reviewed by Oliver Hunt.
      
      * fast/js/function-dot-apply-replace-base-expected.txt: Added.
      * fast/js/function-dot-apply-replace-base.html: Added.
      * fast/js/script-tests/cross-global-object-inline-global-var.js:
      (done):
      * fast/js/script-tests/function-dot-apply-replace-base.js: Added.
      (foo):
      (bar):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@100879 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5da687a7
  11. 14 Nov, 2011 2 commits
    • ggaren@apple.com's avatar
      A little bit of function call cleanup · 50c5ac26
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=72314
      
      Reviewed by Oliver Hunt.
      
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitCall): Renamed callFrame to registerOffset
      because this value doesn't give you the offset of the callee's call frame.
      
      (JSC::BytecodeGenerator::emitReturn): Tightened to use equality instead
      of greater-than. Removed comment since its reasoning was wrong.
              
      (JSC::BytecodeGenerator::emitConstruct): Updated for rename mentioned above.
      
      (JSC::BytecodeGenerator::isArgumentNumber): Provided a more precise way
      to ask this question, giving the bytecode generator more freedom to change
      internal implementation details.
              
      * bytecompiler/BytecodeGenerator.h: Reduced default vector capacity because
      16 was overkill.
      (JSC::CallArguments::registerOffset): Updated for rename mentioned above.
      
      * bytecompiler/NodesCodegen.cpp:
      (JSC::CallArguments::CallArguments):
      (JSC::CallArguments::newArgument): Factored out argument allocation into
      a helper function, so I can change it later.
      
      (JSC::CallFunctionCallDotNode::emitBytecode):
      (JSC::FunctionBodyNode::emitBytecode): Use helper function mentioned above.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@100200 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      50c5ac26
    • ggaren@apple.com's avatar
      Standardized the JS calling convention · 539d1bba
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=72221
              
      Reviewed by Oliver Hunt.
      
      This patch standardizes the calling convention so that the caller always
      sets up the callee's CallFrame. Adjustments for call type, callee type,
      argument count, etc. now always take place after that initial setup.
              
      This is a step toward reversing the argument order, but also has these
      immediate benefits (measured on x64):
              
      (1) 1% benchmark speedup across the board.
              
      (2) 50% code size reduction in baseline JIT function calls.
              
      (3) 1.5x speedup for single-dispatch .apply forwarding.
              
      (4) 1.1x speedup for multi-dispatch .apply forwarding.
      
      This change affected the baseline JIT most, since the baseline JIT had
      lots of ad hoc calling conventions for different caller / callee types.
      
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::branchPtr):
      (JSC::MacroAssemblerX86_64::branchAddPtr): Optimize compare to 0 into
      a test, like other assemblers do. (I added some compares to 0, and didn't
      want them to be slow.)
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dump): Merged op_load_varargs into op_call_varargs so
      op_call_varargs could share code generation with other forms of op_call.
      This is also a small optimization, since op_*varargs no longer have to
      pass arguments to each other through the register file.
      
      (JSC::CallLinkInfo::unlink):
      * bytecode/CodeBlock.h: Added a new call type: CallVarargs. This allows
      us to link functions called through .apply syntax. We need to distinguish
      CallVarargs from Call because CallVarargs changes its argument count
      on each inovcation, so we must always link to the argument count checking
      version of the callee.
      
      * bytecode/Opcode.h:
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitCallVarargs):
      * bytecompiler/BytecodeGenerator.h: Merged op_load_varargs into op_call_varargs.
      
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ApplyFunctionCallDotNode::emitBytecode): Ditto. Also, simplified
      some of this bytecode generation to remove redundant copies.
      
      * dfg/DFGJITCodeGenerator32_64.cpp:
      (JSC::DFG::JITCodeGenerator::emitCall):
      * dfg/DFGJITCodeGenerator64.cpp:
      (JSC::DFG::JITCodeGenerator::emitCall): Added a new call type: CallVarargs.
      DFG doesn't support this type, but its code needs to change slightly
      to accomodate a 3-state variable.
      
      Stopped passing the argument count in regT1 because this is non-standard.
      (The argument count goes in the CallFrame. This trades speed on the slow
      path for speed and code size on the fast path, and simplicity on all paths.
      A good trade, in my opinion.)
      
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::compileEntry):
      (JSC::DFG::JITCompiler::link):
      (JSC::DFG::JITCompiler::compile):
      (JSC::DFG::JITCompiler::compileFunction): Tweaked code to make CallFrame
      setup more obvious when single-stepping. Also, updated for argument count
      not being in regT1.
      
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::addJSCall):
      (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord): Added a new call
      type: CallVarargs.
      
      * dfg/DFGOperations.cpp: Do finish CallFrame setup in one place before
      doing anything else. Don't check for stack overflow because we have no callee
      registers, and our caller has already checked for its own registers.
      
      * dfg/DFGRepatch.cpp:
      (JSC::DFG::dfgLinkFor): We can link to our callee even if our argument
      count doesn't match -- we just need to link to the argument count checking
      version.
      
      * interpreter/CallFrameClosure.h:
      (JSC::CallFrameClosure::setArgument): BUG FIX: When supplying too many
      arguments from C++, we need to supply a full copy of the arguments prior
      to the subset copy that matches our callee's argument count. (That is what
      the standard calling convention would have produced in JS.) I would have
      split this into its own patch, but I couldn't find a way to get the JIT
      to fail a regression test in this area without my patch applied.
      
      * interpreter/Interpreter.cpp: Let the true code bomb begin!
      
      (JSC::eval): Fixed up this helper function to operate on eval()'s CallFrame,
      and not eval()'s caller frame. We no longer leave the CallFrame pointing
      to eval()'s caller during a call to eval(), since that is not standard.
      
      (JSC::loadVarargs): Factored out a shared helper function for use by JIT
      and interpreter because half the code means one quarter the bugs -- in my
      programming, at least.
      
      (JSC::Interpreter::execute): Removed a now-unused way to invoke eval.
              
      (JSC::Interpreter::privateExecute): Removed an invalid ASSERT following
      putDirect, because it got in the way of my testing. (When putting a
      function, the cached base of a PutPropertySlot can be 0 to signify "do
      not optimize".)
              
      op_call_eval: Updated for new, standard eval calling convention.
              
      op_load_varargs: Merged op_load_varargs into op_call_varargs.
      
      op_call_varags: Updated for new, standard eval calling convention. Don't
      check for stack overflow because the loadVarargs helper function already
      checked.
      
      * interpreter/Interpreter.h:
      (JSC::Interpreter::execute): Headers are fun and educational!
      
      * interpreter/RegisterFile.cpp:
      (JSC::RegisterFile::growSlowCase):
      * interpreter/RegisterFile.h:
      (JSC::RegisterFile::grow): Factored out the slow case into a slow
      case because it was cramping the style of my fast case.
      
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile): Moved initialization of
      RegisterFile::CodeBlock to make it more obvious when debugging. Removed
      assumption that argument count is in regT1, as above. Removed call to
      restoreArgumentReference() because the JITStubCall abstraction does this for us.
      
      (JSC::JIT::linkFor): Link even if we miss on argument count, as above.
      
      * jit/JIT.h:
      * jit/JITCall32_64.cpp:
      (JSC::JIT::emitSlow_op_call):
      (JSC::JIT::emitSlow_op_call_eval):
      (JSC::JIT::emitSlow_op_call_varargs):
      (JSC::JIT::emitSlow_op_construct):
      (JSC::JIT::emit_op_call_eval):
      (JSC::JIT::emit_op_call_varargs): Share all function call code generation.
      Don't count call_eval when accounting for linkable function calls because
      eval doesn't link. (Its fast path is to perform the eval.)
      
      (JSC::JIT::compileLoadVarargs): Ported this inline copying optimization
      to our new calling convention. The key to this optimization is the
      observation that, in a function that declares no arguments, if any
      arguments are passed, they all end up right behind 'this'.
      
      (JSC::JIT::compileCallEval):
      (JSC::JIT::compileCallEvalSlowCase): Factored out eval for a little clarity.
      
      (JSC::JIT::compileOpCall):
      (JSC::JIT::compileOpCallSlowCase): If you are still with me, dear reader,
      this is the whole point of my patch. The caller now unconditionally moves
      the CallFrame forward and fills in the data it knows before taking any
      branches to deal with weird caller/callee pairs.
              
      This also means that there is almost no slow path for calls -- it all
      gets folded into the shared virtual call stub. The only things remaining
      in the slow path are the rare case counter and a call to the stub.
      
      * jit/JITOpcodes32_64.cpp:
      (JSC::JIT::privateCompileCTIMachineTrampolines):
      (JSC::JIT::privateCompileCTINativeCall): Updated for values being in
      different registers or in memory, based on our new standard calling
      convention.
              
      Added a shared path for calling out to CTI helper functions for non-JS
      calls.
      
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emit_op_method_check): method_check emits its own code and
      the following get_by_id's code, so it needs to add both when informing
      result chaining of its result. This is important because the standard
      calling convention can now take advantage of this chaining.
      
      * jit/JITCall.cpp:
      (JSC::JIT::compileLoadVarargs):
      (JSC::JIT::compileCallEval):
      (JSC::JIT::compileCallEvalSlowCase):
      (JSC::JIT::compileOpCall):
      (JSC::JIT::compileOpCallSlowCase):
      * jit/JITOpcodes.cpp:
      (JSC::JIT::privateCompileCTIMachineTrampolines):
      (JSC::JIT::emit_op_call_eval):
      (JSC::JIT::emit_op_call_varargs):
      (JSC::JIT::emitSlow_op_call):
      (JSC::JIT::emitSlow_op_call_eval):
      (JSC::JIT::emitSlow_op_call_varargs):
      (JSC::JIT::emitSlow_op_construct): Observe, as I write all of my code a
      second time, now with 64 bits.
      
      * jit/JITStubs.cpp:
      (JSC::throwExceptionFromOpCall):
      (JSC::jitCompileFor):
      (JSC::arityCheckFor):
      (JSC::lazyLinkFor): A lot of mechanical changes here for one purpose:
      Exceptions thrown in the middle of a function call now use a shared helper
      function (throwExceptionFromOpCall). This function understands that the
      CallFrame currently points to the callEE, and the exception must be
      thrown by the callER. (The old calling convention would often still have
      the CallFrame pointing at the callER at the point of an exception. That
      is not the way of our new, standard calling convention.)
      
      (JSC::op_call_eval): Finish standard CallFrame setup before calling 
      our eval helper function, which now depends on that setup.
      
      * runtime/Arguments.h:
      (JSC::Arguments::length): Renamed numProvidedArguments() to length()
      because that's what other objects call it, and the difference made our
      new loadVarargs helper function hard to read.
      
      * runtime/Executable.cpp:
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal): Interpreter build
      fixes.
      
      * runtime/FunctionPrototype.cpp:
      (JSC::functionProtoFuncApply): Honor Arguments::MaxArguments even when
      the .apply call_varargs optimization fails. (This bug appears on layout
      tests when you disable the optimization.)
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@100165 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      539d1bba
  12. 24 Oct, 2011 1 commit
    • oliver@apple.com's avatar
      Crash in void JSC::validateCell<JSC::RegExp*>(JSC::RegExp*) · 780d3ccb
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=70689
      
      Reviewed by Filip Pizlo.
      
      While performing codegen we need to make the GlobalData explicitly
      aware of the codeblock being compiled, as compilation may trigger GC
      and CodeBlock holds GC values, but has not yet been assigned to its
      owner executable.
      
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      (JSC::BytecodeGenerator::~BytecodeGenerator):
      * bytecompiler/BytecodeGenerator.h:
      * heap/AllocationSpace.cpp:
      (JSC::AllocationSpace::allocateSlowCase):
      * heap/Heap.cpp:
      (JSC::Heap::markRoots):
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::JSGlobalData):
      * runtime/JSGlobalData.h:
      (JSC::JSGlobalData::startedCompiling):
      (JSC::JSGlobalData::finishedCompiling):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@98302 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      780d3ccb
  13. 17 Oct, 2011 1 commit
    • fpizlo@apple.com's avatar
      DFG bytecode parser should understand inline stacks · 41f5c958
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=70278
      
      Reviewed by Oliver Hunt.
              
      The DFG bytecode parser is now capable of parsing multiple code blocks at
      once. This remains turned off since not all inlining functionality is
      implemented.       
              
      This required making a few changes elsewhere in the system. The bytecode
      parser now may do some of the same things that the bytecode generator does,
      like allocating constants and identifiers. Basic block linking relies on
      bytecode indices, which are only meaningful within the context of one basic
      block. This is fine, so long as linking is done eagerly whenever switching
      from one code block to another.
      
      * bytecode/CodeOrigin.h:
      (JSC::CodeOrigin::CodeOrigin):
      * bytecompiler/BytecodeGenerator.h:
      * dfg/DFGBasicBlock.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::ByteCodeParser):
      (JSC::DFG::ByteCodeParser::get):
      (JSC::DFG::ByteCodeParser::set):
      (JSC::DFG::ByteCodeParser::getThis):
      (JSC::DFG::ByteCodeParser::setThis):
      (JSC::DFG::ByteCodeParser::currentCodeOrigin):
      (JSC::DFG::ByteCodeParser::getPrediction):
      (JSC::DFG::ByteCodeParser::makeSafe):
      (JSC::DFG::ByteCodeParser::makeDivSafe):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::~InlineStackEntry):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand):
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::ByteCodeParser::linkBlock):
      (JSC::DFG::ByteCodeParser::linkBlocks):
      (JSC::DFG::ByteCodeParser::setupPredecessors):
      (JSC::DFG::ByteCodeParser::buildOperandMapsIfNecessary):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
      (JSC::DFG::ByteCodeParser::parseCodeBlock):
      (JSC::DFG::ByteCodeParser::parse):
      * dfg/DFGGraph.h:
      (JSC::DFG::GetBytecodeBeginForBlock::GetBytecodeBeginForBlock):
      (JSC::DFG::GetBytecodeBeginForBlock::operator()):
      (JSC::DFG::Graph::blockIndexForBytecodeOffset):
      * dfg/DFGNode.h:
      * runtime/Identifier.h:
      (JSC::IdentifierMapIndexHashTraits::emptyValue):
      * runtime/JSValue.h:
      * wtf/StdLibExtras.h:
      (WTF::binarySearchWithFunctor):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@97675 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      41f5c958
  14. 15 Oct, 2011 1 commit
    • fpizlo@apple.com's avatar
      FunctionExecutable should expose the ability to create unattached FunctionCodeBlocks · 67fa6e4e
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=70157
      
      Reviewed by Geoff Garen.
              
      Added FunctionExecutable::produceCodeBlockFor() and rewired compileForCallInternal()
      and compileForConstructInternal() to use this method. This required more cleanly
      exposing some of CodeBlock's tiering functionality and moving the CompilationKind
      enum to Executable.h, as this was the easiest way to make it available to the
      declarations/definitions of CodeBlock, FunctionExecutable, and BytecodeGenerator.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::copyDataFrom):
      (JSC::CodeBlock::copyDataFromAlternative):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::setAlternative):
      * bytecompiler/BytecodeGenerator.h:
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::produceCodeBlockFor):
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal):
      * runtime/Executable.h:
      (JSC::FunctionExecutable::codeBlockFor):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@97564 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      67fa6e4e
  15. 12 Sep, 2011 1 commit
    • fpizlo@apple.com's avatar
      JavaScriptCore does not have baseline->speculative OSR · a71ab055
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=67920
      
      Reviewed by Oliver Hunt.
              
      This adds the ability to on-stack-replace (OSR) from code that is
      running hot in the old JIT to code compiled by the new JIT.  This
      ensures that long-running loops benefit from DFG optimization.
      It also ensures that if code experiences a speculation failure
      in DFG code, it has an opportunity to reenter the DFG once every
      1,000 loop iterations or so.
              
      This results in a 2.88x speed-up on Kraken/imaging-desaturate,
      and is a pure win on the main three benchmark suites (SunSpider,
      V8, Kraken), when tiered compilation is enabled.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dump):
      (JSC::CodeBlock::CodeBlock):
      (JSC::ProgramCodeBlock::compileOptimized):
      (JSC::EvalCodeBlock::compileOptimized):
      (JSC::FunctionCodeBlock::compileOptimized):
      * bytecode/CodeBlock.h:
      * bytecode/Opcode.h:
      * bytecode/PredictedType.h: Added.
      (JSC::isCellPrediction):
      (JSC::isArrayPrediction):
      (JSC::isInt32Prediction):
      (JSC::isDoublePrediction):
      (JSC::isNumberPrediction):
      (JSC::isBooleanPrediction):
      (JSC::isStrongPrediction):
      (JSC::predictionToString):
      (JSC::mergePredictions):
      (JSC::mergePrediction):
      (JSC::makePrediction):
      * bytecode/PredictionTracker.h: Added.
      (JSC::operandIsArgument):
      (JSC::PredictionSlot::PredictionSlot):
      (JSC::PredictionTracker::PredictionTracker):
      (JSC::PredictionTracker::initializeSimilarTo):
      (JSC::PredictionTracker::copyLocalsFrom):
      (JSC::PredictionTracker::numberOfArguments):
      (JSC::PredictionTracker::numberOfVariables):
      (JSC::PredictionTracker::argumentIndexForOperand):
      (JSC::PredictionTracker::predictArgument):
      (JSC::PredictionTracker::predict):
      (JSC::PredictionTracker::predictGlobalVar):
      (JSC::PredictionTracker::getArgumentPrediction):
      (JSC::PredictionTracker::getPrediction):
      (JSC::PredictionTracker::getGlobalVarPrediction):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitLoopHint):
      * bytecompiler/BytecodeGenerator.h:
      * bytecompiler/NodesCodegen.cpp:
      (JSC::DoWhileNode::emitBytecode):
      (JSC::WhileNode::emitBytecode):
      (JSC::ForNode::emitBytecode):
      (JSC::ForInNode::emitBytecode):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canCompileOpcode):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compile):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      * dfg/DFGGraph.h:
      (JSC::DFG::BasicBlock::BasicBlock):
      (JSC::DFG::Graph::predict):
      (JSC::DFG::Graph::getPrediction):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::exitSpeculativeWithOSR):
      (JSC::DFG::JITCompiler::compileEntry):
      (JSC::DFG::JITCompiler::compileBody):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::noticeOSREntry):
      * dfg/DFGNode.h:
      * dfg/DFGOSREntry.cpp: Added.
      (JSC::DFG::predictionIsValid):
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGOSREntry.h: Added.
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGPredictionTracker.h: Removed.
      * dfg/DFGPropagator.cpp:
      (JSC::DFG::Propagator::mergeUse):
      (JSC::DFG::Propagator::mergePrediction):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/CompactJITCodeMap.h:
      (JSC::CompactJITCodeMap::numberOfEntries):
      (JSC::CompactJITCodeMap::decode):
      (JSC::CompactJITCodeMap::Decoder::Decoder):
      (JSC::CompactJITCodeMap::Decoder::numberOfEntriesRemaining):
      (JSC::CompactJITCodeMap::Decoder::read):
      * jit/JIT.cpp:
      (JSC::JIT::emitOptimizationCheck):
      (JSC::JIT::emitTimeoutCheck):
      (JSC::JIT::privateCompileMainPass):
      * jit/JIT.h:
      (JSC::JIT::emit_op_loop_hint):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@95016 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a71ab055
  16. 06 Sep, 2011 1 commit
    • fpizlo@apple.com's avatar
      JavaScriptCore does not have tiered compilation · 594887ab
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=67176
      
      Reviewed by Gavin Barraclough.
      
      This adds the ability to have multiple CodeBlocks associated with
      a particular role in an Executable.  These are stored in
      descending order of compiler tier.  CodeBlocks are optimized when
      a counter (m_executeCounter) that is incremented in loops and
      epilogues becomes positive.  Optimizing means that all calls to
      the old CodeBlock are unlinked.
      
      The DFG can now pull in predictions from ValueProfiles, and
      propagate them along the graph.  To support the new phase while
      maintaing some level of abstraction, a DFGDriver was introduced
      that encapsulates how to run the DFG compiler.
      
      This is turned off by default because it's not yet a performance
      win on all benchmarks.  It speeds up crypto and richards by
      10% and 6% respectively, but still does not do as good of a job
      as it could.  Notably, the DFG backend has not changed, and
      is largely oblivious to the new information being made available
      to it.
      
      When turned off (the default), this patch is performance neutral.
      
      * CMakeLists.txt:
      * GNUmakefile.am:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
      * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/MacroAssemblerX86.h:
      (JSC::MacroAssemblerX86::branchAdd32):
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::branchAdd32):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      (JSC::CodeBlock::~CodeBlock):
      (JSC::CodeBlock::visitAggregate):
      (JSC::CallLinkInfo::unlink):
      (JSC::CodeBlock::unlinkCalls):
      (JSC::CodeBlock::unlinkIncomingCalls):
      (JSC::CodeBlock::clearEvalCache):
      (JSC::replaceExistingEntries):
      (JSC::CodeBlock::copyDataFromAlternative):
      (JSC::ProgramCodeBlock::replacement):
      (JSC::EvalCodeBlock::replacement):
      (JSC::FunctionCodeBlock::replacement):
      (JSC::ProgramCodeBlock::compileOptimized):
      (JSC::EvalCodeBlock::compileOptimized):
      (JSC::FunctionCodeBlock::compileOptimized):
      * bytecode/CodeBlock.h:
      (JSC::GlobalCodeBlock::GlobalCodeBlock):
      (JSC::ProgramCodeBlock::ProgramCodeBlock):
      (JSC::EvalCodeBlock::EvalCodeBlock):
      (JSC::FunctionCodeBlock::FunctionCodeBlock):
      * bytecode/ValueProfile.h:
      (JSC::ValueProfile::dump):
      (JSC::ValueProfile::computeStatistics):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      * bytecompiler/BytecodeGenerator.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::ByteCodeParser):
      (JSC::DFG::ByteCodeParser::addCall):
      (JSC::DFG::ByteCodeParser::dynamicallyPredict):
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::parse):
      * dfg/DFGDriver.cpp: Added.
      (JSC::DFG::compile):
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGDriver.h: Added.
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      (JSC::DFG::Graph::predictArgumentTypes):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::predict):
      (JSC::DFG::Graph::predictGlobalVar):
      (JSC::DFG::Graph::isConstant):
      (JSC::DFG::Graph::isJSConstant):
      (JSC::DFG::Graph::isInt32Constant):
      (JSC::DFG::Graph::isDoubleConstant):
      (JSC::DFG::Graph::valueOfJSConstant):
      (JSC::DFG::Graph::valueOfInt32Constant):
      (JSC::DFG::Graph::valueOfDoubleConstant):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::isConstant):
      (JSC::DFG::JITCompiler::isJSConstant):
      (JSC::DFG::JITCompiler::isInt32Constant):
      (JSC::DFG::JITCompiler::isDoubleConstant):
      (JSC::DFG::JITCompiler::valueOfJSConstant):
      (JSC::DFG::JITCompiler::valueOfInt32Constant):
      (JSC::DFG::JITCompiler::valueOfDoubleConstant):
      * dfg/DFGNode.h:
      (JSC::DFG::isCellPrediction):
      (JSC::DFG::isNumberPrediction):
      (JSC::DFG::predictionToString):
      (JSC::DFG::mergePrediction):
      (JSC::DFG::makePrediction):
      (JSC::DFG::Node::valueOfJSConstant):
      (JSC::DFG::Node::isInt32Constant):
      (JSC::DFG::Node::isDoubleConstant):
      (JSC::DFG::Node::valueOfInt32Constant):
      (JSC::DFG::Node::valueOfDoubleConstant):
      (JSC::DFG::Node::predict):
      * dfg/DFGPropagation.cpp: Added.
      (JSC::DFG::Propagator::Propagator):
      (JSC::DFG::Propagator::fixpoint):
      (JSC::DFG::Propagator::setPrediction):
      (JSC::DFG::Propagator::mergePrediction):
      (JSC::DFG::Propagator::propagateNode):
      (JSC::DFG::Propagator::propagateForward):
      (JSC::DFG::Propagator::propagateBackward):
      (JSC::DFG::propagate):
      * dfg/DFGPropagation.h: Added.
      (JSC::DFG::propagate):
      * dfg/DFGRepatch.cpp:
      (JSC::DFG::dfgLinkFor):
      * heap/HandleHeap.h:
      (JSC::HandleHeap::Node::Node):
      * jit/JIT.cpp:
      (JSC::JIT::emitOptimizationCheck):
      (JSC::JIT::emitTimeoutCheck):
      (JSC::JIT::privateCompile):
      (JSC::JIT::linkFor):
      * jit/JIT.h:
      (JSC::JIT::emitOptimizationCheck):
      * jit/JITCall32_64.cpp:
      (JSC::JIT::emit_op_ret):
      (JSC::JIT::emit_op_ret_object_or_this):
      * jit/JITCode.h:
      (JSC::JITCode::JITCode):
      (JSC::JITCode::bottomTierJIT):
      (JSC::JITCode::topTierJIT):
      (JSC::JITCode::nextTierJIT):
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_ret):
      (JSC::JIT::emit_op_ret_object_or_this):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * jit/JITStubs.h:
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileOptimized):
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileOptimized):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::compileOptimizedForCall):
      (JSC::FunctionExecutable::compileOptimizedForConstruct):
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal):
      * runtime/Executable.h:
      (JSC::EvalExecutable::compile):
      (JSC::ProgramExecutable::compile):
      (JSC::FunctionExecutable::compileForCall):
      (JSC::FunctionExecutable::compileForConstruct):
      (JSC::FunctionExecutable::compileOptimizedFor):
      * wtf/Platform.h:
      * wtf/SentinelLinkedList.h:
      (WTF::BasicRawSentinelNode::BasicRawSentinelNode):
      (WTF::BasicRawSentinelNode::setPrev):
      (WTF::BasicRawSentinelNode::setNext):
      (WTF::BasicRawSentinelNode::prev):
      (WTF::BasicRawSentinelNode::next):
      (WTF::BasicRawSentinelNode::isOnList):
      (WTF::::remove):
      (WTF::::SentinelLinkedList):
      (WTF::::begin):
      (WTF::::end):
      (WTF::::push):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@94559 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      594887ab
  17. 18 Jul, 2011 1 commit
    • oliver@apple.com's avatar
      2011-07-18 Mark Hahnenberg <mhahnenberg@apple.com> · fcacd3c8
      oliver@apple.com authored
              Refactor JSC to replace JSCell::operator new with static create method
              https://bugs.webkit.org/show_bug.cgi?id=64466
      
              Reviewed by Oliver Hunt (oliver@apple.com) and Darin Adler (darin@apple.com).
      
              First step in a longer refactoring process to remove the use of
              operator new overloading in order to allocate GC objects and to replace
              this method with static create methods for each individual type of heap-allocated
              JS object.  This particular patch only deals with replacing uses of
              operator new within JSC proper.  Future patches will remove it from the
              parts that interface with the DOM.  Due to the DOM's continued dependence
              on it, operator new has not actually been removed from JSCell.
      
              * API/JSCallbackConstructor.h:
              (JSC::JSCallbackConstructor::create):
              * API/JSCallbackFunction.h:
              (JSC::JSCallbackFunction::create):
              * API/JSCallbackObject.h:
              (JSC::JSCallbackObject::operator new):
              (JSC::JSCallbackObject::create):
              * API/JSCallbackObjectFunctions.h:
              (JSC::::staticFunctionGetter):
              * API/JSClassRef.cpp:
              (OpaqueJSClass::prototype):
              * API/JSContextRef.cpp:
              * API/JSObjectRef.cpp:
              (JSObjectMake):
              (JSObjectMakeFunctionWithCallback):
              (JSObjectMakeConstructor):
              * JavaScriptCore.exp:
              * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::createActivation):
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::BytecodeGenerator):
              * bytecompiler/BytecodeGenerator.h:
              (JSC::BytecodeGenerator::makeFunction):
              * bytecompiler/NodesCodegen.cpp:
              (JSC::RegExpNode::emitBytecode):
              * interpreter/Interpreter.cpp:
              (JSC::Interpreter::privateExecute):
              (JSC::Interpreter::retrieveArguments):
              * jit/JITStubs.cpp:
              (JSC::DEFINE_STUB_FUNCTION):
              * jsc.cpp:
              (GlobalObject::create):
              (GlobalObject::GlobalObject):
              (functionRun):
              (jscmain):
              * runtime/Arguments.h:
              (JSC::Arguments::create):
              (JSC::Arguments::createNoParameters):
              * runtime/ArrayConstructor.cpp:
              (JSC::constructArrayWithSizeQuirk):
              * runtime/ArrayConstructor.h:
              (JSC::ArrayConstructor::create):
              * runtime/ArrayPrototype.cpp:
              (JSC::arrayProtoFuncSplice):
              * runtime/ArrayPrototype.h:
              (JSC::ArrayPrototype::create):
              * runtime/BooleanConstructor.cpp:
              (JSC::constructBoolean):
              (JSC::constructBooleanFromImmediateBoolean):
              * runtime/BooleanConstructor.h:
              (JSC::BooleanConstructor::create):
              * runtime/BooleanObject.h:
              (JSC::BooleanObject::create):
              * runtime/BooleanPrototype.h:
              (JSC::BooleanPrototype::create):
              * runtime/DateConstructor.cpp:
              (JSC::constructDate):
              * runtime/DateConstructor.h:
              (JSC::DateConstructor::create):
              * runtime/DateInstance.h:
              (JSC::DateInstance::create):
              * runtime/DatePrototype.h:
              (JSC::DatePrototype::create):
              * runtime/Error.cpp:
              (JSC::createError):
              (JSC::createEvalError):
              (JSC::createRangeError):
              (JSC::createReferenceError):
              (JSC::createSyntaxError):
              (JSC::createTypeError):
              (JSC::createURIError):
              (JSC::StrictModeTypeErrorFunction::create):
              (JSC::createTypeErrorFunction):
              * runtime/ErrorConstructor.h:
              (JSC::ErrorConstructor::create):
              * runtime/ErrorInstance.cpp:
              (JSC::ErrorInstance::ErrorInstance):
              (JSC::ErrorInstance::create):
              * runtime/ErrorInstance.h:
              * runtime/ErrorPrototype.cpp:
              (JSC::ErrorPrototype::ErrorPrototype):
              * runtime/ErrorPrototype.h:
              (JSC::ErrorPrototype::create):
              * runtime/ExceptionHelpers.cpp:
              (JSC::InterruptedExecutionError::InterruptedExecutionError):
              (JSC::InterruptedExecutionError::create):
              (JSC::createInterruptedExecutionException):
              (JSC::TerminatedExecutionError::TerminatedExecutionError):
              (JSC::TerminatedExecutionError::create):
              (JSC::createTerminatedExecutionException):
              * runtime/Executable.cpp:
              (JSC::FunctionExecutable::FunctionExecutable):
              (JSC::FunctionExecutable::fromGlobalCode):
              * runtime/Executable.h:
              (JSC::ExecutableBase::create):
              (JSC::NativeExecutable::create):
              (JSC::ScriptExecutable::ScriptExecutable):
              (JSC::EvalExecutable::create):
              (JSC::ProgramExecutable::create):
              (JSC::FunctionExecutable::create):
              (JSC::FunctionExecutable::make):
              * runtime/FunctionConstructor.cpp:
              (JSC::constructFunctionSkippingEvalEnabledCheck):
              * runtime/FunctionConstructor.h:
              (JSC::FunctionConstructor::create):
              * runtime/FunctionPrototype.cpp:
              (JSC::FunctionPrototype::addFunctionProperties):
              * runtime/FunctionPrototype.h:
              (JSC::FunctionPrototype::create):
              * runtime/GetterSetter.h:
              (JSC::GetterSetter::create):
              * runtime/JSAPIValueWrapper.h:
              (JSC::JSAPIValueWrapper::create):
              (JSC::jsAPIValueWrapper):
              * runtime/JSActivation.cpp:
              (JSC::JSActivation::argumentsGetter):
              * runtime/JSActivation.h:
              (JSC::JSActivation::create):
              * runtime/JSArray.h:
              (JSC::JSArray::create):
              * runtime/JSCell.h:
              (JSC::JSCell::allocateCell):
              * runtime/JSFunction.h:
              (JSC::JSFunction::create):
              * runtime/JSGlobalObject.cpp:
              (JSC::JSGlobalObject::init):
              (JSC::JSGlobalObject::reset):
              * runtime/JSGlobalObject.h:
              (JSC::constructEmptyArray):
              (JSC::constructArray):
              * runtime/JSNotAnObject.h:
              (JSC::JSNotAnObject::create):
              * runtime/JSONObject.h:
              (JSC::JSONObject::create):
              * runtime/JSObject.cpp:
              (JSC::JSObject::defineGetter):
              (JSC::JSObject::defineSetter):
              (JSC::putDescriptor):
              * runtime/JSObject.h:
              (JSC::JSFinalObject::create):
              * runtime/JSPropertyNameIterator.cpp:
              (JSC::JSPropertyNameIterator::create):
              * runtime/JSPropertyNameIterator.h:
              (JSC::JSPropertyNameIterator::create):
              * runtime/JSString.cpp:
              (JSC::JSString::substringFromRope):
              (JSC::JSString::replaceCharacter):
              (JSC::StringObject::create):
              * runtime/JSString.h:
              (JSC::RopeBuilder::JSString):
              (JSC::RopeBuilder::create):
              (JSC::RopeBuilder::createHasOtherOwner):
              (JSC::jsSingleCharacterString):
              (JSC::jsSingleCharacterSubstring):
              (JSC::jsNontrivialString):
              (JSC::jsString):
              (JSC::jsSubstring):
              (JSC::jsOwnedString):
              * runtime/JSValue.cpp:
              (JSC::JSValue::toObjectSlowCase):
              (JSC::JSValue::synthesizeObject):
              (JSC::JSValue::synthesizePrototype):
              * runtime/Lookup.cpp:
              (JSC::setUpStaticFunctionSlot):
              * runtime/MathObject.h:
              (JSC::MathObject::create):
              * runtime/NativeErrorConstructor.cpp:
              (JSC::NativeErrorConstructor::NativeErrorConstructor):
              * runtime/NativeErrorConstructor.h:
              (JSC::NativeErrorConstructor::create):
              * runtime/NativeErrorPrototype.h:
              (JSC::NativeErrorPrototype::create):
              * runtime/NumberConstructor.cpp:
              (JSC::constructWithNumberConstructor):
              * runtime/NumberConstructor.h:
              (JSC::NumberConstructor::create):
              * runtime/NumberObject.cpp:
              (JSC::constructNumber):
              * runtime/NumberObject.h:
              (JSC::NumberObject::create):
              * runtime/NumberPrototype.h:
              (JSC::NumberPrototype::create):
              * runtime/ObjectConstructor.h:
              (JSC::ObjectConstructor::create):
              * runtime/ObjectPrototype.h:
              (JSC::ObjectPrototype::create):
              * runtime/Operations.h:
              (JSC::jsString):
              * runtime/RegExp.cpp:
              (JSC::RegExp::RegExp):
              (JSC::RegExp::createWithoutCaching):
              (JSC::RegExp::create):
              * runtime/RegExp.h:
              * runtime/RegExpCache.cpp:
              (JSC::RegExpCache::lookupOrCreate):
              * runtime/RegExpConstructor.cpp:
              (JSC::RegExpConstructor::arrayOfMatches):
              (JSC::constructRegExp):
              * runtime/RegExpConstructor.h:
              (JSC::RegExpConstructor::create):
              * runtime/RegExpMatchesArray.h:
              (JSC::RegExpMatchesArray::create):
              * runtime/RegExpObject.h:
              (JSC::RegExpObject::create):
              * runtime/RegExpPrototype.cpp:
              (JSC::regExpProtoFuncCompile):
              * runtime/RegExpPrototype.h:
              (JSC::RegExpPrototype::create):
              * runtime/ScopeChain.h:
              (JSC::ScopeChainNode::create):
              (JSC::ScopeChainNode::push):
              * runtime/SmallStrings.cpp:
              (JSC::SmallStrings::createEmptyString):
              (JSC::SmallStrings::createSingleCharacterString):
              * runtime/StringConstructor.cpp:
              (JSC::constructWithStringConstructor):
              * runtime/StringConstructor.h:
              (JSC::StringConstructor::create):
              * runtime/StringObject.h:
              (JSC::StringObject::create):
              * runtime/StringObjectThatMasqueradesAsUndefined.h:
              (JSC::StringObjectThatMasqueradesAsUndefined::create):
              * runtime/StringPrototype.cpp:
              (JSC::stringProtoFuncMatch):
              (JSC::stringProtoFuncSearch):
              * runtime/StringPrototype.h:
              (JSC::StringPrototype::create):
              * runtime/Structure.h:
              (JSC::Structure::create):
              (JSC::Structure::createStructure):
              * runtime/StructureChain.h:
              (JSC::StructureChain::create):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@91194 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fcacd3c8
  18. 15 Jul, 2011 1 commit
    • barraclough@apple.com's avatar
      https://bugs.webkit.org/show_bug.cgi?id=64250 · 19afeced
      barraclough@apple.com authored
      Global strict mode function leaking global object as "this".
      
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore: 
      
      The root problem here is that we pass the wrong values into
      calls, and then try to fix them up in the callee. Correct
      behaviour per the spec is to pass in the value undefined,
      as this unless either (1) the function call is based on an
      explicit property access or (2) the base of the call comes
      directly from a 'with'.
      
      This change does away with the need for this conversion of
      objects (non strict code should only box primitives), and
      does away with all this conversion for strict functions.
      
      This patch may have web compatibility ramifications, and may
      require some advocacy.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dump):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * bytecode/Opcode.h:
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      (JSC::BytecodeGenerator::emitResolveWithThis):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * bytecompiler/BytecodeGenerator.h:
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * bytecompiler/NodesCodegen.cpp:
      (JSC::EvalFunctionCallNode::emitBytecode):
      (JSC::FunctionCallResolveNode::emitBytecode):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
          - Change NeedsThisConversion check to test for JSString's vptr
            (objects no longer need conversion).
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::resolveThisAndProperty):
          - Based on resolveBaseAndProperty, but produce correct this value.
      (JSC::Interpreter::privateExecute):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * interpreter/Interpreter.h:
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      (JSC::JIT::privateCompileSlowCases):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * jit/JIT.h:
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_resolve_with_this):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      (JSC::JIT::emit_op_convert_this):
      (JSC::JIT::emitSlow_op_convert_this):
          - Change NeedsThisConversion check to test for JSString's vptr
            (objects no longer need conversion).
      * jit/JITOpcodes32_64.cpp:
      (JSC::JIT::emit_op_resolve_with_this):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      (JSC::JIT::emit_op_convert_this):
      (JSC::JIT::emitSlow_op_convert_this):
          - Change NeedsThisConversion check to test for JSString's vptr
            (objects no longer need conversion).
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * jit/JITStubs.h:
          - Removed op_convert_this_strict, added op_resolve_with_this.
      * runtime/JSActivation.h:
          - removed NeedsThisConversion flag, added IsEnvironmentRecord.
      * runtime/JSStaticScopeObject.h:
          - removed NeedsThisConversion flag, added IsEnvironmentRecord.
      * runtime/JSString.h:
      (JSC::RopeBuilder::createStructure):
          - removed NeedsThisConversion.
      * runtime/JSTypeInfo.h:
      (JSC::TypeInfo::isEnvironmentRecord):
      (JSC::TypeInfo::overridesHasInstance):
          - removed NeedsThisConversion flag, added IsEnvironmentRecord.
      * runtime/JSValue.h:
          - removed NeedsThisConversion.
      * runtime/JSVariableObject.h:
          - Corrected StructureFlags inheritance.
      * runtime/StrictEvalActivation.h:
      (JSC::StrictEvalActivation::createStructure):
          - Added IsEnvironmentRecord to StructureFlags, addded createStructure.
      * runtime/Structure.h:
          - removed NeedsThisConversion.
      * tests/mozilla/ecma/String/15.5.4.6-2.js:
      (getTestCases):
          - Removed invalid test case.
      
      Source/WebCore: 
      
      * bindings/js/JSMainThreadExecState.h:
      (WebCore::JSMainThreadExecState::call):
      * bindings/scripts/CodeGeneratorJS.pm:
      (GenerateHeader):
          - Change call to pass DOM Window shell, instead of the global varaible object.
      
      Source/WebKit/mac: 
      
      * Plugins/Hosted/NetscapePluginInstanceProxy.mm:
      (WebKit::NetscapePluginInstanceProxy::invoke):
      (WebKit::NetscapePluginInstanceProxy::invokeDefault):
          - Change call to pass DOM Window shell, instead of the global varaible object.
      
      Source/WebKit2: 
      
      * WebProcess/Plugins/Netscape/NPJSObject.cpp:
      (WebKit::NPJSObject::invoke):
          - Change call to pass DOM Window shell, instead of the global varaible object.
      
      LayoutTests: 
      
      Add test case / update test results.
      
      * fast/js/call-base-resolution-expected.txt: Added.
      * fast/js/call-base-resolution.html: Added.
          - Add test for ES5 correct this value resolution in calls.
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.10_String.prototype.match/S15.5.4.10_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.12_String.prototype.search/S15.5.4.12_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.13_String.prototype.slice/S15.5.4.13_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.14_String.prototype.split/S15.5.4.14_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.15_String.prototype.substring/S15.5.4.15_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.4_String.prototype.charAt/S15.5.4.4_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.5_String.prototype.charCodeAt/S15.5.4.5_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.6_String.prototype.concat/S15.5.4.6_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.7_String.prototype.indexOf/S15.5.4.7_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.8_String.prototype.lastIndexOf/S15.5.4.8_A1_T3-expected.txt:
          - Check in failing results for these tests - these tests were asserting incorrect behaviour,
            and have since been fixed in test-262, see https://bugs.ecmascript.org/show_bug.cgi?id=117
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@91095 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      19afeced
  19. 28 Jun, 2011 1 commit
    • oliver@apple.com's avatar
      2011-06-28 Oliver Hunt <oliver@apple.com> · 673aed62
      oliver@apple.com authored
              Reviewed by Gavin Barraclough.
      
              Make constant array optimisation less strict about what constitutes a constant
              https://bugs.webkit.org/show_bug.cgi?id=63554
      
              Now allow string constants in array literals to actually be considered constant,
              and so avoid codegen in array literals with strings in them.
      
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::addConstantBuffer):
              (JSC::CodeBlock::constantBuffer):
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::addConstantBuffer):
              (JSC::BytecodeGenerator::addStringConstant):
              (JSC::BytecodeGenerator::emitNewArray):
              * bytecompiler/BytecodeGenerator.h:
              * interpreter/Interpreter.cpp:
              (JSC::Interpreter::privateExecute):
              * jit/JITStubs.cpp:
              (JSC::DEFINE_STUB_FUNCTION):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@89954 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      673aed62
  20. 22 Jun, 2011 1 commit
    • ggaren@apple.com's avatar
      Removed the conceit that global variables are local variables when running global code · 99e9f3f6
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=63106
              
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore: 
      
      This is required for write barrier correctness.
              
      SunSpider reports about a 0.5% regression, mostly from bitops-bitwise-and.js.
      I was able to reduce the regression with a tiny peephole optimization in
      the bytecompiler, but not eliminate it. I'm committing this assuming
      that turning on generational GC will win back at least 0.5%.
      
      (FWIW, the DFG JIT can easily eliminate any regression by sharing loads of
      the global object's var storage. I considered doing the same kind of
      optimization in the existing JIT, but it seemed like moving in the wrong
      direction.)
      
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::addGlobalVar):
      (JSC::BytecodeGenerator::BytecodeGenerator): Don't give global variables
      negative indices, since they're no longer negatively offset from the
      current stack frame.
              
      Do give global variables monotonically increasing positive indices, since
      that's much easier to work with.
              
      Don't limit the number of optimizable global variables, since it's no
      longer limited by the register file, since they're no longer stored in
      the register file.
      
      (JSC::BytecodeGenerator::registerFor): Global code never has any local
      registers because a var in global code is actually a property of the
      global object.
      
      (JSC::BytecodeGenerator::constRegisterFor): Ditto.
      
      (JSC::BytecodeGenerator::emitResolve): Did a tiny bit of constant
      propagation and dead code elimination to speed up our compiles and
      reduce WTFs / minute.
      
      * bytecompiler/BytecodeGenerator.h:
      (JSC::BytecodeGenerator::registerFor): Removed special handling of globals.
      
      (JSC::BytecodeGenerator::shouldOptimizeLocals): Don't optimize locals in
      global code, since there are none.
      
      (JSC::BytecodeGenerator::canOptimizeNonLocals): Do optimize non-locals
      in global code (i.e., global vars), since there are some.
      
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::callEval):
      (JSC::Interpreter::Interpreter):
      (JSC::Interpreter::dumpRegisters):
      (JSC::Interpreter::execute):
      * interpreter/Interpreter.h: Updated for deleted / renamed code.
      
      * interpreter/RegisterFile.cpp:
      (JSC::RegisterFile::gatherConservativeRoots):
      (JSC::RegisterFile::releaseExcessCapacity): Updated for deleted / renamed
      data members.
      
      * interpreter/RegisterFile.h:
      (JSC::RegisterFile::begin):
      (JSC::RegisterFile::size):
      (JSC::RegisterFile::RegisterFile):
      (JSC::RegisterFile::shrink): Removed all code and comments dealing with
      global variables stored in the register file.
      
      (JSC::RegisterFile::grow): Updated for same.
              
      Also, a slight correctness fix: Test the VM commit end, and not just the
      in-use end, when checking for stack overflow. In theory, it's invalid to
      commit past the end of your allocation, even if you never touch that
      memory. This makes the usable size of the stack slightly smaller. No test
      because we don't know of any case in practice where this crashes.
      
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::JSGlobalData): Updated for changes above.
      
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::resizeRegisters):
      (JSC::JSGlobalObject::addStaticGlobals):
      * runtime/JSGlobalObject.h: Simplified globals to have monotonically 
      increasing indexes, always located in our external storage.
      
      LayoutTests: 
      
      * fast/js/recursion-limit-equal-expected.txt: Updated to reflect slightly
      changed recursion limit.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@89465 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      99e9f3f6
  21. 21 Jun, 2011 1 commit
    • ggaren@apple.com's avatar
      2011-06-21 Geoffrey Garen <ggaren@apple.com> · 829e3bbe
      ggaren@apple.com authored
              Reviewed by Oliver Hunt.
      
              Moved 'const' off the global-variable-as-local-variable crack pipe
              https://bugs.webkit.org/show_bug.cgi?id=63105
              
              This is necessary for moving the rest of the code off of same.
              
              Many problems remain in our handling of const. I have fixed none of them.
      
              * bytecompiler/BytecodeGenerator.h:
              (JSC::BytecodeGenerator::scopeChain): New accessor, needed to enable
              const to directly implement its unique scoping rules.
      
              * bytecompiler/NodesCodegen.cpp:
              (JSC::PrefixResolveNode::emitBytecode): Do specify that our resolve is
              for writing, so we don't overwrite const variables.
      
              (JSC::ConstDeclNode::emitCodeSingle): Don't assume that all declared const
              variables are available as local variables, since this won't be the case
              once global variables are not available as local variables. Instead, use
              put_scoped_var in the case where there is no local variable. Like a local
              variable, put_scoped_var succeeds even though const properties are
              read-only, since put_scoped_var skips read-only checks. (Yay?)
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@89392 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      829e3bbe
  22. 16 Jun, 2011 1 commit
    • oliver@apple.com's avatar
      2011-06-15 Oliver Hunt <oliver@apple.com> · 8e3cca58
      oliver@apple.com authored
              Reviewed by Geoffrey Garen.
      
              Reduce memory usage of resolve_global
              https://bugs.webkit.org/show_bug.cgi?id=62765
      
              If we have a large number of resolve_globals in a single
              block start planting plain resolve instructions instead
              whenever we aren't in a loop.  This allows us to reduce
              the code size for extremely large functions without
              losing the performance benefits of op_resolve_global.
      
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::globalResolveInfoCount):
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::shouldAvoidResolveGlobal):
              (JSC::BytecodeGenerator::emitResolve):
              (JSC::BytecodeGenerator::emitResolveWithBase):
              * bytecompiler/BytecodeGenerator.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@89058 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8e3cca58
  23. 14 Jun, 2011 3 commits
    • oliver@apple.com's avatar
      2011-06-14 Oliver Hunt <oliver@apple.com> · a991d698
      oliver@apple.com authored
              Reviewed by Gavin Barraclough.
      
              Constant array literals result in unnecessarily large amounts of code
              https://bugs.webkit.org/show_bug.cgi?id=62658
      
              Add a new version of op_new_array that simply copies values from a buffer
              we hang off of the CodeBlock, rather than generating code to place each
              entry into the registerfile, and then copying it from the registerfile into
              the array.  This is a slight improvement on some sunspider tests, but no
              measurable overall change.  That's okay though as our goal was to reduce
              code size without hurting performance.
      
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::dump):
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::addImmediateBuffer):
              (JSC::CodeBlock::immediateBuffer):
              * bytecode/Opcode.h:
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::addImmediateBuffer):
              (JSC::BytecodeGenerator::emitNewArray):
              * bytecompiler/BytecodeGenerator.h:
              * bytecompiler/NodesCodegen.cpp:
              (JSC::ArrayNode::emitBytecode):
              * interpreter/Interpreter.cpp:
              (JSC::Interpreter::privateExecute):
              * jit/JIT.cpp:
              (JSC::JIT::privateCompileMainPass):
              * jit/JIT.h:
              * jit/JITOpcodes.cpp:
              (JSC::JIT::emit_op_new_array):
              (JSC::JIT::emit_op_new_array_buffer):
              * jit/JITOpcodes32_64.cpp:
              * jit/JITStubs.cpp:
              (JSC::DEFINE_STUB_FUNCTION):
              * jit/JITStubs.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@88873 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a991d698
    • commit-queue@webkit.org's avatar
      2011-06-14 Sheriff Bot <webkit.review.bot@gmail.com> · 0e8ef143
      commit-queue@webkit.org authored
              Unreviewed, rolling out r88841.
              http://trac.webkit.org/changeset/88841
              https://bugs.webkit.org/show_bug.cgi?id=62672
      
              Caused many tests to crash (Requested by rniwa on #webkit).
      
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::dump):
              * bytecode/CodeBlock.h:
              * bytecode/Opcode.h:
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::emitNewArray):
              * bytecompiler/BytecodeGenerator.h:
              * bytecompiler/NodesCodegen.cpp:
              (JSC::ArrayNode::emitBytecode):
              * interpreter/Interpreter.cpp:
              (JSC::Interpreter::privateExecute):
              * jit/JIT.cpp:
              (JSC::JIT::privateCompileMainPass):
              * jit/JIT.h:
              * jit/JITOpcodes.cpp:
              (JSC::JIT::emit_op_new_array):
              * jit/JITOpcodes32_64.cpp:
              (JSC::JIT::emit_op_new_array):
              * jit/JITStubs.cpp:
              * jit/JITStubs.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@88866 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0e8ef143
    • oliver@apple.com's avatar
      2011-06-14 Oliver Hunt <oliver@apple.com> · ebf7685a
      oliver@apple.com authored
              Reviewed by Gavin Barraclough.
      
              Constant array literals result in unnecessarily large amounts of code
              https://bugs.webkit.org/show_bug.cgi?id=62658
      
              Add a new version of op_new_array that simply copies values from a buffer
              we hang off of the CodeBlock, rather than generating code to place each
              entry into the registerfile, and then copying it from the registerfile into
              the array.  This is a slight improvement on some sunspider tests, but no
              measurable overall change.  That's okay though as our goal was to reduce
              code size without hurting performance.
      
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::dump):
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::addImmediateBuffer):
              (JSC::CodeBlock::immediateBuffer):
              * bytecode/Opcode.h:
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::addImmediateBuffer):
              (JSC::BytecodeGenerator::emitNewArray):
              * bytecompiler/BytecodeGenerator.h:
              * bytecompiler/NodesCodegen.cpp:
              (JSC::ArrayNode::emitBytecode):
              * interpreter/Interpreter.cpp:
              (JSC::Interpreter::privateExecute):
              * jit/JIT.cpp:
              (JSC::JIT::privateCompileMainPass):
              * jit/JIT.h:
              * jit/JITOpcodes.cpp:
              (JSC::JIT::emit_op_new_array):
              (JSC::JIT::emit_op_new_array_buffer):
              * jit/JITOpcodes32_64.cpp:
              * jit/JITStubs.cpp:
              (JSC::DEFINE_STUB_FUNCTION):
              * jit/JITStubs.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@88841 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ebf7685a
  24. 25 May, 2011 4 commits
    • oliver@apple.com's avatar
      2011-05-25 Oliver Hunt <oliver@apple.com> · 5652af77
      oliver@apple.com authored
              Reviewed by Geoffrey Garen.
      
              Make RegExp GC allocated
              https://bugs.webkit.org/show_bug.cgi?id=61490
      
              Make RegExp GC allocated.  Basically mechanical change to replace
              most use of [Pass]RefPtr<RegExp> with RegExp* or WriteBarrier<RegExp>
              where actual ownership happens.
      
              Made the RegExpCache use Strong<> references currently to avoid any
              changes in behaviour.
      
              * JavaScriptCore.exp:
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::visitAggregate):
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::addRegExp):
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::addRegExp):
              (JSC::BytecodeGenerator::emitNewRegExp):
              * bytecompiler/BytecodeGenerator.h:
              * runtime/JSCell.h:
              * runtime/JSGlobalData.cpp:
              (JSC::JSGlobalData::JSGlobalData):
              (JSC::JSGlobalData::clearBuiltinStructures):
              (JSC::JSGlobalData::addRegExpToTrace):
              * runtime/JSGlobalData.h:
              * runtime/JSGlobalObject.cpp:
              (JSC::JSGlobalObject::reset):
              * runtime/RegExp.cpp:
              (JSC::RegExp::RegExp):
              (JSC::RegExp::create):
              (JSC::RegExp::invalidateCode):
              * runtime/RegExp.h:
              (JSC::RegExp::createStructure):
              * runtime/RegExpCache.cpp:
              (JSC::RegExpCache::lookupOrCreate):
              (JSC::RegExpCache::create):
              * runtime/RegExpCache.h:
              * runtime/RegExpConstructor.cpp:
              (JSC::constructRegExp):
              * runtime/RegExpObject.cpp:
              (JSC::RegExpObject::RegExpObject):
              (JSC::RegExpObject::visitChildren):
              * runtime/RegExpObject.h:
              (JSC::RegExpObject::setRegExp):
              (JSC::RegExpObject::RegExpObjectData::RegExpObjectData):
              * runtime/RegExpPrototype.cpp:
              (JSC::RegExpPrototype::RegExpPrototype):
              (JSC::regExpProtoFuncCompile):
              * runtime/RegExpPrototype.h:
              * runtime/StringPrototype.cpp:
              (JSC::stringProtoFuncMatch):
              (JSC::stringProtoFuncSearch):
      2011-05-25  James Robinson  <jamesr@chromium.org>
      
              Reviewed by Geoffrey Garen
      
              CachedResource overhead size calculation ignores the actual size of the URL
              https://bugs.webkit.org/show_bug.cgi?id=61481
      
              CachedResource::overheadSize is used to determine the size of an entry in the memory cache to know when to evict
              it.  When the resource is a large data: URL, for example representing image or audio data, the URL size itself
              can be significant.
      
              This patch uses an estimate of actual number of bytes used by the URL that is valid for ASCII urls and close for
              other types of strings instead of a fixed number.
      
              * loader/cache/CachedResource.cpp:
              (WebCore::CachedResource::overheadSize):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@87346 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5652af77
    • oliver@apple.com's avatar
      6e00d03d
    • oliver@apple.com's avatar
      2011-05-25 Oliver Hunt <oliver@apple.com> · 4872d097
      oliver@apple.com authored
              Reviewed by Geoffrey Garen.
      
              Make RegExp GC allocated
              https://bugs.webkit.org/show_bug.cgi?id=61490
      
              Make RegExp GC allocated.  Basically mechanical change to replace
              most use of [Pass]RefPtr<RegExp> with RegExp* or WriteBarrier<RegExp>
              where actual ownership happens.
      
              Made the RegExpCache use Strong<> references currently to avoid any
              changes in behaviour.
      
              * JavaScriptCore.exp:
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::visitAggregate):
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::addRegExp):
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::addRegExp):
              (JSC::BytecodeGenerator::emitNewRegExp):
              * bytecompiler/BytecodeGenerator.h:
              * runtime/JSCell.h:
              * runtime/JSGlobalData.cpp:
              (JSC::JSGlobalData::JSGlobalData):
              (JSC::JSGlobalData::clearBuiltinStructures):
              (JSC::JSGlobalData::addRegExpToTrace):
              * runtime/JSGlobalData.h:
              * runtime/JSGlobalObject.cpp:
              (JSC::JSGlobalObject::reset):
              * runtime/RegExp.cpp:
              (JSC::RegExp::RegExp):
              (JSC::RegExp::create):
              (JSC::RegExp::invalidateCode):
              * runtime/RegExp.h:
              (JSC::RegExp::createStructure):
              * runtime/RegExpCache.cpp:
              (JSC::RegExpCache::lookupOrCreate):
              (JSC::RegExpCache::create):
              * runtime/RegExpCache.h:
              * runtime/RegExpConstructor.cpp:
              (JSC::constructRegExp):
              * runtime/RegExpObject.cpp:
              (JSC::RegExpObject::RegExpObject):
              (JSC::RegExpObject::visitChildren):
              * runtime/RegExpObject.h:
              (JSC::RegExpObject::setRegExp):
              (JSC::RegExpObject::RegExpObjectData::RegExpObjectData):
              * runtime/RegExpPrototype.cpp:
              (JSC::RegExpPrototype::RegExpPrototype):
              (JSC::regExpProtoFuncCompile):
              * runtime/RegExpPrototype.h:
              * runtime/StringPrototype.cpp:
              (JSC::stringProtoFuncMatch):
              (JSC::stringProtoFuncSearch):
      2011-05-25  Oliver Hunt  <oliver@apple.com>
      
              Reviewed by Geoffrey Garen.
      
              Make RegExp GC allocated
              https://bugs.webkit.org/show_bug.cgi?id=61490
      
              RegExp is GC'd so we don't need the RefPtr shenanigans anymore.
      
              * bindings/js/SerializedScriptValue.cpp:
              (WebCore::CloneDeserializer::readTerminal):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@87343 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4872d097
    • kevino@webkit.org's avatar
      Reviewed by Eric Seidel. · e1696ed5
      kevino@webkit.org authored
      Add JS_EXPORT_PRIVATE macro for exported methods in bytecompiler headers.
              
      https://bugs.webkit.org/show_bug.cgi?id=27551
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@87304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e1696ed5
  25. 09 Apr, 2011 1 commit
    • ggaren@apple.com's avatar
      2011-04-08 Geoffrey Garen <ggaren@apple.com> · f03cbce4
      ggaren@apple.com authored
              Reviewed by Oliver Hunt.
      
              A few heap-related renames and file moves.
              
              WeakGCPtr<T> => Weak<T>
              Global<T> => Strong<T>
              collector/ => heap/
              collector/* => heap/*
              runtime/WeakGCPtr.h => heap/Weak.h
              
              (Eventually, even more files should move into the heap directory. Like
              Heap.h and Heap.cpp, for example.)
      
              * API/JSClassRef.h:
              * CMakeLists.txt:
              * GNUmakefile.am:
              * GNUmakefile.list.am:
              * JavaScriptCore.gypi:
              * JavaScriptCore.pri:
              * JavaScriptCore.pro:
              * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
              * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
              * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
              * JavaScriptCore.vcproj/jsc/jscCommon.vsprops:
              * JavaScriptCore.xcodeproj/project.pbxproj:
              * bytecode/SamplingTool.h:
              * bytecompiler/BytecodeGenerator.h:
              * collector: Removed.
              * collector/handles: Removed.
              * collector/handles/Global.h: Removed.
              * collector/handles/Handle.h: Removed.
              * collector/handles/HandleHeap.cpp: Removed.
              * collector/handles/HandleHeap.h: Removed.
              * collector/handles/HandleStack.cpp: Removed.
              * collector/handles/HandleStack.h: Removed.
              * collector/handles/Local.h: Removed.
              * collector/handles/LocalScope.h: Removed.
              * heap: Copied from collector.
              * heap/Handle.h: Copied from collector/handles/Handle.h.
              * heap/HandleHeap.cpp: Copied from collector/handles/HandleHeap.cpp.
              * heap/HandleHeap.h: Copied from collector/handles/HandleHeap.h.
              * heap/HandleStack.cpp: Copied from collector/handles/HandleStack.cpp.
              * heap/HandleStack.h: Copied from collector/handles/HandleStack.h.
              * heap/Local.h: Copied from collector/handles/Local.h.
              * heap/LocalScope.h: Copied from collector/handles/LocalScope.h.
              * heap/Strong.h: Copied from collector/handles/Global.h.
              (JSC::Strong::Strong):
              (JSC::Strong::~Strong):
              (JSC::Strong::operator=):
              * heap/Weak.h: Copied from runtime/WeakGCPtr.h.
              (JSC::Weak::Weak):
              (JSC::Weak::~Weak):
              * heap/handles: Removed.
              * interpreter/RegisterFile.h:
              * jit/JITStubs.cpp:
              (JSC::JITThunks::hostFunctionStub):
              * jit/JITStubs.h:
              * runtime/Structure.h:
              * runtime/WeakGCPtr.h: Removed.
      2011-04-08  Geoffrey Garen  <ggaren@apple.com>
      
              Reviewed by Oliver Hunt.
      
              A few heap-related renames and file moves.
              
              WeakGCPtr<T> => Weak<T>
              Global<T> => Strong<T>
              collector/ => heap/
              collector/* => heap/*
              runtime/WeakGCPtr.h => heap/Weak.h
              
              (Eventually, even more files should move into the heap directory. Like
              Heap.h and Heap.cpp, for example.)
      
              * JSRun.h:
              * JSValueWrapper.h:
      2011-04-08  Geoffrey Garen  <ggaren@apple.com>
      
              Reviewed by Oliver Hunt.
      
              A few heap-related renames and file moves.
              
              WeakGCPtr<T> => Weak<T>
              Global<T> => Strong<T>
              collector/ => heap/
              collector/* => heap/*
              runtime/WeakGCPtr.h => heap/Weak.h
              
              (Eventually, even more files should move into the heap directory. Like
              Heap.h and Heap.cpp, for example.)
      
              * CMakeLists.txt:
      2011-04-08  Geoffrey Garen  <ggaren@apple.com>
      
              Reviewed by Oliver Hunt.
      
              A few heap-related renames and file moves.
              
              WeakGCPtr<T> => Weak<T>
              Global<T> => Strong<T>
              collector/ => heap/
              collector/* => heap/*
              runtime/WeakGCPtr.h => heap/Weak.h
              
              (Eventually, even more files should move into the heap directory. Like
              Heap.h and Heap.cpp, for example.)
      
              * Plugins/Hosted/NetscapePluginInstanceProxy.h:
              * Plugins/Hosted/NetscapePluginInstanceProxy.mm:
              (WebKit::NetscapePluginInstanceProxy::LocalObjectMap::idForObject):
              (WebKit::NetscapePluginInstanceProxy::LocalObjectMap::forget):
              (WebKit::NetscapePluginInstanceProxy::evaluate):
              * WebView/WebScriptDebugger.h:
      2011-04-08  Geoffrey Garen  <ggaren@apple.com>
      
              Reviewed by Oliver Hunt.
      
              A few heap-related renames and file moves.
              
              WeakGCPtr<T> => Weak<T>
              Global<T> => Strong<T>
              collector/ => heap/
              collector/* => heap/*
              runtime/WeakGCPtr.h => heap/Weak.h
              
              (Eventually, even more files should move into the heap directory. Like
              Heap.h and Heap.cpp, for example.)
      
              * CMakeLists.txt:
              * ForwardingHeaders/collector: Removed.
              * ForwardingHeaders/heap: Copied from ForwardingHeaders/collector.
              * ForwardingHeaders/heap/Strong.h: Copied from ForwardingHeaders/collector/handles/Global.h.
              * ForwardingHeaders/heap/Weak.h: Copied from ForwardingHeaders/runtime/WeakGCPtr.h.
              * ForwardingHeaders/runtime/WeakGCPtr.h: Removed.
              * WebCore.vcproj/WebCore.vcproj:
              * WebCore.vcproj/copyForwardingHeaders.cmd:
              * bindings/js/JSCallbackData.h:
              * bindings/js/JSCustomVoidCallback.h:
              * bindings/js/JSDOMWindowBase.h:
              * bindings/js/JSDOMWindowShell.cpp:
              (WebCore::JSDOMWindowShell::setWindow):
              * bindings/js/JSDataGridDataSource.h:
              * bindings/js/JSEventListener.h:
              * bindings/js/ScheduledAction.cpp:
              (WebCore::ScheduledAction::ScheduledAction):
              * bindings/js/ScheduledAction.h:
              * bindings/js/ScriptCachedFrameData.cpp:
              (WebCore::ScriptCachedFrameData::ScriptCachedFrameData):
              * bindings/js/ScriptCachedFrameData.h:
              * bindings/js/ScriptController.cpp:
              (WebCore::ScriptController::createWindowShell):
              * bindings/js/ScriptController.h:
              * bindings/js/ScriptObject.h:
              * bindings/js/ScriptState.h:
              * bindings/js/ScriptValue.cpp:
              * bindings/js/ScriptValue.h:
              * bindings/js/ScriptWrappable.h:
              * bindings/js/WorkerScriptController.cpp:
              (WebCore::WorkerScriptController::initScript):
              * bindings/js/WorkerScriptController.h:
              * bridge/jsc/BridgeJSC.h:
              * bridge/qt/qt_runtime.h:
              * bridge/runtime_root.h:
              * xml/XMLHttpRequest.cpp:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@83385 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f03cbce4
  26. 15 Mar, 2011 1 commit
  27. 09 Mar, 2011 1 commit
    • barraclough@apple.com's avatar
      Bug 56041 - RexExp constructor should only accept flags "gim" · 745949b0
      barraclough@apple.com authored
      Fix for issues introduced in r80667.
      
      Reviewed by Sam Weinig.
      
      Source/JavaScriptCore: 
      
      Invalid flags to a RegExp literal are a late syntax error!
      
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::addRegExp):
          - Pass a PassRefPtr<RegExp>
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::addRegExp):
      (JSC::BytecodeGenerator::emitNewRegExp):
      * bytecompiler/BytecodeGenerator.h:
          - Pass a PassRefPtr<RegExp>
      * bytecompiler/NodesCodegen.cpp:
      (JSC::RegExpNode::emitBytecode):
          - Should not be ASSERTing that the flags are valid - this is a late(er) error.
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::privateExecute):
          - Need to check for error from RegExp constructor.
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
          - Need to check for error from RegExp constructor.
      * runtime/RegExp.h:
      (JSC::RegExp::isValid):
          - Make isValid check that the regexp was created with valid flags.
      * runtime/RegExpKey.h:
          - Since we'll not create RegExp objects with invalid flags, separate out the deleted value.
      
      LayoutTests: 
      
      * fast/regex/script-tests/parentheses.js:
      * fast/regex/script-tests/pcre-test-1.js:
          - Providing invalid flags to RegExp literals is an error in ES5.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@80684 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      745949b0
  28. 08 Mar, 2011 1 commit
    • oliver@apple.com's avatar
      2011-03-07 Oliver Hunt <oliver@apple.com> · ba10bec9
      oliver@apple.com authored
              Reviewed by Gavin Barraclough.
      
              Make CodeBlock GC write barrier safe
              https://bugs.webkit.org/show_bug.cgi?id=55910
      
              In order to make CodeBlock WriteBarrier safe it was necessary
              to make it have a single GC owner, and for that reason I have
              made ExecutableBase a GC allocated object.  This required
              updating their creation routines as well as all sites that hold
              a reference to them.  GC objects that held Executable's have been
              converted to WriteBarriers, and all other sites now use Global<>.
      
              As an added benefit this gets rid of JSGlobalData's list of
              GlobalCodeBlocks.
      
              Perf testing shows a 0.5% progression on v8, vs. a 0.3% regression
              on SunSpider.  Given none of the tests that show regressions
              demonstrate a regression on their own, and sampling shows up nothing.
              I suspect we're just getting one or two additional gc passes at
              the end of the run.
      
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::dump):
              (JSC::CodeBlock::CodeBlock):
              (JSC::EvalCodeCache::markAggregate):
              (JSC::CodeBlock::markAggregate):
              * bytecode/CodeBlock.h:
              (JSC::CodeBlock::ownerExecutable):
              (JSC::CodeBlock::addConstant):
              (JSC::CodeBlock::constantRegister):
              (JSC::CodeBlock::getConstant):
              (JSC::CodeBlock::addFunctionDecl):
              (JSC::CodeBlock::addFunctionExpr):
              (JSC::GlobalCodeBlock::GlobalCodeBlock):
              (JSC::ExecState::r):
              * bytecode/EvalCodeCache.h:
              (JSC::EvalCodeCache::get):
              * bytecode/SamplingTool.h:
              (JSC::ScriptSampleRecord::ScriptSampleRecord):
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::addConstantValue):
              (JSC::BytecodeGenerator::emitEqualityOp):
              * bytecompiler/BytecodeGenerator.h:
              (JSC::BytecodeGenerator::makeFunction):
              * debugger/Debugger.cpp:
              (JSC::evaluateInGlobalCallFrame):
              * debugger/DebuggerCallFrame.cpp:
              (JSC::DebuggerCallFrame::evaluate):
              * interpreter/Interpreter.cpp:
              (JSC::Interpreter::callEval):
              * jit/JITInlineMethods.h:
              (JSC::JIT::emitLoadDouble):
              (JSC::JIT::emitLoadInt32ToDouble):
              * jit/JITStubs.cpp:
              (JSC::JITThunks::JITThunks):
              (JSC::JITThunks::hostFunctionStub):
              (JSC::JITThunks::clearHostFunctionStubs):
              * jit/JITStubs.h:
              * runtime/Completion.cpp:
              (JSC::checkSyntax):
              (JSC::evaluate):
              * runtime/Executable.cpp:
              (JSC::EvalExecutable::EvalExecutable):
              (JSC::ProgramExecutable::ProgramExecutable):
              (JSC::FunctionExecutable::FunctionExecutable):
              (JSC::FunctionExecutable::~FunctionExecutable):
              (JSC::EvalExecutable::markChildren):
              (JSC::ProgramExecutable::markChildren):
              (JSC::FunctionExecutable::markChildren):
              (JSC::FunctionExecutable::fromGlobalCode):
              * runtime/Executable.h:
              (JSC::ExecutableBase::ExecutableBase):
              (JSC::ExecutableBase::createStructure):
              (JSC::NativeExecutable::create):
              (JSC::NativeExecutable::NativeExecutable):
              (JSC::VPtrHackExecutable::VPtrHackExecutable):
              (JSC::ScriptExecutable::ScriptExecutable):
              (JSC::EvalExecutable::create):
              (JSC::EvalExecutable::createStructure):
              (JSC::ProgramExecutable::create):
              (JSC::ProgramExecutable::createStructure):
              (JSC::FunctionExecutable::create):
              (JSC::FunctionExecutable::createStructure):
              * runtime/FunctionConstructor.cpp:
              (JSC::constructFunction):
              * runtime/Heap.cpp:
              (JSC::Heap::destroy):
              (JSC::Heap::markRoots):
              * runtime/Heap.h:
              * runtime/JSActivation.cpp:
              (JSC::JSActivation::JSActivation):
              (JSC::JSActivation::markChildren):
              * runtime/JSActivation.h:
              (JSC::JSActivation::JSActivationData::JSActivationData):
              * runtime/JSCell.h:
              * runtime/JSFunction.cpp:
              (JSC::JSFunction::JSFunction):
              (JSC::JSFunction::~JSFunction):
              (JSC::JSFunction::markChildren):
              * runtime/JSFunction.h:
              * runtime/JSGlobalData.cpp:
              (JSC::JSGlobalData::storeVPtrs):
              (JSC::JSGlobalData::JSGlobalData):
              (JSC::JSGlobalData::getHostFunction):
              * runtime/JSGlobalData.h:
              * runtime/JSGlobalObjectFunctions.cpp:
              (JSC::globalFuncEval):
              * runtime/JSObject.cpp:
              * runtime/JSStaticScopeObject.cpp:
              (JSC::JSStaticScopeObject::markChildren):
              * runtime/JSStaticScopeObject.h:
              (JSC::JSStaticScopeObject::JSStaticScopeObjectData::JSStaticScopeObjectData):
              (JSC::JSStaticScopeObject::JSStaticScopeObject):
              * runtime/JSZombie.cpp:
              (JSC::JSZombie::leakedZombieStructure):
              * runtime/JSZombie.h:
              (JSC::JSZombie::createStructure):
              * runtime/MarkedSpace.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@80598 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ba10bec9
  29. 28 Feb, 2011 1 commit
    • oliver@apple.com's avatar
      2011-02-28 Oliver Hunt <oliver@apple.com> · 97cdbd4c
      oliver@apple.com authored
              Reviewed by Gavin Barraclough.
      
              Make ScopeChainNode GC allocated
              https://bugs.webkit.org/show_bug.cgi?id=55283
      
              Simplify lifetime and other issues with the scopechain
              by making it gc allocated.  This allows us to simplify
              function exit and unwinding, as well as making the
              current iterative refcounting go away.
      
              * JavaScriptCore.exp:
              * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
              * bytecode/CodeBlock.cpp:
              (JSC::CodeBlock::createActivation):
              * bytecode/StructureStubInfo.cpp:
              * bytecompiler/BytecodeGenerator.cpp:
              (JSC::BytecodeGenerator::generate):
              (JSC::BytecodeGenerator::BytecodeGenerator):
              (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
              (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
              * bytecompiler/BytecodeGenerator.h:
              * debugger/Debugger.cpp:
              (JSC::Recompiler::operator()):
              * debugger/DebuggerCallFrame.h:
              (JSC::DebuggerCallFrame::scopeChain):
              * interpreter/CachedCall.h:
              (JSC::CachedCall::CachedCall):
              * interpreter/CallFrame.h:
              * interpreter/Interpreter.cpp:
              (JSC::depth):
              (JSC::Interpreter::unwindCallFrame):
              (JSC::Interpreter::throwException):
              (JSC::Interpreter::execute):
              (JSC::Interpreter::executeCall):
              (JSC::Interpreter::executeConstruct):
              (JSC::Interpreter::privateExecute):
              * jit/JITCall.cpp:
              (JSC::JIT::compileOpCallInitializeCallFrame):
              (JSC::JIT::compileOpCall):
              * jit/JITCall32_64.cpp:
              (JSC::JIT::compileOpCallInitializeCallFrame):
              (JSC::JIT::emit_op_ret):
              (JSC::JIT::emit_op_ret_object_or_this):
              (JSC::JIT::compileOpCall):
              * jit/JITOpcodes.cpp:
              (JSC::JIT::emit_op_end):
              (JSC::JIT::emit_op_ret):
              (JSC::JIT::emit_op_ret_object_or_this):
              * jit/JITOpcodes32_64.cpp:
              (JSC::JIT::emit_op_end):
              * jit/JITStubs.cpp:
              (JSC::DEFINE_STUB_FUNCTION):
              * jit/JITStubs.h:
              * runtime/ArgList.cpp:
              * runtime/Completion.cpp:
              (JSC::evaluate):
              * runtime/Completion.h:
              * runtime/DateConversion.cpp:
              * runtime/Executable.cpp:
              (JSC::EvalExecutable::compileInternal):
              (JSC::ProgramExecutable::compileInternal):
              (JSC::FunctionExecutable::compileForCallInternal):
              (JSC::FunctionExecutable::compileForConstructInternal):
              * runtime/FunctionConstructor.cpp:
              (JSC::constructFunction):
              * runtime/GCActivityCallbackCF.cpp:
              * runtime/Identifier.cpp:
              * runtime/JSCell.h:
              * runtime/JSChunk.cpp: Added.
              * runtime/JSChunk.h: Added.
              * runtime/JSFunction.cpp:
              (JSC::JSFunction::JSFunction):
              (JSC::JSFunction::markChildren):
              (JSC::JSFunction::getCallData):
              (JSC::JSFunction::getOwnPropertySlot):
              (JSC::JSFunction::getConstructData):
              * runtime/JSFunction.h:
              (JSC::JSFunction::scope):
              (JSC::JSFunction::setScope):
              * runtime/JSGlobalData.cpp:
              (JSC::JSGlobalData::JSGlobalData):
              * runtime/JSGlobalData.h:
              * runtime/JSGlobalObject.cpp:
              (JSC::JSGlobalObject::init):
              (JSC::JSGlobalObject::markChildren):
              * runtime/JSGlobalObject.h:
              (JSC::JSGlobalObject::JSGlobalObjectData::JSGlobalObjectData):
              (JSC::JSGlobalObject::globalScopeChain):
              * runtime/JSGlobalObjectFunctions.cpp:
              (JSC::globalFuncEval):
              * runtime/JSLock.cpp:
              * runtime/JSNumberCell.cpp:
              * runtime/JSZombie.cpp:
              * runtime/MarkedBlock.cpp:
              * runtime/MarkedSpace.cpp:
              * runtime/PropertyNameArray.cpp:
              * runtime/ScopeChain.cpp:
              (JSC::ScopeChainNode::print):
              (JSC::ScopeChainNode::localDepth):
              (JSC::ScopeChainNode::markChildren):
              * runtime/ScopeChain.h:
              (JSC::ScopeChainNode::ScopeChainNode):
              (JSC::ScopeChainNode::createStructure):
              (JSC::ScopeChainNode::push):
              (JSC::ScopeChainNode::pop):
              (JSC::ScopeChainIterator::ScopeChainIterator):
              (JSC::ScopeChainIterator::operator*):
              (JSC::ScopeChainIterator::operator->):
              (JSC::ScopeChainIterator::operator++):
              (JSC::ScopeChainNode::begin):
              (JSC::ScopeChainNode::end):
              (JSC::ExecState::globalData):
              (JSC::ExecState::lexicalGlobalObject):
              (JSC::ExecState::globalThisValue):
              * runtime/ScopeChainMark.h:
              * wtf/DateMath.cpp:
      2011-02-28  Oliver Hunt  <oliver@apple.com>
      
              Reviewed by Gavin Barraclough.
      
              Make ScopeChainNode GC allocated
              https://bugs.webkit.org/show_bug.cgi?id=55283
      
              Update WebCore to deal with the absence of the ScopeChain
              class.
      
              * ForwardingHeaders/runtime/ScopeChain.h: Added.
              * bindings/js/JSHTMLElementCustom.cpp:
              (WebCore::JSHTMLElement::pushEventHandlerScope):
              * bindings/js/JSJavaScriptCallFrameCustom.cpp:
              (WebCore::JSJavaScriptCallFrame::scopeChain):
              (WebCore::JSJavaScriptCallFrame::scopeType):
              * bindings/js/JSLazyEventListener.cpp:
              (WebCore::JSLazyEventListener::initializeJSFunction):
              * bindings/js/JSMainThreadExecState.h:
              (WebCore::JSMainThreadExecState::evaluate):
              * bindings/js/JSNodeCustom.cpp:
              (WebCore::JSNode::pushEventHandlerScope):
              * bindings/js/JavaScriptCallFrame.cpp:
              (WebCore::JavaScriptCallFrame::scopeChain):
              * bindings/js/JavaScriptCallFrame.h:
              * bindings/scripts/CodeGeneratorJS.pm:
              * bridge/c/c_class.cpp:
              * bridge/c/c_runtime.cpp:
              * bridge/jni/JNIBridge.cpp:
              * bridge/qt/qt_runtime.cpp:
              (JSC::Bindings::QtConnectionObject::execute):
              * plugins/PluginViewNone.cpp:
      2011-02-28  Oliver Hunt  <oliver@apple.com>
      
              Reviewed by Gavin Barraclough.
      
              Make ScopeChainNode GC allocated
              https://bugs.webkit.org/show_bug.cgi?id=55283
      
              More updates for the absence of the ScopeChain class
      
              * WebView/WebScriptDebugDelegate.mm:
              (-[WebScriptCallFrame scopeChain]):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@79904 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      97cdbd4c
  30. 20 Jan, 2011 1 commit
    • ossy@webkit.org's avatar
      Refactoring of the custom allocation framework · 95c1bc42
      ossy@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=49897
      
      Patch by Zoltan Horvath <zoltan@webkit.org> on 2011-01-20
      Reviewed by Csaba Osztrogonác.
      
      Source/JavaScriptCore:
      
      Inheriting from FastAllocBase can result in objects getting larger (bug #33896, #46589).
      The modification replaces Noncopyable and FastAllocBase classes and these inherits with their
      equivalent macro implementation at the necessary places.
      
      * wtf/FastAllocBase.h: Turn FastAllocBase's implementation into a macro.
      
      Source/WebCore:
      
      Inheriting from FastAllocBase can result in objects getting larger (bug #33896, #46589).
      The modification replaces Noncopyable and FastAllocBase classes and these inherits with their
      equivalent macro implementation at the necessary places.
      
      Source/WebKit:
      
      Inheriting from FastAllocBase can result in objects getting larger (bug #33896, #46589).
      The modification replaces Noncopyable and FastAllocBase classes and these inherits with their
      equivalent macro implementation at the necessary places.
      
      Source/WebKit2:
      
      Inheriting from FastAllocBase can result in objects getting larger (bug #33896, #46589).
      The modification replaces Noncopyable and FastAllocBase classes and these inherits with their
      equivalent macro implementation at the necessary places.
      
      Tools:
      
      Inheriting from FastAllocBase can result in objects getting larger (bug #33896, #46589).
      The modification replaces Noncopyable and FastAllocBase classes and these inherits with their
      equivalent macro implementation at the necessary places.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@76248 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      95c1bc42
  31. 10 Jan, 2011 1 commit
    • barraclough@apple.com's avatar
      Bug 52079 - Syntax errors should be early errors. · 7e6bd6d6
      barraclough@apple.com authored
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore: 
      
      From chapter 16 the spec:
          An implementation must report most errors at the time the relevant ECMAScript language construct is
          evaluated. An early error is an error that can be detected and reported prior to the evaluation of
          any construct in the Program containing the error. An implementation must report early errors in a
          Program prior to the first evaluation of that Program. Early errors in eval code are reported at
          the time eval is called but prior to evaluation of any construct within the eval code. All errors
          that are not early errors are runtime errors.
      
          An implementation must treat any instance of the following kinds of errors as an early error:
              * Any syntax error."
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
          Added new files.
      * bytecode/CodeBlock.cpp:
          Removed op_throw_syntax_error.
      * bytecode/Opcode.h:
          Removed op_throw_syntax_error.
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::generate):
          If m_expressionTooDeep then throw a runtime error.
      (JSC::BytecodeGenerator::BytecodeGenerator):
          Initialize m_expressionTooDeep.
      (JSC::BytecodeGenerator::emitThrowExpressionTooDeepException):
          Sets m_expressionTooDeep.
      * bytecompiler/BytecodeGenerator.h:
          Added m_expressionTooDeep, removed emitThrowSyntaxError.
      * bytecompiler/NodesCodegen.cpp:
      (JSC::RegExpNode::emitBytecode):
      (JSC::ContinueNode::emitBytecode):
      (JSC::BreakNode::emitBytecode):
      (JSC::ReturnNode::emitBytecode):
      (JSC::LabelNode::emitBytecode):
          Conditions that threw syntax error are now handled during parsing;
          during bytecompilation these are now just ASSERTs.
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::privateExecute):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      * jit/JIT.h:
      * jit/JITOpcodes.cpp:
      * jit/JITOpcodes32_64.cpp:
      * jit/JITStubs.cpp:
      * jit/JITStubs.h:
          Removed op_throw_syntax_error.
      * parser/ASTBuilder.h:
      (JSC::ASTBuilder::createRegExp):
          Renamed; added syntax check.
      * parser/JSParser.cpp:
      (JSC::JSParser::breakIsValid):
      (JSC::JSParser::hasLabel):
      (JSC::JSParser::Scope::Scope):
      (JSC::JSParser::Scope::setIsFunction):
      (JSC::JSParser::Scope::isFunctionBoundary):
      (JSC::JSParser::ScopeRef::hasContainingScope):
      (JSC::JSParser::ScopeRef::containingScope):
      (JSC::JSParser::AutoPopScopeRef::AutoPopScopeRef):
      (JSC::JSParser::AutoPopScopeRef::~AutoPopScopeRef):
      (JSC::JSParser::AutoPopScopeRef::setPopped):
      (JSC::JSParser::popScopeInternal):
      (JSC::JSParser::popScope):
      (JSC::jsParse):
      (JSC::JSParser::JSParser):
      (JSC::JSParser::parseProgram):
      (JSC::JSParser::parseBreakStatement):
      (JSC::JSParser::parseContinueStatement):
      (JSC::JSParser::parseReturnStatement):
      (JSC::JSParser::parseTryStatement):
      (JSC::JSParser::parseFunctionInfo):
      (JSC::JSParser::parseExpressionOrLabelStatement):
      (JSC::JSParser::parsePrimaryExpression):
      * parser/JSParser.h:
      * parser/Nodes.h:
      * parser/Parser.cpp:
      (JSC::Parser::parse):
      * parser/SyntaxChecker.h:
      (JSC::SyntaxChecker::createRegExp):
          Renamed; added syntax check.
      * runtime/ExceptionHelpers.cpp:
      (JSC::createOutOfMemoryError):
      (JSC::throwOutOfMemoryError):
      * runtime/ExceptionHelpers.h:
          Broke out createOutOfMemoryError.
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal):
          Add check for exception after bytecode generation.
      * runtime/RegExpConstructor.cpp:
      (JSC::constructRegExp):
      * runtime/RegExpPrototype.cpp:
      (JSC::regExpProtoFuncCompile):
          RegExp error prefixes not included in error string.
      * yarr/RegexParser.h:
      (JSC::Yarr::Parser::parse):
          Removed regexBegin/regexEnd/regexError.
      * yarr/RegexPattern.cpp:
      (JSC::Yarr::RegexPatternConstructor::regexBegin):
          Removed regexEnd/regexError.
      (JSC::Yarr::compileRegex):
          Add call to regexBegin (no longer called from the parser).
      * yarr/YarrSyntaxChecker.cpp: Added.
      (JSC::Yarr::SyntaxChecker::assertionBOL):
      (JSC::Yarr::SyntaxChecker::assertionEOL):
      (JSC::Yarr::SyntaxChecker::assertionWordBoundary):
      (JSC::Yarr::SyntaxChecker::atomPatternCharacter):
      (JSC::Yarr::SyntaxChecker::atomBuiltInCharacterClass):
      (JSC::Yarr::SyntaxChecker::atomCharacterClassBegin):
      (JSC::Yarr::SyntaxChecker::atomCharacterClassAtom):
      (JSC::Yarr::SyntaxChecker::atomCharacterClassRange):
      (JSC::Yarr::SyntaxChecker::atomCharacterClassBuiltIn):
      (JSC::Yarr::SyntaxChecker::atomCharacterClassEnd):
      (JSC::Yarr::SyntaxChecker::atomParenthesesSubpatternBegin):
      (JSC::Yarr::SyntaxChecker::atomParentheticalAssertionBegin):
      (JSC::Yarr::SyntaxChecker::atomParenthesesEnd):
      (JSC::Yarr::SyntaxChecker::atomBackReference):
      (JSC::Yarr::SyntaxChecker::quantifyAtom):
      (JSC::Yarr::SyntaxChecker::disjunction):
      (JSC::Yarr::checkSyntax):
      * yarr/YarrSyntaxChecker.h: Added.
          Check RegExp syntax.
      
      LayoutTests: 
      
      Fix syntax errors in layout tests, and update expected results.
      
      * editing/selection/select-crash-001.html:
      * editing/selection/select-crash-002.html:
      * fast/canvas/webgl/renderbuffer-initialization.html:
      * fast/forms/25153.html:
      * fast/forms/textfield-drag-into-disabled.html:
      * fast/js/exception-codegen-crash-expected.txt:
      * fast/js/exception-codegen-crash.html:
      * fast/js/kde/parse-expected.txt:
      * fast/js/kde/script-tests/parse.js:
      * fast/js/large-expressions-expected.txt:
      * fast/js/named-function-expression-expected.txt:
      * fast/js/parser-syntax-check-expected.txt:
      * fast/js/script-tests/large-expressions.js:
      * fast/js/script-tests/named-function-expression.js:
      * fast/js/script-tests/parser-syntax-check.js:
      * fast/js/sputnik/Conformance/12_Statement/12.6_Iteration_Statements/12.6.3_The_for_Statement/S12.6.3_A11.1_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.6_Iteration_Statements/12.6.3_The_for_Statement/S12.6.3_A11_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.6_Iteration_Statements/12.6.3_The_for_Statement/S12.6.3_A12.1_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.6_Iteration_Statements/12.6.3_The_for_Statement/S12.6.3_A12_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A1_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A1_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A1_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A1_T4-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A5_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A5_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A5_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A6-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A8_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.7_The_continue_Statement/S12.7_A8_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A1_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A1_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A1_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A1_T4-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A5_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A5_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A5_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A6-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A8_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.8_The_break_Statement/S12.8_A8_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T1-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T10-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T2-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T3-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T4-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T5-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T6-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T7-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T8-expected.txt:
      * fast/js/sputnik/Conformance/12_Statement/12.9_The_return_Statement/S12.9_A1_T9-expected.txt:
      * http/tests/security/isolatedWorld/events.html:
      * http/tests/security/isolatedWorld/userGestureEvents.html:
      * svg/custom/resources/use-instanceRoot-event-listeners.js:
      * svg/custom/rgbcolor-syntax.svg:
      * svg/custom/use-instanceRoot-modifications.svg:
      * svg/custom/use-property-changes-through-svg-dom.svg:
      * webarchive/adopt-attribute-styled-body-webarchive-expected.webarchive:
      * webarchive/resources/adopt-attribute-styled-body-iframe.html:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75408 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7e6bd6d6
  32. 01 Jan, 2011 1 commit
    • abarth@webkit.org's avatar
      Move JavaScriptCore to Source · 76da8fc1
      abarth@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=51604
      
      Reviewed by Eric Seidel.
      
      Update references to JavaScriptCore to point to the new location.
      
      * Android.mk:
      * CMakeLists.txt:
      * DerivedSources.pro:
      * GNUmakefile.am:
      * Makefile:
      * WebKit.pri:
      * WebKit.pro:
      * wscript:
      
      Tools: 
      
      Update references to JavaScriptCore to point to the new location.
      
      * BuildSlaveSupport/build.webkit.org-config/master.cfg:
      * DumpRenderTree/qt/DumpRenderTree.pro:
      * DumpRenderTree/qt/ImageDiff.pro:
      * DumpRenderTree/qt/TestNetscapePlugin/TestNetscapePlugin.pro:
      * DumpRenderTree/wscript:
      * Scripts/build-jsc:
      * Scripts/build-webkit:
      * Scripts/do-file-rename:
      * Scripts/do-webcore-rename:
      * Scripts/run-javascriptcore-tests:
      * Scripts/update-javascriptcore-test-results:
      * Scripts/webkitdirs.pm:
      * Scripts/webkitpy/common/config/build_unittest.py:
      * Scripts/webkitpy/style/checker.py:
      * Scripts/webkitpy/style/checker_unittest.py:
      * Scripts/webkitpy/style/checkers/cpp_unittest.py:
      * WebKitTestRunner/InjectedBundle/qt/InjectedBundle.pro:
      * WebKitTestRunner/qt/WebKitTestRunner.pro:
      * wx/build/settings.py:
      
      WebCore: 
      
      Update references to JavaScriptCore.
      
      * Android.derived.jscbindings.mk:
      * Android.v8bindings.mk:
      * CMakeLists.txt:
      * WebCore.gyp/WebCore.gyp:
      * WebCore.pro:
        - These changes are subtle and might not be 100% correct.
      * move-js-headers.sh:
      
      WebKit/chromium: 
      
      * WebKit.gyp:
        - Point to JavaScriptCore in its new location.
      
      WebKit/gtk: 
      
      * GNUmakefile.am:
      * docs/GNUmakefile.am:
        - Point to JavaScriptCore in its new location.
      
      WebKit/qt: 
      
      * WebKit_pch.h:
      * docs/qtwebkit.qdocconf:
        - Point to JavaScriptCore in its new location.
      
      WebKit/win: 
      
      * WebKit.vcproj/WebKit.sln:
        - Point to JavaScriptCore in its new location.
      
      WebKit/wx: 
      
      * bindings/python/wscript:
      * wscript:
        - Point to JavaScriptCore in its new location.
      
      WebKit2: 
      
      * WebKit2.pro:
        - Point to JavaScriptCore in its new location.
      
      Websites/bugs.webkit.org: 
      
      * PrettyPatch/PrettyPatch.rb:
        - Remove reference to JavaScriptCore as a source directory.
      
      Websites/webkit.org: 
      
      * coding/assertion-guidelines.html:
        - Update documentation to point to the new location of
          JavaScriptCore.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@74855 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      76da8fc1
  33. 20 Dec, 2010 1 commit
    • barraclough@apple.com's avatar
      Bug 51358 - Should check stack depth rather than using recursion limits in byte compilation · dd4a6e42
      barraclough@apple.com authored
      Reviewed by Olver Hunt.
      
      The current implementation of recursion limit checking is not safe on smaller stacks.
      Switch to using a common mechanism, shared with the parser, to check recursion limits.
      
      Make bytecompiler use StackBounds. Empirical testing shows emitStrcat to have the largest
      footprint on the stack, at just under 1k on x86-64.  Given this, the default recursion
      check (requiring 4k of available space to recurse) seems reasonable.
      
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      * bytecompiler/BytecodeGenerator.h:
      (JSC::BytecodeGenerator::emitNode):
      (JSC::BytecodeGenerator::emitNodeInConditionContext):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::BinaryOpNode::emitStrcat):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@74374 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      dd4a6e42