These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
The previous Windows issues have been resolved, and we now use GetTickCount64()
on Windows Vista and later, falling back to timeGetTime() with rollover
protection for earlier Windows versions.
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23490015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/23469013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23295034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use V8_FINAL and V8_OVERRIDE in Ast classes.
- Use V8_FINAL and V8_OVERRIDE in Lithium mips backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium arm backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium x64 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium ia32 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium classes.
- Use V8_FINAL and V8_OVERRIDE in Hydrogen classes.
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/22796020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16244 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use V8_FINAL and V8_OVERRIDE in objects.
- Use V8_FINAL and V8_OVERRIDE in Ast classes.
- Use V8_FINAL and V8_OVERRIDE in Lithium mips backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium arm backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium x64 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium ia32 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium classes.
- Use V8_FINAL and V8_OVERRIDE in Hydrogen classes.
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/23064017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16232 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
This adds an early check to the graph builder which prevents adding an
HWrapReceiver instruction if the receiver type is already known at graph
building time. Also HAllocate no longer unnecessarily postpones setting
it's type until type inference but sets it right away. These changes are
in preparation for escape analysis.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/19493005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15843 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is just a rename change with the exception of a bug found along the way in
CodeStubGraphBuilder<FastCloneShallowArrayStub>::BuildCodeStub(). There, the
intent is to get the boilerplate object from an AllocationSite. But the wrong
HObjectAccess was used. It only succeeds because it happened to be the same
offset :).
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/19595004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix the invalid array length check, replacing it with a check of
the elements pointer similar to TransitionElementsKindStub.
Refactor common code from ElementsTransitionAndStoreStub and TransitionElementsKindStub into BuildTransitionElementsKind() helper method.
Add test case for the MD5 computation that used to crash before,
and a small test case for the specific issue.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/19367003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This essentially relands r14930 and r14935 with adaptions to the current
code base. It models the instantiation of an implicit receiver for
CallNew nodes in hydrogen using HAllocate together with generic stores
instead of one specialized HAllocateObject instruction, hence creating a
single choking point for inlined allocation in optimized code.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/19207002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
