1. 29 Jun, 2015 7 commits
  2. 27 Jun, 2015 1 commit
  3. 26 Jun, 2015 29 commits
  4. 25 Jun, 2015 3 commits
    • yangguo's avatar
      Serializer: commit new internalized strings after deserialization. · cf21d22f
      yangguo authored
      Reserving space for deserialization can cause GC, which
      can evict entries from the string table. Having more deleted
      entries now, StringTable::EnsureCapacity could cause a GC
      later during deserialization even when we actually still
      have enough capacity.
      
      Instead, we now keep new internalized strings in a separate list
      and commit them to the string table at the end.
      
      R=ulan@chromium.org
      BUG=chromium:502085
      LOG=N
      
      Review URL: https://codereview.chromium.org/1204863006
      
      Cr-Commit-Position: refs/heads/master@{#29308}
      cf21d22f
    • mbrandy's avatar
      PPC64: Fix "[ic] Record call counts for monomorphic calls made with an IC." · e4f546c5
      mbrandy authored
      StoreP to a tagged object pointer requires a scratch register.
      
      R=dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1207323002
      
      Cr-Commit-Position: refs/heads/master@{#29307}
      e4f546c5
    • 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