Upgrade AlignedMemory to support dynamic allocations.

base/memory/aligned_memory.cc

Index: base/memory/aligned_memory.cc
diff --git a/base/memory/aligned_memory.cc b/base/memory/aligned_memory.cc
new file mode 100644
index 0000000000000000000000000000000000000000..f88495f06468bcd9a6730199e6beb35f06346f3d
--- /dev/null
+++ b/base/memory/aligned_memory.cc
@@ -0,0 +1,42 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "base/memory/aligned_memory.h"
+
+#if defined(OS_ANDROID) || defined(OS_NACL)

[willchan no longer on Chromium, 2012/07/23 18:48:45]

As per Chromium style guide, please move platform specific #includes after all
the cross-platform ones.

[DaleCurtis, 2012/07/23 19:04:27]

Done.

+#include <malloc.h>
+#endif
+
+#include "base/logging.h"
+
+namespace base {
+
+void* AlignedAlloc(size_t size, size_t alignment) {
+  DCHECK_GT(size, 0U);
+  DCHECK_EQ(alignment & (alignment - 1), 0U);
+  DCHECK_EQ(alignment % sizeof(void*), 0U);
+  void* ptr = NULL;
+#if defined(COMPILER_MSVC)
+  ptr = _aligned_malloc(size, alignment);
+// Both Android and NaCl technically support posix_memalign(), but do not expose
+// it in the current version of the library headers used by Chrome.  Luckily,
+// memalign() on both platforms returns pointers which can safely be used with

[Jeffrey Yasskin, 2012/07/23 18:34:40]

I've seen too many incorrect claims of this form to believe them anymore. ;)
("This data race is totally safe I promise!!1! ... *crash*")

Since there's no documentation, would it be too much to ask you to file bugs
against NaCl and Android to _add_ documentation, and link to them from here?
Then at least future maintainers have somewhere to go check to see if the
claim's become incorrect in the mean time. If I'm overstepping my limits as a
chrome reviewer, it's ok to tell me to buzz off on this. :)

[DaleCurtis, 2012/07/23 19:04:27]

The absolute worst case here is free() silently accepting non-malloc'd
addresses.  The more likely case seems to be that free() will crash immediately
if this statement is not true.

In any case, I'll file documentation bugs w/ the respective projects as soon as
GoogleCode goes out of read-only mode.

[willchan no longer on Chromium, 2012/07/23 19:15:44]

AIUI, passing non-malloc'd addresses to free() is a security hole. 

[DaleCurtis, 2012/07/23 19:32:21]

We have confirmation from NaCl and Android that this is safe (via jvoung and via
commit message / code in dlmalloc / Bionic), just no user documentation; so my
comment was more of a "what if".  You're correct though on the security
implications, my point was that I suspect the likely case is fail fast.

+// free(), so we can use it instead.
+#elif defined(OS_ANDROID) || defined(OS_NACL)
+  ptr = memalign(alignment, size);
+#else
+  if (posix_memalign(&ptr, alignment, size))
+    ptr = NULL;
+#endif
+  // Since aligned allocations may fail for non-memory related reasons, force a
+  // crash if we encounter a failed allocation; maintaining consistent behavior
+  // with a normal allocation failure in Chrome.
+  CHECK(ptr) << "If you crashed here, your aligned allocation is incorrect: "

[willchan no longer on Chromium, 2012/07/23 18:48:45]

I know Jeffrey asked for more info here, but in order to avoid binary bloat,
please remove the message portion here. Alternatively, only keep those strings
in debug mode.

[DaleCurtis, 2012/07/23 19:04:27]

Done.

+      << "size=" << size << ", alignment=" << alignment;
+  // Sanity check alignment just to be safe.
+  DCHECK_EQ(reinterpret_cast<uintptr_t>(ptr) & (alignment - 1), 0U);
+  return ptr;
+}
+
+}  // namespace base