2013-08-28 Filip Pizlo <[email protected]>

CodeBlock compilation and installation should be simplified and rationalized

https://bugs.webkit.org/show_bug.cgi?id=120326

Reviewed by Oliver Hunt.

Previously Executable owned the code for generating JIT code; you always had

to go through Executable. But often you also had to go through CodeBlock,

because ScriptExecutable couldn't have virtual methods, but CodeBlock could.

So you'd ask CodeBlock to do something, which would dispatch through a

virtual method that would select the appropriate Executable subtype's method.

This all meant that the same code would often be duplicated, because most of

the work needed to compile something was identical regardless of code type.

But then we tried to fix this, by having templatized helpers in

ExecutionHarness.h and JITDriver.h. The result was that if you wanted to find

out what happened when you asked for something to be compiled, you'd go on a

wild ride that started with CodeBlock, touched upon Executable, and then

ricocheted into either ExecutionHarness or JITDriver (likely both).

Another awkwardness was that for concurrent compiles, the DFG::Worklist had

super-special inside knowledge of what JITStubs.cpp's cti_optimize would have

done once the compilation finished.

Also, most of the DFG JIT drivers assumed that they couldn't install the

JITCode into the CodeBlock directly - instead they would return it via a

reference, which happened to be a reference to the JITCode pointer in

Executable. This was super weird.

Finally, there was no notion of compiling code into a special CodeBlock that

wasn't used for handling calls into an Executable. I'd like this for FTL OSR

entry.

This patch solves these problems by reducing all of that complexity into just

three primitives:

- Executable::newCodeBlock(). This gives you a new code block, either for call

or for construct, and either to serve as the baseline code or the optimized

code. The new code block is then owned by the caller; Executable doesn't

register it anywhere. The new code block has no JITCode and isn't callable,

but it has all of the bytecode.

- CodeBlock::prepareForExecution(). This takes the CodeBlock's bytecode and

produces a JITCode, and then installs the JITCode into the CodeBlock. This

method takes a JITType, and always compiles with that JIT. If you ask for

JITCode::InterpreterThunk then you'll get JITCode that just points to the

LLInt entrypoints. Once this returns, it is possible to call into the

CodeBlock if you do so manually - but the Executable still won't know about

it so JS calls to that Executable will still be routed to whatever CodeBlock

is associated with the Executable.

- Executable::installCode(). This takes a CodeBlock and makes it the code-for-

entry for that Executable. This involves unlinking the Executable's last

CodeBlock, if there was one. This also tells the GC about any effect on

memory usage and does a bunch of weird data structure rewiring, since

Executable caches some of CodeBlock's fields for the benefit of virtual call

fast paths.

This functionality is then wrapped around three convenience methods:

- Executable::prepareForExecution(). If there is no code block for that

Executable, then one is created (newCodeBlock()), compiled

(CodeBlock::prepareForExecution()) and installed (installCode()).

- CodeBlock::newReplacement(). Asks the Executable for a new CodeBlock that

can serve as an optimized replacement of the current one.

- CodeBlock::install(). Asks the Executable to install this code block.

This patch allows me to kill *a lot* of code and to remove a lot of

specializations for functions vs. not-functions, and a lot of places where we

pass around JITCode references and such. ExecutionHarness and JITDriver are

both gone. Overall this patch has more red than green.

It also allows me to work on FTL OSR entry and tier-up:

- FTL tier-up: this will involve DFGOperations.cpp asking the DFG::Worklist

to do some compilation, but it will require the DFG::Worklist to do

something different than what JITStubs.cpp would want, once the compilation

finishes. This patch introduces a callback mechanism for that purpose.

- FTL OSR entry: this will involve creating a special auto-jettisoned

CodeBlock that is used only for FTL OSR entry. The new set of primitives

allows for this: Executable can vend you a fresh new CodeBlock, and you can

ask that CodeBlock to compile itself with any JIT of your choosing. Or you

can take that CodeBlock and compile it yourself. Previously the act of

producing a CodeBlock-for-optimization and the act of compiling code for it

were tightly coupled; now you can separate them and you can create such

auto-jettisoned CodeBlocks that are used for a one-shot OSR entry.

* CMakeLists.txt:

* GNUmakefile.list.am:

* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

* JavaScriptCore.xcodeproj/project.pbxproj:

* Target.pri:

* bytecode/CodeBlock.cpp:

(JSC::CodeBlock::prepareForExecution):

(JSC::CodeBlock::install):

(JSC::CodeBlock::newReplacement):

(JSC::FunctionCodeBlock::jettisonImpl):

(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):

* bytecode/CodeBlock.h:

(JSC::CodeBlock::hasBaselineJITProfiling):

* bytecode/DeferredCompilationCallback.cpp: Added.

(JSC::DeferredCompilationCallback::DeferredCompilationCallback):

(JSC::DeferredCompilationCallback::~DeferredCompilationCallback):

* bytecode/DeferredCompilationCallback.h: Added.

* dfg/DFGDriver.cpp:

(JSC::DFG::tryCompile):

* dfg/DFGDriver.h:

