- 08 Apr, 2016 1 commit
-
-
hablich authored
Revert of Migrate FastCloneShallowObjectStub to TurboFan (patchset #7 id:140001 of https://codereview.chromium.org/1838283003/ ) Reason for revert: Makes some WebGL tests flaky: https://codereview.chromium.org/1866373002/ Bisection on tryserver shows this as the culprit. Local repro unfortunately does not work. Original issue's description: > Migrate FastCloneShallowObjectStub to TurboFan > > BUG= > > Committed: https://crrev.com/4c2b04542f263b2679194f9fb75672ebbe72b924 > Cr-Commit-Position: refs/heads/master@{#35330} TBR=bmeurer@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review URL: https://codereview.chromium.org/1875683002 Cr-Commit-Position: refs/heads/master@{#35353}
-
- 07 Apr, 2016 2 commits
-
-
cbruni authored
Pushing undefined onto a FAST_DOUBLE_ARRAY does not enforce the right representation checks. BUG=chromuim:599089 LOG=n Review URL: https://codereview.chromium.org/1868973002 Cr-Commit-Position: refs/heads/master@{#35332}
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1838283003 Cr-Commit-Position: refs/heads/master@{#35330}
-
- 01 Apr, 2016 1 commit
-
-
jochen authored
We expect that the majority of malloc'd memory held by V8 is allocated in Zone objects. Introduce an Allocator class that is used by Zones to manage memory, and allows for querying the current usage. BUG=none R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org LOG=n TBR=rossberg@chromium.org Review URL: https://codereview.chromium.org/1847543002 Cr-Commit-Position: refs/heads/master@{#35196}
-
- 23 Mar, 2016 1 commit
-
-
verwaest authored
Deoptimizing from the stub is fairly slow, so add support for the other fast-path cases to avoid deopts. Notably, push with multi-arg is used by pdfjs. BUG=chromium:597252 LOG=n Review URL: https://codereview.chromium.org/1825843002 Cr-Commit-Position: refs/heads/master@{#35037}
-
- 22 Mar, 2016 1 commit
-
-
verwaest authored
This roughly doubles performance for generic Array.prototype.push. BUG= Review URL: https://codereview.chromium.org/1816553002 Cr-Commit-Position: refs/heads/master@{#34987}
-
- 21 Mar, 2016 1 commit
-
-
bmeurer authored
Up until now all type conversions (i.e. ToNumber, ToString and friends) had their own specific call interface descriptors, where some of them had to match (i.e. ToString and NumberToString have to use the same argument register). Instead of all the different descriptors, it's sufficient to have a single TypeConversionDescriptor instead. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1823523002 Cr-Commit-Position: refs/heads/master@{#34916}
-
- 02 Mar, 2016 1 commit
-
-
epertoso authored
The macro is currently used by AllocateHeapNumberStub and AllocateMutableHeapNumberStub, which are now turbofan code stubs. It can be used to allocate objects in the new or old space, optionally with double alignment. BUG=588692 LOG=y Review URL: https://codereview.chromium.org/1735803003 Cr-Commit-Position: refs/heads/master@{#34424}
-
- 29 Feb, 2016 1 commit
-
-
bmeurer authored
Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match our naming convention, and add a new TurboFan-powered ToBooleanStub, which just does the ToBoolean conversion without any runtime call or code patching, so we can use it for Ignition (and TurboFan). Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we already have for to_string and to_number, so we don't need to actually dispatch on the concrete Oddball at all. R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/1744163002 Cr-Commit-Position: refs/heads/master@{#34361}
-
- 27 Feb, 2016 1 commit
-
-
bmeurer authored
Since both null and undefined are also marked as undetectable now, we can just test that bit instead of having the CompareNilIC try to collect feedback to speed up the general case (without the undetectable bit being used). Drive-by-fix: Update the type system to match the new handling of undetectable in the runtime. R=danno@chromium.org Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba Cr-Commit-Position: refs/heads/master@{#34237} Review URL: https://codereview.chromium.org/1722193002 Cr-Commit-Position: refs/heads/master@{#34344}
-
- 26 Feb, 2016 1 commit
-
-
adamk authored
Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of https://codereview.chromium.org/1722193002/ ) Reason for revert: Speculative revert in attempt to fix #2 crasher on canary. Original issue's description: > [compiler] Drop the CompareNilIC. > > Since both null and undefined are also marked as undetectable now, we > can just test that bit instead of having the CompareNilIC try to collect > feedback to speed up the general case (without the undetectable bit > being used). > > Drive-by-fix: Update the type system to match the new handling of > undetectable in the runtime. > > R=danno@chromium.org > > Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba > Cr-Commit-Position: refs/heads/master@{#34237} TBR=danno@chromium.org,verwaest@chromium.org,bmeurer@chromium.org LOG=y BUG=chromium:589897 NOTRY=true Review URL: https://codereview.chromium.org/1743433002 Cr-Commit-Position: refs/heads/master@{#34308}
-
- 24 Feb, 2016 1 commit
-
-
bmeurer authored
Since both null and undefined are also marked as undetectable now, we can just test that bit instead of having the CompareNilIC try to collect feedback to speed up the general case (without the undetectable bit being used). Drive-by-fix: Update the type system to match the new handling of undetectable in the runtime. R=danno@chromium.org Review URL: https://codereview.chromium.org/1722193002 Cr-Commit-Position: refs/heads/master@{#34237}
-
- 17 Feb, 2016 1 commit
-
-
mstarzinger authored
R=rossberg@chromium.org,bmeurer@chromium.org,verwaest@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1700993002 Cr-Commit-Position: refs/heads/master@{#34067}
-
- 16 Feb, 2016 2 commits
-
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1693833002 Cr-Commit-Position: refs/heads/master@{#34036}
-
danno authored
Before this CL, the context of the parent frame was used when deoptimizing a stub failure rather than the context value passed to the stub itself. In order to guarantee that the right context is passed to the runtime upon stub failure, this CL adds the context explicitly to the stub's environment that's used to compute the failure deoptimizing translations. The context can then be extracted during deoptimization translation to ensure that the precise context that was passed to the stub is also passed to the runtime. R=jarin@chromium.org LOG=N Review URL: https://codereview.chromium.org/1694183003 Cr-Commit-Position: refs/heads/master@{#34030}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@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/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 1 commit
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
- 02 Feb, 2016 1 commit
-
-
jarin authored
This CL removes the Config templatization from the types. It is not necessary anymore, after the HeapTypes have been removed. The CL also changes the type hierarchy - the specific type kinds are not inner classes of the Type class and they do not inherit from Type. This is partly because it seems impossible to make this work without templates. Instead, a new TypeBase class is introduced and all the structural (i.e., non-bitset) types inherit from it. The bitset type still requires the bit-munging hack and some nasty reinterpret-casts to pretend bitsets are of type Type*. Additionally, there is now the same hack for TypeBase - all pointers to the sub-types of TypeBase are reinterpret-casted to Type*. This is to keep the type constructors in inline method definitions (although it is unclear how much that actually buys us). In future, we would like to move to a model where we encapsulate Type* into a class (or possibly use Type where we used to use Type*). This would loosen the coupling between bitset size and pointer size, and eventually we would be able to have more bits. TBR=bradnelson@chromium.org Review URL: https://codereview.chromium.org/1655833002 Cr-Commit-Position: refs/heads/master@{#33656}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@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/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # 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/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
- 20 Jan, 2016 1 commit
-
-
danno authored
The motivation for this is that CompilationInfo really shouldn't explicitly know anything about CodeStubs. This is evident in the TurboFan stubs pipeline, which only needs to pass down information about Code::Flags to the code generator and not any of the CallInterfaceDescriptor silliness that Hydrogen has to push around, since TF has the Linkage class that encapsulates everything that is needed for the stub ABI. So, instead of threading CodeStub machinery through the TF stub pipeline, it is now removed from CompilationInfo and replaced by only the explicit bits needed both by the Crankshaft and TF pipelines in code generation. Review URL: https://codereview.chromium.org/1604543002 Cr-Commit-Position: refs/heads/master@{#33410}
-
- 16 Dec, 2015 1 commit
-
-
bmeurer authored
The TypeOfStub didn't test the undetectable bit properly if the instance was also callable, and therefore returned "object" for document.all (which is both undetectable and callable). CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel R=yangguo@chromium.org BUG=chromium:567998 LOG=n Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc Cr-Commit-Position: refs/heads/master@{#32852} Review URL: https://codereview.chromium.org/1527863003 Cr-Commit-Position: refs/heads/master@{#32883}
-
- 15 Dec, 2015 2 commits
-
-
machenbach authored
Revert of [stubs] Fix TypeOfStub to properly return "undefined" for undetectable. (patchset #1 id:1 of https://codereview.chromium.org/1527863003/ ) Reason for revert: [Sheriff] Changes layout tests. Please fix upstream first: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3491 Original issue's description: > [stubs] Fix TypeOfStub to properly return "undefined" for undetectable. > > The TypeOfStub didn't test the undetectable bit properly if the instance > was also callable, and therefore returned "object" for document.all > (which is both undetectable and callable). > > R=yangguo@chromium.org > BUG=chromium:567998 > LOG=n > > Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc > Cr-Commit-Position: refs/heads/master@{#32852} TBR=yangguo@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:567998 Review URL: https://codereview.chromium.org/1525703003 Cr-Commit-Position: refs/heads/master@{#32855}
-
bmeurer authored
The TypeOfStub didn't test the undetectable bit properly if the instance was also callable, and therefore returned "object" for document.all (which is both undetectable and callable). R=yangguo@chromium.org BUG=chromium:567998 LOG=n Review URL: https://codereview.chromium.org/1527863003 Cr-Commit-Position: refs/heads/master@{#32852}
-
- 09 Dec, 2015 1 commit
-
-
mvstanton authored
It's expensive to walk all shared function infos during the gc atomic pause. Instead, use WeakCells to implement this structure without manual clearing. Reland due to a bug when reusing entries in the optimized code map. BUG= Review URL: https://codereview.chromium.org/1508703002 Cr-Commit-Position: refs/heads/master@{#32696}
-
- 07 Dec, 2015 1 commit
-
-
jochen authored
The backing store is only held alive indirectly via the array buffer referenced by the holder (typed array), so it's not enough to keep the elements alive (or even just the external pointer loaded from the elements). R=mstarzinger@chromium.org,bmeurer@chromium.org LOG=n BUG=v8:1827 Review URL: https://codereview.chromium.org/1493983004 Cr-Commit-Position: refs/heads/master@{#32644}
-
- 03 Dec, 2015 2 commits
-
-
neis authored
Reason for revert: Probably causes GC stress test failures. TBR=mvstanton@chromium.org BUG= NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1493393002 Cr-Commit-Position: refs/heads/master@{#32574}
-
mvstanton authored
It's expensive to walk all shared function infos during the gc atomic pause. Instead, use WeakCells to implement this structure without manual clearing. BUG= Review URL: https://codereview.chromium.org/1478943003 Cr-Commit-Position: refs/heads/master@{#32567}
-
- 02 Dec, 2015 2 commits
-
-
bmeurer authored
Also remove the ResultMode from ToBooleanStub and always return true or false and use the same mechanism in fullcodegen. This is in preparation for adding ToBoolean hints to TurboFan. Drive-by-fix: We can use the power of the ToBooleanIC in TurboFan now that the ResultMode is gone (and the runtime always returns true or false from the miss handler). R=mstarzinger@chromium.org BUG=v8:4583 LOG=n Review URL: https://codereview.chromium.org/1491223002 Cr-Commit-Position: refs/heads/master@{#32524}
-
danno authored
* Add a sibling interface to InterpreterAssembler called CodeStubAssembler which provides a wrapper around the RawMachineAssembler and is intented to make it easy to build efficient cross-platform code stubs. Much of the implementation of CodeStubAssembler is shamelessly stolen from the InterpreterAssembler, and the idea is to eventually merge the two interfaces somehow, probably moving the InterpreterAssembler interface over to use the CodeStubAssembler. Short-term, however, the two interfaces shall remain decoupled to increase our velocity developing the two systems in parallel. * Implement the StringLength stub in TurboFan with the new CodeStubAssembler. Replace and remove the old Hydrogen-stub version. * Remove a whole slew of machinery to support JavaScript-style code stub generation, since it ultimately proved unwieldy, brittle and baroque. This cleanup includes removing the shared code stub context, several example stubs and a tangle of build file changes. BUG=v8:4587 LOG=n Review URL: https://codereview.chromium.org/1475953002 Cr-Commit-Position: refs/heads/master@{#32508}
-
- 01 Dec, 2015 1 commit
-
-
bmeurer authored
This is the initial support for binary operation hints on javascript binary operators, i.e. JSAdd, JSSubtract and so on. The hints are extracted from the fullcodegen code object before graph building and the AstGraphBuilder puts those hints on the operators if available. R=jarin@chromium.org BUG=v8:4583 LOG=n Review URL: https://codereview.chromium.org/1487973002 Cr-Commit-Position: refs/heads/master@{#32443}
-
- 30 Nov, 2015 1 commit
-
-
bmeurer authored
This way we avoid the %_IsSmi magic that is required in TurboFan to (efficiently) check abitrary context slots for smi 0. Checking against "the hole" is common in the AstGraphBuilder and "the hole" is also used to mark other context slots as not initialized. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1484723003 Cr-Commit-Position: refs/heads/master@{#32407}
-
- 27 Nov, 2015 3 commits
-
-
bmeurer authored
Previously all contexts had a link to the global object, but what is required in most cases (except for the global load, store and delete case) is the native context. This also removes the second dummy global object that was still linked to every native context. We will add a different mechanism to ensure that builtins do not pollute the actual global object during bootstrapping. Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel R=yangguo@chromium.org,mstarzinger@chromium.org Committed: https://crrev.com/d290f204938295bfecc5c8e645ccfcff6e80ddb8 Cr-Commit-Position: refs/heads/master@{#32375} Review URL: https://codereview.chromium.org/1480003002 Cr-Commit-Position: refs/heads/master@{#32381}
-
machenbach authored
Revert of [runtime] Replace global object link with native context link in all contexts. (patchset #3 id:40001 of https://codereview.chromium.org/1480003002/ ) Reason for revert: [Sheriff] Breaks: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/5472 Original issue's description: > [runtime] Replace global object link with native context link in all contexts. > > Previously all contexts had a link to the global object, but what is > required in most cases (except for the global load, store and delete > case) is the native context. > > This also removes the second dummy global object that was still linked > to every native context. We will add a different mechanism to ensure > that builtins do not pollute the actual global object during > bootstrapping. > > Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. > > R=yangguo@chromium.org > > Committed: https://crrev.com/d290f204938295bfecc5c8e645ccfcff6e80ddb8 > Cr-Commit-Position: refs/heads/master@{#32375} TBR=yangguo@chromium.org,mstarzinger@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1478303002 Cr-Commit-Position: refs/heads/master@{#32377}
-
bmeurer authored
Previously all contexts had a link to the global object, but what is required in most cases (except for the global load, store and delete case) is the native context. This also removes the second dummy global object that was still linked to every native context. We will add a different mechanism to ensure that builtins do not pollute the actual global object during bootstrapping. Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1480003002 Cr-Commit-Position: refs/heads/master@{#32375}
-
- 25 Nov, 2015 2 commits
-
-
jochen authored
We always want to have an Isolate, so just use an extra ctor arg BUG=2487 R=yangguo@chromium.org,mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1476763002 Cr-Commit-Position: refs/heads/master@{#32277}
-
bmeurer authored
This is the initial step towards refactoring the regexp literation creation code to make it less obscure and more similar to the mechanism we use to create array and object literals. There's now a new runtime entry %CreateRegExpLiteral with the same interface as the entries for array and object literals, except that we still pass the flags as string. Instead of embedding the hand written native to clone JSRegExp instances we now have a FastCloneRegExpStub, which behaves similar to the other FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already had. R=mlippautz@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/1475823003 Cr-Commit-Position: refs/heads/master@{#32255}
-
- 24 Nov, 2015 1 commit
-
-
bmeurer authored
Change the runtime entries and their associated code stubs for object and array literal creation to take the closure instead of the raw literals pointer. This is way easier to deal with (and cleaner) in TurboFan. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1469833005 Cr-Commit-Position: refs/heads/master@{#32220}
-