commit 5129a5ddd1d504ec730f2ae4f72ff4593908f4a4
author Benoît Lizé <lizeb@chromium.org> Tue Oct 15 09:53:08 2019
committer Commit Bot <commit-bot@chromium.org> Tue Oct 15 09:53:08 2019
tree f84037026e95dcc2c1a2e22af05d8d88e9454f5a
parent b1a7500d2f773f1ef994f8b4a80508aae5f7df58

base/allocator: Use typed encoded/decoded freelist entries.

In PartitionAlloc, the freelist entries are encoded (except for the head). The
encoding process is symmetric, meaning that there was a single "Transform()"
function. This is confusing and error-prone.

This adds a type for an encoded freelist entry, making the difference
clearer.

Note that this fixes a bug of PartitionAlloc on big endian platforms. In
PartitionPurgePage(), the tail of the freelist had an un-encoded nullptr
value. This is incorrect, as the code using it would decode the value, and get
the wrong one as a consequence. This does not trigger on little-endian
platforms, as the transformation we use is such that Encode(nullptr) == nullptr,
but on big endian ones Encode(ptr) = ~ptr, meaning that this would lead to a
crash.

It seems that Chrome does not ship on big endian platforms though (and that no
chromium-based project uses PartitionAlloc on big endian platforms), as
otherwise this would crash the renderer very quickly. The issue is eliminated
with the new types.

There is no behavior change in this CL on little endian, and should not impact
performance either.

Bug: 998048, 787153
Change-Id: I67798659202156360aeddc6e71c5d330f5daa163
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1857328
Commit-Queue: Benoit L <lizeb@chromium.org>
Reviewed-by: Egor Pasko <pasko@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#705884}