(JSC::DFG::tryCompile):

* dfg/DFGFailedFinalizer.cpp:

(JSC::DFG::FailedFinalizer::finalize):

(JSC::DFG::FailedFinalizer::finalizeFunction):

* dfg/DFGFailedFinalizer.h:

* dfg/DFGFinalizer.h:

* dfg/DFGJITFinalizer.cpp:

(JSC::DFG::JITFinalizer::finalize):

(JSC::DFG::JITFinalizer::finalizeFunction):

* dfg/DFGJITFinalizer.h:

* dfg/DFGOSRExitPreparation.cpp:

(JSC::DFG::prepareCodeOriginForOSRExit):

* dfg/DFGOperations.cpp:

* dfg/DFGPlan.cpp:

(JSC::DFG::Plan::Plan):

(JSC::DFG::Plan::compileInThreadImpl):

(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):

(JSC::DFG::Plan::finalizeAndNotifyCallback):

* dfg/DFGPlan.h:

* dfg/DFGWorklist.cpp:

(JSC::DFG::Worklist::completeAllReadyPlansForVM):

* ftl/FTLJITFinalizer.cpp:

(JSC::FTL::JITFinalizer::finalize):

(JSC::FTL::JITFinalizer::finalizeFunction):

* ftl/FTLJITFinalizer.h:

* heap/Heap.h:

(JSC::Heap::isDeferred):

* interpreter/Interpreter.cpp:

(JSC::Interpreter::execute):

(JSC::Interpreter::executeCall):

(JSC::Interpreter::executeConstruct):

(JSC::Interpreter::prepareForRepeatCall):

* jit/JITDriver.h: Removed.

* jit/JITStubs.cpp:

(JSC::DEFINE_STUB_FUNCTION):

(JSC::jitCompileFor):

(JSC::lazyLinkFor):

* jit/JITToDFGDeferredCompilationCallback.cpp: Added.

(JSC::JITToDFGDeferredCompilationCallback::JITToDFGDeferredCompilationCallback):

(JSC::JITToDFGDeferredCompilationCallback::~JITToDFGDeferredCompilationCallback):

(JSC::JITToDFGDeferredCompilationCallback::create):

(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):

* jit/JITToDFGDeferredCompilationCallback.h: Added.

* llint/LLIntEntrypoints.cpp:

(JSC::LLInt::setFunctionEntrypoint):

(JSC::LLInt::setEvalEntrypoint):

(JSC::LLInt::setProgramEntrypoint):

* llint/LLIntEntrypoints.h:

* llint/LLIntSlowPaths.cpp:

(JSC::LLInt::jitCompileAndSetHeuristics):

(JSC::LLInt::setUpCall):

* runtime/ArrayPrototype.cpp:

(JSC::isNumericCompareFunction):

* runtime/CommonSlowPaths.cpp:

* runtime/CompilationResult.cpp:

(WTF::printInternal):

* runtime/CompilationResult.h:

* runtime/Executable.cpp:

(JSC::ScriptExecutable::installCode):

(JSC::ScriptExecutable::newCodeBlockFor):

(JSC::ScriptExecutable::newReplacementCodeBlockFor):

(JSC::ScriptExecutable::prepareForExecutionImpl):

* runtime/Executable.h:

(JSC::ScriptExecutable::prepareForExecution):

(JSC::FunctionExecutable::jettisonOptimizedCodeFor):

* runtime/ExecutionHarness.h: Removed.

2013-08-28 Chris Curtis <[email protected]>

https://bugs.webkit.org/show_bug.cgi?id=119548

Refactoring Exception throws.

Reviewed by Geoffrey Garen.

Gardening of exception throws. The act of throwing an exception was being handled in

different ways depending on whether the code was running in the LLint, Baseline JIT,

or the DFG Jit. This made development in the vm exception and error objects difficult.

* runtime/VM.cpp:

(JSC::appendSourceToError):

This function moved from the interpreter into the VM. It views the developers code

(if there is a codeBlock) to extract what was trying to be evaluated when the error

occurred.

(JSC::VM::throwException):

This function takes in the error object and sets the following:

1: The VM's exception stack

2: The VM's exception

3: Appends extra information on the error message(via appendSourceToError)

4: The error object's line number

5: The error object's column number

6: The error object's sourceURL

7: The error object's stack trace (unless it already exists because the developer

created the error object).

(JSC::VM::getExceptionInfo):

(JSC::VM::setExceptionInfo):

(JSC::VM::clearException):

(JSC::clearExceptionStack):

* runtime/VM.h:

(JSC::VM::exceptionOffset):

(JSC::VM::exception):

(JSC::VM::addressOfException):

(JSC::VM::exceptionStack):

VM exception and exceptionStack are now private data members.

* interpreter/Interpreter.h:

(JSC::ClearExceptionScope::ClearExceptionScope):

Created this structure to temporarily clear the exception within the VM. This

needed to see if addition errors occur when setting the debugger as we are

unwinding the stack.

* interpreter/Interpreter.cpp:

(JSC::Interpreter::unwind):

