1. 12 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove inline header includes from non-inline headers (1). · 00a07bc1
      mstarzinger authored
      This tries to remove includes of "-inl.h" headers from normal ".h"
      headers, thereby reducing the chance of any cyclic dependencies and
      decreasing the average size of our compilation units.
      
      Note that this change still leaves 7 violations of that rule in the
      code. However there now is the "tools/check-inline-includes.sh" tool
      detecting such violations.
      
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1283033003
      
      Cr-Commit-Position: refs/heads/master@{#30125}
      00a07bc1
  2. 11 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove several grab-bag includes from the v8.h header. · 58109a2c
      mstarzinger authored
      This is the first step of turning the v8.h file into a normal header
      instead of an include-the-world header. The new rule is that no other
      header files are allowed to include v8.h, which is enforced by DEPS.
      
      Also the number of includes inside the v8.h file has been drastically
      reduced. Basically the last missing piece is the inclusion of the big
      objects-inl.h file.
      
      This in turn makes many headers follow the IWYU principle.
      
      R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1282503003
      
      Cr-Commit-Position: refs/heads/master@{#30102}
      58109a2c
  3. 30 Jul, 2015 2 commits
    • binji's avatar
      [d8] Fix tsan bugs · 053b8434
      binji authored
      script_executed and last_run are read/written by multiple threads. Also
      externalized_shared_contents_ is modified by multiple threads.
      
      BUG=4306
      R=jarin@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1252623003
      
      Cr-Commit-Position: refs/heads/master@{#29912}
      053b8434
    • binji's avatar
      [d8 Workers] Fix bug creating Worker during main thread termination · a87db3de
      binji authored
      When the main thread terminates, it forcibly terminates all Worker threads.
      When this happens, the threads objects were only half-created; they had a
      JavaScript Worker object, but not a C++ worker object.
      
      This CL fixes that bug, as well as some other fixes:
      * Signatures on Worker methods
      * Use SetAlignedPointerFromInternalField instead of using an External.
      * Remove state_ from Worker. Simplify to atomic bool running_.
      
      BUG=chromium:511880
      R=jarin@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1255563002
      
      Cr-Commit-Position: refs/heads/master@{#29911}
      a87db3de
  4. 23 Jul, 2015 2 commits
  5. 20 Jul, 2015 1 commit
  6. 17 Jul, 2015 2 commits
  7. 16 Jul, 2015 1 commit
    • binji's avatar
      d8: Leak context_mutex_ so it will never be destroyed while locked · 162f116a
      binji authored
      Calling quit() from d8 will call exit(), which will run static destructors. If
      context_mutex_ is statically allocated, pthread_mutex_destroy will be called.
      
      When running d8 in "isolates" mode, another thread may be running. If it calls
      CreateEvaluationContext, it will lock the context_mutex_. If the mutex is
      destroyed while it is locked, it will return an error.
      
      This CL changes the Mutex to a LazyMutex, which will leak instead of being
      destroyed.
      
      BUG=v8:4279
      R=jarin@chromium.org
      R=machenbach@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1240553003
      
      Cr-Commit-Position: refs/heads/master@{#29709}
      162f116a
  8. 15 Jul, 2015 1 commit
  9. 14 Jul, 2015 4 commits
  10. 13 Jul, 2015 2 commits
  11. 07 Jul, 2015 1 commit
  12. 06 Jul, 2015 1 commit
    • binji's avatar
      Fix bug when transferring SharedArrayBuffer to multiple Workers. · dd7962bf
      binji authored
      Previously, the serialization code would call Externalize for every transferred
      ArrayBuffer or SharedArrayBuffer, but that function can only be called once. If
      the buffer is already externalized, we should call GetContents instead.
      
      Also fix use-after-free bug when transferring ArrayBuffers. The transferred
      ArrayBuffer must be internalized in the new isolate, or be managed by the
      Shell. The current code gives it to the isolate externalized and frees it
      immediately afterward when the SerializationData object is destroyed.
      
      BUG=chromium:497295
      R=jarin@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1215233004
      
      Cr-Commit-Position: refs/heads/master@{#29499}
      dd7962bf
  13. 01 Jul, 2015 1 commit
  14. 25 Jun, 2015 1 commit
    • binji's avatar
      Fix cluster-fuzz regression when getting message from Worker · 28b0129b
      binji authored
      The issue is that Worker.prototype.terminate was deleting the C++ Worker
      object, and then Worker.prototype.getMessage was trying to read messages from
      the queue.
      
      The simplest solution is to keep workers in a zombie state when they have been
      terminated. They won't be reaped until Shell::CleanupWorkers is called.
      
      I've also fixed some threading issues with Workers:
      
      * Workers can be created by another Worker, so the Shell::workers_ variable
      must be protected by a mutex.
      
      * An individual Worker can typically only be accessed by the isolate that
      created it, but the main thread can always terminate it, so the Worker::state_
      must be accessed in a thread-safe way.
      
      BUG=chromium:504136
      R=jochen@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1208733002
      
      Cr-Commit-Position: refs/heads/master@{#29306}
      28b0129b
  15. 22 Jun, 2015 1 commit
    • binji's avatar
      Add d8 API for spawning function on a new thread (Third try) · 001ee86e
      binji authored
      This API closely matches the Worker API. The differences:
      
      1) The argument to the Worker constructor is a function to run, not a script.
      2) Receiving a message from a worker is a synchronous API (as there is no event
      loop).
      
      The serialization done here is not robust as the real DOM implementation. For
      example, recursive data structures or otherwise duplicated objects are not
      allowed.
      
      BUG=chromium:497295
      LOG=n
      
      Review URL: https://codereview.chromium.org/1192923002
      
      Cr-Commit-Position: refs/heads/master@{#29195}
      001ee86e
  16. 19 Jun, 2015 2 commits
  17. 18 Jun, 2015 2 commits
  18. 12 Jun, 2015 1 commit
  19. 03 Jun, 2015 1 commit
  20. 22 Apr, 2015 1 commit
  21. 20 Apr, 2015 1 commit
  22. 13 Apr, 2015 1 commit
  23. 10 Feb, 2015 1 commit
    • adamk's avatar
      Enable compiling mjsunit tests as ES6 modules · a18b797f
      adamk authored
      Adding the line "// MODULE" to an mjsunit file will now cause
      run-tests.py to prefix the test case with "--module" in the
      d8 commandline.
      
      d8 has itself been updated to treat files preceded with "--module" as
      modules (that is, it compiles them with ScriptCompiler::CompileModule,
      and turns on --harmony-modules).
      
      Review URL: https://codereview.chromium.org/902263002
      
      Cr-Commit-Position: refs/heads/master@{#26555}
      a18b797f
  24. 21 Nov, 2014 1 commit
  25. 10 Sep, 2014 1 commit
  26. 02 Sep, 2014 1 commit
  27. 04 Aug, 2014 1 commit
  28. 16 Jul, 2014 1 commit
    • vogelheim@chromium.org's avatar
      Change ScriptCompiler::CompileOptions to allow for two 'cache' modes · a42612b4
      vogelheim@chromium.org authored
      (parser or code) and to be explicit about cache consumption or production
      (rather than making presence of cached_data imply one or the other.)
      
      Also add a --cache flag to d8, to allow testing the functionality.
      
      -----------------------------
      API change
      
      Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).
      
      Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.
      
      Changes from old behaviour:
      
      - If you previously didn't use caching, nothing changes.
      Example:
        v8::CompileUnbound(isolate, source, kNoCompileOptions);
      
      - If you previously used caching, it worked like this:
      
        - 1st run:
        v8::CompileUnbound(isolate, source, kProduceToCache);
        Then, source->cached_data would contain the
        data-to-be cached. This remains the same, except you
        need to tell V8 which type of data you want.
        v8::CompileUnbound(isolate, source, kProduceParserCache);
      
        - 2nd run:
        v8::CompileUnbound(isolate, source, kNoCompileOptions);
        with source->cached_data set to the data you received in
        the first run. This will now ignore the cached data, and
        you need to explicitly tell V8 to use it:
        v8::CompileUnbound(isolate, source, kConsumeParserCache);
      -----------------------------
      
      BUG=
      R=marja@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/389573006
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      a42612b4
  29. 07 Jul, 2014 1 commit
  30. 30 Jun, 2014 1 commit
  31. 23 Jun, 2014 1 commit