Skip to content

V
V8
Switch branch/tag
  1. 05 Dec, 2018 1 commit
  3. 30 Nov, 2018 1 commit
  5. 16 Nov, 2018 1 commit
  7. 12 Nov, 2018 1 commit
  9. 09 Nov, 2018 1 commit
  11. 31 Oct, 2018 1 commit
  13. 29 Oct, 2018 1 commit
  15. 17 Oct, 2018 1 commit
  17. 16 Oct, 2018 1 commit
    • Dan Elphick's avatar
      [snapshot] Create a ReadOnly snapshot · f602712f
      Dan Elphick authored 
      In preparation for sharing RO_SPACE between all Isolates within a
process, this first pulls RO_SPACE out of the Startup snapshot and puts
it in its own ReadOnly snapshot.

The snapshot is first populated with the read-only roots. After that the
StartupSerializer serializes as before but starting from the first
mutable root. References to objects in the ReadOnly snapshot that aren't
themselves roots are added to a new cache called ReadOnlyObjectCache
which functions like the PartialSnapshotCache but lives in the
ReadOnlySerializer rather than the StartupSerializer. These cache
entries are referenced using a new bytecode: ReadOnlyObjectCache. (To
make room for this, the ApiReference bytecode has been moved).

To reduce code duplication, the StartupSerializer has been refactored to
create a new base class RootSerializer, which ReadOnlySerializer also
subclasses. The base class is responsible primarily for keeping track of
already serialized roots and visiting the roots.

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iff26042886130ae22eccf2e11b35f6f226f4a792
Bug: v8:8191
Reviewed-on: https://chromium-review.googlesource.com/c/1244676
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56681}
      f602712f
  19. 15 Oct, 2018 1 commit
    • Predrag Rudic's avatar
      MIPS: Port [turbofan] Use relative calls/jumps on arm for builtins · a1974d49
      Predrag Rudic authored 
      Port commit 23dbb81d.

Original CL message:

>This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
>builtins to embedded builtins. To make this work, the code range size is
>limited to 32MB on arm during mksnapshot, which ensures that all builtin
>to builtin offsets for jumps/calls fit into the B/BL immediate. At code
>generation time, we put a placeholder into the instruction offset which
>we resolve to the right code object when the code is copied to the heap.
>We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
>The relocation mode RELATIVE_CODE_TARGET should never appear after
>generating the snapshot.
>
>We modify the target_address/set_target_address methods of RelocInfo
>such that they return the absolute target addresses for pc-relative B/BL
>instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
>the same way as code targets. This, however, only matters during
>snapshot creation time, and production code never contains
>RELATIVE_CODE_TARGET relocations.
>
>Bug: v8:6666
>Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
>Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
>Reviewed-on: https://chromium-review.googlesource.com/1117181
>Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
>Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
>Reviewed-by: Jakob Gruber <jgruber@chromium.org>
>Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
>Cr-Commit-Position: refs/heads/master@{#54320}

This CL is completed Miran's draft without MIPS64 port.
(https://chromium-review.googlesource.com/c/v8/v8/+/1136640/3).

Change-Id: I979378ac445548641755968d890f7f4a82dc7986
Reviewed-on: https://chromium-review.googlesource.com/c/1221313
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIvica Bogosavljevic <ibogosavljevic@wavecomp.com>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56640}
      a1974d49
  21. 25 Sep, 2018 3 commits
    • Yang Guo's avatar
      Reland "[snapshot] add checksum to startup snapshot" · 8ff37bc7
      Yang Guo authored 
      This is a reland of bcb8d49b

TBR=petermarshall@chromium.org

Original change's description:
> [snapshot] add checksum to startup snapshot
>
> We already had checksumming for code cache data. We now extend
> checksumming to the startup snapshot to catch data corruption early.
>
> The performance impact for deserialization is a regression of 1-2%,
> which should be acceptable.
>
> Sample output for the included test with --profile-deserialization:
>
> [Verifying snapshot checksum took 0.023 ms]
> [Deserializing isolate (134348 bytes) took 1.891 ms]
> [Verifying snapshot checksum took 0.024 ms]
> [Deserializing isolate (134348 bytes) took 1.654 ms]
> [Deserializing context #0 (47208 bytes) took 0.331 ms]
> Deserialization will reserve:
>     208168 bytes per isolate
>     123368 bytes per context #0
> Snapshot blob consists of:
>     134492 bytes in 6 chunks for startup
>     115272 bytes for builtins
>      47152 bytes in 31 chunks for context #0
> [Verifying snapshot checksum took 0.048 ms]
> [Verifying snapshot checksum took 0.043 ms]
>
> R=peria@chromium.org, petermarshall@chromium.org
>
> Bug: chromium:881417
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7
> Reviewed-on: https://chromium-review.googlesource.com/1241874
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56217}

Bug: chromium:881417
Change-Id: I037f378fc2d45c3e0fa670bf538df68cbba5c53c
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1243191Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56224}
      8ff37bc7
    • Clemens Hammacher's avatar
      Revert "[snapshot] add checksum to startup snapshot" · 0a04f263
      Clemens Hammacher authored 
      This reverts commit bcb8d49b.