Removed the code that would try to add error information if it did not exist.

All of this functionality has moved into the VM and all error information is set

at the time the error occurs.

The rest of these functions reference the new calling convention to throw an error.

* API/APICallbackFunction.h:

(JSC::APICallbackFunction::call):

* API/JSCallbackConstructor.cpp:

(JSC::constructJSCallback):

* API/JSCallbackObjectFunctions.h:

(JSC::::getOwnPropertySlot):

(JSC::::defaultValue):

(JSC::::put):

(JSC::::putByIndex):

(JSC::::deleteProperty):

(JSC::::construct):

(JSC::::customHasInstance):

(JSC::::call):

(JSC::::getStaticValue):

(JSC::::staticFunctionGetter):

(JSC::::callbackGetter):

* debugger/Debugger.cpp:

(JSC::evaluateInGlobalCallFrame):

* debugger/DebuggerCallFrame.cpp:

(JSC::DebuggerCallFrame::evaluate):

* dfg/DFGAssemblyHelpers.h:

(JSC::DFG::AssemblyHelpers::emitExceptionCheck):

* dfg/DFGOperations.cpp:

(JSC::DFG::operationPutByValInternal):

* ftl/FTLLowerDFGToLLVM.cpp:

(JSC::FTL::LowerDFGToLLVM::callCheck):

* heap/Heap.cpp:

(JSC::Heap::markRoots):

* interpreter/CallFrame.h:

(JSC::ExecState::clearException):

(JSC::ExecState::exception):

(JSC::ExecState::hadException):

* interpreter/Interpreter.cpp:

(JSC::eval):

(JSC::loadVarargs):

(JSC::stackTraceAsString):

(JSC::Interpreter::execute):

(JSC::Interpreter::executeCall):

(JSC::Interpreter::executeConstruct):

(JSC::Interpreter::prepareForRepeatCall):

* interpreter/Interpreter.h:

(JSC::ClearExceptionScope::ClearExceptionScope):

* jit/JITCode.cpp:

(JSC::JITCode::execute):

* jit/JITExceptions.cpp:

(JSC::genericThrow):

* jit/JITOpcodes.cpp:

(JSC::JIT::emit_op_catch):

* jit/JITOpcodes32_64.cpp:

(JSC::JIT::privateCompileCTINativeCall):

(JSC::JIT::emit_op_catch):

* jit/JITStubs.cpp:

(JSC::returnToThrowTrampoline):

(JSC::throwExceptionFromOpCall):

(JSC::DEFINE_STUB_FUNCTION):

(JSC::jitCompileFor):

(JSC::lazyLinkFor):

(JSC::putByVal):

(JSC::cti_vm_handle_exception):

* jit/SlowPathCall.h:

(JSC::JITSlowPathCall::call):

* jit/ThunkGenerators.cpp:

(JSC::nativeForGenerator):

* jsc.cpp:

(functionRun):

(functionLoad):

(functionCheckSyntax):

* llint/LLIntExceptions.cpp:

(JSC::LLInt::doThrow):

(JSC::LLInt::returnToThrow):

(JSC::LLInt::callToThrow):

* llint/LLIntSlowPaths.cpp:

(JSC::LLInt::LLINT_SLOW_PATH_DECL):

* llint/LowLevelInterpreter.cpp:

(JSC::CLoop::execute):

* llint/LowLevelInterpreter32_64.asm:

* llint/LowLevelInterpreter64.asm:

* runtime/ArrayConstructor.cpp:

(JSC::constructArrayWithSizeQuirk):

* runtime/CommonSlowPaths.cpp:

(JSC::SLOW_PATH_DECL):

* runtime/CommonSlowPaths.h:

(JSC::CommonSlowPaths::opIn):

* runtime/CommonSlowPathsExceptions.cpp:

(JSC::CommonSlowPaths::interpreterThrowInCaller):

* runtime/Completion.cpp:

(JSC::evaluate):

* runtime/Error.cpp:

(JSC::addErrorInfo):

(JSC::throwTypeError):

(JSC::throwSyntaxError):

* runtime/Error.h:

(JSC::throwVMError):

* runtime/ExceptionHelpers.cpp:

(JSC::throwOutOfMemoryError):

(JSC::throwStackOverflowError):

(JSC::throwTerminatedExecutionException):

* runtime/Executable.cpp:

(JSC::EvalExecutable::create):

(JSC::FunctionExecutable::produceCodeBlockFor):

* runtime/FunctionConstructor.cpp:

(JSC::constructFunction):

(JSC::constructFunctionSkippingEvalEnabledCheck):

* runtime/JSArray.cpp:

(JSC::JSArray::defineOwnProperty):

(JSC::JSArray::put):

(JSC::JSArray::push):

* runtime/JSCJSValue.cpp:

(JSC::JSValue::toObjectSlowCase):

(JSC::JSValue::synthesizePrototype):

(JSC::JSValue::putToPrimitive):

* runtime/JSFunction.cpp:

(JSC::JSFunction::defineOwnProperty):

* runtime/JSGenericTypedArrayViewInlines.h:

