This is for mobile platforms where application footprint size is
important. To avoid including compression libraries into V8, we assume
that the host machine have them (true for Linux), and rely on embedder
to provide decompressed data.
Currently, only snapshot data can be comressed. It is also possible to
compress libraries sources, but it is more involved and will be
addressed in another CL.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/6901090
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7724 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ensure that there is always enough bytes between consequtive calls in optimized code to write a call instruction at the return points without overlapping.
Add a call to deoptimize all functions after running tests with --stress-opt. This will catch some issues with functions which cannot be forcefully deoptimized. Some of the tests failed on ARM with that change without the rest of the changes in this change.
Review URL: http://codereview.chromium.org/6661022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Worth mentioning:
- Specialized versions of pixel array and store/loads inside the generic stubs have been removed, since to have parity for all external arrays, 8 different versions would have to be inlined/checked.
- There's a new constant in v8.h for external arrays with pixel array elements.
Review URL: http://codereview.chromium.org/6546036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
On 32-bit platforms any pointer with 0 as LSB can be wrapped into Smi. However, on 64-bit
platforms it's currently not the case as x64 Smis must have 0s in lower 32 bit word.
Even worse, macroassembler Move instruction will try to fetch integer value from Smi
and will shift by 32 bits to the right rendering stored pointer incorrect.
BUG=v8:1037
Review URL: http://codereview.chromium.org/6119009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As taking a snapshot of a large heap takes noticeable time, it's
good to be able to monitor and control it.
The change itself is small, big code deletes and additions are in
fact moves. The only significant change is simplification of
approximated retained sizes calculation algorithm.
Review URL: http://codereview.chromium.org/5687003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5978 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Approximation is done by building a dominators tree for the heap graph.
Dominator nodes and retained sizes are serialized into JSON.
Removed:
- reachable size (it is useless, after all);
- HeapEntryCalculatedData (size is now stored in the node, retaining
paths in a hash map);
Review URL: http://codereview.chromium.org/5154007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5867 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Otherwise, retaned memory sizes are not precise. This increases size
of heap snapshot, I will deal with this later. Heap objects and
references previously missing in snapshot are now marked as 'hidden'.
That means, they not shown to user, but participate in sizes
calculation.
Other small changes:
- added 'shortcut' graph edges: e.g. to pin global objects on top
level;
- meta-information in JSON snapshot is no more double encoded.
Review URL: http://codereview.chromium.org/5139002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
HeapNumbers do consume memory, so it's worth dumping them. However, we
don't dump their values, as they are not as self-descriptive as values
of strings, and they will increase snapshot size. Storing heap numbers
values can be added if we will feel a sufficient demand for that.
InternalFields are used, e.g. for storing references to DOM nodes
event handlers.
Review URL: http://codereview.chromium.org/3769007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5635 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
to avoid storing serialized snapshot on VM, instead it is emitted
using output stream interface.
The size of JSON emitted is roughly equal to used heap size
(when stored as an ASCII string).
Now a whole heap snapshot can be serialized and transmitted outside
VM. This makes possible:
- implementing non-async UI for heap snapshots inspection;
- storing heap snapshots for further inspection;
- remote profiling (we can even implement a snapshotting mode
where a snapshot isn't even stored in VM, only transmitted --
good for mobile devices);
- creating tools for outside heap snapshots processing, e.g.
converting to HPROF.
Review URL: http://codereview.chromium.org/3311028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5450 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allows the host application to provide a mechanism for notification and custom logging through a callback (set through the API V8::AddMemoryAllocationCallback and removed through V8::RemoveMemoryAllocationCallback), when V8 allocates ro frees memory.
This replaces the current histogram data "V8.ExecutableMemoryMax" by allowing usage data to be logged by the application as required rather than always through V8.
BUG=http://crbug.com/54222
TEST=Set the callback function with the API and cause V8 to allocate memory.
Patch by Paul Mehta <pmehta@chromium.org>
Review URL: http://codereview.chromium.org/3329006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5403 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Eventually indexed property query callbacks will return attributes
(as an integer) or an empty handle if property is not intercepted.
To gradually migrate to this new API, USE_NEW_QUERY_CALLBACK
macro would control if old or new style API is used.
So the migration plan is:
1) introduce new API which should be explictily enabled;
2) switch to new API defining USE_NEW_QUERY_CALLBACK before
include of <v8.h> (that would require changes to client code as well)
3) remove old API from v8
4) remove #define USE_NEW_QUERY_CALLBACK from clients.
BUG=http://code.google.com/p/v8/issues/detail?id=816
Review URL: http://codereview.chromium.org/3101001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5228 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If object enters NEAR_DEATH state, it must be explicitly cleared and/or disposed, otherwise
it would retain JS object forever. Note as well that parameter is reset to NULL on first
invocation so weak handle callback would be in hard situation.
Review URL: http://codereview.chromium.org/3011009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
TYPE_CHECK in v8.h should assign to volatile qualified null-pointer.
Unless the pointer is volatile qualified, Clang will warn that LLVM
removes the assignment during optimization. This is not a problem as
that code should never execute, but the warning is treated as an error
when building Chromium, and thus stops the build.
Code review URL: http://codereview.chromium.org/3005010/show
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5093 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To trace objects between snapshots, an external map of object tags is
maintained. After the first heap snapshot has been taken, the map is
updated by reporting object moves from the GC. If no snapshots were
taken, there is no overhead (except for flag checking).
I considered graph comparison algorithms that doesn't require using
object tags, but they are all of a high computational complexity, and
will still fail to detect object moves properly, even for trivial
cases, so using tags looks like unavoidable.
Review URL: http://codereview.chromium.org/3020002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5078 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix issues so v8 could be built as a DLL.
-. get rid of all the compiler warning by moving dllexport/dllimport
to the individual members for classes which have inline members.
-. update v8 gyp to build v8.dll for chromium multi-dll version (win
and component==shared_library)
Note: most of the code are contributed by sjesse.
Code review URL: http://codereview.chromium.org/2882009/show
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This changes the way the constants kJSObjectType, kFirstNonstringType and kProxyType are made available to the inlined part of the V8 API. This change to fixed constants resolves linker this linker error Windows
error LNK2001: unresolved external symbol "public: static int v8::internal::Internals::kJSObjectType" (?kJSObjectType@Internals@internal@v8@@2HA)
when linking against a V8 DLL.
This change also makes it possible to build all the C++ tests with ENABLE_DEBUGGER_SUPPORT not defined. Now C++ tests run ENABLE_DEBUGGER_SUPPORT not defined, and only the JavaScript tests which tests the debugger fails when ENABLE_DEBUGGER_SUPPORT is not defined.
Review URL: http://codereview.chromium.org/2820016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4898 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changed the disposal of external string resources to call a virtual Dispose method on the resource. The default inplementation of Dispose deletes the object and will capture the delete operator matching the new operator used to allocate the object.
Review URL: http://codereview.chromium.org/2658008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4816 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Eventually named property query callbacks will return attributes
(as an integer) or an empty handle if property is not intercepted.
To gradually migrate to this new API, USE_NEW_QUERY_CALLBACK
macro would control if old or new style API is used.
So the migration plan is:
1) introduce new API which should be explictily enabled;
2) switch to new API defining USE_NEW_QUERY_CALLBACK before
include of <v8.h> (that would require changes to client code as well)
3) remove old API from v8
4) remove #define USE_NEW_QUERY_CALLBACK from clients.
Review URL: http://codereview.chromium.org/2576003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4797 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently one can only define accessors on object templates. This patch
allows to create accessors on the fly.
These accessors could control access to elements as well. This element
support is somewhat rudimentary and may require future work (for example,
we probably don't want to convert index into a string.)
Review URL: http://codereview.chromium.org/2123012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4714 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changing ScriptData API to serialize its internal representation to a
const char* array.
This decouples the API from the internal representation and avoids the need for
callers to serialize themselves.
As a side-effect, ScriptData::New() no longer assumes ownership of its input.
This shouldn't matter as typical usage patterns for the old API would have
required a copy prior to calling ScriptData::New().
Review URL: http://codereview.chromium.org/2118010/show
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4710 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As several pages can run in a single V8 instance, it is possible to
have functions from different security contexts intermixed in a single
CPU profile. To avoid exposing function names from one page to
another, filtering is introduced.
The basic idea is that instead of capturing return addresses from
stack, we're now capturing JSFunction addresses (as we anyway work
only with JS stack frames.) Each JSFunction can reach out for
context's security token. When providing a profile to a page, the
profile is filtered using the security token of caller page. Any
functions with different security tokens are filtered out (yes, we
only do fast path check for now) and their ticks are attributed to
their parents.
Review URL: http://codereview.chromium.org/2083005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Exposes Local<Context> v8::Debug::GetDebugContext().
Rationale: We can already get debugger context instance using various workarounds,
so exposing it explicitly in the API only makes things more clear.
2) Removes debugger.HasJavaScriptFrames() requirement for entering debugger context.
Rationale: Sometimes we'd like to call into debugger from the external native code.
3) Makes Debugger v8::Debug::Call execute on debugger context's global object.
Rationale: This is somewhat arguable, but temporary measure. We've agreed that we
should introduce a DebugAPI object that would expose necessary API in the debug-delay.
The problem is that it would take some time to define this API and it is not really
convenient to do that on the v8 land given the difference in v8 / host lifecycle.
The plan is to compose this API as a Debug.* wrapper outside v8 by means of exposing
debugger context's global object here, and once API settles down, upstream it to v8 and
start making Debug::Calls on this new DebugAPI object instead.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4251 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Added Get and Set taking uint32_t for faster and more convenient
access to elements.
* Added less verbose casting for handles. Now instead of
v8::Local<v8::String>::Cast(args[0])
one can write
args[0].As<v8::String>().
Review URL: http://codereview.chromium.org/660243
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4002 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change allows to associate integer tags with blocks of profiler
log events, and repeat calls to 'ResumeProfiler' / 'PauseProfiler' in
order to establsh nested (not necessary properly nested) blocks. By
supporting this, we will be able to match WebInspector's CPU profiler
abilities in DevTools.
I also refactored some testing code.
Review URL: http://codereview.chromium.org/619004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3889 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of weak handles external strings use a separate table. This
table uses 5 times less memory than weak handles. Moreover, since we
don't have to follow the weak handle callback protocol we can collect
the strings faster and even on scavenge collections.
Review URL: http://codereview.chromium.org/467037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3439 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Storing a JSArray in the Script object could cause an indirect reference from the compilation cache to a global object to be created. Now the line ends are only stored as a FixedArrya and when that is needed in JavaScript a JSArray copy is created. Changed some of the JavaScript code to cache the line ends in a local variable for better performance.
BUG=http://code.google.com/p/v8/issues/detail?id=528
TEST=test/test-api/Bug528
Review URL: http://codereview.chromium.org/434117
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3374 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The different length string types was used to encode the string length and the hash in one field. This is now split into two fields one for length and one for hash. The hash field still encodes the array index of the string if it has one. If an array index is encoded in the hash field the string length is added to the top bits of the hash field to avoid a hash value of zero.
On 32-bit this causes an additional 4 bytes to be used for all string objects. On 64-bit this will be half on average dur to pointer alignment.
Review URL: http://codereview.chromium.org/436001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A callback on the debugger thread when a message is received. Allows the
embedding application to wake up the main thread in order to handle the
message. Useful when the embedding application is idle and sitting in a
select() call.
Patch by Ryan Dahl <coldredlemur@gmail.com>
Review URL: http://codereview.chromium.org/395013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
separate JS stack.
In exception handling, we need to be able to compare addresses into
the JavaScript portion of the stack with the address of a C++ handler
on the stack. Since the stacks are separate on the simulator, we need
a JavaScript stack address corresponding to a C++ try catch handler in
order to perform valid address comparisons.
On the simulator, we now link the C++ try catch handlers indirectly
through the JS stack and use the JS stack indirection address for
comparisons.
JS C++
handler
[C++ address] <------ next_
\
\
\----> handler
[C++ address] <------ next_
On actual hardware the C++ try catch handlers continue to be directly
linked.
BUG=http://code.google.com/p/v8/issues/detail?id=271
Review URL: http://codereview.chromium.org/360004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3228 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
