mac: Hook up allocator shim.

mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

On macOS, there is an additional abstraction layer called malloc zones. This CL
only hooks the default malloc zone, which appears to be responsible for most
allocations. There is no good mechanism [short of interposition] to determine
when new malloc zones are added, so there's no clean mechanism of hooking all
zones. Plus we would have to rework the allocator shim abstraction.

BUG=665567

[erikchen, 2016-12-22 22:47:26]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-22 22:47:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-22 22:55:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-22 22:55:02]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[erikchen, 2016-12-23 00:13:50]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 00:14:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 00:25:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 00:25:57]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[erikchen, 2016-12-23 01:28:39]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 01:29:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 01:42:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 01:42:32]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)

[erikchen, 2016-12-23 16:46:13]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 16:46:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 16:57:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 16:57:36]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[erikchen, 2016-12-23 17:35:35]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 17:35:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 18:03:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 18:03:28]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[erikchen, 2016-12-27 17:18:57]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 17:19:03]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-27 17:31:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-27 17:31:44]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[erikchen, 2016-12-27 18:00:34]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 18:00:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-27 19:00:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-27 19:00:58]

Dry run: This issue passed the CQ dry run.

[erikchen, 2016-12-27 19:13:10]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 19:13:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-27 20:16:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-27 20:16:37]

Dry run: This issue passed the CQ dry run.

[erikchen, 2016-12-27 20:37:49]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 20:38:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[erikchen, 2016-12-27 20:40:55]

Description was changed from

==========
Test CL for allocator shim on mac.

Hook up batch free, batch malloc

patch in form 2499373003

BUG=
==========

to

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

Hook up batch free, batch malloc

patch in form 2499373003

BUG=
==========

[erikchen, 2016-12-27 20:43:30]

Description was changed from

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

Hook up batch free, batch malloc

patch in form 2499373003

BUG=
==========

to

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

Hook up batch free, batch malloc

patch in form 2499373003

BUG=
==========

[erikchen, 2016-12-27 20:44:00]

Description was changed from

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

Hook up batch free, batch malloc

patch in form 2499373003

BUG=
==========

to

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

BUG=665567
==========

[erikchen, 2016-12-27 20:46:38]

Description was changed from

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

BUG=665567
==========

to

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

On macOS, there is an additional abstraction layer called malloc zones. This CL
only hooks the default malloc zone, which appears to be responsible for most
allocations. There is no good mechanism [short of interposition] to determine
when new malloc zones are added, so there's no clean mechanism of hooking all
zones. Plus we would have to rework the allocator shim abstraction.

BUG=665567
==========

[erikchen, 2016-12-27 20:47:00]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 20:47:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-27 20:57:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-27 20:57:40]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[erikchen, 2016-12-27 21:15:31]

Description was changed from

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Change the signature of GetSizeEstimateFn to take a const void* address.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

On macOS, there is an additional abstraction layer called malloc zones. This CL
only hooks the default malloc zone, which appears to be responsible for most
allocations. There is no good mechanism [short of interposition] to determine
when new malloc zones are added, so there's no clean mechanism of hooking all
zones. Plus we would have to rework the allocator shim abstraction.

BUG=665567
==========

to

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

On macOS, there is an additional abstraction layer called malloc zones. This CL
only hooks the default malloc zone, which appears to be responsible for most
allocations. There is no good mechanism [short of interposition] to determine
when new malloc zones are added, so there's no clean mechanism of hooking all
zones. Plus we would have to rework the allocator shim abstraction.

BUG=665567
==========

[erikchen, 2016-12-27 21:15:48]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 21:16:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-27 21:20:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-27 21:20:56]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[erikchen, 2016-12-27 21:24:37]

Patchset #12 (id:220001) has been deleted

[erikchen, 2016-12-27 21:25:52]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 21:26:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-27 22:30:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-27 22:30:48]

Dry run: This issue passed the CQ dry run.

[erikchen, 2016-12-27 23:04:05]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 23:04:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[erikchen, 2016-12-27 23:15:50]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-27 23:16:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-28 00:18:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-28 00:18:52]

Dry run: This issue passed the CQ dry run.

[erikchen, 2016-12-28 17:21:27]

erikchen@chromium.org changed reviewers:
+ primiano@chromium.org

[erikchen, 2016-12-28 17:21:28]

primiano: Please review.

[Robert Sesek, 2017-01-03 19:09:06]

rsesek@chromium.org changed reviewers:
+ rsesek@chromium.org

[Robert Sesek, 2017-01-03 19:09:07]

https://codereview.chromium.org/2601573002/diff/300001/base/process/memory_ma...
File base/process/memory_mac.mm (left):

