Skip to content

V
V8
Switch branch/tag
  1. 03 May, 2016 1 commit
  3. 21 Apr, 2016 1 commit
    • mstarzinger's avatar
      [profiler] Remove obsolete CompilationInfo argument. · 6f43e1f5
      mstarzinger authored 
      This removes the CompilationInfo argument from one of the logging
functions where it is unused. The long-term goal is to not pass around
the CompilationInfo at all. The assumption that the CompilationInfo is
available is incompatible with serialized code, where compilation has
happened during building time of V8 itself.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#35705}
      6f43e1f5
  5. 20 Apr, 2016 1 commit
  7. 12 Apr, 2016 1 commit
  9. 11 Apr, 2016 5 commits
  11. 08 Apr, 2016 2 commits
    • jfb's avatar
      Revert of Fix printf formats (patchset #8 id:140001 of... · 4c4fdc2d
      jfb authored 
      Revert of Fix printf formats (patchset #8 id:140001 of https://codereview.chromium.org/1869433004/ )

Reason for revert:
One small issue easily fixed here: https://codereview.chromium.org/1867333003/

But it looks like MSVS 2013 doesn't like some of the formats and exists with the unhelpful:
Stderr:
f:\dd\vctools\crt\crtw32\stdio\output.c(1125) : Assertion failed: ("Incorrect
format specifier", 0)

It's easier to revert for now, I'll dig more into the docs:
https://msdn.microsoft.com/en-us/library/56e442dc(v=vs.120).aspx
https://msdn.microsoft.com/en-us/library/tcxf1dw6(v=vs.120).aspx

And then resubmit, making sure I run these bots.

Original issue's description:
> Fix printf formats
>
> The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
>
>  - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
>  - Uses it appropriately.
>  - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
>  - Fixes a bunch of incorrect formats.
>
> R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
>
> Committed: https://crrev.com/6ebf9fbb93d31f9be41156a3325d58704ed4933d
> Cr-Commit-Position: refs/heads/master@{#35365}

TBR=jochen@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,ahaas@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#35366}
      4c4fdc2d
    • jfb's avatar
      Fix printf formats · 6ebf9fbb
      jfb authored 
      The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:

 - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
 - Uses it appropriately.
 - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
 - Fixes a bunch of incorrect formats.

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

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

Cr-Commit-Position: refs/heads/master@{#35365}
      6ebf9fbb
  13. 05 Apr, 2016 2 commits
  15. 31 Mar, 2016 1 commit
  17. 21 Mar, 2016 2 commits
  19. 18 Mar, 2016 1 commit
  21. 17 Mar, 2016 4 commits
  23. 15 Mar, 2016 1 commit
    • ahaas's avatar
      [wasm] Int64Lowering of I64Div and I64Rem. · 29e0e8e9
      ahaas authored 
      On 32-bit systems these instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameters is done in the
Int64Lowering. We use the return value of the C function to determine
whether the calculation should trap or not.

R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34768}
      29e0e8e9
  25. 14 Mar, 2016 3 commits
  27. 11 Mar, 2016 1 commit
    • joransiu's avatar
      S390: Printf format specifier for size_t · 59267a08
      joransiu authored 
      GCC on S390 31-bit treats size_t as 'long unsigned int', which
is incompatible with %d format specifier that expects an 'int'.
Introduce a new V8 SIZET PREFIX to use %zd instead.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,yangguo@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34724}
      59267a08
  29. 10 Mar, 2016 1 commit
    • joransiu's avatar
      S390: Platform specific includes in common files · daea0e75
      joransiu authored 
      Add S390 platform specific \#includes across various common files.
Add S390 CPU features to enum.
Add S390 implementation to extract sp/fp/pc from signal context.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34674}
      daea0e75
  31. 09 Mar, 2016 1 commit
  33. 04 Mar, 2016 2 commits
  35. 03 Mar, 2016 1 commit
  37. 02 Mar, 2016 1 commit
  39. 01 Mar, 2016 3 commits
  41. 26 Feb, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add support for cpu profiler logging. · cb29f9cd
      rmcilroy authored 
      Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.

The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.

Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.

Still to do is tracking source positions which will be done in a
followup CL.

BUG=v8:4766
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34321}
      cb29f9cd
  43. 22 Feb, 2016 1 commit
  45. 10 Feb, 2016 1 commit
    • mlippautz's avatar
      [heap] Move to page lookups for SemiSpace, NewSpace, and Heap containment methods · cfbd2561
      mlippautz authored 
      Preparing the young generation for (real) non-contiguous backing memory, this
change removes object masks that are used to compute containment in semi and new
space. The masks are replaced by lookups for object tags and page headers, where
possible.

Details:
- Use the fast checks (page header lookups) for containment in regular code.
- Use the slow version that masks out the page start adress and iterates all
  pages of a space for debugging/verification.
- The slow version works for off-heap/unmapped memory.
- Encapsulate all checks for the old->new barrier in Heap::RecordWrite().

BUG=chromium:581412
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33857}
      cfbd2561
  47. 08 Feb, 2016 1 commit
    • yangguo's avatar
      [serializer] Ensure immortal immovable roots are deserialized correctly. · 07d40b74
      yangguo authored 
      The serializer collects objects in iteration order, not in allocation
order. This means that the deserializer will put these objects in
iteration order onto the reserved pages as well. There is no guarantee
that objects that were on the first page will end up on the first page
after deserialization.

Until now we got lucky, since we only ever need one space per page for
the default snapshot. For roots, the iteration order and allocation
order also do not differ enough to cause any issue for immortal
immovable root objects. These objects need to stay on the first page of
its allocated space to not move.

However, let's make sure it stays this way, and we realize soon enough
if this assumption does not hold.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33810}
      07d40b74
  49. 05 Feb, 2016 1 commit