Skip to content

V
V8
Switch branch/tag
  1. 30 Oct, 2009 1 commit
  3. 15 Oct, 2009 2 commits
    • kmillikin@chromium.org's avatar
      Added first support for tracking locations of expressions in the · 339e49c0
      kmillikin@chromium.org authored 
      fast-mode code generator.

AST expression nodes are annotated with a location when doing the
initial syntactic check of the AST.  In the current implementation,
expression locations are 'temporary' (ie, allocated to the stack) or
'nowhere' (ie, the expression's value is not needed though it must be
evaluated for side effects).

For the assignment '.result = true' on IA32, we had before (with the
true value already on top of the stack):

32  mov eax,[esp]
35  mov [ebp+0xf4],eax
38  pop eax

Now:

32  pop [ebp+0xf4]


======== On x64, before:

37  movq rax,[rsp]
41  movq [rbp-0x18],rax
45  pop rax

Now:

37  pop [rbp-0x18]


======== On ARM, before (with the true value in register ip):

36  str ip, [sp, #-4]!
40  ldr ip, [sp, #+0]
44  str ip, [fp, #-12]
48  add sp, sp, #4

Now:

36  str ip, [fp, #-12]


Review URL: http://codereview.chromium.org/267118

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      339e49c0
    • kmillikin@chromium.org's avatar
      Initial port of top-level code generator to ARM. For the constant · 11d9e7ff
      kmillikin@chromium.org authored 
      true at the top level we generate:

  0  stmdb sp!, {r1, r8, fp, lr}
  4  add fp, sp, #8
  8  ldr ip, [r10, #+4]
 12  ldr r2, [r10, #+0]
 16  str ip, [sp, #-4]!
 20  add lr, pc, #4
 24  cmp sp, r2
 28  ldrcc pc, [pc, #+68]        ;; code: STUB, StackCheck, minor: 0
 32  ldr ip, [pc, #+68]          ;; object: 0xf5bc4161 <true>
 36  str ip, [sp, #-4]!
 40  ldr ip, [sp, #+0]
 44  str ip, [fp, #-12]
 48  add sp, sp, #4
 52  ldr ip, [fp, #-12]
 56  str ip, [sp, #-4]!
 60  ldr r0, [sp], #+4
 64  mov sp, fp                  ;; js return
 68  ldmia sp!, {fp, lr}
 72  add sp, sp, #4
 76  bx lr
 80  ldr r0, [r10, #+4]
 84  mov sp, fp                  ;; js return
 88  ldmia sp!, {fp, lr}
 92  add sp, sp, #4
 96  bx lr
100  constant pool begin
104  constant
108  constant

Review URL: http://codereview.chromium.org/264067

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3073 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      11d9e7ff
  5. 14 Oct, 2009 1 commit
    • kmillikin@chromium.org's avatar
      Initial infrastructure for fast compilation of top-level code. The · f74e7235
      kmillikin@chromium.org authored 
      fast code generator is optimized for compilation time and code size.

Currently it is only implemented on IA32.  It is potentially triggered
for any code in the global scope (including code eval'd in the global
scope).  It performs a syntactic check and chooses to compile in fast
mode if the AST contains only supported constructs and matches some
other constraints.

Initially supported constructs are

* ExpressionStatement,
* ReturnStatement,
* VariableProxy (variable references) to parameters and
    stack-allocated locals,
* Assignment with lhs a parameter or stack-allocated local, and
* Literal

This allows compilation of literals at the top level and not much
else.

All intermediate values are allocated to temporaries and the stack is
used for all temporaries.  The extra memory traffic is a known issue.

The code generated for 'true' is:

 0  push ebp
 1  mov ebp,esp
 3  push esi
 4  push edi
 5  push 0xf5cca135             ;; object: 0xf5cca135 <undefined>
10  cmp esp,[0x8277efc]
16  jnc 27  (0xf5cbbb1b)
22  call 0xf5cac960             ;; code: STUB, StackCheck, minor: 0
27  push 0xf5cca161             ;; object: 0xf5cca161 <true>
32  mov eax,[esp]
35  mov [ebp+0xf4],eax
38  pop eax
39  mov eax,[ebp+0xf4]
42  mov esp,ebp                 ;; js return
44  pop ebp
45  ret 0x4
48  mov eax,0xf5cca135          ;; object: 0xf5cca135 <undefined>
53  mov esp,ebp                 ;; js return
55  pop ebp
56  ret 0x4

Review URL: http://codereview.chromium.org/273050

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f74e7235
  7. 08 Oct, 2009 1 commit
  9. 30 Sep, 2009 1 commit
  11. 16 Sep, 2009 1 commit
    • mikhail.naganov@gmail.com's avatar
      Add initial version of retainers heap profile. · abc0bd46
      mikhail.naganov@gmail.com authored 
      The profile is taken together with constructors profile. In theory, it
should represent a complete heap graph. However, this takes a lot of memory,
so it is reduced to a more compact, but still useful form. Namely:

 - objects are aggregated by their constructors, except for Array and Object
   instances, that are too hetereogeneous;

 - for Arrays and Objects, initially every instance is concerned, but then
   they are grouped together based on their retainer graph paths similarity (e.g.
   if two objects has the same retainer, they are considered equal);

Review URL: http://codereview.chromium.org/200132

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2903 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      abc0bd46
  13. 11 Sep, 2009 1 commit
  15. 09 Sep, 2009 1 commit
  17. 07 Sep, 2009 1 commit
  19. 26 Aug, 2009 1 commit
  21. 24 Aug, 2009 1 commit
  23. 19 Aug, 2009 1 commit
  25. 31 Jul, 2009 2 commits
  27. 29 Jul, 2009 1 commit
  29. 17 Jul, 2009 1 commit
  31. 07 Jul, 2009 1 commit
  33. 24 Jun, 2009 1 commit
  35. 28 May, 2009 1 commit
    • mikhail.naganov@gmail.com's avatar
      Implement a dynamically growing memory log buffer with an upper limit. · e48095b8
      mikhail.naganov@gmail.com authored 
      The goal of this change is to allow longer profiling sessions and preserve memory when profiler isn't started. The buffer starts with 64K and grows until it reaches the upper limit, which is currently set to 50MB --- according to my evaluations, this is enough for at least 20 minutes of GMail profiling. As we're planning to introduce compression for the profiler log, this time boundary will be significantly increased soon.

To make possible unit testing of the new component, I've factored out Logger's utility classes into a separate source file: log-utils.h/cc. Log and LogMessageBuilder are moved there from log.cc without any semantical changes.

Review URL: http://codereview.chromium.org/115814


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      e48095b8
  37. 14 May, 2009 3 commits
  39. 05 May, 2009 2 commits
  41. 30 Apr, 2009 1 commit
    • sgjesse@chromium.org's avatar
      Added better version information · a4708472
      sgjesse@chromium.org authored 
      The current version is now held in src/version.cc in a number of defines which needs to be modified when changing version.

The following defines make up the version information:

  MAJOR_VERSION
  MINOR_VERSION
  BUILD_NUMBER
  PATCH_LEVEL
  CANDIDATE_VERSION

The first four are numbers and the fifth is a boolean. Besides these five the define

  SONAME

can be used to set a specific soname when building the a shared library (see below). This will most likely be used on stable branches where binary compatibility is ensured between different versions. This define is a string.

This version information is now read by the SCons build to support setting the soname for a Linux shared library. This requires passing the option soname=on to the SCons build.

When soname=on is specified the soname for the shared library can be set in two different ways. Either it will be the full versioned library name (e.g. libv8-1.2.2.so) or a specific soname defined in src/version.cc. Whenever a shared library is build with an soname the filename of the library will hold the full version name (e.g. libv8-1.2.2.so).

I did not update the xcode project with the new files.

BUG=151
Review URL: http://codereview.chromium.org/100104

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1826 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      a4708472
  43. 29 Apr, 2009 2 commits
  45. 24 Apr, 2009 1 commit
  47. 23 Apr, 2009 1 commit
  49. 22 Apr, 2009 1 commit
  51. 14 Apr, 2009 1 commit
  53. 07 Apr, 2009 1 commit
  55. 31 Mar, 2009 1 commit
  57. 05 Mar, 2009 1 commit
  59. 03 Mar, 2009 1 commit
  61. 27 Feb, 2009 1 commit
  63. 25 Feb, 2009 2 commits
  65. 24 Feb, 2009 1 commit
    • sgjesse@chromium.org's avatar
      Add socket support to platform code. · be059966
      sgjesse@chromium.org authored 
      The new Socket class is an encapsulation of the standard BSD socket API. As it depends on platform specific include files and have some slight platform variations it is part of the platform code.

On Mac OS only the option SO_REUSEADDR is set to true for server sockets. Running the test required it as the bound listener socket would sometimes end up in TIME_WAIT. On Windows and Linux this has never been observed (given the client end of the socket is closed before the server end).

The code has been tested on Windows, Linux and Mac OS. The FreeBSD version is a copy of the Linux version but has not been compiled nor tested.

Missing Xcode project updates.
Review URL: http://codereview.chromium.org/27085

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