As an afterthought, I realized that I put function objects moves
reporting into a method that deals with only code object moves. I've
looked up that function objects are allocated in old pointer space and
new space, so I moved logging to the corresponding VM methods.
BUG=553
Review URL: http://codereview.chromium.org/552089
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3679 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem appeared due to a fact that stubs doesn't create a stack
frame, reusing the stack frame of the caller function. When building
stack traces, the current function is retrieved from PC, and its
callees are retrieved by traversing the stack backwards. Thus, for
stubs, the stub itself was discovered via PC, and then stub's caller's
caller was retrieved from stack.
To fix this problem, a pointer to JSFunction object is now captured
from the topmost stack frame, and is saved into stack trace log
record. Then a simple heuristics is applied whether a referred
function should be added to decoded stack, or not, to avoid reporting
the same function twice (from PC and from the pointer.)
BUG=553
TEST=added to mjsunit/tools/tickprocessor
Review URL: http://codereview.chromium.org/546089
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Always invoke HeapObjectIterator::has_next() before invoking HeapObjectIterator::next().
This is necessary as ::has_next() has an important side-effect of going to the next
page when current page is exhausted.
And to find if pointers are encodable use more precise data---top of map space, not a number
of pages, as pages might stay in map space due to chunking.
Review URL: http://codereview.chromium.org/552066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3672 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in particular).
* Called function is passed on the stack instead of
using a static variable.
* Builtins that don't need the called function don't
get it.
* Made is_construct statically known to HandleApiCall
by setting custom construct stub for API functions.
Review URL: http://codereview.chromium.org/536065
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3613 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
for partial snapshots. After reserving space we can be sure that allocations
will happen linearly (no GCs and no free-list allocation). This change also
contains the start of the partial snapshot support, which, however is not yet
completed or tested.
Review URL: http://codereview.chromium.org/545026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added newly added instructions to test-disasem-ia32.cc and implemented the missi
ng ones in the disasembler.
Added some asserts to 8-bit instructions which only work with eax, ebx, ecx and
edx (al, bl, cl and dl).
Removed the loope instruction.
Review URL: http://codereview.chromium.org/548002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3577 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
This adds a code stub which can do most of what Heap::AllocateConsString can do. It bails out if the result cannot fit in new space or if the result is a short (flat) string and one argument is an ascii string and the other a two byte string. It also bails out if adding two one character strings as Heap::AllocateConsString has special handling of this utilizing the symbol table. The stub is used both for the binary add operation and for StringAdd calls from runtime JavaScript files. Extended the string add test to cover all sizes of flat result stings.
Review URL: http://codereview.chromium.org/442024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3400 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For scripts originating from a call to eval the Script object used to hold a reference to the function from where the eval was called together with the code offset within that function of the eval call. This is used by the stack trace and is part of the debugger protocol. In order to avoid storing the function the script, the position within the script and the name of the function calling eval is stored instead. This avoids holding context dependent objects in the script object.
The calculation of the position of the eval in the script holding the eval is now done when the eval script is compiled as it is not possible to postpone this unless a reference is kept to the generated code for the function calling eval.
BUG=http://code.google.com/p/v8/issues/detail?id=528
TEST=cctest/test-api/Regress528
Review URL: http://codereview.chromium.org/450034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3393 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The check for the number og GC's required is now 1 or 2 instead of two to get rig of failures on ARM.
Updated the test to keep the code used by the test in the compilation cache by compiling it in another context. This makes the remaining issue with the eval cache more explicit.
Review URL: http://codereview.chromium.org/449051
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3387 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
This is needed to show calls to DOM in CPU profiles. I can think
of a better approach like adding specific functions into V8 API
for explicitly providing callback names and modifying bindings codegen
appropriately. My plan is as follows:
- submit this CL;
- implement anything I need to process log data and display DOM
calls in profiles;
- think again about adding specific functions and modifying bindings
codegen.
BUG=http://code.google.com/p/chromium/issues/detail?id=27613
Review URL: http://codereview.chromium.org/402100
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3340 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
Change name of shifts picking the shift count from cl to sal_cl, shl_cl and shr_cl.
Add special encoding of shift by one for shr which was missing it.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3314 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
available. We use this to ensure that snapshots on MacOSX can
use SSE2 instructions. Also clean up and assertify the
handling of things we can't do when we are generating a
snapshot. Fix a bug in the new serialization tests where
they activated Snapshot::enable() too late after code had been
generated that assumed no snapshots.
Review URL: http://codereview.chromium.org/391051
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
make standard regexps like \s and . case independent.
* Make use of the fact that the subject string is ASCII only
when making character classes case independent.
* Avoid spending time making large ideogram or punctuation
ranges case independent when there is no case mapping anyway.
Review URL: http://codereview.chromium.org/378024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3243 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
it in regular flat strings that are part of the snapshot.
After this change we don't need libraries-empty.cc any more. In
this change libraries-empty.cc is just a the same as libraries.cc
and the scons build builds it but does not use it. We can move
in stages to a situation where it is not generated at all for all
the build systems that we have.
Review URL: http://codereview.chromium.org/360050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3238 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the generated code for function.apply there was a loop checking the stack limit for interruption. This loop would call into the runtime system to handle interuption and keep running until there was no interruption. However if the interuption was debug break the runtime system would never clear the interruption as debug break is prevented in builtins are prevented and the assumption here was that returning with the debug break flag set would move execution forward.
Renamed initial_jslimit and initial_climit to real_jslimit and real_climit. Renamed a few external references related to the stack limit as well.
Exposed the real stack limit to generated code to make the stack check when entering function.apply use the real stack limit and not the stack limit which is changed to signal interruption.
Added the real stack limit to the roots array.
BUG=http://code.google.com/p/v8/issues/detail?id=493
TEST=cctest/test-debug/DebugBreakFunctionApply
Review URL: http://codereview.chromium.org/345048
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3229 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
- don't engage the processing thread of CPU profiling until the first time profiling is resumed, this saves us a thread allocation for the majority of users;
- don't log shared libraries addresses: this is useless for JS-only profiling, and also consumes time on startup.
Review URL: http://codereview.chromium.org/340013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3154 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of individual changes:
- Added infrastructure for custom stub caching.
- Push the code object onto the stack in exit calls instead of a
debug/non-debug marker.
- Remove the DEBUG_EXIT frame type.
- Add a new exit stub generator for API getters.
Review URL: http://codereview.chromium.org/330017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3130 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. This is a follow-on CL to
http://codereview.chromium.org/293023 .
Based on review feedback, defined the behavior of storing NaN and
+/-Infinity into external arrays of integer types as storing 0. Added
test cases. Added fucomi instruction to assembler. Fixed bug in
KeyedLoadIC::GenerateExternalArray when allocation of HeapNumber
failed. Fixed bug in encoding of 16-bit immediate arithmetic
instructions in 64-bit port.
Removed raising of exceptions for negative array indices passed to
external arrays and associated tests. Based on current discussion in
WebGL working group, will probably end up removing the exception
throwing altogether.
Review URL: http://codereview.chromium.org/294022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
When starting JS profiling under Chromium, a map from function addresses to function names is created. During it, for sourceful scripts, an attempt to access script source is made. This can cause a crash, if a source is an external string, which already has been disposed. We had a similar problem in the past with DebugGetLoadedScripts.
BUG=http://crbug.com/23768
TEST=test-log/Issue23768
Review URL: http://codereview.chromium.org/269003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3027 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
The main piece of this change was to add support for break on return for ARM. On ARM the normal js function return consist of the following code sequence.
mov sp, fp
ldmia sp!, {fp, lr}
add sp, sp, #4
bx lr
to a call to the debug break return entry code using the following code sequence
mov lr, pc
ldr pc, [pc, #-4]
<debug break return entry code entry point address>
bktp 0
The values of Assembler::kPatchReturnSequenceLength and Assembler::kPatchReturnSequenceLength are somewhat misleading, but they fit the current use in the debugger. Also Assembler::kPatchReturnSequenceLength is used in the IC code as well (for something which is not related to return sequences at all). I will change that in a separate changelist.
For the debugger to work also added recording of the return sequence in the relocation info and handling of source position recording when a function ends with a return statement.
Used the constant kInstrSize instead of sizeof(Instr).
Passes all debugger tests on both simulator and hardware (only release mode tested on hardware).
Review URL: http://codereview.chromium.org/199075
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
