introduced in https://crrev.com/72f884a19fa4434bba6fc0e013ec4ea0a2366893
The regression comes from adding the next weak field of AllocationSite
as a hidden reference into the snapshot.
Before 72f884 the reference was implicitly ignored because the body
descriptor of AllocationSite did not include it.
This patch explicitly skip the next weak field of AllocationSite.
BUG=chromium:630027
Review-Url: https://codereview.chromium.org/2189643004
Cr-Commit-Position: refs/heads/master@{#38211}
We ported hashmap.h into libsampler as a workaround before, so the main focus of
this patch is to reduce code duplication. This patch moves the hashmap into
src/base as well as creates DefaultAllocationPolicy using malloc and free.
BUG=v8:5050
LOG=n
Review-Url: https://codereview.chromium.org/2010243003
Cr-Commit-Position: refs/heads/master@{#36873}
Left trimming assumes that nobody other than the JSArray has a reference to the
backing store. Sampling heap profiler may profile the backing store and keep a
reference too it. This reference was never updated on a left-trim, causing a
crash.
R=alph@chromium.org, hpayer@chromium.org, mattloring@google.com
BUG=
Review URL: https://codereview.chromium.org/1885723002
Cr-Commit-Position: refs/heads/master@{#35449}
If no objects allocated at a location are live when a profile is
collected we report a zero count sample. This is confusing to those
looking at the profiles and will leak memory.
We now delete allocations once the number of sampled live objects for
that location reaches zero.
R=ofrobots@google.com
BUG=
Review URL: https://codereview.chromium.org/1828333002
Cr-Commit-Position: refs/heads/master@{#35305}
If a script is unloaded between the collection of an allocation and the
tranlation of an allocation profile, the profiler will segfault. With
this change, we report unloaded scripts as having no line number,column
number, or name.
R=ofrobots@google.com
BUG=
Review URL: https://codereview.chromium.org/1846723002
Cr-Commit-Position: refs/heads/master@{#35147}
Makes --ignition cause eager compilation if we aren't building the startup
snapshot.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1811553003
Cr-Commit-Position: refs/heads/master@{#35066}
Implements poisson unsampling. A poisson process is used to determine
which samples to collect based on a sample rate. Unsampling will
approximate the true number of allocations at each site taking into
account that smaller allocations are less likley to be sampled.
This work was originally being done in the agent that
consumes profiles but it is more efficient to do it here
and individual consumers of the API should not have to
worry about the mathematical details of the sampling
process.
R=ofrobots@google.com
BUG=
Review URL: https://codereview.chromium.org/1706343002
Cr-Commit-Position: refs/heads/master@{#34234}
Reason for revert:
The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio
Original issue's description:
> [profiler] Implement POC Sampling Heap Profiler
>
> This implements a proof-of-concept sampling based heap profiler inspired by
> tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
>
> The basic idea is the sample allocations using a randomized Poisson process. At
> any point in time we can cheaply request the set of live sample objects that
> should be a representative sample of heap. Samples include stack-traces from the
> allocation sites, making this an effective tool for memory leak debugging.
>
> Unlike AllocationTracking, this is intended to be cheap and usable online in
> production.
>
> The proof-of-concept is only sampling new-space allocations at this point.
> Support for sampling paged space and native allocations is anticipated in the
> future.
>
> [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
> [2] http://blog.golang.org/profiling-go-programs
>
> Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262
> Cr-Commit-Position: refs/heads/master@{#33448}
TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,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/1615173002
Cr-Commit-Position: refs/heads/master@{#33449}
This implements a proof-of-concept sampling based heap profiler inspired by
tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
The basic idea is the sample allocations using a randomized Poisson process. At
any point in time we can cheaply request the set of live sample objects that
should be a representative sample of heap. Samples include stack-traces from the
allocation sites, making this an effective tool for memory leak debugging.
Unlike AllocationTracking, this is intended to be cheap and usable online in
production.
The proof-of-concept is only sampling new-space allocations at this point.
Support for sampling paged space and native allocations is anticipated in the
future.
[1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[2] http://blog.golang.org/profiling-go-programs
Review URL: https://codereview.chromium.org/1555553002
Cr-Commit-Position: refs/heads/master@{#33448}
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}
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}
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}
The test expectations should fail consistently in both release and debug
builds. DCHECK is only meant for debug-only checks in production code.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1506753002
Cr-Commit-Position: refs/heads/master@{#32639}
* 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}
This replaces internal GetConstructorName with toStringTag, .constructor's name
and class_name. This entirely changes how the name is computed for use in
devtools.
BUG=chromium:529177
LOG=n
Review URL: https://codereview.chromium.org/1435273002
Cr-Commit-Position: refs/heads/master@{#32374}
This is in preparation to enabling --turbo-inlining by default, fixing
various issues when general purpose inlining is running against our
entire test suite.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1407533004
Cr-Commit-Position: refs/heads/master@{#31294}
This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1371083003
Cr-Commit-Position: refs/heads/master@{#31019}
Adds Uint32x4, Uint16x8, and Uint8x16 types.
Adds all functions in the current spec, except for loads and stores.
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1294513004
Cr-Commit-Position: refs/heads/master@{#30322}
This tries to remove includes of "-inl.h" headers from normal ".h"
headers, thereby reducing the chance of any cyclic dependencies and
decreasing the average size of our compilation units.
Note that this change still leaves 7 violations of that rule in the
code. However there now is the "tools/check-inline-includes.sh" tool
detecting such violations.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1283033003
Cr-Commit-Position: refs/heads/master@{#30125}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
Until now, TF-generated code stubs piggy-backed off of the builtin
context. Since generation of code stubs is lazy, stubs generated at
different times in different native contexts would contain embedded
pointers different builtin contexts, leading to cross-context references
and memory leaks.
After this CL, all TF-generated code stubs are generated inside a
internal thinned-out, native context that lives solely for the
purpose of hosting generated code stubs.
Review URL: https://codereview.chromium.org/1213203007
Cr-Commit-Position: refs/heads/master@{#29593}
Reason for revert:
I'm reverting this while working on the regression fix
Original issue's description:
> Remove the weak list of views from array buffers
>
> Instead, views have to check their array buffer for whether
> it's neutered or not.
>
> BUG=v8:3996
> R=hpayer@chromium.org,dslomov@chromium.org,verwaest@chromium.org
> LOG=n
>
> Committed: https://crrev.com/5ae083a05a6743d6cb91585f449539f7846a5d8c
> Cr-Commit-Position: refs/heads/master@{#27995}
TBR=dslomov@chromium.org,hpayer@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3996
Review URL: https://codereview.chromium.org/1061753008
Cr-Commit-Position: refs/heads/master@{#28014}
Instead, views have to check their array buffer for whether
it's neutered or not.
BUG=v8:3996
R=hpayer@chromium.org,dslomov@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1094863002
Cr-Commit-Position: refs/heads/master@{#27995}
Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site.
Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC.
BUG=
Review URL: https://codereview.chromium.org/1082973003
Cr-Commit-Position: refs/heads/master@{#27831}
This avoids both a mysterious boolean argument ("insert") and lets
non-mutating lookups skip passing an allocator (in one such case,
we were passing a scary-looking ZoneAllocationPolicy(NULL)!).
Review URL: https://codereview.chromium.org/1074943002
Cr-Commit-Position: refs/heads/master@{#27799}
Before this patch the embedder could assign timestamp to the last interval after calling GetHeapStats. This would be slightly different from the timstamps assigned by v8 internally and written into heap snapshot. This patch allow to avoid this small discrepancy by returning timestamp along with last heap stats update.
BUG=chromium:467222
LOG=Y
Review URL: https://codereview.chromium.org/1037803002
Cr-Commit-Position: refs/heads/master@{#27466}
None of these fields is used in Blink. Embedder always can implement them using existing API.
BUG=chromium:465651
LOG=Y
Review URL: https://codereview.chromium.org/983833006
Cr-Commit-Position: refs/heads/master@{#27113}
Math functions:
Some Math functions require typed arrays for their implementation. The embedded
script may call those Math functions. The serializer needs to deal with this.
Added assertion to make sure no other typed array is created when snapshotting.
Number-string cache:
We assume that the initial snapshot does not expand the number-string cache.
This is no longer true for custom heap snapshots.
Bound functions:
Bound functions store the bound arguments in a COW fixed array, including the
bindee function. COW arrays are serialized into the startup snapshot and
referenced in the partial snapshot via partial snapshot cache. However, the
bindee function is context-dependent and must not be part of the startup
snapshot. There is no need for bound functions to use a COW array though.
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/851073002
Cr-Commit-Position: refs/heads/master@{#26072}
When object is creating via native V8 API calls JS callstack is empty and the allocation is indistinguishable from say compiler allocations. This change adds a separate entry for such allocations.
Since FunctionInfo not necessarily corresponds to a heap object they are now referred to using their index in the list of all FunctionInfos.
BUG=chromium:277984
LOG=N
R=loislo@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/177203002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19718 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Made operator* return reference to the raw type, not pointer. New method 'get()' should be used when raw pointer is needed.
Also removed useless inline modifier from the SmaprtPointer methods and added const modifier to the methods that don't change smart pointer.
Made ~SmartPointerBase protected to avoid accidental calls of the non-virtual base class's destructor.
drive-by: fixed use after free in src/factory.cc
BUG=None
LOG=N
R=alph@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/101763003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Heap allocation reported to AllocationTracker may be later divided into several objects so it is incorrect to put the block as a new HeapObject into the map. We will match allocated block with actual HeapObjects later when iterating Heap (will be addressed in another patch). Since the objects are not assigned an id immediately after creation we need to call FindOrAddEntry when finding id for SharedFunctionInfo during stack crawling.
Removed hooks for tracking creation of AllocationMemento. AllocationMemento is not a HeapObject and should be considered as implementation overhead.
Renamed NewObjectEvent to AllocationEvent which is more precise in case of folded allocations and when a part of the new block becomes AllocationMemento.
BUG=None
LOG=N
R=loislo@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/95283003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is initial implementation of allocation profiler.
Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.
Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.
This patch is r17301 plus a fix for the test crash in debug mode. The test crashed because we were traversing stack trace when just allocated object wasn't completely configured, in particular the map pointer was incorrect. Invalid Map pointer broke heap iteration required to find Code object for a given pc during stack traversal. The solution is to insert free space filler in the newly allocated block just before collecting stack trace.
BUG=chromium:277984,v8:2949
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/61893031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17742 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is initial implementation of allocation profiler.
Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.
Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.
This patch is r17301 plus a fix for the test crash in debug mode. The test crashed because we were traversing stack trace when just allocated object wasn't completely configured, in particular the map pointer was incorrect. Invalid Map pointer broke heap iteration required to find Code object for a given pc during stack traversal. The solution is to insert free space filler in the newly allocated block just before collecting stack trace.
BUG=chromium:277984,v8:2949
R=hpayer@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/34733004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17365 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is initial implementation of allocation profiler.
Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.
Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.
BUG=chromium:277984
R=hpayer@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/27227005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The reason of that is a number of cons strings in the app.
The app constructs a json string and as a result v8 heap has
a very long chain of cons strings.
Profiler counts all these strings as plain String objects and
assign the content of the strings as node names.
It required O(n^2) time and O(n^2) memory.
Solution: I introduced two new types, kConsString and kSliced string.
They do not use the content of the string for names. So the problem disappeared.
The heap profiler usability problem will be solved on Blink side.
BUG=285770
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/23460027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16611 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added instance method on v8::Isolate for retrieving instance of v8::HeapProfiler for that isolate. All static methods of v8::HeapProfiler are deprecated, corresponding instance methods are added to v8::HeapProfiler.
All static methods on v8::internal::HeapProfiler were converted into instance ones.
BUG=None
Review URL: https://codereview.chromium.org/12907006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I tried to limit the use of v8::Isolate::GetCurrent() and v8::internal::Isolate::Current() as much as possible, but sometimes this would have involved restructuring tests quite a bit, which is better left for a separate CL.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12716010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Minor cleanups on the way, e.g. making sure that we never use something after an allocation failed. Style question: Should we switch to some kind of MUST_USE_RESULT-style to ensure that we handle failures consistently? Not sure...
BUG=v8:2576
Review URL: https://codereview.chromium.org/12867002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13946 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Prevously v8 put a link to each context variable into a function where
the variable is visible.
Because of that if there are N functions sharing a context having M variables
then N*M links were created for the snapshot.
The fix makes v8 to put the links into the context object.
BUG=145687
TEST=test-heap-snapshot/ManyLocalsInSharedContext
Review URL: https://codereview.appspot.com/7715044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds multiple things:
Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell).
An ownership bit is added to maps indicating whether it owns its own descriptor array or not.
Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added.
Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions.
To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map.
We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map.
When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place.
Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array.
When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10909007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
