* Identify heap numbers that contain non-Smi int32s and do bit
ops on them without calling the fp hardware or emulation.
* Identify results that are non-Smi int32s and write them into
heap numbers without calling the fp hardware or emulation.
* Do unary minus on heap numbers without going into the runtime
system.
* On add, sub and mul if we have both Smi and heapnumber inputs
to the same operation then convert the Smi to a double and do
the op without going into runtime system. This also applies
if we have two Smi inputs but the result is not Smi.
Review URL: http://codereview.chromium.org/119241
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2131 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a trivial per-row compression:
- short aliases are introduced for events and code creation tags;
- in tick events, offsets are used instead of absolute addresses;
- removed 'code-allocation' event, as it seems not used.
The first two options are depend on the new flag: 'compress-log', which is off by default.
On benchmarks run w/o snapshot, this gives 45% log size reduction.
Review URL: http://codereview.chromium.org/119304
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
deferred code snippets are highly stylized. They always make a call
to a stub or the runtime and then return. This change takes advantage
of that.
Creating a deferred code object now captures a snapshot of the
registers in the virtual frame. The registers are automatically saved
on entry to the deferred code and restored on exit.
The clients of deferred code must ensure that there is no change to
the registers in the virtual frame (eg, by allocating which can cause
spilling) or to the stack pointer. That is currently the case.
As a separate change, I will add either code to verify this constraint
or else code to forbid any frame effect.
The deferred code itself does not use the virtual frame or register
allocator (or even the code generator). It is raw macro assembler
code.
Review URL: http://codereview.chromium.org/118226
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2112 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
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
called from within a loop or not. In the past we lost the
information if a call site went megamorphic before a lazily
compiled callee was called for the first time. Now we track
that correctly (this is an issue that affects richards).
We still don't manage to track the in-loop state through a
constructor call, since constructor calls use LoadICs instead
of CallICs. This issue affects delta-blue. So in this patch
we assume that lazy compilations that don't happen through a
CallIC happen from inside a loop. I have an idea to fix this
but this patch is big enough already.
With our improved tracking of in-loop state I have switched
off the inlining of in-object loads for code that is not in
a loop. This benefits compile speed. One issue is that
eagerly compiled code now doesn't get the in-object loads
inlined. We need to eagerly compile less code to fix this.
Review URL: http://codereview.chromium.org/115744
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2046 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
encoding the values in one word and by using an indirection table for
handles.
This reduces compilation time by roughly 10% and we should be able to make the slow case equality checking of frame elements faster as well.
Review URL: http://codereview.chromium.org/115347
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1949 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The function that prepares a virtual frame slot for writing (in order
to preserve the copy-on-write semantics of aliased frame elements) can
allocate registers, which may spill one from the frame. If we're
unlucky, the spilled register can be the source register for the frame
element write. In that case, ensure we do the write from memory.
Review URL: http://codereview.chromium.org/115125
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1904 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
stack pointer to change by more than one in a corner case. If we push
a constant smi larger than 16 bits, we push it via a temporary
register. Allocating the temporary can cause a register to be spilled
from the frame somewhere above the stack pointer.
As a fix, do not use pushes to materialize ranges of elements of size
larger than one.
Review URL: http://codereview.chromium.org/92121
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1785 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
