Skip to content

V
V8
Switch branch/tag
  1. 04 Oct, 2013 2 commits
  3. 02 Oct, 2013 1 commit
  5. 27 Aug, 2013 1 commit
  7. 24 Jul, 2013 1 commit
  9. 05 Jul, 2013 1 commit
  11. 03 Jul, 2013 2 commits
  13. 14 Jun, 2013 1 commit
  15. 06 Jun, 2013 1 commit
  17. 31 May, 2013 1 commit
  19. 27 May, 2013 1 commit
  21. 23 May, 2013 2 commits
  23. 22 May, 2013 2 commits
  25. 10 May, 2013 1 commit
  27. 08 May, 2013 2 commits
  29. 07 May, 2013 2 commits
  31. 02 May, 2013 1 commit
  33. 26 Apr, 2013 1 commit
  35. 06 Mar, 2013 1 commit
  37. 22 Nov, 2012 1 commit
    • rossberg@chromium.org's avatar
      Get rid of static module allocation, do it in code. · ce05280b
      rossberg@chromium.org authored 
      Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)

All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.

For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,

  module A {
    let x;
    module B { let y; }
  }
  module C { let z; }

allocates contexts as follows:

[header| .A | .B | .C | A | C ]  (global)
          |    |    |
          |    |    +-- [header| z ]  (module)
          |    |
          |    +------- [header| y ]  (module)
          |
          +------------ [header| x | B ]  (module)

Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).

To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.

1. Allocate: for each module _literal_, allocate the module contexts and
   respective instance object and wire them up. This happens in the
   PushModuleContext runtime function, as generated by AllocateModules
   (invoked by VisitDeclarations in the hosting scope).

2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
   assign the respective instance object to respective local variables. This
   happens in VisitModuleDeclaration, and uses the instance objects created
   in the previous stage.
   For each module _literal_, this phase also constructs a module descriptor
   for the next stage. This happens in VisitModuleLiteral.

3. Populate: invoke the DeclareModules runtime function to populate each
   _instance_ object with accessors for it exports. This is generated by
   DeclareModules (invoked by VisitDeclarations in the hosting scope again),
   and uses the descriptors generated in the previous stage.

4. Initialize: execute the module bodies (and other code) in sequence. This
   happens by the separate statements generated for module bodies. To reenter
   the module scopes properly, the parser inserted ModuleStatements.

R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ce05280b
  39. 11 Oct, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Added a simple dead code removal phase. · f03fd70d
      svenpanne@chromium.org authored 
      We iteratively remove all dead Hydrogen instruction until we reach a fixed point. We consider an instruction dead if it is unused, has no observable side effects and is deletable. The last part of the condition is currently not very nice: We basically have to whitelist "safe" instructions, because we are missing more detailed dependencies and/or more detailed tracking of side effects.

We disable dead code elimination for now in our test runners, because we have tons of poorly written tests which wouldn't test anymore what they are supposed to test with this phase enabled. To get test coverage for dead code elimination itself, we should enable it on a few build bots. This is not really a perfect state, but the best we can do for now.

This patch includes a few const-correctness fixes, most of them were necessary for this CL.

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12697 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f03fd70d
  41. 27 Aug, 2012 1 commit
    • verwaest@chromium.org's avatar
      Make order of addition the primary order of descriptor arrays. · efb53e14
      verwaest@chromium.org authored 
      The order by name is maintained as secondary order by using unused bits in the property details.

This is preliminary work towards sharing descriptors arrays.

The change allows us
- to get rid of the LastAdded bits in the map, binding it to the number of valid descriptors for the given map
- to avoid resorting by enumeration index to create the cache
- (maybe in the future, depending on performance) to get rid of the enumeration cache altogether.

Although generally the number_of_descriptors equals the NumberOfOwnDescriptors in the current version, this is preliminary work towards sharing    descriptors, where maps may have more descriptors than are valid for the map.

Review URL: https://chromiumcodereview.appspot.com/10879013

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12385 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      efb53e14
  43. 05 Jul, 2012 1 commit
    • verwaest@chromium.org's avatar
      Separating transitions from descriptors. · d7a5b7d5
      verwaest@chromium.org authored 
      In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.