(JSC::::create):

(JSC::::createUninitialized):

(JSC::::validateRange):

(JSC::::setWithSpecificType):

* runtime/JSGlobalObjectFunctions.cpp:

(JSC::encode):

(JSC::decode):

(JSC::globalFuncProtoSetter):

* runtime/JSNameScope.cpp:

(JSC::JSNameScope::put):

* runtime/JSONObject.cpp:

(JSC::Stringifier::appendStringifiedValue):

(JSC::Walker::walk):

* runtime/JSObject.cpp:

(JSC::JSObject::put):

(JSC::JSObject::defaultValue):

(JSC::JSObject::hasInstance):

(JSC::JSObject::defaultHasInstance):

(JSC::JSObject::defineOwnNonIndexProperty):

(JSC::throwTypeError):

* runtime/ObjectConstructor.cpp:

(JSC::toPropertyDescriptor):

* runtime/RegExpConstructor.cpp:

(JSC::constructRegExp):

* runtime/StringObject.cpp:

(JSC::StringObject::defineOwnProperty):

* runtime/StringRecursionChecker.cpp:

(JSC::StringRecursionChecker::throwStackOverflowError):

2013-08-28 Zan Dobersek <[email protected]>

[GTK] Add support for building JSC with FTL JIT enabled

https://bugs.webkit.org/show_bug.cgi?id=120270

Reviewed by Filip Pizlo.

* GNUmakefile.am: Add LLVM_LIBS to the list of linker flags and LLVM_CFLAGS to the list of

compiler flags for the JSC library.

* GNUmakefile.list.am: Add the missing build targets.

* ftl/FTLAbbreviations.h: Include the <cstring> header and use std::strlen. This avoids compilation

failures when using the Clang compiler with the libstdc++ standard library.

(JSC::FTL::mdKindID):

(JSC::FTL::mdString):

2013-08-23 Andy Estes <[email protected]>

Fix issues found by the Clang Static Analyzer

https://bugs.webkit.org/show_bug.cgi?id=120230

Reviewed by Darin Adler.

* API/JSValue.mm:

(valueToString): Don't leak every CFStringRef when in Objective-C GC.

* API/ObjCCallbackFunction.mm:

(JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl): Don't

release m_invocation's target since NSInvocation will do it for us on

-dealloc.

(objCCallbackFunctionForBlock): Tell NSInvocation to retain its target

and -release our reference to the copied block.

* API/tests/minidom.c:

(createStringWithContentsOfFile): Free buffer before returning.

* API/tests/testapi.c:

(createStringWithContentsOfFile): Ditto.

2013-08-26 Brent Fulgham <[email protected]>

[Windows] Unreviewed build fix after r154629.

* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing build files.

* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2013-08-26 Ryosuke Niwa <[email protected]>

Windows build fix attempt after r154629.

* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

2013-08-25 Mark Hahnenberg <[email protected]>

JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage does a check on the length of the ArrayStorage after possible reallocing it

https://bugs.webkit.org/show_bug.cgi?id=120278

Reviewed by Geoffrey Garen.

* runtime/JSObject.cpp:

(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):

2013-08-26 Filip Pizlo <[email protected]>

Fix indention of Executable.h.

Rubber stamped by Mark Hahnenberg.

* runtime/Executable.h:

2013-08-26 Mark Hahnenberg <[email protected]>

Object.defineProperty should be able to create a PropertyDescriptor where m_attributes == 0

https://bugs.webkit.org/show_bug.cgi?id=120314

Reviewed by Darin Adler.

Currently with the way that defineProperty works, we leave a stray low bit set in

PropertyDescriptor::m_attributes in the following code:

var o = {};

Object.defineProperty(o, 100, {writable:true, enumerable:true, configurable:true, value:"foo"});

This is due to the fact that the lowest non-zero attribute (ReadOnly) is represented as 1 << 1

instead of 1 << 0. We then calculate the default attributes as (DontDelete << 1) - 1, which is 0xF,

but only the top three bits mean anything. Even in the case above, the top three bits are set

to 0 but the bottom bit remains set, which causes us to think m_attributes is non-zero.

Since some of these attributes and their corresponding values are exposed in the JavaScriptCore

framework's public C API, it's safer to just change how we calculate the default value, which is

where the weirdness was originating from in the first place.

* runtime/PropertyDescriptor.cpp:

2013-08-24 Sam Weinig <[email protected]>

Add support for Promises

https://bugs.webkit.org/show_bug.cgi?id=120260

Reviewed by Darin Adler.

Add an initial implementation of Promises - http://dom.spec.whatwg.org/#promises.

- Despite Promises being defined in the DOM, the implementation is being put in JSC

in preparation for the Promises eventually being defined in ECMAScript.

* CMakeLists.txt:

* DerivedSources.make:

* DerivedSources.pri:

* GNUmakefile.list.am:

* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

* JavaScriptCore.xcodeproj/project.pbxproj:

* Target.pri:

Add new files.

* jsc.cpp:

