- 12 Apr, 2016 1 commit
-
-
hlopko authored
When the embedder sets the heap tracer, V8, during marking, will collect all reachable wrappers, and then ask embedder to trace its heap. The embedder is expected to call PersistentBase::RegisterExternalReference with all wrappers reachable from the given ones. This fixed point iteration happens in MarkCompact::ProcessEphemeralMarking. For more efficient object visiting during marking, we need a special JS_API_OBJECT_TYPE (in tandem with already existing JS_SPECIAL_API_OBJECT_TYPE) and corresponding visitor (JSApiObjectVisitor). BUG=chromium:468240 LOG=no Review URL: https://codereview.chromium.org/1844413002 Cr-Commit-Position: refs/heads/master@{#35412}
-
- 04 Mar, 2016 1 commit
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1765713003 Cr-Commit-Position: refs/heads/master@{#34492}
-
- 03 Mar, 2016 1 commit
-
-
machenbach authored
This reverts commit 2608ecc7. Revert "Specialize helper methods in the LookupIterator by is_element." This reverts commit 6eb483f8. Revert "Avoid SetPropertyInternal if the LookupIterator is NotFound" This reverts commit ca5bd8d4. Revert "Inline fast-bailout-checks for LookupIterator::UpdateProtector" This reverts commit d98570a1. This breaks layout tests with timeouts: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/5060 It also seems to break jsfunfuzz: https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/7930 The other three CLs are reverted to be able to revert the first. BUG=v8:4798 LOG=n TBR=verwaest@chromium.org Review URL: https://codereview.chromium.org/1761593003 Cr-Commit-Position: refs/heads/master@{#34457}
-
- 02 Mar, 2016 1 commit
-
-
verwaest authored
This introduces a new instance type and reorders the JSObject types so any type requiring special LookupIterator support can be identified with a single range check. In addition, it restructures the Next for better performance, avoiding unnecessary calls. BUG= Review URL: https://codereview.chromium.org/1751043002 Cr-Commit-Position: refs/heads/master@{#34429}
-
- 01 Mar, 2016 1 commit
-
-
jochen authored
This means we can't cache templates that have object properties. Disable caching for those. BUG= R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1753643002 Cr-Commit-Position: refs/heads/master@{#34402}
-
- 26 Feb, 2016 3 commits
-
-
jochen authored
We know it's a postive integer BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1739753004 Cr-Commit-Position: refs/heads/master@{#34327}
-
jochen authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1743543002 Cr-Commit-Position: refs/heads/master@{#34326}
-
jochen authored
The keys are always positive integers, so use an UnseededNumberDictionary to store them instead of an ObjectHashTable R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1741623003 Cr-Commit-Position: refs/heads/master@{#34325}
-
- 25 Feb, 2016 1 commit
-
-
mstarzinger authored
This adds explicit setters for the SharedFunctionInfo::function_data field. Such setters are safer because they allow for explicit checking of which values are allowed, and they improve readability because the intended semantics become clear for each call-site. Also fix a cctest case along the way. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1730853005 Cr-Commit-Position: refs/heads/master@{#34297}
-
- 09 Feb, 2016 1 commit
-
-
epertoso authored
BUG= Committed: https://crrev.com/4d46b510caf534d770ce19a01a11b8796304471b Cr-Commit-Position: refs/heads/master@{#33812} Review URL: https://codereview.chromium.org/1609233002 Cr-Commit-Position: refs/heads/master@{#33851}
-
- 08 Feb, 2016 3 commits
-
-
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}
-
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}
-
epertoso authored
BUG= Review URL: https://codereview.chromium.org/1609233002 Cr-Commit-Position: refs/heads/master@{#33812}
-
- 06 Feb, 2016 1 commit
-
-
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}
-
- 03 Feb, 2016 1 commit
-
-
hablich authored
Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a … (patchset #3 id:80001 of https://codereview.chromium.org/1642223003/ ) Reason for revert: Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout. Reference: https://codereview.chromium.org/1652413003/ Original issue's description: > [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. > > This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks. > > BUG=chromium:579009 > LOG=Y > > Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d > Cr-Commit-Position: refs/heads/master@{#33674} TBR=verwaest@chromium.org,ishell@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:579009 Review URL: https://codereview.chromium.org/1660263003 Cr-Commit-Position: refs/heads/master@{#33698}
-
- 02 Feb, 2016 1 commit
-
-
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. This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks. BUG=chromium:579009 LOG=Y Review URL: https://codereview.chromium.org/1642223003 Cr-Commit-Position: refs/heads/master@{#33674}
-
- 27 Jan, 2016 1 commit
-
-
verwaest authored
BUG=chromium:580584 LOG=y Review URL: https://codereview.chromium.org/1632603002 Cr-Commit-Position: refs/heads/master@{#33551}
-
- 18 Jan, 2016 1 commit
-
-
neis authored
BUG=v8:4163,v8:4630 LOG=y R=rossberg Review URL: https://codereview.chromium.org/1590873002 Cr-Commit-Position: refs/heads/master@{#33360}
-
- 27 Dec, 2015 2 commits
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 Cr-Commit-Position: refs/heads/master@{#33042} Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33044}
-
bmeurer authored
Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ ) Reason for revert: Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind Original issue's description: > [runtime] Introduce dedicated JSBoundFunction to represent bound functions. > > According to the ES2015 specification, bound functions are exotic > objects, and thus don't need to be implemented as JSFunctions. So > we introduce a new JSBoundFunction type to represent bound functions > and make them optimizable. This already improves the performance of > calling or constructing bound functions by 10-100x depending on the > use case because we avoid the crazy dance between JavaScript and C++ > that was implemented in v8natives.js previously. > > There's still room for improvement in the performance of actually > creating bound functions, which is also relevant in practice, but > we already have a plan how to accomplish that later. > > The mips/mips64 ports were contributed by akos.palfi@imgtec.com. > > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > BUG=chromium:535408, chromium:571299, v8:4629 > LOG=n > > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 > Cr-Commit-Position: refs/heads/master@{#33042} TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:535408, chromium:571299, v8:4629 Review URL: https://codereview.chromium.org/1552473002 Cr-Commit-Position: refs/heads/master@{#33043}
-
- 26 Dec, 2015 1 commit
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33042}
-
- 24 Nov, 2015 2 commits
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1467473002 Cr-Commit-Position: refs/heads/master@{#32223}
-
epertoso authored
BUG= Review URL: https://codereview.chromium.org/1407313004 Cr-Commit-Position: refs/heads/master@{#32213}
-
- 10 Nov, 2015 1 commit
-
-
http://crrev.com/1367953002epertoso authored
This CL is in preparation for the API change introduced in http://crrev.com/1407313004. BUG= Review URL: https://codereview.chromium.org/1434693008 Cr-Commit-Position: refs/heads/master@{#31930}
-
- 30 Oct, 2015 1 commit
-
-
neis authored
This is in preparation of implementing Reflect.set. Besides making SetSuperProperty and others return Maybe<bool>, this CL also fixes some parts of my previous refactoring of SetProperty and others: It doesn't make sense to take both a language_mode and a should_throw argument. A strict language_mode should imply THROW_ON_ERROR. R=rossberg, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1431443003 Cr-Commit-Position: refs/heads/master@{#31678}
-
- 23 Oct, 2015 1 commit
-
-
neis authored
This is in preparation of implementing Reflect.set. R=rossberg BUG= Review URL: https://codereview.chromium.org/1394983005 Cr-Commit-Position: refs/heads/master@{#31501}
-
- 22 Oct, 2015 1 commit
-
-
neis authored
Proxies are not properly supported yet. R=rossberg BUG=v8:3931 LOG=n Review URL: https://codereview.chromium.org/1417243002 Cr-Commit-Position: refs/heads/master@{#31465}
-
- 21 Oct, 2015 1 commit
-
-
caitpotter88 authored
Add mechanism for adding per-context ECMAScript intrinsics to Template objects, which may be instantiated in multiple contexts. BUG= LOG=N R=jochen@chromium.org, verwaest@chromium.org Review URL: https://codereview.chromium.org/1409593002 Cr-Commit-Position: refs/heads/master@{#31450}
-
- 29 Sep, 2015 1 commit
-
-
vogelheim authored
(This is somewhat experimental; hence protected by #ifdef.) R=epertoso@chromium.org, jochen@chromium.org BUG=chromium:508898 LOG=N Review URL: https://codereview.chromium.org/1367953002 Cr-Commit-Position: refs/heads/master@{#31002}
-
- 24 Sep, 2015 3 commits
-
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4413, v8:4430 LOG=n Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 Cr-Commit-Position: refs/heads/master@{#30900} Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30902}
-
bmeurer authored
Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ ) Reason for revert: Failed on Fuzzer and MIPS bot. Original issue's description: > [es6] Introduce spec compliant IsConstructor. > > There was already a bit on the Map named "function with prototype", > which basically meant that the Map was a map for a JSFunction that could > be used as a constructor. Now this CL generalizes that bit to > IsConstructor, which says that whatever (Heap)Object you are looking at > can be used as a constructor (i.e. the bit is also set for bound > functions that can be used as constructors and proxies that have a > [[Construct]] internal method). > > This way we have a single chokepoint for IsConstructor checking, which > allows us to get rid of the various ways in which we tried to guess > whether something could be used as a constructor or not. > > Drive-by-fix: Renamed IsConstructor on FunctionKind to > IsClassConstructor to resolve the weird name clash, and the > IsClassConstructor name also matches the spec. > > R=jarin@chromium.org, rossberg@chromium.org > BUG=v8:4430 > LOG=n > > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 > Cr-Commit-Position: refs/heads/master@{#30900} TBR=jarin@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4430 Review URL: https://codereview.chromium.org/1360403002 Cr-Commit-Position: refs/heads/master@{#30901}
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4430 LOG=n Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30900}
-
- 03 Sep, 2015 1 commit
-
-
bmeurer authored
This turns the has_instance_call_handler bit on Map into an is_callable bit, that matches the spec definition of IsCallable (i.e. instances have [[Call]] internal methods). Also fix the typeof operator to properly say "function" for everything that is callable. Also remove the (unused) premature %_GetPrototype optimization from Crankshaft, which just complicated the Map bit swap. R=mstarzinger@chromium.org, rossberg@chromium.org, yangguo@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg Review URL: https://codereview.chromium.org/1316933002 Cr-Commit-Position: refs/heads/master@{#30552}
-
- 01 Sep, 2015 1 commit
-
-
mstarzinger authored
This CL us a pure refactoring that makes an empty compilation unit including just "isolate.h" or "contexts.h" but not "objects-inl.h" compile without warnings or errors. This is needed to further reduce the header dependency tangle. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1322883002 Cr-Commit-Position: refs/heads/master@{#30500}
-
- 10 Jul, 2015 1 commit
-
-
verwaest authored
Revert preallocating of descriptors since right now getters and setters cause copying of descriptor arrays BUG= Review URL: https://codereview.chromium.org/1225213008 Cr-Commit-Position: refs/heads/master@{#29579}
-
- 03 Jul, 2015 1 commit
-
-
verwaest authored
Additionally speed up instantiation of ObjectTemplates by preallocating enough space in the descriptor arrays BUG=v8:4184 LOG=n Review URL: https://codereview.chromium.org/1218403002 Cr-Commit-Position: refs/heads/master@{#29468}
-
- 17 Jun, 2015 2 commits
-
-
machenbach authored
Revert of Added constructor call on object in InstantiateObject method (patchset #5 id:80001 of https://codereview.chromium.org/1137693003/) Reason for revert: [Sheriff] This breaks layout test expectations: http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2032/builds/437 See: https://storage.googleapis.com/chromium-layout-test-archives/V8-Blink_Linux_32/437/layout-test-results/fast/dom/create-element-after-stack-overflow-pretty-diff.html Please land a needsmanualrebaseline change on the blink-side before relanding this, if the change was intended. Please include a blink trybot on relanding this. Original issue's description: > Added constructor call on object in InstantiateObject method > > I found after upgrading from 4.2.2 where apinatives.js still > existed to 4.4.56 where everything had been converted to C++ in > api-natives.cc, my constructors for ObjectTemplate instantiated objects > were no longer being called. After investigation, I noticed in > apinatives.js that a new call would handle that, but there was no > corresponding constructor call in api-natives.cc (or anywhere else > along the chain of InstantiateObject), so I added a call to > Execution::Call to actually construct the object. Forgive me if that > isn't the right place to add it (InitializeBody in objects-inl.h also > looked like a good place), or if there's a reason constructors are > not being called. > > I also added myself to the AUTHORS file in this CL. > > Committed: https://crrev.com/e61a957b2a9726294cdd2802a6a2b6e3a9ef657d > Cr-Commit-Position: refs/heads/master@{#29076} TBR=verwaest@chromium.org,svenpanne@chromium.org,dtalley@gmail.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1188233002 Cr-Commit-Position: refs/heads/master@{#29085}
-
dtalley authored
I found after upgrading from 4.2.2 where apinatives.js still existed to 4.4.56 where everything had been converted to C++ in api-natives.cc, my constructors for ObjectTemplate instantiated objects were no longer being called. After investigation, I noticed in apinatives.js that a new call would handle that, but there was no corresponding constructor call in api-natives.cc (or anywhere else along the chain of InstantiateObject), so I added a call to Execution::Call to actually construct the object. Forgive me if that isn't the right place to add it (InitializeBody in objects-inl.h also looked like a good place), or if there's a reason constructors are not being called. I also added myself to the AUTHORS file in this CL. Review URL: https://codereview.chromium.org/1137693003 Cr-Commit-Position: refs/heads/master@{#29076}
-
- 12 Jun, 2015 2 commits
-
-
verwaest authored
BUG=v8:4137 LOG=n Review URL: https://codereview.chromium.org/1178893002 Cr-Commit-Position: refs/heads/master@{#29004}
-
verwaest authored
Reland of Replace SetObjectProperty / DefineObjectProperty with less powerful alternatives where relevant. (patchset #3 id:40001 of https://codereview.chromium.org/1178503004/) BUG=v8:4137 LOG=n Review URL: https://codereview.chromium.org/1180943002 Cr-Commit-Position: refs/heads/master@{#29000}
-