https://codereview.chromium.org/2601573002/diff/300001/base/process/memory_ma...
base/process/memory_mac.mm:133: void* oom_killer_malloc(struct _malloc_zone_t*
zone,
I think this may break OOM crash bucketing on Mac, FYI.

[DmitrySkiba, 2017-01-10 21:48:33]

dskiba@chromium.org changed reviewers:
+ dskiba@chromium.org

[DmitrySkiba, 2017-01-10 21:48:34]

https://codereview.chromium.org/2601573002/diff/300001/base/allocator/allocat...
File base/allocator/allocator_shim.h (right):

https://codereview.chromium.org/2601573002/diff/300001/base/allocator/allocat...
base/allocator/allocator_shim.h:65: using BatchMallocFn = unsigned(const
AllocatorDispatch* self,
We should also add a callback for free_definite_size, which is now just calls
free, which I suspect slightly regresses performance (because free has to find
allocation size again).

Also, how about somehow marking that these are macOS specific? Maybe #ifdef them
out on other platforms?

[Primiano Tucci (use gerrit), 2017-01-17 17:09:59]

Had a first pass here. First of all, thanks for all the hard work here, I
understand this stuff is ... tough.

An overall comment before the inline ones:
I am perfectly happy with your line of thought here, that is: OSX has these
extra malloc zones. They would be too much of a pain to shim, requiring to
rearchitect it, for very little benefit. 

My only objection is that the current CL is making the overall code that handles
the allocation a bit confusing: essentially you end up having some of the bits
in base/memory_mac.mm and some of the bits in base/allocator, which is quite
unfortunate purely for the sake of following this code (and more practically for
the sake of base owners to handle this review).

Here's my proposal:
right now 99% memory_mac.mm is about intercepting the various functions in the
zones and mangling them. It has 3-4 zones (default, purgable, core foundation,
etc) and we are only interested in one.
I think a clean solution is:
step 1) Move 99% of this file into base/allocator/mac_allocator_zones.mm (or
some similar name). The 1% remaining would be just UncheckedMalloc,
UncheckedCalloc & friends that are the ones defining what declared and expected
in base/memory

step 2) for the default zone, introduce a Save/Restore-like API for the default
zone. So you end up in a state where this mac_allocator_zones.mm can:
 A. route all the non-default zones to the current oom kill implementation
 B. get/unprotect the default zone
 C. set the default zone to something else

Step 3) introduce the shim magic and use B,C from Step 2 to imlement the shim.

This might be a bit more CLs but has IMHO the benefit of being more manageable
for reviewers.
step 1 and 2 will be pure refactoring, so should be quite easy for base
reviewers to digest it.
step 3 is the real change, but at that point you will be mostly calling an API
that you introduced in 2.
Also this split should make it more easy to #ifdef EXPERIMENTAL_SHIM and
understand the new vs old behavior.
Also, as a final result, all the allocator code will live consistently in one
place without weird splits.

WDYT? Happy to expand more offline if necessary

https://codereview.chromium.org/2601573002/diff/300001/base/allocator/allocat...
File base/allocator/allocator_shim_override_mac_symbols.h (right):

https://codereview.chromium.org/2601573002/diff/300001/base/allocator/allocat...
base/allocator/allocator_shim_override_mac_symbols.h:1: // Copyright 2016 The
Chromium Authors. All rights reserved.
s/2016/2017/ happy new year :)
also I think this file is mixing together the shim entry and exit point.
If you look at the other platforms, there are two sets of files in the shim
usually:
1) allocator_shim_override_XXX.h
2) allocator_shim_default_dispatch_to_YYY.cc

1 is the entrypoint, essentially the magical mechanism that make it so that when
something in chrome calls malloc & friend, that call is diverted to the shim.
From what I see here, this is the case here for InitializeAllocatorShim, 
ShimZoneCallbacks, etc

2 is the exit point. After the chain of dispatchers has been traversed, this
file defines how to go back to the actual malloc implementation (the last link
of the chain). This is the case here for the definition of
AllocatorDispatch::default_dispatch
and the various MallocImpl* etc

I'd keep 1 and 2 separate, mostly for the sake of keeping the pattern of the
shim consistent. It's already quite complicated as you can see, I'd avoid adding
more entropy :)

Now, I am aware that the tricky part here is that there is a dependency on the
two. Essentially when you initialize the shim you retrieve and save the old
methods in that g_unshimmed_zone and than use that after the dispatch.
The best way that comes to my mind is to follow the pattern that siggi followed
on Win, which is creating a separate .cc file (see win_stubs) which is used by
both.

This also links to the other comment that I have  about memory_mac.mm