Update jsc's GlobalObjectMethodTable to stub out the new QueueTaskToEventLoop callback. This mean's

you can't quite use Promises with with the command line tool yet.

* interpreter/CallFrame.h:

(JSC::ExecState::promisePrototypeTable):

(JSC::ExecState::promiseConstructorTable):

(JSC::ExecState::promiseResolverPrototypeTable):

* runtime/VM.cpp:

(JSC::VM::VM):

(JSC::VM::~VM):

* runtime/VM.h:

Add supporting code for the new static lookup tables.

* runtime/CommonIdentifiers.h:

Add 3 new identifiers, "Promise", "PromiseResolver", and "then".

* runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::reset):

(JSC::JSGlobalObject::visitChildren):

Add supporting code Promise and PromiseResolver's constructors and structures.

* runtime/JSGlobalObject.h:

(JSC::TaskContext::~TaskContext):

Add a new callback to the GlobalObjectMethodTable to post a task on the embedder's runloop.

(JSC::JSGlobalObject::promisePrototype):

(JSC::JSGlobalObject::promiseResolverPrototype):

(JSC::JSGlobalObject::promiseStructure):

(JSC::JSGlobalObject::promiseResolverStructure):

(JSC::JSGlobalObject::promiseCallbackStructure):

(JSC::JSGlobalObject::promiseWrapperCallbackStructure):

Add supporting code Promise and PromiseResolver's constructors and structures.

* runtime/JSPromise.cpp: Added.

* runtime/JSPromise.h: Added.

* runtime/JSPromiseCallback.cpp: Added.

* runtime/JSPromiseCallback.h: Added.

* runtime/JSPromiseConstructor.cpp: Added.

* runtime/JSPromiseConstructor.h: Added.

* runtime/JSPromisePrototype.cpp: Added.

* runtime/JSPromisePrototype.h: Added.

* runtime/JSPromiseResolver.cpp: Added.

* runtime/JSPromiseResolver.h: Added.

* runtime/JSPromiseResolverConstructor.cpp: Added.

* runtime/JSPromiseResolverConstructor.h: Added.

* runtime/JSPromiseResolverPrototype.cpp: Added.

* runtime/JSPromiseResolverPrototype.h: Added.

Add Promise implementation.

2013-08-26 Zan Dobersek <[email protected]>

Plenty of -Wcast-align warnings in KeywordLookup.h

https://bugs.webkit.org/show_bug.cgi?id=120316

Reviewed by Darin Adler.

* KeywordLookupGenerator.py: Use reinterpret_cast instead of a C-style cast when casting

the character pointers to types of larger size. This avoids spewing lots of warnings

in the KeywordLookup.h header when compiling with the -Wcast-align option.

2013-08-26 Gavin Barraclough <[email protected]>

RegExpMatchesArray should not call [[put]]

https://bugs.webkit.org/show_bug.cgi?id=120317

Reviewed by Oliver Hunt.

This will call accessors on the JSObject/JSArray prototypes - so adding an accessor or read-only

property called index or input to either of these prototypes will result in broken behavior.

* runtime/RegExpMatchesArray.cpp:

(JSC::RegExpMatchesArray::reifyAllProperties):

- put -> putDirect

2013-08-24 Filip Pizlo <[email protected]>

FloatTypedArrayAdaptor::toJSValue should almost certainly not use jsNumber() since that attempts int conversions

https://bugs.webkit.org/show_bug.cgi?id=120228

Reviewed by Oliver Hunt.

It turns out that there were three problems:

- Using jsNumber() meant that we were converting doubles to integers and then

possibly back again whenever doing a set() between floating point arrays.

- Slow-path accesses to double typed arrays were slower than necessary because

of the to-int conversion attempt.

- The use of JSValue as an intermediate for converting between differen types

in typedArray.set() resulted in worse code than I had previously expected.

This patch solves the problem by using template double-dispatch to ensure that

that C++ compiler sees the simplest possible combination of casts between any

combination of typed array types, while still preserving JS and typed array

conversion semantics. Conversions are done as follows:

SourceAdaptor::convertTo<TargetAdaptor>(value)

Internally, convertTo() calls one of three possible methods on TargetAdaptor,

with one method for each of int32_t, uint32_t, and double. This means that the

C++ compiler will at worst see a widening cast to one of those types followed

by a narrowing conversion (not necessarily a cast - may have clamping or the

JS toInt32() function).

This change doesn't just affect typedArray.set(); it also affects slow-path

accesses to typed arrays as well. This patch also adds a bunch of new test

coverage.

This change is a ~50% speed-up on typedArray.set() involving floating point

types.

* GNUmakefile.list.am:

* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

* JavaScriptCore.xcodeproj/project.pbxproj:

* runtime/GenericTypedArrayView.h:

(JSC::GenericTypedArrayView::set):

* runtime/JSDataViewPrototype.cpp:

(JSC::setData):

* runtime/JSGenericTypedArrayView.h:

(JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):

(JSC::JSGenericTypedArrayView::setIndexQuickly):

* runtime/JSGenericTypedArrayViewInlines.h:

(JSC::::setWithSpecificType):

