Bug: v8:7754,v8:7490,v8:7965
Change-Id: I574dbade6dc21204461be4d83b138f7341016305
Reviewed-on: https://chromium-review.googlesource.com/1152819Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54779}

This moves the static handle() helper function to handles-inl.h as
it ultimately depends on handles-inl.h anyway. To make this
possible, also move some other code to -inl.h files and split up
some header files into a -inl.h part.

Bug: v8:7490
Change-Id: I0f68e0728ba082b87ffa911aaf205d9b1523d2c9
Reviewed-on: https://chromium-review.googlesource.com/1146723Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54617}

Strictly speaking there are some left in api.cc, but they are in
deprecated functions with non-deprecated alternatives.

Apart from changes made using tooling, this also modifies
FieldType::AsClass to return Map* rather than Handle<Map> and converts
its call sites to create the Handle when they need it - currently
several sites immediately dereference the Handle.

Also marks WasmDebugInfo as NeverReadOnlySpaceObject so GetIsolate and
GetHeap remain usable.

Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I7ea5048f97f140c757f651712b8c33a5c7e0ebc1
Reviewed-on: https://chromium-review.googlesource.com/1140302Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54513}

Remove the one-argument Handle constructor and "handle" factory method,
replacing them with Isolates where available and GetIsolate() methods
otherwise.

TBR=verwaest@chromium.org

Bug: v8:7786
Change-Id: I8ee92ef727c05382c984a3e4c290198d0b312619
Reviewed-on: https://chromium-review.googlesource.com/1113542Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54025}

This gets rid of the weakness hacks which were needed for remembering that maps
as handlers are weak, and other handles are strong.

BUG=v8:7308

Change-Id: I7fd3252ba67350803e2207dc12bbdf6abbae7e23
Reviewed-on: https://chromium-review.googlesource.com/1055449Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53151}

After closing a handle scope, and when allocating a new segment in a
zone, treat that memory as uninitialized in MSan. This will hopefully
catch more errors than handle zapping, which needs to be enabled
explicitly.

R=ahaas@chromium.org

Bug: v8:7570
Change-Id: Ie3be07434bed878fb607a522787514421f397197
Reviewed-on: https://chromium-review.googlesource.com/1046657
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53089}

This CL fixes all occurences that don't require special OWNER reviews,
or can be reviewed by Michi.

After this one, we should be able to reenable the readability/check
cpplint check.

R=mstarzinger@chromium.org

Bug: v8:6837, v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62
Reviewed-on: https://chromium-review.googlesource.com/721120
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48670}

Bug: chromium:763010
Change-Id: Iafed5a0e8087f415cd2c11a0b1326c04bd01ef80
Reviewed-on: https://chromium-review.googlesource.com/665351Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48018}

R=clemensh@chromium.org

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I3df5d50f81909188ee0cb31d0f479aadeeabe20f
Reviewed-on: https://chromium-review.googlesource.com/662780Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47991}

R=clemensh@chromium.org

Change-Id: If0554f01068fb76228e85cfe120630eda86de41d
Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47945}

The biggest problem is isolate.h (this CL doesn't solve that yet).

BUG=v8:5294

Change-Id: I56b32109f501c48facd99cd12ca6c8f427e188a9
Reviewed-on: https://chromium-review.googlesource.com/471487Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44613}

The x64 side is included in https://chromium-review.googlesource.com/c/444226/

BUG=v8:5294

Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}

TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.

Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.

Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.

This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}

