Add code to fetch the windows type along its version to base.

BUG=none
TEST=none

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239507 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Fix compiler errors when using CBU16_{LEAD,TRAIL} from base/third_party/icu/icu_utf.h.

These macros referenced type UChar which is not defined in base_icu. Define a
type for it in the base_icu:: namespace.

R=brettw@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239652 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revert 239423 since it breaks base_unittests in linux, cros, mac valgrind bots.

"""
> Make gtest always use simple internal regex engine.
> 
> In order to allow regex matches in gtest to be shared between Windows and other
> systems, we tell gtest to always use it's internal engine.
> 
> The syntax supported by the internal engine initially looks like a subset of
> POSIX regexs. However character class shortcuts are not valid POSIX.
> 
> Even more confusingly the system POSIX regex function often defines extra
> features not actually part of the standard allowing regex that work on Linux
> fail on Mac OS X.
> 
> A search through the code base did not reveal any locations where features not
> supported by the internal regex engine where used.
> 
> See bug https://code.google.com/p/chromium/issues/detail?id=317224 for more detailed description.
> 
> BUG=317224
> 
> Review URL: https://codereview.chromium.org/55983002

TBR=mithro@mithis.com

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239679 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
linux_aura: Move parallel_jobs_ override to base/.

The ui_unittests and views_unittests did not use the content layer, so
they were still flaky.

BUG=326701

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239680 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The comment in base64.h implies that base::Base64Encode() can return false, but
this cannot happen in practice. Fix the comment.

The implementation of Base64Encode() attempts to check for the return value
MODP_B64_ERROR as a failure, but modp_b64_encode() cannot return this
value. Remove the check.

Remove unneeded integer cast.

Change the return type to void.

BUG=323357
TEST=base_unittests, compile all
TBR=jochen@chromium.org,miket@chromium.org,joi@chromium.org,akalin@chromium.org,sergeyu@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239759 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add DiscardableMemoryAllocator to minimize use of FDs with discardable memory.                                                                                                                                                                                                                                                 

Discardable memory has the current limitation on Android (at least) that it's
backed by a file (descriptor) thus it is a limited resource.

DiscardableMemoryAllocator provides a way to create instances of
DiscardableMemory in an efficient way. Note that just like regular
DiscardableMemory, the DiscardableMemoryAllocator should not be used for small
allocations since it works with page granularity (4 KBytes).

On Android DiscardableMemory creation can now happen in two different ways:
- Each client-requested allocation is backed by an individual ashmem region.
  This allows to delete ashmem regions individually by closing the ashmem file
  descriptor. This is the default path that is taken when file descriptor usage
  allows us to do so. 
- Allocations are performed by the global allocator when file descriptor usage
  gets too high. This still allows unpinning but does not allow deleting
  individual regions (i.e.  immediately releasing the physycal pages backing
  them). Unfortunately the physical memory backing an ashmem region is only
  freed when the file descriptor is closed.
  madvise(MADV_REMOVE)/fallocate(FALLOCATE_FL_PUNCH_HOLE) don't work with
  ashmem unfortunately.

When file descriptor usage gets too high (which can be observed on
images.google.com for instance) the allocator starts operating by creating as
less ashmem regions (= consuming as less FDs) as possible:
- Large (32 MBytes) ashmem regions get lazily created. This size might need
  some tuning/runtime adjustment as a follow up. 
- Allocation works first by trying to recycle previously freed chunks  (if any)
  by doing a closest size match (implemented with multiset<>.lower_bound() in
  O(log n)).
  If no free chunks can be recycled then a new chunk in the ashmem region is
  returned to the user. If the ashmem region is not big enough then a new 
  region is created.
- DiscardableMemory instance deletion works by marking the chunk used by the 
  instance as discardable (i.e. ashmem_region_unpin()) and notifying the 
  allocator with the metadata (e.g. chunk size) that allows it to later recycle
  the chunk efficiently.
  Note that free chunks are marked as discardable as mentioned above therefore
  they can be reclaimed by the kernel under memory pressure. Since they are not 
  immediately released unfortunately the allocator still tries to minimize
  fragmentation (to avoid causing memory pressure) by merging free contiguous
  chunks when possible as well as splitting recycled free chunks that are too 
  large (and that would cause fragmentation).

BUG=299828

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239763 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revert 239763 "Add DiscardableMemoryAllocator to minimize use of..."

> Add DiscardableMemoryAllocator to minimize use of FDs with discardable memory.                                                                                                                                                                                                                                                 
> 
> Discardable memory has the current limitation on Android (at least) that it's
> backed by a file (descriptor) thus it is a limited resource.
> 
> DiscardableMemoryAllocator provides a way to create instances of
> DiscardableMemory in an efficient way. Note that just like regular
> DiscardableMemory, the DiscardableMemoryAllocator should not be used for small
> allocations since it works with page granularity (4 KBytes).
> 
> On Android DiscardableMemory creation can now happen in two different ways:
> - Each client-requested allocation is backed by an individual ashmem region.
>   This allows to delete ashmem regions individually by closing the ashmem file
>   descriptor. This is the default path that is taken when file descriptor usage
>   allows us to do so. 
> - Allocations are performed by the global allocator when file descriptor usage
>   gets too high. This still allows unpinning but does not allow deleting
>   individual regions (i.e.  immediately releasing the physycal pages backing
>   them). Unfortunately the physical memory backing an ashmem region is only
>   freed when the file descriptor is closed.
>   madvise(MADV_REMOVE)/fallocate(FALLOCATE_FL_PUNCH_HOLE) don't work with
>   ashmem unfortunately.
> 
> When file descriptor usage gets too high (which can be observed on
> images.google.com for instance) the allocator starts operating by creating as
> less ashmem regions (= consuming as less FDs) as possible:
> - Large (32 MBytes) ashmem regions get lazily created. This size might need
>   some tuning/runtime adjustment as a follow up. 
> - Allocation works first by trying to recycle previously freed chunks  (if any)
>   by doing a closest size match (implemented with multiset<>.lower_bound() in
>   O(log n)).
>   If no free chunks can be recycled then a new chunk in the ashmem region is
>   returned to the user. If the ashmem region is not big enough then a new 
>   region is created.
> - DiscardableMemory instance deletion works by marking the chunk used by the 
>   instance as discardable (i.e. ashmem_region_unpin()) and notifying the 
>   allocator with the metadata (e.g. chunk size) that allows it to later recycle
>   the chunk efficiently.
>   Note that free chunks are marked as discardable as mentioned above therefore
>   they can be reclaimed by the kernel under memory pressure. Since they are not 
>   immediately released unfortunately the allocator still tries to minimize
>   fragmentation (to avoid causing memory pressure) by merging free contiguous
>   chunks when possible as well as splitting recycled free chunks that are too 
>   large (and that would cause fragmentation).
> 
> BUG=299828
> 
> Review URL: https://codereview.chromium.org/25293002

TBR=pliard@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239779 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Stop doing unnecessary UTF-8 to UTF-16 conversions in JSONWriter.

The JSONReader only accepts UTF-8 input strings and converts \uXXXX sequences
back into UTF-8. However, the JSONWriter converts all non-ASCII characters to
UTF-16 escape sequences. This round-tripping is sub-optimal, as noted in a
TODO from r54359.

One reason for this may be that JsonDoubleQuote(), used by JSONWriter, does not
handle UTF-8 bytes correctly, interpreting them as code points and writing them
out as \u00XX sequences. If this were read back through a RFC-compliant JSON
parser, the result would be an invalid encoding error. JsonDoubleQuote() does
handle UTF-16 correctly, though.

This rewrites the base/json/string_escape.h API and fixes the above UTF-8 issue
by dividing callers up into three groups:

1. Those that pass valid UTF-8 to be escaped. Prior to this change, very few
   callers used this variant. Those that did were likely using ASCII, otherwise
   the output would be mangled due to the above issue. Now, valid UTF-8 will be
   passed through to the output unescaped. Invalid UTF-8 sequences are replaced
   with U+FFFD.

2. Those that pass valid UTF-16 to be escaped. This function now validates that
   the input is valid UTF-16, and then converts it to unescaped UTF-8 sequences
   for the output.

3. Those that pass arbitrary byte arrays as std::string and expect a non-RFC-
   compliant encoding of the binary data using \uXXXX escapes. This behavior is
   now in the EscapeBytesAsInvalidJSONString() function. It is only used by
   callers who want a "debug string" but do not expect to actually parse the
   output as valid JSON, since it is not.

Additionally, this removes the JSONWriter::OPTIONS_DO_NOT_ESCAPE flag, since
the writer can now handle UTF-8 appropriately.

BUG=15466

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239800 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Fix Java style issues in base/

BUG=320711
NOTRY=true

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239808 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
GTTF: Enable glibcxx debug mode for Debug builds by default.

This will help us catch problems earlier.

This CL actually fixes several problems detected by this mode.

BUG=65151, 267870, 267891
TEST=none
R=avi@chromium.org, jar@chromium.org, thakis@chromium.org, thestig@chromium.org, yoz@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239811 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revert "Revert 239763 "Add DiscardableMemoryAllocator to minimize use of...""

The previous attempt failed due to ASAN complaining during the
DiscardableMemory.TooLargeAllocationFails test (which is quite expected).

TBR=willchan
BUG=299828

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239816 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Fixing all Java import ordering issues.

BUG=320711
TBR=isherman@chromium.org
NOTRY=true

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239823 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revert 239759 "The comment in base64.h implies that base::Base64..."

> The comment in base64.h implies that base::Base64Encode() can return false, but
> this cannot happen in practice. Fix the comment.
> 
> The implementation of Base64Encode() attempts to check for the return value
> MODP_B64_ERROR as a failure, but modp_b64_encode() cannot return this
> value. Remove the check.
> 
> Remove unneeded integer cast.
> 
> Change the return type to void.
> 
> BUG=323357
> TEST=base_unittests, compile all
> TBR=jochen@chromium.org,miket@chromium.org,joi@chromium.org,akalin@chromium.org,sergeyu@chromium.org
> 
> Review URL: https://codereview.chromium.org/86913002

TBR=ricea@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239921 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revert 239921 "Revert 239759 "The comment in base64.h implies th..."

*****************
Reverting the revert. Congrats, the original CL wasn't the cause for the failure; sorry for the mess.
*****************


> Revert 239759 "The comment in base64.h implies that base::Base64..."
> 
> > The comment in base64.h implies that base::Base64Encode() can return false, but
> > this cannot happen in practice. Fix the comment.
> > 
> > The implementation of Base64Encode() attempts to check for the return value
> > MODP_B64_ERROR as a failure, but modp_b64_encode() cannot return this
> > value. Remove the check.
> > 
> > Remove unneeded integer cast.
> > 
> > Change the return type to void.
> > 
> > BUG=323357
> > TEST=base_unittests, compile all
> > TBR=jochen@chromium.org,miket@chromium.org,joi@chromium.org,akalin@chromium.org,sergeyu@chromium.org
> > 
> > Review URL: https://codereview.chromium.org/86913002
> 
> TBR=ricea@chromium.org
> 
> Review URL: https://codereview.chromium.org/101113004

TBR=vadimt@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@239944 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Enable tcmalloc heap-profiler module on Windows.

This CL only enables heap-profiler in static build
on Windows.

With this CL, heap-profiler does not work fully.
It outputs following information.
- memory mapped files and their address regions
- stack traces of malloc() calls


Reference CL: http://crrev.com/11415113/

BUG=159993

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@240072 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revert of https://codereview.chromium.org/100823007/
Reason for revert: This patchset breaks at least displayment of Russian localized strings on Chromeos login screen.

TBR=mark@chromium.org,jshin@chromium.org,thakis@chromium.org,asanka@chromium.org,zea@chromium.org,bauerb@chromium.org,rsesek@chromium.org
NOTREECHECKS=true
NOTRY=true

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@240082 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Disable timing from chrome://profiler on Android.

On Android, on a arm CPU, TimeTicks::Now() is taking 900ns (20 times
what it takes on a desktop x86 CPU). The bigger user of TimeTicks::Now()
is tracked_objects::TrackedTime, and this impacts the overall
performance of Chrome on this platform.

This CL adds compile line flags that allows to disable
tracked_objects::TrackedTime. It also disable
tracked_objects::TrackedTime by default on Android.

BUG=315070

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@240092 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
GTTF: Make new test launcher automatically use single process mode when debugged.

This also applies on Valgrind.

Use --test-launcher-debug-launcher to override auto-detection and debug
the launcher itself.

BUG=236893
R=sky@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@240186 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Stop doing unnecessary UTF-8 to UTF-16 conversions in JSONWriter.

The JSONReader only accepts UTF-8 input strings and converts \uXXXX sequences
back into UTF-8. However, the JSONWriter converts all non-ASCII characters to
UTF-16 escape sequences. This round-tripping is sub-optimal, as noted in a
TODO from r54359.

One reason for this may be that JsonDoubleQuote(), used by JSONWriter, does not
handle UTF-8 bytes correctly, interpreting them as code points and writing them
out as \u00XX sequences. If this were read back through a RFC-compliant JSON
parser, the result would be an invalid encoding error. JsonDoubleQuote() does
handle UTF-16 correctly, though.

This rewrites the base/json/string_escape.h API and fixes the above UTF-8 issue
by dividing callers up into three groups:

1. Those that pass valid UTF-8 to be escaped. Prior to this change, very few
   callers used this variant. Those that did were likely using ASCII, otherwise
   the output would be mangled due to the above issue. Now, valid UTF-8 will be
   passed through to the output unescaped. Invalid UTF-8 sequences are replaced
   with U+FFFD.

2. Those that pass valid UTF-16 to be escaped. This function now validates that
   the input is valid UTF-16, and then converts it to unescaped UTF-8 sequences
   for the output.

3. Those that pass arbitrary byte arrays as std::string and expect a non-RFC-
   compliant encoding of the binary data using \uXXXX escapes. This behavior is
   now in the EscapeBytesAsInvalidJSONString() function. It is only used by
   callers who want a "debug string" but do not expect to actually parse the
   output as valid JSON, since it is not.

Additionally, this removes the JSONWriter::OPTIONS_DO_NOT_ESCAPE flag, since
the writer can now handle UTF-8 appropriately.

BUG=15466

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=239800
Reverted: https://src.chromium.org/viewvc/chrome?view=rev&revision=240082

R=asanka@chromium.org, bauerb@chromium.org, mark@chromium.org, thakis@chromium.org, zea@chromium.org

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@240190 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Change "high RAM" level for iOS devices from 250 MB to 500MB.

All supported devices have at least 256MB so this change aims to keep the method relevant.

BUG=327736

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

git-svn-id: http://src.chromium.org/svn/trunk/src/base@240194 4ff67af0-8c30-449e-8e8b-ad334ec8d88c