Reason for revert: MSan compile error: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/23025

Original change's description:
> [snapshot] add checksum to startup snapshot
> 
> We already had checksumming for code cache data. We now extend
> checksumming to the startup snapshot to catch data corruption early.
> 
> The performance impact for deserialization is a regression of 1-2%,
> which should be acceptable.
> 
> Sample output for the included test with --profile-deserialization:
> 
> [Verifying snapshot checksum took 0.023 ms]
> [Deserializing isolate (134348 bytes) took 1.891 ms]
> [Verifying snapshot checksum took 0.024 ms]
> [Deserializing isolate (134348 bytes) took 1.654 ms]
> [Deserializing context #0 (47208 bytes) took 0.331 ms]
> Deserialization will reserve:
>     208168 bytes per isolate
>     123368 bytes per context #0
> Snapshot blob consists of:
>     134492 bytes in 6 chunks for startup
>     115272 bytes for builtins
>      47152 bytes in 31 chunks for context #0
> [Verifying snapshot checksum took 0.048 ms]
> [Verifying snapshot checksum took 0.043 ms]
> 
> R=​peria@chromium.org, petermarshall@chromium.org
> 
> Bug: chromium:881417
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7
> Reviewed-on: https://chromium-review.googlesource.com/1241874
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56217}

TBR=peria@chromium.org,yangguo@chromium.org,petermarshall@chromium.org

Change-Id: Iccb82092858ab68a5d6ae9552fa716108eda354b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:881417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1243190Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56221}
      0a04f263
    • Yang Guo's avatar
      [snapshot] add checksum to startup snapshot · bcb8d49b
      Yang Guo authored 
      We already had checksumming for code cache data. We now extend
checksumming to the startup snapshot to catch data corruption early.

The performance impact for deserialization is a regression of 1-2%,
which should be acceptable.

Sample output for the included test with --profile-deserialization:

[Verifying snapshot checksum took 0.023 ms]
[Deserializing isolate (134348 bytes) took 1.891 ms]
[Verifying snapshot checksum took 0.024 ms]
[Deserializing isolate (134348 bytes) took 1.654 ms]
[Deserializing context #0 (47208 bytes) took 0.331 ms]
Deserialization will reserve:
    208168 bytes per isolate
    123368 bytes per context #0
Snapshot blob consists of:
    134492 bytes in 6 chunks for startup
    115272 bytes for builtins
     47152 bytes in 31 chunks for context #0
[Verifying snapshot checksum took 0.048 ms]
[Verifying snapshot checksum took 0.043 ms]

R=peria@chromium.org, petermarshall@chromium.org

Bug: chromium:881417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7
Reviewed-on: https://chromium-review.googlesource.com/1241874Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56217}
      bcb8d49b
  23. 20 Sep, 2018 1 commit
    • Dan Elphick's avatar
      [interpreter] Always put bytecode handlers in builtins table · daa296b5
      Dan Elphick authored 
      This always creates the bytecode handlers as part of the builtins table
regardless of the V8_EMBEDDED_BYTECODE_HANDLERS definition.

Lazy deserialization of bytecode handlers is enabled for this flow by
moving the three lazy bytecode deserializers from the strong roots into
the builtins table (ensuring that they not marked lazy themselves).

To simplify lazy deserialization, the illegal bytecode handler is made
non-lazy so that GetAndMaybeDeserializeBytecodeHandler doesn't to know
about it.

Since the bytecode handlers are now always part of the builtins table,
many bytecode specific methods are removed, including logging and in
BuiltinsSerializer and BuiltinsDeserializer.

Removes setup-interpreter.h, setup-interpreter-internal.cc and
builtin-snapshot-utils.*.

Change-Id: Ie421aa897a04f7b3bcb964c476eb7ab149388d53
Reviewed-on: https://chromium-review.googlesource.com/1220046Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56063}
      daa296b5
  25. 03 Sep, 2018 1 commit
  27. 22 Aug, 2018 1 commit
  29. 21 Aug, 2018 2 commits
    • jgruber's avatar
      [builtins] Mark initial builtins on ia32 isolate-independent · 6ab19087
      jgruber authored 
      This populates the isolate-independent builtin whitelist with initial
builtins that do not access any isolate-dependent data and thus don't
need the root register at all.

Unlike most other platforms, we can't use a scratch register in the
off-heap trampoline since there's no free register available. The
trampolines on ia32 are thus implemented as pc-relative jumps
(thankfully we can address the entire address space).

Drive-by: Made Code::IsIsolateIndependent consistent with
FinalizeEmbeddedCodeTargets. Code targets are only allowed on some
platforms.

Bug: v8:6666
Change-Id: I0bf02eecba8a099afa7b7c892188cd377cbda840
Reviewed-on: https://chromium-review.googlesource.com/1183224Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55265}
      6ab19087
    • Dan Elphick's avatar
      Reland "[builtins] Start adding byte code handlers to builtins" · fe5e07d7
      Dan Elphick authored 
      This is a reland of 041ae1f8

The clashing method has been fixed.

Original change's description:
> [builtins] Start adding byte code handlers to builtins
>
> Adds a new build flag, v8_enable_embedded_bytecode_handlers, that adds
> the bytecode handlers to the BUILTIN_LIST macros.
>
> Currently it's not connected up to the code-generation so it actually
> does nothing except expand the builtins table.
>
> Bug: v8:8068
> Change-Id: Iaecc3982cf22d04e6c46169b86c9d694952fd091
> Reviewed-on: https://chromium-review.googlesource.com/1179887
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55215}

