This fixes a corner case where the code flusher is disabled while the
incremental marker is still running. This can happen when the debugger
is loaded and a scavenge is triggered. Make sure that all flushing
decisions are revisited after the candidates lists are evicted.
R=hpayer@chromium.org
BUG=chromium:173458,chromium:168582
TEST=cctest/test-heap/Regress173458
Review URL: https://codereview.chromium.org/12217108
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13641 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes a corner case that happens when JSFunctions are enqueued as
code flushing candidates but their respective SharedFunctionInfo isn't.
If the JSFunction gets evicted due to optimization the code slot in the
SharedFunctionInfo will never be recorded in the slots buffer.
R=hpayer@chromium.org
BUG=chromium:168801
TEST=cctest/test-heap/Regress168801
Review URL: https://codereview.chromium.org/11896064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13481 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When code objects in the heap for FUNCTIONs and OPTIMIZED_FUNCTIONs are marked by the GC, their prologue is patched with a call to a stub that removes the patch. This allows the collector to quickly identify code objects that haven't been executed since the last full collection (they are the ones that sill contain the patch). The functionality is currently disabled, but can be activated by specifying the "--age-code".
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/10837037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12898 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This enables code flushing even with incremental marking enabled and
fully shares the function link field in JSFunctions between candidates
for code flushing and the optimized functions list. If a candidate for
code flushing gets optimized, it will be evicted from the candidates
list.
R=ulan@chromium.org
BUG=v8:1609
Review URL: https://codereview.chromium.org/11140025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12796 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is another preparation for incremental code flushing. Instead of
linking candidates using the code entry field, we use the next pointer
that is also used to link optimized functions together. Since we only
support flushing of unoptimized code, this field can be shared.
R=ulan@chromium.org
BUG=v8:1609
Review URL: https://codereview.chromium.org/11141023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12734 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