1. 31 Mar, 2016 1 commit
  2. 29 Mar, 2016 1 commit
    • fdoray's avatar
      TaskScheduler [5/9] Task Tracker · 0fc7a666
      fdoray authored
      This change is a subset of https://codereview.chromium.org/1698183005/
      
      All tasks go through the scheduler's TaskTracker when they are posted and
      when they are executed. The TaskTracker enforces shutdown semantics and takes
      care of tracing and profiling.
      
      We have an alternate implementation which uses atomic operations to reduce lock
      contention. However, we prefer to check this simple implementation in first and
      bring the atomic operations in an incremental CL.
      
      BUG=553459
      
      Review URL: https://codereview.chromium.org/1705943002
      
      Cr-Commit-Position: refs/heads/master@{#383749}
      0fc7a666
  3. 18 Mar, 2016 1 commit
    • fdoray's avatar
      TaskScheduler [4/9] Priority Queue · 6477fbde
      fdoray authored
      This change is a subset of https://codereview.chromium.org/1698183005/
      
      A PriorityQueue holds Sequences of Tasks. It supports Push, Pop and
      Peek operations through a Transaction object.
      
      A SequenceSortKey must be provided to push a Sequence into a
      PriorityQueue. Sequences are sorted according to their SequenceSortKey.
      The SequenceSortKey of a Sequence never changes while it is in the
      PriorityQueue (even if Tasks are pushed/popped from the Sequence).
      
      BUG=553459
      
      Review URL: https://codereview.chromium.org/1709713002
      
      Cr-Commit-Position: refs/heads/master@{#382115}
      6477fbde
  4. 17 Mar, 2016 2 commits
  5. 16 Mar, 2016 1 commit
    • bcwhite's avatar
      Refactor histogram_persistence to be a class. · 33d95806
      bcwhite authored
      The number of top-level functions was getting too large
      and impeding development of other features due to the
      previous lack of OO design.
      
      The code is largely unchanged, just moved into a stateful
      class and reordered to match the public/private sections
      of the class.
      
      Two other CLs are included here because they fit well with the refactoring:
      
      https://codereview.chromium.org/1689833002/
      Add ownership-transfer to histogram management calls.
      
        This CL changes the interface to use scoped_ptr to
        explicitly document, with std::move, when the transfer
        of ownership is taking place.
      
      https://codereview.chromium.org/1731453002/
      Reduce histogram creation time by avoiding import of those just created.
      
        Attempting to import histograms in the persistent memory
        segment is necessary because it could be shared and thus
        have other processes creating objects within it. However,
        there's no need to import those objects that this process
        created.
      
        The simple method remembering the "reference" of the last
        histogram created in the allocator catches almost all
        cases and reduces histogram creation time by 40%.
      
      BUG=546019
      TBR=grt,thakis
      grt: setup/installer_metrics.cc (no logic changes)
      thakis: gn & gyp changes for new files
      
      Review URL: https://codereview.chromium.org/1738063002
      
      Cr-Commit-Position: refs/heads/master@{#381386}
      33d95806
  6. 15 Mar, 2016 2 commits
    • primiano's avatar
      Make the allocator_features gyp target target-only · d19a1048
      primiano authored
      allocator_features uses buildflag_header to generate a header at
      build time. In host/target builds, both the #host and #target
      targets have a ninja rule for the same path, which is bad.
      This CL makes allocator_features follow the same pattern of
      base_debugging_flags (target-only, everything else explicitly refers
      to the #target veriant)
      
      I verified that the problem reproduces without this patch
      by doing:
      $ build/gyp_chromium -DOS=android -Duse_experimental_allocator_shim=1
      $ ninja -w dupbuild=err -n -C out_android/Release/ all
      ninja: warning: multiple rules generate gen/base/allocator/features.h. builds involving this target will not be correct;
      
      And this CL fixes it.
      
      BUG=593695
      
      Review URL: https://codereview.chromium.org/1794943006
      
      Cr-Commit-Position: refs/heads/master@{#381289}
      d19a1048
    • dcheng's avatar
      Remove legacy scoped_ptr implementation. · ba7fcd69
      dcheng authored
      scoped_ptr is just a type alias now for std::unique_ptr on all platforms.
      
      BUG=554298
      
      Review URL: https://codereview.chromium.org/1801823003
      
      Cr-Commit-Position: refs/heads/master@{#381132}
      ba7fcd69
  7. 14 Mar, 2016 1 commit
  8. 12 Mar, 2016 2 commits
    • wfh's avatar
      Add test for multithreaded ActiveVerifier behavior. · 8f20e83d
      wfh authored
      Previous to crrev.com/678736a1 there was a race in the setting of the
      g_active_verifier global that could have caused multiple instantiations.
      
      This adds a test to verify the new behavior and detect any future
      regressions. The test failing with the old code can be seen here:
      
      http://pastebin.com/raw/iXz8j21C
      
      BUG=592753
      TEST=base_unittests --gtest_filter=ScopedHandleTest.MultiProcess
      
      Review URL: https://codereview.chromium.org/1779333003
      
      Cr-Commit-Position: refs/heads/master@{#380835}
      8f20e83d
    • scottmg's avatar
      Add histograms to compare GetVersionEx() with VerQueryValue() of kernel32 · d68b1e1c
      scottmg authored
      Checking VerQueryValue() of kernel32 reports the "real" OS, rather than
      the potentially shimmed one that GetVersionEx() reports.
      
      Normally it's better to use GetVersionEx() because that'll determine the
      APIs that are available and how they behave. However, we'd like to know
      if there are a substantial percentage of users in compatibility mode, as
      there have been complaints of users seeing the "XP and Vista are no
      longer supported" infobar on Windows 7.
      
      R=asvitkine@chromium.org, robliao@chromium.org, wfh@chromium.org, nick@chromium.org
      BUG=581499
      
      Review URL: https://codereview.chromium.org/1784623003
      
      Cr-Commit-Position: refs/heads/master@{#380793}
      d68b1e1c
  9. 10 Mar, 2016 1 commit
  10. 09 Mar, 2016 1 commit
    • primiano's avatar
      Allocator shim skeleton + Linux impl behind a build flag · 4e68ed2d
      primiano authored
      TL;DR
      -----
      This CL introduces the skeleton for the unified allocator shim and
      an actual working implementation for Linux.
      The Linux implementation is really just taking the headers that today
      define the malloc symbols in tcmalloc and copying them to base.
      All the changes introduced are conditioned behind the build-time flag
      use_experimental_allocator_shim, which is disabled by default.
      
      Background Context
      ------------------
      There are two reasons why we want to intercept allocations in Chrome:
      1) To enforce some security properties (suicide on malloc failure via
         std::new_handler, preventing allocations > 2GB which can trigger
         signed vs. unsigned bugs in third_party libraries).
      2) For diagnostic purposes (heap profiling).
      
      Today (before this CL) allocation calls are already intercepted in
      most Chrome platforms, but that happens in a disorganized and
      inconsistent fashion. More in details:
      On Linux: TCMalloc redefines the malloc()/new() symbols and we added
        code to the internal fork of tcmalloc to achieve 1).
      On Mac: we inject our hooks in the default malloc zone in
        EnableTerminationOnOutOfMemory() (memory_mac.mm)
      On Windows: we strip the malloc symbols out of libcmt and re-define
        them in allocator_shim_win.cc
      On Android: we don't have 1)
      
      The purpose of this work is to refactor and uniform this.
      The goal is to have all the OS call into a single module (herein
      allocator_shim.h) which performs 1) in base (as opposite to forking
      allocator-specific code) and which offers a uniform interface for 2).
      
      Why is this good?
      -----------------
      - Makes the allocator code more readable.
      - Allows to unfork code from tcmalloc.
      - Allows to design a more maintainable heap profiler, which shares
        the same code paths of the security enforcement layer.
      
      Notes about execution
      ---------------------
      Essentially on each platform we need to do three things:
       - Dismantle the code that defines the malloc()/new symbols.
       - Let the malloc()/new symbols route through the shim.
       - Have the shim ultimately invoke the actual allocator (tcmalloc,
         winheap, system allocator) as defined by the build config.
      This clearly cannot happen atomically in one CL.
      The plan, therefore, is to make the above happen behind a build-time
      flag (use_experimental_allocator_shim), so the shim can be easily
      tested / rolled-back in case of failures, and ultimately drop the
      build-time flag (and remove the dead cde) once everything works.
      This also will make dealing with reverts very manageable.
      
      Therefore this CL (and likely all the future ones) is meant to be
      a no-op until use_experimental_allocator_shim==true.
      
      Design doc: bit.ly/allocator-shim
      
      BUG=550886
      TEST=build with use_experimental_allocator_shim=true, base_unittests --gtest_filter=AllocatorShimTest.*
      
      Review URL: https://codereview.chromium.org/1675143004
      
      Cr-Commit-Position: refs/heads/master@{#380196}
      4e68ed2d
  11. 05 Mar, 2016 1 commit
    • tzik's avatar
      Retire scoped_ptr_unittest.nc · 13fb9a28
      tzik authored
      scoped_ptr<> is now an alias of std::unique_ptr<> on Linux. So on Linux,
      the test is no longer needed in Chromium. Since no one seems to care the
      test on the other OSes than Linux, it's time to drop it.
      
      BUG=554298
      
      Review URL: https://codereview.chromium.org/1765833002
      
      Cr-Commit-Position: refs/heads/master@{#379454}
      13fb9a28
  12. 04 Mar, 2016 1 commit
  13. 19 Feb, 2016 2 commits
    • mikecase's avatar
      Put generated non-test Java runner scripts into bin/. · 4868bb07
      mikecase authored
      Previous CL moved these scripts into bin/helper/ because lots of
      these scripts are not meant to be directly run by developers (they
      are run by other scripts such as
      build/android/pylib/junit/test_runner.py). Moving these scripts
      back directly into bin/ because this move caused an issue with
      incremental builds.
      
      BUG=
      TBR=pauljensen@chromium.org
      
      Review URL: https://codereview.chromium.org/1708383002
      
      Cr-Commit-Position: refs/heads/master@{#376527}
      4868bb07
    • erikchen's avatar
      base: Create file mappings with reduced access control permissions. · 4b12c0a1
      erikchen authored
      A newly created file mapping has two sets of permissions. It has access control
      permissions (WRITE_DAC, WRITE_OWNER, READ_CONTROL, and DELETE) and file
      permissions (FILE_MAP_READ, FILE_MAP_WRITE, etc.). ::DuplicateHandle() with the
      parameter DUPLICATE_SAME_ACCESS copies both sets of permissions.
      
      The Chrome sandbox prevents HANDLEs with the WRITE_DAC permission from being
      duplicated into unprivileged processes. But the only way to copy file
      permissions is with the parameter DUPLICATE_SAME_ACCESS. This means that there
      is no way for a privileged process to duplicate a file mapping into an
      unprivileged process while maintaining the previous file permissions.
      
      This CL removes all access control permissions of a file mapping immediately
      after creation, which effectively means that ::DuplicateHandle() only copies
      the file permissions.
      
      These permissions are only enforced if the file mapping has a name, so this
      CL also gives all file mappings a name.
      
      BUG=493414
      
      Review URL: https://codereview.chromium.org/1677163003
      
      Cr-Commit-Position: refs/heads/master@{#376358}
      4b12c0a1
  14. 16 Feb, 2016 3 commits
  15. 12 Feb, 2016 1 commit
    • zforman's avatar
      Makes GetBuildTime behave sanely on all build types. · 08d91b75
      zforman authored
      After discussion with maruel and agl, it seems that
      (1) for the purposes of build determinism, it's necessary
          to be able to arbitrarily set the build time.
      (2) for the purposes of continuous integration, longer duration
          between cache invalidation is better, but >=1mo is preferable.
      (3) for security purposes, timebombs would ideally be as close to
          the actual time of the build as possible. It must be in the past.
      (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
          HTST pinning, <=1mo is preferable.
      
      All of these can reasonably be satisfied by using different settings for CI
      versus official builds:
      - For official build, the build time is set to 5:00am of the day of the build or
        the day before.
      - For continuous integration build, the build time is set to the current month.
        If the current day is within the first week of the month and last Sunday
        wasn't part of the current month, the Sunday of the previous month is used.
        This results that cache invalidation happens on a Sunday, which is preferable
        from an infrastructure standpoint.
      - In the case that the build time needs to be set to a specific value (i.e. to
        reproduce a build), the GN/GYP variable 'override_build_date' can be used to
        set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
      
      The way it is done is:
      - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
        value depends on if an official build is done or not.
      - This step depends on build/util/LASTCHANGE so it is run at every sync. The
        file is only touched if the content changed to not affect null build.
      
      Most importantly, this change removes the need of both GN/GYP variable
      "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
      is always deterministic (up to a month) by default. This removes the risk
      oversight of forgetting to set this variable, which already happened.
      
      R=maruel@chromium.org
      BUG=489490
      
      Review URL: https://codereview.chromium.org/1641413002
      
      Cr-Commit-Position: refs/heads/master@{#375136}
      08d91b75
  16. 06 Feb, 2016 1 commit
  17. 02 Feb, 2016 1 commit
  18. 30 Jan, 2016 3 commits
    • brettw's avatar
      Move base/prefs to components/prefs · 58cd1f12
      brettw authored
      This change is the minimal move change. It does not update namespaces or includes. Forwarding headers and targets exist to map to the new location. The namespaces, include guards, and references to these files will be updated in follow-ups.
      
      The GYP build has been updated to point to the new location because the forwarding headers generated a .gyp file cycle. Avoiding a cycle with libaddressinput is why prefs is a separate .gyp from most of the rest of the components. The GN build uses forwarding targets to keep the change smaller.
      
      The json pref store unit tests had to be updated because of the way that they used histograms conflicted with the hsitogram setup of the components unittests. Fortunately, there's a HistogramTester helper for this case, so this patch uses it in for the moved test in place of manually checking histogram counts.
      
      json_pref_store_unittests.cc also depended on the files il base/test/data/prefs. Rather than worry about updating all the isolates and such, this just adds the data inline and avoids having separate test files.
      
      Reland of http://crrev.com/1648403002 with iOS fix
      TBR=jam@chromium.org
      
      Review URL: https://codereview.chromium.org/1653693002
      
      Cr-Commit-Position: refs/heads/master@{#372536}
      58cd1f12
    • joedow's avatar
      Revert of Move base/prefs to components/prefs (patchset #7 id:120001 of... · b48cea96
      joedow authored
      Revert of Move base/prefs to components/prefs (patchset #7 id:120001 of https://codereview.chromium.org/1648403002/ )
      
      Reason for revert:
      Reverting due to failure on iOS builder:
      https://build.chromium.org/p/chromium.mac/builders/iOS_Device_%28ninja%29/builds/38425/steps/steps/logs/stdio
      
      Original issue's description:
      > Move base/prefs to components/prefs
      >
      > This change is the minimal move change. It does not update namespaces or includes. Forwarding headers and targets exist to map to the new location. The namespaces, include guards, and references to these files will be updated in follow-ups.
      >
      > The GYP build has been updated to point to the new location because the forwarding headers generated a .gyp file cycle. Avoiding a cycle with libaddressinput is why prefs is a separate .gyp from most of the rest of the components. The GN build uses forwarding targets to keep the change smaller.
      >
      > The json pref store unit tests had to be updated because of the way that they used histograms conflicted with the hsitogram setup of the components unittests. Fortunately, there's a HistogramTester helper for this case, so this patch uses it in for the moved test in place of manually checking histogram counts.
      >
      > json_pref_store_unittests.cc also depended on the files il base/test/data/prefs. Rather than worry about updating all the isolates and such, this just adds the data inline and avoids having separate test files.
      >
      > BUG=
      >
      > Committed: https://crrev.com/deb824cd36c02a93854537d70e1853cb9f1c55b9
      > Cr-Commit-Position: refs/heads/master@{#372494}
      
      TBR=jam@chromium.org,brettw@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1645073005
      
      Cr-Commit-Position: refs/heads/master@{#372499}
      b48cea96
    • brettw's avatar
      Move base/prefs to components/prefs · deb824cd
      brettw authored
      This change is the minimal move change. It does not update namespaces or includes. Forwarding headers and targets exist to map to the new location. The namespaces, include guards, and references to these files will be updated in follow-ups.
      
      The GYP build has been updated to point to the new location because the forwarding headers generated a .gyp file cycle. Avoiding a cycle with libaddressinput is why prefs is a separate .gyp from most of the rest of the components. The GN build uses forwarding targets to keep the change smaller.
      
      The json pref store unit tests had to be updated because of the way that they used histograms conflicted with the hsitogram setup of the components unittests. Fortunately, there's a HistogramTester helper for this case, so this patch uses it in for the moved test in place of manually checking histogram counts.
      
      json_pref_store_unittests.cc also depended on the files il base/test/data/prefs. Rather than worry about updating all the isolates and such, this just adds the data inline and avoids having separate test files.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1648403002
      
      Cr-Commit-Position: refs/heads/master@{#372494}
      deb824cd
  19. 21 Jan, 2016 1 commit
    • primiano's avatar
      Reland (2) of: Allow base to depend on allocator · e97b9201
      primiano authored
      Reason for reland:
      Some targets (clearkeycdmadapter, osmesa) now fell in the state where
      they depend indirectly on base (which causes the removal of the default
      clib) but via a shared_library boundary (which does not propagate the
      replacement allocator / shim layer code).
      Fixing those targets by adding a direct base dependency.
      
      This causes a breakage in the main waterfall:
      https://build.chromium.org/p/chromium.win/builders/Win%20x64%20GN/builds/10231
      
      Original CL description:
      > A smaller, yet key, step to move
      >
      > From: a situation where mainly executables (but not really) depend on
      > allocator, and base needs dependencies (to tcmalloc) to be injected
      > from content (which violates the ODR in component buids).
      >
      > To: a situation where only base depends on allocator and the other
      > targets get recursively the required linked flags.
      >
      > In essence this CL is a more gradual approach to the bigger
      > unreviewable crrev.com/1528013002.
      >
      > How is the transition handled?
      > ------------------------------
      > After this CL, the situation will be as follows:
      > From a build time perspective base will also depend on allocator.
      > This will not change anything substantial in static builds and introduce
      > yet another (temporary) ODR violation in Linux component builds.
      > The big change introduced by this CL is the fact that all the executable
      > targets that depend on base (virtualy all) will also get another
      > indirect dependency to allocator.
      >
      > In other words, after this CL executable targets will depend on
      > allocator for two reasons:
      >  - Because they have an explicit dependency to it (the one I am going to
      >    get rid of in the immediate future).
      >  - Because this new transitive path I am introducing in base.
      >
      > Rationale of this approach
      > --------------------------
      > This allows to restrict the critical changes in a smaller CL easier to
      > review, at the cost of the temporary double dependency on base.
      > The good things are:
      >  - If something will break, this CL will be very easy to revert.
      >  - The next cleanups will be straightforward.
      >  - We have now smoke tests (crrev.com/1577883002) that will help us
      >    realize if something goes wrong.
      >
      > Next steps
      > ----------
      > In the next CLs I will:
      >  - Remove the content -> base injection layer, and let base directly use
      >    the tcmalloc functions it needs.
      >  - Remove all the traces of USE_TCMALLOC outside of base.
      >  - Start cleaning up the hundreds use_allocator conditionals in the gyp
      >    files in a way which is easier to review and produce zero ninja diffs
      >    (see crrev.com/1583973002 as an example)
      >
      > Ninja diffs caused by this change
      > ---------------------------------
      >  ### Win, static build, GN:   https://paste.ee/p/hvcRp
      >  The missing targets (mostly tests) that previously were
      >  not depending on allocator, now get that by virtue of the transitive
      >  dependency.
      >
      >  ### Win, static build, GYP:  https://paste.ee/p/AGuKR
      >  As above. Just GYP seems to emit the ninja files in a different,
      >  inlined, format.
      >
      >  ### linux static build, GYP:  https://paste.ee/p/kmD7U
      >  As above. Plus the new targets also get the -Wl,-u (keep symbol)
      >  args as expected by allocator.gyp for the tcmalloc heap profiler.
      >
      >  ### linux shared build, GYP: https://paste.ee/p/FHHNR
      >  Nothing relevant. Just I moved the dependency to allocator from
      >  base_unittests to base, and that is the only thing that reflects in the
      >  ninja files.
      >
      > BUG=564618
      
      TBR=wfh@chromium.org,brettw@chromium.org,kbr@chromium.org
      BUG=564618
      
      Review URL: https://codereview.chromium.org/1616793003
      
      Cr-Commit-Position: refs/heads/master@{#370694}
      e97b9201
  20. 20 Jan, 2016 5 commits
    • primiano's avatar
      Revert of Reland of: Allow base to depend on allocator (patchset #2 id:20001... · d1cb127a
      primiano authored
      Revert of Reland of: Allow base to depend on allocator (patchset #2 id:20001 of https://codereview.chromium.org/1605023004/ )
      
      Reason for revert:
      The Win bot is also broken. I give up for today.
      https://build.chromium.org/p/chromium.win/builders/Win%20x64%20GN/builds/10231/steps/compile/logs/stdio
      
      Original issue's description:
      > Reland of: Allow base to depend on allocator
      >
      > Reason for reland:
      > Fix empty gyp target edge case, that caused the breakage.
      >
      > Original CL: http://crrev.com/1584893002
      > Revert CL: http://crrev.com/1610673002
      > Breakage: https://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/35574
      >
      > Original CL description:
      > > A smaller, yet key, step to move
      > >
      > > From: a situation where mainly executables (but not really) depend on
      > > allocator, and base needs dependencies (to tcmalloc) to be injected
      > > from content (which violates the ODR in component buids).
      > >
      > > To: a situation where only base depends on allocator and the other
      > > targets get recursively the required linked flags.
      > >
      > > In essence this CL is a more gradual approach to the bigger
      > > unreviewable crrev.com/1528013002.
      > >
      > > How is the transition handled?
      > > ------------------------------
      > > After this CL, the situation will be as follows:
      > > From a build time perspective base will also depend on allocator.
      > > This will not change anything substantial in static builds and introduce
      > > yet another (temporary) ODR violation in Linux component builds.
      > > The big change introduced by this CL is the fact that all the executable
      > > targets that depend on base (virtualy all) will also get another
      > > indirect dependency to allocator.
      > >
      > > In other words, after this CL executable targets will depend on
      > > allocator for two reasons:
      > >  - Because they have an explicit dependency to it (the one I am going to
      > >    get rid of in the immediate future).
      > >  - Because this new transitive path I am introducing in base.
      > >
      > > Rationale of this approach
      > > --------------------------
      > > This allows to restrict the critical changes in a smaller CL easier to
      > > review, at the cost of the temporary double dependency on base.
      > > The good things are:
      > >  - If something will break, this CL will be very easy to revert.
      > >  - The next cleanups will be straightforward.
      > >  - We have now smoke tests (crrev.com/1577883002) that will help us
      > >    realize if something goes wrong.
      > >
      > > Next steps
      > > ----------
      > > In the next CLs I will:
      > >  - Remove the content -> base injection layer, and let base directly use
      > >    the tcmalloc functions it needs.
      > >  - Remove all the traces of USE_TCMALLOC outside of base.
      > >  - Start cleaning up the hundreds use_allocator conditionals in the gyp
      > >    files in a way which is easier to review and produce zero ninja diffs
      > >    (see crrev.com/1583973002 as an example)
      > >
      > > Ninja diffs caused by this change
      > > ---------------------------------
      > >  ### Win, static build, GN:   https://paste.ee/p/hvcRp
      > >  The missing targets (mostly tests) that previously were
      > >  not depending on allocator, now get that by virtue of the transitive
      > >  dependency.
      > >
      > >  ### Win, static build, GYP:  https://paste.ee/p/AGuKR
      > >  As above. Just GYP seems to emit the ninja files in a different,
      > >  inlined, format.
      > >
      > >  ### linux static build, GYP:  https://paste.ee/p/kmD7U
      > >  As above. Plus the new targets also get the -Wl,-u (keep symbol)
      > >  args as expected by allocator.gyp for the tcmalloc heap profiler.
      > >
      > >  ### linux shared build, GYP: https://paste.ee/p/FHHNR
      > >  Nothing relevant. Just I moved the dependency to allocator from
      > >  base_unittests to base, and that is the only thing that reflects in the
      > >  ninja files.
      > >
      > > BUG=564618
      >
      > TBR=wfh@chromium.org,brettw@chromium.org
      > BUG=564618
      >
      > Committed: https://crrev.com/717238e9faac7bdd5a7a63fffdcee77e93d48e1f
      > Cr-Commit-Position: refs/heads/master@{#370438}
      
      TBR=thakis@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=564618
      
      Review URL: https://codereview.chromium.org/1606393002
      
      Cr-Commit-Position: refs/heads/master@{#370441}
      d1cb127a
    • primiano's avatar
      Reland of: Allow base to depend on allocator · 717238e9
      primiano authored
      Reason for reland:
      Fix empty gyp target edge case, that caused the breakage.
      
      Original CL: http://crrev.com/1584893002
      Revert CL: http://crrev.com/1610673002
      Breakage: https://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/35574
      
      Original CL description:
      > A smaller, yet key, step to move
      >
      > From: a situation where mainly executables (but not really) depend on
      > allocator, and base needs dependencies (to tcmalloc) to be injected
      > from content (which violates the ODR in component buids).
      >
      > To: a situation where only base depends on allocator and the other
      > targets get recursively the required linked flags.
      >
      > In essence this CL is a more gradual approach to the bigger
      > unreviewable crrev.com/1528013002.
      >
      > How is the transition handled?
      > ------------------------------
      > After this CL, the situation will be as follows:
      > From a build time perspective base will also depend on allocator.
      > This will not change anything substantial in static builds and introduce
      > yet another (temporary) ODR violation in Linux component builds.
      > The big change introduced by this CL is the fact that all the executable
      > targets that depend on base (virtualy all) will also get another
      > indirect dependency to allocator.
      >
      > In other words, after this CL executable targets will depend on
      > allocator for two reasons:
      >  - Because they have an explicit dependency to it (the one I am going to
      >    get rid of in the immediate future).
      >  - Because this new transitive path I am introducing in base.
      >
      > Rationale of this approach
      > --------------------------
      > This allows to restrict the critical changes in a smaller CL easier to
      > review, at the cost of the temporary double dependency on base.
      > The good things are:
      >  - If something will break, this CL will be very easy to revert.
      >  - The next cleanups will be straightforward.
      >  - We have now smoke tests (crrev.com/1577883002) that will help us
      >    realize if something goes wrong.
      >
      > Next steps
      > ----------
      > In the next CLs I will:
      >  - Remove the content -> base injection layer, and let base directly use
      >    the tcmalloc functions it needs.
      >  - Remove all the traces of USE_TCMALLOC outside of base.
      >  - Start cleaning up the hundreds use_allocator conditionals in the gyp
      >    files in a way which is easier to review and produce zero ninja diffs
      >    (see crrev.com/1583973002 as an example)
      >
      > Ninja diffs caused by this change
      > ---------------------------------
      >  ### Win, static build, GN:   https://paste.ee/p/hvcRp
      >  The missing targets (mostly tests) that previously were
      >  not depending on allocator, now get that by virtue of the transitive
      >  dependency.
      >
      >  ### Win, static build, GYP:  https://paste.ee/p/AGuKR
      >  As above. Just GYP seems to emit the ninja files in a different,
      >  inlined, format.
      >
      >  ### linux static build, GYP:  https://paste.ee/p/kmD7U
      >  As above. Plus the new targets also get the -Wl,-u (keep symbol)
      >  args as expected by allocator.gyp for the tcmalloc heap profiler.
      >
      >  ### linux shared build, GYP: https://paste.ee/p/FHHNR
      >  Nothing relevant. Just I moved the dependency to allocator from
      >  base_unittests to base, and that is the only thing that reflects in the
      >  ninja files.
      >
      > BUG=564618
      
      TBR=wfh@chromium.org,brettw@chromium.org
      BUG=564618
      
      Review URL: https://codereview.chromium.org/1605023004
      
      Cr-Commit-Position: refs/heads/master@{#370438}
      717238e9
    • robert.bradford's avatar
      Revert of Allow base to depend on allocator (patchset #3 id:60001 of... · 1dffe63d
      robert.bradford authored
      Revert of Allow base to depend on allocator (patchset #3 id:60001 of https://codereview.chromium.org/1584893002/ )
      
      Reason for revert:
      Made the tree go red - build failure on iOS_Device: https://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/35574
      
      Original issue's description:
      > Allow base to depend on allocator
      >
      > A smaller, yet key, step to move
      >
      > From: a situation where mainly executables (but not really) depend on
      > allocator, and base needs dependencies (to tcmalloc) to be injected
      > from content (which violates the ODR in component buids).
      >
      > To: a situation where only base depends on allocator and the other
      > targets get recursively the required linked flags.
      >
      > In essence this CL is a more gradual approach to the bigger
      > unreviewable crrev.com/1528013002.
      >
      > How is the transition handled?
      > ------------------------------
      > After this CL, the situation will be as follows:
      > From a build time perspective base will also depend on allocator.
      > This will not change anything substantial in static builds and introduce
      > yet another (temporary) ODR violation in Linux component builds.
      > The big change introduced by this CL is the fact that all the executable
      > targets that depend on base (virtualy all) will also get another
      > indirect dependency to allocator.
      >
      > In other words, after this CL executable targets will depend on
      > allocator for two reasons:
      >  - Because they have an explicit dependency to it (the one I am going to
      >    get rid of in the immediate future).
      >  - Because this new transitive path I am introducing in base.
      >
      > Rationale of this approach
      > --------------------------
      > This allows to restrict the critical changes in a smaller CL easier to
      > review, at the cost of the temporary double dependency on base.
      > The good things are:
      >  - If something will break, this CL will be very easy to revert.
      >  - The next cleanups will be straightforward.
      >  - We have now smoke tests (crrev.com/1577883002) that will help us
      >    realize if something goes wrong.
      >
      > Next steps
      > ----------
      > In the next CLs I will:
      >  - Remove the content -> base injection layer, and let base directly use
      >    the tcmalloc functions it needs.
      >  - Remove all the traces of USE_TCMALLOC outside of base.
      >  - Start cleaning up the hundreds use_allocator conditionals in the gyp
      >    files in a way which is easier to review and produce zero ninja diffs
      >    (see crrev.com/1583973002 as an example)
      >
      > Ninja diffs caused by this change
      > ---------------------------------
      >  ### Win, static build, GN:   https://paste.ee/p/hvcRp
      >  The missing targets (mostly tests) that previously were
      >  not depending on allocator, now get that by virtue of the transitive
      >  dependency.
      >
      >  ### Win, static build, GYP:  https://paste.ee/p/AGuKR
      >  As above. Just GYP seems to emit the ninja files in a different,
      >  inlined, format.
      >
      >  ### linux static build, GYP:  https://paste.ee/p/kmD7U
      >  As above. Plus the new targets also get the -Wl,-u (keep symbol)
      >  args as expected by allocator.gyp for the tcmalloc heap profiler.
      >
      >  ### linux shared build, GYP: https://paste.ee/p/FHHNR
      >  Nothing relevant. Just I moved the dependency to allocator from
      >  base_unittests to base, and that is the only thing that reflects in the
      >  ninja files.
      >
      > BUG=564618
      >
      > Committed: https://crrev.com/58e5f8b23a68e6a87d89e87c6d9e6bef2c265ecd
      > Cr-Commit-Position: refs/heads/master@{#370405}
      
      TBR=wfh@chromium.org,thakis@chromium.org,brettw@chromium.org,primiano@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=564618
      
      Review URL: https://codereview.chromium.org/1610673002
      
      Cr-Commit-Position: refs/heads/master@{#370407}
      1dffe63d
    • primiano's avatar
      Allow base to depend on allocator · 58e5f8b2
      primiano authored
      A smaller, yet key, step to move
      
      From: a situation where mainly executables (but not really) depend on
      allocator, and base needs dependencies (to tcmalloc) to be injected
      from content (which violates the ODR in component buids).
      
      To: a situation where only base depends on allocator and the other
      targets get recursively the required linked flags.
      
      In essence this CL is a more gradual approach to the bigger
      unreviewable crrev.com/1528013002.
      
      How is the transition handled?
      ------------------------------
      After this CL, the situation will be as follows:
      From a build time perspective base will also depend on allocator.
      This will not change anything substantial in static builds and introduce
      yet another (temporary) ODR violation in Linux component builds.
      The big change introduced by this CL is the fact that all the executable
      targets that depend on base (virtualy all) will also get another
      indirect dependency to allocator.
      
      In other words, after this CL executable targets will depend on
      allocator for two reasons:
       - Because they have an explicit dependency to it (the one I am going to
         get rid of in the immediate future).
       - Because this new transitive path I am introducing in base.
      
      Rationale of this approach
      --------------------------
      This allows to restrict the critical changes in a smaller CL easier to
      review, at the cost of the temporary double dependency on base.
      The good things are:
       - If something will break, this CL will be very easy to revert.
       - The next cleanups will be straightforward.
       - We have now smoke tests (crrev.com/1577883002) that will help us
         realize if something goes wrong.
      
      Next steps
      ----------
      In the next CLs I will:
       - Remove the content -> base injection layer, and let base directly use
         the tcmalloc functions it needs.
       - Remove all the traces of USE_TCMALLOC outside of base.
       - Start cleaning up the hundreds use_allocator conditionals in the gyp
         files in a way which is easier to review and produce zero ninja diffs
         (see crrev.com/1583973002 as an example)
      
      Ninja diffs caused by this change
      ---------------------------------
       ### Win, static build, GN:   https://paste.ee/p/hvcRp
       The missing targets (mostly tests) that previously were
       not depending on allocator, now get that by virtue of the transitive
       dependency.
      
       ### Win, static build, GYP:  https://paste.ee/p/AGuKR
       As above. Just GYP seems to emit the ninja files in a different,
       inlined, format.
      
       ### linux static build, GYP:  https://paste.ee/p/kmD7U
       As above. Plus the new targets also get the -Wl,-u (keep symbol)
       args as expected by allocator.gyp for the tcmalloc heap profiler.
      
       ### linux shared build, GYP: https://paste.ee/p/FHHNR
       Nothing relevant. Just I moved the dependency to allocator from
       base_unittests to base, and that is the only thing that reflects in the
       ninja files.
      
      BUG=564618
      
      Review URL: https://codereview.chromium.org/1584893002
      
      Cr-Commit-Position: refs/heads/master@{#370405}
      58e5f8b2
    • bcwhite's avatar
      Create "persistent memory allocator" for persisting and sharing objects. · 34ae4983
      bcwhite authored
      This allocator reserves memory within a specific block that itself can
      be persisted and/or shared between processes by various means.
      
      It is lock-free for operation on all platforms (even Android which
      does not support inter-process locks) and self-checking to deal
      with security concerns where not all processes accessing the memory
      are fully trustworthy.
      
      BUG=546019
      
      Review URL: https://codereview.chromium.org/1410213004
      
      Cr-Commit-Position: refs/heads/master@{#370377}
      34ae4983
  21. 16 Jan, 2016 1 commit
  22. 15 Jan, 2016 4 commits
    • jbudorick's avatar
      Revert of [Android] Rework multidex and enable multidex for unit_tests_apk.... · 1c4276c2
      jbudorick authored
      Revert of [Android] Rework multidex and enable multidex for unit_tests_apk. (RELAND) (patchset #2 id:20001 of https://codereview.chromium.org/1590243003/ )
      
      Reason for revert:
      mysterious compile errors on Android appeared two builds after this landed.
      
      https://build.chromium.org/p/chromium/builders/Android/builds/50690
      
      Original issue's description:
      > [Android] Rework multidex and enable multidex for unit_tests_apk. (RELAND)
      >
      > This is a reland of https://codereview.chromium.org/1581563003
      >
      > BUG=272790
      > TBR=thakis@chromium.org,yfriedman@chromium.org,phajdan.jr@chromium.org
      >
      > Committed: https://crrev.com/ab450c5ede0635194331286088d0f488f4086ba5
      > Cr-Commit-Position: refs/heads/master@{#369815}
      
      TBR=agrieve@chromium.org,thakis@chromium.org,yfriedman@chromium.org,phajdan.jr@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=272790
      
      Review URL: https://codereview.chromium.org/1587673014
      
      Cr-Commit-Position: refs/heads/master@{#369864}
      1c4276c2
    • jbudorick's avatar
      [Android] Rework multidex and enable multidex for unit_tests_apk. (RELAND) · ab450c5e
      jbudorick authored
      This is a reland of https://codereview.chromium.org/1581563003
      
      BUG=272790
      TBR=thakis@chromium.org,yfriedman@chromium.org,phajdan.jr@chromium.org
      
      Review URL: https://codereview.chromium.org/1590243003
      
      Cr-Commit-Position: refs/heads/master@{#369815}
      ab450c5e
    • vasilii's avatar
      Revert of [Android] Rework multidex and enable multidex for unit_tests_apk.... · ac74e7a7
      vasilii authored
      Revert of [Android] Rework multidex and enable multidex for unit_tests_apk. (patchset #7 id:120001 of https://codereview.chromium.org/1581563003/ )
      
      Reason for revert:
      Broke compilation on Android
      
      https://build.chromium.org/p/chromium/builders/Android/builds/50665
      
      FAILED: cd ../../components; python ../build/android/gyp/apk_obfuscate.py --configuration-name Release --android-sdk /b/build/slave/Android/build/src/third_party/android_tools/sdk//platforms/android-23 --android-sdk-tools /b/build/slave/Android/build/src/third_party/android_tools/sdk//build-tools/23.0.1 --android-sdk-jar /b/build/slave/Android/build/src/third_party/android_tools/sdk//platforms/android-23/android.jar "--input-jars-paths=/b/build/slave/Android/build/src/third_party/android_tools/sdk//extras/android/support/multidex/library/libs/android-support-multidex.jar \"../out/Release/lib.java/jsr_305_javalib.jar\" \"../out/Release/lib.java/base_java.jar\" /b/build/slave/Android/build/src/third_party/android_tools/sdk//extras/android/support/annotations/android-support-annotations.jar \"../out/Release/lib.java/cronet_api.jar\" \"../out/Release/lib.java/url_java.jar\" \"../out/Release/lib.java/net_java.jar\" \"../out/Release/lib.java/cronet_java.jar\" \"../out/Release/lib.java/chromium_apk_cronet_perf_test_apk.jar\"" "--proguard-configs=cronet/android/proguard.cfg \"../out/Release/cronet_perf_test_apk/proguard.txt\"" --test-jar-path ../out/Release/test.lib.java/CronetPerfTest.jar --obfuscated-jar-path ../out/Release/cronet_perf_test_apk/obfuscated.jar --proguard-jar-path ../third_party/proguard/lib/proguard.jar --stamp ../out/Release/cronet_perf_test_apk/obfuscate.stamp --testapp --proguard-enabled
      Traceback (most recent call last):
        File "../build/android/gyp/apk_obfuscate.py", line 185, in <module>
          sys.exit(main(sys.argv[1:]))
        File "../build/android/gyp/apk_obfuscate.py", line 167, in main
          DoProguard(options)
        File "../build/android/gyp/apk_obfuscate.py", line 124, in DoProguard
          proguard.CheckOutput()
        File "/b/build/slave/Android/build/src/build/android/gyp/util/proguard_util.py", line 180, in CheckOutput
          stderr_filter=stderr_filter)
        File "/b/build/slave/Android/build/src/build/android/gyp/util/build_utils.py", line 162, in CheckOutput
          raise CalledProcessError(cwd, args, stdout + stderr)
      util.build_utils.CalledProcessError: Command failed: ( cd /b/build/slave/Android/build/src/components; java -jar ../third_party/proguard/lib/proguard.jar -forceprocessing -libraryjars /b/build/slave/Android/build/src/third_party/android_tools/sdk//platforms/android-23/android.jar -injars /b/build/slave/Android/build/src/third_party/android_tools/sdk//extras/android/support/multidex/library/libs/android-support-multidex.jar:../out/Release/lib.java/jsr_305_javalib.jar:../out/Release/lib.java/base_java.jar:/b/build/slave/Android/build/src/third_party/android_tools/sdk//extras/android/support/annotations/android-support-annotations.jar:../out/Release/lib.java/cronet_api.jar:../out/Release/lib.java/url_java.jar:../out/Release/lib.java/net_java.jar:../out/Release/lib.java/cronet_java.jar:../out/Release/lib.java/chromium_apk_cronet_perf_test_apk.jar -include cronet/android/proguard.cfg -include ../out/Release/cronet_perf_test_apk/proguard.txt -outjars ../out/Release/cronet_perf_test_apk/obfuscated.jar -dump ../out/Release/cronet_perf_test_apk/obfuscated.jar.dump -printseeds ../out/Release/cronet_perf_test_apk/obfuscated.jar.seeds -printusage ../out/Release/cronet_perf_test_apk/obfuscated.jar.usage -printmapping ../out/Release/cronet_perf_test_apk/obfuscated.jar.mapping )
      Warning: org.chromium.base.multidex.ChromiumMultiDexInstaller: can't find referenced class org.chromium.base.multidex.ChromiumMultiDex
      Warning: org.chromium.base.multidex.ChromiumMultiDexInstaller: can't find referenced class org.chromium.base.multidex.ChromiumMultiDex
      Warning: there were 2 unresolved references to classes or interfaces.
               You may need to specify additional library jars (using '-libraryjars').
      Error: Please correct the above warnings first.
      
      Original issue's description:
      > [Android] Rework multidex and enable multidex for unit_tests_apk.
      >
      > This allows multidex to be used in release builds.
      >
      > BUG=272790
      >
      > Committed: https://crrev.com/f743bef34d49987c0f1f69e2f0bb6cb8beb03bf5
      > Cr-Commit-Position: refs/heads/master@{#369715}
      
      TBR=phajdan.jr@chromium.org,agrieve@chromium.org,dpranke@chromium.org,thakis@chromium.org,yfriedman@chromium.org,jbudorick@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=272790
      
      Review URL: https://codereview.chromium.org/1587253003
      
      Cr-Commit-Position: refs/heads/master@{#369717}
      ac74e7a7
    • jbudorick's avatar
      [Android] Rework multidex and enable multidex for unit_tests_apk. · f743bef3
      jbudorick authored
      This allows multidex to be used in release builds.
      
      BUG=272790
      
      Review URL: https://codereview.chromium.org/1581563003
      
      Cr-Commit-Position: refs/heads/master@{#369715}
      f743bef3
  23. 21 Dec, 2015 1 commit
  24. 19 Dec, 2015 1 commit
    • tfarina's avatar
      move libevent into base · c7ebe6da
      tfarina authored
      This simplifies the process of bootstrapping gn standalone.
      
      And libevent is not really used outside of base. base is actually its only client.
      
      BUG=569352
      TEST=See CL for details for how to reproduce this.
      R=thestig@chromium.org
      TBR=cpu@chromium.org
      
      Review URL: https://codereview.chromium.org/1531573008
      
      Cr-Commit-Position: refs/heads/master@{#366282}
      c7ebe6da
  25. 15 Dec, 2015 1 commit