Bug: v8:8068
Change-Id: Ibc98929a9ad464e9d4c9fc7d43401f0fb0df9a00
Reviewed-on: https://chromium-review.googlesource.com/1181981Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55244}
      fe5e07d7
  31. 20 Aug, 2018 2 commits
    • Dan Elphick's avatar
      Revert "[builtins] Start adding byte code handlers to builtins" · 737ffec5
      Dan Elphick authored 
      This reverts commit 041ae1f8.

Reason for revert: Causes jumbo builds to fail because of duplicate GenerateBytecodeHandler definitions.

Original change's description:
> [builtins] Start adding byte code handlers to builtins
> 
> Adds a new build flag, v8_enable_embedded_bytecode_handlers, that adds
> the bytecode handlers to the BUILTIN_LIST macros.
> 
> Currently it's not connected up to the code-generation so it actually
> does nothing except expand the builtins table.
> 
> Bug: v8:8068
> Change-Id: Iaecc3982cf22d04e6c46169b86c9d694952fd091
> Reviewed-on: https://chromium-review.googlesource.com/1179887
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55215}

TBR=rmcilroy@chromium.org,jgruber@chromium.org,delphick@chromium.org

Change-Id: I860b3ecf543944fd0f4fdcb8de09d21a4b784150
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8068
Reviewed-on: https://chromium-review.googlesource.com/1181301Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55225}
      737ffec5
    • Dan Elphick's avatar
      [builtins] Start adding byte code handlers to builtins · 041ae1f8
      Dan Elphick authored 
      Adds a new build flag, v8_enable_embedded_bytecode_handlers, that adds
the bytecode handlers to the BUILTIN_LIST macros.

Currently it's not connected up to the code-generation so it actually
does nothing except expand the builtins table.

Bug: v8:8068
Change-Id: Iaecc3982cf22d04e6c46169b86c9d694952fd091
Reviewed-on: https://chromium-review.googlesource.com/1179887
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55215}
      041ae1f8
  33. 17 Aug, 2018 1 commit
  35. 08 Aug, 2018 1 commit
  37. 26 Jul, 2018 1 commit
  39. 20 Jul, 2018 1 commit
  41. 09 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Use relative calls/jumps on arm for builtins · 23dbb81d
      Sigurd Schneider authored 
      This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
builtins to embedded builtins. To make this work, the code range size is
limited to 32MB on arm during mksnapshot, which ensures that all builtin
to builtin offsets for jumps/calls fit into the B/BL immediate. At code
generation time, we put a placeholder into the instruction offset which
we resolve to the right code object when the code is copied to the heap.
We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
The relocation mode RELATIVE_CODE_TARGET should never appear after
generating the snapshot.

We modify the target_address/set_target_address methods of RelocInfo
such that they return the absolute target addresses for pc-relative B/BL
instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
the same way as code targets. This, however, only matters during
snapshot creation time, and production code never contains
RELATIVE_CODE_TARGET relocations.

