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
New abstract class CodeEventListener was created.
CodeEventLogger which is the base class for Jit, LowLevel
and CodeAddressMap loggers was inherited from CodeEventListener.
CodeAddressMap class was moved to serializer.cc because serializer is the only user for it. Actually it collects code names and pushes them to the standard log as SnapshotCodeNameEvent. So I extracted this code into separate function CodeNameEvent. It happens that this method works only when Serializer serializes an object. So I added direct log call there.
CodeEventLogger class declaration was moved to the header
because CodeAddressMap needs it.
The code for the nested class CodeEventLogger::NameBuffer was left in the cc file.
CpuProfiler now is inherit CodeEventListener but not used
the loggers infrastructure yet due to the complex initialization schema. I'd like to fix that in a separate cl.
BUG=none
TEST=current test set.
R=yangguo@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/19724007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Allocations of AllocationSites occur in generated code, so generated code needs to be able to add to the list. For now I have a special hydrogen instruction, though it would be nice to use general purpose instructions.
* The snapshot contains AllocationSites, and these need to be re-threaded into the list on deserialization.
Something nice is that the AllocationSites are only created in old space, so a special new space visitor isn't required.
BUG=
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/18173013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the speed of deserializing code. The current startup
time improvement for V8 is around 6%, but code deserialization
is speeded up disproportionately, and we will soon have more
code in the snapshot.
* Removed support for deserializing into large object space.
The regular pages are 1Mbyte now and that is plenty. This
is a big simplification.
* Instead of reserving space for the snapshot we actually
allocate it now. This removes some special casing from
the memory management and simplifies deserialization since
we are just bumping a pointer rather than calling the
normal allocation routines during deserialization.
* Record in the snapshot how much we need to boot up and
allocate it instead of just assuming that allocations in
a new VM will always be linear.
* In the snapshot we always address an object as a negative
offset from the current allocation point. We used to
sometimes address from the start of the deserialized data,
but this is less useful now that we have good support for
roots and repetitions in the deserialization data.
* Code objects were previously deserialized (like other
objects) by alternating raw data (deserialized with memcpy)
and pointers (to external references, other objects, etc.).
Now we deserialize code objects with a single memcpy,
followed by a series of skips and pointers that partially
overwrite the code we memcopied out of the snapshot.
The skips are sometimes merged into the following
instruction in the deserialization data to reduce dispatch
time.
* Integers in the snapshot were stored in a variable length
format that gives a compact representation for small positive
integers. This is still the case, but the new encoding can
be decoded without branches or conditional instructions,
which is faster on a modern CPU.
Review URL: https://chromiumcodereview.appspot.com/10918067
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The deoptimizer generates full-code-generator code and relies on it having
the same layout as last time. This means that the code the full code
generator makes for the snapshot should be the same as the code it makes
later. This change makes the full code generator create more consistent
code between mksnapshot time and run time.
This is a bug fix and a step towards making the snapshot code more robust.
Review URL: https://chromiumcodereview.appspot.com/10824084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12233 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
with more JS code that is loaded into the VM before writing the snapshot. Get
rid of the hard coded limit on the partial snapshot cache size. This change
disables most of the serializer tests for the snapshot build of the VM: It's
getting too complicated to support both booting from a snapshot and then
creating a new snapshot from the same VM or loading more code with another
snapshot in the same VM.
Review URL: http://codereview.chromium.org/10574013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11871 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Object model changes
----------------------------------------
New fixed_cow_array_map is used for the elements array of a JSObject
to mark it as COW. The JSObject's map and other fields are not
affected. The JSObject's map still has the "fast elements" bit set. It
means we can do only the receiver map check in keyed loads and the
receiver and the elements map checks in keyed stores. So introducing
COW arrays doesn't hurt performance of these operations. But note that
the elements map check is necessary in all mutating operations because
the "has fast elements" bit now means "has fast elements for reading".
EnsureWritableFastElements can be used in runtime functions to perform
the necessary lazy copying.
Generated code changes
----------------------------------------
Generic keyed load is updated to only do the receiver map check (this
could have been done earlier). FastCloneShallowArrayStub now has two
modes: clone elements and use COW elements. AssertFastElements macro
is added to check the elements when necessary. The custom call IC
generators for Array.prototype.{push,pop} are updated to avoid going
to the slow case (and patching the IC) when calling the builtin should
work.
COW enablement
----------------------------------------
Currently we only put shallow and simple literal arrays in the COW
mode. This is done by the parser.
Review URL: http://codereview.chromium.org/3144002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in allowing more flexible compilation and to simplify builtins lookup.
This changes a number of places where code objects are assigned to
SharedFunctionInfo objects to also assign this code object to the
JSFunction. In addition, the code flushing is changed slightly to
accomodate this (we need to flush the code from functions pointing to
SharedFunctionInfo objects that has already been flushed).
Review URL: http://codereview.chromium.org/3120006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5233 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