R=bmeurer@chromium.org

Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755
Cr-Commit-Position: refs/heads/master@{#31566}

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

Cr-Commit-Position: refs/heads/master@{#31576}

Revert of Canonicalize handles for optimized compilation. (patchset #1 id:1 of https://codereview.chromium.org/1423833003/ )

Reason for revert:
GC stress failure on ia32 optdebug:

/tmp/runfswAKT/out/Debug/d8 --test --random-seed=-1536184370 --turbo --always-opt --nohard-abort --nodead-code-elimination --nofold-constants --enable-slow-asserts --debug-code --verify-heap --stack-size=46 /tmp/runfswAKT/test/mjsunit/mjsunit.js /tmp/runfswAKT/test/mjsunit/regress/regress-1132.js --gc-interval=500 --stress-compaction --concurrent-recompilation-queue-length=64 --concurrent-recompilation-delay=500 --concurrent-recompilation

Run #1
Exit code: -6
Result: FAIL
Expected outcomes: PASS
Duration: 00:06:279

Stderr:

#
# Fatal error in ../../src/hashmap.h, line 248
# Check failed: base::bits::IsPowerOfTwo32(capacity_).
#

==== C stack trace ===============================

Original issue's description:
> Canonicalize handles for optimized compilation.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755
> Cr-Commit-Position: refs/heads/master@{#31566}

TBR=jochen@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#31570}

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31566}

The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.

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

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

Cr-Commit-Position: refs/heads/master@{#30458}

Bunch of cleanups to allow us to get rid of handles-inl.h at some
point (in the not so far future); but more importantly to sanitize uses
of handles and prepare for handle canonicalization support.

R=yangguo@chromium.org

Committed: https://crrev.com/3283195d0408333cce552cf4087577e6f41054e5
Cr-Commit-Position: refs/heads/master@{#28222}

Committed: https://crrev.com/d940c6d3bcc227b459cb4123d9a8332d9ed0d5f8
Cr-Commit-Position: refs/heads/master@{#29666}

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

Cr-Commit-Position: refs/heads/master@{#29675}

Revert of [handles] Sanitize Handle and friends. (patchset #5 id:180001 of https://codereview.chromium.org/1128533002/)

Reason for revert:
[Sheriff] Still breaks mac asan:
http://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/2066

Original issue's description:
> [handles] Sanitize Handle and friends.
>
> Bunch of cleanups to allow us to get rid of handles-inl.h at some
> point (in the not so far future); but more importantly to sanitize uses
> of handles and prepare for handle canonicalization support.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3283195d0408333cce552cf4087577e6f41054e5
> Cr-Commit-Position: refs/heads/master@{#28222}
>
> Committed: https://crrev.com/d940c6d3bcc227b459cb4123d9a8332d9ed0d5f8
> Cr-Commit-Position: refs/heads/master@{#29666}

TBR=yangguo@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#29669}

Bunch of cleanups to allow us to get rid of handles-inl.h at some
point (in the not so far future); but more importantly to sanitize uses
of handles and prepare for handle canonicalization support.

R=yangguo@chromium.org

Committed: https://crrev.com/3283195d0408333cce552cf4087577e6f41054e5
Cr-Commit-Position: refs/heads/master@{#28222}

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

Cr-Commit-Position: refs/heads/master@{#29666}

v8 builds with --no-snap were hitting handle limits compiling natives for handle count unit tests that run with --check_handle_count. Patch now has higher handle limits (~4k more than required for failing natives compilation).

Original issue: https://codereview.chromium.org/1185633002/

Original issue's description:
    > Additional HandleScopes to limit Handle consumption.
    >
    > erikcorry@chromium.org suggested digging into v8 handle usage. Found potential scopes in ast.cc and runtime-literals.cc and added tests.
    >
    > The runtime-literals.cc change reduces peak handles in imaging-darkroom.js from 1,282,610 to 428,218. The ast.cc change reduces the peak handles in string-t
agcloud.js from 80,738 to 8,176.
    >
    > No significant handle count issues found with major websites, but substantial savings on some benchmarks and demos:
    >
    > Kraken's imaging-darkroom.js down from 1,282,610 to 428,218 due to runtime-literals.cc scope.
    > SunSpider's string-tagcloud.js down from 80,738 to 8.176 due to ast.cc
    >
    > http://www.flohofwoe.net/demos/dragons_asmjs.html (738,906 -> 478,296)
    > http://www.flohofwoe.net/demos/instancing_asmjs.html (737,884 -> 477,274)
    > https://dl.dropboxusercontent.com/u/16662598/Ports/DOSBox-web/doom.html?engine=dosbox-growth.js (1,724,114 -> 1,087,408)
    > https://kripken.github.io/ammo.js/examples/new/ammo.html (175,784 -> 142,058)
    >
    > BUG=
    >
    > Committed: https://crrev.com/3a4c7538839186aa38910c66c986abb563f4ccd2
    > Cr-Commit-Position: refs/heads/master@{#29155}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#29322}

Revert of Additional HandleScopes to limit Handle consumption. (patchset #4 id:50001 of https://codereview.chromium.org/1185633002/)

Reason for revert:
Fails the following test

handle-count-ast
handle-count-runtime-...

on V8 Linux - nosnap - debug - 1

http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/851/steps/Check/logs/stdio

Original issue's description:
> Additional HandleScopes to limit Handle consumption.
>
> erikcorry@chromium.org suggested digging into v8 handle usage. Found potential scopes in ast.cc and runtime-literals.cc and added tests.
>
> The runtime-literals.cc change reduces peak handles in imaging-darkroom.js from 1,282,610 to 428,218. The ast.cc change reduces the peak handles in string-tagcloud.js from 80,738 to 8,176.
>
> No significant handle count issues found with major websites, but substantial savings on some benchmarks and demos:
>
> Kraken's imaging-darkroom.js down from 1,282,610 to 428,218 due to runtime-literals.cc scope.
> SunSpider's string-tagcloud.js down from 80,738 to 8.176 due to ast.cc
>
> http://www.flohofwoe.net/demos/dragons_asmjs.html (738,906 -> 478,296)
> http://www.flohofwoe.net/demos/instancing_asmjs.html (737,884 -> 477,274)
> https://dl.dropboxusercontent.com/u/16662598/Ports/DOSBox-web/doom.html?engine=dosbox-growth.js (1,724,114 -> 1,087,408)
> https://kripken.github.io/ammo.js/examples/new/ammo.html (175,784 -> 142,058)
>
> BUG=
>
> Committed: https://crrev.com/3a4c7538839186aa38910c66c986abb563f4ccd2
> Cr-Commit-Position: refs/heads/master@{#29155}

TBR=yangguo@chromium.org,erikcorry@chromium.org,oth@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#29160}

erikcorry@chromium.org suggested digging into v8 handle usage. Found potential scopes in ast.cc and runtime-literals.cc and added tests.

The runtime-literals.cc change reduces peak handles in imaging-darkroom.js from 1,282,610 to 428,218. The ast.cc change reduces the peak handles in string-tagcloud.js from 80,738 to 8,176.

No significant handle count issues found with major websites, but substantial savings on some benchmarks and demos:

Kraken's imaging-darkroom.js down from 1,282,610 to 428,218 due to runtime-literals.cc scope.
SunSpider's string-tagcloud.js down from 80,738 to 8.176 due to ast.cc

http://www.flohofwoe.net/demos/dragons_asmjs.html (738,906 -> 478,296)
http://www.flohofwoe.net/demos/instancing_asmjs.html (737,884 -> 477,274)
https://dl.dropboxusercontent.com/u/16662598/Ports/DOSBox-web/doom.html?engine=dosbox-growth.js (1,724,114 -> 1,087,408)
https://kripken.github.io/ammo.js/examples/new/ammo.html (175,784 -> 142,058)

BUG=

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

Cr-Commit-Position: refs/heads/master@{#29155}

Revert of [handles] Sanitize Handle and friends. (patchset #4 id:50001 of https://codereview.chromium.org/1128533002/)

Reason for revert:
[Sheriff] Breaks mac asan:
http://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/1198

Original issue's description:
> [handles] Sanitize Handle and friends.
>
> This almost allows us to get rid of handles-inl.h, once we fix the
> cyclic dependencies (follow up CL).
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3283195d0408333cce552cf4087577e6f41054e5
> Cr-Commit-Position: refs/heads/master@{#28222}

TBR=yangguo@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#28235}

This almost allows us to get rid of handles-inl.h, once we fix the
cyclic dependencies (follow up CL).

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28222}

R=svenpanne@chromium.org

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

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

BUG=none
R=hpayer@chromium.org
LOG=n

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22850 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=hpayer@chromium.org

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

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

R=hpayer@chromium.org

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

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

R=mstarzinger@chromium.org

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

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

ExtensionConfiguration is just a simple container for extension names
(in a perfect world we would use vector<string> and range-based for
loops), and HandleScopeData was in the totally wrong place. Some
additional cleanup on the way, e.g. using the null pattern behind our
external API.

R=dcarney@chromium.org

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

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

That will make it easier to turn on handle zapping alone and experiment
with it.

R=jkummerow@chromium.org

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

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

This should avoid zapping the same unused handles over and over again
when using many small nested handle scopes.

BUG=none
R=mstarzinger@chromium.org, vegorov@chromium.org

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

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

R=mstarzinger@chromium.org
BUG=

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

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

Revert "Introduce a handle zapping setting, and enable it by default for release and debug" due to performance impact.

R=jochen@chromium.org

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

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

The checks are split out from "extra checks" which are too expensive to
turn on by default.

R=danno@chromium.org

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

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

R=jkummerow@chromium.org
BUG=

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

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