when using snapshots.
The alignment of new space has to match the alignment in the snapshot,
but the max committed amount of memory does not.
For now, we assume that the default semispace size is always used in a
snapshot.
Review URL: http://codereview.chromium.org/300036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. The optimizations are patterned after
those previously done for CanvasPixelArray. This CL adds all of the
necessary framework but continues to use the generic KeyedLoadIC and
KeyedStoreIC code, to create a baseline for benchmarking purposes. The
next CL will add the optimized ICs to ic-ia32.cc and ic-x64.cc.
These new CanvasArray types have different semantics than
CanvasPixelArray; out-of-range values are clamped via C cast
semantics, which is cheaper than the clamping behavior specified by
CanvasPixelArray. Out-of-range indices raise exceptions instead of
being silently ignored.
As part of this work, pulled FloatingPointHelper::AllocateHeapNumber
up to MacroAssembler on ia32 and x64 platforms. Slightly refactored
KeyedLoadIC and KeyedStoreIC. Fixed encoding for fistp_d on x64 and
added a few more instructions that are needed for the new ICs. The
test cases in test-api.cc have been verified by hand to exercise all
of the generated code paths in the forthcoming specialized ICs.
Review URL: http://codereview.chromium.org/293023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Turned on with '--log-producers' flag, also needs '--noinline-new' (this is temporarily), '--log-code', '--log-gc'. Not all allocations are traced (I'm investigating.)
Stacks are stored using weak handles. Thus, when an object is collected, its allocation stack is deleted.
Review URL: http://codereview.chromium.org/267077
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3069 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The profile is taken together with constructors profile. In theory, it
should represent a complete heap graph. However, this takes a lot of memory,
so it is reduced to a more compact, but still useful form. Namely:
- objects are aggregated by their constructors, except for Array and Object
instances, that are too hetereogeneous;
- for Arrays and Objects, initially every instance is concerned, but then
they are grouped together based on their retainer graph paths similarity (e.g.
if two objects has the same retainer, they are considered equal);
Review URL: http://codereview.chromium.org/200132
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2903 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This only wins us around 1% in performance, but it makes the code more
compact. We don't currently have a way to represent in the virtual
frame that a slot contains a value from the root array. Adding this
would probably make the code more compact.
Review URL: http://codereview.chromium.org/174639
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Android system provides a unique feature that it sends a notification to the
browser in low memory condition, and the browser cleans up cache and frees
resources. Forcing a GC in low memory condition can free DOM objects and also
can shrink the old spaces.
This patch addresses the last comment in
http://codereview.chromium.org/173016/show
Mads Ager 2009/08/19 17:24:23
I would prefer to not use the flags to signal that a compacting collection is
requested.
TBR = ager
Review URL: http://codereview.chromium.org/173102
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2725 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Additionally fix NewSpace capacity bug by removing the duplicated
capacity and maximum capacity book keeping. The capacity and maximum
capacity of NewSpace is the capacity and maximum capacity of one of
it's semispaces.
Review URL: http://codereview.chromium.org/174052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During parsing functions are analyzed for statements of the form this.x = ...;. These assignments are categorized in two types: simple and non simple. The simple ones are where the right hand side is known to be either a constant or an argument to the function. If a function only contains statements of this type the property names are collected and for the simple assignments the index of the argument or the constant value assigned are stored as well.
When the initial map for a function is created and the function consists of only this type of assignemnts the initial map is created with a descriptor array describing these properties which will be known to always exist in an object created from the function.
The information on this property assignments is not collected during pre-parsing so if compiling using pre-parse data these optimization hints are not available.
Next step will be to use the information collected for the simple assignments to generate constructor code which will create and initialize the object from this information without calling the code for the function.
Review URL: http://codereview.chromium.org/172088
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2710 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allocate the code stubs dictionary and non monomorphic cache dictionary with an initial size which avoids these dictionaries to be expanded during bootstrapping. This gets rid of 9 dictionary expansions during bootstrapping.
Preallocate the dictionary when normalizing an object to a size sufficient for holding the number of properties which is expected to be added to the object. This is used when ceating an object from an object literal boilerplate where multiple properties are known to be added. This gets rid of 10 dictionary expansions during bootstrapping.
There are now 3 dictionary expansions left during bootstrapping.
Review URL: http://codereview.chromium.org/160382
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is activated with '--log-gc' flag.
JS object size is calculated as its size + size of 'properties' and 'elements' arrays, if they are non-empty. This doesn't take maps, strings, heap numbers, and other shared objects into account.
As Soeren suggested, I've moved ZoneSplayTree from jsregexp to zone, and removed now empty jsregexp-inl header file.
Review URL: http://codereview.chromium.org/159504
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2570 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If V8 is holding on to a lot of external memory, we attempt to clean
it up even if we do not get an allocation failure. Since tiny V8
objects can hold on to a lot of external memory, we might run out of
external memory while waiting for a normal allocation failure.
Review URL: http://codereview.chromium.org/155916
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The flag is only turned on when --trace_gc is one. It prints out used and available bytes in each space. To enable it, ENABLE_LOGGING_AND_PROFILING must be defined.
This is a mini version of --heap_stats, but don't need DEBUG macro to be turned on.
Review URL: http://codereview.chromium.org/149568
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2449 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
space is similar to map space in that it has fixed-size objects. A
common superclass for a space with fixed size objects is used for the
map space and cell space.
Allocate all cells in cell space. Handle it during all GCs. Modify
the free-list node representation (so that the size is not at a fixed
offset in all cells) to allow two-pointer free-list nodes. Clean up
some stuff in the MC collector.
Review URL: http://codereview.chromium.org/155211
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2411 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a trivial per-row compression:
- short aliases are introduced for events and code creation tags;
- in tick events, offsets are used instead of absolute addresses;
- removed 'code-allocation' event, as it seems not used.
The first two options are depend on the new flag: 'compress-log', which is off by default.
On benchmarks run w/o snapshot, this gives 45% log size reduction.
Review URL: http://codereview.chromium.org/119304
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When loaded scripts are requested this cache is filled with all the script objects in the heap. Hereafter its content is kept in sync with the active scripts in the heap through the notifications of new scripts compiled and by using weak handles to get notified when a script is collected.
Through the tracking of collected scripts the debugger event OnScriptCollected have been added to notify a debugger that a script previously returned through the scripts command is no longer in use.
Make the ComputeIntegerHash globally available.
Moved clearing of the mirror cache to when debugger is really left. Previously recursive invocations of the debugger cause the mirror cache to be cleared causing handles to become either stale or reference other objects.
Review URL: http://codereview.chromium.org/115462
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1988 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in the old generation while its remembered set is being swept for
pointers into the young generation. This is done by delaying the
copying of promoted objects from when they are first encountered and
promoted to only when their body is visited.
Review URL: http://codereview.chromium.org/115086
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1971 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ENABLE_DEBUGGER_SUPPORT is enabled by default unless it is on Android platform.
On Android platform, it can also enabled by passing -DENABLE_DEBUGGER_SUPPORT flag to the compiler.
This should not affect any existing build (I hope, cross my fingers) except the build in real Android environment (in other word, it only affects me now).
There are lot of room for code refactoring in stead of using #ifdef all over the place. I will leave this to v8 folks.
Review URL: http://codereview.chromium.org/77035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1745 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently function name inference is wired with AST optimization pass to avoid introducing another pass over AST. A better solution would be to rewrite AST visitors so they can be naturally combined together in a single pass, as their current implementation doesn't allow it.
For examples of cases where function names can be inferred, see the tests file.
Review URL: http://codereview.chromium.org/62146
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1696 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(generic state inside V8) in the API to allow the V8 shell to run all
the mjsunit tests with heap protection on.
These state changes are only taken when built with
ENABLE_HEAP_PROTECTION. The two states OTHER and EXTERNAL are treated
the same because we will not properly reenter OTHER through the API.
Review URL: http://codereview.chromium.org/56060
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1643 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
and unprotecting it when (re)entering. The functionality is enabled
by the flag --protect-heap and requires V8 to be built with
ENABLE_HEAP_PROTECTION and ENABLE_LOGGING_AND_PROFILING defined.
Implemented on Linux and Windows but not yet for other platforms.
Review URL: http://codereview.chromium.org/53004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1595 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Some minor changes, and removed the new handlescope in the inner loop of replace. Only really affects replaces on extremely long strings.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1524 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
an object that holds a setter. If there are no store ics then no
flushing is done. The implementation has been tweaked so that no ICs
are cleared during normal context creation.
This may cost us some performance but I'm submitting it as it is and
if there are problems we can either decide to be smarter about when,
what and/or how we clear, or back this change out altogether.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1509 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Moved the registrered debug event listener from the context to a global handle in the Debugger class. Storing it in the context did not make much sense.
Changed a lot of tests to handle the API change.
BUG=1242707
Review URL: http://codereview.chromium.org/19753
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1212 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This can lead to large objects which wastes a lot of space if we normalize properties. We therfore clear the inobject properties when normalizing properties. This is done by adjusting the instance size in the new map and overwriting the inobject properties with a filler.
Review URL: http://codereview.chromium.org/17308
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of the generated code. These can be used by the profiler to
categorize the ticks that occur within generated code and thereby show
more detailed information about where time is spent in generated code.
For instance, this is what the profiler displayed for a simple regexp
benchmark with irregexp-native before:
[JavaScript]:
total nonlib name
87.2% 87.2% RegExp: (?:\w*\W+)*
This is what we can display now:
[JavaScript]:
total nonlib name
87.2% 87.2% RegExp: (?:\w*\W+)*
- 53.0% 56.7% BranchOrBacktrack
- 14.9% 59.8% CheckCharacterLT
- 13.7% 20.4% CheckStackLimit
- 6.7% 6.7% SafeCall
- 2.7% 7.0% CheckCharacterGT
- 2.4% 2.4% SafeReturn
- 2.1% 2.1% LoadCurrentCharacter
- 1.8% 1.8% PushRegister
- 0.9% 0.9% PopRegister
- 0.9% 0.9% AdvanceRegister
- 0.3% 0.3% PopCurrentPosition
- 0.3% 0.3% CheckGreedyLoop
- 0.0% 20.4% PushBacktrack
- 0.0% 22.3% CheckCharacter
- 0.0% 2.4% IfRegisterLT
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Here is a description of the background and design of split window in Chrome and V8:
https://docs.google.com/a/google.com/Doc?id=chhjkpg_47fwddxbfr
This change list splits the window object into two parts: 1) an inner window object used as the global object of contexts; 2) an outer window object exposed to JavaScript and accessible by the name 'window'. Firefox did it awhile ago, here are some discussions: https://wiki.mozilla.org/Gecko:SplitWindow. One additional benefit of splitting window in Chrome is that accessing global variables don't need security checks anymore, it can improve applications that use many global variables.
V8 support of split window:
There are a small number of changes on V8 api to support split window:
Security context is removed from V8, so does related API functions;
A global object can be detached from its context and reused by a new context;
Access checks on an object template can be turned on/off by default;
An object can turn on its access checks later;
V8 has a new object type, ApiGlobalObject, which is the outer window object type. The existing JSGlobalObject becomes the inner window object type. Security checks are moved from JSGlobalObject to ApiGlobalObject. ApiGlobalObject is the one exposed to JavaScript, it is accessible through Context::Global(). ApiGlobalObject's prototype is set to JSGlobalObject so that property lookups are forwarded to JSGlobalObject. ApiGlobalObject forwards all other property access requests to JSGlobalObject, such as SetProperty, DeleteProperty, etc.
Security token is moved to a global context, and ApiGlobalObject has a reference to its global context. JSGlobalObject has a reference to its global context as well. When accessing properties on a global object in JavaScript, the domain security check is performed by comparing the security token of the lexical context (Top::global_context()) to the token of global object's context. The check is only needed when the receiver is a window object, such as 'window.document'. Accessing global variables, such as 'var foo = 3; foo' does not need checks because the receiver is the inner window object.
When an outer window is detached from its global context (when a frame navigates away from a page), it is completely detached from the inner window. A new context is created for the new page, and the outer global object is reused. At this point, the access check on the DOMWindow wrapper of the old context is turned on. The code in old context is still able to access DOMWindow properties, but it has to go through domain security checks.
It is debatable on how to implement the outer window object. Currently each property access function has to check if the receiver is ApiGlobalObject type. This approach might be error-prone that one may forget to check the receiver when adding new functions. It is unlikely a performance issue because accessing global variables are more common than 'window.foo' style coding.
I am still working on the ARM port, and I'd like to hear comments and suggestions on the best way to support it in V8.
Review URL: http://codereview.chromium.org/7366
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@540 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
