Skip to content

V
V8
Switch branch/tag
  1. 13 Oct, 2020 2 commits
  3. 05 Oct, 2020 1 commit
  5. 01 Oct, 2020 1 commit
  7. 30 Sep, 2020 2 commits
    • Jakob Gruber's avatar
      Rename legacy code kinds · 29bcdaad
      Jakob Gruber authored 
      CodeKind::OPTIMIZED_CODE -> TURBOFAN

Kinds are now more fine-grained and distinguish between TF, TP, NCI.

CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING

Code stubs (like builtins, but generated at runtime) were removed from
the codebase years ago, this is the last remnant. This kind is used
only for deopt entries (which should be converted into builtins) and
for tests.

Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70234}
      29bcdaad
    • Jakob Gruber's avatar
      [turboprop] Add TURBOPROP code kind · 75b8c238
      Jakob Gruber authored 
      Turboprop-generated Code objects will now have the dedicated
TURBOPROP code kind instead of OPTIMIZED_FUNCTION. When possible,
the code kind is used as the source of truth instead of
FLAG_turboprop. This is the initial step towards implementing
tier-up from Turboprop to Turbofan.

Future work: Rename OPTIMIZED_FUNCTION to TURBOFAN, rename STUB to
DEOPT_ENTRIES_OR_FOR_TESTING, implement TP tier-up.

No-Try: true
Bug: v8:9684
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Change-Id: I3c9308718d7e9a2b7e6796e7ea94f17e5ff84c0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424140
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70213}
      75b8c238
  9. 28 Sep, 2020 1 commit
  11. 24 Sep, 2020 1 commit
  13. 22 Sep, 2020 3 commits
    • Camillo Bruni's avatar
      Reland "[log][d8] Only use d8.log.getAndStop on temporary log file" · 1724c77c
      Camillo Bruni authored 
      This is a reland of 21bb43cc

The build failures seems to be an infra flake.

Original change's description:
> [log][d8] Only use d8.log.getAndStop on temporary log file
>
> We run tests in parallel which can cause multiple tests to write to
> the shared v8.log file. This obviously breaks the simple assertions in
> mjsunit/tools/log.js.
>
> - Use temporary files for log testing with --logfile='+'
>
> - Change the symbol from '&' to '+' for using temporary files for
>   logging with --logfile
>
> - Enable skipped log tests again.
>
> Bug: v8:10937, chromium:1129854, chromium:1130196
> Change-Id: I607dc9a9ecc352e58525cdd21c1c93efebf0f09f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421826
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70071}

Bug: v8:10937
Bug: chromium:1129854
Bug: chromium:1130196
Change-Id: I2ccf7528f35057ef668aa211142e0f1073fc1fc3
Tbr: verwaest@chromium.org, victorgomes@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424257Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70076}
      1724c77c
    • Francis McCabe's avatar
      Revert "[log][d8] Only use d8.log.getAndStop on temporary log file" · ec570b8a
      Francis McCabe authored 
      This reverts commit 21bb43cc.

Reason for revert: See broken build: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20builder/49882

Original change's description:
> [log][d8] Only use d8.log.getAndStop on temporary log file
> 
> We run tests in parallel which can cause multiple tests to write to
> the shared v8.log file. This obviously breaks the simple assertions in
> mjsunit/tools/log.js.
> 
> - Use temporary files for log testing with --logfile='+'
> 
> - Change the symbol from '&' to '+' for using temporary files for
>   logging with --logfile
> 
> - Enable skipped log tests again.
> 
> Bug: v8:10937, chromium:1129854, chromium:1130196
> Change-Id: I607dc9a9ecc352e58525cdd21c1c93efebf0f09f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421826
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70071}

TBR=cbruni@chromium.org,verwaest@chromium.org,victorgomes@chromium.org

Change-Id: I5de61792c283139b2a898334e28e1f7b2d7c08f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10937
Bug: chromium:1129854
Bug: chromium:1130196
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424625Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70072}
      ec570b8a
    • Camillo Bruni's avatar
      [log][d8] Only use d8.log.getAndStop on temporary log file · 21bb43cc
      Camillo Bruni authored 
      We run tests in parallel which can cause multiple tests to write to
the shared v8.log file. This obviously breaks the simple assertions in
mjsunit/tools/log.js.