The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.

Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.

Review URL: https://chromiumcodereview.appspot.com/10697015

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d7a5b7d5
  45. 25 Jun, 2012 2 commits
  47. 11 Jun, 2012 1 commit
  49. 02 Mar, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Re-land CL 9466047. · 5033b9b6
      svenpanne@chromium.org authored 
      Main change from the original CL: Call::ComputeTarget does not use IsProperty
anymore, because this would potentially need a holder, which we don't have
here. Using Map::LookupInDescriptors with a NULL holder is a bit fishy in
general, because one has to be *extremely* careful when using its LookupResult.

The original CL made Chrome's NetInternalsTest.netInternalsTourTabs browser test
fail, but it's a mystery how this could happen: We should never reach
Call::ComputeTarget via Call::RecordTypeFeedback with a CALLBACKS property,
because we never consider calls to them monomorphic, which is in turn because of
the stub cache leaving them in the pre-monomorphic state. Therefore, I don't
have a clue how to write a regression test for this...

As an additional tiny bonus, the --trace-opt output for deoptimizations has been
improved.

Review URL: https://chromiumcodereview.appspot.com/9584003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10906 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      5033b9b6
  51. 29 Feb, 2012 1 commit
  53. 28 Feb, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Handle CALLBACKS correctly in IsProperty functions. · 18ba2216
      svenpanne@chromium.org authored 
      With transitions in AccessorPairs, it is not enough to look at the PropertyType
alone to decide whether we look at a property or not: For objects with
JavaScript accessors, we have to look into the AccessorPair itself and see if
one of its 2 parts is actually a JavaScript accessor. Therefore, a predicate
with a PropertyType argument alone doesn't make sense anymore, we might need the
associated value, too.

Things are complicated by the fact that the holder in a LookupResult can be
NULL, so we must be careful to retrieve its value only when it is really
needed. To achieve the needed call-by-name semantics, a new Entry is introduced,
which is basically a closure over a DescriptorArray and an index into this array
(C++0x to the rescue!). GCC is clever enough to inline this class, so we pay no
runtime penalty for this abstraction.

It's all a bit ugly, but this is caused by the current structure of Descriptor,
DescriptorArray and LookupResult: Things would be much easier if DescriptorArray
were, well, an array of Descriptors, and LookupResult were a 'Maybe Descriptor'
(in Haskell-terms).

Review URL: https://chromiumcodereview.appspot.com/9466047

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10847 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      18ba2216
  55. 06 Feb, 2012 1 commit
  57. 03 Feb, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Removed IsTransitionType predicate. · b34e202b
      svenpanne@chromium.org authored 
      With the upcoming changes to CALLBACKS properties, a predicate on the transition
type alone doesn't make sense anymore: For CALLBACKS one has to look into the
property's value to decide, and there is even the possibility of having a an
accessor function *and* a transition in the same property.

I am not completely happy with some parts of this CL, because they contain
redundant code, but given the various representations we currently have for
property type/value pairs, I can see no easy way around that. Perhaps one can
improve this a bit in a different CL, the current diversity really, really hurts
productivity...

As a bonus, this CL includes a few minor things:

 * CaseClause::RecordTypeFeedback has been cleaned up and it handles the
   NULL_DESCRIPTOR case correctly now. Under some (very unlikely) circumstances,
   we previously missed some opportunities for monomorphic calls. In general, it
   is rather unfortunate that NULL_DESCRIPTOR "shines through", it is just a
   hack for the inability to remove a descriptor entry during GC, something
   callers shouldn't have to be aware of.

 * DescriptorArray::CopyInsert has been cleaned up a bit, preparing it for later
   CALLBACKS-related changes.

 * LookupResult::Print is now more informative for CONSTANT_TRANSITION.

Review URL: https://chromiumcodereview.appspot.com/9320066

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10600 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      b34e202b
  59. 09 Nov, 2011 1 commit
  61. 08 Nov, 2011 1 commit