- 09 Feb, 2016 4 commits
-
-
bmeurer authored
Revert of [builtins] Remove bunch of uses of %_Arguments and %_ArgumentsLength. (patchset #1 id:1 of https://codereview.chromium.org/1678953004/ ) Reason for revert: Breaks tree Original issue's description: > [builtins] Remove bunch of uses of %_Arguments and %_ArgumentsLength. > > There are a bunch of places in our builtins where we use %_Arguments and > %_ArgumentsLength for no good reason, as arguments object and/or rest > parameter is as good and performant in these cases. Now the only uses > of %_Arguments and %_ArgumentsLength left are in string.js, which > requires dedicated investigation. > > R=yangguo@chromium.org > > Committed: https://crrev.com/2160429fd458e3c095475e718c97f77ac90d906f > Cr-Commit-Position: refs/heads/master@{#33834} TBR=yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1677063005 Cr-Commit-Position: refs/heads/master@{#33835}
-
bmeurer authored
There are a bunch of places in our builtins where we use %_Arguments and %_ArgumentsLength for no good reason, as arguments object and/or rest parameter is as good and performant in these cases. Now the only uses of %_Arguments and %_ArgumentsLength left are in string.js, which requires dedicated investigation. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1678953004 Cr-Commit-Position: refs/heads/master@{#33834}
-
bmeurer authored
By now only the default %TypedArray%.prototype.sort compare function and the JS implementation of SameValueZero were still using the odd %_IsMinusZero intrinsic, whose semantics both included a number check (actually HeapNumber test) plus testing if the heap number stores the special -0 value. In both cases we already know that we deal with number so we can reduce it to a simple number test for -0, which can be expressed via dividing 1 by that value and checking the sign of the result. In case of the compare function, we can be even smarter and work with the reciprocal values in case x and y are equal to 0 (although long term we should probably rewrite the fast case for the typed array sorting function in C++ anyway, which will be way, way faster than our handwritten callback-style, type-feedback polluted JS implementation). R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1680783002 Cr-Commit-Position: refs/heads/master@{#33833}
-
v8-autoroll authored
Rolling v8/tools/clang to fa731f3e12b54c519e08c0fe9b26cf12274df20c TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1677363003 Cr-Commit-Position: refs/heads/master@{#33832}
-
- 08 Feb, 2016 32 commits
-
-
mbrandy authored
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1675383002 Cr-Commit-Position: refs/heads/master@{#33831}
-
mbrandy authored
Port 2166bd8c R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1677213002 Cr-Commit-Position: refs/heads/master@{#33830}
-
mbrandy authored
Port 3ef573e9 Original commit message: Replace the somewhat awkward RestParamAccessStub, which would always call into the runtime anyway with a proper FastNewRestParameterStub, which is basically based on the code that was already there for strict arguments object materialization. But for rest parameters we could optimize even further (leading to 8-10x improvements for functions with rest parameters), by fixing the internal formal parameter count: Every SharedFunctionInfo has a formal_parameter_count field, which specifies the number of formal parameters, and is used to decide whether we need to create an arguments adaptor frame when calling a function (i.e. if there's a mismatch between the actual and expected parameters). Previously the formal_parameter_count included the rest parameter, which was sort of unfortunate, as that meant that calling a function with only the non-rest parameters still required an arguments adaptor (plus some other oddities). Now with this CL we fix, so that we do no longer include the rest parameter in that count. Thereby checking for rest parameters is very efficient, as we only need to check whether there is an arguments adaptor frame, and if not create an empty array, otherwise check whether the arguments adaptor frame has more parameters than specified by the formal_parameter_count. The FastNewRestParameterStub is written in a way that it can be directly used by Ignition as well, and with some tweaks to the TurboFan backends and the CodeStubAssembler, we should be able to rewrite it as TurboFanCodeStub in the near future. Drive-by-fix: Refactor and unify the CreateArgumentsType which was different in TurboFan and Ignition; now we have a single enum class xwhich is used in both TurboFan and Ignition. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:2159 LOG=n Review URL: https://codereview.chromium.org/1677223002 Cr-Commit-Position: refs/heads/master@{#33829}
-
binji authored
To bring V8 into line with the proposed design changes in: https://github.com/WebAssembly/design/pull/489 (This CL is forked from https://codereview.chromium.org/1634673002/. That CL doesn't merge cleanly, and I can't update it.) TBR=titzer@chromium.org LOG=Y BUG=chromium:575167 Review URL: https://codereview.chromium.org/1682443002 Cr-Commit-Position: refs/heads/master@{#33828}
-
littledan authored
This patch moves Symbol.species support to the "experimental JavaScript features" flag. While @@species is still a performance hit, it doesn't seem like it would make the web unusably slow; shipping would still have to wait on fixing the performance regression, but staging this version should yield valuable web compatibility information. R=cbruni BUG=v8:4093 LOG=Y Review URL: https://codereview.chromium.org/1678143002 Cr-Commit-Position: refs/heads/master@{#33827}
-
littledan authored
ES2016 TypedArray subclassing semantics break the Node.js Buffer module, also used on the web. I wrote a pull request against the web and Node versions to fix the issue, but the pull request has not yet been granted, and this is blocking shipping the change. For now, this patch extends the web compatibility workaround to the --harmony-species flag, so that Symbol.species and associated subclassing semantics can ship independently. R=cbruni BUG=v8:4665 LOG=Y Review URL: https://codereview.chromium.org/1678123002 Cr-Commit-Position: refs/heads/master@{#33826}
-
mbrandy authored
Port 187b3f28 R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1680833002 Cr-Commit-Position: refs/heads/master@{#33825}
-
akos.palfi authored
TEST=cctest/test-interpreter/InterpreterTryCatch, cctest/test-run-bytecode-graph-builder/BytecodeGraphBuilderTryCatch, cctest/test-run-bytecode-graph-builder/BytecodeGraphBuilderTryFinally2 BUG= Review URL: https://codereview.chromium.org/1673333003 Cr-Commit-Position: refs/heads/master@{#33824}
-
mbrandy authored
Port bb883395 Original commit message: This replaces the global remembered set with per-page remembered sets. Each page in the old space, map space, and large object space keeps track of the set of slots in the page pointing to the new space. The data structure for storing slot sets is a two-level bitmap, which allows us to remove the store buffer overflow and SCAN_ON_SCAVENGE logic. Design doc: https://goo.gl/sMKCf7 R=ulan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:578883 LOG=NO Review URL: https://codereview.chromium.org/1679873003 Cr-Commit-Position: refs/heads/master@{#33823}
-
alph authored
Do not rely on elapsed time to collect enough samples. Use CollectSample API function instead. Remove checks for extra functions present in a profile, as there in fact can be lots of native support functions. BUG=v8:2999 LOG=N Review URL: https://codereview.chromium.org/1665303004 Cr-Commit-Position: refs/heads/master@{#33822}
-
rmcilroy authored
Also replace SKIPS by FAIL to ensure tests are reenabled once they work. BUG=v8:4680 LOG=N CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm64_dbg,v8_linux_arm_dbg Review URL: https://codereview.chromium.org/1667323002 Cr-Commit-Position: refs/heads/master@{#33821}
-
mstarzinger authored
This allows us to remove the somewhat awkward BuildLoadObjectField from the BytecodeGraphBuilder and also allows us to simplify the bytecode stream for class literals. R=oth@chromium.org Review URL: https://codereview.chromium.org/1678103002 Cr-Commit-Position: refs/heads/master@{#33820}
-
mythria authored
Adds implementation and tests to support const/let variables in the interpreter. BUG=v8:4280,v8:4679 LOG=N Review URL: https://codereview.chromium.org/1634153002 Cr-Commit-Position: refs/heads/master@{#33819}
-
caitpotter88 authored
Previously, Object.values() and Object.entries() were piggy-backing on Object.keys(). This meant that they would pre-filter non-enumerable properties, violating the runtime behaviour of the methods. Unfortunately, this does not match the current proposal text. Also incorporates several tests verifying this behaviour based on tests included in the ChakraCore implementation. In this reland, the new patch fills up the longer-lasting FixedArray with `undefined` to avoid the crash in Heap::Verify(). Originally reviewed at https://codereview.chromium.org/1637753004 BUG=v8:4663 LOG=N R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org Review URL: https://codereview.chromium.org/1673673002 Cr-Commit-Position: refs/heads/master@{#33818}
-
mstarzinger authored
The flag in question is a debug-only flag supported by full-codegen and Crankshaft only. In it's current form there are some unresolved issues: - The flag is defeated by inlining in Crankshaft. - The flag is not supported by TurboFan. - The flag is not supported by Ignition. Instead of addressing the above issues and increasing maintenance cost for all backends and also given the "slim" test coverage, this CL fully removes the support from all backends. R=bmeurer@chromium.org,jkummerow@chromium.org Review URL: https://codereview.chromium.org/1676263002 Cr-Commit-Position: refs/heads/master@{#33817}
-
verwaest authored
Generally we only care whether the next object is a hidden prototype. It's simpler to check whether the current object has a hidden prototype instead of walking to the next prototype and checking its map. BUG= Review URL: https://codereview.chromium.org/1675223002 Cr-Commit-Position: refs/heads/master@{#33816}
-
bmeurer authored
This allows us to remove the somewhat awkward BuildLoadObjectField from the AstGraphBuilder and also allows us to simplify fullcodegen for class literals. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1679813002 Cr-Commit-Position: refs/heads/master@{#33815}
-
machenbach authored
Revert of Do not eagerly instantiate accessors' JSFunction. (patchset #9 id:180001 of https://codereview.chromium.org/1609233002/ ) Reason for revert: [Sheriff] Breaks gcmole: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gcmole/builds/6260 Original issue's description: > Do not eagerly instantiate accessors' JSFunction. > > BUG= > > Committed: https://crrev.com/4d46b510caf534d770ce19a01a11b8796304471b > Cr-Commit-Position: refs/heads/master@{#33812} TBR=verwaest@chromium.org,epertoso@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1679683004 Cr-Commit-Position: refs/heads/master@{#33814}
-
bmeurer authored
This moves the JSCreate related functionality from JSTypedLowering into a dedicated JSCreateLowering reducer. This is in preparation of landing the support for optimized literals in TurboFan, which would blow up JSTypedLowering quite seriously otherwise. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1678833002 Cr-Commit-Position: refs/heads/master@{#33813}
-
epertoso authored
BUG= Review URL: https://codereview.chromium.org/1609233002 Cr-Commit-Position: refs/heads/master@{#33812}
-
jacob.bramley authored
BUG= Review URL: https://codereview.chromium.org/1678043002 Cr-Commit-Position: refs/heads/master@{#33811}
-
yangguo authored
The serializer collects objects in iteration order, not in allocation order. This means that the deserializer will put these objects in iteration order onto the reserved pages as well. There is no guarantee that objects that were on the first page will end up on the first page after deserialization. Until now we got lucky, since we only ever need one space per page for the default snapshot. For roots, the iteration order and allocation order also do not differ enough to cause any issue for immortal immovable root objects. These objects need to stay on the first page of its allocated space to not move. However, let's make sure it stays this way, and we realize soon enough if this assumption does not hold. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1675553002 Cr-Commit-Position: refs/heads/master@{#33810}
-
bmeurer authored
Replace the somewhat awkward RestParamAccessStub, which would always call into the runtime anyway with a proper FastNewRestParameterStub, which is basically based on the code that was already there for strict arguments object materialization. But for rest parameters we could optimize even further (leading to 8-10x improvements for functions with rest parameters), by fixing the internal formal parameter count: Every SharedFunctionInfo has a formal_parameter_count field, which specifies the number of formal parameters, and is used to decide whether we need to create an arguments adaptor frame when calling a function (i.e. if there's a mismatch between the actual and expected parameters). Previously the formal_parameter_count included the rest parameter, which was sort of unfortunate, as that meant that calling a function with only the non-rest parameters still required an arguments adaptor (plus some other oddities). Now with this CL we fix, so that we do no longer include the rest parameter in that count. Thereby checking for rest parameters is very efficient, as we only need to check whether there is an arguments adaptor frame, and if not create an empty array, otherwise check whether the arguments adaptor frame has more parameters than specified by the formal_parameter_count. The FastNewRestParameterStub is written in a way that it can be directly used by Ignition as well, and with some tweaks to the TurboFan backends and the CodeStubAssembler, we should be able to rewrite it as TurboFanCodeStub in the near future. Drive-by-fix: Refactor and unify the CreateArgumentsType which was different in TurboFan and Ignition; now we have a single enum class which is used in both TurboFan and Ignition. R=jarin@chromium.org, rmcilroy@chromium.org TBR=rossberg@chromium.org BUG=v8:2159 LOG=n Review URL: https://codereview.chromium.org/1676883002 Cr-Commit-Position: refs/heads/master@{#33809}
-
ivica.bogosavljevic authored
Fix failures on MIPS simulator because incomplete handling of MTHC1 and MFHC1 in Fp32 mode Fix failures on older kernels that have problems with MTHC1 and MFHC1 in kernel FPU emulation Original issue's description: > Revert of MIPS: Add FPXX support to MIPS32R2 (patchset #3 > id:40001 of https://codereview.chromium.org/1586223004/ ) > > Reason for revert: > Revert patch due to a number of failures appearing on the > MIPS v8 simulator > > Original issue's description: >> MIPS: Add FPXX support to MIPS32R2 >> >> The JIT code generated by V8 is FPXX compliant >> when v8 compiled with FPXX flag. This allows the code to >> run in both FP=1 and FP=0 mode. It also alows v8 to be used >> as a library by both FP32 and FP64 binaries. >> >> BUG= >> >> Committed: https://crrev.com/95110dde666158a230a823fd50a68558ad772320 >> Cr-Commit-Position: refs/heads/master@{#33576} BUG= Review URL: https://codereview.chromium.org/1659883002 Cr-Commit-Position: refs/heads/master@{#33808}
-
jacob.bramley authored
This is effectively a port of 4eff883b (r27731). BUG= Review URL: https://codereview.chromium.org/1671883003 Cr-Commit-Position: refs/heads/master@{#33807}
-
ulan authored
This replaces the global remembered set with per-page remembered sets. Each page in the old space, map space, and large object space keeps track of the set of slots in the page pointing to the new space. The data structure for storing slot sets is a two-level bitmap, which allows us to remove the store buffer overflow and SCAN_ON_SCAVENGE logic. Design doc: https://goo.gl/sMKCf7 BUG=chromium:578883 LOG=NO Review URL: https://codereview.chromium.org/1608583002 Cr-Commit-Position: refs/heads/master@{#33806}
-
verwaest authored
This speeds up base constructor instantiation by ~3x. BUG= Review URL: https://codereview.chromium.org/1673163002 Cr-Commit-Position: refs/heads/master@{#33805}
-
machenbach authored
Useful for example for using atomicops_internal_portable.h on Android. BUG=v8:4615 LOG=y patch from issue 1525813002 at patchset 1 (http://crrev.com/1525813002#ps1) Review URL: https://codereview.chromium.org/1637473003 Cr-Commit-Position: refs/heads/master@{#33804}
-
yangguo authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1674023003 Cr-Commit-Position: refs/heads/master@{#33803}
-
bmeurer authored
The preallocated JSAccessorPropertyDescriptor, JSDataPropertyDescriptor and JSIteratorResult had the constructor field unset, which in turn causes GetCreationContext() to fail for those instances. R=verwaest@chromium.org BUG=v8:4738 LOG=n Review URL: https://codereview.chromium.org/1676823002 Cr-Commit-Position: refs/heads/master@{#33802}
-
yangguo authored
TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1674153002 Cr-Commit-Position: refs/heads/master@{#33801}
-
bmeurer authored
It's fine to use JS_OBJECT_TYPE for JSIteratorResult and only have a preallocated initial map for them to avoid unnecessary polymorphism from generators / builtin iterators. The instance type doesn't provide any advantage, since we always have to treat JSIteratorResult objects as regular JSObjects later. R=yangguo@chromium.org TBR=hpayer@chromium.org Review URL: https://codereview.chromium.org/1680513002 Cr-Commit-Position: refs/heads/master@{#33800}
-
- 07 Feb, 2016 1 commit
-
-
v8-autoroll authored
Rolling v8/build/gyp to 57190fa278689da857c6dfd6b4886dbfddce98ce TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1679673002 Cr-Commit-Position: refs/heads/master@{#33799}
-
- 06 Feb, 2016 3 commits
-
-
ishell authored
[api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor. Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate. When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map. ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to. The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object. BUG=chromium:579009 LOG=Y Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d Cr-Commit-Position: refs/heads/master@{#33674} Review URL: https://codereview.chromium.org/1642223003 Cr-Commit-Position: refs/heads/master@{#33798}
-
jing.bao authored
BUG= Review URL: https://codereview.chromium.org/1627263002 Cr-Commit-Position: refs/heads/master@{#33797}
-
jing.bao authored
BUG= Review URL: https://codereview.chromium.org/1628133002 Cr-Commit-Position: refs/heads/master@{#33796}
-