(JSC::::set):

* runtime/ToNativeFromValue.h: Added.

(JSC::toNativeFromValue):

* runtime/TypedArrayAdaptors.h:

(JSC::IntegralTypedArrayAdaptor::toJSValue):

(JSC::IntegralTypedArrayAdaptor::toDouble):

(JSC::IntegralTypedArrayAdaptor::toNativeFromInt32):

(JSC::IntegralTypedArrayAdaptor::toNativeFromUint32):

(JSC::IntegralTypedArrayAdaptor::toNativeFromDouble):

(JSC::IntegralTypedArrayAdaptor::convertTo):

(JSC::FloatTypedArrayAdaptor::toJSValue):

(JSC::FloatTypedArrayAdaptor::toDouble):

(JSC::FloatTypedArrayAdaptor::toNativeFromInt32):

(JSC::FloatTypedArrayAdaptor::toNativeFromUint32):

(JSC::FloatTypedArrayAdaptor::toNativeFromDouble):

(JSC::FloatTypedArrayAdaptor::convertTo):

(JSC::Uint8ClampedAdaptor::toJSValue):

(JSC::Uint8ClampedAdaptor::toDouble):

(JSC::Uint8ClampedAdaptor::toNativeFromInt32):

(JSC::Uint8ClampedAdaptor::toNativeFromUint32):

(JSC::Uint8ClampedAdaptor::toNativeFromDouble):

(JSC::Uint8ClampedAdaptor::convertTo):

2013-08-24 Dan Bernstein <[email protected]>

[mac] link against libz in a more civilized manner

https://bugs.webkit.org/show_bug.cgi?id=120258

Reviewed by Darin Adler.

* Configurations/JavaScriptCore.xcconfig: Removed “-lz” from OTHER_LDFLAGS_BASE.

* JavaScriptCore.xcodeproj/project.pbxproj: Added libz.dylib to the JavaScriptCore target’s

Link Binary With Libraries build phase.

2013-08-23 Laszlo Papp <[email protected]>

Failure building with python3

https://bugs.webkit.org/show_bug.cgi?id=106645

Reviewed by Benjamin Poulain.

Use print functions instead of python statements to be compatible with python 3.X and 2.7 as well.

Archlinux has been using python3 and that is what causes issues while packaging QtWebKit along with Qt5.

* disassembler/udis86/itab.py:

(UdItabGenerator.genInsnTable):

* disassembler/udis86/ud_opcode.py:

(UdOpcodeTables.print_table):

* disassembler/udis86/ud_optable.py:

(UdOptableXmlParser.parseDef):

(UdOptableXmlParser.parse):

(printFn):

2013-08-23 Filip Pizlo <[email protected]>

Incorrect TypedArray#set behavior

https://bugs.webkit.org/show_bug.cgi?id=83818

Reviewed by Oliver Hunt and Mark Hahnenberg.

This was so much fun! typedArray.set() is like a memmove on steroids, and I'm

not smart enough to figure out optimal versions for *all* of the cases. But I

did come up with optimal implementations for most of the cases, and I wrote

spec-literal code (i.e. copy via a transfer buffer) for the cases I'm not smart

enough to write optimal code for.

* runtime/JSArrayBufferView.h:

(JSC::JSArrayBufferView::hasArrayBuffer):

* runtime/JSArrayBufferViewInlines.h:

(JSC::JSArrayBufferView::buffer):

(JSC::JSArrayBufferView::existingBufferInButterfly):

(JSC::JSArrayBufferView::neuter):

(JSC::JSArrayBufferView::byteOffset):

* runtime/JSGenericTypedArrayView.h:

* runtime/JSGenericTypedArrayViewInlines.h:

(JSC::::setWithSpecificType):

(JSC::::set):

(JSC::::existingBuffer):

2013-08-23 Alex Christensen <[email protected]>

Re-separating Win32 and Win64 builds.

https://bugs.webkit.org/show_bug.cgi?id=120178

Reviewed by Brent Fulgham.

* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:

Pass PlatformArchitecture as a command line parameter to bash scripts.

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:

* JavaScriptCore.vcxproj/build-generated-files.sh:

Use PlatformArchitecture from command line to determine which object directory to use (obj32 or obj64).

2013-08-22 Filip Pizlo <[email protected]>

build-jsc --ftl-jit should work

https://bugs.webkit.org/show_bug.cgi?id=120194

Reviewed by Oliver Hunt.

* Configurations/Base.xcconfig: CPPFLAGS should include FEATURE_DEFINES

* Configurations/JSC.xcconfig: The 'jsc' tool includes headers where field layout may depend on FEATURE_DEFINES

* Configurations/ToolExecutable.xcconfig: All other tools include headers where field layout may depend on FEATURE_DEFINES

* ftl/FTLLowerDFGToLLVM.cpp: Build fix

(JSC::FTL::LowerDFGToLLVM::compilePutStructure):

(JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):

2013-08-23 Oliver Hunt <[email protected]>

Re-sort xcode project file

* JavaScriptCore.xcodeproj/project.pbxproj:

