Fix partition_alloc unit tests.

base/allocator/partition_allocator/PartitionAlloc.md

 # PartitionAlloc Design
 
 This document explains a high-level design of PartitionAlloc.
 If you're interested in its in-depth implementation, see comments
-in PartitionAlloc.h.
+in partition_alloc.h.
 
 [TOC]
 
 ## Overview
 
 PartitionAlloc is a memory allocator optimized for performance and security
 in Blink. All objects in Blink are expected to be allocated with
 PartitionAlloc or Oilpan (but not yet done).
 
 ## Partitions and buckets
@@ skipping 50 matching lines @@
 ## Security
 
 Security is one of the most important goals of PartitionAlloc.
 
 Different partitions are guaranteed to exist in separate address spaces.
 When objects contained in a page in a partition are all freed,
 the physical memory is returned to the system but the address space
 remains reserved. The address space may be reused later only for the partition.
 Remember that PartitionAlloc puts LayoutObjects into a dedicated partition.
 This is because LayoutObjects are likely to be a source of use-after-free.
-Simiarly, PartitionAlloc puts Strings, Vectors etc into the Buffer partition
+Similarly, PartitionAlloc puts Strings, Vectors etc into the Buffer partition
 because the length and/or contents may be exploited by user scripts.
 This means that PartitionAlloc greedily uses virtual address spaces in favor of
 security hardening.
 
 Also the following security properties are provided:
 
 * Linear overflows cannot corrupt into the partition.
 
 * Linear overflows cannot corrupt out of the partition.
 
 * Metadata is recorded in a dedicated region (not next to each object).
 Linear overflow or underflow cannot corrupt the metadata.
 
 * Buckets are helpful to allocate different-sized objects on different addresses.
 One page can contain only similar-sized objects.
 
 * Dereference of a freelist pointer should fault.
 
 * Partial pointer overwrite of freelist pointer should fault.
 
 * Large allocations are guard-paged at the beginning and end.