This change implements a simple data-flow analysis pass over captured
objects to the existing escape analysis. It tracks the state of values
in the Hydrogen graph through CapturedObject marker instructions that
are used to construct an appropriate translation for the deoptimizer to
be able to materialize these objects again.
This can be considered a combination of scalar replacement of loads and
stores on captured objects and sinking of unused allocations.
R=titzer@chromium.org
TEST=mjsunit/compiler/escape-analysis
Review URL: https://codereview.chromium.org/21055011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16098 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If an developer attempts to "subclass" Error by running
`MyError.prototype = new Error();`, then the internal v8::Message object
that's produced and handed off to `window.onerror` handlers is poorly
stringified as "[object Object]".
This patch adjusts the stringification process for these objects to
include not only native Error objects, but also objects that have Error
in their prototype chain, and haven't overwritten Error.toString with
some custom variant.
BUG=2822
R=mstarzinger@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/21761002
Patch from Mike West <mkwst@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
https://codereview.chromium.org/19541010/
The main problem is that if you called Object.getNotifier(obj) on an object, %SetObserved(object) would never get called on it, and thus it would be unobservable (new test added for this).
Additionally, Runtime::SetObserved was asserting obj->IsJSObject() which would fail if called on a proxy.
It just happens that our existing test always called getNotifier() before Object.observe on proxies, and thus we never previously attempted to transition the map of a proxy.
Both issues are now fixed and properly tested.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/21891008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t.
This way it seems more natural as we are going to support submilisecond sampling
rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test
failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22155003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t. This way it seems more natural as we are going to support submilisecond sampling rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22172002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16049 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'm going to change CPU profiler API and deprecate GetSelfTime, GetTotalTime and GetTotalSamplesCount on CpuProfileNode as all of those values are derived from self samples count and sampling rate. The sampling rate in turn is calculate based on the profiling duration so having start/end time and total sample count is enough for calculating smpling rate.
BUG=267595
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/21918002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'd like to propagate bailout reason to cpu profiler.
So I need to save it into heap object SharedFunctionInfo.
But:
1) all bailout reason strings spread across all the sources.
2) they are native strings and if I convert them into String then I may have a performance issue.
3) one byte is enough for 184 bailout reasons. Otherwise we need 8 bytes for the pointer.
Also I think it would be nice to have error strings collected in one place.
In that case we will get additional benefits:
It allows us to keep this set of messages under control.
It gives us a chance to internationalize them.
It slightly reduces the binary footprint.
From the other hand the developers have to add new strings into that enum.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/20843012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16024 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The first jump to a specific label was marked as jump to absolute
position -4. This value was stored in the assembly as a branch to a
offset (-4 - (instruction offset + 8)). The offset is only 24 bit
long on ARM. Thus instruction offsets higher than 2^23 - 12 would overflow
the offset.
Fix by denoting the first jump to a label by storing the jump
instruction location as the target. This will result in offset of -8,
which of course always fits in the branch instruction.
BUG=2736
TEST=cctest/test-assembler-arm/17
R=bmeurer@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17116006
Patch from Kimmo Kinnunen <kkinnunen@nvidia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In order to properly sanitize exception data during a 'window.onerror'
handler, we need to know whether a script was served with proper CORS
headers at the time it was loaded into V8. This patch adds a single bool
to ScriptOrigin, and pipes that through the compiler to land on the
Script object. We can then retrieve the parameter when calling the
embedder's exception callback.
BUG=crbug.com/159566
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/20646006
Patch from Mike West <mkwst@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15963 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Sampling rate is now calculated as total number of samples divided by profiling time in ms. Before the patch the sampling rate was updated once per 100ms which doesn't have any obvious advantage over the simpler method.
Also we are going to get rid of the profile node self and total time calculation in the v8 CPU profiler and only expose profiling start/end time for CpuProfile and number of ticks on each ProfileNode and let clients do all the math should they need it.
BUG=None
R=bmeurer@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/21105003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