2013-08-23 Oliver Hunt <[email protected]>

Support in memory compression of rarely used data

https://bugs.webkit.org/show_bug.cgi?id=120143

Reviewed by Gavin Barraclough.

Include zlib in LD_FLAGS and make UnlinkedCodeBlock make use of CompressibleVector. This saves ~200k on google maps.

* Configurations/JavaScriptCore.xcconfig:

* bytecode/UnlinkedCodeBlock.cpp:

(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):

(JSC::UnlinkedCodeBlock::addExpressionInfo):

* bytecode/UnlinkedCodeBlock.h:

2013-08-22 Mark Hahnenberg <[email protected]>

JSObject and JSArray code shouldn't have to tiptoe around garbage collection

https://bugs.webkit.org/show_bug.cgi?id=120179

Reviewed by Geoffrey Garen.

There are many places in the code for JSObject and JSArray where they are manipulating their

Butterfly/Structure, e.g. after expanding their out-of-line backing storage via allocating. Within

these places there are certain "critical sections" where a GC would be disastrous. Gen GC looks

like it will make this dance even more intricate. To make everybody's lives easier we should use

the DeferGC mechanism in these functions to make these GC critical sections both obvious in the

code and trivially safe. Deferring collections will usually only last marginally longer, thus we

should not incur any additional overhead.

* heap/Heap.h:

* runtime/JSArray.cpp:

(JSC::JSArray::unshiftCountSlowCase):

* runtime/JSObject.cpp:

(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):

(JSC::JSObject::createInitialUndecided):

(JSC::JSObject::createInitialInt32):

(JSC::JSObject::createInitialDouble):

(JSC::JSObject::createInitialContiguous):

(JSC::JSObject::createArrayStorage):

(JSC::JSObject::convertUndecidedToArrayStorage):

(JSC::JSObject::convertInt32ToArrayStorage):

(JSC::JSObject::convertDoubleToArrayStorage):

(JSC::JSObject::convertContiguousToArrayStorage):

(JSC::JSObject::increaseVectorLength):

(JSC::JSObject::ensureLengthSlow):

* runtime/JSObject.h:

(JSC::JSObject::putDirectInternal):

(JSC::JSObject::setStructureAndReallocateStorageIfNecessary):

(JSC::JSObject::putDirectWithoutTransition):

2013-08-22 Filip Pizlo <[email protected]>

Update LLVM binary drops and scripts to the latest version from SVN

https://bugs.webkit.org/show_bug.cgi?id=120184

Reviewed by Mark Hahnenberg.

* dfg/DFGPlan.cpp:

(JSC::DFG::Plan::compileInThreadImpl):

2013-08-22 Gavin Barraclough <[email protected]>

Don't leak registers for redeclared variables

https://bugs.webkit.org/show_bug.cgi?id=120174

Reviewed by Geoff Garen.

We currently always allocate registers for new global variables, but these are wasted when the variable is being redeclared.

Only allocate new registers when necessary.

No performance impact.

* interpreter/Interpreter.cpp:

(JSC::Interpreter::execute):

* runtime/Executable.cpp:

(JSC::ProgramExecutable::initializeGlobalProperties):

- Don't allocate the register here.

* runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::addGlobalVar):

- Allocate the register here instead.

2013-08-22 Gavin Barraclough <[email protected]>

https://bugs.webkit.org/show_bug.cgi?id=120128

Remove putDirectVirtual