Bug: v8:6666
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
Reviewed-on: https://chromium-review.googlesource.com/1117181Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54320}
      23dbb81d
  43. 05 Jul, 2018 2 commits
  45. 04 Jul, 2018 1 commit
  47. 03 Jul, 2018 1 commit
  49. 22 Jun, 2018 1 commit
  51. 28 May, 2018 1 commit
  53. 25 May, 2018 1 commit
    • jgruber's avatar
      [builtins,x64] pc-relative builtin-to-builtin calls · e5630ea9
      jgruber authored 
      This addresses one of the major remaining slowdowns with embedded
builtins on x64.

When generating code for a call to a builtin callee from a builtin
caller, we'd look up the Code target object from the builtins constant
list, calculate the location of the first instruction, and jump to it.
Note that for embedded builtin callees, the Code object is itself only
a trampoline to the off-heap code and thus an additional indirection.
An example of the call sequence in pseudo-asm:

// Load from the constants list.
mov reg, [kRootPointer, kBuiltinsConstantListOffset]
mov reg, [reg, offset_of_the_code_constant]
// Calculate first instruction and call it.
add reg, Code::kHeaderOffset
call reg
// The trampoline forwards to the off-heap area.
mov kOffHeapTrampolineRegister, <off-heap instruction_start>
jmp kOffHeapTrampolineRegister

This CL changes calls to embedded builtin targets to use pc-relative
addressing. This reduces the above instruction sequence to:

call <pc-relative offset to target instruction_start>

Embedded-to-embedded calls jump directly to the embedded instruction
stream, bypassing the trampoline. Heap-to-embedded calls (and all
calls to heap-builtins) use pc-relative addressing targeting the
on-heap Code object.

Other relevant platforms (arm,arm64,mips,mips64) do not use pc-relative
calls. For these, we'll need a different solution, e.g. a table of
embedded builtin addresses reachable from the root pointer, similar to
the external reference table.

Bug: v8:6666
Change-Id: Ic0317d454e2da37d74eaecebcdfcbc0d5f5041ad
Reviewed-on: https://chromium-review.googlesource.com/1068732
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53349}
      e5630ea9
  55. 03 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Update isolate-independent list & related fixups · 519bd47f
      jgruber authored 
      With the exception of the InterpreterEntryTrampoline, all builtins are
now isolate-independent and can be embedded into the binary.

This CL updates the corresponding list and also contains a few smallish
tweaks to support having these builtins off the heap:

* wasm: copy the off-heap builtin, not its trampoline.
* Code::contains: support off-heap builtins.
* JSFunction::is_compiled: compare builtin index instead of identity
  (this is relevant during mksnapshot when we transition from the
  on-heap builtin to its off-heap representation + the trampoline).
* Remove old DCHECKs.
* A few tweaks in macro-assembler ports that have snuck in recently.

Bug: v8:6666
Change-Id: Iabf5b47ade3826a4da35b6b75a4e61614f0158b0
Reviewed-on: https://chromium-review.googlesource.com/1032777
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52935}
      519bd47f
  57. 26 Apr, 2018 3 commits
  59. 20 Apr, 2018 1 commit
  61. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  63. 09 Apr, 2018 1 commit
    • jgruber's avatar
      [builtins] Remove unused predicate IsOffHeapSafe · 05ec0c40
      jgruber authored 
      Builtins::IsOffHeapSafe is unused now that embedded builtins are
shipped in the snapshot.

A longer explanation: there used to be a difference between
IsOffHeapSafe and IsIsolateIndependent back at an earlier stage when
we still copied off-heap-safe builtins off the heap on isolate startup.
At that point, off-heap builtins didn't need to be isolate-independent,
e.g. they could still contain embedded external references.
Now that embedded builtins are shipped in the snapshot, this
distinction is no longer needed.

Bug: v8:6666
Change-Id: I0be6120b94b01480262f472f0904ea9037941e2a
Reviewed-on: https://chromium-review.googlesource.com/1002652Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52473}
      05ec0c40
  65. 05 Apr, 2018 1 commit
    • jgruber's avatar
      Rename Code::instruction_{start,end,size} functions · 7b29fe43
      jgruber authored 
      In order to clarify the difference between, e.g., InstructionStart and
instruction_start, rename as follows:

Code::instruction_start -> raw_instruction_start
Code::instruction_end   -> raw_instruction_end
Code::instruction_size  -> raw_instruction_size

The difference between the camel-case and raw_* function families is
in how they handle off-heap-trampoline Code objects. For example, when
called on an off-heap-trampoline: raw_instruction_start returns the
trampoline's entry point, while InstructionStart returns the off-heap
code's entry point (located in the .text section of the binary).

Some callsites were updated to call the camel-case function family as
appropriate.

Bug: v8:6666
Change-Id: I4a572f47c2d161a853599d7c17879e263b0d1a87
Reviewed-on: https://chromium-review.googlesource.com/997532
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52387}
      7b29fe43