- Use temporary files for log testing with --logfile='+'

- Change the symbol from '&' to '+' for using temporary files for
  logging with --logfile

- Enable skipped log tests again.

Bug: v8:10937, chromium:1129854, chromium:1130196
Change-Id: I607dc9a9ecc352e58525cdd21c1c93efebf0f09f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421826
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70071}
      21bb43cc
  15. 18 Sep, 2020 3 commits
    • Dominik Inführ's avatar
      [heap] Move DCHECK from constructor to NewMessageBuilder · 142488db
      Dominik Inführ authored 
      The DCHECK is only guaranteed to hold after checking that is_logging()
still returns true.

Bug: v8:10315
Change-Id: Ia43657faffa4c7eda70c95a446bee1389d08e6fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418713Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70013}
      142488db
    • Peter Marshall's avatar
      Revert "Reland "[cpu-profiler] Log OSR code when starting the profiler"" · 15a78f97
      Peter Marshall authored 
      This reverts commit 8b60d8fc.

Reason for revert: Flaky on windows: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/27302

Original change's description:
> Reland "[cpu-profiler] Log OSR code when starting the profiler"
> 
> This is a reland of f6965281
> 
> Updated the test:
> 1. Set profiling interval to 100us to get 10x the samples
> 2. Guarantee we spend at least 1ms per iteration, instead of only
> bailing out if we spend more than 1ms. This gives us enough samples on
> release mode.
> 3. Increase the time spent profiling optimized code by 50% to make sure
> we have a big enough difference.
> 
> With 1000 iterations I didn't see any flakes locally so this looks solid
> now.
> 
> Original change's description:
> > [cpu-profiler] Log OSR code when starting the profiler
> >
> > OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> > starting up the profiler. This meant we didn't properly attribute
> > ticks to SFI code. The ticks ended up going to the caller instead.
> >
> > There is a weak cache of OSR code per native context, so iterate that
> > on profiler startup and log all the code objects.
> >
> > Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Mythri Alle <mythria@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69964}
> 
> Change-Id: Ib506e88b546008e462967259763bbf985b74b462
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69990}

TBR=mythria@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org

Change-Id: Ie3272c4fd297ca6f10a47c3fe8826e226a9f0545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418714Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69999}
      15a78f97
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Log OSR code when starting the profiler" · 8b60d8fc
      Peter Marshall authored 
      This is a reland of f6965281

Updated the test:
1. Set profiling interval to 100us to get 10x the samples
2. Guarantee we spend at least 1ms per iteration, instead of only
bailing out if we spend more than 1ms. This gives us enough samples on
release mode.
3. Increase the time spent profiling optimized code by 50% to make sure
we have a big enough difference.

With 1000 iterations I didn't see any flakes locally so this looks solid
now.

Original change's description:
> [cpu-profiler] Log OSR code when starting the profiler
>
> OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> starting up the profiler. This meant we didn't properly attribute
> ticks to SFI code. The ticks ended up going to the caller instead.
>
> There is a weak cache of OSR code per native context, so iterate that
> on profiler startup and log all the code objects.
>
> Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69964}

Change-Id: Ib506e88b546008e462967259763bbf985b74b462
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69990}
      8b60d8fc
  17. 17 Sep, 2020 4 commits
  19. 16 Sep, 2020 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · 76217f57
      Alex Kodat authored 
      While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be using isolate->js_entry_sp
to determine the stack to walk but isolate->js_entry_sp is the stack
pointer for the thread that currently has the Isolate lock so, if the
sampled thread does not have the lock, the sampler woud be iterating
over the wrong stack, one that might actually be actively changing on
another thread. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

Bug: v8:10850
Change-Id: Iba6cabcd3e11a19c261c004103e37e806934dc6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69952}
      76217f57
  21. 14 Sep, 2020 2 commits
  23. 09 Sep, 2020 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[test][d8] Add d8.log.getAndStop helper"" · 92236da2
      Sathya Gunasekaran authored 
      This reverts commit 23531d82.

Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/33007?