Unreviewed, checked in commented out code. :-(

* interpreter/Interpreter.cpp:

(JSC::Interpreter::execute):

- delete commented out code

2013-08-22 Gavin Barraclough <[email protected]>

Error.stack should not be enumerable

https://bugs.webkit.org/show_bug.cgi?id=120171

Reviewed by Oliver Hunt.

Breaks ECMA tests.

* runtime/ErrorInstance.cpp:

(JSC::ErrorInstance::finishCreation):

- None -> DontEnum

2013-08-21 Gavin Barraclough <[email protected]>

https://bugs.webkit.org/show_bug.cgi?id=120128

Remove putDirectVirtual

Reviewed by Sam Weinig.

This could most generously be described as 'vestigial'.

No performance impact.

* API/JSObjectRef.cpp:

(JSObjectSetProperty):

- changed to use defineOwnProperty

* debugger/DebuggerActivation.cpp:

* debugger/DebuggerActivation.h:

- remove putDirectVirtual

* interpreter/Interpreter.cpp:

(JSC::Interpreter::execute):

- changed to use defineOwnProperty

* runtime/ClassInfo.h:

* runtime/JSActivation.cpp:

* runtime/JSActivation.h:

* runtime/JSCell.cpp:

* runtime/JSCell.h:

* runtime/JSGlobalObject.cpp:

* runtime/JSGlobalObject.h:

* runtime/JSObject.cpp:

* runtime/JSObject.h:

* runtime/JSProxy.cpp:

* runtime/JSProxy.h:

* runtime/JSSymbolTableObject.cpp:

* runtime/JSSymbolTableObject.h:

- remove putDirectVirtual

* runtime/PropertyDescriptor.h:

(JSC::PropertyDescriptor::PropertyDescriptor):

- added constructor for convenience

2013-08-22 Chris Curtis <[email protected]>

errorDescriptionForValue() should not assume error value is an Object

https://bugs.webkit.org/show_bug.cgi?id=119812

Reviewed by Geoffrey Garen.

Added a check to make sure that the JSValue was an object before casting it as an object. Also, in case the parameterized JSValue

has no type, the function now returns the empty string.

* runtime/ExceptionHelpers.cpp:

(JSC::errorDescriptionForValue):

2013-08-22 Julien Brianceau <[email protected]>

Fix P_DFGOperation_EJS call for MIPS and ARM EABI.

https://bugs.webkit.org/show_bug.cgi?id=120107

Reviewed by Yong Li.

EncodedJSValue parameters must be aligned to even registers for MIPS and ARM EABI.

* dfg/DFGSpeculativeJIT.h:

(JSC::DFG::SpeculativeJIT::callOperation):

2013-08-21 Commit Queue <[email protected]>

Unreviewed, rolling out r154416.

http://trac.webkit.org/changeset/154416

https://bugs.webkit.org/show_bug.cgi?id=120147

Broke Windows builds (Requested by rniwa on #webkit).

* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:

* JavaScriptCore.vcxproj/build-generated-files.sh:

2013-08-21 Gavin Barraclough <[email protected]>

Clarify var/const/function declaration

https://bugs.webkit.org/show_bug.cgi?id=120144

Reviewed by Sam Weinig.

Add methods to JSGlobalObject to declare vars, consts, and functions.

* runtime/Executable.cpp:

(JSC::ProgramExecutable::initializeGlobalProperties):

* runtime/Executable.h:

- Moved declaration code to JSGlobalObject

* runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::addGlobalVar):

- internal implementation of addVar, addConst, addFunction

* runtime/JSGlobalObject.h:

(JSC::JSGlobalObject::addVar):

(JSC::JSGlobalObject::addConst):

(JSC::JSGlobalObject::addFunction):

- Added methods to declare vars, consts, and functions

2013-08-21 Yi Shen <[email protected]>

https://bugs.webkit.org/show_bug.cgi?id=119900

Exception in global setter doesn't unwind correctly

Reviewed by Geoffrey Garen.

Call VM_THROW_EXCEPTION_AT_END in op_put_to_scope if the setter throws exception.

* jit/JITStubs.cpp:

(JSC::DEFINE_STUB_FUNCTION):

2013-08-21 Mark Hahnenberg <[email protected]>

Rename/refactor setButterfly/setStructure

https://bugs.webkit.org/show_bug.cgi?id=120138

Reviewed by Geoffrey Garen.

setButterfly becomes setStructureAndButterfly.

Also removed the Butterfly* argument from setStructure and just implicitly

used m_butterfly internally since that's what every single client of setStructure

was doing already.

* jit/JITStubs.cpp:

(JSC::DEFINE_STUB_FUNCTION):

* runtime/JSObject.cpp:

(JSC::JSObject::notifyPresenceOfIndexedAccessors):

(JSC::JSObject::createInitialUndecided):

(JSC::JSObject::createInitialInt32):

(JSC::JSObject::createInitialDouble):

(JSC::JSObject::createInitialContiguous):

(JSC::JSObject::createArrayStorage):

(JSC::JSObject::convertUndecidedToInt32):

(JSC::JSObject::convertUndecidedToDouble):

(JSC::JSObject::convertUndecidedToContiguous):

(JSC::JSObject::convertUndecidedToArrayStorage):

(JSC::JSObject::convertInt32ToDouble):

(JSC::JSObject::convertInt32ToContiguous):

(JSC::JSObject::convertInt32ToArrayStorage):

(JSC::JSObject::genericConvertDoubleToContiguous):

(JSC::JSObject::convertDoubleToArrayStorage):

(JSC::JSObject::convertContiguousToArrayStorage):

(JSC::JSObject::switchToSlowPutArrayStorage):

(JSC::JSObject::setPrototype):

(JSC::JSObject::putDirectAccessor):

(JSC::JSObject::seal):

(JSC::JSObject::freeze):

(JSC::JSObject::preventExtensions):

(JSC::JSObject::reifyStaticFunctionsForDelete):

(JSC::JSObject::removeDirect):

* runtime/JSObject.h:

(JSC::JSObject::setStructureAndButterfly):

(JSC::JSObject::setStructure):

(JSC::JSObject::putDirectInternal):

(JSC::JSObject::setStructureAndReallocateStorageIfNecessary):

(JSC::JSObject::putDirectWithoutTransition):

* runtime/Structure.cpp:

(JSC::Structure::flattenDictionaryStructure):

2013-08-21 Gavin Barraclough <[email protected]>

https://bugs.webkit.org/show_bug.cgi?id=120127

Remove JSObject::propertyIsEnumerable

Unreviewed typo fix

* runtime/JSObject.h:

- fix typo

2013-08-21 Gavin Barraclough <[email protected]>