The problem is other array may have holes, for example
when fixed array comes from JSArray (in case of named interceptor).
If that would prove to be a performance problem, we could
pass an additional argument into UnionOfKeys to hold actual length.
Review URL: http://codereview.chromium.org/3595013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5591 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Change more functions used by the Compiler class to have a uniform
interface: they get passed as argument an input/output pointer to a
CompilationInfo that they mutate if they succeed, and they return a
flag telling whether they succeeded.
Also, remove some unnecessary timers.
Review URL: http://codereview.chromium.org/3561012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5583 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The plan is to use the CompilationInfo class to communicate inputs and
outputs to compilation pipeline phases, which each return a boolean
success/failure flag.
The intent is to make it easier to compose small pieces of the
pipeline without having to grow a custom function each time, each
taking a half dozen arguments.
This change modifies the very front end (the parser).
Review URL: http://codereview.chromium.org/3586006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5581 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current parameters (initial slack = 6, kGenerousAllocationsCount = 16)
caused 15-20% performance regression on 3d-raytrace on x64
(visible both in standalone shell and in the web harness). This is very
likely some kind of an alignment problem (it goes away completely with --prof).
A similar problem can be observed on ia32 with initial slack=2.
Increased initial slack to 8 and decreased constructions count to 8.
This made the regression go away (and did not harm any of the other tests).
Review URL: http://codereview.chromium.org/3595002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5571 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
during snapshot size optimization.
Sorry, now I figured out that the diff implementation itself was also
incorrect. Reachable nodes must be filtered from the beginning,
otherwise, an object that is already disconnected, but not discarded
yet, will not appear as a deleted (thankfully, this bug for some
reason had appeared on the x64 port.)
BUG=868
TEST=HeapSnapshotRootPreservedAfterSorting
Review URL: http://codereview.chromium.org/3531005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5570 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The lazy parsing functions took a host of arguments that can all be
derived from the SharedFunctionInfo, and the SharedFunctionInfo is
always available when parsing lazily. Change the interface to take a
single CompilationInfo or SharedFunctionInfo argument.
Also remove a flag in the parser that was always false when it was read.
Review URL: http://codereview.chromium.org/3538005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5561 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It was a wart that we had three handle fields, exactly one of which
was non-null; and that we had three overloaded constructors. Instead,
introduce subclasses and virtual methods.
Remove some unused fields from class CompilationInfo.
Review URL: http://codereview.chromium.org/3566003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5560 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When inspecting an AST node in the debugger, it can be difficult to
find its concrete type. Add a "node_type" virtual function to all the
concrete AST nodes.
Use a macro to generate the definition of node_type as well as Accept
and the AsXXX type testing/casting functions.
Review URL: http://codereview.chromium.org/3431026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5549 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reduces size of preparser data significantly when there are nested functions.
Also allows us to drop the "skip" fields of function entries,
that tells us how much preparse-data to skip when skipping the function source.
Review URL: http://codereview.chromium.org/3412034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5541 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The object's space in Page starts after Page header and is aligned to kMapAlignment which is 32 bytes on 32-bit and 8 bytes on 64-bit.
In case of 64-bit target, the current page header size is exactly 32 bytes so we get the code magically aligned at 32 bytes but it is better to have a separate CODE_POINTER_ALIGN macro to make sure the object space in Page is aligned properly for both maps and code.
There could be a small waste of bytes sometimes (since both Page header and Code header sizes are aligned separately) but it seems the optimal one would involve cross-dependencies between .h files and not clear if it's worth it.
This is a back-port from Isolates branch.
Review URL: http://codereview.chromium.org/3461021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5526 ce2b1a6d-e550-0410-aec6-3dcde31c8c00