R=bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/665893006

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24771 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/456663002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22988 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This way we don't clash with the ASSERT* macros
defined by GoogleTest, and we are one step closer
to being able to replace our homegrown base/ with
base/ from Chrome.

R=jochen@chromium.org, svenpanne@chromium.org

Review URL: https://codereview.chromium.org/430503007

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

- this avoids using relative include paths which are forbidden by the style guide
- makes the code more readable since it's clear which header is meant
- allows for starting to use checkdeps

BUG=none
R=jkummerow@chromium.org, danno@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/304153016

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/259183002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit r20938 for breaking the windows build.

TBR=ulan@chromium.org

Review URL: https://codereview.chromium.org/254463003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20939 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/257453003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20938 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org, kcc@google.com

Review URL: https://codereview.chromium.org/208743004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=328202
R=jkummerow@chromium.org
LOG=N

Review URL: https://codereview.chromium.org/108783005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18564 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

1. Use inline macro to mitigate the side effect emulation overhead
2. Refactor Zone::DeleteAll() to merge two loops together

R=bmeurer@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/18057004

Patch from Weiliang Lin <weiliang.lin2@gmail.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15522 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

In case tcmalloc is not being used, the malloc()/free() overhead
can be significant for several runtime functions like StringReplace.
Therefore we reintroduce the runtime_zone into Isolate and reenable
the segment caching functionality of Zone.

There's now also a simpler version of ZoneScope w/o nesting capabilities.

BUG=v8:2759
R=danno@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/18635003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15465 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The zone_excess_limit_ is not changed at runtime, and there seems to
be no obvious reason to do so in the future.

R=danno@chromium.org
BUG=

Review URL: https://codereview.chromium.org/18034006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15354 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

There's no need to differentiate between an actual Zone and its
scope. Instead we bind the lifetime of the Zone memory to the
lifetime of the Zone itself, which is way easier to understand
than having to dig through the code looking for zone scopes.

Depends on https://codereview.chromium.org/17826004/

R=danno@chromium.org
BUG=

Review URL: https://codereview.chromium.org/17827005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/16858018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15197 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The CompilationInfo record now saves a Zone, and the compiler pipeline
allocates memory from the Zone in the CompilationInfo.  Before
compiling a function, we create a Zone on the stack and save a pointer
to that Zone to the CompilationInfo; which then gets picked up and
allocated from.

BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/10534139

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9297058

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10545 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9297052

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10543 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/7859030

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9211 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TEST=chromium valgrind bots

Review URL: http://codereview.chromium.org/7660016

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8949 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/6685088

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/6190002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6249 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Thus, now there is a "generic" SplayTree and its Zone-bound
specialization ZoneSplayTree.

This is needed for my reimplementation of profiler tree generation in
C++. As generation is performed in a separate thread, Zone can't be
used, because it intentionally not thread-safe.

Review URL: http://codereview.chromium.org/660280

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3990 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

positives, but I've restructured the code to be more explicit.

Review URL: http://codereview.chromium.org/159192

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2521 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

TBR=kasperl

Review URL: http://codereview.chromium.org/13210

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@928 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

- Do not keep growing the zone segment size exponentially. By putting
  an upper limit on the segment size we limit the requirements for
  contiguous memory allocation.

Review URL: http://codereview.chromium.org/12984

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@926 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

scope, leading to zone exhaustion.  Added assertion that a zone scope
exists on zone allocation.


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@898 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

stack limit and that the zone allocation limit hasn't been met.


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Added presubmit step to check copyright.



git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@242 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

unsafe calls to Zone::DeleteAll() from parser and use ZoneScopes
instead.


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@54 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

git-svn-id: http://v8.googlecode.com/svn/trunk@2 ce2b1a6d-e550-0410-aec6-3dcde31c8c00