https://codereview.chromium.org/2601573002/diff/300001/base/allocator/allocat...
base/allocator/allocator_shim_override_mac_symbols.h:85: void
ShimZoneCallbacks(ChromeMallocZone* zone) {
just for clarify I think should be called InitializeShimZoneCallbacks,
SetupShimZoneCallbacks  or similar

https://codereview.chromium.org/2601573002/diff/300001/base/allocator/allocat...
base/allocator/allocator_shim_override_mac_symbols.h:166:
InitializeAllocatorShim();
Hmm this:
- will cause the static initializers check to go red on the main waterfall and
revert the cl
- is a bit too magical. If I read the current code correctly, it is all
initialized by EnableTerminationOnOutOfMemory(), which is called in
content_main_runner.cc. Can we keep th same pattern, i.e. create an explicit
InitializeAllocatorShim() api in allocator_shim.h and call it from
content_main_runner.cc
- concretely this might open new bugs that we were not exposed before because we
call this too early

https://codereview.chromium.org/2601573002/diff/300001/build/config/allocator...
File build/config/allocator.gni (right):

https://codereview.chromium.org/2601573002/diff/300001/build/config/allocator...
build/config/allocator.gni:19: if ((is_linux || is_android || is_mac ||
the pattern I used in the past was to flip the switch separately. 
In the past this always broke some random bot in a random waterfall and took a
bunch of attempts to stick.
Having the flag in a separate CL avoids revert/reland thrashing on the rest of
the code

https://codereview.chromium.org/2601573002/diff/300001/chrome/app/framework.o...
File chrome/app/framework.order (right):

https://codereview.chromium.org/2601573002/diff/300001/chrome/app/framework.o...
chrome/app/framework.order:21: __Znam
why these symbols are changing?

[erikchen, 2017-01-23 21:55:23]

> My only objection is that the current CL is making the overall code that
handles
> the allocation a bit confusing: essentially you end up having some of the bits
> in base/memory_mac.mm and some of the bits in base/allocator, which is quite
> unfortunate purely for the sake of following this code (and more practically
for
> the sake of base owners to handle this review).
I'm happy to break this CL into smaller CLs.

[erikchen, 2017-01-27 22:47:11]

On 2017/01/23 21:55:23, erikchen wrote:
> > My only objection is that the current CL is making the overall code that
> handles
> > the allocation a bit confusing: essentially you end up having some of the
bits
> > in base/memory_mac.mm and some of the bits in base/allocator, which is quite
> > unfortunate purely for the sake of following this code (and more practically
> for
> > the sake of base owners to handle this review).
> I'm happy to break this CL into smaller CLs.

Refactors have been landing, follow at
https://bugs.chromium.org/p/chromium/issues/detail?id=665567.

New version of this CL up at https://codereview.chromium.org/2658723007/, only
primiano added as a reviewer. To reply to some comments from this CL:

rsesek: The new CL does not turn on the experimental shim yet, so we can punt
this discussion by one more CL. That being said, the process should still die in
TerminateBecauseOutOfMemory(), but instead it will be called from
oom_killer_new(), which should more closely mirror the behavior of the other
platforms.

dskiba: I hooked up free_definite_size. #ifdef is not a good way of marking this
as mac-only, since that pollutes #ifdefs in all the files. 

primiano: The new CL has been refactored as per your request.

[erikchen, 2017-01-27 22:47:19]

Description was changed from

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

On macOS, there is an additional abstraction layer called malloc zones. This CL
only hooks the default malloc zone, which appears to be responsible for most
allocations. There is no good mechanism [short of interposition] to determine
when new malloc zones are added, so there's no clean mechanism of hooking all
zones. Plus we would have to rework the allocator shim abstraction.

BUG=665567
==========

to

==========
mac: Hook up allocator shim.

This CL is based on dskiba's CL at https://codereview.chromium.org/2499373003/#.

This CL makes several changes:
  * Hooks into C/C++ heap allocations so that they go through base/allocator.
    This brings macOS into parity with the other platforms.
  * Add two new functions to AllocatorDispatch: BatchMallocFn and BatchFreeFn.

On macOS, there is an additional abstraction layer called malloc zones. This CL
only hooks the default malloc zone, which appears to be responsible for most
allocations. There is no good mechanism [short of interposition] to determine
when new malloc zones are added, so there's no clean mechanism of hooking all
zones. Plus we would have to rework the allocator shim abstraction.

BUG=665567
==========

[Robert Sesek, 2017-01-30 11:07:22]

On 2017/01/27 22:47:11, erikchen wrote:
> rsesek: The new CL does not turn on the experimental shim yet, so we can punt
> this discussion by one more CL. That being said, the process should still die
in
> TerminateBecauseOutOfMemory(), but instead it will be called from
> oom_killer_new(), which should more closely mirror the behavior of the other
> platforms.

I have no problem with changing these functions. Just please also update the
magic signature generator after it lands so that things continue to bucket as
OOM correctly.