Original change's description:
> Reland "[test][d8] Add d8.log.getAndStop helper"
> 
> This is a reland of 95aa697b
> 
> Original change's description:
> > [test][d8] Add d8.log.getAndStop helper
> >
> > The new helper function allows us to write tests for log parsing
> > without the need to first generating a log file. This makes it easier
> > to spot errors when the log format changes.
> >
> > - Add d8 global variable
> > - Add file_name accessor to Logger and Log classes
> > - Change OS::LogFileOpenMode to w+ / wb+
> > - Use separate Log::WriteLogHeader method
> > - Remove unused logger_ instance variable from Log
> >
> > Bug: v8:10644
> > Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563
> > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69715}
> 
> Bug: v8:10644
> 
> TBR=verwaest@chromium.org
> 
> Change-Id: I54741344834d88a376b74e2e3a2047e880a94624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396081
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69769}

TBR=mlippautz@chromium.org,cbruni@chromium.org,gsathya@chromium.org,verwaest@chromium.org

Change-Id: I493315e0d6498f0fa9bed3409725bb52d554b53a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400982Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69770}
      92236da2
    • Camillo Bruni's avatar
      Reland "[test][d8] Add d8.log.getAndStop helper" · 23531d82
      Camillo Bruni authored 
      This is a reland of 95aa697b

Original change's description:
> [test][d8] Add d8.log.getAndStop helper
>
> The new helper function allows us to write tests for log parsing
> without the need to first generating a log file. This makes it easier
> to spot errors when the log format changes.
>
> - Add d8 global variable
> - Add file_name accessor to Logger and Log classes
> - Change OS::LogFileOpenMode to w+ / wb+
> - Use separate Log::WriteLogHeader method
> - Remove unused logger_ instance variable from Log
>
> Bug: v8:10644
> Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69715}

Bug: v8:10644

TBR=verwaest@chromium.org

Change-Id: I54741344834d88a376b74e2e3a2047e880a94624
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396081
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69769}
      23531d82
  25. 08 Sep, 2020 1 commit
  27. 07 Sep, 2020 3 commits
  29. 01 Sep, 2020 1 commit
    • Peter Marshall's avatar
      Revert "[cpu-profiler] Ensure sampled thread has Isolate lock under Windows" · 32435062
      Peter Marshall authored 
      This reverts commit dfb3f7da.

Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861

Original change's description:
> [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
> 
> While the sampler checked if the sampled thread had the Isolate locked
> (if locks are being used) under Linux, the check was not done under
> Windows (or Fuchsia) which meant that in a multi-threading application
> under Windows, thread locking was not checked making it prone to seg
> faults and the like as the profiler would be extracting info from a
> heap in motion. The fix was to move the lock check into CpuSampler
> and Ticker (--prof) so all OSes would do the correct check.
> 
> The basic concept is that on all operating systems a CpuProfiler, and
> so its corresponding CpuCampler, the profiler is tied to a thread.
> This is not based on first principles or anything, it's simply the
> way it works in V8, though it is a useful conceit as it makes
> visualization and interpretation of profile data much easier.
> 
> To collect a sample on a thread associated with a profiler the thread
> must be stopped for obvious reasons -- walking the stack of a running
> thread is a formula for disaster. The mechanism for stopping a thread
> is OS-specific and is done in sample.cc. There are currently three
> basic approaches, one for Linux/Unix variants, one for Windows and one
> for Fuchsia. The approaches vary as to which thread actually collects
> the sample -- under Linux the sample is actually collected on the
> (interrupted) sampled thread whereas under Fuchsia/Windows it's on
> a separate thread.
> 
> However, in a multi-threaded environment (where Locker is used), it's
> not sufficient for the sampled thread to be stopped. Because the stack
> walk involves looking in the Isolate heap, no other thread can be
> messing with the heap while the sample is collected. The only ways to
> ensure this would be to either stop all threads whenever collecting a
> sample, or to ensure that the thread being sampled holds the Isolate
> lock so prevents other threads from messing with the heap. While there
> might be something to be said for the "stop all threads" approach, the
> current approach in V8 is to only stop the sampled thread so, if in a
> multi-threaded environment, the profiler must check if the thread being
> sampled holds the Isolate lock.
> 
> Since this check must be done, independent of which thread the sample
> is being collected on (since it varies from OS to OS), the approach is
> to save the thread id of the thread to be profiled/sampled when the
> CpuSampler is instantiated (on all OSes it is instantiated on the
> sampled thread) and then check that thread id against the Isolate lock
> holder thread id before collecting a sample. If it matches, we know
> sample.cc has stop the sampled thread, one way or another, and we know
> that no other thread can mess with the heap (since the stopped thread
> holds the Isolate lock) so it's safe to walk the stack and collect data
> from the heap so the sample can be taken. It it doesn't match, we can't
> safely collect the sample so we don't.
> 
> Bug: v8:10850
> Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69623}

TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com

Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}
      32435062
  31. 31 Aug, 2020 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · dfb3f7da
      Alex Kodat authored 
      While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be extracting info from a
heap in motion. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

Bug: v8:10850
Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69623}
      dfb3f7da
  33. 20 Aug, 2020 1 commit
    • Dominik Inführ's avatar
      [logging] Make Log::IsEnabled() atomic · 41d2e5c9
      Dominik Inführ authored 
      With concurrent allocation background threads invoke Log::IsEnabled()
as well. Fix data race here by making is_enabled_ atomic, such that
IsEnabled() remains cheap.

After locking the mutex in MessageBuilder, IsEnabled() needs to be
checked again in case an old value was read. Otherwise we might log
even though logging was already disabled on another thread.

The other direction where a log message isn't logged is deemed
acceptable.

Bug: v8:10315
Change-Id: I32c9dd2e9879fbdb4ca94e080a16ddd875de7c30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362948
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69495}
      41d2e5c9
  35. 17 Aug, 2020 3 commits
  37. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored 
      This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.

LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).

This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.

Bug: chromium:1011762

Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  39. 11 Aug, 2020 1 commit
  41. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored 
      With the new Turbofan variants (NCI and Turboprop), we need a way to
distinguish between them both during and after compilation. We
initially introduced CompilationTarget to track the variant during
compilation, but decided to reuse the code kind as the canonical spot to
store this information instead.

Why? Because it is an established mechanism, already available in most
of the necessary spots (inside the pipeline, on Code objects, in
profiling traces).

This CL removes CompilationTarget and adds a new
NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
various things about a given code kind (e.g.: does this code kind
deopt?).

As a (very large) drive-by, refactor both Code::Kind and
AbstractCode::Kind into a new CodeKind enum class.

Bug: v8:8888
Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  43. 04 Aug, 2020 1 commit
  45. 01 Aug, 2020 1 commit
    • Ulan Degenbaev's avatar
      [ukm] Rename v8::Context::Token to v8::metrics::Recorder::ContextId · 260ec995
      Ulan Degenbaev authored 
      Chrome is currently adding a 128-bit V8ContextToken to keep track of
V8 contexts across multiple isolates and processes. Having per-isolate
token exposed by V8 leads to confusion of these two tokens.

This moves v8::Context::Token to v8::metrics::Recorder and changes
the corresponding functions:
- v8::Context::GetToken => v8::metrics::Recorder::GetContextId
- v8::Context::GetByToken => v8::metrics::Recorder::GetContext

This CL is purely mechanical and does not change the behaviour.

Bug: chromium:1101749
Tbr: clemensb@chromium.org
Change-Id: I31bbfa02ebab1c0d91b00f0d08c1b236392d14d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330023
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69188}
      260ec995
  47. 28 Jul, 2020 2 commits
    • Ross McIlroy's avatar
      [TurboProp] Add reference map population to fast reg alloc. · e9a37bf8
      Ross McIlroy authored 
      Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.

BUG=v8:9684

Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
      e9a37bf8
    • Ross McIlroy's avatar
      [TurboProp] Add support for spill slot allocation to fast reg alloc · 5b0c6cde
      Ross McIlroy authored 
      Adds support for tracking the instruction range of spilled operands,
and then allocating spill slots to these ranges. It also adds some
unittests covering spill slot allocation.

Spill slots are allocated in a linear fashion, running through the
instruction stream in a linear order, ensuring that no spill operand
is allocated to a same spill slot that is already assigned to during
this whole start / end range. This isn’t optimal, since it doesn’t
take into account holes in these ranges (e.g, blocks between start
and end that aren’t dominated by the start), but in practice rarely
leads to more than one extra spill slot being allocated compared to
the current allocator.

BUG=v8:9684

Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69107}
      5b0c6cde