Clean up and clarify PartitionAlloc

Source/wtf/PartitionAlloc.h

 /*
  * Copyright (C) 2013 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 123 matching lines @@
 // constant values, we pack _all_ partitionAllocGeneric() sizes perfectly up
 // against the end of a system page.
 static const size_t kPartitionPageShift = 14; // 16KB
 static const size_t kPartitionPageSize = 1 << kPartitionPageShift;
 static const size_t kPartitionPageOffsetMask = kPartitionPageSize - 1;
 static const size_t kPartitionPageBaseMask = ~kPartitionPageOffsetMask;
 static const size_t kMaxPartitionPagesPerSlotSpan = 4;
 
 // To avoid fragmentation via never-used freelist entries, we hand out partition
 // freelist sections gradually, in units of the dominant system page size.
-// What we're actually doing is avoiding filling the full partition page
-// (typically 16KB) will freelist pointers right away. Writing freelist
-// pointers will fault and dirty a private page, which is very wasteful if we
-// never actually store objects there.
+// What we're actually doing is avoiding filling the full partition page (16 KB)

[Jens Widell, 2015/09/03 13:11:45]

I guess this comment meant to discuss the "bucket pages" (my own term, not used
in the code) that are multiples of partition pages, and indeed "typically 16 KB"
(i.e. a single partition page) at least for smaller bucket sizes. "Bucket pages"
are logically what PartitionBucket::activePagesHead point to.

In other words, |X x partition page| makes up the storage for a "bucket page" of
which |Y x bucket slot size| will be used, thus leaving |Z x system page size|
memory permanently unused. (Z might be zero.)

And the restricted freelist filling discussed here avoids filling up the whole
bucket page, by touching as few system pages as possible. It doesn't care
specifically about partition page boundaries.

+// with freelist pointers right away. Writing freelist pointers will fault and
+// dirty a private page, which is very wasteful if we never actually store
+// objects there.
 static const size_t kNumSystemPagesPerPartitionPage = kPartitionPageSize / kSystemPageSize;
 static const size_t kMaxSystemPagesPerSlotSpan = kNumSystemPagesPerPartitionPage * kMaxPartitionPagesPerSlotSpan;
 
 // We reserve virtual address space in 2MB chunks (aligned to 2MB as well).
 // These chunks are called "super pages". We do this so that we can store
 // metadata in the first few pages of each 2MB aligned section. This leads to
 // a very fast free(). We specifically choose 2MB because this virtual address
 // block represents a full but single PTE allocation on ARM, ia32 and x64.
 //
 // The layout of the super page is as follows. The sizes below are the same
@@ skipping 653 matching lines @@
 using WTF::partitionAlloc;
 using WTF::partitionFree;
 using WTF::partitionAllocGeneric;
 using WTF::partitionFreeGeneric;
 using WTF::partitionReallocGeneric;
 using WTF::partitionAllocActualSize;
 using WTF::partitionAllocSupportsGetSize;
 using WTF::partitionAllocGetSize;
 
 #endif // WTF_PartitionAlloc_h