v8/tools/gcmole
Rodrigo Bruno eb164dbd00 Reland "[heap] Attempt to incorporate backing store counters into heap sizing and GC trigger stragery."
This is a reland of ba735dde20

Original change's description:
> [heap] Attempt to incorporate backing store counters into heap sizing and GC trigger stragery.
> 
> Bug: chromium:845409
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: Ic62a4339110e3dd2a6b1961a246e2bee0c07c03b
> Reviewed-on: https://chromium-review.googlesource.com/1160162
> Commit-Queue: Rodrigo Bruno <rfbpb@google.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55128}

Bug: chromium:845409
Change-Id: Iaff177f7bebbc073460fab0ae4e5cd9e632e1921
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1177301
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Rodrigo Bruno <rfbpb@google.com>
Cr-Commit-Position: refs/heads/master@{#55454}
2018-08-28 12:41:53 +00:00
..
bootstrap.sh Update gcmole to a more recent clang/llvm. 2014-08-07 12:56:53 +00:00
BUILD.gn Reland "[turboassembler] Introduce hard-abort mode" 2018-07-24 15:58:46 +00:00
gccause.lua Adjust contents of kAheadOfTime to match write-barrier stub called from CompileArrayPushCall. 2011-10-04 11:38:12 +00:00
gcmole-tools.tar.gz.sha1 [test] Upgrade gcmole plugin 2017-02-16 14:54:22 +00:00
gcmole.cc [gcmole] Fixes for unreachable code 2017-02-16 14:13:11 +00:00
gcmole.lua Reland "[heap] Attempt to incorporate backing store counters into heap sizing and GC trigger stragery." 2018-08-28 12:41:53 +00:00
Makefile Update gcmole to a more recent clang/llvm. 2014-08-07 12:56:53 +00:00
parallel.py Make gcmole execute in parallel. 2015-02-18 15:35:34 +00:00
README Make it clear that GCMole depends on Clang 2.9 currently. 2013-04-23 12:48:59 +00:00
run-gcmole.py [torque] refactor BUILD.gn to list torque sources in one place 2018-05-08 12:48:49 +00:00

DESCRIPTION -------------------------------------------------------------------

gcmole is a simple static analysis tool used to find possible evaluation order 
dependent GC-unsafe places in the V8 codebase.

For example the following code is GC-unsafe:

Handle<Object> Foo();  // Assume Foo can trigger a GC.
void Bar(Object*, Object*);

Handle<Object> baz;
baz->Qux(*Foo());  // (a)  
Bar(*Foo(), *baz);  // (b)

Both in cases (a) and (b) compiler is free to evaluate call arguments (that 
includes receiver) in any order. That means it can dereference baz before 
calling to Foo and save a raw pointer to a heap object in the register or 
on the stack.  

PREREQUISITES -----------------------------------------------------------------

1) Install Lua 5.1

2) Get LLVM 2.9 and Clang 2.9 sources and build them.

Follow the instructions on http://clang.llvm.org/get_started.html.

Make sure to pass --enable-optimized to configure to get Release build 
instead of a Debug one.

3) Build gcmole Clang plugin (libgcmole.so)

In the tools/gcmole execute the following command:

LLVM_SRC_ROOT=<path-to-llvm-source-root> make

USING GCMOLE ------------------------------------------------------------------

gcmole consists of driver script written in Lua and Clang plugin that does
C++ AST processing. Plugin (libgcmole.so) is expected to be in the same
folder as driver (gcmole.lua).

To start analysis cd into the root of v8 checkout and execute the following
command:

CLANG_BIN=<path-to-clang-bin-folder> lua tools/gcmole/gcmole.lua [<arch>]

where arch should be one of architectures supported by V8 (arm, ia32, x64).

Analysis will be performed in 2 stages: 

- on the first stage driver will parse all files and build a global callgraph 
approximation to find all functions that might potentially cause GC, list
of this functions will be written into gcsuspects file.

- on the second stage driver will parse all files again and will locate all 
callsites that might be GC-unsafe based on the list of functions causing GC. 
Such places are marked with a "Possible problem with evaluation order." 
warning. Messages "Failed to resolve v8::internal::Object" are benign and 
can be ignored.

If any errors were found driver exits with non-zero status.