Fix for issue 603.
Revision r3484 removed the property name from the call stack for
call ICs. When a non-function was called via a call IC and
Function.prototype.call, an extra value was left on the stack that the
caller could not know to clean up.
Fix is to change the JS builtin used for calling non-functions. It
now gets the callee as receiver, rather than iterating stack frames
and finding it on the expression stack of its JS caller.
Review URL: http://codereview.chromium.org/604064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3882 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Simple objects which are constructed without calling the actual constructor function did not take setters defined on prototype chain of the new object into account.
Constructing objects this way is now not done if there are setters involved on the prototype chain of the new object.
This only fixes the case where the setter is found when the first object from a constructor is created. If the prototype chain is changed new objects will on take any change to setters into account.
TEST=test/mjsunit/setter-on-constructor-prototype.js
Review URL: http://codereview.chromium.org/606062
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
With the current API the embedder has to extrenalize a string each
time a string is encountered to avoid the cost of repeated character
copying/conversion. The issue here is that the externalization cost
itself is non-negligible (both in time and space) and should not be
paid for a rarely used string. This change is an attempt to predict a
string's usage frequency based on its freshness. A string is
considered fresh if it was recently allocated in the new space.
Review URL: http://codereview.chromium.org/608006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change add simple local live variable information to
the fast code generator. It supports only AST nodes that
are accepted by the syntax checker.
Each variable use points to a variable definition structure
which contains the last use of the definition.
To determine whether a variable is live after a certain point
we can check whether its last use occurs later in the evaluation
order defined by the AST labeling number.
The new information is currently only printed out together with
the IR and not yet used for code generation.
Review URL: http://codereview.chromium.org/603004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3839 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Do not use the speculative compiler for functions with other than one
statement in the body, and do not use it if subexpressions can have
side effects. Bailing out to the beginning of the full code is not
sound if side effects have already occurred.
Add tests that would fail without the restrictions.
Review URL: http://codereview.chromium.org/598016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3826 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Support a binary operation (bitwise OR) so long as it's not nested in
the left subexpression. This ensures that the expression stack never
has height greater than two and so can be kept fully in registers.
The bounded expression stack height and the absence of any side
effects on the fast path allows us to still bailout out to the very
beginning of the function if any of our fast-path checks fail.
Review URL: http://codereview.chromium.org/594008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3822 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
on functions that takes five or more arguments. Original version runs
for a long time when there is 5 arguments in a runtime function (45+
seconds). The fuzzer can be run with all arguments on all functions
regardless of the number of arguments by setting
RUN_WITH_ALL_ARGUMENT_ENTRIES to true in fuzz-natives.js
Review URL: http://codereview.chromium.org/598011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3819 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a first step towards loading globals directly from property cells instead
of going through a load IC.
This change supports only properties with the DontDelete attribute since
we are only able to bailout into the generic code generated by the secondary
code generator the beginning of a function. The resulting fast-case code is
specialized for a specific context. When invoked with a different global object,
it will always bailout to the secondary code.
When loading a property that does not exist at compile-time or a property
that is deleteable we still generate the generic load IC.
Review URL: http://codereview.chromium.org/565034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3808 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
this causes the debug check to fails since type() asserts that the
lookup_type != NOT_FOUND. This does not change any functionality since we
explicitly checked if it was one of the three types that we need to delete.
Also changed defineProperties in v8natives to actually return the object
being defined (as specified by spec)
Review URL: http://codereview.chromium.org/572003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
DefineOwnProperty (changed to allow for redefinition of existing property)
SameValue
Extra info on propertydescriptor
GetProperty
HasProperty
Currently the DefineOrRedefineAccessorProperty deletes the existing
property on the object if it is a dataproperty (FIELD or NORMAL) and
adds a new one. This can potentially be optimized.
Review URL: http://codereview.chromium.org/555149
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When functions only have simple assignments of the form this.x = ... the object is created in generated code without actually calling the constructor. In this case the initial map for the function already contains the properties assigned in the constructor. The field descriptors in this initial map now has an enumeration index assigned to make property enumeration order the insertion order. The insertion order here is the order of the this.x assignments in the code.
BUG=http://crbug.com/3867
TEST=test/mjsunit/regress/regress-crbug-3867.js
Review URL: http://codereview.chromium.org/566016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3768 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
objects in the startup heap from a partial snapshot. This happens
through the partial snapshot cache. A startup snapshot and a
partial snapshot are created together so that the startup snapshot
contains the partial snapshot cache entries needed.
Review URL: http://codereview.chromium.org/548149
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As the start index is already passed it is easy to calculate the "at start" boolean in generated code. Also as direct entry has been implemented this needs to be done in generated code anyway, and therefore might as well be moved to the generated code for RegExp. The "at start" value is now calcualted as a local variable on the native RegExp frame based on the value of the start index argument.
The x64 version have been tested on both Linux and 64-bit Windows Vista.
For ARM I have tested cctest/test-regexp on ARM hardware, but the rest of the tests have only been run on the ARM simulator.
Review URL: http://codereview.chromium.org/554078
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
non-optimizing compiler can cope with. By default it bails out
to the old compiler on encountering a for loop (for performance)
but with this change the --always-fast-compiler flag will enable
functions with for loops to be compiled in the non-optimizing
compiler. Also enables the non-optimizing compiler on functions
that can be lazily compiled (again only with the flag).
Review URL: http://codereview.chromium.org/552065
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3667 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Most of the test cases fail as the different objects according to the tests
can not have additional properties attached to them. I will file a bug report
on the es5 conform site as they should allow this. Some of the test fails
because we still miss some of the es5 features used.
Review URL: http://codereview.chromium.org/545109
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3642 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a function is called with a value type as the receiver this is now boxed as an object.
This is a low-impact solution where the receiver is only boxed when required. For IC calls to the V8 builtins values are not boxed and as most of the functions on String.prototype, Number.prototype and Boolean.prototype are sitting there most IC calls on values will not need any boxing of the receiver.
For calls which are not IC calls but calls through the CallFunctionStub a flag is used to determine whether the receiver might be a value and only when that is the case will the receiver be boxed.
No changtes to Function.call and Function.apply - they already boxed values. According to the ES5 spec the receiver should not be boxed for these functions, but current browsers have not adopted that change yet.
BUG=223
TEST=test/mjsunit/value-wrapper.js
TEST=test/mjsunit/regress/regress-crbug-3184.js
Review URL: http://codereview.chromium.org/542087
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3617 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
Until now we only supported postfix operations on global variables.
This change add generic count operations to the top-level compiler.
I tried to re-use code from the code generator used for assignment expressions
where possible.
Review URL: http://codereview.chromium.org/496009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3530 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
On 32-bit the maps are now aligned on a 32-byte boundary in order to encode more maps during compacting GC. The actual size of a map on 32-bit is 28 bytes making this change waste 4 bytes per map.
On 64-bit the encoding for compacting GC is now using more than 32-bits and the maps here are still pointer size aligned. The actual size of a map on 64-bit is 48 bytes and this change does not intruduce any waste.
My choice of 16 bits for kMapPageIndexBits for 64-bit should give the same maximum number of pages (8K) for map space. As maps on 64-bit are larger than on 32-bit the total number of maps on 64-bit will be smaller than on 32-bit. We could consider raising this to 17 or 18.
I moved the kPageSizeBits to globals.h as the calculation of the encoding really depended on this.
There are still an #ifdef/#endif in objects.h and this constant could be moved to globaks.h as well, but I kept it together with the related constants.
All the tests run in debug mode with additional options --gc-global --always-compact as well (except for a few tests on which also fails before this change when run with --gc-global --always-compact).
BUG=http://code.google.com/p/v8/issues/detail?id=524
BUG=http://crbug.com/29428
TEST=test/mjsunit/regress/regress-524.js
Review URL: http://codereview.chromium.org/504026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3481 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
Condition block of do/while statements is a valid break location so it should have its own position. The block is represented by a regular Expression node so we cannot store the position in it, instead the position is stored in a separate field in DoWhileStatement AST node.
BUG=514
Review URL: http://codereview.chromium.org/385136
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3312 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
regular expressions to be consistent with typeof in other contexts.
Typeof regular expressions should now be 'function' in all contexts.
In the JS natives, IS_FUNCTION, IS_OBJECT, and IS_REGEXP return the
same answers as before.
Review URL: http://codereview.chromium.org/360053
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3231 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
used to signal that an expression was the immediate subexpression of
typeof, or (?) in the arm of a conditional expression itself in the
typeof state.
It was inconsistently consulted. It was not used for property loads,
but only for slot loads. This means that we matched the Webkit JSC
(not Spidermonkey) behavior for:
typeof(true ? x : y) // throws ReferenceError
and we matched the SpiderMonkey behavior (not JSC) for:
with ({}) { typeof(true ? x : y) } // ==> "undefined"
Now we are expected to match the JSC behavior in all cases.
Review URL: http://codereview.chromium.org/362004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3212 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
o.x() and o[expr]()
other changes:
- Fix missing relocation info for StoreIC on global object.
- Generate only one common return sequence instead of always appending
"return <undefined>" at the end of each function: The first JS
return-statement will generate the common return sequence. All
other return-statements will generate a unconditional branch to the common
return sequence.
Review URL: http://codereview.chromium.org/340037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3183 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
I also added more unit tests for literals.
Right now, the fast compiler produces code very similar to
the existing code generator. We may consider different ways to
further compact the generated code for top-level code.
ARM always goes through a runtime function to initialize computed
properties in an object literal whereas IA32 and x64 use StoreIC.
Review URL: http://codereview.chromium.org/316009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3129 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
currently compiled the same as with the optimizing compiler: they are
cloned from a boilerplate object and the boilerplate objects are
lazily constructed.
Also changed argument pushing on ARM to use stm (store multiple),
which required changing the order of arguments to the runtime
functions DeclareGlobals and NewClosure. They were only used from
generated code.
Finally, changed the toplevel code generator so that stack pops to
discard a temporary became addition to the stack pointer on ia32 and
x64.
Review URL: http://codereview.chromium.org/303021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3110 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
Based on a recent patch for Webkit.
trim is defined in ES 5 section 15.5.4.20.
Author: Jan de Mooij <jandemooij@gmail.com>
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3052 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
1. Change the AST node type CallNew to be a subclass of Expression
rather than Call. It's not really a call but it just happens to
have the same fields.
2. Change our error reporting for invalid left-hand sides in for-in
statements, pre- and postfix count expressions, and assignments.
Before we signaled a syntax error at compile time *unless* the LHS
was a function call or 'new' expression, in which case we signaled
a reference error at runtime. Now we signal a reference error at
runtime in all cases. This matches the JSC behavior in Safari 4.
Review URL: http://codereview.chromium.org/249039
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2994 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
In the Runtime_DebugGetPropertyDetails the raw object pointers from a LookupResult could be used after a GC might have happened. Fixed the bug and restructured the code to make it less likely for changes to the code to re-introduce the bug.
Skipped a long running test from the ARM simulator in debug mode (and renamed the test).
Review URL: http://codereview.chromium.org/204039
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The construction of arrays when using the the Array function either as a constructor or a normal function is now handled fully in generated code in most cases. Only when Array is called with one argument which is either negative or abowe JSObject::kInitialMaxFastElementArray (which is currently 1000) or if the allocated object cannot fit in the room left in new space is the runtime system entered.
Two new native code built-in functions are added one for normal invocation and one for the construct call. The existing C++ builtin is renamed, but kept. When the normal invocation cannot be handled in generated code the C++ builtin is called. When the construct invocation cannot be handled in native code the generic construct stub is called (which will end up in the C++ builtin through a construct trampoline).
One thing that might be changed is preserving esi (constructor function) during the handling of a construct call. We know precisily what function we where calling anyway and can just reload it. This could remove the parameter construct_call to ArrayNativeCode and remove the handling of this from that function.
The X64 and ARM implementations are not part of this changelist.
Review URL: http://codereview.chromium.org/193125
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2899 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
Removed a false assertion in ScopeIterator that assumed context extension to never be a JSContextExtensionObject.
The context extension object in a 'with' context is JSContextExtensionObject iff the 'with' statement is generated from a catch block in order to extend its local scope with a variable holding exception object. This is how we differentiate 'catch' scope from 'with' scope.
Chrome bug:
http://code.google.com/p/chromium/issues/detail?id=17229
Review URL: http://codereview.chromium.org/202005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2843 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The SCons build now supports building for 64-bit Windows. This still requires that the SCons build is passed an env parameter containing the PATH and LIB for the 64-bit build as SCons autodetects the 32-bit environment.
Lowered the warning level for the 64-bit build temporarily.
Added a verbose option to SCons to display the startup banner for the Microsoft Visual C++ tools.
Review URL: http://codereview.chromium.org/174605
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2774 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a
specialized constructor stub is now generated. This generated code allocates the
object and fills in the initial properties directly. If this fails for some
reason code continues in the generic constructor stub which in turn might pass
control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change.
For x64 and ARM the generic construct stub is used.
This is change is identical to http://codereview.chromium.org/174392 (committed in r2753 and reverted in r2754) except that a few parts have already been committed from http://codereview.chromium.org/173469 (committed in r2762).
Review URL: http://codereview.chromium.org/173470
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When copying a map always set the descriptor array to describe the pre-allocated properties, even when descriptors are to be dropped.
Added a test which otherwise failed with an assert on ARM in debug mode. The reason for it only surfasing on ARM is that the NewObject runtime function is always used for allocating new JSObjects on ARM.
This change includes a few parts of http://codereview.chromium.org/174392 needed to trigger the error.
Review URL: http://codereview.chromium.org/173469
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2762 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a specialized constructor stub is now generated. This generated code allocates the object and fills in the initial properties directly. If this fails for some reason code continues in the generic constructor stub which in turn might pass control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change. For x64 and ARM the generic construct stub is used.
Review URL: http://codereview.chromium.org/174392
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2753 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
MSVS names '.map' file using only module's name, so both 'a.exe' and 'a.dll' will have 'a.map' file. To distinguish an originating module, we're now checking for image base which is always 00400000 for .exe files, and not 00400000 for .dlls.
Verified that windows-tick-processor can now process logs from Chromium using .map file generated for 'chrome.dll', an that it still works for V8's 'shell.exe'.
Review URL: http://codereview.chromium.org/172044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2699 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'm planning to use it in DevTools heap profiler. It is a common scenario in debugging memory leaks to enforce GC, then perform an operation, then enforce GC again to check for non-collected (that is, leaked) objects. Using the existing GC extension isn't possible because it doesn't exposed in the normal operation mode of Chromium.
Review URL: http://codereview.chromium.org/159787
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2619 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
I found two causes of flakinness:
- SIGPROF signal isn't delivered to a process;
- Profiler thread (the one that retrieves tick events from
the queue and writes to log) doesn't get a CPU;
Both are fixed.
The script from bug description with run count increased to 200 runs without any test failures.
OS X and Windows are unaffected because they don't use signals mechanism.
BUG=http://code.google.com/p/v8/issues/detail?id=410
TEST=see bug description
Review URL: http://codereview.chromium.org/159406
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2547 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We did not handle the case where the left-hand-side expression was
fully compiled to control flow. There were also some assertions for
unary and binary expressions that crashed debug builds when the
expression was fully compiled to control flow.
Regression test added.
Review URL: http://codereview.chromium.org/160006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2524 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
'nm' is now called with an option to report function code sizes. Static code entries are restricted to the sizes reported, and the remaining unnamed code is attributed to a library as a whole. This makes reports more accurate, as some functions are tiny, but has chunks of unnamed code behind them.
This change doesn't affect reporting on Windows, as in .map files function code sizes aren't specified.
Review URL: http://codereview.chromium.org/149513
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2455 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Fast runtime calls for div and mod.
* Fix assembly and disassembly of multiply instructions.
* Strength reduce and inline multiplications to shift-add.
* Strength reduce and inline mod by power of 2.
* Strength reduce mod by other small integers to mul.
* Strength reduce div by 2 and 3.
Review URL: http://codereview.chromium.org/155047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2355 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
With the new representation of the global object adding JavaScript accessors for a property after global inline caches was created for that property did not work property as the inline caches did not take the JavaScript accessor information (fixed array with two elements) that could be present in a global object property cell into account.
This is now fixed by changing the map for a global object when a JavaScript accessor is defined on it.
BUG=394
TEST=test\mjsunit\regress\regress-394.js
Review URL: http://codereview.chromium.org/150162
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove the check for deleted properties in the global load inline cache if the property is known to be read only.
Propegate the in loop flag for the global call inline cache.
Changed the propagation of the code flags in the call stub compiler to compute these the same way for all types of call stubs and assert that the flags for the generated code is the same as those used for the cache lookup.
Addressed a few comments from previous review in test-api.cc.
Review URL: http://codereview.chromium.org/150101
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2308 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Error, ReferenceError, etc. are given a stack property that gives a
stack trace. Here's an example stack trace:
ReferenceError: FAIL is not defined
at Constraint.execute (deltablue.js:527)
at Constraint.recalculate (deltablue.js:426)
at Planner.addPropagate (deltablue.js:703)
at Constraint.satisfy (deltablue.js:186)
at Planner.incrementalAdd (deltablue.js:593)
at Constraint.addConstraint (deltablue.js:164)
at Constraint.BinaryConstraint (deltablue.js:348)
at Constraint.EqualityConstraint (deltablue.js:517)
at chainTest (deltablue.js:809)
at deltaBlue (deltablue.js:881)
at deltablue.js:888
If Error.prepareStackTrace holds a function this function is used to
format the stack trace, for instance allowing code generators to
customize the way stack traces are reported to make them easier to
process.
Next step: performance measurements to see if it is feasible to turn
this on by default.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2302 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Fix incorrect signedness in disassembly of umull/mull on ARM.
* Fix incorrect register order in disassembly of umull/mull.
* Fix incorrect assembly of umull on ARM.
* Remove retroactively obsoleted restriction on choice of
registers in mul instructions on ARM.
Review URL: http://codereview.chromium.org/150002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2292 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Because of varying floating-point precision, the slow case is hard to
test with explicit values. Instead, we check that sine and cosine do
not return the same value (the regression was that the slow case of
cosine accidentally did sine instead of cosine).
Review URL: http://codereview.chromium.org/126123
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2169 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Code addresses are now written as an offset from the previous address for ticks, code move and delete events. Employed backreference and RLE compression for code move and delete events. This gives additional 30% log size reduction for benchmarks run w/o snapshot.
Overall compression results (compared with the revision of V8 having no compression):
- V8: 70% size reduction for benchmarks run w/o snapshot (for reference, gzip gives 87%)
- Chromium: 65% size reduction for public html version of benchmarks (v4) (for reference, gzip gives 90%)
The one obvious opportunity for improving compression results in Chromium is to compress URLs of scripts.
Review URL: http://codereview.chromium.org/125114
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For each frame it is now possible to request information on the scope chain. Each scope in the chain can have one of the types local, global, with and closure. For scopes of type global and with the mirror for the actual global or with object is available. For scopes of type local and closure a plain JavaScript object with the materialized content of the scope is created and its mirror is returned. Depending on the level of possible optimization the content of the materialized local and closure scopes might only contain the names which are actually used.
To iterate the scope chain an iterator ScopeIterator have been added which can provide the type of each scope for each part of the chain. This iterator creates an artificial local scope whenever that is present as the context chain does not include the local scope.
To avoid caching the mirror objects for the materialized the local and closure scopes transient mirrors have been added. They have negative handles and cannot be retrieved by subsequent lookup calls. Their content is part of a single response.
For debugging purposes an additional runtime function DebugPrintScopes is been added.
Added commands 'scopes' and 'scope' to the developer shell and fixed the dir command.
BUG=none
TEST=test/mjsunit/debug-scopes.js
Review URL: http://codereview.chromium.org/123021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2149 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Two techniques are involved:
- compress repeated line ends (common stack beginnings) by using back references;
- do RLE compression of repeated tick events.
This gives only 5% size reduction on benchmarks run, but this is because tick events are only comprise 10% of file size. Under Chromium winnings are bigger because long repeated samples of idleness are now compressed into a single line.
Tickprocessor will be updated in the next patch.
Review URL: http://codereview.chromium.org/123012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2147 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Scripts now have a compilation type which can be host, eval or JSON. Host scripts are compiled through the API, eval scripts are compiled through call to evan and JSON scripts are compiled as a result of calling JSON.parse.
For scripts scripts compiled through eval the JavaScript function in top of the stack and the pc offset into the code is stored in the script object. This makes it possible to calculate the source position of the eval call later when requested. This information can be obtained through the script mirror object and is part of the script mirror JSON serialization for the debugger protocol.
Moved the enumeration ScripType into class Script and remamed to Type. The new compilation type enumeration is also inside the class Script.
This information is now shown when using the scripts command in he developer shell debugger.
Review URL: http://codereview.chromium.org/119108
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2119 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
interceptors and dont-delete attributes.
Minor change to the behavior of eval: throw exception when calling
eval in a context for which the global has been detached. This
matches the behavior of both Firefox and Safari post navigation in the
browser.
Review URL: http://codereview.chromium.org/118374
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
submitted in revisions 2093, 2094, 2099, and 2106.
There's no evidence that supports that these changes
should be the cause of the unexplained performance
regressions on the intl2 and DHTML page cyclers.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem was I incorrectly treated NULL result as failure to fetch
a property with a getter. However, if getter returns zero, it is
manifested as NULL pointer (see added test case).
Good news: that gives another boost as before this CL if getter returned
0, I did another slow lookup.
Review URL: http://codereview.chromium.org/119172
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.
Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.
Review URL: http://codereview.chromium.org/112082
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Running "system" JavaScript with the debug break flag active leads to slow running code while waiting for the break in non "system" JavaScript (one exception to this it is to try to avoid breaks in the clear mirror cache JavaScript code called when leaving the debugger).
* If this happens while processing RegExp running in native code an infinite loop is created as the stack guard handler for RegExp does not move execution forward
Fixed a GC bug in the interrupt handling for RegExp running in native code.
Added test of debug break while in debug message handler callback and debug break while executing a RegExp.
Review URL: http://codereview.chromium.org/115262
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When profiler's memory buffer is filled up, profiling is stopped and it is ensured that the last record in the buffer is "profiler,\"pause\"" thus making the end of profiling session explicit. Otherwise DevTools Profiler would need to guess whether the current profiling session has been stopped.
Tested with Chromium.
Review URL: http://codereview.chromium.org/115859
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2072 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The goal of this change is to allow longer profiling sessions and preserve memory when profiler isn't started. The buffer starts with 64K and grows until it reaches the upper limit, which is currently set to 50MB --- according to my evaluations, this is enough for at least 20 minutes of GMail profiling. As we're planning to introduce compression for the profiler log, this time boundary will be significantly increased soon.
To make possible unit testing of the new component, I've factored out Logger's utility classes into a separate source file: log-utils.h/cc. Log and LogMessageBuilder are moved there from log.cc without any semantical changes.
Review URL: http://codereview.chromium.org/115814
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2067 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
This is intended to be used with Chromium. When in resource-saving mode, profiler doesn't consume any resources (sampler and logging is off) until resumed. Then again, when profiler is paused, sampling and logging are turned off.
Tested under Linux and Windows. Also have done preliminary testing with Chromium.
Review URL: http://codereview.chromium.org/113762
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2036 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Without the change the debugger may crash as Debugger::EventActive(v8::Break) called from OnDebugBreak may clear current debugger context.
Also when compilation cache was enabled debugger could fail on second attach for the same reason(see AfterCompileMessageWhenMessageHandlerIsReset).
BUG=12404
Review URL: http://codereview.chromium.org/115709
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If was failing because with snapshot the range between minimum and maximum addresses of heap objects is very large (close to 0xf0000000). To fix this I rewrote handling of address maps in the test.
Submitting with TBR because of late time. I think, we'll need to revisit this change tomorrow.
TBR=sgjesse@chromium.org
Review URL: http://codereview.chromium.org/113641
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2019 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The goal is to make possible having --prof flag always enabled in Chromium. Currently we can't do this because --prof causes compiler and gc to log code creations / moves / deletes which aren't needed until we start profiling. With LogCompiledFunctions it will be possible not to log anything until we start profiling. When started, the current map of compiled functions will be logged and compiler / gc logging will be enabled to update current state. When profling is stopped, logging will be turned off again.
Funny that testing code is actually much longer and complex than function code.
Review URL: http://codereview.chromium.org/112036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2009 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
This will enable reading profiler log in Chrome. The current implementation of memory buffer is trivial (fixed size buffer, no memory recycling) but enough to start end-to-end DevTools Profiler implementation. Later it will be enhanced.
Review URL: http://codereview.chromium.org/108011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1870 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- TARGET, the architecture we will generate code for.
This is brought it from the build system.
- HOST, the architecture our C++ compiler is building for.
This is detected automatically based on compiler defines.
This adds macros for 32 or 64 bit, and cleans up some
include conditionals, etc.
Review URL: http://codereview.chromium.org/99355
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1864 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
NPN_Construct allows a NPObject to be called as a construct. For example, the
test case
var s = new app.Packages.java.lang.Integer(5);
app.Packages.java.lang.Integer is a NPObject, and it implements NPN_Construct.
This fix allows a JSObject created by an API function be called as a construct
if it can be called
as a function. This is done by generating the same code for
var s = new app.Packages.java.lang.Integer(5); as
var s = app.Packages.java.lang.Integer(5);
and the caller handles both case correctly. A more sophiscated fix is to one
extra JSConstructCall
frame and allow CallAsConstructor in Builtin::HandleApiCallAsFunction.
This change itself shouldn't affect the semantic of normal case such as:
var a = {};
var s = new a();
A TypeError exception will be thrown in CALL_NON_FUNCTION (runtime.js).
Another part of fix is in the binding code, V8NPObject, which makes
NPN_InvokeDefault or NPN_Construct
call depending on which function is available.
Review URL: http://codereview.chromium.org/100243
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1837 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current version is now held in src/version.cc in a number of defines which needs to be modified when changing version.
The following defines make up the version information:
MAJOR_VERSION
MINOR_VERSION
BUILD_NUMBER
PATCH_LEVEL
CANDIDATE_VERSION
The first four are numbers and the fifth is a boolean. Besides these five the define
SONAME
can be used to set a specific soname when building the a shared library (see below). This will most likely be used on stable branches where binary compatibility is ensured between different versions. This define is a string.
This version information is now read by the SCons build to support setting the soname for a Linux shared library. This requires passing the option soname=on to the SCons build.
When soname=on is specified the soname for the shared library can be set in two different ways. Either it will be the full versioned library name (e.g. libv8-1.2.2.so) or a specific soname defined in src/version.cc. Whenever a shared library is build with an soname the filename of the library will hold the full version name (e.g. libv8-1.2.2.so).
I did not update the xcode project with the new files.
BUG=151
Review URL: http://codereview.chromium.org/100104
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1826 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
